Vorstellung des OpenAI Privacy Filter

• Ein Open-Weights-Modell zum Erkennen und Maskieren personenbezogener Daten in unstrukturiertem Text, das lokal ausgeführt werden kann, sodass Daten vor dem Filtern das Gerät nicht verlassen müssen
• Kombiniert bidirektionale Token-Klassifikation mit Span-Decoding, um Eingaben in einem Durchgang zu labeln und PII-Spans auch in Kontexten von bis zu 128.000 Token schnell zu rekonstruieren
• Im Unterschied zu regelbasierten Verfahren, die von Formaten wie Telefonnummern oder E-Mails abhängen, unterscheidet es auf Basis von Sprach- und Kontextverständnis besser zwischen öffentlichen Informationen und Informationen, die maskiert werden müssen
• Wurde mit öffentlichen und synthetischen Daten gemeinsam trainiert, erreichte auf PII-Masking-300k einen F1-Wert von 96 %, in einer korrigierten Version F1 97,43 %, und steigerte die Leistung bei der Domain-Anpassung mit wenig Daten von 54 % auf 96 %
• Ist weder ein Anonymisierungstool noch ein Ersatz für Compliance-Zertifizierungen; in hochsensiblen Bereichen bleiben menschliche Prüfung, domänenspezifische Evaluierung und zusätzliches Fine-Tuning wichtig

---

Produktüberblick und Bereitstellungsmodell

• Ein Open-Weights-Modell, das auf Erkennung und Ausblendung personenbezogener Daten spezialisiert ist und PII im Text finden sowie maskieren oder löschen kann
• Unterstützt die lokale Ausführung, sodass Daten vor dem Filtern das Gerät nicht verlassen müssen, und kann das Offenlegungsrisiko im Vergleich zur De-Identifizierung auf einem Server verringern
• Ist auf die schnelle Verarbeitung langer Eingaben ausgelegt und kann in einem einzigen Durchlauf entscheiden, was ausgeblendet werden soll
• Entwickler können es in ihrer eigenen Umgebung ausführen und für ihre eigenen Anwendungsfälle feinabstimmen, um stärkeren Datenschutz in Trainings-, Indexierungs-, Logging- und Review-Pipelines zu verankern
• Wurde auf Hugging Face und GitHub unter der Apache-2.0-Lizenz veröffentlicht und ist für Experimente, Anpassungen und kommerzielle Bereitstellung gedacht

Was es von bisherigen Ansätzen unterscheidet

• Traditionelle PII-Erkennungstools verlassen sich häufig auf deterministische Regeln für Formate wie Telefonnummern oder E-Mail-Adressen
• Solche Verfahren können in engen Einsatzbereichen gut funktionieren, übersehen aber leicht subtilere personenbezogene Informationen und sind schwächer im Umgang mit Kontext
• Privacy Filter kann auf Basis eines tieferen Sprach- und Kontextverständnisses ein breiteres Spektrum an PII in unstrukturiertem Text erkennen
• Es wurde so entworfen, dass es besser zwischen Informationen unterscheidet, die öffentlich sind und erhalten bleiben sollten, und solchen, die mit einer Person verknüpft sind und maskiert oder gelöscht werden sollten
• Es wurde mit dem Ziel entwickelt, die Datenschutzstandards über das bisherige Niveau hinaus anzuheben; intern werden ebenfalls feinabgestimmte Versionen in datenschutzwahrenden Workflows eingesetzt

Modellarchitektur und Erkennungsumfang

• Verwendet eine Architektur, die ein bidirektionales Token-Klassifikationsmodell mit Span-Decoding kombiniert
• Startet von einem autoregressiven vortrainierten Checkpoint und wird anschließend zu einem Token-Klassifikator auf Basis eines festen Datenschutz-Labelschemas angepasst
• Statt Text tokenweise zu generieren, wird die Eingabesequenz in einem Schritt vollständig gelabelt und danach mit einem eingeschränkten Viterbi-Verfahren zu konsistenten Spans rekonstruiert
• Dadurch zeigt die Architektur hohe Geschwindigkeit und Effizienz, da alle Token in einem einzigen Forward-Pass gelabelt werden
• Kann PII-Spans mithilfe des umgebenden Kontexts bestimmen; das veröffentlichte Modell unterstützt Kontexte von bis zu 128.000 Token
• Das Gleichgewicht zwischen Recall und Precision lässt sich an die Betriebsumgebung anpassen
• Das veröffentlichte Modell umfasst insgesamt 1,5 Milliarden Parameter, davon sind 50 Mio. aktiv
• Die Vorhersagekategorien sind die acht Klassen private_person, private_address, private_email, private_phone, private_url, private_date, account_number, secret
• account_number wird genutzt, um verschiedene Kontonummern einschließlich Kreditkartennummern und Bankkontonummern zu maskieren, und secret deckt Einträge wie Passwörter und API-Schlüssel ab
• Die Labels werden als BIOES-Span-Tags decodiert, um sauberere und konsistentere Maskierungsgrenzen zu erzeugen

