Warum PII-Maskierung der falsche Baustein ist

Die Frage kommt in jedem Projekt, in dem ein LLM auf Unternehmensdaten losgelassen werden soll: Wie stellen wir sicher, dass keine personenbezogenen Daten in die Cloud gelangen? Die naheliegende Antwort ist ein Filter - PII erkennen, ersetzen, Antwort zurückübersetzen. Technisch klingt das nach einem überschaubaren Baustein.

Ich habe diesen Baustein zu Ende gedacht. Das Ergebnis: Er trägt nicht. Nicht, weil die Erkennung zu schlecht wäre, sondern weil die Konstruktion ein Governance-Problem mit Technik zu lösen versucht.

Der Weg dorthin ist trotzdem lehrreich, denn er produziert Erkenntnisse, die auch dann gelten, wenn man am Ende etwas anderes baut.

Die Frage nach der Sicherheit ist nicht beantwortbar

Ein Detektor hat keinen beweisbaren Recall auf ungesehenen Daten. Recall ist dabei der Anteil der tatsächlich vorhandenen Fälle, die auch gefunden wurden - die Kennzahl, die bei einem Schutzmechanismus zählt. Man kann sie auf einem Evaluationsset messen, aber Produktion ist eine andere Verteilung. Jede Aussage der Form „es rutscht nichts durch” ist damit nicht schwach begründet, sondern unbegründet.

Das ist kein Implementierungsdetail. Wer einen automatisierten Filter als Compliance-Maßnahme verkauft, verkauft eine Garantie, die er nicht hat - und die von jedem Datenschutzbeauftragten mit einem einzigen Gegenbeispiel widerlegt wird.

Beantwortbar sind andere Fragen: Wie hoch ist die gemessene Fehlerrate? Was passiert im Fehlerfall? Wie schnell fällt es auf? Wer trägt das Restrisiko formal? Die letzte Frage ist keine Formalie. Ein Detektor ohne benannten Risikoträger bedeutet, dass die Entscheidung faktisch beim Implementierer liegt.

Kurz eingeschoben: NER und Spans

Zwei Begriffe, die im Folgenden ständig auftauchen.

NER steht für Named Entity Recognition - Modelle, die in einem Text markieren, welche Wörter eine Person, eine Organisation, einen Ort oder eine Kontonummer bezeichnen. Klassisch geschieht das durch Klassifikation jedes einzelnen Tokens: Für jedes Wort entscheidet das Modell, ob und zu welcher Kategorie es gehört.

Ein Span ist das Ergebnis: ein zusammenhängender Textabschnitt mit Anfangs- und Endposition sowie einem Typ. In „Bitte kontaktieren Sie Maria Bölk” wäre der Span die Zeichenfolge Maria Bölk, Typ PERSON, Position 23 bis 33 (Ende exklusiv).

Diese Unterscheidung ist keine Begriffsklauberei, sondern später der entscheidende Punkt: Ein Span ist ein Textabschnitt, keine Person. Dass zwei Spans auf dieselbe reale Person verweisen, steht nirgends - das muss ein eigener Schritt herstellen.

Erkennung: zwei Schichten, zwei Fehlermodi

Wer Erkennung baut, sollte sauber trennen:

Deterministische Erkenner für alles mit Struktur und Prüfsumme - IBAN, E-Mail, Telefonnummern, Steuer-IDs, interne Kennungsformate. Vollständiger Recall, testbar mit Fixtures, versionierbar. Auf diesen Teil kann man sich verlassen.

Probabilistische Erkenner für alles ohne Struktur - Personennamen, Organisationen, Orte, besondere Kategorien nach Art. 9 DSGVO. Recall unbekannt und domänenabhängig.

Für die zweite Schicht sind zero-shot-fähige Modelle wie GLiNER die bessere Wahl als klassisches Encoder-NER. Nicht wegen der Genauigkeit, sondern aus einem strukturellen Grund: Das Label-Set wird zur Laufzeit übergeben. Damit ist die Frage, was maskiert wird, Konfiguration statt Trainingsartefakt. Bei einem fixen NER-Modell bedeutet eine neue Entitätsklasse Retraining.

Zur Einordnung der Größenordnung: Auf dem SPY-Benchmark erreicht GLiNER2-PII, ein im Mai 2026 veröffentlichtes 300-Millionen-Parameter-Modell mit 42 Entitätstypen, einen Span-Level-F1 von 0,477 - der beste Wert unter fünf verglichenen Systemen, darunter OpenAI Privacy Filter und drei weitere GLiNER-Varianten.¹ Das ist kein Messfehler und keine Modellschwäche im engeren Sinn. Span-genaue Erkennung über dutzende heterogene, lokal geprägte Kategorien ist ein hartes Problem.

