KI-Anonymisierung und NER: der Leitfaden, der Anonymisierung, Pseudonymisierung und DSGVO entwirrt (2026)
Quick Answer: Was ist KI-Anonymisierung und NER?
Anonymisierung und Pseudonymisierung durch KI stützen sich auf die NER-Technik (Named Entity Recognition, „Erkennung benannter Entitäten”: die Fähigkeit einer KI, automatisch Namen, Adressen, Nummern, Daten, Organisationen in einem Text zu erkennen). Die KI identifiziert diese personenbezogenen Daten und ersetzt sie durch Marker oder Pseudonyme.
Kritische DSGVO-Unterscheidung:
- Anonymisierung: irreversible Transformation. Die Daten fallen aus dem Anwendungsbereich der DSGVO heraus (Erwägungsgrund 26). Technisch sehr schwer zu erreichen — die Person darf nie wieder identifizierbar sein, auch nicht durch Verknüpfung mit anderen Quellen, auch nicht, wenn jemand den Schlüssel wiederherstellt.
- Pseudonymisierung (Art. 4 Nr. 5 DSGVO): reversibler Ersatz unter strenger Zugriffskontrolle. Die Daten bleiben personenbezogen im Sinne der DSGVO, das Risiko ist aber reduziert.
Die Mehrheit der sogenannten „KI-Anonymisierungs”-Projekte erzeugt in Wirklichkeit eine Pseudonymisierung. Das ist das Erste, was geklärt werden muss: Alles andere — Rechtsgrundlage, DSFA, Aufbewahrungsdauer, Drittlandtransfers — folgt daraus.
Toolset 2026:
- Große Sprachmodelle (Mistral Large, Aleph Alpha Luminous, GPT-4o, Claude): 95-98 % Genauigkeit auf Standarddeutsch, einfach über Prompt einsetzbar, aber Inferenzkosten und Anbieterabhängigkeit.
- Spezialisierte NER-Modelle (spaCy de_core_news_lg, German BERT NER von Deepset, GLiNER, Microsoft Presidio): schneller, günstiger bei Volumen, aber starre Taxonomie.
- Für Souveränität: Mistral on-premise oder Llama 3 selbst gehostet + spaCy intern, null Datenabfluss in die USA — relevant für Krankenkassen, gesetzliche Krankenversicherung, Kanzleien und Banken.
Belastbare Use Cases: Korpusvorbereitung für internes Fine-Tuning, Teilung mit akademischen Partnern unter AVV, Antwort auf ein Auskunftsersuchen nach Art. 15 DSGVO ohne Drittpersonen preiszugeben, Management-Analyse interner Korpora unter Wahrung der Mitbestimmung des Betriebsrats, sektorale Compliance (Krankenkassen, ärztliche Schweigepflicht, KWG), Dokumentenvorbereitung vor Aufruf eines SaaS-LLM.
Warum dieses Thema, warum jetzt
Viele deutsche Organisationen haben im Kopf: „unsere Dokumente an einen LLM senden, aber ohne die personenbezogenen Daten darin”. Die Idee ist gesund. Das Versprechen wird selten eingelöst.
Drei Dinge haben sich 2026 geändert. Erstens, moderne LLMs beherrschen NER auf Deutsch wirklich — das war 2022 nicht der Fall. Zweitens, dedizierte Open-Source-Modelle (spaCy, GLiNER, German BERT NER) sind heute in Reichweite einer souveränen Bereitstellung — kein einziges Wort muss an OpenAI gesendet werden, um ein einziges Wort zu anonymisieren. Drittens, die regulatorische Doktrin hat sich verhärtet: BfDI und EDSA wiederholen regelmäßig, dass Pseudonymisierung nicht Anonymisierung ist (EDSA-Stellungnahme 28/2024).
Die Falle: zu glauben, ein Namensdetektor reiche aus, „aus der DSGVO herauszukommen”. Das reicht nicht. Dieser Artikel entwirrt, was funktioniert, was nicht funktioniert und wo die Linie zwischen KI, Organisation, DSB und menschlicher Validierung gezogen werden muss.
Anonymisierung vs. Pseudonymisierung: die Unterscheidung, die alles ändert
Das ist die Basis. Alles andere — Rechtsgrundlage, DSFA, Auftragsverarbeitungsverträge, Aufbewahrungsdauer — hängt von dieser Unterscheidung ab.
Anonymisierung im Sinne der DSGVO
Damit Daten wirklich anonymisiert sind, müssen drei Bedingungen gleichzeitig erfüllt sein, wie sie der BfDI in seinem Positionspapier zur Anonymisierung 2020 darlegt:
- Keine direkte Re-Identifikation — Namen, Identifikatoren, Steuer-IDs, Krankenversicherungsnummern werden entfernt oder transformiert.
- Keine indirekte Re-Identifikation — keine Attributkombination kann eine Person isolieren. Das umfasst singuläre Kontexte („der einzige Vertriebsleiter, der ACME GmbH im März 2025 verlassen hat”).
- Keine Re-Identifikation durch Verknüpfung — auch durch Verknüpfung mit dem Handelsregister, dem Bundesanzeiger, einem LinkedIn-Export oder einem offenen Dataset bleibt die Person ununterscheidbar.
Sind diese drei Bedingungen erfüllt, fallen die Daten aus dem Anwendungsbereich der DSGVO heraus. Das ist das maximale Versprechen.
Diese drei Bedingungen zu erreichen ist technisch sehr schwer, besonders für Freitexte (Mails, Protokolle, Verträge). Formale Techniken existieren — k-anonymity, l-diversity, t-closeness — aber sie betreffen vor allem tabellarische Datenbanken, nicht Freitext.
Pseudonymisierung im Sinne der DSGVO
Art. 4 Nr. 5 DSGVO definiert sie als „die Verarbeitung personenbezogener Daten in einer Weise, dass die personenbezogenen Daten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt werden und technischen und organisatorischen Maßnahmen unterliegen”.
Konkret: Maria Schmidt wird durch Person_001 ersetzt, und eine Tabelle Person_001 → Maria Schmidt wird woanders unter sehr eingeschränktem Zugang aufbewahrt. Pseudonymisierung reduziert das Risiko stark, aber die Daten bleiben personenbezogen im Sinne der DSGVO. Alle Pflichten gelten: Verarbeitungsverzeichnis (Art. 30), Rechtsgrundlage, Aufbewahrungsdauer, Betroffenenrechte, DSFA falls anwendbar, AVV mit Auftragsverarbeitern.
Schnelle Entscheidungstabelle
| Kriterium | Anonymisierung | Pseudonymisierung |
|---|---|---|
| Personenbezug | Unwiderruflich zerstört | Über separaten Schlüssel erhalten |
| DSGVO-pflichtig? | Nein | Ja |
| Machbarkeit auf Freitext | Sehr schwer | Mit NER + Policy machbar |
| Typischer Use Case | Veröffentlichung offener Datasets | Interne Verarbeitung, eingerahmtes Teilen |
| Restrisiko | Nahe null (gut gemacht) | Niedrig, aber nicht null |
| Umsetzungsaufwand | Hoch | Moderat |
Praxisurteil: Die meisten sogenannten „KI-Anonymisierungs”-Projekte sind in Wirklichkeit Pseudonymisierungen. Das ist keine Schwäche, das ist ein klarer Rahmen. Die Falle besteht darin, Anonymisierung zu versprechen und Pseudonymisierung zu liefern: Die Compliance bricht zusammen, und der DSB entdeckt das Problem sechs Monate später — typischerweise bei einer Prüfung durch die Landesdatenschutzbehörde.
NER: was es leistet, was es nicht leistet
Die Mechanik
NER (Named Entity Recognition) identifiziert in einem Text die benannten Entitäten, die zu vordefinierten Kategorien gehören. Eine klassische Taxonomie für den deutschen Kontext:
| Kategorie | Beispiel | DSGVO-Sensibilität |
|---|---|---|
| PER — Person | Maria Schmidt, Herr Müller | Direkter Identifikator |
| ORG — Organisation | ACME GmbH, AOK Bayern | Indirekt (mit PER kombiniert) |
| LOC — Ort | Berlin, Friedrichstraße 24 | Indirekt, manchmal direkt (genaue Adresse) |
| DATE | 15. März 2026 | Indirekt (Daten persönlicher Ereignisse) |
| EMAIL / PHONE / IBAN / STEUER_ID / KV_NR | maria@acme.de, 030 12345678 | Direkte Identifikatoren |
| MISC — Sonstige | Aktenzeichen, interne Referenz | Variabel |
Für die Pseudonymisierung in deutschen Unternehmen wird diese Taxonomie um Geschäftskategorien erweitert: Patientennummer (KIS), Mandanten-ID, Aktenzeichen, sensitive Beträge, Vertragsidentifikatoren, Postleitzahl (kombiniert mit Alter und Geschlecht stark identifizierend — Sweeney-Resultat aus den USA überträgt sich auf deutsche PLZ). Diese fachliche Typisierung macht den Unterschied zwischen generischem NER und nutzbarer Pseudonymisierung.
Vereinfachtes Pipeline-Schema
[Quelltext]
│
▼
[NER] → Liste erkannter Entitäten (Typ, Wert, Position)
│
▼
[Ersetzungsrichtlinie] → was löschen, was pseudonymisieren, was behalten
│
▼
[Pseudonymgenerierung] → Tabelle „Original → Pseudonym"
│ │
│ ▼
│ [Sicherer Tresor]
▼ (Re-ID-Schlüssel,
[Pseudonymisierter Text] sehr eingeschränkter Zugriff)Der Tresor ist das kritische Bauteil. Wenn jemand auf die Korrespondenztabelle zugreifen kann, bricht die Pseudonymisierung zusammen. Das ist ein architektonischer Punkt, kein Implementierungsdetail — die Landesdatenschutzbehörde wird genau diese Kontrolle bei einer Prüfung untersuchen.
Was NER nicht sieht
NER, selbst hervorragendes, übersieht drei Familien identifizierender Daten:
1. Indirekt identifizierende Daten durch Kontext. „Der Vertriebsleiter, der ACME GmbH im März 2025 zu einem Konkurrenten verlassen hat” — kein Eigenname im Satz, aber nur eine Person der Welt passt. Der NER erkennt „Vertriebsleiter”, „ACME GmbH”, „März 2025”. Er versteht nicht, dass die Kombination singulär ist.
2. Seltene Kombinationen. „Frau, 47 Jahre, Agraringenieurin, wohnhaft in Garmisch, Mutter von Zwillingen” — kein Element ist isoliert identifizierend, die Gesamtheit aber stark. Kein NER erkennt „seltene Kombination”.
3. Implizite interne Referenzen. „Wie gestern am Telefon besprochen, hier der Briefentwurf für den Mandanten, von dem wir sprachen” — der NER sieht keine identifizierbare Entität, und doch weiß ein Mensch, der den Kontext kennt, genau, von wem die Rede ist.
Deshalb bleibt die menschliche Prüfung auf Stichprobe Pflicht: 5 bis 10 % des Korpus zu Beginn, reduzierbar auf 1-2 % nach Stabilisierung. Und deshalb kombinieren wir NER systematisch mit einer kontextuellen Umformulierungsrichtlinie auf Hochrisikofällen: wir ersetzen nicht nur Namen, wir neutralisieren auch singuläre Kontexte.
Die drei technischen Ansätze (in Klartext)
Ansatz 1 — Generisches LLM mit Anweisung
Man gibt dem LLM eine Anweisung wie: „identifiziere in diesem Text alle benannten Entitäten und gib sie strukturiert mit Typ und Position zurück”. Moderne Modelle (Mistral Large, Aleph Alpha Luminous, GPT-4o, Claude) leisten das auf Standarddeutsch sehr gut.
| Vorteile | Grenzen |
|---|---|
| Hohe Genauigkeit (95-98 % auf Standarddeutsch) | Nicht triviale Inferenzkosten bei Volumen |
| Kontextverständnis (nützlich bei Mehrdeutigkeit) | Latenz (einige Sekunden pro Dokument) |
| Flexibel: Taxonomie über Prompt anpassbar | Anbieterabhängigkeit beim LLM |
| Keine technische Lernkurve | Möglicher Datenabfluss zu ausländischem Anbieter bei SaaS |
Wann das die richtige Wahl ist: Prototypen, niedrige bis mittlere Volumina (bis einige Zehntausend Dokumente pro Monat), evolutive Taxonomie, Team ohne NLP-Expertise.
Ansatz 2 — Spezialisiertes NER-Modell (Open Source)
Vortrainiertes Spezialmodell: spaCy de_core_news_lg, German BERT NER (Deepset), GLiNER, Microsoft Presidio. Läuft lokal, sehr schnell, niedrige Kosten.
| Vorteile | Grenzen |
|---|---|
| Sehr schnell (Millisekunden pro Dokument) | Standardmäßig starre Taxonomie |
| Wirtschaftlich bei Volumen | Performance je nach Domäne variabel |
| On-premise einsetzbar, null Datenabfluss | Technischeres Setup (Python, Modellpaketierung) |
| Reif (spaCy seit 2015 in Produktion) | Schwaches Kontextverständnis |
Wann das die richtige Wahl ist: hohe Volumina (Krankenkassen, Bankunterlagen), kritische Latenz, maximale Souveränitätsanforderung, kontrolliertes Inferenzbudget.
Ansatz 3 — Hybrid
Spezialisiertes Modell für die schnelle Erkennung im Hauptfluss + generisches LLM für komplexe oder mehrdeutige Fälle + menschliche Prüfung kritischer Fälle.
| Vorteile | Grenzen |
|---|---|
| Optimum Kosten / Genauigkeit bei großen Volumina | Komplexere Architektur |
| Robust auf atypische Fälle | Erfordert Orchestrator (LangChain, Custom-Code) |
| Souveränitätskompatibel | Verlangt Metrik-Tracking (LLM-Fallback-Rate) |
Wann das die richtige Wahl ist: stabilisierter Produktionsbetrieb, hohe Volumina, hohe Qualitätsanforderung, fähiges Pipeline-Operations-Team.
Schnelle Entscheidungsmatrix
Monatliches Volumen?
│
├── < 10.000 Dokumente
│ └── Latenz kritisch (Echtzeit)?
│ ├── Ja → Spezialisiertes NER (spaCy)
│ └── Nein → Generisches LLM
│
├── 10.000 – 1 Million
│ └── Maximale Sensibilität (Krankenkasse, Kanzlei)?
│ ├── Ja → Hybrid auf souveräner Stack
│ └── Nein → Souveränes generisches LLM (Mistral, Aleph Alpha)
│
└── > 1 Million
└── Hybrid zwingend (Inferenzökonomie + Qualität)Use Cases, die halten
Kein erschöpfender Katalog. Sechs belastbare Fälle, mit dem, was vor dem Start zu wissen ist.
Fall 1 — Korpus für internes Fine-Tuning vorbereiten
Kontext: ein deutsches Unternehmen will einen Open-Source-LLM (Llama, Mistral) auf seinen Kontext anpassen. Es verfügt über einen Korpus interner Protokolle, Mailverkehr, Dokumentation. Ohne Pseudonymisierung können diese Daten in die Gewichte des finalen Modells gelangen und durch einen sogenannten Membership-Inference-Angriff („war dieses Dokument im Trainingskorpus?”) wieder auftauchen.
Typisches Volumen: 10.000 bis 500.000 Dokumente.
Was schiefgehen kann: unvollständige Pseudonymisierung interner Referenzen (Aktenzeichen, Projektcodes) — diese Referenzen werden vom NER nicht erkannt, ermöglichen aber interne Verknüpfungen.
Erfolgsmetrik: Re-Identifikationsrate < 1 % auf einer manuellen Stichprobe nach Pseudonymisierung.
Fall 2 — Teilen mit akademischem Partner oder Berater
Kontext: eine deutsche Kanzlei will einen Vertragskorpus mit einem Lehrstuhl für statistische Analyse teilen. Ein Krankenkassen-Akteur will Pflegeprotokolle mit einem Datenberater für ein Qualitätsaudit teilen.
Typisches Volumen: einige Tausend Dokumente.
Was schiefgehen kann: Unterschätzung indirekt identifizierender Daten. Ein auf Parteinamen anonymisierter Vertrag kann durch Aktenzeichen, zuständiges Gericht, Eintragungsdatum identifizierbar bleiben.
Schutz: AVV mit dem Partner, begrenzte Aufbewahrung, nachweisbare Vernichtung, prüfbare Auditierung. Pseudonymisierung allein ersetzt nicht den Vertrag — und bei Krankenkassendaten ist die ärztliche Schweigepflicht (§ 203 StGB) nicht verhandelbar.
Fall 3 — Auskunftsersuchen nach Art. 15 DSGVO beantworten
Kontext: eine Person verlangt Zugang zu ihren personenbezogenen Daten. Sie hat das Recht, sie zu erhalten — aber nicht nebenbei die Daten anderer Personen, die in denselben Dokumenten stehen (Mails, Protokolle). NER + Schwärzung Dritter macht die Antwort konform. Die Aufsichtsbehörden (z.B. BayLDA, LfDI BW) verhängen regelmäßig Bußgelder bei schlecht geschwärzten Auskünften.
Typisches Volumen: variabel, manchmal eine Handvoll Dokumente, manchmal mehrere Hundert.
Was schiefgehen kann: Über-Pseudonymisierung, die das Dokument unverständlich macht und den Antragsteller daran hindert, seine eigenen Daten zu verstehen.
Schutz: klare Richtlinie für das, was geschwärzt und was behalten wird, Validierung durch DSB oder Rechtsabteilung vor Versand.
Fall 4 — Internen Korpus analysieren ohne unzulässige Beschäftigtenüberwachung
Kontext: eine Geschäftsleitung will wiederkehrende Themen in internen Austauschen (Mails, Kundensupport) verstehen, ohne die Linie der unzulässigen Individualüberwachung nach BDSG § 26 zu überschreiten. Pseudonymisierung von Absendern und Empfängern erlaubt eine aggregierte Analyse — aber Mitbestimmung des Betriebsrats nach BetrVG § 87 ist Pflicht.
Typisches Volumen: 10.000 bis 1 Million Nachrichten pro Monat.
Was schiefgehen kann: Pseudonymisierung reicht nicht, wenn die Analyse indirekt individuelles Verhalten enthüllt (atypisches Sendevolumen, einzigartige Zeitmuster). Aggregation vor der Analyse ist erforderlich.
Schutz: vorherige Information und Beteiligung des Betriebsrats, dokumentierte DSFA, begrenzter Zweck, eingeschränkter Zugriff auf Ergebnisse.
Fall 5 — Sektorale Compliance (Krankenkassen, ärztliche Schweigepflicht, Banken)
Kontext: ein Krankenkassen-Akteur will einen externen LLM zur Analyse von Befundberichten nutzen. Ist die Patientennummer für die Analyse nicht erforderlich, erlaubt die Pseudonymisierung im Vorfeld den Versand des Inhalts an einen weniger eingeschränkten LLM (Mistral Le Chat Enterprise) statt eine vollständige BSI-C5-konforme Infrastruktur zu erfordern. § 203 StGB (ärztliche Schweigepflicht) gilt aber weiter — die Pseudonymisierung entbindet die Organisation nicht von Zweck-, Erforderlichkeits- und Datenminimierungsdokumentation. Siehe unseren Leitfaden DSGVO-konforme KI.
Schutz: AVV mit dem LLM-Anbieter, DSFA zwingend, Nachvollziehbarkeit jedes Versands, Aufbewahrung der Originalversion in BSI-C5-konformer Umgebung.
Fall 6 — Rechnungsbearbeitung und Finanzflüsse
Kontext: sensitive Rechnungen (Lieferantenrechnungen mit Gehaltsdaten, Pflegerechnungen in PKV), detaillierte Spesenabrechnungen. Pseudonymisierung von Patienten- oder Mitarbeiterdaten vor der Verarbeitung durch einen SaaS-LLM zur strukturierten Extraktion. Siehe unseren Leitfaden KI-Rechnungsautomatisierung.
Typisches Volumen: 10.000 bis 500.000 Dokumente pro Monat je nach Größe der Organisation.
Referenzarchitektur: was wir konkret aufbauen
Eine produktive KI-Anonymisierungs-Pipeline gliedert sich in sieben Phasen. Jede hat ihre Fallstricke.
Phase 1 — Ingestion. Das Dokument kommt im Rohformat: PDF, Word, Mail, Datenbankexport, gescanntes Bild. Bei nicht-textlichen Dokumenten vorgeschaltete OCR (Tesseract, AWS Textract in Region Frankfurt, Doctly). In dieser Phase wird das Original verschlüsselt für Audit aufbewahrt.
Phase 2 — NER-Erkennung. LLM oder Spezialmodell identifiziert die Entitäten. Ausgabe: strukturierte Liste {Typ, Wert, Start_Offset, End_Offset}. Bei langen Dokumenten Chunking in Blöcke einiger Tausend Zeichen mit Überlappung; sonst übersehen die Modelle Entitäten an Block-Grenzen.
Phase 3 — Ersetzungsrichtlinie. Geschäftsentscheidung, nicht technisch:
- Zu löschende Kategorien (saubere Entfernung, z.B. Kreditkartennummern in Mails)
- Zu pseudonymisierende Kategorien (Ersatz durch stabilen pseudonymen Identifikator, z.B. Personennamen)
- Zu erhaltende Kategorien (für nachgelagerte Nutzung sinnvoll, z.B. Daten für Zeitreihenanalyse)
Phase 4 — Pseudonymgenerierung. Maria Schmidt → Person_001. Das Pseudonym muss stabil sein (dieselbe Person erhält in allen Dokumenten dasselbe Pseudonym) und unkorreliert zum Originalwert (kein Hash des Werts — ein Hash ist über Wörterbuchangriff angreifbar, wenn die Domäne klein ist). Die Korrespondenztabelle wird in einem separaten Tresor aufbewahrt.
Phase 5 — Anwendung auf Text. Effektive Ersetzung. Achtung auf Wortgrenzen, Groß-/Kleinschreibung, Umlaute, Schreibvarianten. Ein Maria Schmidt kann später als Frau Schmidt, M. Schmidt, Schmidt auftauchen — der NER muss diese Formen verbinden (sogenannte Coreference Resolution).
Phase 6 — Validierung. Menschliche Prüfung auf Stichprobe (5 bis 10 % zu Beginn, reduzierbar auf 1-2 % nach Stabilisierung). Wir messen:
- Übersehene Entitäten (Recall)
- Falsche Treffer (Precision)
- Vorhandensein indirekt identifizierender Restdaten
Phase 7 — Audit und Logs. Getrennte Aufbewahrung:
- Verschlüsseltes Originaldokument (bei Streit, Auskunftsersuchen, Audit)
- Pseudonymisiertes Dokument (für nachgelagerte Nutzung)
- Korrespondenztabelle (Tresor, sehr eingeschränkter Zugriff)
- Zugriffslogs (wer hat was, wann gesehen)
Vereinfachtes Produktionsschema
[Quelle] [Verarbeitung] [Ziele]
│ │ │
▼ ▼ ▼
PDF / Mail ──► OCR ──► NER ──► Policy ──► Pseudo. ──► SaaS LLM / Fine-Tune / Teilen
│ │
└─► Audit ──┘
│
▼
Schlüssel-Tresor (strenger Zugriff)
Verschlüsseltes Original (BSI C5 wenn KK)Die Re-Identifikations-Falle
Das ist der ultimative Test. Pseudonymisierung, die Verknüpfungsangriffen nicht standhält, ist keine nutzbare Pseudonymisierung — und die Aufsichtsbehörde wird das bei einer Prüfung sagen.
Drei klassische Angriffe
Angriff 1 — Verknüpfung mit offener Quelle. Der Angreifer verfügt über das Handelsregister, Bundesanzeiger, einen LinkedIn-Export. Er kreuzt die im pseudonymisierten Dokument verbliebenen Attribute (Alter, Stadt, Beruf, Arbeitgeber) mit diesen Quellen. Ist eine Kombination eindeutig, gelingt die Re-Identifikation. Die berühmte Sweeney-Studie (1997) zeigte, dass 87 % der US-Personen über PLZ + Geburtsdatum + Geschlecht eindeutig identifizierbar sind — deutsche PLZ ergeben ähnliche Ergebnisse.
Angriff 2 — Inferenz durch Kontext. Der Angreifer kennt die Domäne. Er weiß, dass nur ein Vertriebsleiter ACME GmbH im März 2025 verlassen hat. Er folgert die Identität.
Angriff 3 — Membership Inference (auf fein abgestimmtem LLM). Ein Angreifer befragt ein auf einem pseudonymisierten Korpus fein abgestimmtes Modell, um zu erraten, ob eine bestimmte Person im Korpus war. Hat das Modell überangepasst, leakt es Informationen. Die Carlini-et-al.-Arbeit (2023) zu Extraktionsangriffen auf GPT-2 hat das Thema in die Vorstandsetagen gebracht.
Drei Verteidigungen
Verteidigung 1 — k-Anonymität (für tabellarische Datenbanken). Jede Attributkombination erscheint mindestens k-mal im Dataset. Bei k = 5 ist jedes Profil von mindestens 4 anderen ununterscheidbar. Auf Freitext partielle Übertragung durch Generalisierung: „47 Jahre” → „40-50 Jahre”, „Agraringenieurin in Garmisch” → „Fachkraft in Süddeutschland”.
Verteidigung 2 — l-Diversität und t-Closeness. Erweiterungen der k-Anonymität, die auch die Diversität sensitiver Werte in jeder Gruppe einschränken. Nützlich, wenn sensitive Daten (Gesundheit, Meinung) Kern des Datasets sind.
Verteidigung 3 — Re-Identifikationstests. Pragmatischer: aktiv versuchen, auf einer Stichprobe zu re-identifizieren. Gelingt das zu leicht, ist die Pseudonymisierung unzureichend. Diese Praxis wird vom BfDI für sensitive Projekte erwartet.
Keine der drei schützt vollständig. Die Praxisregel: explizit testen vor Inbetriebnahme und die Tests dokumentieren.
DSGVO-Compliance: was wirklich erwartet wird
Die KI-Anonymisierung/-Pseudonymisierung ist selbst eine automatisierte Verarbeitung personenbezogener Daten. Also DSGVO-pflichtig. Hier ist, was zu erfassen und im Prüfungsfall vorzulegen ist.
Im Verzeichnis der Verarbeitungstätigkeiten (Art. 30 DSGVO)
Ein dedizierter Eintrag: „automatisierte Pseudonymisierung durch NER für [konkreten Zweck]”. Erfasst werden:
- Zweck (z.B. Korpus für Fine-Tuning vorbereiten, mit Partner X teilen, interne Mails analysieren)
- Verarbeitete Datenkategorien (Freitext, Typen erkannter Entitäten)
- Betroffene Personen (Kunden, Mitarbeiter, Versicherte je nach Fall)
- Aufbewahrungsdauer (Original, pseudonymisierte Version, Korrespondenztabelle — jeweils begründet)
- Auftragsverarbeiter (LLM-Anbieter, Hosting)
- Technische und organisatorische Maßnahmen (TOM)
Rechtsgrundlage
Je nach Kontext:
- Berechtigtes Interesse (Art. 6 Abs. 1 lit. f DSGVO): häufigster Fall für interne Verarbeitungen, unter Bedingung der dokumentierten Interessenabwägung (Zweck vs. Betroffenenrechte).
- Vertragserfüllung: wenn die Verarbeitung direkt aus der Vertragserfüllung mit der Person folgt.
- Rechtliche Verpflichtung: selten, aber möglich (Antwort auf Auskunftsersuchen z.B.).
- Einwilligung: ausnahmsweise, und zu vermeiden, wenn eine andere Grundlage greift — die Einwilligung kann widerrufen werden.
DSFA (Datenschutz-Folgenabschätzung)
In den meisten Fällen empfohlen, zwingend in mehreren vom BfDI gelisteten Szenarien:
- Hohe Volumina
- Sensitive Daten (Gesundheit, politische Meinungen, Biometrie, Strafregisterdaten)
- Verarbeitung in großem Umfang
- Systematische Mitarbeiterüberwachung
- Quellenverknüpfung
Die DSFA dokumentiert das Restrisiko nach Pseudonymisierung, begründet die technischen Entscheidungen und formalisiert die Zugriffskontrolle auf den Schlüssel. Sie wird der Aufsichtsbehörde im Prüfungsfall vorgelegt. Siehe unseren DSFA-Leitfaden für KI-Projekte.
AVV mit dem LLM-Anbieter
Bei Nutzung eines SaaS-LLM muss der Auftragsverarbeitungsvertrag (AVV) regeln:
- Verarbeitungsort (idealerweise EU — Mistral, Scaleway, IONOS, T-Systems)
- Verbot der Datennutzung zum Modelltraining
- Aufbewahrungsdauer von Prompts und Ausgaben
- Unterauftragsverarbeiter (Hoster, Backups)
- Modalitäten der Vorfallmeldung
Mit einem souveränen europäischen Anbieter ist der AVV deutlich einfacher. Mit einem US-Anbieter wird er zu einer eigenständigen technischen Akte (Standardvertragsklauseln, Transfer Impact Assessment nach Schrems II, manchmal unbrauchbar je nach Datenart — besonders bei Krankenkassendaten oder Bankdaten unter KWG).
Verarbeitungsort
Für sensitive Daten (Krankenkassen, ärztliche Schweigepflicht, Bankdaten unter KWG, Gehaltsdaten) ist der Ort ein eigenes Thema. Drei Niveaus:
- Souveräne Cloud (Scaleway, OVHcloud Frankfurt, IONOS Cloud, T-Systems Open Telekom Cloud, plusserver) — Daten bleiben in der EU, unter europäischem Recht, ohne Risiko der Beschlagnahme nach US Cloud Act.
- On-premise — die KI läuft auf den Servern der Organisation, null Datenabfluss. Siehe unseren Leitfaden lokales LLM im Unternehmen.
- Ausländische Cloud mit vertraglichem Rahmen — möglich, aber mit erheblicher Dokumentationslast und nicht-null Restrisiko. Das EU-US Data Privacy Framework hilft bei einigen Flüssen, deckt aber nicht alle Use Cases ab.
Für die meisten sensitiven Fälle in Deutschland behalten wir entweder einen souveränen Anbieter (Mistral La Plateforme, Aleph Alpha, IONOS) oder On-Premise. Das ist der Ansatz, den DPLIANCE für seine Kunden im Rahmen maßgeschneiderter KI-Lösungen verfolgt.
Was wir nicht versprechen wollen
Drei Antipattern, die wir regelmäßig in Projekten sehen und bei DPLIANCE vermeiden.
„Wir anonymisieren, also sind wir aus der DSGVO heraus.” Nein, außer in sehr Ausnahmefällen. Pseudonymisierung bleibt unter DSGVO. Wenn das Verlassen der DSGVO für das Projekt notwendig ist, muss das Projekt neu konzipiert werden — nicht der Sinn der Wörter verbogen. Das BfDI-Positionspapier ist hier explizit.
„Der NER erkennt alles, wir brauchen keine menschliche Prüfung.” Kein NER erkennt singuläre Kontexte, seltene Kombinationen, implizite Referenzen. Menschliche Prüfung auf Stichprobe ist zu Beginn nicht verhandelbar und bleibt im stabilen Betrieb empfohlen.
„Wir behalten den Re-Identifikationsschlüssel, schließen ihn aber gut weg.” Ist der Schlüssel mehreren Personen zugänglich, wird die Pseudonymisierung theoretisch. Die DSGVO-Praxis erwartet einen sehr eingeschränkten, protokollierten Zugriff mit ausnahmsweisem und nachvollziehbarem Wiederherstellungsprozess.
FAQ
Was ist der konkrete Unterschied zwischen Anonymisierung und Pseudonymisierung nach DSGVO?
Anonymisierung ist irreversibel: Die betroffene Person kann nicht mehr identifiziert werden — auch nicht durch Verknüpfung mit anderen Quellen, auch nicht mit einem Schlüssel. Die Daten fallen aus dem Anwendungsbereich der DSGVO und des BDSG heraus (Erwägungsgrund 26). Pseudonymisierung nach Art. 4 Nr. 5 DSGVO ist reversibel: Ein Pseudonym ersetzt direkte Identifikatoren, aber ein Re-Identifikationsschlüssel existiert getrennt unter strenger Zugangskontrolle. Die Daten bleiben personenbezogen im Sinne der DSGVO. Praktische Folge: Die Mehrheit der sogenannten „KI-Anonymisierungs”-Projekte erzeugt in Wirklichkeit eine Pseudonymisierung. Die DSGVO-Pflichten gelten weiter (Verarbeitungsverzeichnis, Rechtsgrundlage, DSFA bei Bedarf), auch wenn das Risiko gesenkt wurde.
Reicht NER (Named Entity Recognition) aus, um einen Text zu anonymisieren?
Nein, fast nie. NER erkennt explizite benannte Entitäten: Vor- und Nachnamen, Telefonnummern, Adressen, IBAN, Steuer-ID, Krankenversicherungsnummer, Daten. Es übersieht systematisch indirekt identifizierende Daten: präzise Beschreibungen („der Vertriebsleiter, der ACME GmbH im März 2025 verlassen hat”), seltene Kombinationen (Alter + Stadt + Beruf), interne Referenzen (Aktenzeichen, das mit einem Mandanten korreliert), kontextuelle Formulierungen. Eine rigorose Anonymisierung erfordert NER + Kontextanalyse + menschliche Prüfung kritischer Fälle + Re-Identifikationstests — genau das, was BfDI und Landesdatenschutzbeauftragte erwarten.
Welche Genauigkeit ist von einem KI-NER 2026 auf Deutsch zu erwarten?
Auf Standarddeutsch erkennt ein modernes LLM (Mistral Large, GPT-4o, Claude, Aleph Alpha) 95 bis 98 % der expliziten benannten Entitäten mit einem gut konstruierten Prompt. Spezialmodelle (spaCy de_core_news_lg, German BERT NER von Deepset, GLiNER multilingual) erreichen je nach Domäne 92 bis 99 % F1. Die Performance bricht stark ein bei: ausländischen oder seltenen Namen, gemischten Sprachen (Türkisch, Russisch in deutschen Kontexten), Branchenabkürzungen, impliziten Referenzen im Text. Kein Modell erreicht 100 % — deshalb bleibt die menschliche Stichprobenprüfung zu Beginn unverzichtbar.
Generisches LLM oder spezialisiertes NER-Modell?
Für die meisten Anwendungsfälle 2026 reicht ein gut geprompteter generischer LLM (Mistral, Aleph Alpha Luminous, GPT-4o, Claude) mit Genauigkeit über 95 %. Ein spezialisiertes NER-Modell (spaCy de_core_news_lg, German BERT NER, fein abgestimmtes Modell) wird relevant, wenn das Volumen sehr hoch ist (Millionen Dokumente pro Monat), die Latenz kritisch ist (Echtzeit-Triage bei Krankenkassen oder Banken) oder der Kontext hochspezialisiert ist (medizinische Terminologie, juristische Terminologie). Einfache Regel: mit generischem LLM für den Prototyp starten, auf spezialisiertes Modell umsteigen, wenn Kosten oder Performance es rechtfertigen.
Bleiben durch NER pseudonymisierte Daten weiterhin der DSGVO unterworfen?
Ja. Die DSGVO sieht Daten als personenbezogen an, solange eine Re-Identifikation möglich ist — direkt, indirekt, durch Verknüpfung mit anderen Quellen oder über den Pseudonymisierungsschlüssel. Pseudonymisierung reduziert das Risiko, lässt die Daten aber nicht aus dem Anwendungsbereich der DSGVO heraus. Für eine echte Anonymisierung im Sinne der DSGVO muss der Schlüssel zerstört, indirekt identifizierende Daten entfernt und die Resilienz gegen Verknüpfungsangriffe getestet werden. Das ist technisch sehr schwierig — der BfDI ist hier in seinen Positionspapieren explizit.
Welche Use Cases halten in deutschen Unternehmen wirklich?
Sechs belastbare Fälle: (1) Korpusvorbereitung für das Fine-Tuning eines internen Modells ohne Leak-Risiko; (2) Datenteilung mit einem Berater oder akademischen Partner unter Auftragsverarbeitungsvertrag (AVV); (3) Beantwortung eines Auskunftsersuchens nach Art. 15 DSGVO ohne Drittpersonendaten preiszugeben; (4) Analyse interner Korpora (Mails, Protokolle) für Management-Zwecke ohne unzulässige Beschäftigtenüberwachung nach BDSG § 26 und Mitbestimmung des Betriebsrats nach BetrVG; (5) Sektorale Compliance (Krankenkassen, ärztliche Schweigepflicht nach § 203 StGB, Banken nach KWG); (6) Dokumentenvorbereitung vor Aufruf eines SaaS-LLM zur Reduktion der Exposition.
Welche Tools ermöglichen souveräne KI-Anonymisierung 2026?
Souveräne generische LLMs: Mistral Large über La Plateforme (Frankreich), Aleph Alpha Luminous (Heidelberg), Mistral on-premise via vLLM, deutsche Hosting-Anbieter (IONOS Cloud, T-Systems Open Telekom Cloud, plusserver). Open-Source-Spezialmodelle: spaCy de_core_news_lg (hervorragendes Preis-Leistungs-Verhältnis für Deutsch), German BERT NER von Deepset, GLiNER multilingual. Microsoft Presidio ist ein exzellentes Open-Source-Framework, aber die Standard-Inferenz läuft über OpenAI — auf souveränen Anbieter oder lokal umzuleiten. Für maximale Souveränität: Mistral on-prem oder Llama 3 selbst gehostet + spaCy intern, null Datenabfluss.
Ist eine DSFA für ein KI-Anonymisierungsprojekt erforderlich?
In den meisten Fällen empfohlen, in mehreren Szenarien zwingend: hohe Volumina, sensitive Daten (Gesundheit, Meinungen, Biometrie nach Art. 9 DSGVO), Verarbeitung in großem Umfang, systematische Mitarbeiterüberwachung, Quellenverknüpfung. Logik: Die KI-Anonymisierung ist selbst eine automatisierte Verarbeitung personenbezogener Daten, also DSGVO-pflichtig. Die DSFA dokumentiert das Restrisiko nach Pseudonymisierung, begründet die technischen Entscheidungen und formalisiert die Zugriffskontrolle auf den Re-Identifikationsschlüssel. Die Liste der DSFA-pflichtigen Verarbeitungen wird vom BfDI und den Landesdatenschutzbehörden geführt.
Quellen: Verordnung (EU) 2016/679 (DSGVO), insbesondere Art. 4 Nr. 5 und Erwägungsgrund 26; BDSG; BfDI-Positionspapier zur Anonymisierung (2020); EDSA-Stellungnahme 28/2024 zu Datenschutzaspekten von KI-Modellen; § 203 StGB (ärztliche Schweigepflicht); BetrVG § 87 (Mitbestimmung); offizielle Dokumentation für spaCy, Microsoft Presidio, GLiNER, German BERT NER (Deepset); Mistral AI La Plateforme; Aleph Alpha Luminous.
Um ein KI-Anonymisierungsprojekt in Ihrer Organisation zu rahmen — Toolwahl, Methodik, Pipeline, Compliance — siehe unseren Leitfaden DSGVO-konforme KI, unseren DSFA-Leitfaden für KI-Projekte, unseren Leitfaden lokales LLM im Unternehmen, oder kontaktieren Sie uns über unsere maßgeschneiderten KI-Lösungen.