AI DPIA: when is it required? Five-step check (2026)

Short answer: a DPIA is required when the processing of personal data by your AI system is likely to result in a high risk to the rights and freedoms of individuals (Article 35(1) GDPR). That is always the case in the three situations of Article 35(3): automated evaluation or profiling on which decisions with legal effects are based, large-scale processing of special category or criminal offence data, and systematic large-scale monitoring of publicly accessible areas. A DPIA is also required for any processing on your supervisory authority's list under Article 35(4); the Dutch DPA's list of mandatory DPIAs, for example, includes profiling, fraud prevention, credit scores and employee monitoring. If your system falls outside those, test it against the nine criteria in the guidelines endorsed by the EDPB: in most cases two or more mean a DPIA is needed. Only an AI system that processes no personal data at all clearly falls outside the obligation.

Just need the yes or no? The short answer to whether a DPIA is required is on one page.

A data protection officer at a health insurer receives a question from the innovation department: "We want to deploy an AI model that predicts claim behaviour. Do we need to do anything about that?" The answer is yes, and what she needs to do is a DPIA. But not just any DPIA. One specifically designed around the risks that AI systems bring.

The Data Protection Impact Assessment (DPIA) is not a new instrument. Article 35 of the GDPR has required it since 2018. But the rise of AI systems processing personal data at ever-increasing scale makes the DPIA more relevant than ever. And with the EU AI Act, in force since 1 August 2024 and applying in stages (Article 113), a new landscape emerges where the DPIA plays its own role alongside the FRIA (Fundamental Rights Impact Assessment). Since the Digital Omnibus (Regulation (EU) 2026/1744) that FRIA duty applies from 2 December 2027; for systems already in use before that date and intended for use by public authorities, by 2 August 2030 at the latest (Article 111(2)).

In this article you can check in five steps whether a DPIA is required, how to conduct one for AI, what supervisory authorities expect, and how to combine the DPIA with AI Act obligations.

When is a DPIA required for AI? Five steps

Article 35(1) GDPR states that a DPIA is required when processing is "likely to result in a high risk to the rights and freedoms of natural persons." For AI systems that process personal data this is often the case, but the law gives a fixed order for deciding it. Work through these five steps in this order.

Step 1: does the AI system process personal data?

The GDPR only applies to personal data. Do not look at the input alone: training data, prompts, log files and the output the system produces about a person can all be personal data. If the system processes no personal data at all, for example a model optimising manufacturing processes based on machine data, there is no DPIA obligation. In every other case, go to step 2.

Step 2: does it fall under one of the three situations of Article 35(3)?

In these three situations a DPIA is always required:

a) Automated evaluation with legal effects. A systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect people. Think of an AI system that determines whether someone gets a loan, can take out insurance, or qualifies for a benefit. For AI systems this is the most common trigger.

b) Large-scale processing of special category or criminal offence data. When your AI system processes, on a large scale, special category data (Article 9, such as health data or biometric data used to uniquely identify someone) or data relating to criminal convictions and offences (Article 10). An AI model analysing medical images at scale falls directly under this.

c) Systematic and large-scale monitoring of publicly accessible areas. Camera systems with facial recognition, crowd analysis with AI, or smart sensors in public spaces. The combination of AI and surveillance is a classic DPIA trigger.

If your application falls under one of these, the DPIA is required. If not, go to step 3.

Step 3: is the processing on your supervisory authority's list?

Under Article 35(4), each supervisory authority adopts a list of processing operations that require a DPIA. Specifics vary by country. The Dutch DPA's list names 17 types of processing (Government Gazette 2019, no. 64418); for AI applications these categories are the most relevant:

• Profiling and observing and influencing behaviour
• Fraud prevention, blacklists and covert investigation
• Credit scores and people's financial situation
• Employee monitoring
• Biometric data, health data and genetic data
• Camera surveillance, location data, communication data and the internet of things

Note: the authority sets its own condition for each category, often that the processing is large-scale or systematic. Read the description of the category that resembles your application. The full list with those conditions is on our page about the Dutch DPA list of mandatory DPIAs. The list is not exhaustive: if your processing is not on it, a DPIA may still be required. That is what step 4 is for.

Step 4: test against the nine criteria of the EDPB guidelines

If the processing is not covered by step 2 or 3, you assess yourself whether a high risk is likely. The guidelines of the former Article 29 Working Party, endorsed by the EDPB (WP248 rev.01), list nine criteria:

