Pseudonymisation vs anonymisation under the GDPR

Pseudonymisation vs anonymisation: the short answer

Pseudonymisation hides who someone is while keeping a way back; anonymisation removes the way back altogether. That single difference decides whether the GDPR applies.

Article 4(5) of the GDPR defines pseudonymisation as processing personal data so that it can no longer be attributed to a specific person without additional information, provided that information is kept separately and protected by technical and organisational measures. A table that maps [PERSON_1] back to "John Smith" is exactly that additional information.

Recital 26 draws the line. Pseudonymised data that could be attributed to a person using additional information should be considered personal data. Anonymous data, meaning information that does not relate to an identified or identifiable person, taking into account all the means reasonably likely to be used, fall outside the GDPR.

Where reversible tokens stand

Reversible tokens are pseudonymisation, not anonymisation. Whoever holds the key can restore the original values, so for that party the tokenised text remains personal data.

That is the intended design. When you send a contract to an AI, you want the answer back with the real names in place. The reversal key is the "additional information" of Article 4(5), and it has to be kept separately and securely.

The GDPR treats this positively. Article 32 lists pseudonymisation as an example of an appropriate security measure, and Article 25 on data protection by design and by default names it as a measure controllers can build into their processing. Tokenisation is therefore a recognised safeguard, even when it does not take the data outside the Regulation.

What the EDPB guidelines add

In January 2025 the European Data Protection Board adopted Guidelines 01/2025 on pseudonymisation for public consultation. They explain how pseudonymisation can reduce risk and support compliance, and what controllers need in place for it to be effective.

Themes that are useful in practice include defining the "pseudonymisation domain" (who should not be able to re-identify), keeping the additional information separate, and protecting it with appropriate measures. Read the guidelines, and check whether a final version has since been adopted, on the EDPB website.

The SRB judgment and the relative approach

In Case C-413/23 P, EDPS v SRB, judgment of 4 September 2025, the Court of Justice addressed whether pseudonymised data are personal data for a recipient who does not hold the key.

The Court indicated that this depends on the recipient's position: whether that recipient has means reasonably likely to be used to re-identify the people concerned. It also indicated that the controller's own obligations to inform data subjects are assessed from the controller's perspective at the time the data are collected, not from the recipient's.

This is often described as a relative, or recipient-based, approach. It does not mean pseudonymised data stop being personal data for the controller who holds the key. Practitioners should read the full judgment on CURIA rather than rely on summaries, as the reasoning is fact-specific.

What this means for sending tokens to an AI provider

If an AI provider receives only tokens and has no reasonable means to re-identify anyone, there is a credible argument that the text is not personal data from its perspective. That argument weakens if the surrounding context still identifies someone.

Context matters more than people expect. A token hides a name, but "[PERSON_1], the only female partner at a named firm in a small town" may still point to one person. Good tokenisation covers not just names but all identifiers, and a human check catches identifying context.

Many organisations take a cautious line: they use tokenisation to minimise what the provider sees, and still treat the provider under their normal processor and transfer arrangements (Article 28 and Chapter V, Articles 44 to 49). Where the key is held matters too. With Keys stay with you, detection and replacement run in your browser, so LEXARIS itself never receives the document content or the key; the guide to client-side keys explains the trade-offs.

Replacement modes and their likely GDPR status

The mode you choose largely decides whether the result is pseudonymised or potentially anonymous. The table below is a starting point, not a verdict; context can still identify someone.

A hash deserves a note: the same value always gives the same hash, which is useful for matching records, but it also means anyone with the secret key could test candidate values. Each mode is explained in seven ways to replace personal data, and the replacement modes section summarises them.

A practical checklist for DPOs

Before approving tokenised AI use, a DPO can work through a short list of questions.

1. Purpose and lawful basis. Is there a lawful basis for the underlying processing, independent of the tokenisation?
2. Coverage. Does detection cover every identifier in your documents, including headers, footers, metadata and attachments?
3. Context. Could remaining text identify someone indirectly? Is there a human check before sending?
4. Key location. Who holds the reversal key, where is it stored, and who can access it?
5. Recipient means. What could the AI provider reasonably use to re-identify, and what do its terms say about retention and use of prompts?
6. Contracts and transfers. Are processor terms (Article 28) and transfer safeguards (Articles 44 to 49) in place for the tools involved?
7. Records. Is the approach reflected in your records of processing and, where needed, a DPIA?

LEXARIS offers compliance profiles for the GDPR, UK GDPR and six other regimes, described in the compliance profiles section. For US health data, see HIPAA de-identification before AI.