A Data Protection Impact Assessment — DPIA, or DSFA (Datenschutz-Folgenabschätzung) in German terminology — is legally required for any processing that is likely to result in a high risk to the rights and freedoms of individuals. Under Article 35 GDPR, that captures a large share of enterprise AI: systematic and extensive profiling with significant effects, large-scale processing of special-category data, and the use of new technologies. AI systems that touch personal data tend to land in at least one of those buckets.
Most enterprise teams treat the DPIA as a compliance hurdle — something legal throws over the wall that delays the project by weeks. That framing is wrong and expensive. A well-run DPIA is the fastest way to surface risks, align stakeholders, and build documentation you need anyway — for the GDPR today and, where it applies, for the EU AI Act's fundamental rights impact assessment from 2 August 2026 onward.
When a DPIA is required for AI
Article 35(1) GDPR sets the general trigger: where processing — in particular using new technologies, and given its nature, scope, context and purposes — is likely to result in a high risk to the rights and freedoms of natural persons, a DPIA must be carried out before processing begins. Article 35(3) names three cases where it is mandatory by default: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based; large-scale processing of special categories of data (Article 9) or criminal-conviction data (Article 10); and systematic large-scale monitoring of publicly accessible areas.
German supervisory authorities have gone further. The Datenschutzkonferenz (DSK) — the body of federal and state authorities — has published a so-called Muss-Liste, a list of processing operations for the non-public sector for which a DPIA is always required under Article 35(4). Several activities on that list map directly onto common AI use cases: scoring and creditworthiness assessment, processing for behavioural analysis, and the large-scale evaluation of employee data. If your system does any of those things, the question is settled before you start.
The practical rule: if your AI system processes personal data and does anything beyond trivial automation, assume a DPIA is required and check the relevant authority's list to confirm. The cost of running one when it turns out not to be strictly required is a few hours. The cost of skipping one when it was required is an enforcement action — supervisory authorities can fine a failure to conduct a DPIA under Article 83(4) GDPR, with a ceiling of up to €10 million or 2% of worldwide annual turnover, whichever is higher.
The DPIA as a readiness accelerator
Here is the reframe that changes how teams approach this exercise: the DPIA is not a compliance document. It is a readiness diagnostic.
A properly structured DPIA forces you to answer questions you need answered regardless. What data does the system process, and where does it come from? What decisions does it influence or make? Who is affected by those decisions, and what are the consequences when they go wrong? What safeguards prevent errors, bias, or misuse? Who holds human-oversight authority, and how do they exercise it? What is the fallback when the model produces a wrong output?
These are not legal questions. They are engineering and operational questions. If you cannot answer them, you are not ready to deploy — whether or not a DPIA is formally required. That is why we run the DPIA during Discovery, not after development. Done early, it surfaces issues while they are still cheap to fix; done late, the same findings demand architectural rework.
Step-by-step: running a DPIA for AI
Step 1 — Define the scope. Describe the system, its purpose, the data it processes, and the processing operations, and be specific about each. Spell out what the system does and what type of AI it is — classification, generation, prediction. Name the personal data that enters it, including source, categories, and volume, and the outputs it produces, whether predictions, recommendations, decisions, or content. Note the processing operations involved — training, inference, fine-tuning, retrieval — and the business outcome the system serves, then state how many individuals are affected and how often. This is Article 35(7)(a) territory: the systematic description of processing and purposes. Do not write a novel; one page suffices. The goal is clarity, not comprehensiveness.
Step 2 — Assess necessity and proportionality. This is where you justify that AI is the right approach and that you process only what is needed — the explicit requirement of Article 35(7)(b). Ask whether AI processing is genuinely necessary for the stated purpose, or whether the same outcome is reachable by less invasive means. Confirm that you are processing only the personal data required and that data minimisation is built into the architecture rather than bolted on. Establish your legal basis: legitimate interest under Article 6(1)(f) is common for enterprise AI but requires a documented balancing test, while consent under Article 6(1)(a) is rare and usually impractical at deployment scale. Finally, confirm purpose limitation — that the system is used only for the purpose described, with safeguards against scope creep. This is where compliance-by-design architecture pays off: if minimisation was a design constraint from the start, this section writes itself.
Step 3 — Identify and assess risks. Map the risks to individuals' rights and freedoms. For AI systems, the recurring categories are accuracy risk, where incorrect predictions or classifications harm affected individuals; bias and discrimination, where the system produces systematically unfair outcomes for particular groups; transparency risk, where individuals do not know they are subject to AI processing or cannot understand how decisions are reached; autonomy risk, where the system constrains choices or makes calls that should involve human judgement; security risk, where the model introduces new attack surfaces such as model inversion, prompt injection, or data leakage; and function creep, where the system is quietly repurposed beyond its original intent. For each, assess likelihood and severity on a simple high/medium/low matrix. The point is not statistical precision but identification — you cannot mitigate a risk you have not named.
Step 4 — Define mitigation measures. For each identified risk, set out concrete safeguards rather than aspirations. Accuracy is addressed through validation testing, performance thresholds, human review of edge cases, and ongoing monitoring with drift detection. Bias is addressed through testing across affected groups, fairness metrics, and regular audits. Transparency is addressed through clear disclosure to affected individuals, explainability mechanisms, and the data subject's right not to be subject to a solely automated decision under Article 22, including the right to obtain human intervention. Autonomy is addressed through human-in-the-loop design, override mechanisms, and escalation paths; security through EU-resident infrastructure, encryption in transit and at rest, access controls, and audit logging; function creep through technical controls that limit use to the stated purpose and contractual restrictions on providers. Document what you actually do, not what you intend to do — the DPIA is an accountability record and must reflect the real state of your controls.
Step 5 — Consult your DSB and stakeholders. Article 35(2) GDPR requires the controller to seek the advice of the data protection officer (Datenschutzbeauftragter), where one is designated, when carrying out a DPIA. This is not optional. Beyond the DSB, involve the technical team building or operating the system, the business owner who defines the use case and accepts the residual risk, legal counsel for regulatory interpretation, and the departments whose workflows or staff are affected. In our experience the consultation meeting is the highest-value hour of the whole exercise — it surfaces assumptions no one had questioned, risks no single stakeholder would have spotted alone, and an alignment that would otherwise take months to reach.
Step 6 — Document, sign off, and maintain. The final document should carry the system description and processing overview, the necessity-and-proportionality assessment, the risk matrix, the mitigation measures and their implementation status, the DSB's opinion, and sign-off from the responsible business owner, together with a review schedule. The GDPR makes the review explicit: under Article 35(11), the controller must reassess whether processing still matches the DPIA at least when the risk represented by the processing changes. For AI systems that means a standing trigger — new data sources, model updates, or expanded use cases all reopen the assessment. Build that into your change-management process rather than treating the DPIA as a one-time artefact.
DPIA meets the EU AI Act
If your system is a high-risk AI system under the EU AI Act, a second assessment may apply. Article 27 introduces the fundamental rights impact assessment (FRIA), which deployers must complete before putting certain high-risk systems into service — and its obligations begin on 2 August 2026. The FRIA does not apply to every deployer: it is aimed at public bodies, private entities delivering public services, and deployers of specific Annex III systems such as creditworthiness scoring and risk assessment and pricing in life and health insurance.
The two assessments are related but not identical. The DPIA protects personal data; the FRIA has a broader remit, evaluating effects on fundamental rights such as non-discrimination and human dignity, and it can apply even where the data-protection trigger is weaker. The regulation builds in the overlap deliberately. Under Article 27(4), where an obligation of the FRIA is already met through a DPIA conducted under Article 35 GDPR, the FRIA complements that DPIA rather than duplicating it. In practice that means you scope both together — a single, well-structured assessment that satisfies the GDPR and feeds directly into the FRIA, with the AI-Act-specific elements (deployment context, affected groups, human-oversight detail, complaint mechanisms) layered on top. For how the AI Act's wider requirements interact with the GDPR, see the EU AI Act Compliance Guide.
Common mistakes to avoid
Treating the DPIA as a one-off. Article 35(11) ties the review to changes in risk, and AI systems change constantly — data shifts, models are retrained, use cases expand. A DPIA frozen at launch is out of date within a quarter.
Running it after development. By then mitigation requires architectural change. Run it during Discovery, when the cost of a finding is a design decision rather than a rebuild.
Making it too abstract. "We will implement appropriate safeguards" is worthless. Name the safeguard, describe how it works, and state who is responsible for it.
Skipping the DSB consultation. Article 35(2) makes it a legal duty where a DSB is designated. Document the consultation and the opinion you received.
Doing it alone. A DPIA written by one person in isolation misses the risks that only show up at the seams between teams. It is a cross-functional exercise by design.
Get it done, not perfect
The DPIA is not a research project. It is a structured conversation that produces a document — and for a typical, well-scoped AI workflow it is a matter of focused sessions, not weeks of legal drafting. The discipline is in asking the right questions of the right people once, early, and writing down the honest answers.
At Remote Native we facilitate that exercise as part of the engagement: a DPIA template tailored to your specific workflow, the right stakeholders in the room, and documentation that holds up under both the GDPR and the EU AI Act.
A Fit Call scopes your DPIA and maps the assessment to the right legal triggers — before a missing assessment becomes an enforcement problem.
References: Regulation (EU) 2016/679 (GDPR), Article 35, https://gdpr-info.eu/art-35-gdpr/; Regulation (EU) 2024/1689 (EU AI Act), Article 27, https://artificialintelligenceact.eu/article/27/; Datenschutzkonferenz, "Liste von Verarbeitungsvorgängen nach Art. 35 Abs. 4 DS-GVO (Muss-Liste, nicht-öffentlicher Bereich)," https://www.bfdi.bund.de/DE/Fachthemen/Inhalte/Technik/Datenschutz-Folgenabschaetzungen.html; IAPP, "EU AI Act: Mapping the Interplays with the GDPR," https://iapp.org/resources/article/mapping-interplays-gdpr-eu-ai-act.