1. Evaluation or scoring, including profiling and predicting
2. Automated decision-making with legal or similarly significant effect
3. Systematic monitoring
4. Sensitive data or data of a highly personal nature
5. Data processed on a large scale
6. Matching or combining datasets
7. Data concerning vulnerable data subjects, such as employees, children or patients
8. Innovative use or applying new technological or organisational solutions
9. Processing that prevents data subjects from exercising a right or using a service or contract

If the processing meets two or more criteria, the guidelines say a DPIA is required in most cases. A new AI application can fall under criterion 8, and using AI on your own staff touches criterion 7, because the guidelines treat employees as vulnerable data subjects. One more criterion can then be enough.

Step 5: record the outcome, also when you do not carry out a DPIA

If you conclude that no DPIA is needed although the processing meets one or more criteria, justify that and record the reasons; the guidelines ask for this explicitly. A DPIA is not needed when:

• the AI system processes no personal data (step 1);
• a single DPIA already covers a set of similar processing operations presenting similar high risks (Article 35(1), last sentence);
• the processing has a legal basis for which a general impact assessment was already carried out when that basis was adopted, unless the Member State deems a DPIA necessary (Article 35(10)).

If the DPIA is required, carry it out before the processing starts (Article 35(1)). And even when a DPIA is not formally required, it can be wise to do one anyway: it helps you demonstrate compliance with the GDPR (accountability, Article 5(2)).

What makes a DPIA for AI different?

A DPIA for a traditional information system (a CRM, an HR database) is relatively straightforward. You know what data goes in, what happens to it, and what comes out. With AI systems, that is fundamentally different.

Model opacity

With many AI systems, particularly deep learning models, it is difficult or impossible to explain exactly how the model arrives at a particular output. This directly affects the transparency principle of the GDPR (Article 5(1)(a)) and the safeguards for automated decision-making (Article 22(3)). In your DPIA, you describe how you deal with this opacity.

Training data as a risk source

The AI model is only as good as the data it was trained on. Bias in training data leads to discriminatory outcomes. In your DPIA, you assess the provenance, quality and representativeness of training data. Questions you need to answer:

• Is the training data representative of the population to which the model is applied?
• Does the training data contain historical biases the model could reproduce?
• Was the training data lawfully obtained, and is there a valid legal basis for its use?
• How do you handle personal data in the training set after training?

Model drift and continuous change

Unlike traditional systems, AI models can change over time. A model that is retrained (fine-tuning) or works with real-time data (online learning) can gradually drift from its original behaviour. Your DPIA is therefore not a one-off document but a living instrument that you review periodically.

Emergent behaviour

Large language models and other generative AI systems can exhibit unexpected behaviour that does not follow directly from the training data or the system configuration. In your DPIA, you describe how you monitor for unforeseen behaviour and what measures you take when the model behaves unexpectedly.

Conducting the DPIA step by step

The GDPR prescribes in Article 35(7) four minimum elements for the content of a DPIA. Below we work through each element with specific points of attention for AI systems.

Element 1: systematically describe the processing

Start with a complete description of the AI system and how it processes personal data.

First describe the AI system itself: what type of model is it (rule-based, machine learning, deep learning, generative), what is its function, and which decisions does it support or make? Who is the provider and who is the deployer? What input does the system receive and what output does it produce?

Then map the data flows. Which personal data enters the system as direct input, training data or contextual data? How is that data processed within the model? Where is it stored: locally, in the cloud or with the provider? And is data shared with third parties, such as API providers or cloud vendors?

Next, identify the data subjects: which categories of people are affected, how many people potentially, and whether vulnerable groups are involved, such as minors, patients or employees.

Finally, record the legal basis. Which ground under Article 6 GDPR is the processing based on? For special category data: which exception under Article 9(2) applies? And for automated decision-making: does an exception under Article 22(2) apply?

Element 2: assess necessity and proportionality

This is the step many organisations rush through. You must demonstrate that the use of AI technology is necessary and proportionate for the purpose you want to achieve.

Start with purpose limitation: is the purpose of the AI processing specified, explicit and legitimate? Could the same purpose be achieved without AI or with less intrusive means? If a simple decision tree produces the same result, a complex neural network is hard to justify.

Next, look at data minimisation. Does the AI system only process the personal data that is strictly necessary? Many AI models are trained on more data than needed simply because the data is available. That is not a valid justification.

Also assess storage limitation: how long is personal data retained, and can training data still be traced back to individuals after training? And finally accuracy: how do you ensure the AI system's output is accurate, and what error rate is acceptable given the impact on data subjects?

