OpenAI Privacy Filter: Ein PII-Modell, das lokal laeuft

OpenAI hat ein Redaktionsmodell veroeffentlicht — und open-source gestellt

Am 22. April 2026 hat OpenAI Privacy Filter veroeffentlicht, ein kleines Modell mit offenen Gewichten, das speziell fuer die Erkennung personenbezogener Daten in unstrukturiertem Text entwickelt wurde. Es steht unter Apache 2.0 und ist auf Hugging Face verfuegbar — Sie koennen die Gewichte herunterladen, das Modell fine-tunen und auf eigener Hardware betreiben, sogar auf einem Entwickler-Laptop.

Genau das ist der spannende Punkt. OpenAI ist die Firma, die wie keine andere fuer "Schicken Sie Ihre Daten an unsere API" steht — und die Kernbotschaft ihrer Ankuendigung ist das Gegenteil davon: Sie sollen PII bevor es ein Modell erreicht entfernen. Das Eingangsrisiko — Nutzer, die Logs, E-Mails oder Vertraege in ChatGPT einfuegen — ist genau das, was OpenAI entschaerfen will.

Was kann das Modell konkret und wo steht es im Vergleich zur bestehenden Open-Source-PII-Landschaft? Sehen wir uns das genauer an.

Was ist drin

Privacy Filter ist ein Sparse-Mixture-of-Experts-Modell (MoE) mit 1,5 Mrd. Gesamtparametern, von denen pro Token aber nur 50 Mio. aktiv sind — dank eines 128-Experten-Designs mit Top-4-Routing im Feed-Forward-Block. Diese aggressive Sparsity ist Absicht: zur Inferenzzeit fuehren Sie effektiv ein 50M-Parameter-Modell aus, das klein genug ist, um in einem Browser-Tab oder auf einer CPU zu laufen.

Das Modell erkennt acht Kategorien sensibler Spans:

Die letzte Kategorie — secret — ist ungewoehnlich. Die meisten PII-Modelle hoeren bei "personenbezogenen Informationen" auf. OpenAI hat die Erkennung von Zugangsdaten explizit in dasselbe Modell eingebaut. Das spiegelt ein Muster wider, das wir in produktiven AI-Gateways immer wieder sehen: Entwickler kopieren Code in LLMs, und Zugangsdaten rutschen mit hindurch.

Die Benchmark-Werte

Auf dem oeffentlichen PII-Masking-300k-Benchmark erreicht Privacy Filter:

• +F1: 96,0 % (94,04 % Precision / 98,04 % Recall)
• +Auf einer korrigierten Version desselben Benchmarks: F1: 97,43 %

Zum Vergleich: Ein fine-getuntes DeBERTa v3 auf demselben Datensatz erreicht F1 ~97,6 %. Privacy Filter ist also ungefaehr gleichauf mit dem besten festen Open-Source-Modell, das die Community bisher produziert hat — bei deutlich kleinerer Inferenzgroesse. Das ist ein echtes Ergebnis, keine PR-Aussage.

Warum "lokal ausfuehrbar" wichtig ist

Die interessante Designentscheidung ist das Throughput-Ziel. OpenAI hat Privacy Filter ausdruecklich als Tool fuer "Privacy-Workflows mit hohem Durchsatz" positioniert — gedacht zum Bereinigen von Daten, bevor sie ein anderes Modell erreichen, nicht als Modell selbst.

Es gibt drei Stellen, an denen so etwas wirklich gebraucht wird:

1. +Beim Einlesen — bevor Logs, Support-Tickets oder Dokumente gespeichert oder indexiert werden.
2. +In einem Proxy vor LLM-Aufrufen — PII aus dem Prompt entfernen, bevor er an OpenAI / Anthropic / ein selbst gehostetes Modell geht.
3. +Am Edge / im Browser — saeubern, bevor die Daten das Geraet des Nutzers ueberhaupt verlassen.

Ein Modell mit 50M aktiven Parametern und F1 von 96 % macht (3) zum ersten Mal realistisch. Sie brauchen keinen GPU-Pool, um einen Absatz Text zu redigieren. Das laesst sich in einem Service Worker ausfuehren.

Das ist eine echte Verschiebung. Der bisherige Open-Source-Stand der Technik fuer In-Browser-PII-Erkennung waren deutlich kleinere, schwaechere Modelle — oder ein vollstaendiges DeBERTa an den Client auszuliefern, was fuer die meisten Apps zu schwer ist.

Vergleich zu vorhandenen Modellen

Einen ausfuehrlicheren Ueberblick ueber die Landschaft finden Sie in unserem Vergleich der besten Open-Source-Modelle fuer PII-Redaktion. Hier die Kurzfassung mit Privacy Filter eingeordnet:

Ein paar ehrliche Beobachtungen:

