Anonymisation vs Pseudonymisation under the GDPR

Last reviewed: 2026-07-08 · By Victor Humenhuk (AIGP certified)

Anonymised data can no longer be linked to an identifiable person by any means reasonably likely to be used, and falls outside the GDPR entirely under Recital 26. Pseudonymised data has had identifiers replaced or held separately, but can still be attributed to a person using additional information, so it remains personal data and every GDPR obligation continues to apply. Pseudonymisation is a security and data-protection-by-design measure under Articles 4(5), 25 and 32, not an exit route from the Regulation. In AI this distinction decides whether a training set, and sometimes a trained model, is in scope at all, and the EDPB has taken the position that a model trained on personal data is not automatically anonymous.

Anonymisation vs pseudonymisation side by side

	Anonymisation	Pseudonymisation
GDPR status	Outside scope (Recital 26)	Personal data, fully in scope
Definition	Not identifiable by any means reasonably likely to be used, by the controller or by another person	Article 4(5): cannot be attributed to a person without additional information kept separately and subject to technical and organisational measures
Reversible	No, irreversible in practice	Yes, by whoever holds the additional information
Function	Takes the data out of the regime	Risk reduction, and an express Article 25 and Article 32 safeguard
Data subject rights	Do not apply	Apply in full
Typical techniques	Aggregation, generalisation, k-anonymity and its extensions, differential privacy at sufficient strength	Tokenisation, key-coding, hashing, encryption where the key is retained
Evidence expected	A documented re-identification risk assessment, revisited over time	Documented separation of the additional information, plus access controls
Classic error	Calling hashed identifiers anonymised	Assuming pseudonymisation ends GDPR obligations

What is the legal test for anonymous data?

Recital 26 sets it out: the principles of data protection do not apply to anonymous information, and to determine whether a person is identifiable account should be taken of all the means reasonably likely to be used, either by the controller or by another person, considering objective factors such as the cost of and time required for identification, and available technology and technological developments.

Three points follow, and all three matter in practice:

The test is relative, not absolute. In Breyer (C-582/14) the CJEU held that data is personal where the party holding it has means lawfully available to it and reasonably likely to be used to identify the individual with the help of a third party. Zero theoretical risk is not the standard; reasonable likelihood is.
Whose perspective counts is contested. Whether pseudonymised data transferred to a recipient that lacks the additional information is personal data in that recipient's hands has been litigated in the EDPS v SRB proceedings (General Court, T-557/20, then on appeal to the Court of Justice as C-413/23 P). Check the current state of that line of authority before relying on a recipient-side argument.
Three risks must be defeated. The Article 29 Working Party's Opinion 05/2014 on anonymisation techniques frames the assessment around singling out, linkability and inference. A technique that defeats one but not the others has not anonymised anything.

Identifiability is also dynamic: a dataset that was safely anonymous in 2019 may not be after a new auxiliary dataset is published, so anonymisation claims need re-testing. And anonymising personal data is itself processing, so it needs a lawful basis and must be compatible with the original purpose. See anonymisation, pseudonymisation and PETs.

Which techniques give you which?

Very few techniques deliver anonymisation on their own.

Hashing: pseudonymisation, not anonymisation, even when salted. If the input space is small, a hashed email address or national identifier can be brute-forced.
Encryption where you keep the key: pseudonymisation. The key is the additional information referred to in Article 4(5).
Tokenisation and key-coding: pseudonymisation.
Generalisation and suppression to k-anonymity: a step towards anonymisation, but k-anonymity alone is vulnerable to attribute disclosure, which is why l-diversity and t-closeness exist.
Aggregation to sufficiently large cohorts: often anonymous, provided small cells are suppressed and repeated queries cannot be differenced.
Differential privacy: the strongest formal guarantee, but the guarantee depends entirely on the privacy budget and its cumulative use.
Synthetic data: not automatically anonymous. A generator that memorises rare records can leak them, so synthetic outputs need the same re-identification testing as any other release.
Federated learning and homomorphic encryption: these limit exposure of raw data, but they do not by themselves make the data or the resulting model anonymous.

Why this matters for AI training data and models

The EDPB's Opinion 28/2024 on AI models and personal data is the key reference. It takes the position that anonymity must be assessed case by case, and that a model trained on personal data is not automatically anonymous. For a model to be considered anonymous, both the likelihood of directly or indirectly extracting personal data of individuals whose data was used in training, and the likelihood of obtaining such data from queries, should be insignificant. The opinion also addresses legitimate interests as a legal basis for development and deployment, applying the familiar three-step test, and the consequences that unlawful processing during development can have for later operation.

The practical governance consequences are:

Memorisation and extraction are testable. Membership inference and extraction attacks belong in your red teaming plan, not just in the research literature.
If a training set is only pseudonymised, erasure and rectification requests reach it, and you need to know how to honour them.
Document the anonymisation assessment for each dataset and model. We removed the names is not an assessment, and it will not survive scrutiny.

Common traps to avoid

Treating pseudonymisation as a scope exclusion. It is a safeguard, and one the GDPR expressly rewards, but the data stays personal.
Using de-identified as a synonym. It is a US term of art with its own meanings, including the HIPAA safe harbour and expert determination routes, and it does not map cleanly onto the GDPR concepts.
Ignoring the words or by another person in Recital 26. Identifiability is not judged solely on what your own team could do.
Anonymising once and never revisiting. Re-identification risk moves with the availability of auxiliary data and with compute.
Confusing data minimisation with anonymisation. Collecting less data is a separate obligation from making what you hold unidentifiable.

Related study notes

Frequently asked questions

Is pseudonymised data still personal data?

Yes. Recital 26 states that personal data which has undergone pseudonymisation and could be attributed to a natural person by the use of additional information should be considered information on an identifiable natural person. All GDPR obligations, including data subject rights, continue to apply.

Is hashing an email address anonymisation?

Normally not. Hashing is deterministic, so the same input always yields the same output, which supports linking. Where the input space is limited, as it is for emails and phone numbers, the hash can be reversed by brute force. Hashing is best treated as pseudonymisation.

Is synthetic data anonymous?

Not automatically. If the generative model has memorised rare or outlying records, synthetic output can reproduce or allow inference of real individuals' data. Synthetic datasets need the same singling-out, linkability and inference testing as any other release before you can call them anonymous.

Is a trained model personal data?

It can be. The EDPB's Opinion 28/2024 says the question must be assessed case by case, and that a model trained on personal data is not anonymous by default. Where personal data can plausibly be extracted from the model or obtained from its outputs, the model itself is in scope.

Test yourself

Try the free AIGP practice questions, or read the full AIGP study guide - free.