AI and GDPR Guide: Lawful Basis, DPIAs and Automated Decisions

Most AI systems that touch people process personal data, and the GDPR applies to every stage, from training a model to the decision an agent takes about a customer. The hard questions are practical ones: which lawful basis covers training and deployment, when a DPIA is mandatory, whether a model can be treated as anonymous, and when an automated decision falls under Article 22. This guide covers those questions for EU GDPR and the UK regime after the Data (Use and Access) Act 2025. It is written for security, privacy and engineering leads who have to turn legal positions into controls, logs and evidence. Training-data sourcing and privacy-enhancing techniques are covered in the AI and Privacy Guide; this page focuses on lawful basis, DPIAs and automated decisions.

Key takeaways

• Development and deployment are separate processing activities that each need a purpose, a lawful basis and a record. A basis that covers serving a customer does not automatically cover training a model on that customer's data.
• Legitimate interest is possible but must be earned through the three-step test the EDPB set out in Opinion 28/2024, with documented necessity, balancing and mitigating measures that go beyond what the GDPR already requires.
• Models are not anonymous by default. The EDPB expects the likelihood of extracting personal data from the model, or obtaining it through queries, to be insignificant, and expects the controller to prove it with testing.
• Article 22 is about solely automated decisions with legal or similarly significant effects. Human review only takes a decision out of scope if the reviewer has real authority and competence to change it.
• A DPIA is the backbone document for most AI use cases: Article 35(3)(a) makes it mandatory for systematic and extensive evaluation of people that leads to significant decisions, and the AI Act tells deployers to reuse provider information in it.

Scope: who and what is covered

The GDPR (Regulation (EU) 2016/679) applies to any processing of personal data by a controller or processor established in the EU, or offering goods or services to, or monitoring, people in the EU. Nothing in it is specific to AI, which is why the regulators have issued AI-specific interpretation rather than new rules. The UK GDPR follows the same structure, amended by the Data (Use and Access) Act 2025 (DUAA); the ICO states that all of the Act's data protection provisions are now in force.

Interaction with the EU AI Act: the AI Act applies alongside the GDPR, not instead of it. Article 26(9) tells deployers of high-risk AI systems to use the information the provider gives them under Article 13 when they carry out a DPIA, and Article 26(11) requires deployers of Annex III systems that make or assist decisions about people to tell those people the system is being used. Article 86 adds a right to an explanation of the role an Annex III high-risk system played in a decision, where Union law does not already provide one. See the EU AI Act Compliance Guide and the EU AI Act High-Risk AI Systems Guide.

Key obligations

Lawful basis for training and deployment

The EDPB's Opinion 28/2024 (18 December 2024, requested by the Irish supervisory authority under Article 64(2)) states there is no hierarchy among the Article 6(1) bases. In practice most organisations choose between consent, contract and legitimate interest. For legitimate interest, the opinion sets out a three-step test:

1. Legitimate interest: the interest must be lawful, clearly and precisely articulated, and real and present. The opinion gives developing a conversational agent and improving threat detection as examples of interests that can qualify.
2. Necessity: the processing must actually be needed for that interest, with no less intrusive way to achieve it, and the volume of personal data must be proportionate under data minimisation.
3. Balancing: the interest must not be overridden by the rights and interests of the people concerned. Their reasonable expectations are a key factor, and the EDPB says that meeting transparency requirements is not enough on its own to establish those expectations.

Mitigating measures can tip the balance, but the EDPB says they must be tailored to the case and go beyond what the GDPR already requires. Typical examples practitioners use include excluding sensitive sources from scraping, honouring opt-outs before training, pseudonymising identifiers in training sets and filtering outputs for personal data. Special category data (Article 9) needs a separate Article 9(2) condition, which legitimate interest does not provide.

Is the model itself personal data?

The EDPB says AI models trained on personal data cannot always be considered anonymous, and supervisory authorities should assess claims case by case. For a model to be anonymous, both the likelihood of extracting training data from the model and the likelihood of obtaining it from queries should be insignificant for any person. Controllers should document design choices, testing and resistance to attacks such as membership inference and training data extraction. OWASP LLM02:2025 Sensitive Information Disclosure covers the same risk from the application side.

