OpenAI hat ein Privacy-Classifier-Tool veröffentlicht. openai/privacy-filter ist ein bidirektionaler Token-Klassifikator mit 1,5 Milliarden Parametern, lizenziert unter Apache 2.0, der im Browser läuft, acht Kategorien personenbezogener Daten in einem einzigen Forward Pass erkennt und eine Governance-Schicht schließt, die in vielen Agent-Stacks zu wenig Gewicht hat.
Wer das Release als weiteren Modell-Drop liest, verpasst das eigentliche Signal.
Wer heute Agenten auf Kundendaten betreibt, löst PII-Redaktion meist per Regex-Bibliothek oder leitet Anfragen durch ein LLM, beides mit eigenen Kompromissen. Dieser Artikel zeigt, was openai/privacy-filter tatsächlich ist, welche Architekturentscheidungen zählen und wo das Modell in einen echten Agent-Governance-Stack gehört. Außerdem erkläre ich, warum dieses Release meine Position zu Agenten auf nicht vertrauenswürdigen Eingaben aktualisiert und was das für regulierte Workloads bedeutet.
Governance constraints
- openai/privacy-filter ist ein zwecktrainierter Klassifikator, kein General-LLM. 1,5 Milliarden Parameter insgesamt, 50 Millionen aktiv per MoE-Routing, 128.000-Token-Kontext, Apache-2.0-Lizenz.
- Die Architektur entstammt der gpt-oss-Linie. Der Language-Model-Head ist durch einen 33-Class-BIOES-Token-Classification-Head ersetzt. Dekodiert mit Constrained Viterbi für Span-Kohärenz.
- Ausführung im Browser-Tab über Transformers.js und WebGPU. Kein API-Round-Trip, kein Server-Egress, kein OpenAI-Account zur Laufzeit nötig.
- Erkennt acht PII-Kategorien: private_person, private_email, private_phone, private_address, private_url, private_date, account_number, secret.
- Keine Anonymisierung. Englisch-first mit nachlassender Trefferquote auf Nicht-Latein-Schriften. Statische Label-Taxonomie, für Erweiterungen ist Fine-Tuning erforderlich.
OpenAI hat ein Privacy-Classifier-Tool veröffentlicht.
Die meisten Berichte werden das als weiteren OpenAI-Drop auf Hugging Face einordnen. Das Architektursignal ist ein anderes. Hier handelt es sich um einen bidirektionalen Klassifikator, der aus einem autoregressiven gpt-oss-Checkpoint post-trainiert wurde, mit einem durch einen 33-Class-Token-Classification-Head über acht Privacy-Span-Kategorien plus Background-Class ersetzten Language-Model-Head.
OpenAI hat kein Modell zum Chatten veröffentlicht. Veröffentlicht wurde ein Tool, das Eingaben und Ausgaben anderer Modelle absichert.
Das ist bedeutsam, weil die Branche dazu neigt, generative LLMs für Aufgaben einzusetzen, die zwecktrainierte Klassifikatoren besser lösen, darunter PII-Erkennung. Ein 70-Milliarden-Parameter-General-Purpose-Modell auf jede eingehende Anfrage zum PII-Masking anzuwenden, ist rechnerisch teuer für eine im Kern einfache Klassifikationsaufgabe. Ein 1,5-Milliarden-Parameter-Klassifikator mit 50 Millionen aktiven MoE-Parametern erledigt dasselbe in einem Forward Pass, läuft auf einem Laptop und kann keine neuen E-Mail-Adressen halluzinieren.
Dass die Herleitung von gpt-oss selten kommentiert wird, ist das eigentliche Versäumnis. OpenAI signalisiert, dass die gpt-oss-Familie zur Grundlage für zweckgebaute Hilfsmodelle wird, die Behörden und Engineering-Teams lokal betreiben sollen. Damit ist zu rechnen: Es werden weitere folgen.
Für die Bewertung eines Agent-Governance-Stacks für regulierte Workloads entwirft webvise compliance-konforme Stacks von Grund auf.
Die Architektur, in klaren Worten
Privacy Filter ist ein Pre-Norm-Encoder-Stack aus acht Blöcken mit Grouped-Query-Attention (14 Query-Heads, 2 KV-Heads, Gruppengröße 7), Rotary Positional Embeddings und einem 128-Expert-Sparse-MoE-Feed-Forward-Block mit Top-4-Routing. Die Residual-Stream-Breite beträgt 640. Gesamtparameter: 1,5 Milliarden, aktive Parameter pro Token: 50 Millionen.
Banded Attention mit einer Bandbreite von 128 ergibt ein effektives Fenster von 257 Tokens. Bei einer Kontextlänge von 128.000 Tokens entfällt das Chunking für typische Long-Document-Workloads.
Der Labeling-Head gibt 33 Logits pro Token aus: ein Background-Label plus acht Span-Kategorien, aufgefächert in BIOES-Tags (Begin, Inside, End, Single). Die Inferenz verwendet einen Constrained-Viterbi-Decoder mit Linear-Chain-Transition-Scoring über vollständige Label-Pfade. Sechs Transition-Bias-Parameter steuern Background-Persistenz, Span-Einstieg, Fortsetzung, Abschluss und Boundary-to-Boundary-Übergabe. Der praktische Effekt: Span-Grenzen bleiben kohärent in Mischformat-Text, wo unabhängiges Argmax-Decoding fragmentiert.
Laufzeit-Operating-Points erlauben die Feinjustierung des Precision-vs.-Recall-Tradeoffs ohne Retraining. Bias Richtung Span-Einstieg und Fortsetzung führt zu Over-Redaktion (compliance-freundlich, aber lauter). Bias Richtung Background-Persistenz zu Under-Redaktion (erhält Kontext, riskiert Leakage). Die vollständige Model Card inklusive Evaluierungsmethodik liegt unter huggingface.co/openai/privacy-filter.
Warum Browser-Ausführbarkeit die Platzierungsentscheidung verändert
Die meisten PII-Redaktions-Middlewares laufen serverseitig. Daten überqueren die Leitung im Klartext, treffen auf einen Redaktions-Service, werden bereinigt und gelangen dann zur Model-API. Jeder Schritt addiert Latenz, Kosten und einen Punkt, an dem die Klartextversion in Logs landet.
Privacy Filter läuft in einem Browser-Tab via Transformers.js mit WebGPU und q4-Quantisierung. Die Konsequenz: Benutzereingaben lassen sich im Browser redaktieren, bevor der Text das Gerät verlässt.
Der Server empfängt eine redaktierte Version. Der Log-Speicher sieht eine redaktierte Version. Der LLM-Provider sieht eine redaktierte Version. Die eigene Infrastruktur muss nicht fehlerfrei sein, weil der Klartext sie niemals erreicht.
Das verändert die Platzierungsrechnung auf drei Wegen. Client-seitige Inferenz verschiebt die Trust-Boundary aus dem eigenen Rechenzentrum heraus. Ein Modell mit 50 Millionen aktiven Parametern ist klein genug, um es als Teil eines Standardbundles auszuliefern, ohne das Ladebudget einer modernen Web-App zu sprengen. Und die Apache-2.0-Lizenz erlaubt Fine-Tuning auf eigenen Domain-Daten und Re-Hosting der Weights, ohne eine kommerzielle Vereinbarung aushandeln zu müssen.
Reale Kosten bestehen: WebGPU-Support ist außerhalb von Chromium-Browsern inkonsistent, Model-Weights müssen einmal pro Cache-Bust heruntergeladen werden, und das Inferenzfenster ist durch den verfügbaren Gerätespeicher begrenzt. Für einen Compliance-Workflow in einer Desktop-Web-App sind diese Kosten vertretbar. Für eine Mobile-Webview mit aggressiver Cache-Eviction meistens nicht.
Wo das Modell in einen Agent-Governance-Stack gehört
Ein echter Agent-Governance-Stack hat klare Schichten. Das Arbeitsmodell, das bei webvise zum Einsatz kommt, sieht so aus:
- Layer 1: Ingress-Authentifizierung und Rate Limiting
- Layer 2: Data Minimization (Input Redaction)
- Layer 3: Prompt-Komposition und Context Assembly
- Layer 4: Model Inference
- Layer 5: Output Filtering (PII, Safety, Policy)
- Layer 6: Egress zu Action-Handlern, Storage, Drittanbieter-APIs
openai/privacy-filter passt klar auf Layer 2 und, mit anderer Operating-Point-Kalibrierung, auf Layer 5. Safety-Modelle, Prompt-Injection-Detektoren oder Agent-Level-Policy-Engines ersetzt es nicht. Die bisher gepflegte Regex-Bibliothek schon, mit Architektur-Eigenschaften, die regelbasierte Ansätze nicht erreichen.
| Platzierung | Trust Boundary | Wann einsetzen |
|---|---|---|
| Client-seitig (Browser + WebGPU) | Klartext verlässt das Gerät nicht | Compliance-first-Web-Apps, regulierte Branchen, interne Tools |
| Server-Middleware (Node + Transformers) | Vertrauenswürdiger Server, auditierte Logs | APIs, Backend-Agenten, Batch-Pipelines |
| Output-Filter (post-response) | Model-Output erreicht den Client nicht im Rohzustand | Chat-Agenten, generierte Inhalte, nutzerseitige RAG-Flows |
Für die meisten Client-Stacks lautet die Antwort: Layer 2 und Layer 5 in Kombination. Der browser-lokale Check verhindert, dass versehentliche PII das Context-Window überhaupt erst betritt. Der serverseitige Output-Check fängt ab, was das Modell generiert oder in seiner Antwort durchsickern lässt. Defense in depth ist das Ziel.
Wer Datenflüsse heute gegen eine Governance-Schicht mapped, spricht mit webvise über Stack-Design, bevor Entscheidungen fallen.
Die acht Kategorien und wo das Modell versagt
Die Label-Taxonomie von Privacy Filter ist statisch. Acht Kategorien plus eine Background-Class, mit BIOES-Boundary-Tags pro Kategorie.
| Kategorie | Was erkannt wird | Bekannte Fehlerquelle |
|---|---|---|
| private_person | Personennamen | Seltene Regionalnamen, Initialen, ehrentitelgeprägte Referenzen werden untererkannt |
| private_email | E-Mail-Adressen | Solide Abdeckung. Verschleierte Formate ("name at domain") können entgehen |
| private_phone | Telefonnummern | Internationale Formate zuverlässig. Nicht-standardmäßige Trennzeichen fragmentieren gelegentlich |
| private_address | Postadressen | Mehrzeilige Adressen in dichtem Layout fragmentieren an Grenzen |
| private_url | Identifizierende URLs | Over-Redaktion bei URLs öffentlicher Entitäten bei ambigem lokalem Kontext |
| private_date | Geburtsdaten, Termine | Kontextsensitiv. Kalenderdaten in Terminierungstexten werden gelegentlich over-redaktiert |
| account_number | Bank-, Kunden-, Patienten-IDs | Domainspezifische Identifier-Muster werden untererkannt |
| secret | API-Keys, Credentials, Tokens | Neue Credential-Formate und aufgeteilte Secrets werden übersehen |
Wer in der eigenen Domain Kategorien jenseits dieser Liste benötigt, muss fine-tunen. Die Model Card ist explizit: Die Label-Policy lässt sich zur Laufzeit nicht ändern. Das ist der Preis eines 50-Millionen-aktiven-Parameter-Klassifikators: Die Taxonomie ist eingebrannt. Teams, die Optionen vergleichen, finden im Leitfaden zu den besten lokalen KI-Modellen für compliance-konforme Unternehmen 2026 die General-Purpose-LLM-Seite derselben Entscheidung.
OpenAIs Model Card ist ungewöhnlich direkt. Drei Grenzen, die ernst zu nehmen sind, bevor Sie etwas ausliefern.
Englisch-first: mehrsprachige Performance
Das Modell wurde auf ausgewählten mehrsprachigen Benchmarks getestet. Die Genauigkeit sinkt bei Nicht-Latein-Schriften und bei Namenskonventionen geschützter Gruppen. Wer Kundendaten mit deutschen, polnischen oder italienischen Personennamen verarbeitet, muss mit nachlassender Trefferquote rechnen. Empfehlung: Fine-Tuning auf In-Domain-Beispielen oder ein zweiter Regex-Fallback für die kritischsten Kategorien.
Keine Anonymisierung
Das Modell ist ein Redaktionshilfsmittel, keine Anonymisierungsgarantie. Oberflächliche PII zu entfernen eliminiert kein Re-Identifikationsrisiko, wenn Quasi-Identifikatoren (PLZ, Alter, seltene Diagnose) gehäuft auftreten. Wer eine DSGVO-Anonymisierung oder HIPAA-De-Identifizierung nach der Safe-Harbor-Methode als Compliance-Pflicht hat, braucht eine dedizierte Pipeline darüber, nicht nur dieses Modell. Der Überblick zu KI-Regulierungen und Zertifizierungen in Deutschland und Europa kartiert den Regulierungsstack im Detail.
Hochsensible Workflows brauchen Menschen in der Schleife
Medizin, Recht, Finanzen, HR, Bildung, öffentliche Verwaltung: In diesen Vertikalen legen False Negatives Daten offen und False Positives entziehen Reviewern den Kontext, den sie für Entscheidungen brauchen. Privacy Filter ist in diesen Umgebungen eine Eingabe in einen Reviewprozess, kein Ersatz dafür.
Meine Regel: Privacy Filter sitzt in einem Stack mit mindestens einem weiteren Check nachgelagert. Ist es die einzige Schicht, ist man ein Modell-Update entfernt von einer Regression, die niemand bemerkt.
Meine Position zu "Agenten im offenen Web" aktualisiert
Anfang dieses Monats habe ich eine Position veröffentlicht: Für Kunden werden keine KI-Agenten ausgeliefert, die das offene Web lesen. Der Grund war konkret. Angreifer-kontrollierte Eingaben (eine gecrawlte Seite, eine nutzerseitig eingereichte URL, ein Drittanbieter-Feed) liefern dem Agenten PII, Credentials oder Prompt-Injection-Payloads, die in nachgelagerte Aktionen durchsickern.
openai/privacy-filter verändert diese Abwägung partiell. Auf der Input-Leakage-Seite stumpft ein browser-lokaler Klassifikator über gecrawlten Content, bevor er in den Prompt-Kontext eintritt, zwei spezifische Muster ab: Sensitive-Data-Exposure und Context-Poisoning via eingebetteter PII.
Den Prompt-Injection-Vektor berührt das nicht. Eine sorgfältig präparierte Seite, die dem Agenten befiehlt, seinen Speicherinhalt zu mailen, wird nicht gestoppt. Verhindert wird aber, dass diese Seite versehentlich die Heimadresse eines Kunden ins Kontext-Fenster des Modells trägt.
Die aktualisierte Position: Schmale Open-Web-Reader für nicht-sensible Workflows (öffentliche Datenaggregation, Competitive Intelligence, Marktforschung) werden nun gebaut, wenn Privacy Filter auf beiden Seiten des Modell-Calls verdrahtet ist. Für Workflows, die Kundendaten, interne Dokumente oder authentifizierte Aktionen berühren, gilt das ohne vorherigen dedizierten Red-Team-Durchlauf weiterhin nicht.
So binden Sie es ein
Zwei gängige Muster, beide direkt aus der Model Card. Die Python-Pipeline für serverseitige Redaktion:
`from transformers import pipeline; classifier = pipeline(task="token-classification", model="openai/privacy-filter"); classifier("My name is Alice Smith")`
Und die Transformers.js-Pipeline für browser-seitige Redaktion via WebGPU:
`import { pipeline } from "@huggingface/transformers"; const classifier = await pipeline("token-classification", "openai/privacy-filter", { device: "webgpu", dtype: "q4" }); await classifier(input, { aggregation_strategy: "simple" });`
Die Browser-Pipeline gehört in einen Web Worker, damit Inferenz den Main Thread nicht blockiert. Model-Weights per Service Worker cachen, damit der First-Visit-Penalty nur einmal pro Cache-Bust anfällt. Den Operating Point im Staging-Umfeld mit repräsentativen Daten justieren, bevor Production angefasst wird. Das offizielle Repository enthält die vollständige Model Card, einen Demo-Space und Fine-Tuning-Guidance.
Das Privacy-Filter-Release von OpenAI ist eine These darüber, wohin die Branche steuert: zweckgebaute, browser-ausführbare, Apache-2.0-Klassifikatoren an den Rändern des Stacks, die steuern, was LLMs sehen und was sie zurückgeben. Das ist die Form der Compliance-Arbeit, die bei webvise geleistet wird, und es ist die Form der Governance-Schicht, die den meisten Agenten heute fehlt.
Agent-Stacks ohne Data-Minimization-Schicht haben mit diesem Release einen soliden Open-Weight-Ausgangspunkt. Wer Hilfe beim Einbinden in etwas braucht, auf das Kunden in der Produktion verlässlich aufbauen können, baut webvise das.
Die Praktiken von webvise sind an den ISO 27001- und ISO 42001-Standards ausgerichtet.