Element 3: identify and assess the risks

This is where the DPIA becomes AI-specific. Beyond the usual privacy risks, you look at five additional risk categories for AI systems. To add those AI questions to your existing DPIA template as a fixed module, with the evidence that belongs to each part, use the AI addendum to your DPIA.

Discrimination and bias is the most discussed risk. Can the model systematically disadvantage certain groups based on protected characteristics? How do you test for bias before and after deployment, and which fairness metrics do you apply? An AI system that evaluates job applicants and structurally scores women lower is not only unethical but also contrary to the GDPR and equal treatment law.

With unlawful profiling, you examine whether the system creates profiles of individuals based on their behaviour, location or other characteristics. Are those profiles accurate, and are they used for purposes data subjects can reasonably expect?

Loss of autonomy concerns the extent to which the AI system determines what people see, which choices they can make, or how they are assessed. Is meaningful human intervention possible, or does the system in practice act as a black box that dictates decisions?

Also assess security risks: how vulnerable is the model to adversarial attacks, data poisoning or model extraction? And what happens if the model is compromised?

Finally, transparency risks. Do data subjects know they are dealing with an AI system? And can they understand how the system reaches a decision? With complex models full explainability is often not achievable, but you do describe the steps you take to be as transparent as possible.

Element 4: describe the measures

For each identified risk, you describe the measures you take to mitigate it.

For AI systems, the most common measures include: periodic bias audits to test for fairness and discrimination, explainability tools such as SHAP or LIME to explain model outcomes, and a human-in-the-loop setup where a human reviews high-impact decisions.

Additionally, continuous monitoring is essential: you track model drift, performance degradation and unexpected behaviour. Establish solid data governance with quality controls on training data and documentation of data provenance. Restrict via access control who can call the model and which data it can access. And ensure you have an incident procedure describing what happens when the AI system produces erroneous or harmful output.

The role of the DPO for AI systems

The Data Protection Officer (DPO) has a statutory advisory role in the DPIA: where a DPO has been designated, you seek their advice (Article 35(2) GDPR). For AI systems, this role is especially important.

Involve the DPO at an early stage, not just when the system has already been procured or built. Consult the DPO during selection of an AI vendor (what data goes to the provider?), during design of data flows (which personal data is truly needed?), during the testing phase (are test results acceptable from a privacy perspective?), at the decision to put the system into production, and at every significant change to the model or data.

Record the DPO's advice and how it was followed up in the DPIA. That way you can show during an inspection what was done with the advice. How the DPO fills that role on a permanent footing alongside the rest of AI governance, and where the role stops, is set out in AI governance through the privacy function.

Prior consultation: when to contact the authority

A frequently forgotten obligation: Article 36 GDPR requires you to consult the supervisory authority when the DPIA indicates that the processing would result in a high risk in the absence of measures to mitigate it.

With AI systems, this occurs more often than with traditional systems. Model opacity, the potential for bias and the scale of processing make it harder to reduce all risks to an acceptable level.

The procedure works as follows:

1. You provide the DPIA to the supervisory authority, together with a description of the measures already taken (Article 36(3))
2. The authority gives written advice within 8 weeks; that period can be extended by 6 weeks (Article 36(2))
3. The authority can use its powers, up to and including a ban on the processing (Article 58)

In practice, we recommend informing the authority early when you intend to deploy an AI system for automated decision-making with significant impact on individuals.

DPIA and the EU AI Act: dual obligations

Since the EU AI Act came into force, organisations may face both a DPIA obligation (GDPR) and a FRIA obligation (AI Act, Article 27). These are two different assessments with different focus areas.

The DPIA finds its legal basis in Article 35 GDPR and focuses on the protection of personal data. The supervisor is the national data protection authority. A missing or deficient DPIA falls under the fine tier of Article 83(4) GDPR: up to 10 million euro or 2 percent of worldwide annual turnover. Any controller whose processing is likely to result in a high risk must conduct a DPIA.

The FRIA is based on Article 27 of the AI Act and looks beyond privacy: at all fundamental rights an AI system may affect. The deployer notifies the market surveillance authority of the results (Article 27(3)). The duty applies only to certain deployers of high-risk systems listed in Annex III (except point 2, critical infrastructure): bodies governed by public law and private entities providing public services, and anyone using AI for creditworthiness or for life and health insurance (Annex III point 5(b) and (c)). The AI Act sets no specific fine ceiling for Article 27; penalties follow from national rules (Article 99(1)).

