Der Schutz personenbezogener Daten sieht völlig anders aus, sobald KI im Spiel ist

Drei Jahrzehnte lang bedeutete der Schutz personenbezogener Daten, zu kontrollieren, wo Daten gespeichert wurden und wer die Datenbank erreichen konnte. KI-Werkzeuge haben dieses Modell in etwa achtzehn Monaten demontiert.

Das ist keine Kritik an der KI. Es ist die Beschreibung eines strukturellen Wandels – und ihn zu verstehen, ist der Unterschied zwischen einem Datenschutz, der tatsächlich funktioniert, und einem Datenschutz, der bei einem Compliance-Audit gut aussieht, in der Praxis aber in dem Moment versagt, in dem ein Wissensarbeiter ein Chatfenster öffnet.

Das alte Modell – und warum es funktionierte

Der klassische Schutz personenbezogener Daten war für strukturierte Daten gedacht: CRM-Datensätze, Patientensysteme, HR-Datenbanken, Finanzbuchhaltungen. Die Bedrohung war der unbefugte Zugriff – ein Angreifer oder ein nicht berechtigter Mitarbeiter, der Daten erreicht, die er nicht erreichen sollte.

Die Antwort war entsprechend strukturiert:

• Tokenisierung und Verschlüsselung auf Feldebene in Datenbanken: Sozialversicherungsnummern und Kontonummern werden im Ruhezustand durch undurchsichtige Token ersetzt. Nur berechtigte Dienste können das Token wieder zum Original auflösen.
• Rollenbasierte Zugriffskontrollen: einschränken, welche Mitarbeiter welche Tabellen abfragen können. Jeden Lesezugriff protokollieren.
• Netzwerk-DLP (Data Loss Prevention): den ausgehenden Verkehr auf strukturierte Muster personenbezogener Daten durchsuchen – Format von Sozialversicherungsnummern, Kreditkartennummern, IBAN-Muster – und die Exfiltration blockieren, bevor sie den Unternehmensperimeter verlässt.
• Datenmaskierung in Nicht-Produktionsumgebungen: mit realistisch aussehenden, aber synthetisch erzeugten Daten testen, die keine echten Identitäten enthalten.

Das funktionierte, weil Daten an abgegrenzten, bekannten Orten lebten. Man konnte die Systeme aufzählen, die personenbezogene Daten hielten, die Speicher- und Netzwerkschichten in Kontrollen einwickeln, und diese Kontrollen hielten gegen das Bedrohungsmodell, für das sie gebaut waren.

Was KI-Werkzeuge verändert haben

Die Angriffsfläche hat sich verschoben – nicht weil KI-Werkzeuge unsicher wären, sondern weil sie einen neuen, reibungslosen Weg vom kontrollierten Speicher zur externen Verarbeitung eingeführt haben.

Betrachten Sie den Arbeitsablauf: Ein Wissensarbeiter öffnet SharePoint, lädt ein Vertrags-PDF herunter, öffnet ChatGPT und fügt den Inhalt ein. Er war berechtigt, auf das Dokument zuzugreifen – keine Zugriffskontrolle wurde verletzt. Er hat keine Daten im technischen Sinne exfiltriert – er hat ein zugelassenes Gerät im Unternehmensnetz genutzt. Aber das Dokument, mit jedem Namen, jeder Adresse und jeder Finanzzahl darin, ist soeben zu kommerzieller Cloud-Infrastruktur gewandert, in die die Organisation keinen Einblick hat, die kein Vertrag regelt und über die es kein Audit-Protokoll gibt.

Das alte Werkzeug hat dafür keinen Griff:

• Netzwerk-DLP erkennt strukturierte Muster in Datei-Uploads und ausgehenden Strömen, aber die meisten KI-Interaktionen geschehen als HTTPS-POST-Anfragen an eine Web-Oberfläche – der Proxy sieht die Zieldomäne, nicht den Inhalt des Nachrichtenkörpers.
• Datenbank-Tokenisierung schützt personenbezogene Daten im Ruhezustand. Zu dem Zeitpunkt, an dem ein Nutzer ein PDF heruntergeladen hat und es liest, wurden die Daten bereits aus dem Token-Speicher entnommen, rekonstruiert und dargestellt. Das Token-System hat genau das getan, wozu es gedacht war – es war nur nicht für den nächsten Schritt ausgelegt.
• Zugriffskontrollen waren in dem Moment erfüllt, in dem der berechtigte Nutzer die Datei öffnete. Was nach diesem Zugriff geschieht, liegt absichtlich außerhalb ihres Bereichs.

Das alte Modell setzte voraus, dass die Kontrolle des Zugriffs auf Daten gleichbedeutend mit der Kontrolle dessen war, was mit den Daten geschah. KI-Werkzeuge haben diese Annahme sauber gebrochen. Berechtigter Zugriff plus ein Chatfenster ergibt Daten, die die Organisation verlassen – leise, legal (aus Sicht der Zugriffskontrolle) und in großem Umfang.

Warum die Filterung auf Cloud-Seite zu kurz greift

Eine Antwort auf diese Lücke besteht darin, den gesamten KI-Verkehr durch einen Unternehmens-Proxy zu leiten, der Anfragen abfängt, nach personenbezogenen Daten durchsucht, sie schwärzt und die bereinigte Version weiterleitet. Dieser Ansatz existiert und ist besser als nichts. Aber er hat strukturelle Grenzen:

