Datenmaskierung für KI: Personenbezogene Daten vor dem Modellzugriff schützen

Datenmaskierung für KI sorgt dafür, dass Namen, Kundennummern oder Gesundheitsangaben nicht ungefiltert in externe KI-Modelle gelangen. Das ist relevant, weil ein Auftragsverarbeitungsvertrag die rechtliche Zusammenarbeit regelt, aber keinen einzigen riskanten Prompt technisch stoppt.

Ein typischer Fall aus dem Arbeitsalltag: Eine Sachbearbeiterin will eine lange Kundenbeschwerde zusammenfassen lassen und kopiert den vollständigen E-Mail-Verlauf in ChatGPT oder einen anderen KI-Dienst. Im Text stehen Ansprechpartner, private Telefonnummern, Vertragsnummern und vielleicht eine Information zur Erkrankung eines Mitarbeiters. Der Nutzen der KI ist legitim. Der unkontrollierte Datenabfluss ist es nicht. Datenmaskierung für KI trennt deshalb die fachliche Aufgabe vom Personenbezug.

Datenmaskierung für KI gehört vor das Modell

Die wirksame Schutzmaßnahme sitzt zwischen Nutzer und KI-Modell. Ein zentrales KI-Gateway nimmt jede Anfrage entgegen, prüft den Inhalt, maskiert erkannte personenbezogene Daten und leitet erst dann den bereinigten Prompt an das freigegebene Modell weiter. Dasselbe Gateway ersetzt Platzhalter in der Antwort wieder, falls der jeweilige Anwendungsfall das erfordert.

Diese Position in der Architektur ist entscheidend. Eine Nutzungsrichtlinie kann untersagen, Kundendaten einzugeben; sie erkennt aber nicht, ob ein Vertriebsmitarbeiter es in einer stressigen Minute trotzdem tut. Ein Browser-Plugin ist ebenfalls keine belastbare Kontrollinstanz, wenn Mitarbeitende über Schnittstellen, Automatisierungen oder private Tools arbeiten. Das Gateway schafft einen technischen Zwangspunkt. Ohne diesen Punkt bleibt Datenschutz bei KI weitgehend eine Vertrauensfrage.

Ein Beispiel: Der Prompt „Formuliere eine Antwort an Frau Anna Weber, Kundennummer 482991, zu ihrem Vertrag“ wird vor dem Versand zu „Formuliere eine Antwort an [PERSON_1], [KUNDENNUMMER_1], zu ihrem Vertrag“. Das externe Modell sieht den Fallkontext, aber keine direkt identifizierende Person. Nach der Verarbeitung kann das interne System die Platzhalter wieder mit den Originalwerten verbinden.

Named-Entity-Recognition erkennt mehr als Namen

Named-Entity-Recognition, kurz NER, ist die technische Grundlage für die automatische Erkennung schutzbedürftiger Textstellen. Ein NER-Modell ordnet Textabschnitten Kategorien zu, etwa PERSON, ORGANISATION, ORT oder DATUM. Für Datenmaskierung für KI reicht ein allgemeines Sprachmodell allein allerdings selten aus. Unternehmensdaten folgen ihren eigenen Mustern.

In einem Logistikunternehmen ist eine Sendungsnummer oft kein personenbezogenes Datum, kann aber über das Fachsystem unmittelbar zu einem Empfänger führen. In der Personalabteilung kann eine Personalnummer denselben Effekt haben. Ein Modell muss daher mit fachlichen Regeln ergänzt werden. Reguläre Ausdrücke erkennen beispielsweise IBANs, E-Mail-Adressen, Telefonnummern und Kreditkartennummern zuverlässig. Wörterbücher erfassen bekannte Kundenbezeichnungen oder interne Projektnamen. Kontextregeln helfen bei Fällen, die formal harmlos aussehen: Die Zahl „170492“ ist nur eine Zahl, bis sie hinter „Mitarbeiter-ID“ steht.

Die Praxis verlangt eine Erkennungs-Pipeline statt eines einzelnen Filters. Zuerst laufen klare Formate über Regelwerke. Danach bewertet Named-Entity-Recognition den Fließtext. Schließlich prüft eine Klassifikation, ob der gesamte Vorgang in eine besonders sensible Kategorie fällt, etwa Personalakte oder Gesundheitsfall. Wer alles einem einzigen NER-Modell überlässt, produziert entweder Lücken oder eine so hohe Fehlalarmrate, dass Fachbereiche das System umgehen.

