OpenAI Privacy Filter: Das Open-Weight-PII-Modell, das in Ihrem Browser läuft (und wo es in einen Agent-Stack gehört)

OpenAI hat gerade ein Werkzeug geliefert, kein Modell. openai/privacy-filter ist ein bidirektionaler Token-Classifier mit 1.5 Milliarden Parametern, veröffentlicht unter Apache 2.0, der in Ihrem Browser läuft, acht Kategorien personenbezogener Daten in einem einzigen Forward Pass erkennt und die Governance-Schicht schließt, die die meisten Agent-Stacks überspringen.

Wer die Release Notes als weiteren Modell-Drop liest, verpasst das eigentliche Signal.

Wenn Sie heute Agents auf Kundendaten betreiben, ist PII-Redaktion wahrscheinlich eine Regex-Bibliothek, die Sie pflegen, oder ein LLM-Aufruf, für den Sie lieber nicht zahlen würden. Dieser Artikel beschreibt, was openai/privacy-filter tatsächlich ist, welche architektonischen Entscheidungen wichtig sind und wo es in einen echten Agent-Governance-Stack gehört. Außerdem erklären wir, warum dieses Release unsere Position zu Agents, die nicht vertrauenswürdige Eingaben lesen, aktualisiert, und was Sie damit tun sollten, wenn Sie regulierte Workloads ausliefern.

Wichtigste Erkenntnisse

• openai/privacy-filter ist ein zweckgebundener Classifier, kein allgemeines LLM. 1.5 Milliarden Parameter insgesamt, 50 Millionen aktiv über MoE Routing, 128.000-Token-Kontext, Apache 2.0 Lizenz.

• Die Architektur leitet sich aus der gpt-oss-Linie ab. Der Language-Model-Head wird durch einen 33-Klassen-BIOES-Token-Classification-Head ersetzt. Dekodierung mit eingeschränktem Viterbi für Span-Kohärenz.

• Läuft in einem Browser-Tab über Transformers.js und WebGPU. Kein API-Round-Trip, kein Server-Egress, zur Laufzeit kein OpenAI-Konto erforderlich.

• Erkennt acht PII-Kategorien: private_person, private_email, private_phone, private_address, private_url, private_date, account_number, secret.

• Keine Anonymisierung. English-first mit vermindertem Recall bei nicht-lateinischen Schriften. Statische Label-Taxonomie, die für Erweiterungen Fine-Tuning erfordert.

OpenAI hat ein Werkzeug geliefert, kein Modell. Das ist die Nachricht.

Die meisten Medien werden dies als weiteren OpenAI-Drop auf Hugging Face melden. Das architektonische Signal ist ein anderes. Dies ist ein bidirektionaler Classifier, der aus einem autoregressionalen gpt-oss-Checkpoint post-trainiert wurde, wobei der Language-Model-Head gegen einen 33-Klassen-Token-Classification-Head über acht Privacy-Span-Kategorien plus eine Background-Klasse ausgetauscht wurde.

OpenAI veröffentlicht kein Modell zum Chatten. Sie haben ein Werkzeug veröffentlicht, das Eingaben und Ausgaben anderer Modelle filtert.

Das ist bedeutsam, weil die Branche drei Jahre damit verbracht hat, generative LLMs als Standardprimitive für jedes Textproblem zu behandeln, einschließlich solcher, für die LLMs schlecht geeignet sind. PII-Redaktion ist ein Klassifikationsproblem. Ein allgemeines 70-Milliarden-Parameter-Modell auf jede eingehende Anfrage anzusetzen und es freundlich zu bitten, E-Mail-Adressen zu maskieren, ist ein teurer Umweg. Ein 1.5-Milliarden-Parameter-Classifier mit 50 Millionen aktiven MoE-Parametern erledigt dieselbe Aufgabe in einem Forward Pass, läuft auf einem Laptop und kann keine neuen E-Mail-Adressen halluzinieren.

