Pseudonymisieren vor der KI: Welche Ansätze es gibt – und was davon im Alltag trägt

Für das Pseudonymisieren von Dokumenten vor der KI-Nutzung haben sich fünf Klassen von Ansätzen etabliert: Regex/Mustererkennung mit Prüfsummen für strukturierte Daten wie IBAN und Steuer-ID, NER-Modelle (spaCy, Flair, GLiNER, Framework Presidio) für freie Namen im Fließtext, LLM-basierte Extraktion als flexible, aber nicht reproduzierbare Zweitmeinung, Cloud-SaaS-Dienste (die Ihre Originalangaben zwangsläufig erst zu sehen bekommen) und das lokale Ensemble, das Prüfsummen, deutsches NER-Modell, OCR und menschliche Sichtprüfung auf Ihrem eigenen Gerät kombiniert. Keiner ist per se „der beste“: In der Praxis gewinnt fast immer die Kombination, und für echte, sensible Immobilien- und Finanzdokumente das lokale Ensemble, weil die Originalangaben den Rechner nie verlassen und der EuGH (C-413/23 P vom 4. September 2025) den relativen Personenbezug bestätigt hat. Dieser Beitrag ordnet die Landschaft ein: was die Ansätze können, wo ihre Grenzen liegen und worauf Sie achten sollten, bevor Sie einem Werkzeug Ihre sensibelsten Unterlagen anvertrauen.

Die Versuchung ist groß. Ein Mietvertrag soll zusammengefasst, ein Behördenschreiben beantwortet, eine Selbstauskunft geprüft werden – und ein Sprachmodell erledigt genau das in Sekunden. Der Haken: In diesen Dokumenten stehen Namen, Anschriften, IBANs, Steuer-IDs, Geburtsdaten. Daten von Mietern, Mandanten, Kaufinteressenten. Sie gehören nicht ungefiltert in ein fremdes KI-System — und „irgendein Tool, das schwärzt“ ist selten die richtige Antwort.

Erst die Weiche: anonymisieren oder pseudonymisieren?

Anonymisieren entfernt den Personenbezug unumkehrbar und eignet sich für die Weitergabe nach außen; pseudonymisieren ersetzt Angaben durch konsistente Platzhalter mit lokal aufbewahrter Zuordnungstabelle — der richtige Weg, wenn eine KI mit dem Text arbeiten und ein Ergebnis mit echten Namen zurückkommen soll. Die DSGVO nimmt diese Weiche streng.

Anonymisieren bedeutet, den Personenbezug unumkehrbar zu entfernen. Der Name wird geschwärzt, die IBAN entfernt – und niemand, auch Sie selbst nicht, kann aus dem Ergebnis die Person rekonstruieren. Richtig anonymisierte Daten fallen aus der DSGVO heraus.

Pseudonymisieren ersetzt die identifizierenden Angaben durch konsistente Platzhalter – aus „Anna Müller“ wird durchgängig „Mieter_Gruppe1“ – und behält eine Zuordnungstabelle, mit der sich das später lokal wieder auflösen lässt. Wichtig, weil oft falsch verstanden: Pseudonymisierte Daten bleiben personenbezogene Daten im Sinne von Art. 4 Nr. 5 DSGVO. Sie sind besser geschützt, aber nicht „draußen“ aus dem Gesetz.

Die Aufsichtsbehörden (u. a. die Prüflogik des BfDI) empfehlen eine klare Reihenfolge: Erst prüfen, ob Anonymisierung genügt. Für einen reinen Serienbrief-Text mag das reichen. Sobald aber die Analyse Zusammenhänge braucht – „welche Zahlung gehört zu welchem Mieter“, „ist der Bürge derselbe wie der Käufer“ –, zerstört echtes Anonymisieren genau die Kohärenz, die Sie brauchen. Dann ist Pseudonymisieren mit späterer Rückführung der richtige Weg.

