OpenAI Privacy Filter: PII masking does not equal GDPR

OpenAI released a small open model for local detection and masking of personal information. Privacy Filter can clean logs, documents and prompts before they are sent to an external service. It is not an automatic process that guarantees anonymisation or GDPR compliance after one pass.

The vendor explicitly documents limitations outside English, with unusual identifiers and out-of-distribution data. European organisations need tests for their own national identifiers, addresses, inflected names and operational documents.

What OpenAI released

According to the Privacy Filter announcement, the model has 1.5 billion parameters, around 50 million active during inference, and a context window up to 128,000 tokens. It is Apache 2.0 licensed and can run locally.

It recognises eight broad categories including contact data, financial and account identifiers, document numbers and secrets such as API keys. Code is available on GitHub, and the Hugging Face model card documents usage and limitations.

OpenAI reports 96% F1 on PII-Masking-300k and 97.43% after annotation corrections. F1 combines precision and recall on that dataset. It does not mean the model finds 96% of every PII type in a real document or language.

Masking, pseudonymisation and anonymisation

Masking replaces a detected fragment. If the model misses an identifier or name, the data remains.

Pseudonymisation separates identity from data while allowing relinking with additional information. It remains personal data under GDPR.

Anonymisation requires that identifying a person is not reasonably possible, including through combination with other data. Removing a name is inadequate when job title, date, small location and a unique event identify the person.

Privacy Filter assists masking. It does not automatically evaluate reidentification risk across a dataset or issue a compliance certificate.

Where local filtering helps

cleaning logs and support tickets before external LLM analysis;
redacting documents for test environments;
detecting API keys and contact data at scale;
supporting DSAR or e-discovery with human review;
adding a DLP layer to a RAG ingestion pipeline.

Local execution reduces the need to send raw content to another provider. The local service still needs protection: temporary files, cache, logs, telemetry and administrator access may contain originals.

Building a representative test set

Use synthetic or lawfully protected samples covering national identifiers, tax numbers, IBANs, documents, phone numbers and addresses.
Include inflection, diacritics, abbreviations and typographical errors.
Add indirect identifiers such as role, small location and event date.
Measure recall per category; overall F1 can hide a weak result for one sensitive identifier.
Measure false positives so redaction does not destroy incident or customer-service evidence.
Add deterministic validation such as checksums and structured identifier patterns.
Require human review for legal, medical, employment and other high-risk material.
Retest after model, tokenizer, prompt and document-format changes.

Safer pipeline architecture

Minimise data at source. Run deterministic rules and Privacy Filter locally, validate the result, then send only cleaned content to the target model. Retain a replacement map only when necessary; encrypt it and separate access.

Do not keep full prompts indefinitely for debugging. Monitor output too, because a downstream model can reconstruct sensitive information from its knowledge source. Apply the broader controls in our AI security guide and GDPR technical security measures.

Privacy Filter is a useful local component with an open licence, long context and broad entity coverage. Its strength is reducing exposure before data leaves the organisation. Safe deployment still requires deterministic rules, a representative local-language test set, human review, minimisation and protection of the complete pipeline.

Sources: OpenAI announcement, GitHub repository, Hugging Face model card.