Reversible PII redaction, explained

The problem with ordinary redaction

Classic redaction is destructive. A name becomes a black bar, and the black bar is permanent. That is correct for a document being released under disclosure and wrong for a prompt, because the reply you get back is addressed to a black bar. Ask a model to draft a letter to [REDACTED] about invoice [REDACTED] and you get a template you now have to fill in by hand — which is the work you were trying to avoid.

So users do the rational thing and turn the redaction off. A control that makes the tool useless does not get used.

The mechanism

Reversible redaction replaces each sensitive value with a stable, typed placeholder and keeps the mapping locally.

Detect. As text is composed, pattern and context matching flags entities: names, emails, phone numbers, national IDs, card numbers, addresses, dates, monetary amounts, account and invoice references, API keys.
Confirm. Each detection is shown to the user, who can accept it or mark it public. Detection suggests; it does not decide.
Substitute. Each confirmed value is replaced with a typed token — [REDACTED_PERSON_01], [REDACTED_MONEY_01] — and the token-to-value map is held in local memory.
Send. Only the substituted text is transmitted. The model sees structure, not identity.
Restore. The reply comes back containing the same tokens. They are swapped for the real values on the device, before the user sees the text.

Why the model does not need the real values

Language models operate on structure and relation, not on the literal identity of an entity. "Draft a dispute letter for [REDACTED_PERSON_01] regarding [REDACTED_MONEY_01] charged on [REDACTED_DATE_01]" contains everything the model needs to produce the letter. Typed tokens preserve the grammatical role and the semantic category; the model conjugates around them correctly. Restoring afterwards yields the same output you would have received had you sent the real data — because for the purposes of the task, you did.

Where the mapping lives

This is the part that matters and the part most easily got wrong. If the token map is stored on a server, that server now holds a decryption key for every prompt your organisation has ever sent, and you have concentrated the risk instead of removing it. In a correct implementation the map exists only in memory on the user's own device, for the lifetime of the exchange. There is no cloud component that could be subpoenaed, breached or misconfigured, because there is nothing there.

What it costs

Detection, substitution and restoration together add roughly 68 milliseconds — below the threshold at which a person notices a delay. For organisations that cannot send anything at all, the same pipeline runs against a fully local model with no network component.

Watch the substitution and restore happen on text you type yourself.

See it on your own data.

A 30-minute walkthrough of detection, redaction and restore on the kind of documents your team actually handles.

Book a demo