Personenbezogene Daten und LLMs: Wie gut funktioniert automatische Anonymisierung wirklich?

Ein praktischer Test der Standard-NER-Bibliotheken für deutsche Geschäftstexte

Andre Jahn, Jahn Consulting - März 2026

Das Problem

Wer ein Large Language Model wie Claude oder GPT mit Unternehmensdaten nutzen will, steht vor einer grundsätzlichen Frage: Was passiert mit den personenbezogenen Daten im Text?

Die DSGVO verlangt eine Rechtsgrundlage für jede Verarbeitung personenbezogener Daten. Sobald ein Dokument mit Namen, Adressen oder identifizierbaren Personenbezügen an ein LLM übergeben wird, findet Verarbeitung statt - unabhängig davon, ob das Modell in der Cloud oder lokal läuft.

Theoretisch gibt es mehrere Wege, diese Verarbeitung zu legitimieren. In der Praxis scheitern die meisten davon an der Realität des Unternehmensalltags.

Warum Einwilligung selten funktioniert

Der naheliegende Ansatz - die betroffenen Personen fragen - klingt einfach, ist aber in den häufigsten Szenarien problematisch.

Bei Mitarbeiterdaten ist Einwilligung kaum belastbar. Die DSGVO und die deutschen Aufsichtsbehörden sehen das Machtgefälle zwischen Arbeitgeber und Arbeitnehmer als grundsätzliches Problem. Eine Einwilligung, die im Kontext eines Arbeitsverhältnisses gegeben wird, gilt als nicht wirklich freiwillig - und damit als anfechtbar. "Stimmst du zu, dass wir deine Personalakte durch ein LLM verarbeiten?" ist keine Frage, bei der ein Mitarbeiter frei entscheidet.

Bei Kundendaten ist Einwilligung theoretisch machbar, aber operativ aufwendig. Sie muss spezifisch, informiert und freiwillig sein. Das bedeutet: Sie müssen dem Kunden erklären, was ein LLM mit seinen Daten macht - und das ist bei einem probabilistischen Sprachmodell konzeptionell schwierig. Hinzu kommt: Einwilligung ist jederzeit widerrufbar, und dann muss die Verarbeitung sofort eingestellt werden können.

Und selbst mit Einwilligung greift Art. 5(1)(c) DSGVO - das Prinzip der Datenminimierung. Auch wenn die Rechtsgrundlage steht, dürfen nur die Daten verarbeitet werden, die für den konkreten Zweck notwendig sind. Einen ganzen Aktentext ins LLM zu schieben, wenn nur eine Zusammenfassung gebraucht wird, ist mindestens argumentativ angreifbar.

Bleibt als pragmatischster Weg für die meisten Enterprise-Szenarien: Personenbezogene Daten vor dem LLM-Aufruf anonymisieren, das LLM mit bereinigten Daten arbeiten lassen, und im Output die Originaldaten wieder einsetzen.

Der technische Ansatz: Anonymisieren und De-Anonymisieren

Die Architektur einer solchen Pipeline sieht konzeptionell einfach aus:

Originaltext → PII-Erkennung → Anonymisierung → LLM-Verarbeitung → De-Anonymisierung → Output

Im Kern steht die automatische Erkennung personenbezogener Daten - sogenannte Named Entity Recognition (NER). Spezialisierte Modelle analysieren den Text und markieren Entitäten wie Personennamen, Orte, Organisationen und andere identifizierbare Informationen.

Das bekannteste Framework für diesen Zweck ist Microsoft Presidio - ein Open-Source-Tool, das Erkennung und Anonymisierung kombiniert und auch einen De-Anonymisierungspfad bietet. Unter der Haube nutzt Presidio NER-Modelle für die eigentliche Erkennung. Das Standard-Backend ist spaCy, die am weitesten verbreitete NLP-Bibliothek für Produktionsumgebungen. Eine Alternative ist Flair, ein Framework von Zalando Research, das auf kontextuelle Embeddings setzt und in Benchmarks oft höhere Genauigkeit bei der Entitätserkennung erreicht.

Die entscheidende Frage ist: Wie gut funktionieren diese Modelle bei deutschen Geschäftstexten?

Der Test

Um das herauszufinden, habe ich beide Modelle mit demselben Eingabetext getestet - einem Satz, wie er täglich in deutschen Unternehmen entsteht:

"Max Müller aus Berlin hat am 15. Januar bei der Deutschen Bank angerufen und mit Frau Krause über die Erweiterung der Kreditlinie gesprochen."

