Training data and GDPR: the questions to ask early

Published 21 September 2026 · 5 min read

If your training data contains information about identifiable people, data protection law applies regardless of how you obtained it or how the dataset is licensed. We are not lawyers and this is not legal advice — it is an account of the questions that come up, so that you can take the right ones to someone qualified.

Licence and lawful basis are different things

This is the misunderstanding that causes the most trouble. A dataset's licence is granted by whoever compiled it and concerns copyright in the compilation. Data protection rights belong to the people the data is about, and they cannot be licensed away by a third party.

So a CC0 dataset of personal data is a dataset that is free of copyright restriction and fully subject to data protection obligations. The two questions are independent and you need an answer to both. A permissive licence resolves one of them.

Public availability does not resolve it either. Information being accessible on the open web does not by itself make processing it lawful — that is a separate assessment, and one regulators have taken positions on.

Look for NC first and SA second. Under a CC licence, everything else is an attribution line in your model card.

The concepts that come up

Framed as the questions your legal team will ask you, since you are the one who knows the answers.

Lawful basis. Under what basis are you processing this? Consent, legitimate interests and the other bases have different requirements and different consequences. Legitimate interests is commonly relied on for model training and requires a documented balancing assessment rather than an assertion.
Purpose limitation. Data collected for one purpose cannot freely be reused for another. If a dataset was gathered for academic research, using it to train a commercial product may be a new purpose requiring its own basis — which is a large part of why research-only licences exist.
Transparency. People generally have a right to know their data is being processed. This is awkward for web-scraped corpora and is one reason provenance records matter.
Data minimisation. You should process what you need, not everything you can get. “We took the whole dump in case it was useful” is the opposite of this principle.
Erasure. People can request deletion. Removing a row from a dataset is straightforward; removing its influence from trained weights is not, and the question of whether you must is unsettled.
Special categories. Health, genetic and biometric data, racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership and sex life or sexual orientation carry heightened protection under Article 9. Faces and voices become biometric data under GDPR when they are processed by specific technical means to identify someone uniquely — face recognition, speaker verification — which catches many face and speech datasets and the models trained on them.

A clean licence on the dataset you downloaded says nothing about the images inside it. Provenance is the chain, and a restriction anywhere in it is a restriction on what you ship.

A component diagram of a personal-data detection engine. Text input passes to a PII Analyzer that calls a set of recognisers - built-in, custom patterns and custom models, the built-in ones using regex, checksum, NER and context - and returns the detected PII. — Personal data has to be located before anything can be said about lawful basis — regexes, checksums, NER and context, each catching what the others miss. Detection first, policy second. Image: microsoft/presidio · MIT repository

The erasure problem, honestly

This is the one with no clean answer, and it is worth understanding rather than hoping it does not arise.

If someone exercises a right to erasure and their data was in your training set, you can delete the row. Whether you must also remove its influence from the model is contested, and the technical means to do so — machine unlearning — remain an active research area rather than a reliable procedure. Retraining from a cleaned dataset works and is expensive.

What practitioners actually do is reduce exposure in advance: minimise personal data in training sets, prefer datasets with documented consent, pseudonymise or remove direct identifiers where the task does not need them, and keep records good enough to answer which model versions saw which data. That last one is the capability that makes the problem manageable rather than paralysing, and it is cheap to build and impossible to retrofit.

A grouped bar chart of ParrotScore (0 to 0.5) for four kinds of personal information (email, ip, phone num, phone num +1) across six Pythia models from 160m to 6.9b; email is highest, rising from about 0.31 to 0.49 with size, followed by IP addresses at about 0.26 to 0.43. — Pythia models of six sizes prompted with the text that preceded an email address, IP address or phone number in their training data, scored on how closely they reproduce it. Scores rise with model size, and the paper reports the largest repeats about one in five email addresses verbatim. Once personal data is in the weights, deleting the source row does not remove it. Image: Figure 2 of the paper · CC BY 4.0 · from “Personal Information Parroting in Language Models”, arXiv:2602.20580

What to do, practically

The engineering actions that make the legal conversation tractable:

A tree diagram with 'Anonymisation methods for tabular data' at the centre, branching up to eliminating direct identifiers (removal of columns), generalisation (numerical, categorical) and suppression (numerical, categorical, tuple suppression), and down to permutation (column-wise, group-wise), perturbation (value distortion, dimensionality reduction), synthetic data (generative machine learning) and differential privacy (local, global). — A taxonomy of anonymisation methods for tabular data: removing direct identifiers, generalising or suppressing values, permuting or perturbing them, generating synthetic data, and differential privacy. Minimising data at ingestion means choosing from a menu like this column by column, and each choice decides how much of the data's usefulness survives. Removing names alone is only the first box. Image: Figure 2 of the article · CC BY 4.0 · from Aufschläger et al. 2023, Information, “Anonymization Procedures for Tabular Data: An Explanatory Technical and Legal Synthesis”, doi:10.3390/info14090487

Inventory first. Know which of your datasets contain personal data, of what kind, from where, and under what terms. Our provenance post covers the record to keep. Without this, no legal assessment is possible and you will be asked for it.

Minimise at ingestion. Strip identifiers the task does not need, before training rather than after. A model that never saw an email address cannot leak one.

Prefer documented consent where you are working with faces, voices or health data. It is the difference between a defensible position and an argument.

Consider synthetic or licensed alternatives. For some tasks, generated data sidesteps the question entirely — see our synthetic data post for where that works and where it does not.

Involve legal before collection, not before launch. The cheap time to discover a problem is while the dataset is a plan.

Two stacked panels. 'Input text' reads: Please cancel my credit card effective September 19th. My name is Aarav Navuluri and my credit card number is 4095-2609-9393-4932. My email is aarav@presidio.site and I live in Amherst. 'Anonymized text' gives the same sentence with the date, name, card number, email and town replaced by DATE_TIME, PERSON, CREDIT_CARD, EMAIL_ADDRESS and LOCATION placeholders. — Minimising at ingestion in practice: the identifiers are replaced by their type, and the request itself, which is what a support model needs to learn from, survives. Stripping direct identifiers like this lowers exposure, but it is not by itself anonymisation in the GDPR sense if the people can still be re-identified from what remains. Image: microsoft/presidio · MIT repository

Questions people ask

Does GDPR apply if I am not in Europe?

It can. Under Article 3(2) it reaches organisations outside the EU that offer goods or services to people in the EU or monitor their behaviour there, so what matters is whose data you process and why, not where you are. Several other jurisdictions have adopted broadly comparable regimes, so the concepts here generalise even where the specific regulation does not. Get advice on your actual footprint.

Is a model trained on personal data itself personal data?

Contested, and it may depend on whether personal data can be extracted from the model. Memorisation and extraction attacks are a real research area, which makes the question less theoretical than it sounds. No reliable general answer exists today.

Can I use a public dataset of faces?

The licence may permit it and data protection law may still constrain it: identifiable faces are personal data, and they become special-category biometric data when processed to recognise or verify individuals. Several prominent face datasets have been withdrawn by their own creators over consent issues, so check a dataset's current status rather than citing the original paper.

What records should I keep?

For each dataset: source, date obtained, licence text as it stood, whether it contains personal data and of what kind, what processing you applied, and which model versions used it. That single table answers most of what anyone will ask you, and it cannot be reconstructed later.

Keep reading

ComplianceEU AI Act Article 10: what it requires of your training data ComplianceMedical AI training data: de-identification and its limits Medical imagingMedical image annotation: readers, reference standards, disagreement