GDPR for AI systems and machine learning: what applies

When does GDPR for AI systems and machine learning apply to our model?

When a customer, contract or regulator asks how your AI product complies with the GDPR, start from one fact: the GDPR applies whenever training or running a model involves personal data, and it requires no audit or certificate, so your organization as controller must produce its own evidence. Whether a given model is in scope depends on facts about the data, the purpose and the people affected, not on the technology label. Work through three questions in order: what personal data entered the training set and what the model can output, what purpose each stage serves, and who the affected people are and what they would reasonably expect. The organization owns each answer and the decisions that follow from it. An implementation partner can prepare the systems, data flows and records that make those answers traceable, and an independent assessor is needed only where the buyer asks for an external opinion.

Start with anonymity, because it is the claim most often made and least often tested. The EDPB's Opinion 28/2024 on AI models says anonymity is assessed case by case: it must be very unlikely both that people whose data trained the model can be identified and that such data can be extracted from the model through queries. Document the tests you ran, such as membership inference and training-data extraction attempts, against the model version you actually deploy. A model that can be queried back into personal data stays in scope even if no one stores the raw dataset. Confirm with your technical team which prompts, logs, fine-tuning sets and retrieval indexes also contain personal data, because each is processing in its own right.

Then check the lawful basis and the training history. If you rely on legitimate interest for development or deployment, the opinion applies a three-step test, and it says a service may rely on that basis only where the processing is strictly necessary and the balancing test is met. Record a legitimate interest assessment for each purpose. Also trace the provenance of the training data: the opinion says a model built with unlawfully processed personal data may affect the lawfulness of its deployment unless it has been duly anonymised. If a dataset was scraped or obtained without a basis, that finding can follow the model into production, so resolve it before the model ships rather than after a customer asks.

Which three tests decide whether an AI model is in scope and lawful?

Three questions settle most GDPR exposure for an AI model: whether the model is anonymous, which lawful basis covers training and deployment, and whether people would reasonably expect their data to be used that way. The first decides whether GDPR applies to the model at all, and the other two decide whether the processing is lawful. Teams should record each answer separately for every model and every use.

Is the model anonymous?

EDPB Opinion 28/2024, adopted on 18 December 2024, says anonymity of an AI model is assessed case by case. The model is anonymous only if it is very unlikely that people whose data trained it can be identified, and very unlikely that such data can be extracted from the model through queries. Keep evidence of memorization and extraction tests, membership inference testing, the threat model used, and the model version tested. The answer changes with the training data, the model architecture, and whether outputs are exposed through an API or open weights.

Which lawful basis fits?

Opinion 28/2024 applies a three-step legitimate interest test to both developing and deploying AI models. It notes that services such as a conversational agent or AI used to improve cybersecurity may rely on legitimate interest only where the processing is strictly necessary and the balancing test is met. Keep a written assessment for training and a separate one for deployment, with the necessity analysis, the less intrusive alternatives considered, the balancing record, and the safeguards applied. Confirm with counsel whether consent or another basis is more appropriate for a given use. The conclusion changes with the model's purpose and the people affected.

Would people reasonably expect it?

Opinion 28/2024 lists factors for whether people can reasonably expect their data to appear in an AI model. These include whether the data were public, the relationship between the person and the controller, the context and source of collection, potential further uses of the model, and whether people know their data are online. Keep a source inventory for each dataset, the privacy notice wording that covers AI training, scraping or licensing provenance, and a written expectation analysis. A model built for customer support and a general-purpose model raise different answers, so each needs its own record.

How the legitimate interest test applies to AI training and deployment

EDPB Opinion 28/2024 asks controllers to test legitimate interest in three steps before relying on it for AI development or deployment, and each step should leave a written record the organization owns. The sequence ends with a decision on whether the processing can proceed, and on what conditions.

