Warum personenbezogene Daten ein Problem für KI-Verarbeitung sind
Wenn ein AI Agent einen Arbeitsvertrag analysiert, eine Gehaltsabrechnung prüft oder eine Krankmeldung verarbeitet, arbeitet er mit personenbezogenen Daten. Name, Adresse, Geburtsdatum, Sozialversicherungsnummer, Gehalt, Diagnose.
Auf einen Blick - PII-Anonymisierung für Enterprise AI
- Roundtrip-Pseudonymisierung ersetzt PII durch konsistente Pseudonyme vor der LLM-Verarbeitung und setzt nach der Verarbeitung die Echtdaten wieder ein.
- Der Decision Layer steuert, welche PII-Kategorien pro Prozess (HR, Finance, Compliance) erkannt werden - über versionierte Regelwerke.
- Pseudonymisierung erhält Dokumentenstruktur und Kontext - anders als Schwärzung, die Dokumente für KI-Analyse unbrauchbar macht.
- Confidence Routing eskaliert mehrdeutige Entitäten an einen Menschen; implizite Identifikatoren erfordern Kontextregeln im Regelwerk.
- IAPP (2024) stellt fest, dass 58 % der Organisationen, die Dokumente mit KI verarbeiten, keine systematische PII-Erkennung haben - mit entsprechendem DSGVO-Risiko.
Diese Daten an ein Sprachmodell zu senden - auch an ein selbst gehostetes - ist datenschutzrechtlich problematisch. Die DSGVO verlangt Datensparsamkeit (Art. 5 Abs. 1 lit. c): Es dürfen nur die Daten verarbeitet werden, die für den Zweck erforderlich sind. Für die Klassifizierung eines Belegtyps braucht das Modell keinen Mitarbeiternamen. Für die Prüfung einer Gehaltsband-Compliance braucht es kein Geburtsdatum.
Trotzdem braucht das Modell Kontext. Ein Vertrag ohne jegliche Personeninformation ist für eine KI-Analyse wertlos - es fehlen die Bezüge, die Relationen, die Zusammenhänge.
Die Lösung ist nicht Schwärzung, sondern Pseudonymisierung.
Roundtrip-Pseudonymisierung: Das Prinzip
Roundtrip-Pseudonymisierung ist ein dreistufiger Prozess:
Schritt 1: Erkennen und Ersetzen. Der Pre-Processing Layer erkennt alle personenbezogenen Daten im Dokument. Jede PII-Instanz wird durch ein konsistentes Pseudonym ersetzt: “Max Müller” wird zu “Person_A”, “52.000 EUR” wird zu “Gehalt_A”, “Hallerstraße 8” wird zu “Adresse_A”. Wichtig: Die Pseudonyme sind konsistent - wenn “Max Müller” auf Seite 3 nochmals erwähnt wird, ist er dort ebenfalls “Person_A”. Das erhält die Dokumentenstruktur.
Schritt 2: Verarbeiten. Das pseudonymisierte Dokument wird an das Sprachmodell übergeben. Das Modell sieht: “Person_A hat Gehalt_A an Adresse_A. Der Vertrag läuft bis 2027.” Es kann die Vertragsanalyse durchführen, die Gehaltsband-Prüfung, die Klausel-Klassifizierung - ohne je einen echten Namen oder ein echtes Gehalt gesehen zu haben.
Schritt 3: Re-Anonymisieren. Der Output des Modells enthält Pseudonyme: “Person_A liegt innerhalb des Gehaltsbands E3.” Der Re-Anonymisierungs-Layer ersetzt die Pseudonyme durch die Echtdaten: “Max Müller liegt innerhalb des Gehaltsbands E3.” Die Zuordnungstabelle wird nach Abschluss gelöscht.
Was der Decision Layer steuert
Nicht jedes Datenfeld muss pseudonymisiert werden. Der Decision Layer definiert, welche PII-Kategorien erkannt und ersetzt werden - gesteuert durch ein versioniertes Regelwerk:
Für einen HR-Prozess: Namen, Gehälter, Adressen, Sozialversicherungsnummern pseudonymisieren. Jobtitel und Abteilungen können bleiben - sie sind für die Analyse relevant und nicht personenbezogen.
Für einen Finance-Prozess: Firmennamen bleiben, Ansprechpartner werden pseudonymisiert, Beträge bleiben (sie sind für die Buchungsentscheidung relevant), Bankverbindungen werden pseudonymisiert.
Für einen Compliance-Prozess: Alles pseudonymisieren - auch Firmennamen, wenn die Analyse produktübergreifend sein soll.
Diese Regeln sind mandantenspezifisch und versioniert. Wenn sich die Betriebsvereinbarung ändert, entsteht eine neue Regelversion. Bei einer Prüfung ist nachvollziehbar, welche PII-Regel in welcher Version zum Verarbeitungszeitpunkt galt.
Grenzen und ehrliche Einschätzung
PII-Erkennung ist nicht perfekt. Named Entity Recognition (NER) macht Fehler - besonders bei:
Ambigen Namen: “Müller” kann ein Nachname oder eine Firmenbezeichnung sein. “Frankfurt” kann eine Stadt oder ein Nachname sein. Der Decision Layer adressiert das durch Confidence Routing: Bei hoher Konfidenz wird automatisch pseudonymisiert. Bei niedriger Konfidenz wird an einen Menschen eskaliert.
Impliziten Identifikatoren: “Die einzige Entwicklerin in der Hamburger Niederlassung” enthält keine explizite PII, identifiziert aber eine Person. Solche indirekten Identifikatoren sind schwer automatisch zu erkennen. Der Ansatz: Kontextregeln im Regelwerk definieren die Kombination aus Merkmalen die eine Identifikation ermöglichen.
Neuen Dokumententypen: Wenn ein neuer Dokumententyp verarbeitet wird, muss das PII-Regelwerk geprüft und ggf. erweitert werden. Das ist kein einmaliges Setup, sondern ein laufender Prozess.
| PII-Kategorie | HR-Prozess | Finance-Prozess | Compliance-Prozess |
|---|---|---|---|
| Namen | Pseudonymisiert | Ansprechpartner pseudonymisiert | Alles pseudonymisiert |
| Gehälter / Beträge | Pseudonymisiert | Bleiben (Buchungsentscheidungen) | Pseudonymisiert |
| Adressen | Pseudonymisiert | Bleiben | Pseudonymisiert |
| ID-Nummern (SVN) | Pseudonymisiert | Pseudonymisiert | Pseudonymisiert |
| Firmennamen | Bleiben | Bleiben | Pseudonymisiert |
| Jobtitel | Bleiben | Bleiben | Kontextabhängig |
| Bankverbindungen | Pseudonymisiert | Pseudonymisiert | Pseudonymisiert |
Mehr zu Document Intelligence: Document Intelligence - PII, Vertragsschwärzung, Signaturerkennung
Termin vereinbaren - Wir zeigen Ihnen die Roundtrip-Pseudonymisierung an Ihren Dokumenten.
Bert Gogolin
Geschäftsführer, Gosign
AI Governance Briefing
Enterprise AI, Regulierung und Infrastruktur - einmal im Monat, direkt von mir.