Dazu Variationen, die typische Muster in Geschäftskorrespondenz abbilden: Anrede plus Nachname ("Frau Weise", "Herrn Dr. Schmidt"), abgekürzte Anreden ("Fr. Krause"), seltene Nachnamen ("Frau Waise"), und eine kontextuelle Personenreferenz ohne Named Entity ("Der Kollege aus der Buchhaltung, der letzten Monat den Vorfall hatte").

Getestete Modelle

  • spaCy mit dem Modell de_core_news_lg - das größte nicht-Transformer-basierte deutsche Modell, trainiert auf Nachrichtentexten
  • Flair mit dem Modell ner-german-large - ein Transformer-basiertes Modell (XLM-RoBERTa), trainiert auf dem CoNLL-2003-Datensatz

Ergebnisse

Testfall spaCy Flair
"Max Müller" ✓ PER ✓ PER
"Frau Krause" ✗ nicht erkannt ✓ PER
"Frau Waise" ✗ nicht erkannt ✓ PER
"Frau Weise" ✗ nicht erkannt ✓ PER
"Herrn Dr. Schmidt" ✗ nicht erkannt ✓ PER
"Fr. Krause / Heinrich&Co" ✗ als eine Entity ✓ PER + ORG (getrennt)
"Anja Krause" ✓ PER ✓ PER
"Kollege aus Buchhaltung" ✗ nicht erkannt ✗ nicht erkannt

Analyse der Ergebnisse

spaCy: Vorname als Trigger

spaCy erkennt "Max Müller" und "Anja Krause" - klassische Vorname-plus-Nachname-Muster. Aber jede Variante mit Anrede statt Vorname wird übersehen: "Frau Krause", "Frau Weise", "Frau Waise", "Herrn Dr. Schmidt" - kein einziger Treffer. Der häufigste Namenspattern in deutschen Geschäftstexten wird komplett ignoriert.

Besonders problematisch ist der Fall "Fr. Krause von Heinrich&Co". spaCy erkennt "Fr. Krause von Heinrich&Co" als eine einzige Person-Entity. Die Firma verschwindet als eigenständige Organisation. Wenn man diesen Text anonymisiert, wird die gesamte Zeichenkette durch ein einziges Pseudonym ersetzt - die Firmenreferenz geht verloren, der anonymisierte Text wird unbrauchbar.

Die Ursache ist nachvollziehbar: Das Modell de_core_news_lg ist auf Nachrichtentexte trainiert. In Zeitungsartikeln steht "Angela Merkel" oder "Bundeskanzler Scholz" - nicht "Frau Merkel" oder "Herrn Dr. Schmidt". Das Modell hat das Pattern Anrede-plus-Nachname schlicht nicht ausreichend gelernt.

Flair: Deutlich besser, aber nicht perfekt

Flair erkennt alle Anrede-Patterns. "Frau Krause", "Frau Waise", "Herrn Dr. Schmidt" - alles korrekt identifiziert, alle mit Confidence-Score 1.0. Bei "Fr. Krause von Heinrich&Co" trennt Flair sauber: "Krause" als PER, "Heinrich&Co" als ORG.

Ein Detail verdient Aufmerksamkeit: Flair gibt nur den Nachnamen als Entity zurück, nicht die Anrede. "Frau Krause" wird zu Entity "Krause". Für die Anonymisierung bedeutet das, dass die Ersetzungslogik den Kontext berücksichtigen muss - ein naives Suchen-und-Ersetzen von "Krause" könnte auch "Krausestraße" treffen. Positionsbasiertes Ersetzen anhand der von Flair gelieferten Start- und End-Indizes ist zwingend.

Der Tradeoff: Flair ist deutlich langsamer als spaCy. In Benchmarks braucht spaCy für denselben Datensatz drei Minuten, Flair über 100. Für Batch-Verarbeitung großer Dokumentenbestände ist das relevant.

Die harte Grenze: Kontextuelle Personenbezüge

"Der Kollege aus der Buchhaltung, der letzten Monat den Vorfall hatte" - bei beiden Modellen: leer. Keine Entity erkannt.

Das ist kein Fehler. Es gibt hier keine Named Entity. Kein Name, kein Ort, keine Organisation. Trotzdem ist der Satz im Unternehmenskontext potenziell personenbezogen - wenn die Buchhaltung nur drei Mitarbeiter hat und einer davon letzten Monat einen Vorfall hatte, ist die Person identifizierbar.

