By · Last updated 2026-03-13

Zurück zum BlogKI-Sicherheit

Wie Samsung dreimal innerhalb eines Monats...

Drei verschiedene Samsung-Ingenieurteams haben im April 2023 proprietären Code und vertrauliche Daten in ChatGPT eingefügt.

March 13, 20269 min Lesezeit
Samsung ChatGPT leaksource code protectionenterprise AI controlsinsider data leakageMCP Server anonymization

Aktualisiert für 2026

Drei Teams, drei Leaks, ein Monat

Im April 2023 gab Samsung Semiconductor drei separate Vorfälle bekannt. Drei verschiedene Teams hatten innerhalb eines einzigen Monats proprietäre Daten an einen KI-Chatbot übermittelt. Die Vorfälle standen nicht miteinander in Verbindung. Verschiedene Personen, verschiedene Rollen, verschiedene Tage.

Sie hatten nur zwei Gemeinsamkeiten. Jede Person nutzte das Tool für echte Arbeit. Jede übermittelte versehentlich Daten, die Samsung nicht außerhalb des Unternehmens teilen wollte.

Vorfall 1 — Quellcode. Ein Softwareingenieur war dabei, Gerätecode zu debuggen. Er fügte proprietären Halbleiter-Quellcode in den Chat ein. Der Code enthielt Fertigungs-IP.

Vorfall 2 — Besprechungsnotizen. Ein Mitarbeiter erstellte eine Zusammenfassung eines Meetings. Sie reichte ihre Notizen zur Verdichtung ein. Diese Notizen enthielten vertrauliche Strategie- und Roadmap-Details.

Vorfall 3 — Datenbankabfrage. Ein dritter Mitarbeiter wollte Hilfe bei einer langsamen Abfrage. Er teilte die Datenbankstruktur und die Abfragelogik. Diese Logik referenzierte proprietäre Schemata und Geschäftsregeln.

Drei Vorfälle. Drei Offenbarungen. Ein Monat.

Warum die Mitarbeiter es taten

Keiner der drei handelte fahrlässig. Sie nutzten ein KI-Tool für Aufgaben, für die KI-Tools gebaut wurden. Code-Review. Textzusammenfassung. Abfrageoptimierung. Jede Aufgabe war legitim.

Das fehlende Element war eine technische Sperre. Kein System blockierte die Übertragung, bevor sie einen externen Server erreichte. Kein Filter erkannte proprietäre Bezeichner, bevor sie das Netzwerk verließen. Zwischen dem echten Bedarf des Mitarbeiters und dem externen Dienst stand nichts.

Eine Richtlinienwarnung existierte. Aber eine Warnung ist keine Barriere. Das Risiko eines versehentlichen Fehlers war abstrakt und weit entfernt. Der Produktivitätsvorteil war real und unmittelbar. Vernünftige Mitarbeiter wählten Produktivität.

Das Ergebnis war vorhersehbar. Drei Vorfälle in dreißig Tagen. Drei IP-Offenbarungen. Eine Unternehmenskrise, die branchenweit Verbote auslöste.

Die Reaktion der Branche

Samsung handelte schnell. Es schränkte den KI-Tool-Zugang auf Unternehmensgeräten ein.

Andere Organisationen folgten. Zu denen, die Einschränkungen ankündigten, gehörten Bank of America, Citigroup, Goldman Sachs, JPMorgan Chase, Apple und Verizon. Der Finanzsektor reagierte am schnellsten. Große Banken und Technologieunternehmen kamen zum gleichen Schluss. KI-Tools ohne technische Kontrollen stellten ein inakzeptables Compliance-Risiko dar.

Jede einzelne Organisation gelangte zum gleichen Befund. Mitarbeiter sind nicht das Problem. Richtlinienwarnungen reichen nicht aus. Daten verließen Unternehmensnetzwerke, weil nichts sie aufhielt. Richtlinien allein können keine technische Sperre erzeugen.

Die 71,6-%-Umgehungsrate

Der Verbotsansatz hat eine gemessene Fehlerquote. LayerX-Forschung aus 2025 ergab, dass 71,6 % der Mitarbeiter, die Unternehmens-KI-Verboten unterliegen, KI-Tools weiterhin nutzten. Sie verwendeten persönliche Konten oder persönliche Geräte.

