GDPR compliance for machine learning models is not a checkbox cleared once during training. Personal data can enter a model at three separate points: the training set, the fine-tuning or RLHF data, and the inference inputs a live system processes. Each point carries its own lawful basis, its own disclosure obligation, and, in the case of the training set, a problem regulators still haven’t fully resolved: once personal data is baked into model weights, GDPR’s erasure and rectification rights don’t have a clean technical answer.
This piece walks through what the regulation actually requires at each stage, where the European Data Protection Board (EDPB) and the UK Information Commissioner’s Office (ICO) have issued specific guidance, and where the law is still catching up to the technology.
Lawful basis changes between training and deployment
Under GDPR, every processing operation needs a lawful basis under Article 6, and the basis that justifies collecting data for a training run is not automatically the basis that justifies using the resulting model against a live person’s data. The ICO’s guidance on AI and data protection treats these as distinct processing activities: training a model is one operation, running it on new personal data at inference is another, and each needs its own Article 6 justification and its own entry in the controller’s record of processing.
In practice, most organizations training models on personal data reach for “legitimate interests” (Article 6(1)(f)) rather than consent, because consent is hard to obtain at training-set scale and easy to withdraw. The EDPB’s Opinion 28/2024 addresses this directly: it builds on the EDPB’s earlier Guidelines 1/2024 on Article 6(1)(f) and requires controllers to run a three-step legitimate interest assessment: identify the interest, show the processing is necessary to achieve it, and balance that necessity against the data subject’s rights and expectations before relying on legitimate interests as the basis for developing an AI model. A generic interest framed as needing data to build better products does not clear that bar on its own; the assessment has to be specific to the model and the data involved.
A separate basis and a separate record at each entry point
The ICO’s training-versus-inference split is the minimum resolution. The operational unit is the entry point, and collapsing the three into a single processing activity is what produces a record of processing that cannot survive a regulator reading it next to the architecture diagram.
The training set. Data assembled before the model exists, usually at a scale where consent is not obtainable, which is why Article 6(1)(f) is the basis most controllers reach for. The legitimate interest assessment Opinion 28/2024 requires belongs to this entry point specifically: the interest identified is the interest in building this model, and the balancing test runs against the reasonable expectations of the people in this corpus, not against some general interest in AI. The Article 30 record for it needs the source of the corpus, the collection window, the categories of data subject it captures, and the retention applied to the raw corpus as something distinct from the retention of the model.
Fine-tuning and RLHF data. This is the entry point teams most often leave out of the record, because the data usually arrives from somewhere that already has a basis of its own: production transcripts, support tickets, human feedback collected during use. Reusing it to improve the model is a different purpose from the one it was collected for, and the compatibility of that reuse has to be assessed rather than assumed. Where the source is user interactions, the record also has to name which product and which tier they came from, because that is what determines whether the reuse was permitted at all.
Inference inputs. Every live request carries personal data supplied by, or about, an identifiable person, and running the model on it is its own operation with its own Article 6 basis, commonly contract or legitimate interest rather than whatever covered training. This is the entry point where retention actually bites: prompts, retrieved context and outputs are typically logged, and the record has to state for how long, who can read them, and which third parties (model provider, hosting provider, observability vendor) receive them and in what role.
Three entry points, three bases, three record entries. The version that fails an inspection is a single line in the ROPA that says “AI model” with one lawful basis behind it.
When a DPIA is required
Most production ML that scores, ranks or profiles individuals trips at least one Article 35 trigger, and the assessment has to happen before the system is built rather than as a retrofit once it is in production. The trigger test, the section-by-section structure, and how the assessment relates to the AI Act’s separate fundamental rights impact assessment are set out in the DPIA template for LLM deployment.
Article 22 and the automated decision problem
Where a model’s output drives a decision with legal or similarly significant effects, Article 22 attaches, and the three-element test, the CJEU’s Schufa reasoning and the review patterns that have and have not been treated as meaningful are covered in GDPR Article 22 and LLM automated decision-making.
What the ICO adds is a usable definition of the load-bearing phrase, “human intervention.” Its guidance on rights related to automated decision-making frames meaningful human review as requiring the reviewer to have the authority to change the outcome, access to the same data the model used, an understanding of the model’s logic, and the ability to weigh information the model didn’t consider. If the review process does not meet all four conditions, the system is still solely automated for GDPR purposes, and the Article 22(3) safeguards and the Article 13/14 disclosure obligations still apply.
Erasure, rectification and model anonymity
What erasure, rectification and objection require once data is in the weights, and how to answer a request, is set out in training-data privacy and data-subject rights. The anonymity test for a trained model is in pseudonymization versus anonymization under GDPR.
The upstream model you did not train
A 2026 analysis of rectification and erasure in ML supply chains, Models in the dark, makes a propagation point that lands hardest on organizations building on a third-party foundation model: whatever personal data is embedded in the base model travels into every fine-tune and derivative built on top of it, and the downstream controller usually has no visibility into what that is. Deleting the downstream fine-tuning set does not reach it.
That turns a technical unknown into a procurement question, and the time to ask it is before signature rather than after the first erasure request arrives:
- What documented process does the provider operate for erasure and rectification requests that have to reach the base model, and what response time does it commit to?
- What does the provider publish about the training corpus: its categories, its collection window, and whether any opt-out or exclusion mechanism was honored?
- Has the provider assessed whether the model itself is anonymous under the Opinion 28/2024 test, and will it share that assessment?
- What contractual commitment covers the inputs sent at inference, and does it exclude training on them?
Where the answers are thin, that is the residual risk, and the honest place to record it is the DPIA and the Article 13/14 disclosure, not a sentence asserting that the deletion was complete.
Practical steps for teams building on personal data
Teams should map every point where personal data enters the pipeline, including the training set, fine-tuning data, RAG retrieval corpus, and live inference inputs, and assign each a separate Article 6 basis and record of processing entry. They should run the DPIA before training starts, not after deployment, particularly for anything that profiles or scores individuals. If a human reviews model outputs, the organization should document that the review meets the four-part meaningful-intervention standard or treat the system as fully automated under Article 22. Before relying on a third-party foundation model, the organization should put the diligence questions above to the vendor and should not assume the model is anonymous without a documented, case-specific assessment. None of this is optional overhead bolted onto an ML project; under current EDPB and ICO guidance, it is what a defensible processing record looks like.
