By · Last updated 2026-03-09

Zurück zum BlogKI-Sicherheit

JPMorgan, Goldman Sachs, Apple: Warum...

27,4 % der Inhalte von Unternehmens-AI-Chatbots enthalten sensible Daten – ein Anstieg um 156 % im Jahresvergleich.

March 9, 20269 min Lesezeit
enterprise AI securityChatGPT banAI data controlsshadow AI

Die Welle der KI-Verbote in Unternehmen

In den letzten zwei Jahren haben die meisten großen Unternehmen öffentliche KI-Tools verboten. Die Verbote kamen schnell. Sie betrafen ChatGPT und ähnliche Tools.

Dazu gehören JPMorgan Chase, Deutsche Bank, Wells Fargo, Goldman Sachs, Bank of America, Apple und Verizon. Alle haben ChatGPT und ähnliche Tools gesperrt.

Der Auslöser war Samsung. Im Jahr 2023 hob Samsung sein internes ChatGPT-Verbot auf. Innerhalb eines Monats gab es drei Datenlecks. Mitarbeiter fügten Halbleiter-Code in ChatGPT ein. Andere fügten Fehlererkennungs-Code ein. Andere fügten Besprechungsnotizen ein. Alle Daten landeten auf den Servern von OpenAI. Samsung hatte keine Möglichkeit, sie zurückzuholen. Das Verbot kam zurück.

Sicherheitsteams sahen den Samsung-Fall als klare Lektion. Wenn ein Technologieunternehmen Lecks nicht stoppen kann, blockiert man die Tools. Einfach.

Oder so dachte man.

Warum die Verbote gescheitert sind

Aktualisiert für 2026

27,4 % aller Inhalte, die in KI-Chatbots für Unternehmen eingegeben werden, enthalten sensible Daten. Das ist ein Anstieg von 156 % gegenüber dem Vorjahr (Zscaler 2025 Data@Risk Report).

Diese Zahl zeigt, was nach den Verboten passiert ist: Mitarbeiter nutzten KI weiter. Sie wechselten einfach zu privaten Konten.

71,6 % des KI-Zugriffs in Unternehmen erfolgt jetzt über nicht-betriebliche Konten. Das umgeht alle unternehmensinternen DLP-Kontrollen (LayerX 2025 Enterprise GenAI Security Report).

Das Verbot hat die KI-Nutzung nicht gestoppt. Es hat KI in den Untergrund gedrängt.

Ein Entwickler auf einem Unternehmenskonto war für die Sicherheit zumindest sichtbar. Logs wurden erstellt. DLP-Alarme wurden ausgelöst. Als dieser Entwickler auf demselben Gerät zu einem privaten Konto wechselte, war alle Sichtbarkeit weg. Gleiche Daten. Keine Kontrolle.

Das Verbot des Unternehmenskontos stoppt das Verhalten nicht. Derselbe Dienst ist nur ein privates Konto entfernt.

Was Mitarbeiter an KI senden

Der Zscaler 2025 Data@Risk Report zeigt, was Mitarbeiter wirklich an KI-Chatbots senden. Die 27,4 % sensible Daten verteilen sich auf diese Kategorien:

  • Proprietäre Geschäftsinformationen und Geschäftsgeheimnisse
  • Kundendaten — Namen, Kontaktdaten, Kontonummern
  • Persönliche Daten von Mitarbeitern
  • Quellcode, manchmal mit eingebetteten Zugangsdaten
  • Finanzdaten — unveröffentlichte Ergebnisse, Deal-Bedingungen, Vertragswerte
  • Rechtliche und privilegierte Mitteilungen

Der Anstieg von 156 % im Jahresvergleich (Zscaler 2025) bedeutet nicht, dass Mitarbeiter unvorsichtiger wurden. Er spiegelt das Wachstum bei der KI-Nutzung wider. Mehr Mitarbeiter nutzen KI für mehr Aufgaben. Mehr sensible Daten fließen dadurch in diese Tools.

Die Produktivitätskosten

Der Sicherheitsfall für ein KI-Verbot ist klar. Der Produktivitätsfall dagegen ist ebenso klar.

Studien zeigen, dass KI-Tools große Vorteile für Wissensarbeiter bringen:

  • Entwickler mit KI-Coding-Tools schließen Aufgaben schneller ab
  • Rechtsteams mit KI für die Dokumentenprüfung bearbeiten mehr Dateien pro Stunde
  • Kundensupport-Teams mit KI für Entwürfe bearbeiten mehr Tickets pro Schicht

Wenn Unternehmen KI für Entwickler verbieten, deren Konkurrenten sie frei nutzen, ist die Lücke real. Analysten ohne KI-Tools fallen zurück. Kollegen in anderen Unternehmen nutzen KI jeden Tag. Die Lücke wächst.

Die Bypass-Rate von 71,6 % ist nicht nur Regelverstoß. Es ist rational. Der Gewinn durch KI ist groß genug, dass Mitarbeiter das Risiko einer Richtlinienverletzung akzeptieren. Sie geben das Tool nicht auf. Das Verbot fordert sie auf, einen Vorteil aufzugeben, auf den sie sich verlassen.

Die technische Lösung

Das Sicherheitsproblem ist real. Sensible Daten, die an externe KI-Anbieter fließen, schaffen echtes Risiko. Aber die Lösung ist technischer Natur — kein Verbot, das Mitarbeiter umgehen.

Der Ansatz: Sensible Daten anonymisieren, bevor sie das KI-Modell erreichen.

