AI DPIA: Data Protection Impact Assessment for AI

Definition: An AI data protection impact assessment (AI DPIA) is a data protection impact assessment under Art. 35 GDPR that looks at the special traits of AI systems. These include where the training data comes from and whether it was lawfully used. They also include the risk that a model reveals personal data, and automated decisions about people. An AI DPIA is not a separate legal tool. It is the familiar DPIA, adapted to AI.

When is a DPIA required for AI?

Art. 35 GDPR requires a DPIA when processing is likely to pose a high risk to the rights and freedoms of people. AI tools often reach this level, because several risk criteria meet:

New technologies: The guidelines of the European data protection authorities name the new use of new technical solutions as a criterion.
Evaluation and profiling: AI that screens job applicants, checks creditworthiness or rates staff performance often falls right under the examples in Art. 35(3) GDPR.
Scale and sensitive data: The risk rises with large amounts of data, with special categories under Art. 9 GDPR (such as health or biometric data) and with vulnerable groups such as employees.

The German supervisory authorities also keep a list of processing that needs a DPIA. It includes the use of artificial intelligence to steer contact with data subjects or to rate personal traits. An internal chatbot that only answers general questions about travel expense rules does not always need a full DPIA. But you should still write down your first screening.

What an AI DPIA must cover in addition

Training data and life cycle

An AI DPIA looks at every phase, not just the live use. The phases are data collection, training, fine-tuning, inference, logging and further development. For each phase, you must set out the purpose and the legal basis. If you use data for training that was collected for another purpose, you must check whether this change of purpose is allowed.

The European Data Protection Board gave its Opinion 28/2024 on AI models. Among other things, it said that a model is not anonymous by default. It also said that training data processed unlawfully can affect how the model may be used later.

Model-specific risks

Memorization and leakage: Models can repeat training data word for word. Or they can reveal it through targeted queries (membership inference, model inversion).
Wrong output: Generative AI can make false statements about real people. This clashes with the accuracy principle (Art. 5(1)(d) GDPR).
Discrimination: Biased training data can lead to worse results for some groups again and again.
Data subject rights: Access, correction and deletion are hard to put in place for trained models. The DPIA must explain how you deal with this. Options are filters, retraining or not using personal training data at all.
Third-party providers: For cloud AI services, check the processing agreements. Check whether the provider uses your inputs for training. And check transfers of data to other countries.

Automated decisions under Art. 22 GDPR

Art. 22 GDPR applies when an AI system makes decisions with legal or similarly major effects and no real human input. The Court of Justice of the EU ruled on this in the SCHUFA case (C-634/21, December 2023). Even a score made by a machine can fall under this rule if it plays a deciding role in a third party's decision.

So the DPIA should check whether human review is real or only on paper. It should also check how data subjects can state their view and challenge the decision.

Relationship with the AI Act's fundamental rights impact assessment

The EU AI Act (Regulation (EU) 2024/1689) brings in a fundamental rights impact assessment (FRIA) in Art. 27. It applies to deployers of certain high-risk AI systems. These are mainly:

public bodies
private entities that provide public services
deployers of systems that check creditworthiness
deployers of systems for risk assessment and pricing in life and health insurance

The duty applies together with the other high-risk rules. After the Digital Omnibus (in force since 27 July 2026), it applies from 2 December 2027 for systems under Annex III.

	DPIA (Art. 35 GDPR)	FRIA (Art. 27 AI Act)
Trigger	High risk from processing personal data	Use of certain high-risk AI by certain deployers
Scope	Rights and freedoms, with a focus on data protection	All fundamental rights, e.g. non-discrimination, access to services
Interplay	Where the DPIA already meets a duty, the FRIA adds to it (Art. 27(4) AI Act)

Art. 26(9) AI Act also asks deployers of high-risk systems to use the information from the provider when they carry out their DPIA. In practice, one joint assessment with a data protection part and a fundamental rights part works well.

A practical approach

Start early: Do the DPIA before you buy or build the system, not at the end of the project.
Describe the system: Write down the purpose, model type, data flows, providers, the role of humans and the effect of decisions.
Get provider information: Ask for the technical documents. Ask for details on training data, data use and where data is stored.
Assess risks for each life-cycle phase and assign measures. Examples are pseudonymization, output filters, access limits, bias tests and time limits for keeping prompts and logs.
Involve the data protection officer and business units. Also involve the works council where staff data is concerned.
Judge the remaining risk: If it stays high, consult the supervisory authority first (Art. 36 GDPR).
Review it often, above all after a model change, retraining or new purposes.

Conclusion

An AI DPIA is the most honest test of whether an AI project holds up under data protection law. But only if it looks at training data, model behavior and the effect of decisions, not just at where the servers are. SecTepe helps you align the DPIA with information security and the demands of the AI Act.

More terms in “AI & Machine Learning”

All terms in “AI & Machine Learning” →