Define the purpose of the AI processing
Start by writing down what the model or AI system is for, which personal data it touches in training, testing and deployment, and who the controller is for each phase. The organization's privacy or product owner drafts this, and the output is a documented purpose statement that names each processing stage separately. Training a model and running it against live user queries are different operations and should be recorded as different purposes. Confirm the precise wording of the opinion's first step against the EDPB text before you adopt your own template.
Confirm the interest is lawful and specific
Establish that the interest pursued is lawful, clearly articulated and real rather than speculative. The controller, with input from product and legal, records the interest in plain terms, such as the functionality the model provides or the security outcome it supports. The output is a short interest statement that a supervisory authority could read and understand without the internal product context. Keep the statement tied to the documented purpose from the previous step.
Document why the processing is strictly necessary
Test whether the same purpose could be met with less personal data, with anonymized or synthetic data, with a smaller training set, or without the model at all. The privacy team and the engineering lead run this check together and record the alternatives considered and why each was rejected. The output is a necessity finding. The opinion ties reliance on legitimate interest for services such as a conversational agent or AI used to improve cybersecurity to this strict necessity condition, so a weak finding here usually ends the analysis.
Assess the impact on the people affected
Map the individuals whose data is used, including people who appear in training sources and people who interact with the deployed system. For each group, note the nature of the data, the source, the relationship with the controller, and whether people could reasonably expect this use. The opinion lists criteria for that expectation, including whether the data was public and whether people know their data is online. The output is the impact section of the balancing record, with each risk identified and rated.
Weigh interests and record the safeguards
Balance the controller's interest against the impact on individuals and record the outcome. Where the balance is only met with conditions, list the safeguards that justify it, such as filtering of sensitive data, output controls against regeneration of personal data, opt-out mechanisms or retention limits. The output is a signed balancing record that the organization keeps and can produce on request. Legal counsel and the data protection officer, where one is designated, should review the conclusion before the processing starts.
Link the assessment to the DPIA and records
Check whether the processing also triggers a data protection impact assessment under Article 35, for example large-scale automated evaluation with significant effects. Reflect the outcome in the records of processing and the privacy notice so that the stated purpose, interest and safeguards match what the system does. The output is a cross-referenced file where the legitimate interest assessment, the DPIA and the records agree. Where deployment is also covered by AI Act deployer duties, the same file should show how the provider's information was used.
Decide, review and retain the assessment
Record a clear decision: proceed, proceed with conditions, or stop and seek another lawful basis. Set an owner and a trigger for review, such as a material change in the model, its data sources or its use. The output is a dated decision with the approver named, kept under version control. Ask any outside adviser to confirm that the assessment is written by the organization and reflects its own processing, because the accountability for the conclusion stays with the controller.

What happens when a model was built on unlawfully processed data

EDPB Opinion 28/2024 says that where an AI model was developed with unlawfully processed personal data, this could affect the lawfulness of its deployment, unless the model has been duly anonymised. For a deployer, the practical consequence is that the training history of a model you did not build can become your compliance problem the day you put it into production. Before you ship, treat the provenance of the model as part of your own lawfulness assessment, not as the provider's private matter.

Ask the vendor or model provider for three things in writing: the data sources used for training, the lawful basis relied on for each source, and the anonymity assessment for the trained model, including how the provider tested whether training data could be extracted through queries. Check that the sources match what the provider describes in its documentation, and that web-scraped or third-party datasets have a documented basis and a record of the steps taken to filter out data that should not have been used. If the provider cannot answer, or answers only with general assurances, record that gap in your DPIA and in your decision on whether to deploy at all.

Automated decisions raise the stakes. The Dutch DPA's fine of EUR 824 990 000 against Uber, announced on 8 October 2026, concerned unlawful automated decision-making and insufficient safeguards, so a model that scores or ranks people can draw regulatory attention even when the deployer did not collect the training data. Read the EDPB news item on the Uber decision directly, and confirm with your counsel which parts of the reasoning apply to your use case and jurisdiction.

How automated decisions, DPIAs and AI Act deployer duties fit together

Article 22(1) gives people the right not to be subject to a decision based solely on automated processing, including profiling, where the decision produces legal effects or similarly significantly affects them. The right attaches to the decision, not to the model. A score that informs a decision made by a person may fall outside it, while a score that automatically approves or refuses an application may fall inside it. Where the right applies, human review has to be meaningful. The reviewer needs authority to change the outcome, access to the inputs and factors behind the result, and enough time and training to question it. A rubber stamp does not meet this test. The Article 29 Working Party guidelines on automated decision-making and profiling explain how supervisory authorities read these points.

Scope test: Map each model output to the action that follows. Identify which outputs take effect without a person deciding.
Reviewer authority: Document who can override a result, and record overrides so the independence of review can be shown.
Explanation support: Make the main factors behind a score visible to the reviewer and, where needed, to the affected person.
Exceptions: Article 22 sets out conditions under which automated decisions can proceed with safeguards. Confirm the lawful route with counsel before relying on it.
Rights handling: Connect objection and challenge routes to the decision notice and log every request.

