GDPR Compliance for Machine Learning Models: Practical Guide

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.

When a DPIA is required

Article 35 of the GDPR requires a data protection impact assessment before any processing “likely to result in a high risk to the rights and freedoms of natural persons,” and it names three triggers explicitly relevant to ML: systematic and extensive automated evaluation of personal aspects (including profiling) that produces legal or similarly significant effects, large-scale processing of special category data, and systematic large-scale monitoring of publicly accessible areas. Most production ML systems that score, rank, or profile individuals, including credit models, hiring screens, fraud detection, and recommendation engines that build behavioral profiles, hit at least the first trigger.

The DPIA has to happen before the system is built, not as a retrofit once it’s in production. It should document the processing operations and purposes, assess necessity and proportionality, identify risks to data subjects, and record the safeguards the controller plans to put in place. If the organization has a Data Protection Officer, that officer has to be consulted as part of the assessment. Where the AI model is also in scope of the EU AI Act as a high-risk system, the DPIA and the AI Act’s fundamental rights impact assessment remain separate obligations; one does not substitute for the other.

Article 22 and the automated decision problem

Article 22 gives a person the right not to be subject to a decision “based solely on automated processing, including profiling,” that produces legal effects or similarly significantly affects them, with three narrow exceptions: the decision is necessary for a contract, it’s authorized by law with safeguards, or it rests on the person’s explicit consent. Where one of those exceptions applies, Article 22(3) still requires the controller to implement safeguards, at minimum the right to obtain human intervention, to state a view, and to contest the decision. Article 22(4) adds a separate constraint: these decisions cannot be based on special category data (health, biometric, political opinion, and so on) unless a specific Article 9(2) exception applies alongside additional safeguards.

The load-bearing phrase for ML teams is “human intervention,” and both the ICO and EDPB have been consistent that inserting a human reviewer who rubber-stamps the model’s output does not take a system out of Article 22’s scope. The ICO’s 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 Article 13/14 disclosure obligations still apply.

The erasure problem GDPR doesn’t cleanly solve

Article 17’s right to erasure and Article 16’s right to rectification were written for data stored in identifiable records, not for data whose influence is distributed across millions of model parameters. A 2026 analysis of GDPR erasure and rectification obligations in ML supply chains lays out why this breaks down in practice: controllers often cannot reliably determine what a specific individual’s data contributed to a trained model, full retraining is the only method with guaranteed correctness and is often prohibitively expensive, and machine unlearning techniques, approaches designed to remove a data point’s influence without full retraining, can degrade model performance or leave verification gaps, since there’s no reliable way to confirm the influence was actually removed. The same analysis flags a compounding problem for anyone using third-party foundation models: personal data embedded in an upstream model propagates into downstream fine-tunes and derivatives, and the controller of the downstream model frequently has no visibility into what’s baked into the base model it started from.

None of this suspends the obligation. It does mean the practical compliance answer is architectural, not just procedural: organizations should identify which models were trained directly on data subject to erasure requests, maintain the ability to retrain or exclude specific sources, and explain accurately in Article 13/14 disclosures what erasure means for a model versus a database record. The claim that “the row was deleted” is not the same as the claim that “the model’s memorization of that row was removed.”

Anonymization is not a given

A recurring mistake is treating a trained model as automatically anonymous because it doesn’t store raw records. The EDPB’s Opinion 28/2024 rejects that assumption and requires a case-by-case assessment of whether a given model, given its training data and its exposure to inference queries, still allows identification of a data subject through means reasonably likely to be used, including membership inference and model inversion techniques. If a model can be shown to genuinely resist that kind of extraction, it falls outside GDPR’s scope for that purpose; if not, the model itself is personal data, with the record-keeping and rights obligations that entails.

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 ask the vendor what erasure and rectification process exists for personal data that may be embedded in the base model 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.