- OpenAI Privacy Filter detects and masks PII and secrets before the content is sent to an LLM or another external system.
- The model can run locally, allowing unredacted information to remain within the organization’s environment.
- It uses context to detect private names, addresses, emails, phone numbers, dates, URLs, account numbers, and secrets.
- The released model has 1.5 billion total parameters, with 50 million active parameters, and supports up to 128,000 tokens.
- It labels the input in a single pass instead of generating a redacted response one token at a time.
- It can support document intake, developer tooling, data-processing pipelines, and LLM workflows.
- It should supplement regex rules, secret scanners, access controls, testing, and human review, not replace them.
- Privacy Filter supports redaction and data minimization, but it does not guarantee anonymization or regulatory compliance.
Imagine this: it is 4 PM on a Friday, and you are debugging a failed CI/CD deployment. You copy a massive stack trace, paste it into an LLM to find the error, and hit Enter.
Five seconds later, your stomach drops. The log contained a live AWS access key and an internal database URL, and that information has now been sent to an external cloud provider.
These incidents are easy to imagine because developers, support teams, and business users routinely send operational data to AI systems. Stack traces may contain authentication tokens. Customer conversations may include phone numbers and email addresses. Uploaded documents may expose names, account numbers, private URLs, and other personally identifiable information (PII).
Avoiding this exposure has often depended on users noticing sensitive information before pressing Send. OpenAI Privacy Filter introduces a more systematic approach: detect and redact sensitive information locally before the content reaches an LLM or another downstream system.
OpenAI released Privacy Filter as an open-weight, context-aware model for detecting and masking PII in unstructured text. Because the model can run locally, the original unredacted content does not have to leave the organization’s environment to be sanitized.
Privacy Filter is not a complete privacy guarantee. Like any machine learning model, it can miss sensitive information or redact harmless content. Its value lies in using it as one layer within a broader privacy strategy.
This practical guide examines how the model works and demonstrates its behaviour across document intake and developer workflows.
Why PII Protection Matters in AI Workflows
LLM applications process much more than carefully written questions. They may receive medical notes, employment forms, leases, contracts, customer tickets, internal documentation, source code, deployment logs, meeting transcripts, and database records.
Sensitive information can enter an AI workflow at several points. A user may paste it directly into a chatbot. A retrieval-augmented generation system may retrieve it from a private document. An AI agent may obtain it through a connected tool. An application may also capture it in prompt logs, traces, analytics, or observability platforms.
The LLM may not need the original identifiers to complete the task. A model can explain an authentication failure without seeing the real API key. It can summarize a medical note without knowing the patient’s name or telephone number. It can classify a support request without receiving the customer’s private email address.
Redacting unnecessary identifiers before transmission follows the principle of data minimization: only provide the downstream system with the information required to complete the task.
For example, a developer does not need to send this complete message to an external model:
The request from priya@example.com failed because API key sk_test_example_12345 was rejected.A sanitized version can preserve the diagnostic meaning:
The request from [PRIVATE_EMAIL] failed because API key [SECRET] was rejected.The context remains useful, but the original sensitive values are not included.
Why Traditional PII Detection Falls Short
Traditional PII detection tools commonly rely on deterministic pattern matching. Regular expressions can be effective at finding structured information such as email addresses, phone numbers, credit card numbers, and known API-key formats.
These methods remain valuable because they are fast, predictable, and easy to audit. However, real-world text is rarely clean or consistent.
Names vary across cultures and languages. Private URLs may look similar to public links. An account number may resemble an order ID. A date could refer to a public product launch, an employee’s birth date, a medical appointment, or the beginning of a lease.
Pattern matching cannot always determine whether a value is sensitive from its format alone. It may catch jane.doe@example.com, but struggle with a private person’s name in an ordinary sentence or an unfamiliar credential embedded inside a large stack trace.
Rules also cannot reliably distinguish public information from private information. A company’s published support email may not require masking, while an employee’s direct address could be sensitive. Understanding that distinction requires surrounding context.
This is where context-aware detection can complement deterministic rules. Regex can continue to catch well-defined patterns, while a specialized model evaluates ambiguous entities within the meaning of the complete text.
What Is OpenAI Privacy Filter?
OpenAI Privacy Filter is an open-weight, bidirectional token-classification model for detecting and masking personally identifiable information in text.
It is designed for high-throughput privacy workflows and can operate locally or on premises. This means the unfiltered input can remain on the user’s device or within the organization’s infrastructure while sensitive spans are detected.
The released model has 1.5 billion total parameters but uses 50 million active parameters during processing. It also supports a context window of up to 128,000 tokens, allowing it to process long documents without relying on the small input windows common in older NLP systems.
OpenAI released the model under the Apache 2.0 licence, allowing teams to experiment with it, customize it, fine-tune it, and use it in commercial deployments.
The model is specialized for classification rather than general-purpose text generation. It does not attempt to answer the prompt or rewrite the complete document. It identifies spans that match its privacy taxonomy so that an application can mask or redact them.
What Can OpenAI Privacy Filter Detect?
Privacy Filter predicts sensitive spans across eight categories:
| Category | What it detects |
private_person | Names and references associated with private individuals |
private_address | Private residential, property, or mailing addresses |
private_email | Email addresses associated with private individuals |
private_phone | Private telephone and contact numbers |
private_url | URLs connected to private users or sensitive resources |
private_date | Dates considered private within the surrounding context |
account_number | Bank accounts, credit cards, billing accounts, and similar identifiers |
secret | Passwords, API keys, access tokens, and authentication credentials |
Not every item in this taxonomy is technically PII. An API key, for example, is a secret rather than personal information. Privacy Filter covers both because AI workflows can expose personal identifiers and operational credentials.
The model is limited to the categories and decision boundaries it was trained to recognize. An organization may also consider employee IDs, customer references, internal hostnames, proprietary project codes, or other values confidential. Those requirements may need additional rules or domain-specific fine-tuning.
How OpenAI Privacy Filter Works
Privacy Filter does not generate text token by token in the way ChatGPT produces an answer. It uses bidirectional token classification with span decoding.
The model first divides the input into tokens. A token may be a complete word, part of a word, punctuation, or another small unit of text.
It then examines the tokens and their surrounding context. Because the classifier is bidirectional, it can consider information on both sides of a token before deciding whether it belongs to a sensitive entity.
Each token receives a probability distribution across the model’s privacy labels. The model then uses constrained Viterbi decoding to combine those token-level predictions into coherent spans.
Walk away with actionable insights on AI adoption.
Limited seats available!
This additional decoding step helps prevent fragmented redaction. Instead of identifying only one part of a person’s name, address, or credential, the model attempts to mark the complete entity.
Privacy Filter uses BIOES tags to define those boundaries:
- B represents the beginning of a multi-token entity.
- I represents a token inside that entity.
- E represents the entity’s final token.
- S represents a single-token entity.
- O represents text outside a detected entity.
In practical terms, these tags help the application replace complete spans with labels such as [PRIVATE_PERSON], [PRIVATE_ADDRESS], or [SECRET] rather than masking disconnected pieces of text.
Building a Local Privacy Filter Demonstration
To understand how the model behaves in realistic workflows, we built a local interface around OpenAI Privacy Filter.
The demonstration contains three workflow views:
- Document Intake Redactor
- Developer Secret Scrubber
- LLM Gateway Demo
Each view represents a point at which sensitive information may enter an enterprise AI or data-processing system. The interface displays the original input, highlights the entities detected by the model, and produces a masked version containing category-specific placeholders.
The two examples below describe what occurred in the Document Intake Redactor and Developer Secret Scrubber demonstrations. They illustrate the model’s behaviour on these specific inputs and should not be interpreted as a guarantee that it will detect every sensitive value in every document or log.
Use Case #1: Document Intake and Compliance Workflows
If you handle medical notes, real estate leases, or HR onboarding forms, data storage is a compliance minefield. You need the general context of the document without the liability of storing the exact identifiers.
In this intake scenario, the filter acts as a sanitation layer before the data reaches the database. In this example, the model masks the patient’s name, date of recording, email address, emergency contact number, symptom-onset date, and insurance billing account while preserving the clinical notes needed for downstream analysis.
Use Case #2: Secret Detection in Developer Workflows
For most engineering teams, this may be the most immediately useful category. The secret class is one of the standout features of this release. Accidental credential leaks in logs, stack traces, and configuration snippets can create serious security risks for engineering teams.
Look closely at the highlighted vulnerabilities here. The model does not rely solely on predefined credential patterns. It can identify many credential-like strings, including API keys and authentication tokens, when they appear inside larger logs or stack traces. By running this locally in your CI/CD pipeline, you can add an additional redaction layer before logs reach observability systems, reducing the risk of accidental credential exposure.
How to Run OpenAI Privacy Filter Locally
OpenAI provides the model through its public GitHub repository and Hugging Face.
The repository can be cloned and installed locally:
git clone https://github.com/openai/privacy-filter.git
cd privacy-filter
pip install -e .After installation, the opf command can inspect and redact a short input:
opf "Alice was born on 1990-01-02."CPU execution can be selected explicitly:
opf --device cpu "Alice was born on 1990-01-02."The command-line tool can also process a file:
opf -f /path/to/input-fileIt supports piped input, allowing it to be included in local processing workflows:
cat /path/to/application.log | opfDevelopers can also load the model using the Hugging Face Transformers pipeline:
from transformers import pipeline
classifier = pipeline(
task="token-classification",
model="openai/privacy-filter",
)
result = classifier(
"Contact Alice Smith at alice@example.com.",
aggregation_strategy="simple",
)
print(result)The classifier returns detected spans, labels, confidence scores, and positions. The surrounding application is responsible for replacing those spans, selecting placeholder formats, handling uncertain results, and deciding whether a request should be allowed to continue.
Where Privacy Filter Should Sit in the Pipeline
Privacy Filter is most useful when it operates before data crosses a trust boundary.
For a direct LLM application, it can run after the user submits a prompt but before the model API is called. In a RAG system, it may run during document ingestion, after retrieval, or at both stages. In a developer workflow, it can inspect logs before they reach an AI assistant or external observability service.
Filtering during ingestion reduces the chance of sensitive values being stored in vector databases and search indexes. However, permanent redaction at this stage may remove information required for authorized internal use.
Filtering immediately before the LLM preserves the original information within approved systems while controlling what reaches the model. It does not, however, protect intermediate storage or application logs.
The correct placement depends on who needs access to the original information, why it is being processed, where copies are stored, and which systems are considered trusted. Sensitive applications may require more than one filtering layer.
Precision, Recall, and Privacy Policies
No PII detector is perfect. Teams must balance recall and precision.
Recall measures how much of the sensitive information the system finds. Higher recall reduces missed PII but may cause the model to redact more harmless text.
Precision measures how often a detected entity is genuinely sensitive. Higher precision preserves more useful content but may allow some sensitive values to remain undetected.
The appropriate balance depends on the application. A system preparing text for public release may prefer aggressive masking. A legal-review tool may require more precise redaction because removing too much context could alter the interpretation of a document.
OpenAI Privacy Filter provides operating controls that allow teams to adjust this trade-off. The correct setting should be selected using representative examples rather than relying only on benchmark results.
Testing should include regional names, local address formats, industry terminology, internal identifiers, abbreviations, multilingual content, malformed logs, and organization-specific credentials.
False negatives and false positives should also be measured separately. A single accuracy score can conceal the type of failure that poses the greatest risk to the workflow.
Performance and Benchmark Results
According to OpenAI, Privacy Filter achieved an F1 score of 96% on the PII-Masking-300k benchmark, with 94.04% precision and 98.04% recall.
OpenAI also evaluated the model on a corrected version of the benchmark after identifying annotation issues. On that version, it reported an F1 score of 97.43%, with 96.79% precision and 98.08% recall.
These results demonstrate strong performance on the evaluated datasets, but they do not guarantee identical results on an organization’s data.
Walk away with actionable insights on AI adoption.
Limited seats available!
Benchmark datasets may not reflect specialized medical language, regional identity formats, internal account structures, unusual credential patterns, or noisy documents produced by OCR. Production adoption should therefore be based on in-domain evaluation.
Limitations and Trade-Offs
Privacy Filter is a redaction and data-minimization aid. It is not an anonymization tool, privacy certification, compliance guarantee, or replacement for organizational policy.
The model can miss uncommon names, regional naming patterns, project-specific identifiers, novel credential formats, and ambiguous private references. It can also over-redact public entities, organization names, common nouns, hashes, sample credentials, or harmless strings that resemble secrets.
Its behaviour is limited by its eight-category taxonomy. If an organization considers other information sensitive, it may need to combine the model with custom rules or fine-tune it for its data and policies.
Performance may vary across languages, scripts, document types, naming conventions, and specialized domains. Short text can also be difficult because the model has less context for determining whether an entity is private.
Local execution reduces the need to send raw text to a remote redaction service, but it does not secure the entire data path. Sensitive information may still appear in application logs, temporary files, browser storage, telemetry, backups, caches, or error reports.
High-sensitivity domains such as healthcare, finance, law, human resources, education, and government require additional caution. Both missed information and unnecessary redaction can have serious consequences in these environments.
Best Practices for Production Use
Privacy Filter should be deployed as part of a layered privacy and security architecture.
Combine it with deterministic patterns for structured identifiers and known credential formats. Add organization-specific detection for employee IDs, internal URLs, customer numbers, project codes, and proprietary secrets.
Avoid logging the original input before redaction. Instead, record operational metadata such as detected categories, entity counts, processing time, model version, and the action taken by the policy layer.
Define what happens when sensitive information is found. Depending on the use case, the system may redact the value automatically, ask the user to review it, block the request, or send it for authorized human approval.
Create a labelled evaluation set using realistic examples from the intended environment. Re-run the evaluation whenever the model, thresholds, preprocessing logic, supported languages, or masking rules change.
Sensitive workflows should fail closed. If the privacy filter becomes unavailable, the application should not automatically send the unredacted content to the downstream provider.
Finally, retain human review for high-risk decisions. Automated redaction can reduce exposure at scale, but human oversight remains important when a missed or incorrectly masked entity could cause legal, financial, clinical, or personal harm.
Final Thoughts
OpenAI Privacy Filter addresses a growing challenge in enterprise AI: organizations want to use LLMs with real operational data, but that data frequently contains information the model does not need to see.
Its ability to run locally makes it useful for document intake, developer tooling, internal search, RAG pipelines, AI agents, and LLM gateways. Its context-aware architecture can also identify sensitive spans that rigid pattern matching may miss.
The practical demonstrations show how the model can preserve useful document and diagnostic context while masking detected names, addresses, contact information, dates, account numbers, private URLs, and secrets.
However, Privacy Filter should not become another “set it and forget it” security control. Reliable protection still depends on deterministic scanners, access controls, representative testing, safe logging, data-retention policies, and human review.
Used within that broader architecture, Privacy Filter moves privacy protection closer to the point where data enters an AI workflow. Instead of depending entirely on users to notice every sensitive value, teams can build data minimization directly into the pipeline before information reaches an external model.
Frequently Asked Questions
What is OpenAI Privacy Filter?
OpenAI Privacy Filter is an open-weight token-classification model that detects and masks personally identifiable information and secrets in text before the content reaches an LLM or another downstream system.
Can OpenAI Privacy Filter run locally?
Yes. It can run on local devices or within an organization’s infrastructure, allowing raw information to be inspected and masked without first sending it to a separate redaction service.
What information can Privacy Filter detect?
The model detects private people, addresses, emails, phone numbers, URLs, dates, account numbers, and secrets. Secrets can include passwords, API keys, access tokens, and other authentication credentials.
Does Privacy Filter make an LLM prompt completely safe?
No. The model may miss sensitive values or redact harmless content. It should be combined with deterministic rules, secret scanners, access controls, representative testing, secure logging, and human review.
Is Privacy Filter an anonymization tool?
No. OpenAI describes it as a redaction and data-minimization aid. Whether information is truly anonymous depends on the remaining context and whether an individual can still be re-identified.
Can Privacy Filter replace regex-based detection?
Not completely. Regex remains effective for known, structured patterns. Privacy Filter adds contextual detection, so combining both methods generally provides stronger coverage than relying on either approach alone.
Can OpenAI Privacy Filter detect API keys?
Its secret category is designed to detect credentials such as API keys, passwords, and authentication tokens. Novel or organization-specific formats may still require deterministic rules or additional fine-tuning.
Is Privacy Filter suitable for healthcare and financial data?
It may serve as one protective layer, but these are high-sensitivity environments. Organizations still need domain-specific evaluation, security controls, compliance review, clear policies, and appropriate human oversight.
Seerin
I am an AIML intern and AI enthusiast passionate about solving real-world problems using artificial intelligence and building practical, impactful solutions.
Walk away with actionable insights on AI adoption.
Limited seats available!
