OpenAI just released Privacy Filter, a bidirectional token-classification model for personally identifiable information detection and masking, under the Apache 2.0 license. It sits on Hugging Face and GitHub, weighs 1.5 billion parameters (50 million active thanks to mixture-of-experts routing), and runs on a laptop. Or in a browser. No API call required.
That last part is the whole point.
What Was Announced
Privacy Filter scans text in a single forward pass and tags eight categories of PII: names, addresses, emails, phone numbers, URLs, dates, account numbers, and secrets (think API keys and passwords). It uses a BIOES span-tagging scheme — Begin, Inside, Outside, End, Single — decoded through a constrained Viterbi procedure rather than naive per-token argmax, which means it produces coherent redaction boundaries instead of fragmenting "123 Main Street" into three separate entities.
The model is architecturally a smaller sibling of gpt-oss, OpenAI's open-weight reasoning models released last August. It starts from an autoregressive pretrained checkpoint, replaces the language model head with a 33-class token-classification head, converts causal attention to bidirectional banded attention (window of 257 tokens), and post-trains with supervised classification loss. The feed-forward layers use sparse MoE with 128 experts and top-4 routing — that's where the 1.5B total / 50M active split comes from.
It ships with a CLI tool (opf) that supports one-shot redaction, piped input, interactive mode, evaluation on labeled datasets, and fine-tuning. The context window is 128K tokens.
What's Actually New Here
PII detection is not a new problem. Microsoft Presidio has been open-source for years. Amazon Comprehend offers managed PII detection. Private AI, Protecto, and a constellation of startups sell this as a service. Regex-based pattern matching can catch phone numbers and emails all day long.
What's different about Privacy Filter is the combination of three things:
First, it's context-aware in a way that regex and even older NER models are not. The model reads the surrounding sentence to decide whether "Annie" is a private name or a brand, and whether "123 Main Street" is someone's home address or a business storefront. The model card includes synthetic evaluations showing that contextual clues before a PII span push overall recall from 58.4% to 86.3%. Without any contextual clue at all — just the raw PII value with no surrounding sentence — recall drops hard. The model is genuinely reading, not pattern-matching.
Second, it's absurdly small for what it does. Fifty million active parameters means this isn't competing for your GPU budget with your actual inference workloads. It fits into a browser via ONNX or Transformers.js. The Hugging Face community is already asking for GGUF quantization, and within hours of release, Hugging Face staff member Merve Noyan submitted a PR to update the model metadata for better discoverability — standard playbook when something is going to get real traction.
Third, it's fine-tunable with very little data. OpenAI's own eval shows that training on just 10% of a domain-specific dataset (the SPY benchmark of synthetic medical and legal text) drives F1 from 54.5% to 96.2%. That's the jump from "useless in production" to "worth deploying" with a small labeled dataset.
Why This Matters for Builders
If you're building anything that processes user text before sending it to an LLM — a customer support pipeline, a document summarizer, a RAG system — you now have a drop-in component that strips PII locally before data leaves your infrastructure.
The deployment story is straightforward:
pip install -e .
opf "Alice was born on 1990-01-02."
Output: <PRIVATE_PERSON> was born on <PRIVATE_DATE>.
You can pipe files through it, run it on CPU with --device cpu, and tune the precision/recall tradeoff at runtime through Viterbi decoder parameters. If your compliance team wants aggressive redaction (high recall, more false positives), you dial one way. If your NLP pipeline downstream needs cleaner text (high precision, risk of missed PII), you dial the other way.
For enterprises already running gpt-oss models on-prem, this slots right into the same infrastructure story. Same Apache 2.0 license. Same architectural family. Same fine-tuning toolkit pattern. OpenAI is building an ecosystem of open-weight components that work together, and Privacy Filter is a utility layer that makes the rest of the stack more deployable in regulated environments.
The 128K context window matters too. Most PII detection tools either chunk long documents or have short context limits that create boundary artifacts. Privacy Filter processes your entire document in one pass. For anyone working with long-form content — legal documents, medical records, support transcripts — that's a meaningful practical advantage.
What's Questionable or Unclear
Let's start with the benchmark numbers. OpenAI reports 96% F1 on the PII-Masking-300k dataset, then says a "corrected" version pushes it to 97.4%. The correction process involved using GPT-5.4 with high reasoning to adjudicate spans that Privacy Filter detected but the benchmark didn't label — essentially using one OpenAI model to validate another OpenAI model. Human reviewers verified 100 of roughly 10,000 disputed spans and found 100% agreement. That's a 1% sample. It's not nothing, but it's also not the kind of rigorous third-party validation that makes you stop worrying.
The multilingual story is thin. The model card says "primarily English" and the eval data backs that up. On European languages in PII-Masking-300k, F1 ranges from 91.4% (Dutch) to 93.4% (English). On synthetic multilingual data including Arabic, Bengali, Hausa, and others, F1 drops to 75.8%–93.3%. For Korean, precision craters to 65.1% on the category-clue eval. If your user base isn't primarily English-speaking, you're going to need significant fine-tuning work, and OpenAI's model card is honest about this.
The adversarial eval results are sobering. When PII is formatted with phonetic alphabet spelling, precision drops to 27.3%. Line breaks in URLs produce false-positive name detections. These are not exotic attack vectors — they're formatting artifacts you'd find in any messy enterprise dataset. The model card transparently documents these failure modes, which is commendable, but it means production deployment requires careful evaluation on your actual data distribution.
There's also the irony worth naming: OpenAI, a company that has faced repeated criticism and regulatory scrutiny over how it handles user data in training, is now releasing the tool to scrub PII from text. The model card states that Privacy Filter's training data included outputs annotated by "a frontier model in the GPT-5 family" — meaning the training pipeline itself routes data through OpenAI's proprietary models. The open-source artifact runs locally, but the process that created it did not.
And with only 8 entity categories, the label taxonomy is intentionally narrow. There's no category for social security numbers, passport numbers, biometric data, medical record numbers, or IP addresses (URLs catch some of these, but not all). OpenAI's answer is fine-tuning, but that shifts the burden to every deploying team to build and label their own domain-specific datasets.
The Bigger Picture
Privacy Filter fits into a pattern that's been accelerating since the gpt-oss release last summer: OpenAI is building a stack of open-weight models that together form a compelling reason for enterprises to build on OpenAI infrastructure — proprietary or open.
The strategic logic is clear. The biggest objection enterprises have to sending data to LLM APIs is privacy. If OpenAI provides the PII-stripping layer and the inference layer and the fine-tuning layer, all under Apache 2.0, the friction to adoption drops significantly. Privacy Filter isn't a revenue product — it's a trust-building component that makes the revenue products easier to sell.
This also puts pressure on Microsoft Presidio, which has been the default open-source PII tool for years but relies on regex + traditional NER rather than a transformer classifier. Presidio is more extensible in terms of entity types and supports images. But Privacy Filter's context-awareness and single-pass architecture offer a fundamentally different performance envelope for text workloads.
For the broader open-source AI ecosystem, the interesting signal is that OpenAI is not just releasing general-purpose language models anymore. They're releasing task-specific utility models — small, efficient, production-oriented — that solve the infrastructure problems standing between their technology and enterprise deployment. That's a different kind of open-source strategy than Hugging Face's "publish everything" approach or Meta's "release Llama and let the community figure it out" approach. It's more like Red Hat: open-source the components that grow the market for your premium services.
Whether that trade is worth it depends on your threat model. If your concern is "I don't want raw PII hitting an LLM API," Privacy Filter genuinely solves that problem. If your concern is "I don't want to build my privacy infrastructure on tooling provided by a company whose business model depends on processing my data," then the Apache 2.0 license means you can fork it and never look back.
Either way, the model is real, it's small, it's fast, and 96% F1 out of the box is a legitimate starting point.