A Data Protection Impact Assessment (DPIA) under Article 35 GDPR is mandatory for most business AI deployments. This checklist walks you through the process in 8 practical steps — with concrete examples for companies operating in Germany, including references to BayLDA (Bavaria's data protection authority) requirements.
Last updated: March 2026
Before you start a DPIA, you need to determine whether one is legally required. Article 35(1) GDPR mandates a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons." For AI tools, that threshold is met in nearly every business scenario.
Article 35(3) GDPR lists three situations that always require a DPIA: systematic and extensive automated evaluation of personal aspects (profiling), large-scale processing of special categories of data, and systematic monitoring of publicly accessible areas. AI systems frequently hit at least one of these.
Beyond the GDPR text itself, each EU supervisory authority publishes a blacklist of processing activities that always require a DPIA. In Bavaria, the BayLDA (Bayerisches Landesamt für Datenschutzaufsicht, based in Ansbach) maintains this list under Article 35(4) GDPR. Check your specific AI use case against it.
Real example: Your tax advisory firm uses ChatGPT for client tax research. Even if the queries seem generic, the moment an employee types a client name, tax ID, or case details into the prompt, you are processing personal data with a new technology. The BayLDA treats new technology adoption as a risk factor that triggers a DPIA — regardless of the query content.
Article 35(7)(a) GDPR requires a "systematic description of the envisaged processing operations and the purposes of the processing." With AI, this is harder than with traditional IT systems because the data flow is often opaque. You need to trace exactly where personal data goes and what happens to it at each stage.
Document the specifics: What personal data enters the AI model? Are prompts stored, and for how long? Is there a data transfer to third countries? Does the provider use your inputs for model training? Where are the outputs stored, and who has access? Create a data flow diagram that traces data from user input through the AI model to the final output.
Practical tip: Map the data flow for one typical use case. Example: "Employee enters client name + tax ID into ChatGPT Free → Data transfers to OpenAI servers in the US → Prompt stored for 30 days → Data may be used for model training." Just writing this out makes the GDPR risks visible. Do it for every AI tool your team uses — you will likely find tools you did not even know were processing personal data.
Article 35(7)(b) GDPR requires an assessment of necessity and proportionality. You need to answer three questions: Is AI processing genuinely necessary for this purpose? Are there less intrusive alternatives? Does the benefit justify the risk to data subjects?
Identify your legal basis. For most business AI deployments, Article 6(1)(f) GDPR (legitimate interest) applies. If you are processing special categories of personal data — health records, religious beliefs, trade union membership — you need a legal basis under Article 9 GDPR, which is much more restrictive. Many firms overlook this: financial data itself may not be "special category," but the combination of financial data with other client information can create a sensitive profile.
Real example: A law firm wants to use AI for contract review. Necessity is clear — manual review takes hours per contract. But is it proportionate to send the entire contract, complete with client names, addresses, and financial terms, to the AI? No. The proportionate approach: PII redaction before AI processing. Personal data is automatically stripped from the document before it reaches the model. Same result, drastically lower risk. That is what proportionality looks like in practice.
Article 35(7)(c) GDPR requires an assessment of "the risks to the rights and freedoms of data subjects." With AI systems, these risks go well beyond traditional IT security concerns. You need to evaluate both the likelihood of each risk occurring and the severity of the potential harm.
AI-specific risks you must assess: Third-country data transfers — are you sending client data to servers in the US? Training data usage — does the provider use your inputs to train their models? Hallucinations — does the AI generate false information that could lead to wrong decisions? Prompt injection — can an attacker manipulate the AI to reveal protected data? Lack of explainability — can you trace how the AI reached a particular output?
Practical tip: Use a risk matrix with "likelihood" and "severity" axes. A tax advisor entering client data into ChatGPT Free has high likelihood (data goes to US servers with every prompt) and high severity (tax IDs, financial records, personal details). That combination gives you a "high risk" rating — which is exactly what you need mitigation measures for in Step 5. Do not skip this structured assessment. The BayLDA expects to see a documented risk evaluation, not just a list of concerns.
Article 35(7)(d) GDPR requires you to define "the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data." These are your technical and organizational measures (TOMs) under Article 32 GDPR — tailored to the specific risks of AI processing.
Proven mitigation measures for AI deployments: EU hosting — run AI models on EU servers (e.g., Azure Germany West Central) instead of sending data to US providers. PII redaction — automatically strip personal data before it reaches the AI model. Data Processing Agreement (DPA/AVV) — sign one with your AI provider under Article 28 GDPR. Access controls — restrict AI access to authorized personnel. Audit trail — log all interactions with the AI. Staff training — train employees on GDPR-compliant AI usage. Human-in-the-loop — require human review for AI outputs that affect individuals.
Real example: A financial advisory firm in Bavaria wants AI-powered document search. Instead of ChatGPT, they deploy an EU-hosted solution with PII redaction, running in their own Azure environment in Frankfurt. Staff complete a 90-minute compliance training. All queries are logged with full audit trails. The DPA with the AI provider is signed and filed. Residual risk drops from "high" to "low" — and the DPIA documents that reduction with evidence.
The DPIA must be fully documented. A casual internal note will not suffice. Your DPIA report should cover all of Steps 1 through 5: the threshold assessment, the processing description, the necessity and proportionality evaluation, the risk assessment, and the mitigation measures. Record who participated in the DPIA and when each step was completed.
Article 35(11) GDPR requires you to review the DPIA "at least when there is a change in the risk represented by processing operations." With AI, changes happen constantly: model updates, new features, different usage patterns, expanded use cases. Schedule at minimum an annual review — and trigger an ad-hoc review whenever the AI system or its context changes significantly.
Practical tip: Maintain a change log. When OpenAI updates its model from GPT-4 to GPT-5, the processing has changed — check whether your DPIA still holds. The same applies when your team starts using the AI for new tasks, like moving from general research to drafting client correspondence. Document each review with the date, findings, and any actions taken. This is what the BayLDA will look for in an audit.
Article 35(2) GDPR is clear: "The controller shall seek the advice of the data protection officer, where designated, when carrying out a data protection impact assessment." This is not a recommendation — it is a legal obligation. If your organization has a DPO (Datenschutzbeauftragter), they must be involved in the DPIA process.
Do not wait until the DPIA is finished to get the DPO's signature. Involve them from the start — ideally at Step 1 when you assess whether a DPIA is needed. Document their opinion, their specific recommendations, and how you addressed each one. If you deviate from a DPO recommendation, document the reasoning.
Practical tip: Many smaller firms in Germany do not have a DPO — even though German law (Section 38 BDSG) requires one once 20 or more people are regularly involved in automated processing of personal data. If you need a DPO but do not have one, fix that before starting the DPIA. A DPIA conducted without the required DPO consultation is a procedural deficiency that the BayLDA will flag during an audit.
If your DPIA concludes that high residual risk remains despite all mitigation measures, Article 36 GDPR requires you to consult the supervisory authority before starting the processing. In Bavaria, this is the BayLDA (Bayerisches Landesamt für Datenschutzaufsicht) in Ansbach, which oversees all non-public bodies.
The prior consultation is not an approval process. The BayLDA reviews your DPIA and issues an opinion within 8 weeks (extendable to 14 weeks). They can provide written recommendations or prohibit the processing. In practice, prior consultation is rare — because most organizations can reduce residual risk to an acceptable level through appropriate measures. That is the entire point of Steps 3 through 5.
Real example: You deploy AI for automated credit application scoring — a processing activity with direct impact on data subjects' rights. Despite EU hosting and access controls, the automated decision-making creates a high residual risk. Consulting the BayLDA before going live would be the correct step. For most AI deployments in tax advisory, law firms, and financial consulting, however, the right set of TOMs brings residual risk down to an acceptable level without needing prior consultation.
Our free AI Check shows you in 2 minutes where your AI usage is GDPR-compliant — and where it is not.
Jose Lugo is a CISSP-certified AI security consultant with 12 years of experience protecting sensitive data in high-security environments. He advises businesses in Germany on GDPR-compliant AI deployment — including conducting Data Protection Impact Assessments for AI systems.