Die Entscheidung, dies von gpt-oss abzuleiten, ist der Teil, der zu wenig berichtet wird. OpenAI signalisiert, dass die gpt-oss-Familie keine einmalige PR-Maßnahme ist. Sie wird zur Grundlage für zweckgebundene Hilfsmodelle, die Behörden und Engineering-Teams lokal betreiben sollen. Erwarten Sie mehr davon.

Wenn Sie einen Agent-Governance-Stack für einen regulierten Workload evaluieren, entwickelt webvise compliance-konforme Stacks von Grund auf.

Die Architektur in verständlicher Sprache

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-Experten-Sparse-MoE-Feed-Forward-Block mit Top-4-Routing. Die Residual-Stream-Breite beträgt 640. Die Gesamtparameter liegen bei 1.5 Milliarden, die aktiven Parameter pro Token bei 50 Millionen.

Es verwendet Banded Attention mit einer Bandbreite von 128, was ein effektives Fenster von 257 Token ergibt. Die Kontextlänge ist auf 128.000 Token begrenzt, was Chunking bei typischen Langdokument-Workloads überflüssig macht.

Der Labeling-Head gibt 33 Logits pro Token aus: ein Background-Label plus acht Span-Kategorien, die in BIOES-Tags (Begin, Inside, End, Single) aufgeteilt werden. Inference führt einen eingeschränkten Viterbi-Decoder mit Linear-Chain-Transition-Scoring über vollständige Label-Pfade aus. Sechs Transition-Bias-Parameter steuern Background-Persistenz, Span-Einstieg, Fortsetzung, Abschluss und Boundary-to-Boundary-Übergabe. Der praktische Effekt ist, dass Span-Grenzen in gemischt formatiertem Text kohärent bleiben, wo unabhängiges Argmax-Decoding fragmentiert.

Laufzeit-Betriebspunkte ermöglichen es Ihnen, den Präzision-versus-Recall-Kompromiss ohne Retraining anzupassen. Bias in Richtung Span-Einstieg und Fortsetzung für Über-Redaktion (compliance-freundlich, mehr Rauschen). Bias in Richtung Background-Persistenz für Unter-Redaktion (erhält Kontext, birgt Leckagenrisiko). Die vollständige Model Card einschließlich Evaluierungsmethodik finden Sie unter huggingface.co/openai/privacy-filter.

Warum die Browser-Ausführbarkeit die Platzierungsentscheidung verändert

Die meisten PII-Redaktions-Middlewares laufen serverseitig. Daten werden im Klartext übertragen, treffen auf einen Redaktionsdienst, werden bereinigt und gelangen dann zur Modell-API. Jeder Schritt fügt Latenz, Kosten und einen Punkt hinzu, an dem die Klartextversion in Logs verweilt.

Privacy Filter läuft in einem Browser-Tab über Transformers.js mit WebGPU und q4-Quantisierung. Die Implikation: Sie können die Eingabe des Nutzers in seinem eigenen Browser redaktieren, bevor der Text das Gerät verlässt.

Der Server sieht eine redaktierte Version. Der Log-Speicher sieht eine redaktierte Version. Der LLM-Anbieter sieht eine redaktierte Version. Sie müssen Ihrer eigenen Infrastruktur nicht vertrauen, perfekt zu sein, weil der Klartext sie nie erreicht.

Das verändert die Platzierungskalkulation auf drei Arten. Client-seitige Inference verschiebt die Trust-Boundary aus Ihrem Rechenzentrum heraus. Ein 50-Millionen-aktiv-Parameter-Modell ist klein genug, um als Teil eines Standardbundles ausgeliefert zu werden, ohne das Ladebudget einer modernen Web-App zu sprengen. Und die Apache 2.0 Lizenz bedeutet, dass Sie auf Ihren eigenen Domaindaten Fine-Tuning betreiben und Gewichte ohne kommerziellen Vertragsabschluss neu hosten können.