Aufschlussreich ist auch, wie die Konkurrenz abschneidet: OpenAI Privacy Filter erreicht auf demselben Benchmark einen vergleichbaren Recall, aber eine Precision um 0,25. Drei von vier markierten Spans gehen als falsch in die Wertung ein. Das ist mit Vorsicht zu lesen: Gemessen wird Exact Match, ein um ein Token verschobener Span zählt damit genauso als Fehler wie ein frei erfundener. Für die Sicherheitsachse ist beides gleichwertig, für die Nutzenachse nicht - eine verschobene Grenze zerstört weniger Kontext als eine Falschklassifikation. Ein Vorgeschmack auf die zweite Fehlerachse bleibt es trotzdem.

Es beziffert aber, was daraus folgt: NER allein trägt keinen Gate. Wer diese Schicht als alleinige Absicherung baut, hat das Konzept schon auf dem Papier falsch.

Nachtrainieren ist die vierte Stufe, nicht die erste

Der Reflex bei unbefriedigender Erkennung ist Fine-Tuning. Bei GLiNER ist das die teuerste und meist unnötigste Option.

Die Label-Strings gehen durch denselben Encoder wie der Text - das Label bedeutet etwas. "employee identification number", "Personalnummer" und "ID" erzeugen am selben Modell unterschiedliches Verhalten. Der billigste Hebel ist deshalb Label-Wording, und er ist überraschend groß. Der zweite ist Threshold pro Label statt global. Der dritte: Entitäten mit fester Struktur gehören in die deterministische Schicht - eine Personalnummer mit definiertem Format nachzutrainieren löst ein Problem, für das ein Regex vollständigen Recall liefert.

Fine-Tuning dreht außerdem genau die Eigenschaft zurück, wegen der man GLiNER gewählt hat. Ab diesem Moment existiert ein Modell-Artefakt mit Version, Trainingsdatensatz und Pflegeaufwand - und der Recall bleibt unbekannt, nur auf anderen Daten.

Was in jedem Fall gebraucht wird, unabhängig von der Trainingsfrage: ein Evaluationsset. Ohne das lässt sich keine der günstigeren Stufen bewerten. Das ist die eigentliche Arbeit.

Die zweite Achse: Nutzenfehler

Hier wird es interessant, und hier fehlt in den meisten Konzepten eine ganze Dimension.

Ein übersehener Span ist ein Sicherheitsfehler. Aber es gibt eine zweite Fehlerklasse, die genauso wehtut:

„Maria Bölk” und „Frau B.” werden nicht als dieselbe Person erkannt. Das nachgelagerte Modell sieht zwei Personen, wo eine ist.
„Hans Müller GmbH” wird als Person klassifiziert. Aus einem Geschäftspartner wird ein Betroffener.

Diese Fehler zerstören Kontext. Und die beiden Achsen ziehen gegeneinander: Threshold runter verbessert den Recall und verschlechtert den Nutzen, weil mehr falsch-positive Spans mehr Kontext zerstören.

Daraus folgt ein Satz, der in Diskussionen fast immer falsch herum steht: Übermaskierung ist keine sichere Voreinstellung. Sie verlagert den Fehler nur - von einem Datenschutzrisiko zu einem fachlich falschen Ergebnis. In regulierten Kontexten ist das ebenfalls ein Compliance-Problem, nur eins, das später auffällt. „Im Zweifel lieber zu viel maskieren” ist nicht konservativ, sondern anders riskant.

Was technisch dagegen hilft

Entity Resolution als eigener Schritt. NER liefert Spans, keine Entitäten. Der Schritt von Spans zu Entitäten wird von keinem NER-Modell geleistet. Teilweise ist er deterministisch machbar - Nachnamensabgleich, Initialabgleich, Anrede- und Titelnormalisierung decken in deutschen Geschäftstexten viel ab, weil die Variantenbildung konventionalisiert ist. Was danach übrig bleibt, braucht echte Semantik und bleibt ungelöst. Ein lokales generatives Modell dafür einzusetzen ist naheliegend und meiner Einschätzung nach trotzdem falsch: GPU-Betrieb und zusätzliche Latenz im synchronen Pfad für eine Handvoll Randfälle. In der Detektion selbst hat ein nichtdeterministisches Verfahren ohnehin nichts verloren - dort leckt ein Fehler still.