Diese Art von kontextuellem Personenbezug erkennt nur, wer den Satz versteht - also ein Sprachmodell. Und damit steht man vor dem Henne-Ei-Problem: Um Daten vor der KI zu schützen, braucht man eine KI, die die Daten sieht.

Ein möglicher Architekturkompromiss ist ein schwächeres, lokales Modell als Vorfilter für semantische Erkennung, dessen Output dann an das eigentliche LLM geht. Datenschutzrechtlich wäre das Eigenverarbeitung. Ob europäische Open-Source-Modelle dafür leistungsfähig genug sind, ist eine offene Frage.

Implikationen für die Praxis

Die Modellwahl ist eine Architekturentscheidung

spaCy in der Standardkonfiguration ist für die Anonymisierung deutscher Geschäftstexte unzureichend. Das ist kein Urteil über die Qualität von spaCy als Framework - es ist eine Aussage über das trainierte Modell und seinen Trainingsdatensatz. Wer Presidio mit dem Default-Backend einsetzt und sich auf die Erkennungsrate verlässt, wiegt sich in falscher Sicherheit.

Flair als NER-Backend - insbesondere das ner-german-large-Modell - liefert für deutsche Texte deutlich bessere Ergebnisse. Presidio unterstützt Flair als alternatives Backend, der Wechsel erfordert keinen Umbau der Anonymisierungs-Pipeline.

Regelbasierte Ergänzung bleibt notwendig

Auch mit dem besseren Modell sollte die NER-basierte Erkennung durch regelbasierte Pattern ergänzt werden. E-Mail-Adressen, IBANs, Telefonnummern, Sozialversicherungsnummern - das sind strukturierte Daten, die deterministisch per Regex erkannt werden können, zuverlässiger als jedes Modell und auditierbar.

Die empfohlene Pipeline ist dreistufig:

  1. Stufe 1 - Regex-Pattern für strukturierte PII (deterministisch, auditierbar)
  2. Stufe 2 - NER-Modell (Flair ner-german-large) für Namen, Orte, Organisationen
  3. Stufe 3 - Dokumentiertes Restrisiko für kontextuelle Personenbezüge, die nur semantisch erkennbar sind

Das Restrisiko muss dokumentiert werden

Keine technische Lösung erreicht 100% Erkennung. Das ist keine Schwäche der Tools, sondern eine strukturelle Eigenschaft der Aufgabe. Kontextuelle Personenbezüge, indirekte Identifikation über Merkmalskombinationen (das Mosaik-Problem) und temporal gebundene Referenzen bleiben als Restrisiko.

Dieses Restrisiko ist dokumentierbar und im Rahmen einer Datenschutz-Folgenabschätzung (DSFA) bewertbar. Die Kombination aus technischen Maßnahmen (Regex + NER), organisatorischen Maßnahmen (Schulung, Prozesse) und dokumentiertem Restrisiko ist ein vertretbarer Ansatz für die meisten Unternehmensszenarien - und ehrlicher als die Behauptung, eine vollständige Lösung zu haben.

Reproduzierbarkeit

Die verwendeten Testskripte sind als GitHub Gist verfügbar. Die Ergebnisse lassen sich mit folgenden Paketen nachvollziehen:

pip install spacy flair
python -m spacy download de_core_news_lg

Das Flair-Modell ner-german-large wird beim ersten Aufruf automatisch heruntergeladen (ca. 1,5 GB).

Fazit

Eine DSGVO-konforme LLM-Pipeline für Unternehmensdaten ist technisch machbar. Die Werkzeuge existieren, das Architekturmuster ist klar. Aber die Standardkonfiguration reicht für deutsche Geschäftstexte nicht aus - weder bei der Modellwahl noch bei der Erwartung an die Erkennungsrate.

Wer diesen Weg geht, muss drei bewusste Entscheidungen treffen: Welches NER-Modell für die eigene Textdomäne geeignet ist. Welche zusätzlichen regelbasierten Filter die Erkennung ergänzen. Und welches Restrisiko akzeptabel und dokumentierbar ist.

Die ehrliche Antwort ist nicht "wir haben es gelöst", sondern "hier ist die Grenze dessen, was technisch sauber lösbar ist - und so gehen wir mit dem Rest um."

Spacy-Test Gist

Fler-Test Gist

---

Andre Jahn ist Solution Architect bei Jahn Consulting und berät Unternehmen zu KI-Governance und Enterprise AI-Architektur.