A DPIA for AI is a data protection impact assessment that examines how an AI system uses personal data and what risks that creates for the people concerned. Many AI projects meet the legal triggers for a DPIA: they process personal data at scale, use new technology, profile individuals or support decisions with significant effects. Yet the usual DPIA templates were written for databases and forms, and they often miss the questions that matter for models. This guide explains when a DPIA for AI is required, how to describe an AI system for assessment, which risks to consider, what safeguards are commonly used, how the assessment relates to the EU AI Act, and what to record.
When a DPIA for AI is required
Article 35 of the GDPR requires a DPIA where processing is likely to result in a high risk to individuals, and it lists three situations. One is a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal or similarly significant effects. Another is large-scale processing of special categories or criminal data. The third is systematic monitoring of a publicly accessible area on a large scale. Supervisory authorities publish lists of further processing types that require a DPIA, and these often include innovative technology such as machine learning, especially when combined with other risk factors such as vulnerable individuals or large-scale data.
In practice, most AI systems that make or support decisions about people, process sensitive data, train on customer or employee data, or monitor behavior will need one. Our guide to when a DPIA is required explains the screening criteria, and the general method is covered in our overview of the DPIA.
Describing the AI system for the DPIA
A description that says the system uses machine learning to improve service is not enough. The assessment needs a systematic description of the processing operations and purposes, and for AI that includes the following.
- Purpose and use case. What decision or output the system supports, and who acts on it.
- Data sources. Data used to train, validate and operate the system, including whether personal data, special category data or data about children is involved, and where it came from.
- Model type and provider. Whether it is built in-house, licensed or a general-purpose model accessed through an interface, and where processing happens.
- Inputs and outputs. What personal data goes in, what comes out, and how outputs are stored and used.
- Human involvement. Who reviews outputs, with what authority and information.
- Recipients and transfers. Any processors, sub-processors and international transfers.
- Retention. How long training data, prompts, logs and outputs are kept.
Free AI risk assessment
Which of your AI systems could harm people, or you?
List your AI systems, models and data, pick from 38 AI risk scenarios, rate them for the people affected and for you, and plan treatment with ISO 42001 Annex A controls. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free AI risk assessment → or View premium report sample
Lawfulness, necessity and proportionality for AI
The DPIA must assess whether the processing is necessary and proportionate. For AI this includes asking whether the same aim could be achieved with less personal data, with synthetic or anonymized data, or with a simpler method. Identify the lawful basis for each stage, since training, deployment and improvement may have different bases. The European Data Protection Board adopted an opinion in December 2024 on certain data protection aspects of AI models, covering the use of legitimate interest, the anonymity of models and the consequences of unlawful development. Read it on the EDPB website and check for the latest guidance. In the United Kingdom, the Information Commissioner’s guidance on AI and data protection is the key source.
AI-specific risks to include in a DPIA for AI
| Risk | Example | Typical measure |
|---|---|---|
| Inaccuracy | Wrong outputs treated as facts about a person | Testing, human review, correction route |
| Discrimination | Unequal error rates across groups | Bias testing, data improvement, monitoring |
| Lack of transparency | People cannot tell that AI was used or why a decision was made | Notices, explanations, meaningful information |
| Automated decisions | Significant decisions made without human involvement | Human review, contestation rights under Article 22 |
| Data leakage or memorization | Model reveals personal data from training | Minimization, filtering, testing for extraction |
| Inference of sensitive traits | Model infers health or beliefs | Limit inputs, block sensitive inference |
| Function creep | Model reused for a different purpose | Purpose limits, governance and approval |
| Security | Prompt injection, data poisoning, model theft | Access controls, testing, monitoring |
Use the categories in our AI harm taxonomy to prompt a full range of consequences, and AI bias testing to evidence fairness claims.
Automated decision-making and Article 22
Article 22 gives individuals the right not to be subject to a decision based solely on automated processing which produces legal or similarly significant effects, subject to exceptions, and requires safeguards such as the right to obtain human intervention, express a view and contest the decision. If your system falls within that provision, the DPIA must show how the exceptions and safeguards apply. Token human involvement, such as a person who routinely approves every output without real review, does not usually take a decision outside the scope of the rule.
Safeguards commonly used
Typical safeguards include reducing and pseudonymizing training data, excluding special category data or sensitive proxies, restricting who can access the model and its logs, setting retention limits, human review of significant outputs, testing before launch and monitoring after, clear notices, ways to challenge outcomes and contractual controls over suppliers, including limits on using your data to train their models. For generative tools, add policies on what staff may enter, and technical controls that stop personal data flowing to unapproved services.
Relationship with the EU AI Act
The AI Act and the GDPR apply together. The AI Act requires deployers of certain high-risk systems, including bodies governed by public law, private entities providing public services and deployers of specified credit and insurance systems, to carry out a fundamental rights impact assessment. It states that where obligations are already met through a DPIA, the fundamental rights assessment complements it. It also requires deployers to use the information provided by the provider under the Act to comply with their DPIA duty where applicable. Read our guides to the fundamental rights impact assessment and AI impact assessment versus DPIA to avoid duplicating work. Check current application dates against the official text, since timelines have been subject to change.
Consultation, residual risk and approval
Seek the advice of the data protection officer, and where appropriate the views of affected individuals or their representatives. Rate the residual risk after safeguards. If a high residual risk remains that you cannot reduce, prior consultation with the supervisory authority is required before processing begins, as explained in our guide to DPIA prior consultation. Record the outcome and the approver. Our guide to DPIA residual risk explains how to judge what remains.
A short worked example
A lender proposes a model to score loan applications. The DPIA records the data used, including transaction histories, notes the system will support decisions with significant effects on applicants, and identifies risks of unfair outcomes, inaccurate data and lack of explanation. Safeguards include removing sensitive inputs and proxies, testing error rates across groups, requiring a human underwriter to review declined applications with the model’s reasons, giving applicants a plain-language explanation and a route to contest, and quarterly monitoring. Residual risk is rated medium, the data protection officer’s advice is recorded, and the credit committee approves with a six-month review.
Review and change management
Treat the DPIA as a living record. Review it after model updates, new data sources, new user groups, incidents and complaints, and at planned intervals. Tie the trigger to your change process so that model releases cannot bypass it. Keep versions so that you can show what was known at each stage.
Common mistakes with a DPIA for AI
Teams describe the model in marketing terms, ignore training data, assume a supplier’s assurances cover their own duties, treat human review as a checkbox, skip fairness testing, forget retention of prompts and logs, and finish the assessment after launch. Another mistake is duplicating the AI impact assessment and the DPIA in separate silos that contradict each other. Share the system description and cross-refer the two.
Using a ready structure
If you want a starting structure, the DPIA Report and Workbook provides a structured report with risk scoring and a working register that can carry the AI-specific questions above. Whichever format you use, complete the DPIA for AI before the system processes real personal data and keep it up to date.
DPIA for AI FAQ
Do all AI systems need a DPIA?
No, but those processing personal data in ways likely to result in high risk usually do, for example profiling with significant effects, sensitive data, large-scale processing or innovative use of technology.
Can a supplier’s documentation replace our DPIA?
No. It can supply useful information, but the controller remains responsible for assessing its own processing and context.
How is a DPIA for AI different from an AI impact assessment?
A DPIA focuses on risks to individuals’ data protection rights, while an AI impact assessment covers wider effects on people and society. They can share a system description and reference each other.
Does Article 22 apply to every AI decision?
Only to decisions based solely on automated processing with legal or similarly significant effects. Meaningful human involvement can take a decision outside its scope, but token review does not.
When must I consult the regulator?
When the DPIA shows a high residual risk that you cannot mitigate, Article 36 requires prior consultation with the supervisory authority before processing starts.