As of May 2026. “We’re deploying AI — do we now absolutely need a Data Protection Impact Assessment?” I hear this question almost every week. The honest answer is uncomfortable for anyone hoping for a simple yes or no: it depends on your specific use case — and that assessment is precisely what you have to document. Claiming flatly that AI always triggers a DPIA oversimplifies the law. Skipping it reflexively risks a genuine compliance breach. This guide shows you how to steer cleanly between those two mistakes.
The key points at a glance
- A DPIA is mandatory under Art. 35 GDPR when a processing operation is likely to result in a high risk to the rights and freedoms of natural persons.
- For AI it is not automatically mandatory. “New technologies” are only an indicator — what matters is the documented threshold analysis of the specific case.
- Clear mandatory indicators: profiling/automated decisions, special categories of data on a large scale, systematic monitoring, and entries on the supervisory authorities’ DPIA “must” lists.
- The process can be structured in 6 steps; if the residual risk remains high, prior consultation with the supervisory authority follows (Art. 36 GDPR).
- DPIA ≠ FRIA: For high-risk AI, the EU AI Act may require both assessments — one does not replace the other.
What is a Data Protection Impact Assessment (DPIA)?
A Data Protection Impact Assessment (German: Datenschutz-Folgenabschätzung, DSFA) is a risk assessment carried out in advance under Art. 35 GDPR. In it, the controller systematically estimates the consequences a planned processing operation will have for the rights and freedoms of data subjects, evaluates those risks, and defines mitigation measures. It is mandatory whenever the processing is likely to result in a high risk.
The decisive point: a DPIA is not a box-ticking form but a steering instrument used before launch. Its purpose is to identify risks before the processing goes live — not to document after the fact what is already happening anyway.
Is a DPIA always mandatory for AI?
No, not across the board. Art. 35(1) GDPR names “the use of new technologies” expressly only as one example (“in particular”) that can point to a high risk. It is not automatic. What is decisive remains whether the specific processing — by its nature, scope, context, and purposes — is likely to give rise to a high risk.
In practice this means: if you deploy AI, you must carry out a threshold analysis (German: Schwellwertanalyse, the preliminary screening that determines whether a full DPIA is required). If that analysis finds no likely high risk, no DPIA is mandatory. But take note — you must justify and document this negative finding in writing. The threshold analysis itself is therefore never dispensable; only the full DPIA may, depending on the outcome, be omitted.
This precision is not legal hair-splitting. It protects you from two costly mistakes: wasted effort on DPIAs that were never required, and unnoticed gaps where a DPIA would have been mandatory.
When is a DPIA mandatory for AI systems?
Three sources are decisive: the statutory standard examples, the supervisory authorities’ “must” lists, and the nine criteria set out by Europe’s data protection regulators.
The three standard examples in Art. 35(3) GDPR
A DPIA is required in particular for:
- A systematic and extensive evaluation of personal aspects based on automated processing — including profiling — that serves as the basis for decisions with legal effect (e.g., AI-assisted applicant scoring, credit or creditworthiness scoring).
- Large-scale processing of special categories of data under Art. 9 (health, biometric data, beliefs, etc.) — for instance AI-based diagnostic support in healthcare.
- Systematic large-scale monitoring of publicly accessible areas — for instance AI-assisted video analytics or facial recognition.
If one of these standard examples applies to your AI system, the obligation to carry out a DPIA is effectively indicated.
The supervisory authorities’ DPIA “must” list (Art. 35(4))
Under Art. 35(4) GDPR, supervisory authorities publish lists of processing operations for which a DPIA must be carried out. Several of these “must” lists apply directly to typical AI scenarios — for example using AI to evaluate or predict behavior, automated decisions with significant effects, or processing large volumes of data from disparate sources. Check the list of your competent supervisory authority, since the lists differ between the German federal states (Bundesländer).
The nine criteria (WP248 / EDPB): two criteria and it gets serious
The former Article 29 Working Party (today the European Data Protection Board, EDPB) defined nine criteria in its guidance WP248 that indicate a high risk — among them scoring/profiling, automated decisions with legal effect, systematic monitoring, sensitive data, large volumes of data, data matching, data concerning vulnerable persons, innovative technologies, and processing that prevents data subjects from exercising their rights.
The supervisory authorities’ rule of thumb: if your processing meets at least two of these nine criteria, a DPIA is generally required. AI projects reach that threshold quickly — for instance when a system carries out profiling and uses an innovative technology at the same time.
Typical AI scenarios at a glance
| AI application | DPIA trigger | Mandatory? |
|---|---|---|
| AI applicant/HR scoring | Profiling + decision with legal effect | Yes |
| AI credit/creditworthiness scoring | Automated individual decision (Art. 22) | Yes |
| AI diagnostic support (healthcare) | Special categories of data, large scale | Yes |
| Facial recognition / video analytics | Systematic monitoring, biometrics | Yes |
| Internal chatbot with no personal data | No high risk to individuals | Probably not (assess) |
| AI writing aid sending customer data to a third-country provider | Data outflow, possibly innovative technology | Assess (threshold analysis) |
The table is no substitute for a case-by-case assessment — it provides orientation. The binding evaluation comes from your documented threshold analysis.
Threshold analysis: how to check whether your AI system needs a DPIA
The threshold analysis is the upstream filter. It answers the question: Do I even need to carry out a full DPIA? In practice you proceed as follows: you describe the planned processing in broad terms, compare it against the standard examples (Art. 35(3)), the “must” list of your supervisory authority, and the nine WP248 criteria, and arrive at a reasoned conclusion.
The most common mistake: companies run the threshold analysis in their heads and record nothing. That is a problem. Because even a “no, no DPIA needed” has to be a deliberate, traceable decision that is documented — otherwise, when in doubt, you have nothing to show the supervisory authority. In practice a short, dated note is enough: the processing assessed, the criteria applied (standard examples, “must” list, WP248), the outcome and its reasoning, and the sign-off. That note is your evidence under the accountability principle (Art. 5(2) GDPR) — and in a dispute it is often the difference between “cleanly documented” and “cannot be proven”.
The threshold analysis is the upstream filter: it compares the planned AI processing against the standard examples, the “must” list and the WP248 criteria — and always ends in a documented decision, even when the outcome is “no DPIA needed.”
Carrying out a DPIA — in 6 steps
If a DPIA is required, structure it along these six steps:
- Systematic description of the processing — capture the purpose, types of data, the AI model used, the data flows, and the processors or model providers involved.
- Assess necessity and proportionality — is the AI-assisted processing genuinely needed, or could it be done with less data?
- Identify risks to rights and freedoms — for example discrimination through bias, opacity of the AI decision, re-identification, unintended outflow of data to the model provider.
- Evaluate the risk — likelihood × severity of harm in a risk matrix, graded from low to high.
- Define mitigation measures — technical and organizational: privacy by design (Art. 25), anonymization/pseudonymization, a data processing agreement, EU data residency, human-in-the-loop for automated decisions.
- Document the result and monitor it — involve the data protection officer (Art. 35(2)), review the DPIA regularly, and, where a high residual risk remains, consult the supervisory authority (Art. 36).
Who is involved?
Responsibility for the DPIA lies with the controller within the meaning of the GDPR — that is, your company. You must seek the advice of the data protection officer (Art. 35(2)). In practice, the business unit using the AI and often the developers or model provider also contribute — because only they know the data flows in detail. It is precisely at this interface between law and technology that most gaps arise.
DPIA and the EU AI Act: what is the difference from the FRIA?
The EU AI Act introduces a second assessment instrument: the Fundamental Rights Impact Assessment (FRIA) under Art. 27 of the AI Act (KI-VO). The AI Act has applied since 1 August 2024; the bans on unacceptable practices have applied since 2 February 2025, and the obligations for general-purpose AI (GPAI) models since 2 August 2025. Many people confuse the two or hope that one replaces the other. It does not.
Art. 27(4) of the AI Act makes it clear: an existing DPIA does not render the FRIA superfluous — the FRIA complements the DPIA. The DPIA under Art. 35 GDPR protects personal data; the FRIA targets a broader spectrum of fundamental rights — such as non-discrimination, freedom of expression, human dignity, and access to justice. Synergies are expressly encouraged: information from a DPIA already prepared may feed into the FRIA.
| Feature | DPIA (Art. 35 GDPR) | FRIA (Art. 27 AI Act) |
|---|---|---|
| Legal basis | GDPR | EU AI Act |
| Protected interest | Personal data | Fundamental rights in the broader sense |
| Trigger | Processing likely to result in a high risk | Certain high-risk AI (incl. Annex III) for certain actors |
| Relationship | does not replace the FRIA | complements the DPIA (Art. 27(4)) |
What this means in practice: if you operate a high-risk AI system that also processes personal data, both assessments may be required. Anyone thinking only of the GDPR overlooks the second half of the obligation.
Note (as of May 2026): The application of individual EU AI Act obligations is taking effect in stages and is the subject of ongoing adjustments. On 7 May 2026, Parliament and Council reached a provisional agreement on the “Digital Omnibus” package (Commission proposal of 19 November 2025), which postpones key deadlines for high-risk AI — for instance, for standalone high-risk systems under Annex III to 2 December 2027. The FRIA obligation itself is unaffected. Check the current status and your specific exposure before implementation.
Real-world example: a DPIA for an AI agent / RAG system
A mid-sized service provider wants to introduce an AI assistant that answers customer inquiries and, to do so, accesses internal documents containing customer data via retrieval-augmented generation (RAG). The language model runs at a US provider.
The threshold analysis shows: personal customer data is processed, transferred to a third-country provider, and combined with an innovative technology — at least two WP248 criteria are met, plus a third-country transfer. A DPIA is indicated.
In the DPIA the company identifies the main risks as the outflow of data to the model provider, possible re-identification from context data, and incorrect responses from the system with effects on data subjects. The mitigation measures: a data processing agreement with the provider, an enterprise plan that allows no training on the inputs, EU data residency or hosting in Europe, pseudonymization of the context data before handover, and a human-in-the-loop for sensitive responses. The remaining residual risk thereby drops below the threshold for prior consultation — documented, verifiable, and audit-proof.
Common mistakes in DPIAs for AI
- Started too late: the DPIA belongs before going live, not after.
- Threshold analysis not documented: even a reasoned “no DPIA needed” must exist in writing.
- Data flow to the model provider overlooked: especially with cloud AI, this is the biggest and most frequently underestimated risk.
- Treating the DPIA as a one-off exercise: if the AI system, the data basis, or the purpose changes, the DPIA must be updated.
- Forgetting the FRIA: for high-risk AI, remember the Fundamental Rights Impact Assessment — the DPIA alone is then not enough.
Frequently asked questions (FAQ)
Is a DPIA always mandatory for AI?
No. In Art. 35(1) GDPR, “new technologies” are only an indicator, not an automatic trigger. Whether a DPIA is mandatory is decided by the documented threshold analysis of the specific case. If it finds no likely high risk, the DPIA is dropped — but the decision must be justified in writing.
Do I need a DPIA for ChatGPT, Copilot, or an AI agent?
That depends on what you process with it. An AI tool with no personal data generally triggers no DPIA obligation. But as soon as you enter personal data, transfer it to a third-country provider, or carry out profiling, the threshold can be reached quickly. Run a threshold analysis and document the result.
How long does a DPIA take, and can I do it myself?
A focused DPIA for a clearly defined AI project is doable within a few days; complex systems take longer. You can in principle carry it out yourself — but you must seek the advice of the data protection officer under Art. 35(2) GDPR. Support makes sense where law and technology meet, for instance in evaluating data flows and mitigation measures.
What happens if the risk remains high despite the measures?
Then prior consultation under Art. 36 GDPR applies: you must involve the supervisory authority before the processing begins. The authority issues a written recommendation within up to eight weeks (extendable). Only after that may you start the processing — adjusted if necessary.
Do I have to submit the DPIA to the supervisory authority?
As a rule, no. The DPIA stays with you as evidence (accountability obligation). It only needs to be submitted as part of the prior consultation under Art. 36 GDPR or upon request by the supervisory authority.
Conclusion and next step
A DPIA for AI is neither a bureaucratic monster nor a reflexive obligation — it is a reasoned risk decision that you must make in a demonstrable way. The key lies in the right sequence: first the threshold analysis, then — if needed — the structured DPIA in six steps, and for high-risk AI a look at the FRIA.
It is precisely at the seam between GDPR obligation and technical implementation that the expensive gaps arise. If you want to set up your AI project in a way that is legally sound and technically clean — from the threshold analysis to the mitigation measure actually implemented — let’s talk it over in a no-obligation initial conversation. As a business lawyer (German Wirtschaftsjurist) who also builds the solution, you get both from a single source.
This post is general information and is not legal advice for an individual case. A binding assessment of your specific AI project requires an individual review.
Author: Leon Lotz, business lawyer (Wirtschaftsjurist) — AI consulting and custom software development, MusketierSoftware.
Sources — as of 22.05.2026
- Art. 35 GDPR — Data Protection Impact Assessment (dsgvo-gesetz.de)
- Art. 36 GDPR — Prior consultation (dsgvo-gesetz.de)
- WP248 rev.01 — Guidelines on Data Protection Impact Assessment (Datenschutzkonferenz)
- HmbBfDI — DPIA “must” list, non-public sector (Art. 35(4))
- ULD — Short paper No. 5: DPIA under Art. 35 GDPR
- keyed.de — Threshold analysis and risk assessment
- dr-datenschutz.de — Fundamental Rights Impact Assessment: Art. 27 AI Act
- activeMind.legal — Fundamental Rights Impact Assessment under the AI Act (FRIA)
- dr-datenschutz.de — Data Protection Impact Assessment
- European Commission — Regulatory framework for AI / AI Act timeline
- Council of the EU — AI: Council and Parliament agree to simplify the rules (07.05.2026)
Related reading
Leon Lotz
Leon Lotz is a business lawyer and founder of MusketierSoftware. He combines legal depth with real software craft.
