A data protection impact assessment (DPIA) is the structured evaluation of what risks a planned data processing operation creates for the people affected and how you get those risks under control. The legal basis is Article 35 GDPR. For AI tools, a DPIA is in most cases not optional. It is mandatory.
The problem: most guides stop at “you need a DPIA” and leave you alone with the blank document. This post walks through the process once, end to end, from checking whether you are obligated to keeping the document current. By the end you will know what to do and in what order.
When is a DPIA mandatory for AI tools?
Article 35(1) GDPR requires a DPIA when a processing operation is likely to result in a high risk to the rights and freedoms of natural persons. For AI tools that is regularly the case, for three reasons.
First: the use of new technologies. Article 35 names it explicitly as a criterion. Generative AI falls under it.
Second: the nature of the data. If you let an AI tool process client data, HR data, or health data, you are processing data where a mistake can seriously affect the people behind it. For professions bound by secrecy obligations, Section 203 of the German Criminal Code adds its own risk dimension.
Third: supervisory practice. The Bavarian data protection authority (BayLDA) lists AI systems on its mandatory list for DPIAs. If you are based in Bavaria and point an AI tool at personal data, answer the question “do I need a DPIA?” with yes and put your energy into doing it well.
In short: if your AI tool processes personal data and you work in a regulated environment, plan for the DPIA. Checking whether you might be exempt often costs more time than the DPIA itself.
Step 1: Describe the processing systematically
Article 35(7)(a) requires a systematic description of the planned processing operations. This is the foundation for everything else, and it is where the quality of the whole document is decided.
Answer concretely:
- Which tool, which version, which plan? “ChatGPT” is not a description. “ChatGPT Team with training use disabled” or “Azure OpenAI, GPT-4o, region Germany West Central” is one.
- Which data goes in? Client correspondence, contract drafts, HR files, accounting data. Name the categories and the groups of people affected.
- Who uses the tool? All employees or a pilot group? The DPIA has to reflect the actual scope, not the maximum conceivable one.
- Where does the data flow? In which region is it processed, who is the processor, which subprocessors are involved? For a case like Azure OpenAI, these are documented, verifiable facts. For some tools this exact question cannot be answered cleanly, and that is itself a finding for the risk assessment.
The more concrete this step, the easier steps 3 and 4 become. Vague description, vague risk assessment, worthless document.
Step 2: Justify necessity and proportionality
Article 35(7)(b) requires an assessment of whether the processing is necessary and proportionate for its purpose. Two questions help:
Why this tool and not a more data-sparing one? If a solution with EU data residency and contractually excluded training use exists, why are you not using it? If you are using it, write exactly that down. It is the strongest line in the entire document.
Does all of the data need to go in? If the tool is supposed to summarize emails, does it need access to the entire document archive? Every data category you keep away from the tool shrinks the risk and shortens the DPIA.
Also document the legal basis for the processing, typically Article 6(1)(b) or (f) GDPR depending on the purpose. One legal basis per processing purpose, not one blanket line for everything.
Step 3: Assess the risks to the people affected
Article 35(7)(c) is the core of the DPIA. What can happen to the people whose data is processed? For AI tools I see four recurring risk categories in practice:
- Uncontrolled data leakage. Employees paste data into prompts that should never have left the company. This is the most common real-world risk, and it is organizational, not technical.
- Processing outside the EU or for training purposes. Depends on the tool and the plan. This is where the clean description from step 1 pays off.
- Access through overly broad permissions. Relevant for integrated assistants like Copilot that see everything the user has access to. I covered those risks in detail in the Copilot DPIA post.
- Faulty outputs with consequences for real people. If AI outputs flow unchecked into notices, letters, or decisions, a hallucination error hits an actual person.
Rate each risk by likelihood and severity, each on a scale a reviewer can follow (a four-step scale of low, medium, high, very high works). What matters is not the perfect matrix but that a supervisory authority can retrace how you got to your conclusion.
Step 4: Define the mitigation measures
Article 35(7)(d) requires the measures you will take to address the risks. The rule is simple: every risk from step 3 needs at least one documented countermeasure.
Typical measures for AI tools:
- Tool configuration: disable training use, choose an EU region, set retention periods. Whatever is configurable gets configured and documented.
- Contractual safeguards: put the data processing agreement in place and on file, record the subprocessors, define a process for reviewing changes.
- Access and permission concept: who may use the tool, with which data, with which rights.
- Use policy: rules for which data may go into prompts and which never may. Without a policy, every technical measure stays patchwork. What belongs in one is covered in the AI use policy post.
- Training: employees have to know the rules, otherwise they exist only on paper.
After the measures, assess each risk again: what remains as residual risk? This second assessment is the part templates most often skip, and it is exactly the part that turns the DPIA into a basis for decisions.
Step 5: Consult the data protection officer
Article 35(2) GDPR: the advice of the data protection officer must be sought, where one has been designated. That is an obligation, not an optional review.
Document the date of the consultation, the DPO’s opinion, and how you handled it. Even a “no objections” belongs in the document in writing. If you work with an external DPO, send them the description from step 1 in advance. They can only assess what they know.
Step 6: Document the result and answer the residual risk question
Now you assemble everything into one document: description, necessity, risk assessment, measures, residual risk, DPO opinion, date, and the people responsible.
Then comes the decisive fork: if a high residual risk remains despite all measures, you must consult the supervisory authority before the processing starts (Article 36 GDPR; in Bavaria that is the BayLDA). In practice this is rarely necessary if the measures from step 4 do their job. But the question has to be answered in the document, not left open.
You do not file the DPIA anywhere. It has to exist and be ready to show on request, for example during an audit.
Step 7: Update it when something changes
Article 35(11) requires a review when the risk of the processing changes. With AI tools, something changes constantly: new model versions, new features, new subprocessors, expanded user groups.
What works in practice is a double trigger: a fixed annual review as the minimum, plus an event-based one for relevant changes. Define who in your company notices and evaluates changes on the vendor side. A DPIA from two years ago that describes a tool which has long since changed is almost as bad in an audit as no DPIA at all.
The three most common mistakes
Treating the vendor’s template as the finished DPIA. Microsoft, OpenAI, and others provide documentation describing what the vendor does. Your DPIA has to describe what you do: your data, your users, your risks, your measures.
Writing the DPIA after the rollout. Article 35 says “prior to the processing.” A DPIA written afterwards is better than none, but then it documents a done deal instead of serving as a checkpoint. If the tool is already live: do it anyway, and date it honestly.
Not documenting the process. Listing risks and measures is not enough. Show how you reached your assessment: which sources, which criteria, who was involved. That is exactly what separates a defensible DPIA from busywork.
Next step
If you want to get started now: I have turned the obligation check and all the required components into a free DPIA checklist. Use it to work through the steps above in order and see immediately what you are still missing.
Jose Lugo is a CISSP-certified AI compliance consultant. He prepares data protection impact assessments for regulated companies in Germany.