OpenAI Just Open-Sourced a Privacy Filter. Here's How Lawyers Should Actually Use It.

The new open-source PII model is genuinely useful, and OpenAI's own release notes are clear that a filter is one component of safe AI use, not the whole answer. Here is what a defensible workflow actually requires.

By John Margerison · Sat, 23 May 2026 · 1820 words

You are about to paste a client's name into ChatGPT.

Maybe it's a contract dispute. Maybe it's a merger you're advising on. The brief is long, the deadline is close, and the AI genuinely helps. You've done it before. Most lawyers have. You tell yourself the risk is probably fine, the client would understand, the data probably isn't being trained on anyway. You hit paste.

That moment, the half-second of doubt before the cursor moves, is the moment this article is about.

In April 2026, OpenAI released something that could, if misread, make that doubt disappear entirely. It's called Privacy Filter. It's free, open-source under Apache 2.0, runs locally on a laptop or inside a browser, and it detects personally identifiable information across eight categories before any text reaches a server. The legal press has covered it as a breakthrough for professional privacy. Some of that coverage is right. Some of it will get lawyers into trouble.

Here is what the tool actually does, how OpenAI itself frames what it is and is not, and what a defensible AI workflow for a practising lawyer actually requires.

What Privacy Filter Is

Privacy Filter is a token-classification model in the 1.5-billion-parameter range, a Named Entity Recognition system tuned specifically for privacy. It is designed to run fast enough to be useful on ordinary hardware. It detects eight categories of sensitive data: private names, contact information such as addresses, emails and phone numbers, digital identifiers like URLs, account numbers and dates, and secrets such as credentials, API keys and passwords.

On the standard PII-Masking-300k benchmark, the model is reported in the high-96 to mid-97 percent F1 range, with the slightly higher number coming from a corrected version of the benchmark that accounts for annotation issues the model's evaluators identified. Those are genuinely strong numbers. The model is context-aware, meaning it can distinguish between a public figure's name used in a general sense and the same name appearing as a private individual in a document. It is designed to run entirely in a browser through transformers.js and WebGPU, which means the text never has to leave the device at all.

For a developer building a data pipeline, or an enterprise sanitising training data, this is a serious tool. OpenAI has indicated it uses a fine-tuned version of Privacy Filter in its own internal privacy workflows. That is not nothing.

What OpenAI Says About Where It Fits

Here is where the legal profession needs to read the release documentation, not the press coverage.

The release positions Privacy Filter as one component of a broader privacy-by-design approach. It is not framed as an anonymisation tool. It is not framed as a compliance certification. It is not framed as a substitute for policy review in high-stakes settings.

The GitHub README goes further. It names legal workflows specifically among the high-sensitivity settings where additional caution is warranted, alongside medical, financial, HR and government contexts. The same documentation flags that in these settings both false negatives and false positives can be costly. Missed spans may expose sensitive information. Excess masking can remove material context needed for review, auditing or downstream decision-making. Either failure mode hurts.

The release also notes, in the same plain way, that the model can make mistakes. It may miss uncommon identifiers or ambiguous references. It can over-redact or under-redact when context is limited.

Read alongside the headline benchmark numbers, the release notes draw an unusually clear line for any practising lawyer: a strong PII detector is not, on its own, the right answer for client-confidential work.

The 4 Percent Problem

A 96 percent F1 score sounds reassuring until you do the arithmetic on a real document.

A 5,000-word brief contains roughly 800 to 1,000 individual tokens that could carry identifying information, names, matter numbers, dates tied to specific events, account references, addresses. At 96 percent recall, the model catches approximately 96 of every 100 PII spans it encounters. The few percent it misses, the false negatives, are not random noise. They tend to cluster around exactly the identifiers that are hardest to catch: unusual surnames, internal matter codes, contextual references (the plaintiff in the Westfield transaction), and any identifier that doesn't match the training distribution.

In a 5,000-word brief, a 2-to-4 percent miss rate is not a rounding error. It is several confidential identifiers reaching the model's server unmasked.

Ask yourself: if you sent a brief to a vendor and told them you redacted it, but there is a 2-to-4 percent chance some client names got through, would your client consider that reasonable care? Would your bar association?

The Duty That Doesn't Have a Confidence Interval

Model Rule 1.6 does not say make reasonable efforts to protect client information except when the tool is 96 percent accurate. It says make reasonable efforts. Full stop.

