AI and GDPR: data protection impact assessments explained
When an AI project needs a data protection impact assessment, what one contains, and how a small business can produce a useful one.
The short answer
A data protection impact assessment is required before processing that is likely to result in a high risk to people’s rights and freedoms. The regulation names three cases in particular: systematic and extensive automated evaluation of personal aspects, including profiling, on which decisions with legal or similarly significant effects are based; processing special category or criminal data on a large scale; and systematic monitoring of publicly accessible areas on a large scale. Supervisory authorities publish their own lists of operations that require one. AI projects frequently land in the first category, which is why the question arises so often. The assessment itself has four required parts: a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to the people affected, and the measures you will take to address them. For a small business that is a few plain pages written before the build, not a research project, and producing it tends to improve the design as much as the paperwork, because it forces the questions about minimisation, oversight and retention that a project would otherwise answer by default.
The four parts, for an AI project
| Part | What to write |
|---|---|
| Description | What the system does, what personal data it uses, where it comes from, who it concerns, who has access, which providers are involved and where they process, retention, and the data flow end to end |
| Necessity and proportionality | Why this processing is necessary for the purpose, why a less intrusive option would not do, the legal basis, how minimisation is applied, how transparency is provided, how rights are honoured |
| Risks to people | What could go wrong from their point of view: wrong outcomes, discrimination, exposure of sensitive inferences, loss of control, inability to contest, security breach; with likelihood and severity |
| Measures | Human decision points, explainability, outcome testing for bias, minimisation and pseudonymisation, access control, logging, retention limits, provider terms, staff training, monitoring and review |
Producing one without a compliance department
- Decide whether one is needed, using the triggers and your authority’s list; record the decision either way.
- Describe the processing by walking the data through the system with whoever built or configured it.
- Challenge necessity: could the purpose be met with less data, with aggregate data, or without AI?
- Assess risks from the person’s perspective, not the business’s; involve someone who can represent them.
- List measures against each risk, and be specific: who decides, what is logged, how long data is kept.
- Note the residual risk and whether consultation is needed.
- Get sign-off from whoever is accountable, with a date.
- Revisit when the purpose, the data, the provider or the model changes, and at least annually.
Where it overlaps with the AI Act
A high-risk system under the AI Act brings its own risk management, documentation, oversight and logging requirements, which overlap substantially with an impact assessment but are not identical. Doing both as one exercise is sensible, provided each set of requirements is met. For a small business the practical approach is a single document covering the data protection assessment, with an annex addressing the additional AI Act deployer obligations where they apply, and an adviser’s review if the use is genuinely high-risk.
What this means for you
Do an impact assessment before AI processing likely to create high risk, particularly profiling with significant effects, large-scale special category data or systematic monitoring. Write the four parts plainly: description, necessity and proportionality, risks to people, and measures. Do it before building so it shapes the design, get sign-off, consult the authority if high residual risk remains, and revisit on change. This is general information rather than legal advice.
Frequently asked questions
When exactly do we need one?
Where processing is likely to result in a high risk, and the regulation names three triggers in particular: systematic and extensive automated evaluation of personal aspects including profiling with significant effects, large-scale processing of special categories or criminal data, and systematic monitoring of a publicly accessible area on a large scale. Supervisory authorities also publish lists of processing operations requiring one. Many AI uses on personal data fall into the first, which is why the question comes up so often.
What does it actually contain?
A systematic description of the processing and its purposes, including legitimate interests where relied on; an assessment of whether the processing is necessary and proportionate to those purposes; an assessment of the risks to the rights and freedoms of the people concerned; and the measures you will take to address those risks, including safeguards and security. For a small business that is typically three to six pages, written plainly.
Who signs it off and what if the risk stays high?
The controller is responsible; in practice the business owner or the person accountable for the processing, with input from whoever understands the technology and, where you have one, the data protection officer. If, after your measures, a high residual risk remains, you must consult the supervisory authority before proceeding. That obligation is a useful forcing function: if you cannot reduce the risk, the design probably needs to change.
Sources
- EUR-Lex: Regulation (EU) 2016/679, Article 35 (accessed 2026-09-14)