The opinion also addresses models built unlawfully. A deployer using a third-party model that still holds personal data should check, as part of its accountability, whether the model was developed lawfully, including the data source and any prior infringement findings, with the depth of the check matching the deployment risk. If a model was effectively anonymised before deployment, the GDPR would not apply to operating it, but personal data collected during deployment is still fully in scope.

Automated decisions under Article 22

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 significantly affects them. Article 22(2) allows such decisions only where necessary for a contract, authorised by Union or Member State law with suitable safeguards, or based on explicit consent. For the contract and consent routes, Article 22(3) requires at least the right to obtain human intervention, to express a point of view and to contest the decision. Article 22(4) bars decisions based on special category data unless Article 9(2)(a) or (g) applies with suitable safeguards. Articles 13(2)(f), 14(2)(g) and 15(1)(h) require meaningful information about the logic involved and the significance and envisaged consequences.

UK difference: the DUAA replaced UK Article 22 with Articles 22A to 22D. According to the ICO, organisations can now rely on any lawful basis for significant automated decisions as long as safeguards apply, while decisions using special category data remain restricted to explicit consent, contract, or where required or authorised by law. The safeguards the ICO lists are information about decisions, the ability to make representations, human intervention and the ability to contest. The ICO's updated ADM guidance was consulted on from 31 March to 29 May 2026 and was still marked as draft when checked.

DPIAs and privacy by design

Article 35(1) requires a DPIA where processing, in particular using new technologies, is likely to result in a high risk. Article 35(3)(a) makes it mandatory for systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with legal or similar effects are based. If residual risk stays high, Article 36 requires prior consultation with the supervisory authority. Article 25 (data protection by design and by default) is where technical controls such as minimised prompts, retention limits and output filters belong. See the DPIA Guide and the DPIA Template.

Security, processors and breaches

Article 32 security applies to training stores, vector databases, prompt logs and agent credentials. Model APIs and hosting usually need an Article 28 processor agreement that covers whether the vendor may use prompts for its own training. A leak of prompts, retrieved documents or agent-altered records is a personal data breach under Articles 33 and 34. See the GDPR Compliance Guide for Security Teams and the Data Breach Notification Checklist.

Timeline and current status

Enforcement and penalties

• Fine ceilings: breaches of the core principles, lawful basis, data subject rights (including Article 22) and international transfers can reach EUR 20 million or 4% of worldwide annual turnover under Article 83(5); obligations such as Articles 25, 28, 32 and 35 fall under Article 83(4), up to EUR 10 million or 2%.
• Orders matter as much as fines: authorities can order processing to stop or data to be deleted (Article 58(2)), which for AI can mean retraining or withdrawing a model.
• OpenAI and the Italian Garante: in December 2024 the Garante announced a EUR 15 million fine against OpenAI for training ChatGPT without first identifying an adequate legal basis, transparency failures, missing age verification and failing to notify a March 2023 breach, and ordered a six-month public information campaign. A Rome Tribunal judgment published on 18 March 2026 upheld OpenAI's appeal, and the Garante has temporarily removed the decision. The case shows both the issues regulators examine and that AI enforcement is still being tested in court.
• Agent-driven breaches are now notified: the Spain AEPD AI agent breach was described by the AEPD as the first breach notified to it that was carried out through an autonomous agent, in which the agent changed personal data and reached invoices.

What it means for AI agents and non-human identities

An AI agent is a non-human identity that reads and changes personal data with delegated permissions. GDPR principles translate into identity controls:

• Purpose limitation as scope: give each agent its own identity, with OAuth scopes and database grants limited to the purpose in the record of processing. A shared service account makes it impossible to show which processing was done for which purpose. See the AI Agent Authorisation Guide.
• Article 22 through tool design: if an agent can approve a refund, reject an application or close an account, that action may be a solely automated significant decision. Put a human approval step on those tools and log who approved. See the Human-in-the-Loop for AI Agents Guide.
• Integrity and confidentiality (Art. 5(1)(f)): agent API keys and tokens are the route to personal data. Vault them, keep them short-lived and remove write access to production records unless the purpose needs it.
• Accountability (Art. 5(2)): log agent identity, user on whose behalf it acted, tool called and records touched, so you can answer access requests and investigate breaches. Keep those logs minimised and time-limited, because they are personal data too.
• Rights handling: agent memory and vector stores must be included in access and erasure workflows. See the AI Agent Memory Security Guide and the Agentic AI Compliance Guide.