Der Grund ist einfach. Ein Tool, das echten Mehrwert bietet, wird genutzt. Menschen finden Umgehungswege, anstatt es aufzugeben. KI kann die Aufgabenzeit halbieren. Eine Richtlinienwarnung ändert diese Kalkulation nicht. Mitarbeiter melden sich von einem persönlichen Telefon oder Laptop an. Sicherheitsteams können diesen Traffic nicht sehen.

Das praktische Ergebnis ist der schlimmste Fall. Unternehmensdaten erreichen weiterhin KI-Anbieter. Aber jetzt fließen sie durch Kanäle ohne jegliche Aufsicht. Unternehmensgeräte-Traffic könnte zumindest protokolliert werden. Die Nutzung persönlicher Konten ist unsichtbar.

Samsungs drei Vorfälle ereigneten sich auf Unternehmensgeräten. Mitarbeiter, die das Verbot umgehen, tun dasselbe. Sie senden Arbeitsdaten an KI-Modelle. Aber jetzt läuft es über Kanäle ohne Unternehmenssichtbarkeit.

Die technische Lösung für die Ursache

Samsungs Vorfälle wurden nicht durch unvorsichtige Menschen verursacht. Sie wurden durch eine Architektur ohne Abfangschicht verursacht. Zwischen dem Prompt des Mitarbeiters und dem Server des Anbieters gab es nichts.

Model Context Protocol (MCP)-Architektur schließt diese Lücke. Sie platziert einen transparenten Proxy im Datenpfad. Entwickler, die Claude Desktop oder Cursor IDE verwenden, sind die primäre Zielgruppe. Das sind genau die Tools, die für das Code-Debugging hinter Samsungs erstem Vorfall eingesetzt wurden. Der MCP Server sitzt im Protokollpfad für beide.

Bevor Text das KI-Modell erreicht, führt der MCP Server ihn durch einen Anonymisierungsschritt. Quellcode wird auf proprietäre Bezeichner gescannt. Funktionsnamen, Variablennamen und API-Endpunkte werden durch strukturierte Token ersetzt. Datenbankschema-Details und Konfigurationswerte werden ebenfalls ersetzt. Der Austausch erfolgt, bevor der Code das Netzwerk verlässt.

Ein Entwickler, der proprietären Code debuggt, sendet Code über den MCP-Client. Die sensiblen Bezeichner sind zu diesem Zeitpunkt bereits Token. Das KI-Modell hilft weiterhin beim Debugging. Die eigentlichen proprietären Details erreichen die Server des Anbieters nie.

Vorfall 1 wird technisch unmöglich. Der Quellcode verlässt das Netzwerk bereits anonymisiert. Der Ingenieur erhält die benötigte Hilfe. Das IP bleibt unter Unternehmenskontrolle.

Dieselbe Logik gilt für Vorfall 2. Die Zusammenfassung von Besprechungsnotizen über browserbasierte Tools wird durch die Chrome Extension und ihre Unternehmenskontrollen adressiert. Vorfall 3 wird durch MCP-Anonymisierung in jeder KI-Coding-Oberfläche abgedeckt.

Verbote vs. technische Kontrollen

Das Verbieten von Tools, die 71,6 % der Mitarbeiter bereits umgehen, reduziert das Risiko nicht. Es verlagert das Risiko in unsichtbare Kanäle.

Der Browser-DLP-Tool-Vergleich deckt Abfangoptionen für browserbasierte KI-Nutzung ab. Für Organisationen, die Anonymisierung mit anderen DLP-Produkten vergleichen, behandelt der Nightfall vs. anonym.legal-Vergleich den Kompromiss zwischen Blockierung und Anonymisierung direkt.

Samsungs Vorfälle waren ein frühes Signal. Die Ursache war eine Abwesenheit. Keine Abfangschicht. Keine technische Kontrolle. Diese Lücke ist jetzt schließbar. Die Frage ist, ob Unternehmen die Lösung einsetzen oder sich weiterhin auf Verbote verlassen, die die meisten Mitarbeiter bereits umgehen.

Quellen

Bereit, Ihre Daten zu schützen?

Beginnen Sie mit der Anonymisierung von PII mit über 285 Entitätstypen in 48 Sprachen.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.