OpenAI Privacy Filter: PII-Masking lokal, Open Source - und auf Deutsch?
OpenAI hat mit dem Privacy Filter ein Open-Source-Modell veröffentlicht, das personenbezogene Daten in Texten erkennt und maskiert - lokal, ohne API-Call. Für deutschsprachige Unternehmen gibt es dabei einen Haken, der sich aber lösen lässt.
Wer Kundendaten an gehostete Sprachmodelle schickt, bewegt sich datenschutzrechtlich auf dünnem Eis. Seit April 2026 gibt es mit dem OpenAI Privacy Filter ein Werkzeug, das personenbezogene Informationen (PII) direkt auf dem eigenen Rechner erkennt und schwärzt - bevor der Text das Haus verlässt. Das Modell steht unter Apache 2.0, ist nur wenige Gigabyte groß und läuft auf handelsüblicher Hardware. In der Praxis funktioniert das gut - mit einer Einschränkung: Deutsche Texte werden spürbar schlechter erkannt als englische. Doch genau dafür liefert das Projekt einen eingebauten Weg: Fine-Tuning auf eigene Daten.
Was der Privacy Filter konkret kann
Das Modell ist kein gewöhnliches LLM. Es handelt sich um einen bidirektionalen Token-Classifier mit 1,5 Milliarden Parametern, von denen nur etwa 50 Millionen gleichzeitig aktiv sind (Sparse Mixture-of-Experts mit 128 Experten, Top-4-Routing). Statt Text zu generieren, weist es jedem Token ein Label zu: acht PII-Kategorien - darunter unter anderem Namen, Adressen, E-Mail-Adressen, Telefonnummern und Kontonummern - nach dem BIOES-Schema (Begin, Inside, Outside, End, Single). Ein spezialisierter Decoder erzwingt dabei gültige BIOES-Übergänge und stellt sicher, dass die erkannten Spans in sich konsistent bleiben. Über sechs konfigurierbare Transition-Bias-Parameter lässt sich steuern, ob das Modell eher aggressiv oder zurückhaltend maskiert.
Auf dem öffentlichen Benchmark PII-Masking-300k erreicht das Modell laut OpenAI einen F1-Score von 96 % (94,04 % Präzision, 98,04 % Recall), auf einer bereinigten Version desselben Benchmarks 97,43 %. Das Kontextfenster von 128.000 Tokens erlaubt es, lange Dokumente - Verträge, Support-Threads, E-Mail-Verläufe - in einem Durchlauf zu verarbeiten, ohne sie vorher in Stücke zerlegen zu müssen.
Warum bidirektional wichtig ist
Reguläre Ausdrücke finden '@' in E-Mail-Adressen, aber nicht den Unterschied zwischen 'Alice aus dem Wunderland' und 'Alice Hansen aus der Buchhaltung in Kopenhagen'. Der Privacy Filter betrachtet den gesamten Kontext in beide Richtungen. Dadurch entscheidet er auf Basis der Umgebung, ob ein Name eine reale Person referenziert oder nicht. Das ist der zentrale Vorteil gegenüber Regex-basierten Pipelines.
Das Problem mit deutschen Texten - und der Lösungsweg
In eigenen Tests auf Hugging Face zeigt sich: Englische Anreden wie 'Dear Philipp Huberty' werden zuverlässig erkannt und maskiert. Die deutsche Variante 'Sehr geehrter Philipp Huberty' dagegen bleibt unberührt stehen. Das ist kein Zufall. OpenAI selbst dokumentiert, dass die multilinguale Leistung ungleichmäßig ist und das Modell primär auf englischsprachigen Daten trainiert wurde. Für deutschsprachige Geschäftskorrespondenz - mit ihren typischen Anredeformeln, Adressformaten und zusammengesetzten Nachnamen - reicht die Basisversion oft nicht aus.
Das bedeutet aber nicht, dass das Modell für den DACH-Raum nutzlos ist. Es bedeutet, dass Sie es anpassen müssen. Und genau das ist explizit vorgesehen.
Fine-Tuning über das mitgelieferte CLI
Das Projekt auf GitHub liefert ein eigenes Trainings-Kommando mit: 'opf train /path/to/training-data.jsonl --output-dir /path/to/finetuned-model'. Damit lässt sich das Modell auf domänenspezifischen Daten nachtrainieren. Ob dabei intern ein Adapter-Verfahren wie LoRA zum Einsatz kommt oder alle Parameter aktualisiert werden, dokumentiert das Repository nicht im Detail. Klar ist: Bei nur 50 Millionen aktiven Parametern ist ein Nachtraining auch auf einer einzelnen Consumer-GPU in vertretbarer Zeit machbar - unabhängig vom konkreten Verfahren.
Die Trainingsdaten müssen im JSONL-Format vorliegen, wobei jeder Eintrag den Text und die Token-Labels nach dem BIOES-Schema enthält. OpenAI berichtet von einer Verbesserung des F1-Scores von 54 % auf 96 % bei einer Domänenanpassung mit vergleichsweise wenigen Beispielen. 'Wenige Beispiele' ist dabei relativ - erfahrungsgemäß sprechen wir von einigen hundert annotierten Texten, nicht von zehntausenden.
Der Aufwand für die Annotation ist der eigentliche Kostenfaktor. Die Modellgröße und das mitgelieferte Tooling machen den technischen Teil vergleichsweise einfach. Wer ein Team hat, das einige Tage lang Beispiel-E-Mails oder Support-Tickets labeln kann, bekommt ein Modell, das deutsche PII deutlich zuverlässiger erkennt als die Basisversion.
DSGVO-Kontext: Warum PII-Masking jetzt relevant ist
Die praktische Bedeutung dieses Tools erschließt sich erst im regulatorischen Kontext. Wenn Mitarbeitende Kundendaten in gehostete LLMs eingeben, handelt es sich um eine Übermittlung personenbezogener Daten an einen Drittanbieter. Dafür braucht es eine Rechtsgrundlage nach DSGVO. In vielen Fällen liegt keine vor - insbesondere keine explizite Einwilligung der betroffenen Kunden. Die italienische Datenschutzbehörde Garante hat OpenAI ein Bußgeld von 15 Millionen Euro auferlegt, unter anderem wegen fehlender Rechtsgrundlage für die Verarbeitung von Nutzerdaten. Zur Einordnung: Die maximalen Bußgelder nach Art. 83 Abs. 5 DSGVO liegen bei bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes - je nachdem, welcher Betrag höher ist.
PII-Masking vor dem API-Call ist die pragmatische Antwort: Der Text, der den eigenen Server verlässt, enthält keine personenbezogenen Daten mehr. Das ersetzt keine vollständige DSGVO-Compliance - Sie brauchen weiterhin eine Datenschutz-Folgenabschätzung (DPIA), einen Auftragsverarbeitungsvertrag mit dem LLM-Anbieter und saubere Löschkonzepte. Aber es reduziert das Risiko an der kritischsten Stelle.
Kein Ersatz für Anonymisierung
OpenAI selbst betont: PII-Masking ist nicht dasselbe wie Anonymisierung. Aus dem verbleibenden Kontext lassen sich unter Umständen Rückschlüsse auf Personen ziehen. Das Modell senkt das Risiko der Re-Identifikation, es eliminiert es nicht. Für die meisten Unternehmensanwendungen - Support-Routing, RAG-Pipelines, Embedding-Generierung - ist das dennoch ein erheblicher Fortschritt gegenüber dem Status quo, der oft 'hoffen, dass niemand personenbezogene Daten eingibt' lautet.
Einordnung: Wann lohnt sich der Einsatz?
Der Privacy Filter ist kein Allheilmittel, aber ein gut konstruiertes Werkzeug für einen konkreten Anwendungsfall. Er lohnt sich, wenn Sie regelmäßig Texte an gehostete LLMs senden, die personenbezogene Daten enthalten können - also E-Mails, Support-Tickets, Vertragsdokumente, interne Notizen. Er lohnt sich weniger, wenn Ihre Texte ohnehin keine PII enthalten oder wenn Sie ausschließlich mit On-Premise-Modellen arbeiten.
Für den deutschsprachigen Einsatz planen Sie realistisch einen Aufwand von einigen Tagen für Annotation und Fine-Tuning ein. Die technische Hürde ist dabei gering: Das CLI ist dokumentiert, die Modellgröße handhabbar, und Sie brauchen kein ML-Team. Was Sie brauchen, sind Beispieldaten aus Ihrem tatsächlichen Textbestand und jemanden, der die PII-Spans korrekt markiert. Wenn Sie unsicher sind, ob und wie das in Ihren Workflow passt, sprechen Sie mich an.