Maskieren, pseudonymisieren oder anonymisieren: Die Methode muss zum Zweck passen

Datenmaskierung ist kein einheitlicher Vorgang. Für einen KI-gestützten Entwurf einer Kundenantwort braucht das Unternehmen oft eine reversible Pseudonymisierung: „Anna Weber“ wird zu „[PERSON_1]“, und nur das interne Gateway kennt die Zuordnung. Die Daten bleiben personenbezogen, weil eine Re-Identifizierung möglich ist. Datenschutzrechtlich ist das eine wichtige Grenze.

Anonymisierung geht weiter. Sie entfernt oder verändert Informationen so, dass eine Person nach vernünftigem Aufwand nicht mehr identifiziert werden kann. Ein Beispiel aus dem Controlling: Statt einzelner Aufträge mit Kundennamen an ein Modell zu geben, übermittelt das System aggregierte Monatswerte je Produktgruppe. Wenn eine Gruppe nur einen Auftrag enthält, hilft die Aggregation nicht; dann ist die Aussage weiterhin rückführbar. Gute Anonymisierung bewertet deshalb Kombinationen von Merkmalen, nicht nur einzelne Felder.

Redaktion ist die strengste Variante. Das Gateway ersetzt einen Fund durch „[ENTFERNT]“ und verwirft den Originalwert für diesen Verarbeitungsschritt. Das passt etwa zu Freitexten aus Schadenmeldungen, wenn ein externes Modell lediglich Tonalität und Struktur verbessern soll. Die Adresse der betroffenen Person trägt dazu nichts bei und hat im Prompt nichts verloren.

Die Wahl der Methode folgt dem Geschäftszweck. Reversible Tokenisierung ist sinnvoll, wenn die KI-Antwort später wieder konkrete Daten enthalten muss. Für Analysen oder Wissensabfragen ist echte Anonymisierung meist die bessere Architektur. Bei besonderen Kategorien personenbezogener Daten nach Artikel 9 Datenschutz-Grundverordnung, etwa Gesundheitsdaten, sollte die Standardentscheidung nicht „maskieren“, sondern „nicht an ein externes Modell senden“ lauten.

Die Qualität der Erkennung muss messbar sein

Ein Filter, der 95 Prozent der Namen erkennt, klingt ordentlich. Bei 10.000 Prompts im Monat bleiben rechnerisch 500 potenzielle Treffer ungeprüft. Ob das akzeptabel ist, entscheidet nicht eine Folie im Projektkickoff, sondern eine Risikoanalyse je Datenklasse und Prozess.

Dafür braucht das Team einen Testsatz aus realistischen, freigegebenen Beispielen. Er sollte Tippfehler, Abkürzungen, kopierte Tabellen, deutsche Umlaute und Fälle aus verschiedenen Fachabteilungen enthalten. Messen Sie mindestens zwei Werte: Recall beschreibt, wie viele tatsächlich vorhandene sensible Daten das System erkennt; Precision zeigt, wie viele Markierungen tatsächlich korrekt sind. Ein niedriger Recall lässt Daten durch. Eine niedrige Precision macht aus einem brauchbaren KI-Werkzeug eine Frustmaschine, weil es harmlose Inhalte ständig blockiert.

Ein brauchbarer Betriebsmodus arbeitet mit Risikostufen. Eine E-Mail-Adresse kann automatisch tokenisiert werden. Bei einem Hinweis auf eine Diagnose blockiert das Gateway die Anfrage und verweist auf ein internes Modell oder einen definierten Fachprozess. Unklare Fälle landen nicht bei einer Person zur manuellen Prompt-Prüfung, denn das skaliert weder organisatorisch noch datenschutzrechtlich. Sie werden nach Regeln behandelt, die der Datenschutzbeauftragte und die Fachverantwortlichen mittragen.

Datenmaskierung für KI braucht Protokollierung und klare Grenzen