Trainingsprozess und Evaluationsergebnisse

• Zunächst wurde eine Privacy-Taxonomy erstellt, die die Span-Typen definiert, die das Modell erkennen soll
  • Sie umfasst persönliche Identifikatoren, Kontaktinformationen, Adressen, nicht öffentliche Datumsangaben, verschiedene Kontonummern einschließlich Kredit- und Bankinformationen sowie Secrets wie API-Schlüssel und Passwörter
• Der Language-Modeling-Head des vortrainierten Sprachmodells wurde durch einen Token-Classification-Head ersetzt und anschließend mit einem überwachten Klassifikationsziel weitertrainiert
• Das Training kombinierte öffentliche und synthetische Daten, um sowohl realistische Texte als auch schwierige Datenschutzmuster zu erfassen
  • Unvollständige Labels in öffentlichen Daten wurden durch modellgestützte Annotation und Prüfung ergänzt, um die Abdeckung zu verbessern
  • Synthetische Beispiele dienten dazu, die Vielfalt bei Formaten, Kontexten und Datenschutz-Untertypen zu erhöhen
• Bei der Inferenz werden tokenbasierte Vorhersagen per eingeschränktem Sequenz-Decoding in konsistente Spans umgewandelt
• Neben Standard-Benchmarks wurden zusätzliche synthetische und Chat-orientierte Evaluierungen für schwierigere, kontextsensitive Fälle durchgeführt
• Auf PII-Masking-300k erreichte es einen F1-Wert von 96 %, eine Precision von 94,04 % und einen Recall von 98,04 %
• In einer korrigierten Version, die bei der Prüfung festgestellte Probleme in den Datensatzannotationen berücksichtigt, erreichte es F1 97,43 %, Precision 96,79 % und Recall 98,08 %
• Schon mit wenig Daten gelang eine schnelle Domain-Anpassung; auf dem evaluierten Benchmark für Domain-Adaption stieg der F1-Wert von 54 % auf 96 %
• Die Model Card enthält außerdem Stresstests zur Secret-Erkennung in Codebasen sowie zu mehrsprachigen, adversarialen und kontextabhängigen Beispielen

Einschränkungen und Hinweise zur Nutzung

• Es ist kein Anonymisierungstool, keine Compliance-Zertifizierung und ersetzt in Hochrisikoumgebungen keine Richtlinienprüfung
• Es ist als ein Baustein in einem insgesamt datenschutzorientierten Systemdesign zu verstehen
• Das Verhalten wird von der beim Training verwendeten Label-Taxonomy und den Entscheidungsgrenzen beeinflusst
• Da Organisationen unterschiedliche Erkennungs- und Maskierungsrichtlinien wünschen können, können Evaluationen in der eigenen Domäne oder zusätzliches Fine-Tuning nötig sein
• Die Leistung kann in Sprachen, Schriftsystemen, Namenskonventionen und Domänen abweichen, die von der Trainingsverteilung abweichen
• Seltene Identifikatoren oder mehrdeutige Personenbezüge können übersehen werden; insbesondere bei begrenztem Kontext wie kurzen Sequenzen kann zu viel oder zu wenig maskiert werden
• In hochsensiblen Bereichen wie Recht, Medizin oder Finanzen bleiben menschliche Prüfung, domänenspezifische Evaluierung und Fine-Tuning wichtig

Veröffentlichungsabsicht und weitere Richtung

