Pseudonymisation vs anonymisation: what the GDPR means for AI
The two words get used interchangeably, but under the GDPR they lead to very different obligations. If you are deciding how to feed documents to an AI, the distinction matters more than any vendor promise.
- Anonymisation removes any reasonable possibility of identifying a person, for anyone. Anonymous data falls outside the GDPR, but true anonymisation is hard and destroys most of the value of a working document.
- Pseudonymisation replaces identifiers with codes and keeps the key separately. For whoever holds the key, the data is still personal data under the GDPR.
- The GDPR explicitly names pseudonymisation as a protective measure (data protection by design, security of processing).
- For AI work, pseudonymisation is the practical choice: the AI reasons on consistent codes, and you restore the real values locally. The key must never travel with the data.
This article explains general principles and is not legal advice.
Two definitions
Anonymisation transforms data so that the person it relates to can no longer be identified, by anyone, using any means reasonably likely to be used. The European data protection authorities' reference opinion on the subject (Article 29 Working Party, Opinion 05/2014) tests it against three risks: singling a person out, linking records about the same person, and inferring information about them. If none of those is reasonably possible, the data is anonymous, and the GDPR no longer applies to it.
Pseudonymisation is defined in Article 4(5) of the GDPR: personal data is processed so that it can no longer be attributed to a specific person without additional information, and that additional information (the key) is kept separately and protected. "Sarah Whitfield" becomes NOM-001; the table linking NOM-001 to Sarah is the key.
The difference that matters: who holds the key
Recital 26 of the GDPR is explicit: data that has been pseudonymised but could be attributed to a person using additional information should be considered information on an identifiable person. In other words, for the organisation that holds the key, pseudonymised data is still personal data. All the usual obligations continue to apply.
The picture for a recipient who never has the key is more nuanced. In September 2025, in EDPS v SRB (case C-413/23 P), the EU Court of Justice indicated that pseudonymised data is not necessarily personal data for every recipient: it depends on whether that recipient has means reasonably likely to be used to re-identify the people concerned. The European Data Protection Board's guidelines on pseudonymisation (Guidelines 01/2025) also describe how pseudonymisation reduces risk when it is done properly, with the key kept out of reach of those who receive the data.
The practical lesson for AI use is simple: the protection comes from where the key is. If the key travels with the data, or sits with the AI provider, pseudonymisation protects very little. If the key never leaves your computer, the AI provider receives codes it has no reasonable way to reverse.
Why the GDPR encourages pseudonymisation
Pseudonymisation is not a loophole; the regulation names it as a good practice. Article 25 (data protection by design and by default) and Article 32 (security of processing) both cite it as an appropriate measure. It is also one of the factors that can make further processing compatible with the original purpose. Regulators treat it as a way to reduce risk while keeping data usable.
Why anonymisation is the wrong tool for AI work
Anonymisation sounds safer, and for publishing statistics it often is. For day-to-day work with an AI, it fails on three counts:
- It is hard to achieve with documents. Free text is full of indirect identifiers. A well-known study by Latanya Sweeney found that a large majority of Americans could be uniquely identified by just their ZIP code, gender and date of birth. A contract or an HR file contains far more than that.
- It destroys the reasoning. If every person becomes "[REDACTED]", the AI can no longer tell the buyer from the seller, or the employee from the manager.
- It is a one-way street. You need the result with the real names in it. Anonymised output has to be reworked by hand before it is usable.
Pseudonymisation done right for AI
For pseudonymisation to hold up when you use Claude, ChatGPT, Gemini or Copilot, four conditions matter:
| Condition | Why |
|---|---|
| The key stays on your side | On the computer, or on your organisation's own file share, never with the AI provider or the tool vendor. |
| Codes are consistent across the whole case | The same person must be NOM-001 in every document, or the AI will treat one person as several. |
| Indirect identifiers are handled | Job titles, rare events, dates and places are flagged and, where needed, generalised. |
| Decoding happens locally | The real values go back into the AI's output on your machine, so they never transit in clear. |
Hidden Tokens is built on exactly these four conditions, and adds a local log of what the AI received so you can prove it. But the criteria apply to any tool you evaluate: ask where the key lives, and you will know most of what you need.
In short
Anonymisation takes data out of the GDPR but makes it nearly useless for AI work. Pseudonymisation keeps it inside the GDPR but, with the key kept locally, means the AI provider only ever sees codes. For organisations that want the productivity of generative AI without handing over their clients' identities, pseudonymisation with a local key is the workable middle ground. See also how to use ChatGPT or Claude with client data.
Frequently asked questions
Is pseudonymised data personal data?
For the organisation that holds the key, yes: the GDPR treats data that can be re-attributed with additional information as data on an identifiable person. Whether it is personal data for a recipient who has no means of re-identification is a separate question, which the EU Court of Justice addressed in 2025 (EDPS v SRB, C-413/23 P). Seek legal advice for your own situation.
Is replacing names with codes enough to anonymise a document?
Usually not. Indirect clues such as a job title, an employer, a date of birth or a rare event can identify someone without a name. That is why a good pseudonymisation tool also flags indirect identifiers, and why the result should be treated as pseudonymised rather than anonymous.
Why not just anonymise everything before using AI?
Because you need the names back. A memo or a spreadsheet produced on anonymous data cannot be returned to the client without someone manually reinserting every value. Pseudonymisation with a local key lets the AI work on codes and puts the real values back automatically.
Does pseudonymisation make my use of AI GDPR-compliant?
It is a recognised safeguard and it reduces risk considerably, but compliance also depends on your lawful basis, your contracts, your records and your other measures. A tool can support compliance; it cannot certify it.