Compliance steps

1. Inventory AI use: list every model, AI feature and agent, including SaaS features switched on by default, with the personal data each one touches. Start with anything that makes or supports decisions about people.
2. Split purposes: record training, fine-tuning, inference, evaluation and logging as separate entries in the Article 30 record, each with its own lawful basis.
3. Run legitimate interest assessments: where Article 6(1)(f) is used, write the three-step test, list the mitigations and set up an Article 21 objection route that reaches training pipelines.
4. Classify decisions: for every automated output, decide whether it is a decision, whether it is solely automated, and whether its effect is legal or similarly significant. Test human review by sampling: if reviewers almost never change the outcome or lack the information to do so, treat the decision as solely automated.
5. Complete DPIAs: run a DPIA before deployment, reusing provider documentation and, for high-risk systems, the AI Act fundamental rights material. Escalate to Article 36 consultation if high residual risk remains.
6. Test the model for leakage: before claiming a model is anonymous, run extraction and membership inference tests, record the results and repeat after retraining.
7. Fix vendor terms: confirm processor or controller roles, prompt retention, training opt-outs, sub-processors and transfer mechanisms in contracts.
8. Write transparency text: update notices with meaningful information about the logic, significance and consequences, and train staff who handle contests.
9. Pilot and roll back: launch to a limited population, monitor contest and override rates, and keep a rollback plan that switches decisions back to human handling if error or complaint rates exceed agreed thresholds.

Measuring it

• Percentage of AI use cases with a current DPIA and lawful basis record.
• Human override rate on reviewed decisions (very low rates suggest rubber-stamping).
• Time to complete access, objection and erasure requests that involve AI systems.
• Number of agents with write access to personal data, and the share with per-agent identities.
• Leakage test results per model release (extraction success rate).

Common failure patterns

• Reusing the service basis for training: assuming contract covers model training on customer data.
• Token human review: a reviewer who clicks approve on every case without the data or authority to disagree, which leaves the decision solely automated.
• Calling the model anonymous without tests: removing names from the training set and asserting the model holds no personal data.
• Forgotten logs and memory: prompt logs and agent memory kept indefinitely and left out of access and erasure processes.
• Over-permissioned agents: agents with broad production write access, the pattern behind the Replit AI agent database deletion, which also wiped personal contact records.

Framework mapping

Practitioner checklist

• Keep an inventory of AI systems and agents with the personal data each processes.
• Record training and inference as separate purposes with their own lawful basis.
• Document a three-step legitimate interest assessment wherever Article 6(1)(f) is used.
• Classify each automated output against Article 22 (or UK Articles 22A-22D) and sample-test human review.
• Complete a DPIA before go-live and reuse AI Act provider documentation in it.
• Test models for extraction and membership inference before any anonymity claim.
• Give each agent its own identity, least-privilege scopes and human approval on significant actions.
• Include prompt logs, vector stores and agent memory in retention, access and erasure workflows.
• Confirm vendor roles, training opt-outs and prompt retention in contracts.
• Track override rates, request handling times and leakage test results.

Standards and references

• EUR-Lex: Regulation (EU) 2016/679 (General Data Protection Regulation)
• EDPB: Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models
• ICO: Guidance on AI and data protection
• ICO: Automated decision-making, including profiling
• ICO: The Data (Use and Access) Act 2025, what does it mean for organisations
• EUR-Lex: Regulation (EU) 2026/1744 (Digital Omnibus on AI)
• Garante per la protezione dei dati personali: ChatGPT decision against OpenAI
• OWASP: Top 10 for LLM Applications 2025

This guide summarises how the EU GDPR and UK GDPR apply to AI systems and is not legal advice. Related NHI Mgmt Group resources: AI and Privacy Guide · DPIA Guide · DPIA Template · GDPR Compliance Guide for Security Teams · Data Breach Notification Checklist