Redaction ist nur so gut wie die Erkennung
PII in einem LLM-Prompt zu maskieren ist der einfache Teil. Sobald man weiss, dass ein Textabschnitt ein Name oder eine Kartennummer ist, ist das Ersetzen trivial. Der schwere Teil - der Teil, der entscheidet, ob Sie tatsaechlich Datenschutz haben oder nur dessen Anschein - ist, die PII ueberhaupt zu finden. Eine uebersehene Adresse landet trotzdem in den Logs Ihres Anbieters.
In diesem Beitrag geht es deshalb um Erkennung: wie Grepture entscheidet, was als PII zaehlt, bevor eine Anfrage OpenAI, Anthropic oder einen anderen Anbieter erreicht. Dahinter steckt kein einzelnes Zaubermodell. Es ist ein geschichteter Stack - deterministische Validatoren fuer das, was Struktur hat, NER-Modelle fuer das, was keine hat - und, wichtig, alles laeuft im Proxy-Prozess, statt an eine Drittanbieter-Erkennungs-API ausgelagert zu werden. So passt es zusammen.
Schicht eins: deterministische Erkennung fuer strukturierte PII
Viel PII hat Struktur, die man verifizieren kann, statt sie zu erraten. E-Mails haben eine Grammatik. Kreditkartennummern haben eine Luhn-Pruefsumme. IBANs haben eine Modulo-97-Pruefung. Sozialversicherungsnummern, Telefonnummern, IP-Adressen, Geburtsdaten - alle haben vorhersehbare Formen.
Fuer diese ist ein ML-Modell das falsche Werkzeug. Sie wollen keinen probabilistischen Klassifikator, der etwas mit 87% Konfidenz bewertet, das ein regulaerer Ausdruck mit Sicherheit bestaetigen kann. Die erste Schicht ist also deterministisch: eine Reihe von Mustererkennern fuer die strukturierten Kategorien - E-Mail, Telefon, Sozialversicherungsnummer, Kreditkarte, IP-Adresse, Postadresse, Geburtsdatum. Ein Treffer ist ein Treffer.
Diese Schicht laeuft auch im Open-Source-Kern des Proxys, ohne dass Modell-Downloads noetig sind. Wenn sich Treffer ueberlappen, werden sie nach Position sortiert und mit einer einfachen, vorhersehbaren Regel entdoppelt - der frueheste Start gewinnt, bei Gleichstand der laengere Span - sodass es nie halb-redaktierte Werte oder verschachtelte Ersetzungen gibt, die die Payload beschaedigen.
Das Ersetzen selbst durchlaeuft nur die String-Werte des geparsten JSON-Body, nie die strukturellen Tokens. Dieses Detail ist wichtiger, als es klingt: Naives Redigieren ueber einen rohen JSON-String kann Schluessel, Zahlen und Satzzeichen zerstoeren und einen Body erzeugen, den der Anbieter ablehnt. Die Erkennung innerhalb dekodierter String-Blaetter haelt das Dokument gueltig.
Wo Regex aufhoert: Namen
Strukturierte Muster decken viel ab, aber sie scheitern an der haeufigsten PII-Kategorie ueberhaupt: Namen. Es gibt kein Regex fuer "dieses Token ist ein Personenname". Wir haben es versucht - und die Designnotiz, die wir im Code hinterlassen haben, ist deutlich: Regex-basierte Namenserkennung ist zu unzuverlaessig fuer den Produktivbetrieb. Ein Muster, das "John Smith" faengt, faengt auch "New York", "Montagmorgen" und die Haelfte der grossgeschriebenen Woerter in jedem Dokument. Die Praezision bricht zusammen.
Namen, Organisationen und Orte sind unstrukturierte PII. Sie sind durch Kontext definiert, nicht durch Form. Genau dafuer wurden statistische Modelle gebaut - und deshalb existiert die zweite Schicht.
Schicht zwei: NER-Modelle fuer die unstrukturierte Art
Fuer die unstrukturierten Kategorien betreibt Greptures Pro-Erkennung transformerbasierte Named-Entity-Recognition-Modelle. Sie klassifizieren Text Token fuer Token und versehen jedes mit Labels wie B-PER (Beginn einer Person), I-LOC (innerhalb eines Ortes) oder O (keine Entitaet). Wir bilden diese Entitaets-Labels auf unsere PII-Kategorien ab - Person, Ort, Organisation - und verwandeln die Laeufe getaggter Tokens in saubere Spans.
Zwei Implementierungsdetails leisten hier die meiste Arbeit:
- Subwort-Zusammensetzung. Transformer-Tokenizer zerlegen Woerter in Subwort-Teile -
Hart+##mann- und taggen jedes Teil. Der Detektor fuegt diese wieder zusammen (Hartmann) und verbindet aufeinanderfolgende Entitaets-Tokens zu vollstaendigen Namen (Michael Hartmann), statt Fragmente auszugeben. - Span-Aufloesung. Sobald eine Entitaet identifiziert ist, muss sie auf exakte Zeichenpositionen im Originaltext abgebildet werden, damit der Maskierer genau den richtigen Teilstring ersetzt. Wo der Tokenizer Offsets liefert, nutzen wir sie direkt; wo nicht, loesen wir die Position auf, indem wir den Entitaetstext in der Quelle suchen und einen Cursor vorruecken, damit wiederholte Namen nicht kollidieren.
Unsere NER-Modelle decken mehrere Sprachen ab, was fuer ein europaeisches Produkt kein Nice-to-have ist - es ist die Anforderung. Ein nur fuer Englisch optimierter Detektor verliert Recall, sobald ein Prompt auf Deutsch ist, und ein EU-Gateway sieht Deutsch, Franzoesisch und Niederlaendisch ganz selbstverstaendlich. Mehrsprachige Abdeckung ist das, was dieselbe Pipeline einen Namen in einem deutschen Support-Ticket genauso zuverlaessig fangen laesst wie in einem englischen.
Wir veroeffentlichen bewusst nicht die genaue Modellaufstellung oder die Quantisierungs- und Schwellenwert-Einstellungen dahinter. Diese sind an echtem Traffic getunt, und dort steckt ein Grossteil der Genauigkeit. Die Architektur aber ist der Punkt: strukturierte PII deterministisch behandelt, unstrukturierte PII von einem dafuer gebauten Modell.
Mehr als PII: ein Modell pro Aufgabe
Die NER-Modelle sind nicht allein. Greptures Erkennungsschicht laedt eine kleine Suite spezialisierter Modelle, von denen jedes eine Aufgabe gut erledigt, statt dass ein Modell alles versucht:
- NER-Modelle fuer persoenliche Entitaeten (Namen, Orte, Organisationen).
- Prompt-Injection-Erkennung - ein Klassifikator, der Versuche markiert, die Anweisungen des Modells zu kapern.
- Toxizitaetserkennung - ein Klassifikator fuer beleidigende oder schaedliche Inhalte.
- Zero-Shot-Klassifikation - ein flexibler Klassifikator fuer Routing und Inhaltskategorisierung, bei dem Labels zur Anfragezeit definiert werden.
Jedes ist ein separates, zweckgebautes Modell fuer ein separates Problem, einmal geladen und ueber Anfragen hinweg wiederverwendet. PII-Redaction nutzt die deterministische Schicht plus die NER-Modelle; die anderen stehen daneben fuer die Sicherheitspruefungen, die gar nicht um personenbezogene Daten gehen.
Warum im-Prozess wichtig ist
Hier ist der Teil, der die Technik mit der Compliance verbindet. Jedes dieser Modelle laeuft innerhalb des Proxy-Prozesses - geladen mit quantisierten ONNX-Gewichten und lokal ausgefuehrt, nicht ueber das Netzwerk an einen gehosteten Erkennungsdienst gerufen.
Diese Reihenfolge ist der ganze Sinn der Redaction. Wenn Ihr "PII-Erkennungs"-Schritt ein API-Aufruf an einen Drittanbieter ist, haben Sie diesem Anbieter den rohen, un-redaktierten Text uebergeben, bevor er bereinigt wird. Sie haben Ihre Datenschutz-Angriffsflaeche nicht verkleinert, sondern einen Verarbeiter hinzugefuegt. Unter der DSGVO ist das ein weiterer Unterauftragsverarbeiter, den Sie vertraglich binden, dokumentieren und in Ihrem Verarbeitungsverzeichnis rechtfertigen muessen.
Erkennung im Prozess vermeidet das vollstaendig - und das gilt in unserer Cloud genauso wie in einer selbstgehosteten Bereitstellung:
- Weniger Unterauftragsverarbeiter. Kein Prompt-Text wird an einen separaten Erkennungsanbieter gesendet. Die Daten, die das Modell sieht, verlassen nie den Proxy, der die Anfrage ohnehin bearbeitet.
- Erkennung vor dem Abfluss (Art. 32). Die Redaction passiert, bevor die Anfrage nach oben weitergeleitet wird, was die einzige Reihenfolge ist, die rohe PII aus dem Anbieter-Aufruf heraushaelt. Nachtraegliche Redaction hat die Daten bereits offengelegt.
- Eine sauberere Datenherkunfts-Geschichte. Da der EU AI Act ab dem 2. August 2026 voll anwendbar ist, ist "Erkennung laeuft im Gateway, kein Datenfanout" weit einfacher einem Pruefer vorzulegen als eine Landkarte von Erkennungs-Unterverarbeitern.
Wenn Ihre Anforderungen weiter gehen - Daten duerfen Ihre eigene Infrastruktur ueberhaupt nie verlassen - ist der Proxy quelloffen und selbst hostbar, sodass Sie die gesamte Pipeline, Modelle inklusive, auf Ihren eigenen Maschinen betreiben koennen. Das ist eine Option fuer Teams, die sie brauchen, keine Voraussetzung fuer die obigen Datenschutz-Garantien. Das im-Prozess-Design haelt die Erkennung bereits aus Drittanbieter-Haenden heraus, egal ob Sie selbst hosten oder Greptures Cloud nutzen.
Sobald die Erkennung eine saubere Menge an Spans erzeugt hat, uebernimmt die Maskierung - und wenn die Antwort des Modells mit den echten Werten zurueckkommen soll, ist das der Mask-and-Restore-Ablauf. Fuer das groessere Erkennungsbild und die Auswahl der Kategorien siehe PII-Erkennung Best Practices und unseren Ueberblick der besten Open-Source-PII-Modelle.
Wichtigste Erkenntnisse
- Erkennung ist der schwere Teil der Redaction, und Grepture teilt sie in zwei Schichten: deterministische Validatoren fuer strukturierte PII, Transformer-NER-Modelle fuer die unstrukturierte Art.
- Strukturierte PII (E-Mails, Karten, IBANs, Sozialversicherungsnummern) wird deterministisch erkannt - kein ML-Raten bei etwas, das eine Pruefsumme beweisen kann - mit vorhersehbarer Ueberlappungsaufloesung, die JSON gueltig haelt.
- Namen, Organisationen und Orte werden von NER-Modellen erkannt, mit Subwort-Zusammensetzung und praeziser Offset-Aufloesung; mehrsprachige Abdeckung ist fuer ein EU-Produkt unerlaesslich.
- Die "mehreren Modelle" sind aufgabenspezialisiert, nicht redundant - separate Modelle fuer PII, Prompt-Injection, Toxizitaet und Klassifikation, jedes einmal geladen und wiederverwendet.
- Die gesamte Erkennung laeuft im Proxy-Prozess, sodass roher Text nie an eine Drittanbieter-Erkennungs-API gesendet wird - in Greptures Cloud ebenso, mit Self-Hosting-Option, wenn Daten vollstaendig auf Ihrer eigenen Infrastruktur bleiben muessen.