Presidio bringt dich an die Startlinie, nicht ins Ziel
Wer personenbezogene Daten aus Text entfernen muss, bevor er die eigenen Systeme verlaesst, greift fast automatisch zu Microsoft Presidio. Es ist die naheliegende Open-Source-Antwort auf PII-Erkennung — und das zu Recht: gut konstruiert, MIT-lizenziert und wirklich stark in dem, wofuer es gebaut wurde.
Dann setzt du es vor eine echte LLM-Last — jeden Prompt, jeden Anbieter, jede Sprache, die deine Nutzer tatsaechlich tippen — und stoesst an eine Grenze. Diese Grenze ist kein Bug. Sie ist die Luecke zwischen einer Erkennungsbibliothek und einem Redaktionssystem. Presidio ist Ersteres. Produktive PII-Redaktion fuer KI-Traffic braucht Letzteres.
In diesem Beitrag geht es darum, wo diese Luecke liegt — und warum es mehr Arbeit ist, sie selbst zu schliessen, als es aussieht.
Was Presidio wirklich ist (und wo es glaenzt)
Presidio ist ein zweistufiges Python-Toolkit. Der Analyzer findet PII, der Anonymizer transformiert sie. Der Analyzer laesst eine Registry von Erkennern ueber deinen Text laufen und liefert Spans mit Konfidenzwerten. Manche Erkenner arbeiten mit Regex und Pruefsummen (Kreditkarten per Luhn, IBANs, E-Mails, SSNs). Andere stuetzen sich auf eine NLP-Engine — standardmaessig spaCy, mit Hugging-Face-Transformern oder Stanza als austauschbare Backends — um das zu finden, was Regex nicht kann, etwa Namen. Ein Kontext-Schritt hebt die Konfidenz an, wenn verraeterische Woerter in der Naehe stehen.
Fuer strukturierte PII ist das hervorragend. Eine Kreditkartennummer hat eine Pruefsumme, eine E-Mail eine Grammatik. Presidio bestaetigt das mit nahezu Gewissheit, und genau dafuer solltest du ein Tool wie dieses einsetzen. Nichts im Folgenden stellt Presidios Erkennungsqualitaet innerhalb seines Designrahmens infrage.
Das Problem: "PII redigieren, bevor sie einen LLM-Anbieter erreicht" ist eine viel groessere Aufgabe als "PII in einem String erkennen". Und Presidio erledigt per Design nur den zweiten Teil.
Luecke 1: Presidio sagt dir vorab, dass es nicht alles faengt
Du musst der Genauigkeitsgrenze nicht auf Zuruf eines Wettbewerbers glauben — Presidios eigene Dokumentation ist erfrischend ehrlich. Aus der offiziellen FAQ und den Docs:
- "Because it is using automated detection mechanisms, there is no guarantee that Presidio will find all sensitive information" — weshalb "additional systems and protections should be employed".
- Zu kommerziellen Alternativen: SaaS-PII-Angebote "often have better entity coverage or accuracy than Presidio".
- Der Evaluationsleitfaden ist deutlich: "No de-identification system is perfect. It is important to evaluate the performance of a PII detection system for your specific use case." Das Projekt veroeffentlicht keinen offiziellen Genauigkeits-Benchmark — du sollst selbst messen.
Wo ballt sich diese Unsicherheit? Bei den unstrukturierten Kategorien — Namen, Organisationen, Orte — die ganz vom NER-Modell abhaengen statt von einer Pruefsumme. Das sind zugleich die haeufigsten PII in echten Prompts. Es gibt keinen regulaeren Ausdruck fuer "dieses Token ist ein Personenname". Versuch es, und du markierst New York, Montagmorgen und die Haelfte aller grossgeschriebenen Woerter. Die Qualitaet deiner Namenserkennung ist also exakt die Qualitaet des NER-Modells, das du eingebunden hast — und das spaCy-Standardmodell tauscht Recall gegen Geschwindigkeit.
Ein unabhaengiger Benchmark eines Privacy-Anbieters testete mehrere universelle PII-Tools, darunter Presidio, gegen rund 45.000 Woerter unsauberer realer Daten (Gespraechstranskripte, medizinische Notizen, Chatprotokolle) und fand einen aggregierten Recall im Bereich von 57–73%. Nimm das eher als Richtung denn als Gesetz — es ist der Test eines Anbieters und isoliert keine Presidio-spezifische Zahl —, aber die Richtung deckt sich mit Presidios eigenem Hinweis. Auf sauberen strukturierten Daten ist die Erkennung top. Auf dem freien Text, den Menschen tatsaechlich an LLMs schicken, rutscht ohne starkes Modelltuning ein nennenswerter Teil der Namen durch.
Luecke 2: Die Mehrsprachen-Wand (frag jeden, der in Europa ausliefert)
Hier ein Detail, das EU-Teams besonders trifft. Presidios Docs sagen unmissverstaendlich: "While different detection mechanisms such as regular expressions are language agnostic, the context words used to increase the PII detection confidence aren't."
In der Praxis heisst das: ein NER-Modell pro Sprache, plus sprachspezifische Kontextwort-Listen, die du selbst uebersetzen und pflegen musst. Sobald ein Prompt auf Deutsch statt Englisch kommt, verliert deine sorgfaeltig getunte englische Pipeline Recall — und ein EU-Gateway sieht Deutsch, Franzoesisch und Niederlaendisch routinemaessig. Die Community-Issues spiegeln das: eigene Erkenner, die im Deutschen versagen, Reibung beim Bau mehrsprachiger Docker-Images, Standardmodelle, die mit deutschen Organisationsnamen kaempfen.
Mehrsprachigkeit ist fuer ein europaeisches Produkt kein Nice-to-have. Sie ist die Anforderung. Mit Presidio ist sie ein Projekt, das dir gehoert.
Luecke 3: Redaktion ist standardmaessig eine Einbahnstrasse
Das ist der grosse Punkt fuer LLM-Anwendungen — und hier merken die meisten Teams, dass Presidios Anonymizer nicht fuer ihren Workflow gebaut wurde.
Der Anonymizer liefert mehrere Operatoren — Replace, Redact, Mask, Hash, Encrypt, Keep. Nur Encrypt ↔ Decrypt ist umkehrbar. Redact, Mask und Hash sind per Design verlustbehaftet: Ist aus Sarah Chen erst <PERSON> geworden, ist das Original weg.
Fuer viele KI-Workloads zerlegt eine Einbahnstrassen-Redaktion still das Produkt. Denk an Zusammenfassungen im Kundensupport, personalisierte Dokumentenerstellung oder jeden mehrstufigen Assistenten: Du musst dem Modell bereinigten Text schicken, aber die Antwort muss mit den echten Namen, E-Mails und Kontonummern zurueckkommen. Das erfordert Mask-and-Restore — PII auf dem Hinweg durch stabile Token ersetzen, auf dem Rueckweg zurueckmappen. Presidio gibt dir Verschluesselungs-Primitive, aber der vollstaendige Restore-Workflow — Token-Speicher, Mapping, Lebenszyklus — ist deiner zum Bauen und Betreiben.
Und es wird subtiler. Presidio haelt ausdruecklich "does not store or maintain stateful sessions" fest. Also liegt sogar die Konsistenz bei dir: Dieselbe Person sollte ueber jeden Gespraechsschritt hinweg auf denselben Platzhalter abgebildet werden, sonst verliert das Modell den Ueberblick, wer wer ist. Eine juengere Aenderung liess den Hash-Operator sogar standardmaessig zufaellige Salts pro Entitaet verwenden, sodass identische Werte unterschiedlich gehasht werden, wenn du nicht selbst ein explizites Salt durchreichst. Entitaets-Konsistenz auf Gespraechsebene — Pflicht fuer ein LLM-Gateway — baust du auf Presidio auf, sie kommt nicht mit.
Luecke 4: Es faengt keine Secrets
Presidio zielt auf PII: Namen, E-Mails, Telefonnummern, Finanzkennungen. Es erkennt keine API-Schluessel, Bearer-Token, AWS-Credentials oder Datenbank-Verbindungsstrings. Das ist kein Versehen, das du wegkonfigurieren kannst — ein Maintainer bestaetigte in den Projekt-Diskussionen, dass Secret-Erkennung "is not currently supported".
Fuer LLM-Traffic ist das ein echtes Risiko. Entwickler kopieren Config in Prompts. RAG-Pipelines saugen .env-Dateien und interne Dokumente ein. Coding-Assistenten liefern Snippets mit echten Credentials. Eine Redaktionsschicht, die fuer Secrets blind ist, uebersieht eine der schwerwiegendsten Leak-Kategorien — genau in den Workloads, in denen es zaehlt. Du braeuchtest ein zweites Tool und eine zweite Integration, um das abzudecken.
Luecke 5: Eine Bibliothek liegt nicht auf dem Netzwerkpfad
Selbst bei perfekter Erkennung hat eine Bibliothek ein strukturelles Problem: Sie laeuft nur dort, wo du sie aufrufst.
Presidio ist Python, eingebettet in deinen Code. Jeder Codepfad, der Daten an einen Anbieter schickt, braucht einen expliziten Analyzer- und Anonymizer-Aufruf. Vergisst du einen — einen neuen Endpunkt, einen Hintergrundjob, ein Drittanbieter-SDK, einen autonomen Agenten mit Tool-Calls, die du nicht selbst geschrieben hast — gehen unredigierte PII direkt hinaus. Mit wachsender Oberflaeche wird "haben wir wirklich jeden Ausgangspunkt umhuellt?" zu einer Frage, die du nicht mehr zuverlaessig beantworten kannst.
Eine Bibliothek liefert ausserdem nichts Operatives gratis. Kein Audit-Trail darueber, was erkannt und redigiert wurde, kein Policy-Management, kein Dashboard, kein Logging — und, wie die FAQ anmerkt, kein SLA und keine Garantie, weil Presidio "is not an official product of any company" ist. Fuer ein Open-Source-Toolkit ist das voellig vertretbar. Es ist nur sehr viel fehlende Oberflaeche zwischen "Presidio erkennt PII in einem String" und "wir koennen einem Pruefer belegen, dass im letzten Quartal keine Kunden-PII OpenAI erreicht hat".
Erkennung ist ein Feature. Redaktion ist ein System.
Tritt man einen Schritt zurueck, ist das Muster klar. Presidio loest ein eng umrissenes Problem — finde PII in diesem Text — und loest es gut. Aber produktive PII-Redaktion fuer KI-Traffic ist ein System mit etlichen weiteren beweglichen Teilen:
- Abdeckung jedes Ausgangspfads, nicht nur der, die du zu umhuellen daran gedacht hast.
- Hoher Recall auf unstrukturierten, mehrsprachigen PII, weil genau das in echten Prompts steckt.
- Erkennung von Secrets und Credentials, neben personenbezogenen Daten.
- Umkehrbare, konsistente Redaktion, damit Antworten echte Werte zurueckbringen, ohne dass das Modell sie je sieht.
- Erkennung vor dem Egress, damit Rohtext die Grenze gar nicht erst verlaesst.
- Ein Audit-Trail, den du einem Compliance-Team uebergeben kannst.
Du kannst jedes dieser Teile auf Presidio aufbauen. Teams tun das. Aber dann pflegst du NER-Modelle, sprachspezifische Kontextlisten, einen Token-Speicher, eine Restore-Pipeline, einen separaten Secret-Scanner, eine Proxy-Schicht und ein Audit-Log — ein stehendes System, keinen Bibliotheksaufruf.
Wie Grepture die Luecke schliesst
Grepture wurde um das System herum gebaut, nicht um den String. Es ist ein Sicherheits-Proxy, der auf dem Netzwerkpfad zwischen deiner Anwendung und jedem KI-Anbieter sitzt. Redaktion ist also nichts, woran du dich erinnern musst — sie ist etwas, das jede Anfrage automatisch durchlaeuft, in jeder Sprache, inklusive Aufrufen von Agenten und Drittanbieter-Bibliotheken, die du nicht geschrieben hast.
Unter der Haube ist die Erkennung so geschichtet, wie das Problem tatsaechlich zerfaellt: deterministische Validatoren fuer strukturierte PII (die per Pruefsumme belegbaren Kategorien) und mehrsprachiges Transformer-NER fuer die unstrukturierte Art — Namen, Organisationen, Orte — ueber die europaeischen Sprachen, die ein EU-Gateway taeglich sieht. Alles laeuft in-process im Proxy, sodass roher Prompt-Text nie an eine Drittanbieter-Erkennungs-API verteilt wird, bevor er bereinigt ist. (Mehr zu diesem Design in wie wir PII redigieren, bevor sie das LLM erreicht — ohne das genaue Modelltuning preiszugeben, das die eigentliche Arbeit leistet.)
Ueber der Erkennung sind die Teile eingebaut, die Presidio dir ueberlaesst:
- Mask-and-Restore — umkehrbare Redaktion mit konsistenten Token, sodass Antworten personalisiert zurueckkommen, waehrend das Modell nur Platzhalter gesehen hat.
- Secret-Scanning fuer API-Schluessel, Token und Credentials, neben PII — kein zweites Tool zum Integrieren.
- Ein eingebauter Audit-Trail und ein Dashboard, sodass die Compliance-Story ein Report ist und kein Forschungsprojekt — was unter DSGVO und dem EU AI Act zaehlt.
Wer die vollstaendige Gegenueberstellung Feature fuer Feature will, findet sie im Vergleich Grepture vs. Presidio. Und falls deine Anforderungen es verlangen: Der Proxy ist Open Source und selbst hostbar — dieselbe Pipeline auf deiner eigenen Infrastruktur.
Presidio ist eine gute Wahl, wenn du ein Erkennungs-Toolkit brauchst und das Team hast, ein System darum zu bauen. Wenn du aber eigentlich das System brauchst — Abdeckung ueberall, Umkehrbarkeit, Secrets, mehrsprachiger Recall und ein Audit-Trail —, ist das eine andere Art von Problem. Und genau dafuer ist Grepture gebaut.
Wichtigste Punkte
- Presidio ist eine Erkennungsbibliothek, kein Redaktionssystem. Es findet PII in einem String gut; produktive KI-Redaktion braucht weit mehr drumherum.
- Die eigenen Docs raeumen die Genauigkeitsgrenze ein — keine Garantie auf vollstaendige Abdeckung, am schwaechsten bei den unstrukturierten Namen/Orgs/Orten, die echte Prompts dominieren, und out-of-the-box schlechter in nicht-englischen Sprachen.
- Redaktion ist standardmaessig eine Einbahnstrasse. Umkehrbares, konsistentes Mask-and-Restore — unverzichtbar fuer mehrstufige und personalisierte LLM-Workloads — musst du selbst bauen.
- Es erkennt keine Secrets. API-Schluessel und Credentials in Prompts gehen direkt durch.
- Eine Bibliothek laeuft nur dort, wo du sie aufrufst. Ein Proxy auf dem Netzwerkpfad faengt jeden Ausgangsweg ab — mit einem Audit-Trail als Beleg.