• Datenschutz wird als fortlaufende Aufgabe verstanden, die Forschung, Produktdesign, Evaluierung und Bereitstellung umfasst
• Das spiegelt die Bedeutung kleiner, effizienter Modelle wider, die bei eng definierten realen Aufgaben Frontier-Niveau erreichen
• Die Veröffentlichung folgt dem Ziel, Infrastruktur zur Wahrung der Privatsphäre leichter prüfbar, ausführbar, anpassbar und verbesserbar zu machen
• Das Modell ist als Werkzeug gedacht, das Modellen hilft, über die Welt zu lernen, ohne dabei private Informationen von Einzelpersonen zu lernen
• Diese Preview-Veröffentlichung ist auch ein Schritt, um Feedback aus der Forschungs- und Datenschutz-Community einzuholen und die Leistung weiter zu verbessern

[GN⁺]

Hacker-News-Kommentare

• So eine Funktion habe ich schon vor ein paar Jahren einmal implementiert, und dabei wurden einige Dinge klar
  PII-Bereinigung muss auf dem Client wieder zurückübersetzt werden, wenn man die UX erhalten will. Wenn der Name zum Beispiel John ist und als [NAME] maskiert wird und das Modell dann mit Hi [NAME] antwortet, muss das vor der Anzeige an den Nutzer wieder zu Hi John rekonstruiert werden
  Am Ende braucht man also in der Schicht, mit der der Nutzer interagiert, einen Mechanismus zur Rückersetzung
  Außerdem sind maskierte PII-Daten für die meisten Zwecke fast nutzlos. Ein Modell braucht bis zu einem gewissen Grad echte Daten, um zu funktionieren, und es gibt so viele Dinge, die als PII klassifiziert werden, dass einfacher Chat zwar noch okay ist, es aber deutlich schwieriger wird, wenn Nutzer komplex mit einem LLM interagieren müssen. Im Extremfall funktioniert dann gar nichts mehr oder es kommt zu Halluzinationen
  Deshalb wird das zwar auf Plattformebene unterstützt, in der Praxis aber wegen dieser Grenzen kaum genutzt
  Ein realistischerer Ansatz ist aus meiner Sicht, nur einen Teil der besonders sicherheitskritischen PII zu entfernen und ein vertrauenswürdiges Modell zu nutzen, das PII so schnell wie möglich verwirft. Dafür muss sich dann aber auch das Systemdesign ziemlich ändern
• Ich baue gerade https://github.com/KevinXuxuxu/anon_proxy, ein Tool ähnlich einem Anonymisierungs-Proxy, das vor einem LLM-Anbieter sitzt
  Es kombiniert modellbasierte Erkennung mit regex PII detection und verarbeitet Ersetzung und Wiederherstellung bidirektional in API-Anfragen und -Antworten. Wenn man das Erkennungsmodell lokal hostet, verlässt die PII die lokale Umgebung nicht
  Das war besonders nützlich beim Umgang mit sensiblen Dokumenten wie Recht, Steuern oder Einwanderung
  • Das Gute an diesem Ansatz ist, dass er sich an jedes Modell anschließen lässt
    Allerdings können das gesamte Gespräch und sein Kontext weiterhin vom Modell und vom Betreiber eingesehen werden
    Deshalb gefällt mir ein Ansatz wie bei Moxies Confer https://confer.to/, bei dem alles verschlüsselt ist und außer dem Endnutzer niemand den Klartext sehen kann, deutlich besser
  • Ich frage mich, wie die Wiederherstellung auf der Antwortseite funktioniert
    Wenn ein Dokument schon im Input maskiert wurde, müsste auch die LLM-Ausgabe maskiert sein — ich verstehe nicht, wie es danach weitergeht
• In diesem Release gibt es einige technisch interessante Punkte
  Der Privacy Filter ist offenbar ein bidirektionales token-classification model mit span decoding; als Ausgangspunkt diente ein autoregressiv vortrainierter Checkpoint, der dann zu einem Token-Klassifikator über einer festen Privacy-Label-Taxonomie angepasst wurde
  Statt Text Token für Token zu generieren, wird die Eingabesequenz in einem Durchgang gelabelt, und mit einem constrained-Viterbi-Verfahren werden konsistente Spans dekodiert
  Das veröffentlichte Modell hat insgesamt 1,5B Parameter, davon 50M aktive Parameter
  Außerdem heißt es, man habe den LM head des vortrainierten Sprachmodells durch einen token-classification head ersetzt und es anschließend mit einem überwachten Klassifikationsziel weitertrainiert
  • Dann müsste sich das auch dafür eignen, in unstrukturiertem Text die Position sensibler Informationen zu finden, ohne auf andere PII-Erkennungsmittel angewiesen zu sein
    Man könnte den Originaltext durch den Filter schicken, die Spans erhalten und diese wieder auf den Originaltext abbilden — damit hätte man letztlich die vollständigen Positionsinformationen der PII