Es gibt echte Kosten. WebGPU-Unterstützung ist außerhalb von Chromium-Browsern inkonsistent, Modellgewichte müssen einmal pro Cache-Bust heruntergeladen werden, und das Inference-Fenster ist durch den verfügbaren Gerätespeicher begrenzt. Für einen Compliance-Workflow über eine Desktop-Web-App sind diese Kosten akzeptabel. Für eine mobile Webview mit aggressiver Cache-Eviction sind sie es in der Regel nicht.

Wo dies in einen Agent-Governance-Stack gehört

Ein echter Agent-Governance-Stack hat verschiedene Schichten. Das Arbeitsmodell, das wir bei webvise verwenden, sieht so aus:

• Schicht 1: Ingress-Authentifizierung und Rate Limiting

• Schicht 2: Datensparsamkeit (Input-Redaktion)

• Schicht 3: Prompt-Komposition und Kontext-Assemblierung

• Schicht 4: Model Inference

• Schicht 5: Output-Filterung (PII, Sicherheit, Richtlinien)

• Schicht 6: Egress zu Action-Handlern, Storage, Drittanbieter-APIs

openai/privacy-filter passt sauber in Schicht 2 und, mit anderer Betriebspunkt-Kalibrierung, in Schicht 5. Es ersetzt keine Safety-Modelle, Prompt-Injection-Detektoren oder agentenseitige Policy-Engines. Es ersetzt die Regex-Bibliothek, die Sie bisher gepflegt haben, und tut dies mit architektonischen Eigenschaften, die regelbasierte Ansätze nicht erreichen können.

Für die meisten Client-Stacks, die wir entwerfen, lautet die Antwort: Schichten 2 und 5 in Kombination. Die browser-lokale Prüfung verhindert, dass versehentliche PII überhaupt in das Kontextfenster gelangt. Die serverseitige Output-Prüfung fängt alles ab, was das Modell generiert oder in seiner Antwort preisgibt. Defense in Depth ist der Punkt.

Wenn Sie Ihre Datenflüsse heute gegen eine Governance-Schicht abbilden, sprechen Sie mit webvise über Stack-Design, bevor Sie sich festlegen.

Die acht Kategorien und wo das Modell versagt

Die Label-Taxonomie von Privacy Filter ist statisch. Acht Kategorien plus eine Background-Klasse, mit BIOES-Grenz-Tags pro Kategorie.

Wenn Ihre Domäne Kategorien außerhalb dieser Liste enthält, betreiben Sie Fine-Tuning. Die Model Card ist explizit: Die Label-Richtlinie lässt sich zur Laufzeit nicht ändern. Das ist der Preis eines 50-Millionen-aktiv-Parameter-Classifiers: Die Taxonomie ist eingebaut. Für Teams, die Optionen vergleichen, behandelt unser Leitfaden zu den besten lokalen KI-Modellen für compliance-konforme Unternehmen 2026 die allgemeine LLM-Seite derselben Entscheidung.

OpenAIs Model Card ist ungewöhnlich direkt. Drei Grenzen, die Sie ernst nehmen sollten, bevor Sie ausliefern.

English-first, nicht mehrsprachig

Das Modell wurde auf ausgewählten mehrsprachigen Benchmarks getestet, aber die Genauigkeit sinkt bei nicht-lateinischen Schriften und Namenskonventionen geschützter Gruppen. Wenn Sie an einen Kunden mit deutschen, polnischen oder italienischen personenbezogenen Daten liefern, ist mit vermindertem Recall zu rechnen. Betreiben Sie Fine-Tuning mit domäneninternen Beispielen oder setzen Sie einen Regex-Fallback für die wichtigsten Kategorien als zweiten Durchlauf ein.

Keine Anonymisierung

Dies ist ein Redaktionshilfsmittel, keine Anonymisierungsgarantie. Das Entfernen von oberflächlicher PII eliminiert nicht das Re-Identifikationsrisiko, wenn Quasi-Identifikatoren (Postleitzahl, Alter, seltene Diagnose) zusammengehäuft auftreten. Wenn Ihre Compliance-Pflicht DSGVO-Anonymisierung oder HIPAA-De-Identifizierung nach der Safe-Harbor-Methode ist, benötigen Sie eine dedizierte Pipeline zusätzlich dazu, nicht diese allein. Unser Beitrag zu KI-Vorschriften und Zertifizierungen in Deutschland und Europa kartiert den regulatorischen Stack im Detail.

