PII redaction, explained

PII redaction is the removal or masking of personally identifiable information from text before that text goes somewhere you do not fully control. The term comes from document redaction, the black bars on a released government file. Applied to AI, it means one specific thing: the names, numbers and identifiers in your prompt are replaced before the prompt reaches the model, so the model can do its work without ever seeing who the text is about.

This page explains how that works, where the common approaches differ, and what to check before trusting any tool with the job.

What counts as PII in a prompt

PII is broader than most people assume. The obvious items are names, email addresses, phone numbers and government identifiers. But a prompt pasted from real work usually carries more than that: account numbers, case references, addresses, dates of birth, medical details, salary figures, IP addresses, and the kind of contextual detail that identifies a person even with the name removed. A date of birth plus a job title plus a town is often enough to identify someone. Regulators treat it that way, and so should a redaction tool.

The practical test is not "is there a name in this text" but "could a person be identified from what remains". That is why serious tools detect dozens of entity types rather than three, and why detection quality is measurable rather than a matter of opinion.

One-way redaction and its problem

The oldest approach deletes or blacks out the sensitive spans and leaves the rest. That works for publishing a document. It works badly for AI, because the reply comes back full of holes. Ask a model to draft a letter about a redacted contract and it will produce a letter about [REDACTED], which you then repair by hand. The tool protected the data by destroying the usefulness of the answer.

One-way redaction still has a place when text will be stored or published and never needs to be read in full again. For working with an assistant, it is the wrong shape.

Reversible masking: tokenized and pseudonymized

The alternative is masking that can be undone after the reply comes back. The sensitive span is replaced with a stand-in, the model works on the stand-in, and the stand-in is swapped back for the original in the answer. Two families exist, and they trade off differently.

Tokenized masking replaces each entity with an opaque token such as ⟦PERSON_1⟧. The same person becomes the same token everywhere, so the model can still reason about who did what. Tokens are visibly artificial, which is a feature: you can see at a glance that the text is protected, and the reverse step can tolerate a model that rephrases or reorders the token.

Pseudonymized masking replaces each entity with a fake but format-valid value: a different name, a plausible IBAN, a date shifted consistently. The text stays natural, which some models handle better, and the output is safe to show to someone who should not know the text was masked at all. The cost is that reversal must be exact, and a reader cannot tell protected text from raw text by looking.

Neither is simply better. Tokenized is more robust and more visible; pseudonymized is more natural and more discreet. A good tool offers both and lets the situation decide.

Where the redaction runs decides what it protects

Every property above is secondary to one question: does the raw text leave your machine before the masking happens?

A redaction service that runs in a vendor's cloud must receive your unredacted text to redact it. Whatever it strips afterwards, the vendor's infrastructure saw the original. That can be an acceptable trade inside a data processing agreement, but it is not the same promise as the text never leaving. If the point of redaction is that third parties never see the raw data, a third-party server in the redaction path defeats the point.

On-device redaction closes that gap structurally. The detection and masking run locally, and only masked text ever crosses the network. The claim is testable rather than contractual: cut the network connection and see whether masking still works, or watch the process with a connection monitor. A tool that keeps working offline was never sending your text anywhere.

How to evaluate a PII redaction tool

Six questions separate the field quickly.

1. Where does processing happen? On your device, or on the vendor's servers? If the answer is unclear in the documentation, assume the server.
2. Is the masking reversible? Can the tool restore the original details in the model's reply, or does it only delete?
3. What does it detect, and how well? Entity types, languages, and ideally published numbers. Detection quality varies enormously and is measurable; a vendor that publishes precision and recall is inviting you to check.
4. Does it work offline? The sharpest single test of every privacy claim in this list.
5. What is retained? Mappings between originals and stand-ins are sensitive in themselves. Where are they stored, and who can read them?
6. Can the claims be inspected? Source availability, enumerated network behaviour, and reproducible benchmarks all beat a policy page.

For how these criteria play out across real tools, see the honest surveys on the blog: the browser extension field, Velum against Microsoft Presidio for engineering teams, and cloud DLP APIs against on-device masking. The trade-offs between the two masking styles get their own piece in tokenized vs pseudonymized masking.

Looking for a local PII anonymizer?

"PII anonymizer" is the phrase most people type for a tool that strips or replaces personal information before data reaches an LLM. It usually means the job described above, but the word carries a specific meaning that is worth separating from the marketing use.

Anonymisation in the regulatory sense is irreversible. Once text is anonymised, nobody can recover the original values, including you. Reversible masking is pseudonymisation, and pseudonymised data is still personal data under the GDPR. Any tool that promises both perfect reversal and true anonymisation is describing two different things with one word.

Both are useful, for different jobs. When you are working with an assistant and need the answer to make sense, reversible masking is what you want: values are replaced on your device before the prompt leaves, and restored in the reply. When a document has to be sanitised for good, before it is filed, shared or published, permanent redaction is the irreversible option, with no mapping kept anywhere.

Velum does both. It masks reversibly for AI work, and redacts permanently for documents that should never carry the values again. Detection and replacement run on your own machine in both cases, which is the part that matters most: a service that anonymises your text on someone else's server has already received the text it was meant to protect.

How Velum does it

Velum is a PII masking tool built around the on-device answer to question one. Detection and masking run entirely on your machine: a regex floor that needs no model, plus an optional on-device NER model with country-specific packs for Spain, the US, UK, France, Germany, Turkey and Italy. Both masking modes described above are supported, tokenized and pseudonymized, and both are reversible, so the model's reply comes back with the real details restored.

The browser extension does the whole round trip with no network access at all. The desktop app makes a short list of enumerated outbound calls, none carrying document content, and lists them in its own interface so the behaviour can be checked rather than believed. Detection quality is measured and published on the benchmarks page, including what gets through.