Deterministische Nachkorrektur über probabilistischem Output. Rechtsformkürzel sind eine endliche, pflegbare Liste: GmbH, GmbH & Co. KG, AG, KGaA, KG, OHG, GbR, UG, gGmbH, e.K., e.V., PartG, PartGmbB, SE, eG, AöR. Grenzt ein PERSON-Span an ein Rechtsformtoken, wird der Gesamtspan zu ORGANISATION - beim Compound über das gesamte Suffix, nicht nur über das letzte Token. Dasselbe Muster für vorangestellte Marker. Der Modellfehler wird nicht wegtrainiert, er wird strukturell abgefangen.

Surrogate statt Platzhalter. [PERSON_1] hat kein Genus, keinen Kasus, keine Anrede. „Sehr geehrte [PERSON_1]” ist grammatisch kaputt, und das Modell arbeitet auf kaputtem Input. Synthetische Ersetzungen - „Maria Bölk” → „Julia Weber”, „Frau B.” → „Frau W.” - erhalten Morphologie und Register. Der Preis: Der Output sieht aus wie echte Daten. Fällt die Rückübersetzung aus oder wird ein Zwischenstand geloggt, ist nicht erkennbar, dass maskiert wurde. Vertretbarer Kompromiss: Surrogate für die Modellverarbeitung, Platzhalter für alles, was geloggt oder inspiziert wird - zwei Repräsentationen aus derselben Entitätstabelle.

Diese Tabelle ist damit keine String-Ersetzungsliste mehr, sondern ein Entitätsregister: ID, alle Oberflächenformen, Typ, Surrogat, Genus. Und sie muss mindestens session-scoped sein, nicht request-scoped - sonst bekommt dieselbe Person über mehrere Turns unterschiedliche Surrogate.

Die einzige Metrik, die die Frage wirklich beantwortet, ist nicht Precision oder Recall, sondern Aufgabenqualität auf maskiertem gegenüber unmaskiertem Text. Dieselbe Aufgabe, beide Varianten, Ergebnisse vergleichen. Alles andere misst den Filter statt das System.

Und dann fällt das Ganze auseinander

Bis hierhin ist das ein lösbares, wenn auch aufwendiges Problem. Der Bruch kommt, wenn man den realen Pfad aufzeichnet:

Input → RAG → Bereinigung → Kontextfenster → LLM → Rückübersetzung → Tool-Call → LLM → … → User

Die Ersetzungen müssen über alle Tool-Calls hinweg identisch bleiben. Das ist kein Filter mehr, sondern ein zustandsbehafteter Übersetzungslayer im heißen Pfad. Und der Killer ist nicht die Ersetzung im Prompt, sondern das Modell, das das Surrogat verändert zurückgibt - flektiert, gekürzt, eingebettet in einen generierten Titel oder ein SQL-Statement. Die Rückabbildung ist dann kein Lookup mehr. Der Tool-Call in Richtung Zielsystem braucht ohnehin Klardaten, die Grenze existiert also nicht einmal, sondern wird pro Aufruf neu gezogen.

Der eigentliche Einwand

Und dann die Frage, die den ganzen Aufwand entwertet: Wo liegen die Daten eigentlich?

Jira, Confluence, Salesforce, Microsoft 365. Wenn die Quellsysteme bei US-Hyperscalern laufen, hat die Übermittlung bereits stattgefunden. Die Maskierung schützt dann nicht die Daten, sondern verhindert genau eine zusätzliche Verarbeitung durch einen zusätzlichen Auftragsverarbeiter - bei dem der Betreiber häufig derselbe Konzern ist, der die Daten ohnehin hostet.

Dahinter steckt der eigentliche Denkfehler: Maskierung ist ein technischer Ersatz für eine fehlende Rechtsgrundlage.

Der Einwand liegt nahe: Der EuGH hat 2025 bestätigt, dass Personenbezug relativ ist - für einen Empfänger, der nicht re-identifizieren kann, sind pseudonymisierte Daten keine personenbezogenen Daten.² Maskierung wäre demnach genau das Werkzeug, das die Auftragsverarbeiter- und Drittlandfrage auflöst. Auf dem Papier stimmt das. In der Pipeline scheitert es an zwei Stellen.

Erstens: Die Entlastung setzt voraus, dass der Empfänger tatsächlich nicht re-identifizieren kann. Das ist keine Absichtserklärung, sondern eine nachzuweisende Eigenschaft - und ein Detektor mit unbekanntem Recall kann diesen Nachweis strukturell nicht liefern. Man behauptet Anonymität gegenüber dem Empfänger auf Basis eines Filters, dessen Fehlerrate man nicht kennt.