Merksatz: Schwärzen (Anonymisieren) für die Weitergabe nach außen. Pseudonymisieren, wenn eine KI mit dem Text arbeiten und ein brauchbares Ergebnis mit echten Namen zurückkommen soll.

Welche Ansätze gibt es?

Fünf Klassen haben sich etabliert — keine ist per se „die beste“, sie haben unterschiedliche Einsatzzwecke:

Ansatz	Stärke	Grenze
(a) Regex / Mustererkennung	Unschlagbar bei strukturierten Daten mit fester Form: IBAN, BIC, E-Mail, Steuer-ID, Kreditkartennummer. Mit Prüfsummen (IBAN mod-97, Luhn, Steuer-ID nach ISO 7064) sogar mit sehr wenig Fehlalarmen.	Erkennt keine freien Namen im Fließtext. „Herr Brandt kündigt zum …“ ist für Regex unsichtbar.
(b) NER-Modelle (spaCy, Flair ner-german-large, deutsche BERT-NER, GLiNER, Framework Presidio)	Erkennen Personen, Orte, Organisationen im Fließtext – auch ohne Anker davor. Gute deutsche Modelle sind robust bei Kleinschreibung und verrauschtem Text (E-Mails, OCR).	Kämpfen mit strukturierter PII (eine IBAN „versteht“ ein Sprachmodell nicht als Ganzes), brauchen Rechenleistung, und die Qualität schwankt stark je nach Modell und Textsorte.
(c) LLM-basierte Extraktion	Flexibel, versteht Kontext, kann auf Zuruf neue Kategorien finden („finde alle Aktenzeichen“).	Langsam, teuer, nicht deterministisch – und für einen Datenschutz-Nachweis denkbar ungeeignet, weil das Ergebnis nicht reproduzierbar ist. Meist nur als Zweitmeinung sinnvoll.
(d) Cloud-SaaS-Dienste	Bequem, nichts zu installieren, oft mit hübscher Oberfläche.	Der Kernkonflikt: Um Ihre Daten unkenntlich zu machen, müssen Sie die Originalangaben erst hochladen. Das Problem wird nur verschoben, nicht gelöst.
(e) Lokales Ensemble (Regex + Prüfsummen + lokales NER + OCR + menschliche Kontrolle)	Kombiniert die Stärken von (a) und (b) auf dem eigenen Gerät, mit Konsistenz über Dokumente und Rückführung. Nichts verlässt den Rechner.	Aufwändiger zu bauen; die Qualität steht und fällt mit der Sorgfalt der einzelnen Schichten. Das ist der Weg, den porthor geht.

Ein verbreiteter Denkfehler ist, nach dem „einen besten NER-Modell“ zu suchen. In der Praxis gewinnt fast immer die Kombination: Prüfsummen fangen die strukturierten Daten fehlerarm ab, ein NER-Modell übernimmt die freien Namen, Kontextregeln unterdrücken Fehlalarme, und ein Mensch bestätigt am Ende. Wer nur ein Modell einsetzt, erbt dessen blinde Flecken ungefiltert.

Fine-tuned, Zero-Shot oder LLM — was passt wann?

Sind die Dokumenttypen begrenzt und wiederkehrend, gewinnt das spezialisierte, lokal laufende deutsche Modell; wechselnde Kategorien sprechen für Zero-Shot-Modelle wie GLiNER; reine LLM-Extraktion ist am flexibelsten, aber am wenigsten nachweisbar.

• Fein-getunte deutsche Modelle (z. B. auf deutschem BERT trainiert) schlagen auf klar umrissenen Dokumenttypen sowohl Zero-Shot-Ansätze als auch allgemeine LLMs deutlich. Sie kennen die sprachlichen Feinheiten – im Deutschen besonders die Groß-/Kleinschreibung, bei der jedes Substantiv großgeschrieben wird und ein Modell leicht jeden Begriff für einen Namen hält.
• Zero-Shot-Modelle wie GLiNER punkten, wenn Sie viele wechselnde Kategorien ohne erneutes Training brauchen – „markiere Personen, Aktenzeichen, Objektnummern, Bürgennamen“ auf Zuruf.
• Reine LLM-Extraktion ist am flexibelsten, aber am wenigsten nachweisbar.

