Key takeaways
- GDPR Article 35 requires a DPIA before processing likely to create high risks. Assess each AI use rather than assuming all AI requires one.
- Article 35(3) names three cases: automated decisions with significant effects, large-scale sensitive data, and large-scale monitoring of public areas.
- Article 29 Working Party guidance lists nine criteria, and meeting two or more usually means a DPIA is needed.
- A DPIA must describe the processing, test necessity and proportionality, assess risks to people and set out the measures that reduce them. The AI Act's fundamental rights impact assessment can build on it.
What a DPIA is, and why AI projects trigger it
A data protection impact assessment (DPIA) records how your planned processing affects people and how you will reduce the risks. GDPR Article 35 requires it before processing likely to create high risks. Using AI alone does not decide the answer. Assess the data, scale, affected people and decisions, then check your national authority’s mandatory list.
When is a DPIA mandatory?
Article 35(3) lists three situations in which a DPIA is always required.
- A systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that have legal or similarly significant effects on a person.
- Large-scale processing of special categories of data (such as health, biometric or political-opinion data) or of data on criminal convictions.
- Systematic monitoring of a publicly accessible area on a large scale.
Article 35(4) adds that each national supervisory authority publishes a list of processing operations that also require one, and most lists mention AI, profiling or health data. Check the list for your country before you decide that you are exempt.
The nine criteria that signal high risk
The Article 29 Working Party, the predecessor of the European Data Protection Board, published criteria to help decide whether processing is likely to be high-risk. As a rule of thumb, meeting two or more of them means you should carry out a DPIA.
| Criterion | How an AI project can meet it |
|---|---|
| Evaluation or scoring, including profiling | Ranking candidates, scoring credit, predicting churn or behaviour |
| Automated decisions with legal or similar effect | A model that approves, rejects or prioritises people without a human decision |
| Systematic monitoring | Analysing calls, messages or camera feeds continuously |
| Sensitive or highly personal data | Consultation audio, medical notes, financial records |
| Large-scale processing | A whole patient list, a full customer base, thousands of calls a day |
| Matching or combining datasets | Joining CRM, support and usage data to train or prompt a model |
| Vulnerable data subjects | Patients, employees, children, benefit claimants |
| Innovative use or new technology | Using a language model or speech recognition in a new way |
| Processing that blocks a right or a service | A model that decides who gets access to a service |
What the DPIA must contain
| Required element | What to write for an AI system |
|---|---|
| A systematic description of the processing and its purposes | Data flows from input to output, the models and vendors involved, where each step runs, retention and who can see what |
| An assessment of necessity and proportionality | Why you need personal data at all, what you remove or redact before the model, and your legal basis |
| An assessment of the risks to people | Wrong or invented outputs, bias, leakage through prompts or logs, memorisation, reuse of data for training, unfair decisions |
| The measures to address the risks | Redaction, EU hosting, access control, logging, human review, accuracy testing, contractual limits on the vendor |
Ask your data protection officer for advice while you draft, as Article 35(2) requires, and keep the assessment alive. A model upgrade, a new vendor or a new use case is a reason to revisit it.
How it fits with the AI Act
Deployers of high-risk AI systems have to use the information the provider supplies to meet their own DPIA duty. Article 27 of the AI Act also requires a fundamental rights impact assessment before certain high-risk systems are used, by public bodies, private entities providing public services and deployers of some credit and insurance systems. Where a DPIA already covers part of that ground, the FRIA complements it, so one joint exercise is usually less work than two separate ones.
If the risk stays high after your measures
Under Article 36, if the DPIA shows a high risk that you cannot reduce enough, you must consult the supervisory authority before you start. In many projects this is avoided by redesigning: collect less, redact more, keep a person in the loop or change where the system runs.
Share your proposed AI workflow and data types. We can document the data flows, vendors and technical controls your DPIA needs.
Discuss your AI data flowsFAQ
Do we need a DPIA for a chatbot?
Not automatically. It depends on what data goes in, who the users are and what the bot decides. A chatbot that handles health, financial or employment matters, or that profiles users, will usually meet at least two of the nine criteria.
Who writes the DPIA, the vendor or us?
The controller, which is you. The vendor, as processor, must help you under Article 28, and you can reuse its documentation, but the assessment and the decision are yours.
Can we use the same document for the DPIA and the AI Act's FRIA?
Often, in part. Article 27 of the AI Act says the fundamental rights impact assessment complements a DPIA where some obligations are already met. Keep them as one file with clearly labelled sections.
Sources
- Regulation (EU) 2016/679 (GDPR), Articles 35 and 36, Official Journal of the EU
- Article 29 Working Party, Guidelines on Data Protection Impact Assessment (WP248 rev.01)
- European Data Protection Board, Opinion 28/2024 on AI models
- Regulation (EU) 2024/1689 (AI Act), Articles 26 and 27, Official Journal of the EU
About the author
Artem Synytskyi · Co-founder · AI
Artem runs AI at ESADEX, building LLM, RAG and speech-to-text systems for regulated environments.