Technology
The difference between pseudonymising, anonymising and masking, what the court said about it and what this means when text goes to an AI model.
With pseudonymisation, you replace identifiable data with a code and keep the link between code and person separately. Whoever holds the link can reverse it. With anonymisation, nobody can reverse it, including you. Pseudonymised data falls under the GDPR for you; truly anonymous data does not.
The difference determines whether you need a lawful basis, whether a mistake is a data breach and what you put in your record of processing activities. Organisations often say they work with “anonymised documents” when only the names have been removed from text that still reveals everything else. That is not anonymisation.
The GDPR defines pseudonymisation in Article 4(5). In brief: processing personal data so that it can no longer be attributed to a specific person without additional information. Two conditions apply. The additional information is kept separately, and technical and organisational measures prevent the data from being attributed to someone nevertheless.
Anonymisation has no separate definition in the articles. It appears in Recital 26: the rules do not apply to information that does not relate to an identified or identifiable person, or that has been rendered anonymous so that the data subject is not or is no longer identifiable.
The same Recital 26 explains how to assess whether someone is identifiable. Consider all means reasonably likely to be used by the organisation itself or another person to identify someone directly or indirectly. Cost, time and available technology all count.
The word “indirectly” matters here. Removing a name is not enough if the rest of the text points to the person.
Because the route back exists. Recital 26 states this explicitly: pseudonymised personal data that could be attributed to a person using additional information should be considered information about an identifiable person. You have that additional information. Its legal status therefore does not change for you.
The Autoriteit Persoonsgegevens (AP), the Dutch data protection authority, says the same in plain language: pseudonymisation is not the same as anonymisation, pseudonymisation is itself processing of personal data, and you must still protect pseudonymised data properly. Its example: a date of birth combined with the four digits of a Dutch postcode is often unique enough to find someone.
The GDPR mentions pseudonymisation in several places as a measure.
It provides no exemption from the rest. You still need a lawful basis (Article 6, and Article 9 for special category data), an entry in your record of processing activities and a DPIA where necessary. See DPIAs for AI tools.
Masking, redacting or blacking out means removing or making identifiable data unreadable without retaining a link. The name becomes a black block or the word “[name]”. It is a technique, not a legal category. Whether the result is anonymous depends on what remains.
It differs from pseudonymisation in two ways. There is no key, so you cannot reverse it yourself either. And the replacement is inconsistent: three instances of “[name]” in one paragraph could be three people, or one. Who actually gave notice, the tenant or the landlord?
The AP warns that removing only directly identifying information such as names achieves nothing if the remaining text contains enough information to find someone.
| Feature | Anonymisation | Pseudonymisation | Masking |
|---|---|---|---|
| What happens | The link to the person is permanently broken | Identifiable data becomes a code; the link is kept separately | Identifiable data is removed or blacked out |
| Reversible | No, for anyone | Yes, for whoever holds the link | No, but the remaining text may still point to someone |
| Covered by the GDPR | No, if truly anonymous | Yes, for whoever holds the link; for a recipient, it depends on what they can reasonably do | Depends on the result: only anonymous if nobody remains identifiable |
| Usefulness of the text | Low for ongoing client files: you no longer know who it concerns | High: the same person keeps the same code and the text remains readable | Moderate to low: who is who is lost |
| Residual risk | Apparent anonymity: the text later turns out to be identifiable | The key leaks, or context points to someone | Missed references and identifying context |
On 4 September 2025, the First Chamber of the Court of Justice delivered its judgement in EDPS/SRB (C-413/23 P). The case concerned the rules for EU institutions themselves (Regulation 2018/1725), rather than the GDPR directly. The definition of pseudonymisation in that regulation uses the same wording as the GDPR. The judgement is therefore also read in relation to the GDPR.
Following the resolution of a bank, the Single Resolution Board (SRB) collected comments from shareholders and creditors and passed them under a code to a consultancy. Only the Board could link the code to a name. The privacy statement did not list the consultancy as a recipient. The European Data Protection Supervisor (EDPS) considered this a breach of the duty to inform. The Board disagreed, because the consultancy could not identify anyone.
The Court did not decide that the comments were not personal data for the consultancy. It explained how to assess that and referred the case back to the General Court for further proceedings.
Two considerations are often overlooked. The duty to inform is assessed from the controller's perspective when the data is collected: the Board should therefore have named the consultancy as a recipient. And if it cannot be ruled out that a later recipient could reasonably link the data to someone, it remains personal data for that transfer and subsequent processing.
The guidelines are not yet final. That is the position as of 13 October 2026.
The consultation version contains one concept useful in practice: the pseudonymisation domain, the circle of people and systems that must not be able to link the data to a person.
For the organisation holding the key, nothing changes: it is personal data. The position may differ for the model provider, but only if it cannot reasonably identify anyone. With free text, that is difficult to assess because context can reveal a great deal.
Take a fictional sentence: “[PERSOON_A4F2], the only civil-law notary in the village of Fictiefburg, was suspended in March 2024.” The name has been replaced. Yet anyone familiar with Fictiefburg knows who it concerns. The provider may also have other information, such as what the user types alongside it.
That is the Court's second condition: the recipient must also be unable to link the data to the person by another route. For text from client files, this is an assessment per document, not a feature of the technology.
The last point is caution, not settled law: the supervisory authorities have not yet explained whether a provider unable to identify anyone remains a processor. What to check in such an agreement is explained in A data processing agreement with an AI provider.
A pseudonymised client file is of little use if the question above it reads: “What does this say about Ms Voorbeeld from Fictiefburg?” That question goes directly to the provider. See Can you put client data in an AI chatbot?. What happens to an uploaded file is explained in Uploading documents to an AI chatbot.
That depends on one question: will you need to know later who it concerns?
What you cannot do is pseudonymise and call it anonymisation. Anyone writing in their AI policy that employees may enter only “anonymised” text needs to know what that word requires. See Creating an AI policy for your organisation.
PrivaSearch pseudonymises, deliberately. Names, addresses, BSNs (Dutch citizen service numbers), IBANs, Dutch number plates and dates of birth are detected inside PrivaSearch itself and replaced with a code such as [PERSOON_A4F2]. The same name always gets the same pseudonym within a project, keeping a passage readable. See How PrivaSearch works.
The link between pseudonym and person is held in a separate vault, with a key per organisation. An AI assistant searching through the connection receives released passages with pseudonyms and a short source reference. No original files, no filenames and no access to the vault. The AI assistant connection works with Claude, ChatGPT Business and Mistral Vibe.
Because detection is never complete, human review is mandatory. A colleague sees the original alongside the pseudonymised text, adds what was missed and approves it. Only then does a document become searchable.
For your organisation, this remains personal data: you hold the key. That is why your environment creates an entry for the record of processing activities and a DPIA starter document, and there is a data processing agreement. What PrivaSearch contributes under each GDPR article and what remains your responsibility is on The GDPR and the EU AI Act. The main page about chatbots is ChatGPT, Claude, Mistral Vibe and the GDPR.
Want to see a pseudonymised passage alongside the original? Book a demo.
Yes, for the organisation holding the link between pseudonym and person. The GDPR says pseudonymised data that can be attributed to someone using additional information counts as information about an identifiable person. You therefore need a lawful basis, must protect it and include the processing in your record of processing activities. The position may differ for a recipient without the key, depending on what they can reasonably do.
If it is truly anonymous, it falls outside the GDPR. The threshold is high: nobody may be able to identify the person using means reasonably likely to be used, including by combining the text with other information. A client file with only the names removed usually fails that test. As long as someone is identifiable, it remains personal data, whatever the document is called.
On 4 September 2025, the Court of Justice ruled that pseudonymised data is not personal data in every case and for everyone. For a recipient who cannot reverse the pseudonymisation or link the data to someone by another route, it may not relate to a person. For whoever holds the key, it remains personal data, and the duty to inform continues to apply.
That depends on your lawful basis, your agreements with the provider and what remains in the text. Pseudonymisation reduces the risk, but your obligations remain: it is personal data for you. Use a business account with a data processing agreement, send only the passage needed and check that the context does not point to anyone. Ask your data protection officer or a lawyer to review it if in doubt.
No. Blacking out removes direct identifiers, but the remaining text may still point to someone: a job title, a place, a date or a rare event. The Autoriteit Persoonsgegevens warns that removing names alone achieves nothing if the remaining data contains enough information to find someone. Whether redacted text is anonymous must therefore be assessed per document.
Assume that you do. The judgement says data may not be personal data for a recipient, but European supervisory authorities have not yet explained what that means for the processor role. The answer also depends on whether the recipient really cannot identify anyone, which is rarely certain with free text. An agreement covers both situations.
How retrieval-augmented generation works, how it differs from uploading and fine-tuning, why it reduces errors and which privacy questions to ask.
What the Model Context Protocol is, how a connection differs from uploading a file, what an assistant receives and which risks you should check.
What a language model does, what tokens and a context window are, why a model invents things and what it does and does not remember from your input.
We show it with fictitious client files from your sector: upload, detection, review, search and the connection with your AI assistant. Afterwards you'll know exactly what your team can use safely.
Book a demo →