In July 2024, the ABA's Standing Committee on Ethics and Professional Responsibility issued Formal Opinion 512, its first formal guidance on generative AI. The opinion is clear: lawyers using AI tools must fully consider their ethical obligations under rules governing competence, confidentiality, communication and fees. Under Rule 1.6, a lawyer using generative AI must be cognisant of the duty to keep confidential all information relating to the representation of a client, regardless of its source, unless the client gives informed consent.

Regardless of its source is the operative phrase. It does not matter whether the leak came from a careless email, a misconfigured cloud drive, or a 4 percent miss rate in a PII filter. The duty is the same.

The question is not whether Privacy Filter is good. It is. The question is whether a filter is a process. It isn't.

A Filter Is Not a Process

This is the gap that matters for lawyers, and it's worth being precise about it.

A filter is a technical component. It runs on text and produces masked text. It has no memory of what it missed. It generates no audit trail. It cannot document, for a bar inquiry or a client, what was redacted, when, by what version of what model, under what policy. It does not tell you whether the AI platform you're sending the masked text to stores that text, trains on it, or shares it with third parties. It does not constitute a firm policy. It is not something you can point to in a disciplinary proceeding and say, this is our AI use protocol.

A defensible AI workflow for a lawyer requires several things that a filter alone cannot provide.

First, redaction that runs before any text reaches a server, and that means client-side or on-device processing, not a cloud redaction service that itself receives the raw document.

Second, a no-server-content-path architecture. The ideal is one where the AI model sees only tokens or pseudonymised placeholders, and the real names are rehydrated locally after the AI's response comes back. The AI never holds the actual identifiers. This is architecturally different from we ran a filter first.

Third, an audit trail. Every document processed, every redaction applied, every AI query made, logged, timestamped and retrievable. Not because you expect a bar complaint, but because the ability to produce that log is itself evidence of reasonable care.

Fourth, a written policy. Something the firm can show a client, a bar association, or a court. What tools are used. What categories of matter are eligible for AI assistance. Who approved the workflow. When it was last reviewed.

Privacy Filter can be one component of that architecture, specifically the redaction layer, if deployed correctly. OpenAI's own framing of the release supports exactly that reading. But the component is not the architecture.

What a Complete Solution Looks Like

There are products built specifically for this use case. The architecture that closes the gap looks like this: redaction runs in the browser, on the user's device, before any text is transmitted. The AI platform receives only a pseudonymised version of the document, tokens like [PERSON_1] and [MATTER_REF_A] in place of actual names and identifiers. The AI drafts, summarises, or analyses against those tokens. The response comes back tokenised. The real names are rehydrated locally, in the browser, by a key that never left the device.

In this architecture, the AI server never sees the client's name. Not because a filter caught it. Because the system was designed so the server never had the opportunity to receive it. That is a meaningfully different security guarantee.

Some platforms built for legal use combine this token-substitution approach with audit logging, matter-level access controls, and documentation designed to satisfy bar requirements. They are not free. But the cost of a bar complaint, a malpractice claim, or a client relationship destroyed by a confidentiality breach is not free either.

Privacy Filter, deployed correctly as the redaction layer inside such a system, is a genuine contribution. Used as a standalone reassurance before pasting into a general-purpose AI tool, it is a false sense of security with a 96 percent confidence interval.

What You Can Do This Week

The half-second of doubt before you hit paste is not paranoia. It is your professional instinct working correctly. Here is how to act on it.

One: Read OpenAI's actual release notes for Privacy Filter, not the press summaries. The limitations section is short, specific, and written by the people who built the model. It will tell you exactly what the tool is not.

Two: Map your current AI use against ABA Formal Opinion 512. For each tool your firm uses, ask: does client data reach a third-party server? Under what terms? Is there a data processing agreement? Is there a written firm policy governing this use? If you cannot answer those questions, you have a gap, regardless of whether you are using Privacy Filter.

Three: Separate the redaction question from the architecture question. A good filter is not a substitute for a no-server-content-path design. Ask your AI vendor specifically: at what point in the process does the server receive text, and what does that text contain?

Four: Write something down. Even a one-page internal policy, what tools are approved, what categories of matter are eligible, what the redaction step is, who reviewed it, is evidence of reasonable care. A bar association or a client asking about your AI practices will be satisfied by a documented process. They will not be satisfied by we used a filter that's 96 percent accurate.

Five: Treat Privacy Filter as what it is, a useful, well-built component that belongs in a larger system. OpenAI shipped something worth using. They also framed it, in plain language, as one component of a broader privacy-by-design approach. Take them at their word.

The moment before you paste is the moment to have the right architecture in place, not the moment to decide whether the filter probably caught everything.