Zweitens: Der Tool-Call in Richtung Zielsystem braucht Klardaten. Die Zuordnung, die den relativen Personenbezug tragen soll, überschreitet die Grenze bei jedem Aufruf neu. Dazu kommt, dass Meinungsäußerungen personenbezogene Daten sind, sobald sie sich einer identifizierbaren Person zuordnen lassen³ - und in Support-Tickets, Beschwerden und Gesprächsnotizen trägt der umgebende Kontext diese Zuordnung häufig auch dann, wenn kein Name mehr im Text steht. Solche Texte sind damit selbst bei perfekter Erkennung nicht sauber entpersonalisiert.

Ist die Rechtsgrundlage vorhanden - AVV, EU-Region, dokumentierte Zweckbindung - verschwindet der Bedarf. Fehlt sie, ruht die Entlastung auf einem Nachweis, den der Filter nicht führen kann. Der Baustein ist in beiden Ästen des Entscheidungsbaums das falsche Werkzeug.

Maskierung ist damit keine Rechtsgrundlage, sondern Datenminimierung nach Art. 5 Abs. 1 lit. c, umgesetzt über Art. 25 - Risikoreduktion. Das ist ehrlicher und deutlich leichter zu verteidigen.

Der unspektakuläre Weg

Wenn Maskierung ein Ersatz für eine fehlende Rechtsgrundlage ist, dann ist die Lösung, die Rechtsgrundlage herzustellen. Das klingt nach Ausweichen, ist aber der kürzere Weg - und er ist bekanntes Handwerk.

Ich bin kein Jurist; das ist die Struktur, wie ich sie verstehe, und sie gehört im Einzelfall geprüft.

Der AVV ist nicht der Prüfpunkt, sondern eine von mehreren Bedingungen. Er regelt das Verhältnis zum Anbieter und macht die Weitergabe an den Auftragsverarbeiter zulässig. Die Rechtsgrundlage für die Verarbeitung selbst muss beim Verantwortlichen ohnehin stehen - meist berechtigtes Interesse oder Vertragserfüllung. Wer ohne Rechtsgrund verarbeitet, tut das mit AVV genauso unzulässig.

Zweckbindung ist der unterschätzte Punkt. Die Daten wurden für Abrechnung, Support oder Vertragsabwicklung erhoben. Sie jetzt durch ein LLM zu schicken, ist eine neue Verarbeitung mit möglicherweise neuem Zweck. Häufig kompatibel, wenn das Modell dieselbe Aufgabe schneller erledigt. Häufig nicht, wenn daraus Auswertung, Bewertung oder Profilbildung wird. An dieser Frage hängen Projekte tatsächlich - nicht am AVV.

Drittlandtransfer, wenn der Anbieter ein US-Konzern ist. EU-Region hilft, löst es aber nicht vollständig, weil der Konzernzugriff aus den USA - Stichwort CLOUD Act - davon unberührt bleibt. Der praktische Weg läuft über Standardvertragsklauseln plus Transfer Impact Assessment. Das EU-US Data Privacy Framework ist der bequemere Pfad, aber politisch instabil; wer darauf allein baut, muss bei der nächsten Kippe umdokumentieren. Standardarbeit, aber dokumentationspflichtig.

Und die LLM-spezifischen Punkte: kein Training auf den übergebenen Daten, vertraglich zugesichert statt in Marketingmaterial. Retention und Logging beim Anbieter. Unterauftragsverarbeiter, denn der Modellanbieter hostet oft nicht selbst. Bei Entscheidungen mit Rechtswirkung Art. 22. Und für ein Auskunftsersuchen muss erklärbar sein, wo Daten in der Pipeline liegen - Logs, Traces und Prompt-Caches sind Verarbeitung.

Der Aufwand verschwindet also nicht, er wandert. Statt eines Übersetzungslayers im heißen Pfad entstehen Verarbeitungsverzeichnis-Eintrag, TOM-Dokumentation, Löschkonzept über die gesamte Kette, Zweckbindungsprüfung und gegebenenfalls eine Datenschutz-Folgenabschätzung. Das ist weniger Arbeit, deutlich weniger fehleranfällig - und es ist Papier statt Laufzeitkomplexität. Papier fällt nicht mitten in einer Session auseinander.

Wichtig ist, was diese Ebene nicht abdeckt. Ein AVV erlaubt die Verarbeitung. Er sagt nichts darüber, welche Tools ein Agent aufrufen darf, welche Systeme er schreibend erreicht und unter wessen Identität er handelt. Bei agentischen Systemen liegt dort das reale Risiko - und dort greift keine Rechtsgrundlage, sondern nur Struktur.

Was übrig bleibt