Check whether each automated decision flow has a recorded override path and whether anyone has used it.

What makes a GDPR for AI systems review more or less demanding

The GDPR does not set a fixed checklist for AI systems. The effort a review takes depends on what data goes in, what the model does to people, and how many parties and environments touch that data. The six factors below are the ones a buyer should raise before asking for a quote.

Number and sensitivity of data sources

Each source of personal data adds a lawful basis question, a retention rule and a set of rights requests to trace. Health, biometric, criminal offence or other special category data raises the bar, and large-scale use of such data also triggers DPIA duties under Article 35(3). Ask whether every training and inference source is inventoried with its origin, category and legal basis. Reduced effort usually comes from fewer sources, documented provenance and removal of special category fields before training.

Model built in-house or obtained

A team that trains its own model controls the training data, the lawful basis and the anonymity assessment. A third-party model shifts part of that burden to the provider, but the deployer still needs the provider's documentation to assess its own processing. EDPB Opinion 28/2024 treats anonymity of a model as a case-by-case question, so a provider's claim alone rarely settles it. Ask what the provider documents about training data origin and whether it will support your anonymity or lawful basis assessment.

Legal or similarly significant effects

When a model's output decides credit, employment, insurance, access to services or similar outcomes, Article 22 applies to decisions made solely by automated means. That brings rights to human intervention, explanation and contestation, and usually a DPIA under Article 35(3). Systems that only support a human decision carry less exposure, but only if the human review is real and documented. Ask whether any output triggers a decision without meaningful human review.

Systems and environments in scope

Each model, feature store, training pipeline, vector index, log store and test copy holds personal data and needs its own access controls, retention and deletion. Production data copied into development or notebooks is a common source of findings. Reduced effort comes from a single documented data flow with masked or synthetic data outside production. Ask for a list of every system and environment that stores or processes training or inference data.

Third parties and sub-processors

Hosted model APIs, labeling vendors, cloud GPU providers, monitoring tools and support staff with access can each act as processors or sub-processors. Each one needs a processing agreement, a documented transfer basis if data leaves the EEA, and a place in the records of processing. Self-hosted platforms inside the client's own infrastructure reduce this count. Ask for the full sub-processor chain and the country where each party can access data.

Maturity of records and DPIA practice

Teams with a current record of processing, existing legitimate interest assessments and a DPIA method can extend them to AI work. Teams without these start from scratch, which usually means more interviews, more documentation and more rework. Where the deployer is a public authority, the AI Act adds registration and DPIA-linked duties under Article 26. Ask whether the existing records of processing and DPIA template cover AI processing or need to be extended first.

Who owns the model, the DPIA and the assessor's review

The organization that develops or deploys the AI system remains the controller or processor under the GDPR and keeps every decision that carries legal accountability. Its privacy, legal and product owners decide which lawful basis applies to training and to deployment, whether a legitimate interest assessment holds up under the three-step test described in EDPB Opinion 28/2024, and whether the model can be treated as anonymous on a case-by-case basis. The same team owns the data protection impact assessment, signs off on its conclusions, and decides whether residual high risk requires prior consultation under Article 36.

Lawful basis decisions: Record which basis applies to each processing purpose, including training, fine-tuning, evaluation and inference.
DPIA ownership: Own the assessment, its risk conclusions and its scheduled review, especially for automated evaluation or large-scale special category data.
Records of processing: Maintain entries that cover the AI pipeline, including the reasons for processing.
Deployment decision: Decide whether the system goes live, under what conditions, and who can stop it.
Data subject rights and automated decisions: Define how Article 22 safeguards and human review work in practice.

Confirm with counsel and your data protection officer which of these decisions your governance already assigns, and who signs them.

What evidence a regulator or customer will ask for before deployment

Before an AI system goes live, a supervisory authority or a customer's privacy team will usually ask for a short set of written artifacts that show what personal data the system uses, why, and how risks were judged. The five items below are the ones most often requested, and each one must stay current as the model, data and purposes change.

Record of processing entry

The Article 30 record must list the AI system as its own processing activity, with its purposes, categories of data subjects and personal data, recipients, transfers and retention. Separate entries are needed for training and for deployment, because the purposes and lawful bases often differ. Owned by the controller's privacy lead, with engineering supplying the data flows. To check it is current, compare the entry against the live pipeline, the model registry and any new third-party APIs added in the last release.

Legitimate interest or other basis assessment