So funktioniert es. Ein Entwickler fügt eine Datenbankabfrage mit Kunden-IDs in Claude ein:

  1. Der Entwickler fügt die Abfrage ein — Kunden-IDs, Kontonummern, Namen inklusive
  2. Eine Anonymisierungsschicht fängt sie vor der Übertragung ab
  3. Kunden-IDs werden zu [ID_1], Kontonummern zu [ACCT_1], Namen zu [CUSTOMER_1]
  4. Die anonymisierte Abfrage erreicht Claude
  5. Claudes Antwort verwendet dieselben Token
  6. Der Entwickler liest die Antwort und versteht den Fix

Claude hat keine echten Kundendaten verarbeitet. Sensible Daten haben das Unternehmensnetzwerk nie verlassen. Der Entwickler hat die Hilfe bekommen, die er brauchte. Die Sicherheit hat nichts zu untersuchen.

MCP-Server für Entwickler

Entwickler, die Claude Desktop oder Cursor IDE verwenden, brauchen einen transparenten Proxy. Das Model Context Protocol (MCP) bietet einen.

Der anonym.legal MCP-Server sitzt zwischen dem KI-Client des Entwicklers und der KI-Modell-API. Aller Text, der über MCP gesendet wird, passiert zuerst die Anonymisierungsmaschine. Das umfasst Dateiinhalte, Code-Snippets, Fehlermeldungen und Konfigurationsdateien.

Aus Sicht des Entwicklers nutzen sie Claude oder Cursor wie gewohnt. Die Anonymisierung ist unsichtbar.

Aus Sicht des Sicherheitsteams verlässt kein proprietärer Code oder Kundendaten das Netzwerk in lesbarer Form. Das Modell erhält anonymisierte Versionen. Antworten werden bei der Rückgabe de-anonymisiert.

Das löst das Samsung-Problem direkt. Jene Mitarbeiter, die Quellcode in ChatGPT eingefügt haben, hätten anonymisierten Code gesendet. Proprietäre Details wären durch Token ersetzt worden, bevor sie OpenAI erreichten.

Chrome-Erweiterung für Browser-KI

Der MCP-Server deckt die IDE-integrierte KI ab. Browser-basierte KI — Claude.ai, ChatGPT, Gemini — braucht eine separate Schicht.

Die Chrome-Erweiterung fängt Text ab, bevor er über den Browser übermittelt wird. Dieselbe Anonymisierungsmaschine läuft. Namen, Unternehmenskennungen, Quellcode-Geheimnisse und Finanzdaten werden zu Token. Sie werden ersetzt, bevor die Anfrage die Server des Anbieters erreicht.

MCP-Server für IDEs plus Chrome-Erweiterung für Browser deckt jeden KI-Berührungspunkt im Unternehmen ab. Zusammen schließen sie die Lücke.

Der Business-Case

Für CISOs, die diesen Ansatz dem Management vorstellen, hat der Fall drei Teile:

1. Sicherheit gleich einem Verbot — Was externe KI-Anbieter erreicht, enthält keine wiederherstellbaren sensiblen Daten. Ein Verstoß beim KI-Anbieter würde nichts Nützliches liefern. Keine Kundendaten. Kein geistiges Eigentum. Keine Betriebsdetails.

2. Kein Produktivitätsverlust — Mitarbeiter nutzen KI-Tools wie gewohnt. Anonymisierung ist transparent. Die Ausgabequalität bleibt gleich. KI-Modelle funktionieren genauso gut mit pseudonymisierten Inhalten wie mit echten Daten.

3. Eliminiert den Bypass — Die Bypass-Rate von 71,6 % zeigt Mitarbeiter, die Produktivität über Richtlinien stellen. Wenn sie KI über Unternehmenskonten ohne Risiko nutzen können, verschwindet das Bypass-Motiv. Die Sicherheit gewinnt die volle Sichtbarkeit zurück.

Das Aktionsplan nach dem Verbot

Für Unternehmen mit KI-Verboten, die bereit sind, voranzugehen, läuft der Übergang in vier Phasen:

Phase 1 — Wochen 1–2: Chrome-Erweiterung über Chrome Enterprise Policy auf allen Unternehmensgeräten bereitstellen. Das gibt sofortige Browser-Abfangung für Mitarbeiter, die bereits persönliche Konten nutzen.

Phase 2 — Wochen 3–4: MCP-Server auf Entwickler-Workstations bereitstellen. Benutzerdefinierte Entity-Muster für interne Kennungen einrichten — Produktcodes, Kontoformate und proprietäre Begriffe.

Phase 3 — Monat 2: KI-Verbot für Unternehmenskonten aufheben. Mitarbeiter können KI jetzt mit technischen Kontrollen statt nur mit Richtlinien nutzen.

Phase 4 — Laufend: Anonymisierungsaktivität überwachen. Verfolgen, welche Datentypen am meisten gefährdet sind. Das nutzen, um Schulungsprioritäten festzulegen und die Entity-Erkennung anzupassen.

Der Samsung-Vorfall hat die Welle der KI-Verbote in Unternehmen ausgelöst. Es war ein Sicherheitsversagen. Es war keine eingebaute Eigenschaft von KI-Tools. Die technischen Kontrollen, die es zum Zeitpunkt des Samsung-Vorfalls nicht gab, existieren jetzt. Sicherheitsteams können sie einsetzen. Oder sie verlassen sich weiter auf Verbote, die 71,6 % der Mitarbeiter bereits umgehen.


Der MCP-Server und die Chrome-Erweiterung von anonym.legal bieten die technische Kontrollschicht für KI in Unternehmen. Beide Tools funktionieren transparent. Mitarbeiter nutzen KI wie gewohnt. Sensible Daten werden anonymisiert, bevor sie externe KI-Anbieter erreichen.

Siehe auch:

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.