The five key differences and the combined approach are in our comparison: the difference between a DPIA and a FRIA.

How to combine DPIA and FRIA

Article 27(4) of the AI Act lets you refer in the FRIA to the parts of the DPIA that already cover an obligation, or include those parts. In practice, this means:

1. Start with the DPIA (it is broader in scope for data protection)
2. Add the FRIA elements of Article 27(1) as separate sections (non-discrimination, human dignity, access to justice, and so on)
3. Document per right both the privacy impact and the broader fundamental rights impact
4. Use a template covering both assessments

Conformity assessment: the third layer

Beyond DPIA and FRIA, the AI Act also has the conformity assessment (Article 43) for providers of high-risk AI systems. Where the DPIA examines data processing risks and the FRIA examines fundamental rights risks, the conformity assessment focuses on technical and organisational requirements such as the Annex IV documentation and the quality management system. As a provider of a high-risk AI system you may face all three. As a deployer, usually the DPIA, plus the FRIA if Article 27 applies to you.

Practical examples

Example 1: AI chatbot for customer service

A telecom company wants to deploy an AI chatbot that can access customer data to answer questions.

DPIA trigger: large-scale processing of personal data and innovative technology (criteria 5 and 8 from step 4).

Specific risks:

• The chatbot could accidentally show personal data of customer A to customer B (data breach)
• The model may have been trained on customer conversations without a valid legal basis
• Sensitive information (payment arrears, complaint history) could unintentionally appear in responses

Measures: strict access control per session, output filtering for personal data, no training on production data without pseudonymisation, clear notification that it is an AI system.

Example 2: HR screening with AI

A recruitment agency wants to use AI to automatically screen and rank CVs.

DPIA trigger: automated decision-making with significant effects and profiling (step 2 under a, and the profiling category on the Dutch DPA list).

Specific risks:

• Discrimination based on gender, age, ethnicity or postcode (proxy discrimination)
• Candidates rejected without human review
• Training data reflects historical hiring bias

Measures: mandatory human review of all rejections, a bias audit before deployment, no use of protected characteristics as features, transparency to candidates about AI use, regular fairness monitoring.

Example 3: predictive analytics in healthcare

A health insurer wants to use AI to predict the risk of chronic conditions and offer preventive programmes.

DPIA trigger: special category data (health), profiling and large-scale processing.

Specific risks:

• Health data is one of the most sensitive categories of personal data
• Risk profiles could lead to exclusion from insurance coverage
• Predictions can be stigmatising
• Inaccurate predictions could lead to unnecessary medical interventions

Measures: a valid legal basis and exception for health data, strict pseudonymisation, no use for acceptance policy (prevention only), validation by medical professionals, an opt-out for insured persons.

DPIA as a living document

A common mistake is to treat the DPIA as a one-off approval document. For AI systems, that is a recipe for problems. The GDPR prescribes in Article 35(11) that you review whether processing is performed in accordance with the DPIA, at least when the risk changes.

For AI systems, specific moments requiring review include:

• The model is retrained with new data
• The input data changes significantly (different sources, different population)
• The system is deployed for a new purpose or new target group
• There have been incidents with the AI system
• Laws and regulations change (such as the phased application of the AI Act)
• The technology changes fundamentally (switch to a different model type)

We recommend reviewing the DPIA at least annually, and more frequently when the AI system is actively being retrained.

DPIA template for AI systems

The DPIA template for AI systems follows the steps in this guide: a decision box on whether the DPIA is required, the data flows from training to feedback, the legal basis per processing operation, a decision box for Article 22 GDPR, a risk matrix with measures, the DPO's advice and a bridge to the fundamental rights impact assessment under Article 27 of the AI Act. It is an editable Word file, checked against the law on 6 October 2026. If you would rather compare with the official model, the EDPB DPIA template (consultation version) is described separately.

Conclusion

The DPIA for AI systems is not a formality. It is the instrument through which you demonstrate that you take people's privacy seriously now that AI systems increasingly intervene in daily life. With the EU AI Act, the DPIA also becomes part of a broader compliance landscape that includes the FRIA and the conformity assessment.

Start early, involve your DPO, be honest about the risks, and treat the DPIA as a living document. That is not only what the law prescribes, it is also what protects your organisation.

More on the relationship between DPIA and FRIA? Read our DPIA and FRIA comparison. Does the FRIA duty apply to you too? The FRIA guide to Article 27 and the FRIA Generator will help.