EDPB Opinion 28/2024 applies a three-step legitimate interest test to developing and deploying AI models, and it allows reliance on that ground only where processing is strictly necessary and the balancing test is met. Document the interest, the necessity, and the reasonable expectations of the people whose data is used, including whether the data were public and how they were collected. Owned by the product owner with legal sign-off. Check it whenever the model's purpose, user base or data source changes.

Anonymity and pseudonymisation assessment

Anonymity of a model is assessed case by case. It must be very unlikely that the model identifies people whose data trained it, and very unlikely that such data can be extracted through queries. Test this with membership inference and training data extraction attempts, and record the methods, results and residual risk. Owned by the ML engineering lead with security testing support. Re-run the tests after each retraining or fine-tuning run, since a model that passed earlier may not pass after new data is added.

DPIA with review date

Article 35(3) requires a DPIA for large-scale automated evaluation with significant effects, large-scale special category data, and large-scale systematic monitoring of public areas, and many AI systems meet at least one trigger. The DPIA must describe the processing, assess necessity and risks, and set out measures, with a dated review cycle. Owned by the DPO or privacy lead, with the system owner accountable for the risk decisions. Check that the review date has not passed and that the DPIA reflects the current model version.

Human review and contestation process

Where a decision is based solely on automated processing and significantly affects a person, Article 22(1) gives the right not to be subject to it. Evidence includes the defined points where a trained person reviews the output, the criteria for overriding it, the channel through which people contest a decision, and logs showing reviews happened. Owned by the business process owner, with operations staff performing the reviews. Test it by sampling logged decisions and confirming that reviewers could actually change the outcome.

How to choose a consultant for GDPR AI work when no certificate exists

Because the GDPR requires no audit, attestation or certificate, you cannot select a consultant by asking whether it holds a credential the way you would for an ISO 27001 or SOC 2 engagement. Instead, select on scope and on who is accountable for each conclusion. Ask the consultant to list, component by component, what it prepares: the record of processing entries for the training and inference pipelines, the technical part of a DPIA, the logging and access design for training data, and the evidence pack for the anonymity question. Then ask who signs off the legal conclusions, such as whether legitimate interest holds or whether a model built on unlawfully processed data can be deployed. A credible answer names your own data protection officer or an outside lawyer for those decisions, and the consultant does not present its own opinion as a legal finding.

Next, test how the consultant handles technical evidence for models and logs. Ask how it would demonstrate that a model is anonymous under the case-by-case test in EDPB Opinion 28/2024, what queries or extraction tests it would run, and how it would keep training data, prompts, outputs and inference logs within retention limits. Ask which in-house staff have data protection expertise, how that expertise is kept current, and whether it has done this work for models that process personal data in your own infrastructure. Check that the handover is defined in advance: versioned DPIA drafts, the configuration exports and log samples that support each claim, and a list of open decisions that remain with you.

Finally, agree the scope in writing before work starts. The agreement should state the systems and model versions in scope, the deliverables and their format, who approves each document, the review trigger if a model is retrained or a new use is added, and what the consultant will not decide. Treat any certification offered as a voluntary Article 42 scheme as a separate question. Such certification is issued for at most three years by accredited certification bodies or supervisory authorities, and it does not reduce your responsibility as controller or processor. Confirm the current accreditation position with the certification body and your supervisory authority rather than relying on the supplier's description.

Questions buyers ask about GDPR for AI systems

Does a trained AI model still contain personal data under GDPR?

It can, and anonymity has to be shown case by case rather than assumed. EDPB Opinion 28/2024 says a model is anonymous only if it is very unlikely that someone could identify the people whose data trained it, and very unlikely that such data could be extracted from the model through queries. The controller must test this with evidence, including membership inference and extraction tests, documented against the model's actual exposure. If the model is not anonymous, every GDPR duty applies to it. Confirm the test approach with your counsel and your supervisory authority, since the boundary is still being worked out in practice.

Can legitimate interest cover training an AI model on scraped data?

Possibly, but only after a documented three-step legitimate interest test passes, and scraped data raises the bar. Opinion 28/2024 says a controller can rely on legitimate interest only if the processing is strictly necessary for the purpose and the balancing test favors the controller. The reasonable expectations of individuals carry real weight: the opinion lists whether data were public, the relationship with the controller, the context of collection, possible later uses of the model and whether people know their data are online. Unlawful collection upstream can also taint deployment, so check the provenance of every dataset before training. Ask counsel to review the assessment for each use case.

Is a DPIA always required for an AI system?

