Anonymization vs. pseudonymization
Anonymized data cannot reasonably be traced back to a person, so privacy law stops applying. Pseudonymized data hides the name behind a key.
See it
What it is
Anonymization is a one-way door. Strip and generalize the data until re-identification is no longer reasonably likely for anyone, which is the test GDPR actually applies: count the other tables you hold, the data someone else could plausibly get hold of, and the cost, time, and technology it would take them. Not a metaphysical guarantee, a judgement you can write down and defend. Do it properly and GDPR stops applying, because the result is no longer personal data. Pseudonymization swaps the direct identifiers for a token and keeps the key somewhere else. Still personal data, still fully regulated, just harder to read over someone's shoulder.
Reach for pseudonymization constantly: it is the practical control behind splitting your analytics store from your identity store, and regulators treat it as evidence you took security seriously. Reach for real anonymization only when you want data to outlive your retention policy, like multi-year aggregate reporting or a public dataset.
The gotcha is hashing. Hashing an email is pseudonymization, not anonymization: the input space is small enough to brute force, and anyone holding the same email reproduces the same hash and rejoins the data. Same trap with 'we removed the name': a birthdate, a zip code, and a gender narrow the field alarmingly fast in most real datasets. If a usable join key still exists and someone could reasonably be expected to reach it, you are pseudonymizing.
Ask AI for it
Review this database schema and data flow and produce a de-identification plan as a table with one row per column. Classify each field as direct identifier, quasi-identifier, or non-identifying, then say whether to drop it, pseudonymize it (name the technique: random token in a separate lookup table, HMAC with a secret pepper, or format-preserving tokenization), or generalize it (bucket ages into ranges, truncate zip to three digits, round timestamps to the day). Flag every remaining combination of quasi-identifiers that could re-identify someone, and state plainly which output is still personal data under GDPR and which is genuinely anonymous. Justify the anonymous calls against the reasonably-likely test: name the other data an attacker or a colleague could realistically join against, and the effort it would take, rather than asserting that re-identification is impossible.