GDPR and AI Training Data: What You Need to Know Before Training on Personal Data

If you're building an AI product that trains on real-world data, there's a question you can't avoid: does that data contain personal information about identifiable people? If the answer is yes — even partially — you're operating inside GDPR's jurisdiction, and the rules are more demanding than many teams realise.

The EU's data protection framework was not designed with machine learning in mind. But it applies to it. Regulators are actively investigating AI training practices, enforcement actions are accumulating, and the EU AI Act adds an overlapping layer of obligations. Getting this right before you train at scale is significantly cheaper than fixing it afterwards.

This guide covers the key GDPR obligations that apply when you use personal data to train AI models — and what compliant practice looks like in 2026.

Why Training Data Is a GDPR Issue

The definition of personal data under GDPR is broad: any information that relates to an identified or identifiable natural person. This captures far more than names and email addresses.

Training datasets built from web scraping, customer interactions, support tickets, medical records, user-generated content, or behavioural logs almost certainly contain personal data. Even datasets that appear anonymised often aren't — re-identification attacks have demonstrated that supposedly anonymised records can be linked back to individuals using auxiliary information.

The key question isn't whether your dataset is labelled as personal. It's whether a natural person could reasonably be identified from it, directly or in combination with other data. If the answer is yes — or even possibly yes — GDPR applies to the collection, storage, and processing of that data for training purposes.

Training is processing. Running a training job on personal data is a processing activity under Article 4(2). That means you need a lawful basis, you need to meet data minimisation requirements, you need to respect retention limits, and you need to be able to respond to data subject rights requests — including the right to erasure.

Lawful Basis for Using Personal Data to Train AI

Article 6 of GDPR requires that every processing activity has a lawful basis. For AI training, the most commonly considered bases are:

Consent

If data subjects have explicitly consented to their data being used for AI training, you have a clean basis. The problem is that consent must be specific, informed, freely given, and unambiguous. A generic "we may use your data to improve our services" clause almost certainly doesn't cover training an AI model on user data — the Article 29 Working Party and its successor the EDPB have been clear that purpose specification must be granular.

Retrospective consent — going back to existing users to ask for AI training consent — is difficult to obtain at scale and often results in low take-up rates.

Legitimate Interests

Legitimate interests under Article 6(1)(f) is the basis most organisations reach for when consent isn't feasible. It requires passing a three-part test: there must be a legitimate interest, the processing must be necessary, and the interests of the data controller must not be overridden by the rights and interests of data subjects.

The EDPB's guidance on legitimate interests (Opinion 1/2024 on the legitimate interest legal basis) makes clear that the necessity and balancing tests must be conducted rigorously. Simply asserting that model improvement is a legitimate interest doesn't satisfy the requirement.

For AI training specifically, the balancing test is often difficult. Data subjects typically have no expectation that their interactions will be used to train AI systems. The processing is often at significant scale. And the downstream uses of the trained model may be unpredictable — which makes the balancing assessment harder to perform honestly.

Public Interest and Research Exemptions

Article 6(1)(e) covers processing necessary for the performance of a task carried out in the public interest. Article 9(2)(j) provides a basis for processing special category data for scientific research purposes. Academic and medical research institutions have more flexibility under these provisions than commercial organisations — though the exemptions still require appropriate safeguards.

The ICO's guidance on AI and data protection notes that commercial AI development is unlikely to qualify for research exemptions in most cases.

What This Means in Practice

For most commercial AI products, the honest answer is that establishing a clean lawful basis for training on existing personal data is difficult unless:

• You obtained specific consent at the point of collection that contemplated AI training
• You can genuinely satisfy the legitimate interests balancing test with documented analysis
• You're building on synthetic or sufficiently anonymised data

The Right to Erasure Problem: Machine Unlearning

Article 17 of GDPR gives data subjects the right to request deletion of their personal data. Under normal data processing, deletion means removing records from databases and backups. With AI training data, it's more complicated.

When personal data has been used to train a model, that data is embedded in the model's weights. You can delete the training record, but the model has already learned from it. Some researchers have demonstrated that training data — including specific personal details — can be extracted from large language models through targeted queries.

The technical field of machine unlearning attempts to address this. Unlearning techniques aim to adjust model weights to remove the influence of specific training examples without retraining the entire model from scratch. The field is advancing rapidly, but most production-grade unlearning approaches are still computationally expensive, imperfect, and difficult to verify.

Regulators haven't yet issued detailed guidance on exactly what erasure means in the context of trained models. The practical risk is that a data subject submits an erasure request, you can demonstrate you've deleted the training record, but the model has retained information about that individual. Whether that constitutes a violation is legally unresolved — but the risk is real.

Practical implications:

• Document which individuals' data is in each training dataset, so you can respond to erasure requests
• Implement data lineage tracking from collection through to training runs
• Design training pipelines so you can retrain from scratch or apply unlearning techniques when necessary
• Consider versioning models so you can roll back to a version trained before a particular data subject's data was included

Data Minimisation and Anonymisation for Training Sets

Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." This principle of data minimisation applies to training data just as it does to any other processing.

Common violations:

• Training on full user records when only specific fields are relevant to the model's task
• Retaining training data indefinitely when a shorter retention period would suffice
• Including sensitive categories of data (health, financial, political views) in training sets when the model's purpose doesn't require it

Anonymisation is the gold standard for escaping GDPR's scope entirely. If data is truly anonymised — such that no individual can be identified from it, directly or indirectly, now or in future — it falls outside the regulation. The challenge is that true anonymisation is harder to achieve than most teams assume.