Hochsensible Workflows erfordern Menschen im Entscheidungsprozess

Medizin, Recht, Finanzen, HR, Bildung, öffentliche Verwaltung. In diesen Bereichen legen False Negatives Daten offen, und False Positives entfernen Kontext, den Prüfer für Entscheidungen benötigen. Privacy Filter ist in diesen Einstellungen eine Eingabe für einen Überprüfungsprozess, kein Ersatz dafür.

Unsere Regel: Privacy Filter sitzt in einem Stack mit mindestens einer weiteren Prüfung nachgelagert. Wenn es die einzige Schicht ist, sind Sie einen Modell-Update von einer Regression entfernt, die niemand bemerkt.

Aktualisierung unserer Position zu Agents im offenen Web

Anfang dieses Monats haben wir eine Position veröffentlicht: webvise wird keine KI-Agents ausliefern, die das offene Web für Kunden lesen. Der Grund war konkret. Angreifer-kontrollierte Eingaben (eine gescrapte Seite, eine vom Nutzer eingereichte URL, ein Drittanbieter-Feed) geben dem Agent PII, Zugangsdaten oder Prompt-Injection-Payloads, die durch nachgelagerte Aktionen durchsickern.

openai/privacy-filter verändert diese Kalkulation teilweise. Auf der Seite der Eingabe-Leckage: Einen browser-lokalen Classifier über gescrapten Inhalt laufen zu lassen, bevor er in den Prompt-Kontext eintritt, stumpft zwei spezifische Muster ab: Exposition sensibler Daten und Kontext-Vergiftung durch eingebettete PII.

Den Prompt-Injection-Vektor berührt es nicht. Es verhindert nicht, dass eine sorgfältig gestaltete Seite den Agent anweist, seinen Speicherinhalt per E-Mail zu versenden. Es verhindert, dass diese Seite versehentlich die Heimadresse eines Kunden in das Kontextfenster des Modells trägt.

Die Positionsaktualisierung: Wir werden nun schmale Open-Web-Leser für nicht-sensible Workflows (öffentliche Datenaggregation, Wettbewerbsintelligenz, Marktforschung) ausliefern, wenn Privacy Filter auf beiden Seiten des Modell-Aufrufs eingebunden ist. Wir werden sie weiterhin nicht für Workflows ausliefern, die Kundendaten, interne Dokumente oder authentifizierte Aktionen berühren, ohne einen dedizierten Red-Team-Durchlauf.

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 über 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" });`

Platzieren Sie die Browser-Pipeline in einem Web Worker, damit Inference den Main Thread nicht blockiert. Cachen Sie die Modellgewichte mit einem Service Worker, damit der Erstbesuchsaufwand nur einmal pro Cache-Bust anfällt. Stimmen Sie den Betriebspunkt im Staging mit repräsentativen Daten ab, bevor Sie die Produktion anfassen. Das offizielle Repository enthält die vollständige Model Card, den Demo-Space und Fine-Tuning-Anleitungen.

OpenAIs privacy-filter-Release ist kein Modell. Es ist eine These darüber, wohin sich die Branche entwickelt: zweckgebundene, browser-ausführbare, Apache 2.0 Classifier, die an den Rändern Ihres Stacks laufen und kontrollieren, was Ihre LLMs sehen und was sie zurückgeben. Das ist die Form der Compliance-Arbeit, die wir bei webvise leisten, und es ist die Form der Governance-Schicht, die den meisten Agents heute fehlt.

Wenn Ihr Agent-Stack keine Datensparsamkeits-Schicht hat, ist dies das Release, auf dem Sie diese Schicht aufbauen sollten. Wenn Sie Hilfe dabei benötigen, es in etwas einzubinden, auf dem Kunden in der Produktion tatsächlich stehen können, baut webvise das.