DPIA for AI systems — when you need one, and what it has to contain
A data protection impact assessment is the one AI governance document most companies already owe under existing law. Done properly it also carries a substantial part of what the AI Act will ask for — which is a good reason not to write a generic one.
First hour’s on us. No commitment.
What you get
- A threshold assessment — whether a DPIA is required, documented either way
- A completed DPIA covering the AI-specific risks, not a template with your system name in it
- The necessity and proportionality analysis, which is the part regulators actually read
- Mitigations that are real, with owners and dates
- A mapping to your AI Act documentation so the same evidence serves both
How it works
- Intake, 45 minutes. What the system does and whose data it touches. Free.
- Assessment, one to three weeks, including sessions with the people who build and run it.
- The DPIA, plus a short register of the decisions taken.
Who you’ll work with
Fidan Ibrahimzada, Legal Counsel for AI and technology law, leads this work. She advises companies on AI regulation, data protection and technology contracts, and previously led the legal department of a commercial law firm. She holds an LL.M. in European Business Law from Lund University. Lawgent is Sweden’s first law firm dedicated to AI and EU regulation — meet the team.
When a DPIA is required
Article 35 of the GDPR requires one where processing is likely to result in a high risk to the rights and freedoms of individuals, and specifically for systematic and extensive automated evaluation producing legal or similarly significant effects, large-scale processing of special category data, and systematic large-scale monitoring of publicly accessible areas.
National supervisory authorities also publish lists of processing operations that always require one. For AI, the practical triggers are: profiling or scoring people, automated decision-making with significant effects, processing at scale, use of new technology in ways individuals would not expect, combining datasets from different sources, and processing data about people in vulnerable positions.
Most AI systems that touch people meet at least two. Where you conclude a DPIA is not needed, write down why — the assessment of the threshold is itself part of accountability.
What makes an AI DPIA different
A conventional DPIA describes a stable processing operation. An AI system has a lifecycle, and the risks differ at each stage.
Training raises the legal basis question for the dataset, the provenance of the data, and information duties toward people whose data you never collected directly.
Deployment raises accuracy, bias, and the effect of an incorrect output on a real person.
Inference and logging raise a data flow most assessments miss entirely — what is retained from each query, for how long, who can see it, and whether it leaves the jurisdiction.
A DPIA that treats the system as one undifferentiated operation will miss the risks that matter, and it will be visible that it did.
The section that carries the weight
Necessity and proportionality is where a DPIA either works or does not. It asks whether you could achieve the same purpose with less data, less intrusion, or a simpler method — and requires you to have considered it.
For AI systems the honest questions are uncomfortable and worth asking: does this need to be automated at all; does it need personal data or would aggregated data do; does it need this much history; would a simpler model with explainable behaviour serve the purpose. A DPIA that shows those alternatives were weighed and rejected for stated reasons is defensible. One that starts from the assumption that the chosen system is necessary has skipped the analysis.
Where it meets the AI Act
The overlap is substantial and worth exploiting.
| DPIA element | Also serves |
|---|---|
| Systematic description of processing | Technical documentation and intended purpose |
| Risk identification and mitigation | The risk management system for high-risk providers |
| Data quality and provenance | Data governance obligations (Art. 10) |
| Safeguards for automated decisions | Human oversight design (Art. 14) |
| Rights and transparency measures | Transparency duties and information to affected persons |
Certain deployers must also carry out a fundamental rights impact assessment under the AI Act. Where both apply, the DPIA can be built to feed it rather than sit beside it.
Frequently asked questions
We use a third-party AI tool. Is the DPIA the vendor’s job?
No. The DPIA belongs to the controller — you. The vendor should supply the information you need, and your contract should require it, but the assessment and the accountability are yours.
Do we need a new DPIA for every model update?
Not for routine updates. You do need to review it where the purpose, the data, the population affected or the risk profile changes materially. Build the review trigger into the document.
Do we have to consult the supervisory authority?
Only where the DPIA indicates a high residual risk that you cannot mitigate. In practice this is uncommon, and reaching that conclusion is itself a signal to revisit the design.
Who should be involved?
The people who build the system, the people who operate it, the business owner, and your DPO where you have one. A DPIA written by legal alone tends to describe a system that does not exist.
How long does one take?
One to three weeks for a single system, most of which is spent understanding how it actually works rather than writing.
Where to start
With one system — ideally the one you are least comfortable about. The first conversation is free and often settles the threshold question on its own.