No, but many AI systems will need one. Article 35(3) names three triggers: systematic and extensive automated evaluation with legal or similarly significant effects, large-scale processing of special category or criminal offence data, and large-scale systematic monitoring of a publicly accessible area. Other AI processing can still meet the general high-risk test in the WP248 DPIA guidelines, so a screening step is needed for each system. Where the assessment shows high residual risk, prior consultation with the supervisory authority under Article 36 may follow. Your controls owner, usually the DPO or privacy lead, should sign off the screening and keep it current as the model changes.

How must automated decisions about people be reviewed?

Article 22(1) gives people the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significant effects. Where that right applies, the system needs a route for meaningful human review, where the reviewer has the authority and information to change the outcome, not a rubber stamp. Engineers should log inputs, model version and the reasons behind each decision so a review and an access request can be answered. The WP251 guidelines on automated decision-making explain what counts as meaningful review. Confirm the legal basis and any exceptions with counsel before launch.

Can our team do GDPR work for an AI system in-house?

Often yes, if you have people who can evidence the work and own the decisions. The controller must own the lawful basis, the DPIA, the transparency notices and the answers to rights requests, and none of that can be delegated to a vendor. An implementation partner can help prepare systems, logging, access controls, data inventories and test evidence, but it does not issue reports or certificate compliance. Independent assessment comes from auditors or supervisory authorities, not from implementers. Decide which tasks your staff can run and where outside engineering or legal review adds value.

What drives the effort and the timeline of a GDPR readiness review for AI?

The main drivers are the number of AI systems in scope, whether personal data is used for training, the sensitivity of the data, how many countries and data flows are involved, and how much documentation already exists. A review of one deployed model with clear provenance is far smaller than a review covering several models trained on mixed sources. Ask any provider for a written scope listing systems, data sources, processing purposes and deliverables before agreeing a fee or date. One-time work includes the inventory, DPIA, legitimate interest assessments and technical tests; recurring work covers model updates, retraining and periodic review. Request a quote that separates these items.

What does the work require from our engineering and privacy teams?

It requires named owners on both sides and access to the actual systems. Engineering needs to provide model cards, training data lineage, retention settings, logs and the technical details of how outputs are produced. Privacy and legal need to set purposes, approve assessments and decide on lawful bases. Security should test access controls, encryption and logging. Expect the controller to keep the record of processing current, since Article 35 and the processing records depend on accurate descriptions of what the model does. Agree in advance who signs off each artifact.

How do AI Act deployer duties relate to GDPR obligations?

The AI Act adds duties on top of GDPR and does not replace them. Article 26(9) requires deployers of high-risk AI systems to use the provider's information when carrying out GDPR data protection impact assessments. Article 26(8) requires public authority deployers to register under Article 49 and not to use a system missing from the EU database. As amended in 2026, Article 27(4) and (5) let deployers cross-reference or include parts of a GDPR DPIA, and the AI Office is to develop a questionnaire template. Map each AI system to both regimes early, and confirm the current consolidated text and application dates with counsel, since the amendments are recent.

How DeployOpen prepares AI systems and evidence for GDPR review

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the logging, access control, data flows and records that GDPR reviews of AI systems depend on. We prepare the systems and evidence; the controller owns its lawful basis decisions, DPIA conclusions and regulatory responsibility, and only an independent assessor or supervisory authority can issue findings or certification.

How we scope

Engagements are fixed-scope, with the systems, data sources, models and processing purposes agreed in writing before work starts.
The written scope names which AI systems, training datasets and deployment environments are covered, and which decisions stay with the client.
We confirm with the client which legal analyses, such as legitimate interest assessments, they will produce themselves with counsel.

How we build

We configure self-hosted platforms with documented access controls, logging of model inputs and outputs, and retention settings the client approves.
We implement pseudonymization, encryption and data flow mapping so personal data movements into and out of model pipelines are traceable.
We test the deployed environment for access and data leakage paths, including queries that could expose training data, and record the results.

How we hand over

We deliver documentation covering system architecture, data flows, processing records and the technical facts a DPIA needs.
Handover includes runbooks for data subject request handling, deletion across logs and backups, and incident steps for personal data breaches.
We list open items the client must decide, such as anonymity conclusions and automated decision safeguards, so ownership is explicit.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
Retainers can cover updating documentation when a model is retrained, a new data source is added or deployment scope changes.
Ask any provider to confirm in writing which evidence they produce and which conclusions remain with your DPO, counsel and assessor.

GDPR for AI systems and machine learning