Faustregel: Sind die Dokumenttypen begrenzt und wiederkehrend – Miet- und Kaufverträge, Selbstauskünfte, Grundbuchauszüge, Behördenschreiben –, gewinnt das spezialisierte, lokale Modell. Genau das ist die Ausgangslage im Immobilien- und Finanzalltag.

Welche Kriterien zählen im Alltag wirklich?

Vergleichslisten im Netz messen gern isolierte Genauigkeit an englischen Standardtexten. Für Ihren Alltag zählen andere Dinge: deutsche Namen samt Kleinschreibung, rechnerisch validierte Prüfziffern, robuste OCR für Scans, Konsistenz über Dokumente hinweg, Recall vor Precision und Nachweisbarkeit gegenüber dem Datenschutzbeauftragten.

Deutsche Namen und Kleinschreibung. Ein „max mustermann“ in einer OCR-Zeile oder ein „SEHR GEEHRTER HERR BRANDT“ in Großbuchstaben – gute deutsche Modelle erkennen das, viele generische nicht.

Strukturierte PII mit Prüfziffer. IBAN, Steuer-ID und Sozialversicherungsnummer sollten nicht „geraten“, sondern rechnerisch validiert werden. Eine Steuer-ID hat eine Prüfziffer; eine nackte elfstellige Zahl (etwa eine Objekt- oder Rechnungsnummer) sollte nicht fälschlich als Steuer-ID maskiert werden. Prüfsummen leisten hier, was kein Sprachmodell kann.

Scans und OCR. Der am meisten unterschätzte Punkt: Ein großer Teil realer Immobilien- und Finanzdokumente liegt als eingescanntes PDF ohne Textebene vor. Nach unseren eigenen Auswertungen sind das rund 55–60 %. Für diese Dokumente ist die Qualität der Texterkennung (OCR) oft wichtiger als die Wahl des NER-Modells – denn was die OCR nicht liest, kann kein Erkenner schützen. Ein Werkzeug ohne robusten OCR-Pfad ist auf halber Strecke blind.

Konsistenz über Dokumente hinweg. „Frau Müller“, „Anna Müller“ und „die Mieterin“ müssen dieselbe Person – denselben Platzhalter – ergeben, sonst zerbricht die Analyse und die Rückführung. Das ist ein Koreferenz-Problem, das über reines Erkennen hinausgeht.

Recall vor Precision. Für den Datenschutz gilt: Eine übersehene Sozialversicherungsnummer ist teurer als ein zu viel maskierter Firmenname. Ein gutes Werkzeug arbeitet recall-orientiert – im Zweifel maskieren – und lässt die Feinkorrektur einer menschlichen Sichtprüfung. Wer Ihnen „nie zu viel geschwärzt“ verspricht, hat die falsche Prioritätenordnung. Wie man das seriös misst, zeigt der Beitrag Wie gut erkennt ein Tool sensible Daten wirklich?

Nachweisbarkeit. Können Sie einem Datenschutzbeauftragten belegen, was das Werkzeug getan hat? Ein Protokoll darüber, welche Schritte durchlaufen wurden, ist im Ernstfall Gold wert.

Und der Ort der Verarbeitung – der eigentliche Hebel, der ein eigenes Kapitel verdient.

Warum ist „lokal statt Cloud“ der entscheidende Hebel?

Weil er die Rechtslage ändert. Ein Cloud-Dienst bekommt zwangsläufig Ihre Originalangaben zu sehen, bevor er sie unkenntlich macht — das Problem wird nur verlagert. Wird dagegen lokal pseudonymisiert und verlässt nur Platzhalter-Text den Rechner, greift der vom EuGH bestätigte relative Personenbezug.

