A support agent pastes a customer's message into an AI assistant to draft a reply. The message contains a full name, an email address, an order number, and a phone number. That data has now left your infrastructure and reached a third party under whatever terms you agreed to, and quite possibly under terms nobody in the room has read.
Redaction sits between the two: strip identifying values before the request leaves, restore them in the response. Simple to describe and full of details that determine whether the result is useful or nonsense.
What changed in 2026
- Enterprise tiers made the calculus clearer. Contractual exclusion from training became the standard business offering, which shifted redaction from a necessity to a defence-in-depth layer for many teams.
- Recognition models improved. Named entity recognition for people, places, and organisations got good enough to catch what regular expressions structurally cannot.
- Rehydration became standard practice. Round-tripping placeholders so the end user sees real values, rather than a redacted response, moved from clever trick to expected behaviour.
- Logs got attention. Teams realised prompts land in their own observability stack too, so redaction had to cover internal logging as well as the outbound call.
Redact without destroying meaning
The naive approach replaces sensitive values with a fixed marker: [REDACTED]. It also destroys the model's ability to reason about the text.
"[REDACTED] emailed [REDACTED] about [REDACTED]" is unusable. The model cannot tell people from products, cannot track who did what, and cannot produce a coherent reply.
Typed, numbered placeholders preserve the structure: "[PERSON_1] emailed [EMAIL_1] about [ORDER_ID_1]". Now the model knows there is a person, an email, and an order reference, and — critically — that the same placeholder appearing twice means the same entity. It can write a reply that references them correctly.
Consistency within a request is what makes this work. Every occurrence of the same value maps to the same placeholder, so coreference survives.
| Approach |
Model comprehension |
Rehydration |
Verdict |
| Delete the value |
Poor |
Impossible |
Avoid |
Fixed [REDACTED] |
Poor |
Impossible |
Avoid |
| Typed placeholder |
Good |
Straightforward |
Default |
| Realistic fake data |
Best |
Requires a map |
Good, riskier |
| Hashing |
Poor |
Possible |
Rarely worth it |
Substituting realistic fake values — a plausible name instead of [PERSON_1] — reads most naturally to the model. The risk is that the output looks entirely real, so a failure to rehydrate produces a response containing a convincing wrong name rather than an obvious placeholder. Typed placeholders fail visibly, which is usually the safer property.
Rehydration
Keep the placeholder-to-value map server-side for the duration of the request, then substitute back into the response before it reaches the user.
The map never leaves your infrastructure. That is the entire security property — the provider sees placeholders, your user sees real values, and the mapping exists only in memory on your side.
Two failure modes to plan for. The model may invent a placeholder that was never in your map — [PERSON_3] when you only sent two — and substituting nothing leaves a visible artefact in the output. Detect unmapped placeholders and handle them explicitly. And the model may modify a placeholder, pluralising or reformatting it, which breaks exact matching. Tolerant matching helps; distinctive placeholder formats that are unlikely to be rewritten help more.
Detection is the hard part
Two mechanisms, and you need both.
Pattern matching handles structured identifiers reliably: email addresses, phone numbers, card numbers, national insurance and social security numbers, IP addresses. These have shapes, and regular expressions plus checksum validation catch them with good precision.
Recognition models handle what has no shape. Names are the obvious case — there is no pattern that matches "Sarah Chen" and not "Product Manager" — along with addresses, organisations, and locations. This needs a model, and it will have both false positives and false negatives.
Neither is complete. Free-text fields contain identifying detail that is neither patterned nor a named entity: "the customer in the corner flat above the chemist on Bridge Street" identifies someone precisely and matches nothing.
Which is why redaction should be framed as reducing exposure rather than eliminating it. Treat it as one layer, alongside contractual protections, access controls, and retention limits — not as the thing that makes a compliance question go away.
Remember to redact your own logs too. Prompts frequently land in an observability stack with looser access controls than the database the data came from, which is an internal disclosure that redaction at the API boundary alone does not address — see LLM observability.
Common mistakes
- Blanking values instead of typing them. Destroys comprehension for no extra safety.
- Inconsistent placeholders within a request. Breaks coreference; the model loses track of who is who.
- Letting the map leave your infrastructure. Defeats the purpose entirely.
- Regex only. Catches structured identifiers and misses every name.
- Not redacting internal logs. The data is still exposed, just to a different audience.
- Treating redaction as compliance. It is a control, not a legal conclusion.
- No handling for unmapped placeholders. Artefacts leak into user-facing output.
FAQ
Do I need this on an enterprise tier?
Contractual exclusion from training addresses one risk. Redaction addresses others — breach exposure, insider access, and the general principle of minimising what leaves. Whether it is required is a policy question; whether it reduces risk is not.
Does it hurt output quality?
Somewhat, and typed placeholders keep the loss small. Where the task genuinely needs the real value — verifying an address format, for instance — redaction and the task are in direct conflict and something has to give.
What about data in retrieved documents?
Same problem, larger surface. A RAG pipeline can retrieve chunks containing personal data and place them straight into the prompt. Redaction has to apply to retrieved context, not just the user's message, and this is a commonly missed gap.
Can the model be asked to redact?
Using a model to detect personal data before sending to another model is workable and imperfect — it will miss things, and you have now sent the data to a model to find out what to hide. Local models are the better fit for that specific job.
How does this relate to prompt injection?
Different risk. Redaction stops data leaving; injection defence stops instructions getting in — see prompt injection defense.
Where to go next
For the adjacent risk of a model revealing its own instructions, read system prompt leakage. For the internal logging surface, LLM observability, and for the policy layer around model outputs, AI guardrails.