A research agency delivers a dataset to a client, describing it as anonymised. The names are out, replaced by respondent numbers. The key sits in a separate file on a different server, as it should.
That dataset is not anonymised. It is pseudonymised, and for the agency holding the key every GDPR obligation still applies.
No privacy terms get misused more than these, and the consequence is always the same: somebody believes the job is done.
#The three operations
Anonymising. The data has been altered so that nobody can identify the person any more, not even with additional information or by combining it with other sources. If that is genuinely the case, it is no longer personal data and the dataset falls outside the GDPR.
Pseudonymising. Identifying values are replaced by a code or key. The person is not directly identifiable but can be identified with the key. For whoever holds the key, it remains personal data. The GDPR names it explicitly as a security measure, not as an exit route.
Masking. A value is hidden when it is displayed, for example showing only the last four digits of an account number. The underlying data usually sits unchanged in the system. This is an access control: it governs who sees what, not what is stored. With AI tools the word usually means something else: swapping a value for a placeholder before the text is sent. In GDPR terms that is pseudonymisation, which comes up again further down.
#What pseudonymisation means in the GDPR
Article 4(5) of the GDPR gives it a definition of its own (checked 7 November 2026). Personal data is processed in such a way that it can no longer be attributed to a specific data subject without additional information. That additional information is kept separately and protected by technical and organisational measures, so the link cannot simply be made.
Three things follow from that wording. The data is still about a person; only the name has gone. A key exists, whether it is a table of respondent numbers or a list recording that [NAME1] stands for Ms Novak. And the protection lies in the separation: someone with only the data sees no names, while someone who also has the key can put everything back.
Anonymisation has no definition of its own in the GDPR. The regulation does not apply to data that can no longer be linked to a person, and whether that is the case depends on the means reasonably likely to be used to identify someone.
#Why only the first removes obligations
The GDPR governs personal data. Where data can no longer be attributed to a person, the regulation does not apply and the whole set of obligations falls away: legal basis, purpose limitation, retention, data subject rights, breach notification.
For you, pseudonymisation removes none of that. The data is better protected, which counts towards whether you have implemented appropriate measures. You still need a legal basis, and a data subject can still request access or erasure. The European Data Protection Board put it plainly when it announced its pseudonymisation guidelines in January 2025: if the controller or anyone else can attribute the data to an individual, it remains personal data (checked 7 November 2026). The EDPB published those guidelines as a version for public consultation.
Masking a display removes nothing at all, because nothing about the stored data has changed.
#What applies to a recipient without the key
This is where things have moved since 2025. The agency from the opening keeps the key. The client receives only respondent numbers and answers. Is that personal data for the client too?
On 4 September 2025 the Court of Justice of the EU ruled in EDPS v SRB (C-413/23 P), a case about comments passed in pseudonymised form to a consultancy. The EDPB takes that judgment into account in its guidelines on anonymisation, announced on 8 July 2026 and then put out for consultation (checked 7 November 2026). They say that whether data is anonymous may vary from one entity to another, and that the means reasonably likely to be used depend on the perspective of the entity concerned, assessed in light of all objective factors.
In practice that comes down to three points.
- Nothing changes for the key holder. The agency processes personal data, with every obligation that comes with it.
- For the recipient it is an assessment, not a rule. If the client can ask for the key, recognise respondents from what they wrote, or link the data to something it already holds, it is personal data for the client. Only if none of that is reasonably likely does the answer change.
- The guidelines are not yet final. The public consultation closed on 30 October 2026. So do not build a data processing agreement or a DPIA on the assumption that a recipient falls outside the GDPR.
#The bar for anonymity is high
This is where it goes wrong in practice, even among people who know the difference.
The question is not whether you can identify the person. The question is whether identification is reasonably possible, using the means and data available.
That is stricter than it sounds, because combining data reveals so much. A dataset without names but with postcode, date of birth and gender is close to a list of names: in Latanya Sweeney's research those three fields were likely to make 87% of the US population unique (checked 7 November 2026). Add job title and organisation, and in a team of twelve only one person fits. See why removing names is not enough.
The same EDPB guidelines propose three tests: no record isolation, no linkage and no inference. You cannot single out the record of one person, you cannot link the data to other data about that person, and you cannot deduce anything about a person from it. A dataset that passes all three can be treated as anonymous; one that fails any of them needs further analysis.
Anonymity is therefore not a property of an operation but an outcome you assess per dataset and per context. The same transformation can produce anonymity in a national sample and fail in a department of twelve.
The same question arises with AI models. In its opinion on AI models of December 2024 the EDPB concluded that a model trained on personal data cannot simply be treated as anonymous, and that the assessment must be made case by case (checked 7 November 2026).
#What to choose in practice
Purpose determines the operation.
Publishing data or taking it outside the GDPR? It has to be anonymisation, backed by a reasoned explanation of why re-identification is not reasonably possible. Aggregation, generalisation and thresholds are the usual techniques.
Research where you must re-link later? Pseudonymisation is the right choice, with the key kept separately and only a small group able to access it. And call it that.
Preventing staff from seeing more than they need? Masking the display is exactly the right tool, and it is not a processing measure.
Putting something into an AI tool? The legal classification matters less than the practical question of which data the task requires. It is usually a combination: remove what is not needed and replace what is needed as context with a placeholder. See the prompt redaction guide.
Take an example. An employee pastes a customer email with a name and a passport number into ChatGPT to draft a reply. With the BeeSensible extension, both are highlighted as the employee types. The name is masked and appears in the prompt as [NAME1]; the employee removes the passport number. If keep context is on, the extension remembers per conversation, on the device only, which placeholder stands for which name, and puts the real name back into the answer on the employee's screen. ChatGPT only ever sees the placeholder.
That is pseudonymisation, and it is the honest name for it. The key stays with your organisation, so for you it remains personal data. Whether the rest of the email still makes someone recognisable, an address or an order number, depends on what is in it. That is why leaving out what the task does not need remains the first step. If you are a privacy officer and want to see what this looks like across the organisation, in counts and never in what anyone typed, the page for privacy officers shows how.
#The word you use is not neutral
"We anonymise the data" is a commitment. Written into a data processing agreement, a privacy notice or a DPIA, it becomes something you can be held to. If it turns out to have been pseudonymisation, the word was wrong, and so was the conclusion attached to it: that the GDPR no longer applied.
So it pays to use the precise word, even when it sounds weaker. Pseudonymisation that is described correctly puts you in a stronger position than anonymisation that does not survive scrutiny.