Ein Cloud-Dienst nimmt Ihnen zwar Arbeit ab – aber er bekommt zwangsläufig die Originalangaben zu sehen, bevor er sie unkenntlich macht. Sie haben das Problem „sensible Daten in fremder Hand“ damit nicht gelöst, sondern nur einen Schritt nach vorn verlagert. Jeder Anbieter mehr in der Kette ist ein Auftragsverarbeiter mehr, ein AVV mehr, ein Prüfpunkt mehr für Ihren DSB.

Wird dagegen lokal auf Ihrem Gerät pseudonymisiert und verlässt nur der pseudonymisierte Text den Rechner, ändert sich die Rechtslage grundlegend. Und das ist seit Kurzem höchstrichterlich untermauert: Der Europäische Gerichtshof hat mit Urteil C-413/23 P vom 4. September 2025 den Grundsatz des relativen Personenbezugs bestätigt. Vereinfacht: Empfängt ein Dritter – etwa der KI-Anbieter – ausschließlich pseudonymisierte Daten und verfügt er selbst über keine Mittel zur Re-Identifizierung (weil die Zuordnungstabelle allein bei Ihnen bleibt), so sind diese Daten für ihn nach dieser Rechtsprechung nicht personenbezogen. „Anonym“ sind sie damit nicht: Bei Ihnen bleiben sie personenbezogene Daten, weil Sie den Schlüssel besitzen. Die Verantwortung bleibt also bei Ihnen – aber der KI-Anbieter wird nicht zum Mitwisser Ihrer Mieter- und Kundendaten.

Das ist der entscheidende Unterschied zwischen „wir laden Ihre Daten hoch und machen sie dann sauber“ und „die Daten werden sauber, bevor sie das Haus verlassen“. Nur der zweite Weg nutzt diese Rechtsprechung wirklich aus.

Wichtig bleibt: Der EuGH nimmt Ihnen nicht alle Pflichten ab. Sie bleiben verantwortlich, müssen Betroffene informieren und die Übermittlung in Ihrem Verarbeitungsverzeichnis dokumentieren. Aber Sie ersparen sich die Auftragsverarbeitungs-Kette und haben ein starkes Argument gegenüber jedem Datenschutzbeauftragten — das passende Material dafür liegt auf der Seite für Ihren DSB.

Fazit: keine Silberkugel – aber ein klarer Favorit für sensible Dokumente

Es gibt kein „bestes Tool“, das jeden Fall löst. Für das schnelle Schwärzen eines unkritischen Textes reicht ein Regex-Werkzeug. Wer viele wechselnde Entity-Typen sucht, ist mit einem Zero-Shot-Modell gut bedient. Presidio ist ein solides Framework für Entwickler, die selbst bauen.

Sobald es aber um echte, sensible Immobilien- und Finanzdokumente geht, die eine KI verstehen und beantworten soll, führt der Weg zu einem lokalen Ensemble: strukturierte Daten über Prüfsummen, Namen über ein gutes deutsches NER-Modell, robuste OCR für Scans, Konsistenz über Dokumente, eine menschliche Sichtprüfung – und die Gewissheit, dass die Originalangaben den Rechner nie verlassen und nur pseudonymisierter Text an die KI geht. Genau diesen Weg geht porthor.

Der ehrliche Zusatz: Auch das beste Verfahren erkennt nicht jede Stelle automatisch. Deshalb gehören die Sichtprüfung und ein nachvollziehbares Protokoll fest dazu – nicht als Schwäche, sondern als seriöser Umgang mit einem Thema, bei dem Vollmundigkeit fehl am Platz ist.

Dieser Beitrag ist eine fachliche Einordnung und ersetzt keine Rechtsberatung.