PII redaction for LLM applications
Keeping personal data out of a third-party model without breaking the product: detection limits, redaction versus tokenisation, and when it is wrong.
Most personal data reaching a model provider does not get there through an exotic attack. It gets there because someone pasted a customer record into a prompt, or because a retrieval step attached a document that happened to contain one, or because an application forwards the whole conversation on every turn and nobody has looked at what accumulates in it.
PII redaction is the control that sits between the application and the provider and removes, replaces or blocks personal and sensitive data in the outbound request. It is a good control, it is not a complete one, and knowing where the line is matters more than the detector's benchmark score.
Redaction, tokenisation, blocking
Three different behaviours get called redaction, and only one of them keeps the product working.
Redaction replaces the detected value with a marker: [REDACTED], [EMAIL]. Simple, and it destroys information the model may need. An assistant asked to draft a reply to [NAME] about invoice [NUMBER] produces a draft somebody then has to repair by hand.
Tokenisation (or pseudonymisation) replaces the value with a stable placeholder before the call — PERSON_1, ACCOUNT_7 — and substitutes the real values back into the completion afterwards. The mapping never leaves your infrastructure. The model reasons about consistent entities, the answer comes back correct, and no real identifier crosses the boundary. This is almost always the right default, and it is the difference between a control people keep and a control people switch off in week three.
Blocking refuses the request outright. Reserve it for categories where processing is genuinely not permitted — special-category data under GDPR Article 9, payment card data in scope for PCI DSS, credentials — and make the error message tell the user which category tripped, because otherwise they will retry with a paraphrase until it goes through.
What detection actually catches, and what it misses
Detection is a mix of pattern matching with validation (card numbers with a Luhn check, national identifiers with a checksum, well-formed emails and IBANs) and statistical models for the things that have no format at all — names, addresses, employers, medical conditions, free-text descriptions of a person.
The reliable part is the formatted identifiers. The unreliable part is everything else, and the misses are systematic rather than random:
- Names outside the training distribution. Detectors are measurably worse on names from under-represented languages and scripts, which makes the residual risk fall unevenly across your users. That is a fairness problem as well as a privacy one, and it belongs in the risk assessment explicitly.
- Personal data expressed as prose. "the contractor who was let go from the Leeds office in March" identifies a person and matches no pattern.
- Context-dependent sensitivity. A postcode is not sensitive; a postcode next to a diagnosis is.
- Non-obvious carriers. Document metadata, filenames, embedded images, spreadsheet formulas and quoted email chains all reach the provider and are routinely excluded from whatever the detector was pointed at.
- Anything encoded. Base64 blobs, URL parameters and JSON payloads pasted in as debugging context.
The honest framing for a risk register: redaction is a substantial reduction in exposure, not a guarantee that no personal data leaves. Write it that way. An unfalsifiable "no PII is sent to third parties" is the claim that fails an audit.
Where redaction is the wrong control
If a workload genuinely cannot tolerate the residual — clinical notes, case files, unredacted legal discovery — the answer is not a better detector. It is a deployment model where the prompt does not leave your network at all: a model running in your own environment, or a provider deployment inside your tenancy with a contractual and technical guarantee that content is not persisted. See on-premises deployment and zero data retention.
Choosing detection for a workload that needed isolation is the most common architectural mistake in this area, and it is usually made because detection was easier to procure.
Do not forget the return path, or the logs
Two things get missed almost universally:
The completion. A model that was given tokenised input can still emit personal data it inferred, retrieved or was given earlier in the conversation. Run detection on the way back as well, particularly where the output is persisted, displayed to a different user, or sent outside the organisation.
Your own logs. The prompt and completion logs you keep for debugging and audit are, in aggregate, the most concentrated store of personal data the application produces. They are frequently the least controlled — an unrestricted search index with no retention schedule. Classify them, bound their retention, put them in a decided region, and control access to them like any other production data store.
Getting the compliance framing right
- Redaction is not anonymisation. If you keep a mapping that can restore the original — and tokenisation does — the data is pseudonymised, and pseudonymised personal data is still personal data under GDPR Recital 26. It is a strong security measure under Article 32; it is not an exit from scope.
- It supports data minimisation under Article 5(1)(c), which is the argument worth making: the provider receives only what the task requires.
- Detection is processing. The redaction service itself sees the raw data, so it is in scope for the same residency, retention and subprocessor questions as anything else in the path.
- Records matter more than intentions. Being able to show what categories are detected, at what operating point, with what measured miss rate, is what turns this from an assertion into evidence.