Replace each entity with a stable token. Sarah Whitfield becomes PERSON_1 everywhere it appears, and the mapping lives in a vault you control.
This is the default for production LLM work, because it preserves the one thing redaction destroys: coreference. The model can follow that PERSON_1 appears in turn one and turn seven and is the same person. It can reason about relationships between PERSON_1 and PERSON_2. It can produce a summary that tracks who did what, and you can restore the real names before anyone reads it.
Two things must be stated plainly, both from Chapter 2.
Pseudonymised data is still personal data. The mapping exists, so GDPR still applies in full. This reduces exposure at the model, it does not take you outside the regulation, and you should never describe it as anonymisation in a security questionnaire.
The vault is now your most sensitive store. You have concentrated the mapping from token to real person into one place. That place needs the safeguard Chapter 14 describes, and it is worth being honest that you have traded a diffuse risk for a concentrated one. Concentrated risk is easier to protect and worse when it fails.
Chapter 9 builds this end to end.
Replace the real value with a realistic fake one. Sarah Whitfield becomes Megan Alvarez, not PERSON_1.
Surrogates preserve utility better than tokens because the text stays natural. Models were trained on text containing names, not text containing PERSON_1. The measured picture is more nuanced than "tokens are bad": Deußer et al. (2026) found reversible strategies including randomisation, which is close to a surrogate, outperforming irreversible ones across eleven benchmarks, while the degradation from any anonymisation was highly task-dependent rather than uniform. A surrogate reads like the original, so the model tends to behave as if it had the original. Whether that matters for your task is something you measure, not something you assume.
Two hazards, one obvious and one not.
The obvious one is consistency. If the same person becomes Megan Alvarez in one paragraph and Dana Reyes in the next, you have destroyed coreference more thoroughly than redaction would have. Surrogate assignment must be deterministic per entity per context, which means a vault, the same as pseudonymisation.
The non-obvious one is the plausibility hazard. A surrogate is indistinguishable from real data to a downstream human. If the model's output reaches a person who does not know substitution happened, they will act on a fabricated name as though it were real. Support agents have contacted the wrong customer this way. If you use surrogates, the boundary where values are restored must be unambiguous, and anything that escapes that boundary must be labelled.
Encrypt the value so the ciphertext has the same shape as the plaintext. A sixteen-digit card becomes a different sixteen-digit number that still passes a Luhn check. A national identifier becomes a different, well-formed national identifier.
FPE earns its place when a downstream system validates format and would reject a token. Legacy schemas with strict column types, systems that check a checksum before accepting a value, pipelines you cannot change. NIST SP 800-38G defines the standard modes, and they have documented caveats for small domains, which matter more than they sound: a value drawn from a small set can be attacked by enumeration regardless of the cipher.
For LLM work specifically, FPE is rarely the right safeguard. The model does not validate your card numbers. You are paying key-management cost for a property nothing downstream uses. It belongs in the toolkit for the data-pipeline side of your estate, and is listed here so you recognise it when someone proposes it.
Generate a new record that has the statistical properties of the original and describes nobody.
This is a genuine research direction and a genuine option for training sets, evaluation corpora, and demo environments. It is not a safeguard for a live request, because you cannot synthesise the specific customer's specific problem and still answer it.
Where it does pay off immediately is test data. The pii-test-data folder from Chapter 7 is a real liability, and a synthesised equivalent removes it. Treat synthesis as the answer to "how do we build realistic test and demo data without copying production", which is a question most teams have answered badly, and not as an answer to "how do we handle this request".
Four questions, in order:
Apply per entity, not per system. A single request can legitimately remove the address, pseudonymise the names, generalise the date of birth, and redact the card number, and that combination is better than any uniform policy.
Most production systems answer "yes" to question 2, because the user expects an answer about their actual customer. That means a round trip, and the round trip has sharper edges than the diagram suggests.
The ladder of eight safeguards and the four questions for choosing one are the author's framework. The ordering by utility and residual risk is a judgement informed by the Deußer results rather than a reproduction of them. An earlier draft called generalisation the best choice for analytics work; the Deußer measurements contradicted that and the text was corrected.
Download the full PDF for free?
Free download — no account required