GDPR AI model compliance cannot be decided by asking whether a training file was deleted or whether model weights look unintelligible. Personal data may be processed during collection, preparation, training, evaluation, fine-tuning, prompting, retrieval, logging, output, and model extraction. The controller must identify those operations, their purposes, actors, lawful bases, necessity, safeguards, and data-subject effects. A model may be anonymous in one controlled context and not in another with greater access, auxiliary data, or extraction capability.
EDPB Opinion 28/2024 addresses three connected questions for supervisory authorities: when AI models may be anonymous, how legitimate interests may support development or deployment, and how unlawful processing in development affects later deployment. It is intentionally case-specific. Teams should turn its factors into an evidence file, not a checkbox declaring the model GDPR-compliant.
Define the model, actors, and processing stages
Identify base model, checkpoints, adapters, embeddings, retrieval indexes, filters, prompts, logs, evaluation sets, and deployment wrappers. Map developer, deployer, data broker, hosting provider, customer, and downstream recipient roles rather than assuming one controller. For each stage, record data sources, categories, special-category or criminal-offence data, children, geography, purpose, retention, access, outputs, and rights handling. Version the analysis because fine-tuning, retrieval, new tools, or public release can change identifiability and reasonable expectations.
Test anonymity against identification and extraction
The EDPB's summary of the Opinion says a model should be very unlikely both to identify people whose data was used and to allow extraction of their personal data through queries. Assess singling out, linkage, inference, memorization, membership inference, prompt extraction, model access, auxiliary datasets, and likely attacker means. Test representative and high-risk records, rare sequences, repeated data, canaries, and privileged access. Pseudonymization, removal of names, or difficult extraction alone does not establish anonymity.
| Factor | Question | Evidence | Reassessment trigger |
|---|---|---|---|
| Training selection | Were identifiers and unnecessary records minimized? | Dataset lineage and filters | New corpus |
| Memorization | Does the model reproduce unique data? | Extraction and canary tests | New checkpoint |
| Identification | Can outputs be linked to a person? | Attack evaluation with auxiliary data | New integration |
| Access | Who can query weights or gradients? | Interface and privilege model | Public or partner release |
| Safeguards | Do rate, output, and monitoring controls reduce means? | Control tests | Control removal |
| Residual likelihood | Is identification or extraction very unlikely? | Reasoned contextual conclusion | Threat or technique change |
Apply the legitimate-interest test stage by stage
State a lawful, specific, real interest for development and separately for deployment. Then prove strict necessity: compare less intrusive data, sampling, licensed sources, synthetic data, local processing, retrieval instead of training, narrower retention, and smaller models. Finally balance the interest against rights and freedoms using source context, relationship, data nature, scale, public availability, vulnerability, reasonable expectations, model uses, outputs, and safeguards. The GDPR official text remains the governing law, including principles, lawful bases, transparency, rights, privacy by design, security, and DPIA duties.
| Step | Required record | Challenge question | Possible outcome |
|---|---|---|---|
| Purpose | Specific development or deployment interest | Is it lawful and current? | Proceed or redefine |
| Necessity | Alternatives and proportionality | Could less data achieve it? | Minimize or stop |
| Expectations | Source, relationship, notice, context | Would people expect this use? | Add limits or reject |
| Impact | Possible identification, bias, misuse, rights friction | Who bears the harm? | Mitigate or reject |
| Safeguards | Technical and rights measures | Do they change actual impact? | Conditional approval |
| Review | Metrics and material-change triggers | Does deployment stay within scope? | Continue, pause, reassess |
Address unlawful training data before deployment
Do not assume a new lawful basis for inference erases an unlawful development history. The Opinion indicates unlawful processing in development may affect deployment unless the model has been duly anonymized, with the exact consequence assessed case by case under applicable law. Preserve lineage and distinguish datasets and model versions. Investigate the defect, stop continuing unlawful collection, evaluate deletion or retraining, isolate affected artifacts, test whether personal data remains, assess deployment dependence on the earlier processing, and seek supervisory or legal guidance where appropriate. Acquisition contracts should disclose provenance and allocate cooperation, remediation, and withdrawal rights.
Design deployment and rights controls
Limit purposes, users, prompts, tools, outputs, retention, and onward disclosure. Provide transparency that describes meaningful processing rather than exposing security-sensitive detail. Route access, objection, erasure, and correction requests across source data, retrieval stores, logs, and feasible model measures; document technical limits rather than denying requests categorically. Run a DPIA where likely high risk and connect it to model evaluation and incident response. The ICO AI guidance provides practical discussion of accountability, minimization, security, individual rights, and privacy-enhancing techniques.
Monitor the evidence after approval
Track extraction attempts, personal-data outputs, rights cases, source changes, user populations, new tools, model access, incidents, complaints, mitigations, and evaluation coverage. Approval conditions should specify thresholds that pause a release or require review. Reassess when weights are released, an API becomes public, context windows expand, retrieval is added, safeguards change, a new fine-tune enters production, or research changes feasible attack means. Procurement teams should obtain enough model and data documentation to perform this continuing review, not rely on a supplier's one-time anonymity label.
Assemble a review file that survives challenge
Keep lineage for each source, collection context, controller, terms, lawful-basis decision, notice, categories, geography, filtering, retention, and objections. Record model artifact hash, code, parameters, evaluation prompts, retrieval sources, safeguards, interface, access classes, and purpose. Document identification and extraction attacks, attacker access and auxiliary data, representative and rare-record tests, red-team results, limits, failures, and residual likelihood. For legitimate interest, retain the interest, evidence it is real, alternatives, necessity, expectations, population impacts, safeguards, objection handling, and approver. Map fairness, transparency, minimization, accuracy, storage, security, rights, transfers, processors, and DPIA separately from the lawful basis.
Where provenance is unlawful or uncertain, preserve investigation scope, stopped collection, affected versions, model dependence, anonymization evidence, deletion or retraining feasibility, restrictions, and legal decision. For purchased models, retain supplier answers, source limits, evaluation access, warranties, audit evidence, rights and incident cooperation, change notice, withdrawal, remediation, and exit. Define metrics for personal-data output, extraction attempts, blocked prompts, rights cases, complaints, source changes, safeguard failures, privileged access, and out-of-scope use. List pause authority and review triggers. Keep rejected releases and superseded analyses; they show that review changed decisions and stop later teams from repeating an approach without understanding failed assumptions.
- Distinguish a model's development purpose from every customer's deployment purpose; necessity and balancing for one context cannot be inherited automatically by another controller.
- Test privileged weight access, fine-tuning interfaces, embeddings, evaluation tools, and logs separately from the public API because identifiability means differ substantially.
- Evaluate records that are unique, repeated, sensitive, publicly searchable, or associated with vulnerable people; average extraction performance can hide severe individual impact.
- Consider whether transparency itself creates risk, then provide useful layered information without publishing attack instructions or personal examples.
- Connect objection and erasure handling to future training suppression, source correction, retrieval removal, output controls, and version decisions rather than promising impossible weight-level deletion casually.
- When safeguards support the balancing test, make them approval conditions with owners and tests; optional future mitigations do not reduce current impact.
- Procurement should restrict unannounced source expansion, fine-tuning, model substitution, retention, or access changes because each can invalidate the buyer's recorded analysis.
The approval outcome should be explicit: approved for a named context, approved with enforceable conditions, limited to research, paused for evidence, or rejected. State who may access the artifact, which interfaces and populations are covered, prohibited uses, retention, monitoring, rights handling, incident triggers, and expiry. Deployment systems should enforce material conditions where possible. A review document stored in a governance folder cannot control an unrestricted model endpoint. Reapproval should be required when a condition cannot be technically enforced or when operating evidence contradicts the assumptions used in anonymity or balancing analysis.
Record dissent and uncertainty so approval does not falsely imply that every privacy question has been resolved.
GDPR AI model review takeaways
- Map every model artifact, actor, processing stage, purpose, and data source before choosing a lawful basis.
- Assess both identification and extraction using realistic access, auxiliary data, and attacker means.
- Run legitimate-interest purpose, necessity, and balancing tests separately for development and deployment.
- Treat public availability as one contextual factor, not permission for unrestricted training.
- Investigate unlawful source processing and its effect on the model before approving deployment.
- Version the evidence and reassess on new data, checkpoints, access, integrations, safeguards, and attacks.
GDPR AI model compliance FAQ
Is a model anonymous because it cannot be read like a database? No. Practical identification and extraction likelihood in context are the relevant questions.
Can public web data support legitimate interest? Public availability is only one factor. Purpose, necessity, expectations, impact, and safeguards still require case-specific assessment.
Does deleting training data cure unlawful collection? Not automatically. The controller must assess continuing model effects, anonymization, deployment dependence, and available remediation.
Conclusion
A GDPR review for AI models is an evidence chain from source to deployed behavior. Test anonymity rather than asserting it, make legitimate interest survive necessity and balancing, and confront unlawful provenance before reuse. Continuous versioned review is essential because the same weights can present a different privacy risk when access, tooling, data, and attackers change.