The short answer
Under GDPR Article 35, a Data Protection Impact Assessment (DPIA) is mandatory whenever processing—particularly using new technologies like AI—is likely to result in a high risk to the rights and freedoms of natural persons.
If an AI tool performs automated decision-making, processes employee performance metrics, handles sensitive personal data (special category data), or monitors individuals at scale, a DPIA is legally required prior to deployment. Deploying high-risk AI without a DPIA can trigger fines under GDPR of up to €10 million or 2% of global annual turnover.
The DPIA Trigger Criteria: The 9 Working Party 29 Criteria
EU Data Protection Authorities evaluate whether a processing activity requires a DPIA based on nine criteria established by the European Data Protection Board (EDPB/WP29). Meeting two or more of these criteria triggers a mandatory DPIA requirement:
- Evaluation or scoring: Including profiling, performance prediction, or candidate screening using AI.
- Automated decision-making with legal or similar significant effect: AI systems that approve/deny loans, select job applicants, or determine insurance rates.
- Systematic monitoring: Tools that track employee behavior, keystrokes, prompt logs, or continuous code activity.
- Sensitive data or data of a highly personal nature: Special category data (health, biometric, political) or financial account details processed by LLMs.
- Data processed on a large scale: Processing data affecting large numbers of individuals or large geographical areas.
- Matching or combining datasets: Feeding data from separate internal systems into an AI RAG pipeline.
- Data concerning vulnerable data subjects: Processing data of children, employees (due to power imbalance), or asylum seekers.
- Innovative use or applying technological or organisational solutions: Using Large Language Models, generative AI, or autonomous AI agents (inherently considered innovative tech under GDPR).
- Preventing data subjects from exercising a right or using a service: AI systems that act as gateways to employment, banking, or utilities.
Because generative AI inherently meets Criterion 8 (“innovative tech”), adding almost any second criterion (such as processing employee code or customer emails) triggers a mandatory DPIA.
Step-by-Step DPIA Execution Framework for AI
A compliant DPIA for an AI tool must contain four core sections:
1. Systematic Description of Processing
- Document the architecture, model sources, and input/output flows.
- Specify whether prompt inference occurs within the EEA or involves cross-border transfers. See our guide on EU data residency for AI: inference vs storage.
- Define data retention schedules for vendor abuse logs and internal RAG databases.
2. Assessment of Necessity and Proportionality
- Verify the lawful basis under GDPR Article 6. See our guide on GDPR lawful basis for AI tools at work.
- Demonstrate data minimization: explain why full prompt context is necessary and describe pre-processing redaction controls.
3. Assessment of Risks to Data Subjects
Identify specific AI-related privacy risks:
- Risk of hallucinated or inaccurate outputs affecting individuals.
- Risk of model training leaking personal data into future completions.
- Risk of prompt injection attacks extracting sensitive context. Read our guide on prompt injection explained.
4. Mitigating Controls and Safeguards
Document technical and organizational countermeasures:
- Signed Data Processing Addendums (DPAs) with enterprise vendors.
- Zero-Data-Retention (ZDR) configuration for API endpoints.
- Role-based access control (RBAC) and secret scanning.
Decision Matrix: Is a DPIA Required?
| Use Case Scenario | DPIA Required? | Primary Trigger Criteria |
|---|---|---|
| AI Coding Assistant for internal developers | Recommended / Likely | Innovative tech + Employee monitoring/data |
| AI Customer Support Bot handling general FAQs | Optional | Innovative tech (1 criterion only) |
| AI Resume / Job Applicant Screening Tool | Mandatory | Automated decision-making + Evaluation/scoring |
| AI Fraud Detection analyzing bank transactions | Mandatory | Systematic monitoring + Financial data |
| AI Summarizer for Internal Employee Meetings | Mandatory | Innovative tech + Employee data + Large scale |
The two-criteria rule is a rule of thumb, not a threshold
The nine criteria are a useful screening tool and they are frequently misunderstood as a scoring system. The guidance is that processing meeting two or more criteria will in most cases require a DPIA — but a controller may conclude that a single criterion is enough, and conversely may document a reasoned view that meeting two does not create high risk in a particular case.
Two things sit above the criteria and are more decisive:
Your national authority’s mandatory list. Article 35(4) requires each supervisory authority to publish a list of processing operations that always require a DPIA. These lists differ by Member State and several explicitly name AI, automated evaluation, or systematic employee monitoring. If your processing is on your authority’s list, the criteria are irrelevant — a DPIA is mandatory. Check the list for every country you operate in, not just your headquarters.
The reasoned negative. If you conclude no DPIA is needed, write down why, with the criteria you considered and the date. An undocumented decision not to assess is indistinguishable from never having thought about it, and that distinction is what an investigation turns on. This costs half a page and is the highest-value document on this page for low-risk deployments.
Article 36: when you must consult the regulator before deploying
This is the part of Article 35 that surprises people, and it has a real timeline attached.
If the DPIA concludes that the processing would result in a high risk in the absence of measures taken to mitigate it, and you cannot sufficiently mitigate that residual risk, you must consult the supervisory authority before processing begins. The authority has eight weeks to respond, extendable by six further weeks for complex processing.
Fourteen weeks is a schedule item, not a formality. A deployment plan that assumes a DPIA is a document to be written the week before launch has no room for this, and discovering the obligation late is how projects stop.
In practice, most competently mitigated AI deployments do not reach this threshold — the residual risk after a DPA, retention limits, access controls and data minimisation is usually not “high”. But the assessment has to be genuine for that conclusion to hold, which is the point.
Who has to be involved
A DPIA written by one person in a security team is a weaker document than the regulation contemplates, and Article 35 names the participants.
You must seek the advice of the DPO where one is designated, and record it. Where the DPO’s advice was not followed, record the reasons — this is a frequently skipped step that is trivially checkable after the fact.
You must, where appropriate, seek the views of data subjects or their representatives. For a workplace tool this generally means employee representatives or a works council, and in several Member States that consultation is separately mandatory under labour law before introducing systems capable of monitoring performance. Doing both conversations at once is considerably easier than doing them in sequence after an objection.
Your processors must assist you under Article 28(3)(f). If a vendor cannot tell you where inference happens, what is retained and for how long, you cannot complete a DPIA — and that inability is itself a finding worth recording. How to get a DPA for an AI tool covers extracting these answers.
A DPIA is a living document
The most common failure is not the absence of a DPIA. It is a DPIA that was accurate at the pilot and describes nothing that is now true.
Re-open it when any of these change: the vendor’s terms or sub-processor list, the model or tier in use, the scale of deployment, the categories of data going in, the geography of inference, or the purposes — particularly if telemetry starts being used for evaluation rather than support.
Set a review date regardless. Annually is defensible for stable processing; quarterly is more realistic in the first year of a fast-moving tool.
Where the AI Act sits alongside this
A DPIA is a GDPR instrument protecting personal data. The EU AI Act imposes a separate, parallel set of obligations organised by risk classification of the AI system itself, and for some deployers of high-risk systems it requires a fundamental rights impact assessment — a different assessment, with a different scope, that can draw on the DPIA but does not replace it or get replaced by it.
Several use cases in the decision matrix above — applicant screening most clearly — attract obligations under both regimes simultaneously. Where your deployment is in that territory, scope the AI Act analysis at the same time rather than discovering it separately, and note that deadlines under that regime depend on when a model was placed on the EU market rather than on when you adopted it. The provider directory records that date per model where it has been verified.
To evaluate vendor data policies during your DPIA assessment, consult our guide on how to judge an AI provider, and GDPR lawful basis for AI tools at work for the Article 6 analysis a DPIA assumes you have already done.