How to anonymize a dataset for AI/ML training under GDPR

To anonymize a dataset for machine learning, remove or mask the columns that identify people — both direct identifiers (name, email, national ID) and quasi-identifiers whose combination can single someone out (birth date, postcode, job title) — before the data reaches any training pipeline. Done properly, the result carries the statistical signal a model needs while no longer relating to identifiable individuals, which under GDPR Recital 26 takes it outside the regulation. The safest place to do this is locally, on the data owner’s own machine, so raw records never touch third-party infrastructure.

TL;DR

• Separate columns into direct identifiers, quasi-identifiers, and target/feature data — treat each differently.
• Mask direct identifiers with consistent tokens; generalise or drop quasi-identifiers that enable re-identification.
• Aim for k-anonymity: every combination of quasi-identifiers should match at least k people, not one. (See re-identification risk.)
• Anonymize before the data enters the training pipeline — ideally locally, so raw PII never leaves your environment.
• If you keep a restore key, it’s pseudonymization, and the dataset stays personal data. For training you usually want irreversible masking.

Step 1 — classify your columns

Most tabular datasets mix three kinds of column:

Column type	Examples	What to do
Direct identifier	name, email, phone, PESEL, SSN, account no.	Mask or remove
Quasi-identifier	birth date, postcode, sex, job title	Generalise, bucket, or drop
Feature / target	purchase amount, label, sensor reading	Usually keep

The mistake that breaks GDPR compliance is treating only the first row as “PII.” A model rarely needs the name — but it also rarely needs the exact birth date when a birth year or age band will do.

Step 2 — mask direct identifiers consistently

Replace each direct identifier with a token, and keep the mapping consistent so the same person is the same token across every row — otherwise you destroy relationships the model may legitimately need (e.g. multiple transactions per customer).

Before:
  Jan Kowalski, 85010212345, [email protected], Kraków, 1985-01-02, spent 240
After:
  [PERSON_7], [PESEL_7], [EMAIL_7], [CITY], 1985, spent 240

For training you generally want this irreversible — destroy the mapping once masked. If any downstream step must re-link to real people, keep a private key and treat the set as pseudonymized (see reversible anonymization).

Step 3 — generalise quasi-identifiers to reach k-anonymity

Masking names is not enough: a birth date + postcode + job title can still identify one person. Generalise until each quasi-identifier combination is shared by at least k individuals:

• Dates → year or age band (1985-01-02 → 1985 or 40–44)
• Full postcode → district or region (31-559 → 31-xxx)
• Rare categories → grouped (“other”)

This is the practical core of k-anonymity: if the smallest group sharing a quasi-identifier profile has k = 1, that row is re-identifiable no matter how many names you removed.

Step 4 — do it locally, before the pipeline

Where you anonymize matters as much as how. If you upload raw records to a cloud service to be masked, the raw PII has already left your control and, potentially, crossed a border. Masking on your own machine or infrastructure, before the dataset enters training, means the sensitive version never leaves the building. That’s the local-first approach behind Amaze’s on-device redaction.

Common mistakes

• Only removing names. Quasi-identifier combinations still re-identify.
• Inconsistent tokens. Breaks per-entity relationships the model needs.
• Masking after upload. The raw data has already left your environment.
• Keeping a key you don’t need. That makes the set pseudonymous and keeps it in GDPR scope.
• Free-text columns left raw. Names and IDs hide inside notes fields — scan those too.

FAQ

Does anonymized training data still fall under GDPR? No — if it is genuinely anonymized (irreversible, no re-identifiable combinations), it is outside the GDPR under Recital 26. Pseudonymized data (a key exists) stays in scope.

Do I need consent to train on anonymized data? Once data is truly anonymous it is no longer personal data, so the GDPR’s consent and lawful-basis rules don’t apply to that use. You still need a basis for the anonymization step itself.

What is k-anonymity in one line? A dataset is k-anonymous if every combination of quasi-identifiers is shared by at least k records, so no single row can be picked out.

Should I mask before or after splitting train/test? Before. Anonymize the whole dataset first so no raw PII exists in any split or cache.

Can I anonymize a database, not just a CSV? Yes — the same classification applies to table columns. Mask direct identifiers and generalise quasi-identifiers at export, before the data reaches training.

---

Amaze masks names (including Polish inflected forms), PESEL, NIP, REGON, KRS, emails, phones, IBANs and more across your files — entirely on your own machine, so raw records never leave your environment before training. See how it works.

Part of our guide: how to use AI without leaking client data.