• Nicht so schlau wie OpenAI, aber ich habe https://tools.nicklothian.com/webner/index.html gebaut, das im Browser mit BERT-basiertem NER einen Teil der PII maskiert
  Für die Anwendungsfälle, die ich getestet habe, hat es ziemlich gut funktioniert
  Das OpenAI-Modell wirkt klein genug, dass ich überlege, es ebenfalls in mein Tool einzubauen
  • Ich habe es gerade auf ein Dokument losgelassen, und es scheint wegen vieler False Positives ziemlich schwer nutzbar zu sein
    Ich habe ein Markdown-Dokument mit etwa 100 Zeilen eingegeben; dabei wurde matter als Organisation erkannt, obwohl es nur Teil von frontmatter ist, end ebenfalls als Organisation, obwohl es zu frontend gehört, und auch MCP wurde als Organisation klassifiziert
    Es gab viele Ergebnisse wie Following the discussion in , blahblah, die auch grammatikalisch keinen Sinn ergeben
    Es fühlt sich exakt wie NLP von vor 10 Jahren an, und das erinnert mich wieder daran, was für ein gutes Projekt spaCy in diesem Bereich war
• Man sollte klar sagen, dass solche Modelltypen fast immer naiv und rudimentär sind
  Für eine einzelne neutrale Nachricht wie Hi, this is Bob. reicht es meist aus, aber sobald sich Daten ansammeln, habe ich noch kein PII-Redaction-Tool gesehen, das das Risiko einer Re-Identifizierung wirklich vollständig berücksichtigt
  Problematisch wird es, sobald Unternehmen so etwas einsetzen und dann glauben, die Daten seien anonymisiert. Das ist keine Anonymisierung
  Trotzdem kann diese Art von Filterung recht nützlich sein, wenn die Daten nicht direkt veröffentlicht oder geteilt werden, sondern in Zwischenschritten wie Moderation, Human Eval oder Model Training verwendet werden
• Es ist etwas schade, dass die Beispiele größtenteils Dinge sind, die sich auch mit regex leicht erfassen lassen, aber ich freue mich trotzdem, dass es als offenes lokales Modell veröffentlicht wurde
  • Bei meinen Kunden verhindere ich mit regulären Ausdrücken, dass persönliche E-Mail-Adressen oder Telefonnummern auf Websites erscheinen
    Trotzdem scheint es sinnvoll, für zusätzliche Sicherheit ein solches Modell parallel laufen zu lassen
    Ich habe keinen GPU-Server, hoffe aber, dass es ein leichtgewichtiges Modell ist, das bei unter 2k Tokens pro Durchlauf auch mit CPU-only inference klarkommt
• Wenn man auf den Link klickt, wird man auf eine maschinell übersetzte Version der OpenAI-Seite weitergeleitet, und die Bedeutung ist komplett zerstört
  redacted wurde mit dem polnischen redagować übersetzt, was nicht Anonymisierung bedeutet, sondern eher Text bearbeiten oder redigieren
• Mich würde interessieren, wie sich das im Vergleich zu Presidio schlägt, das regex und Modelle kombiniert: https://microsoft.github.io/presidio/
  • Vielleicht ließe sich dieses Modell auch in Presidio einbauen
• Ich denke, https://peyeeye.ai löst buchstäblich all die Probleme, über die in diesem Thread gesprochen wird
  • Ein Unternehmen, das ohne Erlaubnis die Daten anderer abgegriffen hat und nun ein Privacy-Tool baut — die Ironie ist kaum zu überbieten
• Ich begrüße diese Veröffentlichung
  Auch außerhalb regulierter Branchen gibt es viele Gründe, solche Modelle und Praktiken vorzuhalten, und theoretisch wird ein Teil davon auch wegen des EU AI Act nötig
  Ich habe bei https://grepture.com bereits Redaction und Rehydration mit einem spezialisierten NER-Modell eingebaut und plane, das hier ebenfalls in die Pipeline aufzunehmen
  Wenn man es optional in den hot path legt und damit die Stellen vor und nach der LLM-Anfrage tatsächlich anfassen kann, ist das für Compliance oder Szenarien mit direkten Nutzereingaben ziemlich nützlich