• Er erfordert eine SSL-Inspektion des HTTPS-Verkehrs – technisch invasiv, betrieblich teuer und zunehmend infrage gestellt durch die Sicherheitsmodelle der Browser und durch den Widerstand der Mitarbeiter aus Gründen des Datenschutzes.
• Er erfordert eine Konfiguration je KI-Werkzeug. Während sich die Verbreitung von KI-Werkzeugen beschleunigt, wächst die Konfigurationsfläche schneller, als irgendein Sicherheitsteam Schritt halten kann. Ein neues KI-Werkzeug wird in dem Moment zur Lücke, in dem ein Nutzer es entdeckt.
• Er erfasst strukturierte Muster personenbezogener Daten (Format von Sozialversicherungsnummern, IBAN), tut sich aber schwer mit frei formulierten Namen, Adressen und kontextabhängigen Identifikatoren – die den Großteil der personenbezogenen Daten in beruflichen Dokumenten ausmachen.
• Er kann das Kopieren und Einfügen aus Anwendungen außerhalb des Proxy-Bereichs nicht erfassen – Mobilgeräte, persönliche Geräte, Abläufe nach dem Muster „offline und dann eingefügt“.

Die Filterung auf Cloud-Seite behandelt KI als einen zu überwachenden Kanal statt als ein neu zu gestaltendes Verhalten. Die zugrunde liegende Handlung – ein Nutzer, der sensible Inhalte aus einem kontrollierten System entnimmt und einem externen Dienst übergibt – geschieht weiterhin. Die Filterung fügt mittendrin eine Bremsschwelle hinzu. Sie geht die Wurzel nicht an.

Der Vergleich im Klartext

Dimension Klassisches DLP Anonymisierung auf Client-Seite

Die richtige Grenze: vor der KI, auf dem Gerät

Der Eingriff muss erfolgen, bevor die Daten das Gerät des Nutzers verlassen – nicht am Netzwerkperimeter, nicht in der Infrastruktur des KI-Anbieters, nachdem der Schaden geschehen ist.

Das erfordert ein anderes Denkmodell. Statt zu fragen „Wie überwachen wir, was Nutzer an KI-Werkzeuge senden?“, wird die Frage zu: „Wie geben wir den Nutzern eine Version ihrer Dokumente, die strukturell sicher an jedes beliebige KI-Werkzeug zu senden ist?“

Die entscheidende Erkenntnis ist, dass die KI keine Identitäten braucht, um ihre Arbeit zu tun. Sie braucht Struktur, Sprache und Kontext. „Alice Martin, geboren am 14. März 1987, wohnhaft 14 rue des Acacias, Lyon, Kundenreferenz A-2091“ sagt einem großen Sprachmodell nichts Zusätzliches über die Vertragsklausel, die es analysieren soll. Entfernen Sie die Identität, behalten Sie die Klausel. Die Ausgabe der KI ist genauso nützlich – und die Originaldaten haben das Gerät nie verlassen.

Wie promptShield das umsetzt

promptShield läuft vollständig offline auf dem Gerät des Nutzers – keine Cloud-Inferenz, kein Netzwerkaufruf während der Anonymisierung. Die Erkennungspipeline wendet drei Schichten auf jedes Dokument an:

• Regex — hochpräzise strukturierte Muster: IBAN, Sozialversicherungsnummer, E-Mail, Telefon, Passnummer und andere Formate von Dokumentkennungen über 7 europäische Sprachen. Diese feuern zuerst, mit hoher Präzision, und erfordern kein Laden eines Modells.
• Entitätserkennung — spaCy- und Transformer-Modelle, die lokal laufen und Namen, Adressen, Organisationen und Daten im Kontext erkennen. Derselbe Entitätsname, der über mehrere Seiten wiederkehrt, wird verknüpft, sodass die Anonymisierung auf Seite 1 ihn auf Seite 4 automatisch unterdrückt.
• Optionaler LLM-Durchlauf — für mehrdeutige Fälle löst ein lokal laufendes GGUF-Modell Grenzfälle auf, ohne Daten irgendwohin zu senden.

Jede erkannte Entität wird durch ein stabiles, typisiertes Token ersetzt: [PERSON_1], [ADDRESS_2], [IBAN_1]. Die Zuordnung zwischen Token und Originalwert wird in einer lokalen SQLite-Datenbank gespeichert – dem Token-Register –, das niemals das Gerät verlässt.

Der Nutzer fügt das anonymisierte Dokument in ein beliebiges KI-Werkzeug ein. Die KI erstellt ihre Analyse anhand der Token. Wenn der Nutzer die Ausgabe der KI auf das Originaldokument anwenden möchte, setzt promptShield die echten Werte wieder ein. Der analytische Arbeitsablauf bleibt unverändert. Die Preisgabe ist strukturell beseitigt.

Was sich ändert und was nicht

Die Anonymisierung auf Client-Seite schließt eine bestimmte Lücke: den reibungslosen Weg von einem kontrollierten Dokument zu einem externen KI-Dienst. Sie ersetzt keine Zugriffskontrollen, ersetzt keine Audit-Protokollierung und nimmt nicht die Notwendigkeit, Mitarbeiter zum angemessenen Umgang mit KI zu schulen.

Was sie ändert, ist das Risikomodell speziell für den KI-Anwendungsfall. Sobald Sie vor dem Einfügen anonymisieren, hat die Frage „Was passiert, wenn ein Mitarbeiter ChatGPT auf ein Mandantendokument anwendet?“ eine andere Antwort. Die KI erhält strukturierten Inhalt – Klausellogik, Finanzkennzahlen, Vertragsarchitektur – ohne angehängte Identifikatoren. Es gibt nichts mehr preiszugeben.

Der alte Perimeter war der Dokumentenspeicher. Der neue Perimeter muss das Dokument selbst sein – genauer: der Moment, in dem es von einem abgegrenzten System zu freiem Text in den Händen eines Nutzers übergeht.

Genau diese Grenze war das klassische DLP nie gebaut zu halten. Es ist die, die jetzt zählt.