Protokollierung beantwortet die Frage, was wann wohin geflossen ist. Das Audit-Log sollte Nutzerkennung, Zeitpunkt, Modell, Datenklasse, angewendete Maskierungsregel und Ergebnis enthalten. Den vollständigen Originalprompt dauerhaft zu speichern, wäre dagegen oft ein neues Datenschutzproblem. Protokollieren Sie Ereignisse und technische Entscheidungen, nicht blind sämtliche Inhalte.

Die Architektur muss auch entscheiden können, wann kein externer Modellzugriff zulässig ist. Für Personalakten, vertrauliche M&A-Unterlagen oder detaillierte Finanzdaten führt kein Weg an einer souverän betriebenen KI-Umgebung vorbei. Offene Modelle auf europäischer Infrastruktur können hier eine belastbare Option sein, wenn Betrieb, Zugriffsrechte, Schlüsselmanagement und Logging sauber umgesetzt sind. Die Frage lautet dann nicht mehr, ob ein einzelner Prompt „wohl okay“ ist. Die Datenklasse entscheidet über den vorgesehenen Verarbeitungspfad.

Das ist der Unterschied zwischen einer KI-Richtlinie und einer KI-Architektur. Die Richtlinie sagt Mitarbeitenden, was sie tun sollen. Die Architektur verhindert, dass ein Fehler aus Zeitdruck unmittelbar zum Datenschutzvorfall wird.

FAQ

Reicht ein Auftragsverarbeitungsvertrag für den Einsatz von ChatGPT aus?

Nein. Ein Auftragsverarbeitungsvertrag ist erforderlich, wenn die Voraussetzungen für Auftragsverarbeitung vorliegen, aber er kontrolliert weder Prompt-Inhalte noch Datenflüsse im Arbeitsalltag. Unternehmen brauchen zusätzlich eine Rechtsgrundlage, ein Verzeichnis der Verarbeitungstätigkeiten, passende technische und organisatorische Maßnahmen sowie eine Prüfung, ob eine Datenschutz-Folgenabschätzung erforderlich ist. Datenmaskierung für KI ist eine dieser technischen Maßnahmen.

Kann Named-Entity-Recognition personenbezogene Daten zuverlässig erkennen?

Named-Entity-Recognition erkennt viele typische Entitäten gut, aber nie fehlerfrei. Besonders schwierig sind interne Kennungen, Schreibfehler, Daten in Tabellen und Informationen, deren Personenbezug nur aus dem Fachkontext entsteht. Deshalb kombiniert eine belastbare Lösung NER mit Formatregeln, kundenspezifischen Wörterbüchern und restriktiven Regeln für sensible Datenklassen.

Ist Pseudonymisierung dasselbe wie Anonymisierung?

Nein. Bei der Pseudonymisierung kann das Unternehmen die Zuordnung über eine intern geschützte Tabelle oder einen Token-Service wiederherstellen. Die Daten bleiben damit personenbezogen. Anonymisierte Daten lassen keine Identifizierung mehr zu; sie fallen nur dann nicht mehr unter die Datenschutz-Grundverordnung, wenn die Anonymisierung tatsächlich belastbar ist.

Welche Daten sollten nie an ein externes KI-Modell gehen?

Gesundheitsdaten, Inhalte aus Personalakten, Zugangsdaten, private Schlüssel und nicht veröffentlichte Geschäftsgeheimnisse gehören grundsätzlich nicht in externe KI-Prompts. Auch bei Vertragsdaten, detaillierten Finanzinformationen und Kundenvorgängen ist der externe Weg nur vertretbar, wenn Datenmaskierung, Zweckbindung und der konkrete Anbieter geprüft sind. Häufig ist ein intern oder europäisch betriebener Modellpfad die bessere Lösung.

Fazit

B2B-Unternehmen im Rhein-Main-Gebiet, etwa in Darmstadt oder Frankfurt, sollten KI-Zugänge nicht über Richtlinien und Einzelentscheidungen steuern, sondern über ein zentrales Gateway mit Datenmaskierung für KI, Modellrouting und revisionsfähigem Logging. Beginnen Sie mit einem klar abgegrenzten Prozess und einem realistischen Testsatz; anschließend lassen sich die Regeln kontrolliert auf weitere Fachbereiche ausweiten. Wenn Sie die KI-Potenziale für Ihr Unternehmen besprechen möchten, vereinbaren Sie einen Termin mit dataso.