Der Baustein verschwindet nicht, er schrumpft auf das, was er tatsächlich leisten kann:

Schema statt Volltext. Die Vertrauensgrenze lässt sich ohne Volltextübertragung überschreiten: RAG ruft ab, Extraktion und Aggregation laufen lokal, über die Grenze geht ein definiertes Schema. Keine Rückübersetzung nötig, weil nie Klardaten drüben waren. Der Fehlermodus wechselt von still und unbegrenzt zu laut und begrenzt - die Aufgabe schlägt fehl, wenn ein Feld nicht extrahierbar war. Das ist ein Fehler, den man sieht. Der Preis ist Allgemeinheit: Es funktioniert nur, wenn man weiß, was man braucht. Und vorausgesetzt ist, dass die Felder selbst unkritisch sind - ein Freitextfeld zusammenfassung im Schema hebelt die Grenze wieder aus. Die Disziplin verschiebt sich vom Filter auf den Schemaentwurf.

Klassifikation an der Quelle. Feldbasierte Typisierung statt Texterkennung stromabwärts. Ein als personenbezogen typisiertes Feld wird nicht selektiert. Deterministisch, prüfbar, versionierbar - überall dort, wo Struktur existiert.

Nicht-personenbezogene Vertraulichkeit. Quellcode, Preislisten, Strategiepapiere, Kundennamen als Geschäftsgeheimnis. Hier greift die Entwarnung „liegt ohnehin bei Atlassian” oft nicht, und es gibt keine Rechtsgrundlage, die das Problem auflöst.

Erkennung ohne Ersetzung. PII überhaupt zu finden ist als Fähigkeit unabhängig wertvoll: Datenklassifikation, Bereinigung von Freitextfeldern, Überblick, wo im Bestand personenbezogene Daten liegen. Der Recall-Einwand von oben gilt hier unverändert, aber sein Fehlermodus ist harmlos: Ein übersehenes Feld blockiert keine Übermittlung, es verlängert nur die Liste offener Punkte. Das ist Data Governance, nicht Prompt-Pipeline - und braucht keine Rückabbildung.

Fazit

Der Verlauf der Vertrauensgrenze ist eine Governance-Entscheidung. Wer sie technisch zu lösen versucht, baut Komplexität in den heißen Pfad, um eine Entscheidung zu vermeiden, die ohnehin jemand treffen muss.

Die tragfähigere Position ist auch die einfachere: nicht maskieren, sondern die Rechtsgrundlage sauber herstellen und dafür sorgen, dass die Daten die Grenze nur dort überschreiten, wo es nötig ist. Das ist strukturell statt probabilistisch - und im Gegensatz zu einem Filter mit unbekanntem Recall ist es eine Aussage, die man verteidigen kann.

Bleibt der Satz, der die Prioritäten sortiert: Datenschutz ist bekanntes Handwerk mit bekannten Werkzeugen. Wirkungskontrolle ist es nicht. Wer Aufwand in Maskierung steckt, arbeitet an dem Teil, für den bereits Lösungen existieren - und lässt den unbearbeitet, für den es keine gibt.

Wer das zu Ende denkt, landet bei einer Umkehrung: Maskierung stellt die Frage Was darf das Modell sehen? und beantwortet sie mit einem Filter, dessen Fehlerrate niemand kennt. Die tragfähige Frage lautet Was darf der Agent wohin weitergeben? - und die lässt sich deterministisch beantworten, außerhalb des Modells. Die Bausteine dafür existieren: Tool-Scoping, Identitätsdelegation, kontextabhängige Policy, Audit. Was fehlt, ist nicht das Werkzeug, sondern die Ebene, die daraus gebaut wird.

Wie diese Ebene aussieht, habe ich als vendor-neutralen Blueprint unter dem Namen Dissemination Control veröffentlicht. Er ergänzt die Rechtsgrundlage, ersetzt sie nicht - und er setzt an dem Punkt an, an dem der Filter aufgehört hat zu tragen.

Zaratiana et al., GLiNER2-PII: A Multilingual Model for Personally Identifiable Information Extraction, arXiv:2605.09973 (Mai 2026). SPY-Benchmark: Savkin et al., 2025. Exact-Match-Evaluation auf Span-Ebene; die Modellkarte auf Hugging Face nennt 0,477 als Durchschnitts-F1, der Begleitartikel des Herstellers 0,471. ↩
EuGH, Urteil vom 4. September 2025, C-413/23 P (EDSB / SRB). ↩
EuGH, Urteil vom 20. Dezember 2017, C-434/16 (Nowak) - Prüfungsantworten und Prüferanmerkungen als personenbezogene Daten. ↩