Anonymization vs pseudonymization: what is the difference?

Anonymization and pseudonymization are two distinct techniques for reducing the identifiability of personal data, and the GDPR treats them in radically different ways. Pseudonymization replaces direct identifiers (name, tax code, email) with a fictitious value, but keeps a key or a linking table somewhere that allows tracing back to the data subject: for this reason the Regulation (Article 4(5) and Recital 26) still treats it as personal data for whoever holds the key, subject to every legal basis and ordinary obligation. Anonymization, instead, must be irreversible: no key, no reasonably available combination of information should allow re-identifying the person. Only in that case does the data fall outside the scope of the GDPR, as Recital 26 clarifies. The threshold for declaring a dataset genuinely anonymous is much higher than it looks, because the assessment must consider all means "reasonably likely" to be used for re-identification, not just the stated intent of whoever is processing the data.

That qualification is not absolute, though. The Court of Justice (4 September 2025, Case C-413/23 P) held that pseudonymized data is not personal data in all cases and for every person: for a recipient with no means reasonably likely to be used for re-identification it may not be. The assessment therefore belongs to each party rather than to the dataset once and for all, which is why the same table can be personal data for the party producing it and not for the party receiving it.

Why the threshold is so high

The risk almost never lies in the removed direct identifier, but in the seemingly harmless attributes left behind: zip code, date of birth, gender. Latanya Sweeney's study showed that these three fields alone uniquely identify roughly 87% of the US population, and Sweeney herself famously re-identified a governor's medical record by cross-referencing an "anonymized" health dataset with public voter rolls. This is the underlying mechanism that makes removing just name and email insufficient: combining indirect PII with a second external dataset is, in practice, the most effective re-identification vector there is.

The technical side: where the real risk sits

On a dataset used to train a model, the most common pseudonymization replaces identifiers with a token and keeps the correspondence table in a separate system: the real protection lies entirely in access control over that table, not in the token itself, which is often reversible with minimal effort if the key is weak or shared. The techniques that actually get closer to anonymization are different: generalization (rounding age or zip code into bands), suppressing rare records that alone would make an individual identifiable, adding calibrated statistical noise, and differential privacy, which mathematically guarantees that a single individual's presence or absence in the dataset does not detectably change the output of a model trained on it. Federated learning tackles the same problem from a different angle: the model trains on data that stays within each organization's perimeter, and only weight updates are shared, never the raw data. When none of these techniques is practical, synthetic data remains the most pragmatic alternative: it reproduces the statistical properties of the real dataset without containing information about existing people.

Enterprise example

An insurance company that wants to train a risk-scoring model on customers' health and demographic data pseudonymizes the records for internal development, keeping the correspondence key in a separate data clean room with restricted access: that dataset remains personal data and every processing operation requires a valid legal basis. If the same company instead wants to share a sample with an external partner for a proof of concept, pseudonymization is not enough: it needs to generalize age bands and zip codes, suppress cases rare enough to isolate a single policyholder, and verify that cross-referencing with public datasets (civil registry, voter rolls) still would not allow re-identification, before treating that sample as genuinely anonymous.

Why it matters for decision-makers

The difference is not academic: it determines whether an AI project stays inside the GDPR's perimeter or falls outside it, and therefore which legal bases, privacy notices and security obligations apply. Treating a merely pseudonymized dataset as "anonymous" is the most common compliance mistake in internal training projects, and the boundary is still settling: the EDPB pseudonymization guidelines (01/2025) remain a draft never finally adopted, and the anonymization ones (02/2026) are out for consultation. That leaves this point even more explicit. Choosing the right technique, tokenization, generalization, differential privacy or synthetic data, has to be made case by case, weighing re-identification risk against the utility the dataset must retain for the model.

This entry is informational and does not constitute legal advice: for decisions on regulated data, involve your DPO or legal counsel.