Anonymisation, pseudonymisation, tokenization: which one you actually have
A vendor tells you their tool anonymises data before it reaches the model. A second says it tokenizes it. A third says it masks it. A fourth says it redacts it. The demos look identical: a name goes in, something that is not the name comes out.
Only one of those four words describes a state where data protection law stops applying to you. The other three describe security measures applied to data that is still personal data, still in scope, and still your responsibility. If you are signing off on a tool, that distinction is the whole review.
This is a plain guide to what each term means, written for the person who has to make the call. It is not legal advice, and the assessment always depends on your specific data and context.
The only question that changes your obligations
Strip away the vocabulary and there is one question underneath: can this data still be connected back to a living person by someone, using means reasonably likely to be used?
If yes, it is personal data. Every obligation you had before still applies: lawful basis, transparency, retention limits, subject rights, breach notification. If no, it is anonymous information and the GDPR does not govern it.
Everything below is a variation on how completely that link is broken, and on who is holding the piece that would restore it.
Anonymisation
Recital 26 of the GDPR sets the bar. The Regulation does not apply to anonymous information, meaning information that does not relate to an identified or identifiable person, or to personal data rendered anonymous in such a way that the person is no longer identifiable.
"No longer identifiable" is doing heavy lifting there. The test is not whether you can identify someone, it is whether anyone can, using means reasonably likely to be used, accounting for available technology and other datasets they could combine with yours.
The working framework, from the Article 29 Working Party's opinion on anonymisation techniques and carried forward by the EDPB, asks three things:
- Singling out. Can you isolate one person's records in the set?
- Linkability. Can you link two records that belong to the same person, in the same set or across sets?
- Inference. Can you deduce a person's attribute from the other values with significant probability?
Fail any of the three and you have not anonymised anything. This is why the bar is high in practice and why most "anonymised" claims collapse under a careful reading: a dataset with a rare job title and a postcode singles people out even with every name removed.
The prize for clearing it is real. Anonymous data leaves scope entirely. The cost is that the process must be irreversible, which usually means throwing away utility you wanted to keep.
Pseudonymisation
This one is defined in the text, at Article 4(5): processing personal data so that it can no longer be attributed to a specific person without the use of additional information, where that additional information is kept separately and protected.
Read the second half again. Pseudonymisation assumes the additional information still exists. Something, somewhere, can put the names back. That is the design.
The consequence trips people up constantly: pseudonymised data is still personal data. It stays in scope. Recital 26 says so directly, treating data that could be attributed to a person through additional information as information about an identifiable person.
So pseudonymisation is not an exit. It is a control. The Regulation treats it that way, naming it as an appropriate technical measure under Article 32 on security of processing, and as an example of data protection by design under Article 25. It reduces the harm if the data is exposed, and it narrows who can re-identify. It does not end your obligations.
A vendor who says "we pseudonymise, so this is no longer personal data" has told you something incorrect about their own product, which is useful information about the vendor.
Tokenization
Tokenization is not a GDPR term at all. It comes from payments, where the problem was card numbers sitting in merchant systems, and it is the vocabulary of PCI DSS rather than of European data protection law.
The mechanic: replace a sensitive value with a surrogate token that has no exploitable meaning, and keep the mapping from token back to value in a separately controlled store, often called a token vault.
Held next to Article 4(5), tokenization is a specific implementation of pseudonymisation. The token is the pseudonym. The vault is the "additional information kept separately". Everything said above about pseudonymisation applies to it: still personal data, still in scope.
Which makes the important question about any tokenization product a very concrete one. Who holds the vault? If the vendor holds it, the vendor can re-identify every record you sent, and that capability sits inside their trust boundary rather than yours. If you hold it, they cannot. Two products can both be described accurately as "tokenization" and land on opposite sides of that line.
Redaction
Redaction is one-way removal. The value is taken out and nothing is kept that restores it.
Done properly, and only if the residual data survives the singling out, linkability and inference test, redaction can amount to anonymisation. Done as most people actually do it, it does not remove anything at all. A black rectangle drawn over a PDF is a graphic placed on top of the page. The text underneath is still in the file, still selectable, still recoverable by anyone who opens it in the right tool. We wrote about what it takes to actually destroy it.
The other cost of real redaction is that you lose the answer. Send a model a contract where every party is a black bar and the reply comes back about black bars. That is the trade one-way redaction forces on you.
Masking
Masking is an umbrella word. On its own it tells you nothing, because it covers reversible and irreversible techniques alike.
When a tool says it masks data, the only useful follow-up is: what happened to the mapping? Destroyed, and you are in redaction territory. Kept and held by you, and it is pseudonymisation under your control. Kept and held by the vendor, and it is pseudonymisation under theirs.
Side by side
| Term | Reversible | Still personal data | Defined in GDPR |
|---|---|---|---|
| Anonymisation | No | No, if the bar is genuinely met | Recital 26 |
| Pseudonymisation | Yes, with the separate information | Yes | Article 4(5) |
| Tokenization | Yes, via the vault | Yes | No, PCI vocabulary |
| Redaction | No | Only if it clears the anonymisation bar | No |
| Masking | Depends | Depends | No |
Where masking a prompt sits
Velum masks personal data on your machine before a prompt or file reaches a model, then restores it in the reply. By the definitions above that is pseudonymisation, and we will not call it anything else. The mapping exists, because reversing it is the point. Data you have masked is still personal data and you still carry every obligation attached to it.
What changes is narrower than "anonymised" and more useful than it sounds: the AI provider never receives the personal data in the first place. There is no vault on our side because the mapping never leaves your machine, so there is no copy of your originals for us to lose, be compelled to hand over, or re-identify. The exposure you were worried about, a client name sitting in someone else's logs and possibly their training set, does not happen. The exposure you still have to manage, personal data on your own device under your own control, is the one you were already managing before AI entered the picture.
That is a smaller claim than the market usually makes. It is also one you can verify, which is the trade we would rather have.
What to ask a vendor
Five questions that cut through the vocabulary:
- Is the data still personal data after your tool processes it? A correct answer is yes for anything reversible.
- Where does the mapping or vault live, and who can read it?
- What leaves my machine or my network, exactly, and when?
- If you claim anonymisation, how does the result hold up against singling out, linkability and inference?
- Can I verify any of this myself, or am I taking your word for it?
The answers will tell you which of the five words above the product has actually earned. Most of the time it is pseudonymisation, and that is fine. It stops being fine when it is sold as something else.
This post is about which word applies to you in law. For the practical side, which masking mode to reach for on a given piece of text, see tokenized vs pseudonymized masking.
If you want to see what pseudonymisation before the model looks like in practice, download Velum or see where it fits.