The ICO's anonymisation guidance emphasises that anonymisation is a spectrum, not a binary state. Pseudonymisation (replacing identifiers with pseudonyms) is not anonymisation — pseudonymised data remains personal data under GDPR. Aggregation reduces re-identification risk but doesn't eliminate it. Differential privacy techniques can provide mathematical guarantees of anonymisation but require careful implementation.

Practical steps:

• Conduct a re-identification risk assessment before treating a dataset as anonymised
• Remove or hash direct identifiers (names, emails, IDs) as a baseline
• Consider suppression, generalisation, and noise addition for quasi-identifiers
• Apply differential privacy if you're publishing or releasing models trained on sensitive data
• Document your anonymisation methodology and its limitations

Synthetic Data as a GDPR-Friendly Alternative

Synthetic data — artificially generated data that mimics the statistical properties of real datasets without containing actual personal information — is increasingly viable as a GDPR-compliant alternative to training on personal data.

The approach involves training a generative model on real data to produce synthetic records that are statistically similar but don't correspond to real individuals. The synthetic dataset is then used to train downstream models.

Advantages:

• Falls outside GDPR's scope if genuinely not personal data
• Can be augmented, shared, and retained without data subject rights implications
• Can be used to balance underrepresented groups in training data
• Simplifies compliance documentation significantly

Limitations:

• Quality depends on the underlying generative model, which itself must be trained on personal data
• Synthetic data may not capture rare events or edge cases that real data would contain
• Some downstream tasks require the authenticity of real data (fraud detection, medical diagnosis)
• The generative model itself remains subject to GDPR obligations

Synthetic data is best understood as one tool in a compliance toolkit, not a universal solution. But for many AI training use cases — particularly those involving large language models trained on common-domain text — it offers a meaningful compliance path.

The EU AI Act Intersection

The EU AI Act, which became progressively applicable from 2024 to 2026, adds obligations that intersect with GDPR but are not identical to it.

Under the AI Act, high-risk AI systems (which include systems used in employment decisions, credit scoring, education, and certain public sector applications) must meet requirements around:

• Training, validation, and testing data governance (Article 10)
• Data quality and representativeness
• Examination for biases
• Documentation of data provenance

Article 10 specifically requires that training datasets be "relevant, representative, free of errors and complete to the best extent possible" and that "appropriate data governance and management practices" be applied.

The AI Act's data governance requirements overlap significantly with GDPR's data minimisation, accuracy, and documentation obligations — but they're not identical, and compliance with one doesn't automatically mean compliance with the other. High-risk AI developers need to map requirements from both frameworks.

The AI Act also requires providers of general-purpose AI models (like foundation models) to publish summaries of training data used, which creates transparency obligations that interact with IP and data protection considerations.

Transparency Obligations When Deploying AI Trained on Personal Data

GDPR's transparency principle under Article 5(1)(a) requires that data subjects know how their data is being processed. When you use personal data to train AI, this creates disclosure obligations at two points:

At the point of collection: Your privacy notice must inform data subjects that their data may be used for AI training, what the legal basis is, and what their rights are. A generic "service improvement" description is unlikely to be sufficient.

When deploying AI systems: If your AI system makes or influences decisions about individuals, those individuals have rights under Article 22 (automated decision-making) and the right to receive meaningful information about the logic involved.

For AI trained on personal data, transparency is also technically difficult. "Black box" models make it hard to explain why a model produced a particular output. Regulators have been reluctant to require full algorithmic transparency — which would often be impractical — but the expectation of meaningful explanation remains.

The AI Act adds a further obligation: natural persons interacting with AI systems in customer-facing contexts must be informed that they're interacting with AI, unless it's obvious.

Practical Compliance Steps

Building GDPR-compliant AI training practices is not a one-time exercise. It requires embedding compliance into your data and ML engineering workflows.

Step 1: Audit your existing training datasets. Identify what personal data is present, from which sources, collected under what legal basis, and with what consent language. This is often the most revealing step — many teams discover training data of uncertain provenance.

Step 2: Establish lawful basis before you train, not after. If you can't clearly articulate the lawful basis for processing personal data in a training run, don't proceed until you can. Retrofitting compliance onto trained models is significantly harder than building it in from the start.

Step 3: Implement data lineage tracking. Know which individuals' data went into which training run. This is essential for responding to erasure requests and for demonstrating compliance to regulators.

Step 4: Document a data retention policy for training data. How long do you need to keep training datasets? Training logs? Model checkpoints? Define retention periods and implement automated deletion.

Step 5: Update your privacy notice. If you're training on customer or user data, your privacy notice must disclose this. Review the specificity of the language — "improving our services" is not the same as "training machine learning models on your interaction data."

Step 6: Conduct a DPIA. A Data Protection Impact Assessment is mandatory under Article 35 for processing that is likely to result in high risk to individuals' rights and freedoms. AI training at scale on personal data almost certainly qualifies. Document the risks and the mitigations.

Step 7: Consider synthetic data or differential privacy for high-risk training. For training sets involving sensitive data categories or at significant scale, the compliance overhead of using real personal data may outweigh the benefits compared to synthetic alternatives.

Start with Your Website

Before you can build compliant AI systems, you need to understand what personal data you're already collecting and processing — including the trackers, analytics, and third-party scripts running on your website.

Run a free scan at https://app.custodia-privacy.com/scan to see which technologies are active on your site, whether they're collecting personal data before consent, and what your current GDPR exposure looks like. It's the first step toward a complete picture of your data processing activities.

This post provides general educational information about GDPR and AI training data compliance. It does not constitute legal advice. Requirements vary by jurisdiction, processing activity, and specific circumstances — consult a qualified data protection professional for advice tailored to your situation.