• +Die Entity-Abdeckung ist schmaler. Acht Kategorien gegenueber 54+ bei ai4privacy DeBERTa oder 60+ bei GLiNER. Wenn Sie feinkoernige Labels brauchen (z. B. IBAN von credit_card von routing_number zu unterscheiden), wirft Privacy Filter das in account_number zusammen — Sie muessen Regex oder ein weiteres Modell darueberlegen.
• +Es ist nicht Zero-Shot. Anders als GLiNER koennen Sie zur Inferenzzeit keinen eigenen Entity-Typ angeben. Das Label-Set ist fest eingebrannt.
• +Es ist English-first. Die Model Card von OpenAI fokussiert auf englische Performance. Mehrsprachige Nutzung ist moeglich, aber unklar charakterisiert — Piiranha ist fuer sprachenuebergreifende Abdeckung weiterhin die sicherere Wahl.
• +Das Verhaeltnis Genauigkeit zu Groesse ist die eigentliche Story. Fuer die Groessenklasse ist F1 von 96-97 % hervorragend. Die MoE-Architektur leistet hier echte Arbeit.

Wo es in eine echte Pipeline passt

Ehrlich eingeordnet: Privacy Filter ist ein sehr gutes Erkennungsmodell, kein vollstaendiges Redaktionssystem. Eine produktive Pipeline braucht zusaetzlich:

1. +Regex fuer strukturierte PII — Kreditkartenmuster, Sozialversicherungsnummern, gaengige Credential-Formate. Sub-Millisekunden, deterministisch, auditierbar. Nicht ersetzen, sondern davorschalten.
2. +Das ML-Modell fuer unstrukturierte PII — Namen, Adressen, kontextabhaengige Entitaeten. Hier verdienen Privacy Filter, DeBERTa oder GLiNER ihr Geld.
3. +Reversibles Mapping — die meisten Teams wollen PII gar nicht zerstoeren. Sie wollen es maskieren, bevor es ihre Umgebung verlaesst, eine sinnvolle Antwort vom LLM bekommen und dann die Originalwerte wiederherstellen, wenn die Antwort zurueckkommt. Privacy Filter erkennt die Spans, aber Sie muessen weiterhin ein Mapping pro Request fuehren.
4. +Observability — was wurde wann von welcher Regel redigiert? Ohne Audit-Trail koennen Sie die Compliance-Fragen, die Sie ueberhaupt erst dazu gebracht haben, nicht beantworten.

Wenn Sie das von Grund auf bauen, ist Privacy Filter ein starker Default fuer Schritt 2. Wenn Sie bereits GLiNER oder ein DeBERTa-Fine-Tune in Produktion haben, ist die Frage vor allem: koennen Sie ein 180M-Parameter-Modell durch ein Modell mit 50M aktiven Parametern an derselben Stelle ersetzen?

Was sich aendert — und was nicht

Diese Veroeffentlichung validiert die Architektur mehr als den Markt. Die Form — kleines Open-Weight-Modell, lokal ausfuehren, vor dem Frontier-Modell saeubern — ist genau die Architektur, die Grepture und einige andere Projekte seit ein paar Jahren propagieren. Dass OpenAI das unter eigener Marke ausliefert, ist ein nuetzlicher Rueckenwind — es macht die Argumentation gegenueber Security-Teams einfacher, die frueher gefragt haben "warum ueberhaupt redigieren?".

Was es nicht aendert: Der Rest des Problems verschwindet nicht. PII zu erkennen ist die einfache Haelfte. Die schwere Haelfte ist alles drumherum: die Regex-Schicht fuer strukturierte Muster, die Policy-Schicht, die entscheidet, was mit jeder Erkennung passiert, das reversible Mapping, damit KI-Antworten nuetzlich bleiben, der Audit-Trail, den Ihr Compliance-Team irgendwann sehen will, und die Secret-Scanning-Regeln, die Zugangsdaten erwischen, die das secret-Label von Privacy Filter uebersehen koennte.

Ein Modell ist eine Komponente. Eine Pipeline ist ein Produkt.

Wie Grepture hilft

Grepture ist die Pipeline. Wir sitzen zwischen Ihrer Anwendung und dem LLM-Provider, fuehren Regex- und ML-Erkennung auf jedem Request aus, unterstuetzen reversible Maskierung, damit Antworten personalisiert bleiben, und protokollieren jede Redaktionsentscheidung fuer das Audit. Sie bekommen die Architektur, fuer die Privacy Filter gebaut ist — ohne das Modell selbst zu hosten, die Schichten zusammenzubauen oder die Policy-Engine selbst zu schreiben.

Wenn Sie Privacy Filter evaluieren und ueberlegen, wo Sie es einsetzen sollen, ist das der richtige Instinkt — und das Gateway ist meistens die Antwort. Wir koennen Privacy Filter auch als ML-Backend fuer die Erkennung betreiben, wenn das das Modell ist, auf das Sie standardisieren wollen.