The Ladder of Safeguards

The eight safeguards

Every safeguard trades utility for risk reduction. The trade is not linear and the right safeguard differs per entity, per task, and sometimes per tenant.

Read it top to bottom as increasing utility and increasing complexity. Safeguard 1 is a select statement. Safeguard 8 is a project.

Removal, and why it is first

The field never enters the prompt. Nothing to detect, nothing to restore, nothing to leak.

Removal is first on the list because it is first in practice and teams reach for it last. The question is not "how do I mask the customer's address" but "does the summarisation task need the address at all?" For a support-ticket summariser, almost never. For a delivery-issue triage tool, sometimes. Ask before you engineer.

This is Chapter 12's whole subject and the single highest-leverage control in the book. Everything below safeguard 1 exists for values that genuinely need to be there.

Redaction and masking

Redaction replaces the value with a marker. [REDACTED], [PERSON], ***. The model knows something was removed and knows roughly what kind of thing it was, if you typed the marker.

It has one significant flaw for conversational work: it destroys identity. Two different people both become [PERSON], so the model cannot tell whether the sentence is about one person or two. For a one-shot classification that does not matter. For a summary of a three-party email thread it produces nonsense.

Masking keeps part of the value. ****1234 for a card, j***@example.com for an email, +31 6 ** ** 12 34 for a phone.

Masking is for humans, not models. Its purpose is letting a support agent confirm "yes, the card ending 1234" without exposing the number. A model gains almost nothing from the last four digits, and the retained characters are a real disclosure: the last four digits of a card plus a name plus a merchant is enough to be useful to someone. Use masking when a person will read the output. Do not use it as a model-facing control and assume it is stronger than redaction, because it is weaker.

Generalisation

Replace a precise value with a band. Exact date of birth becomes an age range. A five-digit ZIP becomes its first three digits. Salary becomes a decile. A precise timestamp becomes the month.

Generalisation is under-used, because it requires thinking about the task rather than applying a uniform rule. If you are asking a model to classify support tickets by urgency, it does not need the customer's date of birth, and it might genuinely benefit from knowing the customer is over 65. Give it the band.

One caution, and it corrects an intuition many people have here. Generalisation feels like the sophisticated choice because it preserves meaning, but measured against model task performance it does worse than a plain token. Deußer et al. (2026) evaluated five anonymisation strategies across eleven benchmarks and five models, and found that the reversible methods (pseudonymisation, randomisation, masking) significantly outperformed the irreversible ones. On the MUSR reasoning benchmark, generalisation scored 0.58 against pseudonymisation's 0.70. Generalisation's value is in reducing the precision of a quasi-identifier, which is a privacy gain. It is not a utility gain, and you should not choose it expecting one.

The caution comes straight from Chapter 2. Generalised values are quasi-identifiers, and quasi-identifiers combine. Age band plus partial ZIP plus gender plus employer can identify one person as surely as a name. Generalisation reduces the risk of a single value and does very little about the risk of a set of them. When you are sending one record it is a strong control. When you are building a corpus, count the combinations.