A Data Protection Impact Assessment — DPIA, or DSFA (Datenschutz-Folgenabschätzung) under German terminology — is legally required for any processing that is likely to result in a high risk to individuals' rights and freedoms. Under DSGVO Article 35, that includes most AI systems that process personal data: automated decision-making, profiling, large-scale processing, and systematic monitoring.

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 the documentation you need for both DSGVO and the EU AI Act in a single pass.

When a DPIA is required for AI

Under DSGVO, a DPIA is mandatory when processing is likely to result in high risk. For AI systems, this is triggered by:

  • Automated decision-making with legal or significant effects on individuals (Article 22 DSGVO)
  • Systematic evaluation of personal aspects (profiling) — scoring, prediction of performance, behaviour, interests
  • Large-scale processing of special categories of data or criminal conviction data
  • Systematic monitoring of publicly accessible areas
  • Use of new technologies — AI systems generally qualify as "new technologies" under the regulation

The German supervisory authorities (Datenschutzaufsichtsbehörden) have published lists of processing activities that require a DPIA. AI-based processing appears on virtually every one of them.

The practical rule: If your AI system processes personal data and does anything beyond trivial automation, assume a DPIA is required. The cost of running one when it is technically not required is negligible. The cost of not running one when it was required is an enforcement action.

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 that you need answered anyway:

  • What data does the AI system process, and where does it come from?
  • What decisions does the system influence or make?
  • Who is affected by those decisions, and what are the consequences?
  • What safeguards are in place to prevent errors, bias, or misuse?
  • Who has human oversight authority, and how do they exercise it?
  • What happens when the system 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 — regardless of whether a DPIA is legally required.

In our engagements, we run the DPIA during Discovery, not after development. This surfaces issues early — before they become architectural rework.

Step-by-step: running a DPIA for AI

Step 1: Define the scope

Describe the AI system, its purpose, the data it processes, and the processing operations. Be specific:

  • System description: What does it do? What type of AI (classification, generation, prediction)?
  • Data inputs: What personal data enters the system? Source, categories, volume.
  • Data outputs: What does the system produce? Predictions, recommendations, decisions, content?
  • Processing operations: Training, inference, fine-tuning, retrieval?
  • Intended purpose: What business outcome does the system serve?
  • Scope of processing: How many individuals are affected? How frequently?

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 why AI is the right approach and that you are processing only what is needed:

  • Necessity: Is AI processing necessary for the stated purpose? Could you achieve the same outcome with less invasive means?
  • Proportionality: Are you processing only the personal data required? Is data minimisation built into the architecture?
  • Legal basis: What is your legal basis under DSGVO? Legitimate interest (Article 6(1)(f)) is common for enterprise AI, but it requires a balancing test. Consent (Article 6(1)(a)) is rare for enterprise deployments.
  • Purpose limitation: Is the system used only for the purpose described? Have you safeguarded against scope creep?

This step is where compliance-by-design architecture pays off. If your system is built with data minimisation 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 typical risk categories are:

  • Accuracy risks: The system makes incorrect predictions or classifications. What is the impact on affected individuals?
  • Bias and discrimination: The system produces systematically unfair outcomes for certain groups. Have you tested for this?
  • Transparency risks: Individuals do not know they are subject to AI processing, or cannot understand how decisions are made.
  • Autonomy risks: The system constrains individuals' choices or makes decisions that should involve human judgement.
  • Data security risks: The AI system creates new attack surfaces (model inversion, prompt injection, data leakage).
  • Function creep: The system is repurposed for uses beyond the original intent.

For each risk, assess likelihood and severity. Use a simple matrix — high/medium/low for each dimension. The goal is not precision but identification: you need to know what the risks are before you can mitigate them.

Step 4: Define mitigation measures

For each identified risk, define concrete safeguards:

  • Accuracy: Validation testing, performance thresholds, human review for edge cases, ongoing monitoring with drift detection.
  • Bias: Testing across demographic groups, fairness metrics, regular audits.
  • Transparency: Clear disclosures to affected individuals, explainability mechanisms, right to human review under Article 22(3).
  • Autonomy: Human-in-the-loop design, override mechanisms, escalation paths.
  • Security: EU-resident infrastructure, encryption at rest and in transit, access controls, audit logging.
  • Function creep: Technical controls limiting use to stated purpose, contractual restrictions with providers.

Document what you are doing, not what you aspire to do. The DPIA is an accountability document. It should reflect the actual state of your safeguards.

Step 5: Consult your DSB and stakeholders

DSGVO Article 35(2) requires you to seek the advice of your DSB (Datenschutzbeauftragter) when conducting a DPIA. This is not optional. It is a legal requirement.

Beyond the DSB, involve:

  • The technical team building or operating the AI system
  • The business owner who defines the use case and accepts the risk
  • Legal counsel for regulatory interpretation
  • Affected departments whose workflows or staff are impacted

In our experience, the consultation meeting is the highest-value part of the DPIA. It surfaces assumptions that no one had questioned, risks that no single stakeholder would have identified, and alignment that would otherwise take months.

Step 6: Document, sign off, and maintain

The final DPIA document should include:

  • System description and processing overview
  • Necessity and proportionality assessment
  • Risk assessment matrix
  • Mitigation measures and their implementation status
  • DSB opinion
  • Sign-off from the responsible business owner
  • Review schedule (we recommend quarterly for AI systems in production)

This is a living document. When the system changes — new data sources, model updates, expanded use cases — the DPIA must be updated. Build this into your change management process.

DPIA meets EU AI Act

For high-risk AI systems under the EU AI Act, the DPIA and the AI Act's fundamental rights impact assessment overlap significantly. We combine both into a single assessment that covers:

  • DSGVO data protection risks and safeguards
  • EU AI Act risk management requirements
  • Fundamental rights implications (non-discrimination, privacy, human dignity)
  • Technical documentation requirements that satisfy both frameworks

This integrated approach eliminates duplication and produces a single source of truth for compliance. For the full picture of how the AI Act's requirements interact with DSGVO, see the EU AI Act Compliance Guide.

Common mistakes to avoid

Treating the DPIA as a one-off. It is not. AI systems evolve — data changes, models are updated, use cases expand. The DPIA must evolve with them.

Running the DPIA after development. By then, mitigation measures require architectural changes. Run it during Discovery.

Making it too abstract. A DPIA that says "we will implement appropriate safeguards" is useless. Name the safeguards. Describe how they work. State who is responsible.

Skipping the DSB consultation. This is a legal requirement, not a suggestion. Document the consultation and the DSB's opinion.

Doing it alone. A DPIA written by one person in isolation misses risks. 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. For a typical AI workflow, the exercise takes 4–8 hours of focused work across 2–3 sessions — not weeks.

At Remote Native, every engagement includes a pre-built DPIA template tailored to the specific AI workflow. We facilitate the sessions, involve the right stakeholders, and produce documentation that satisfies both DSGVO and EU AI Act requirements.

If you need to run a DPIA for an AI initiative and want a structured, efficient approach, book a Fit Call. We will scope the assessment and outline the process — in 30 minutes.

Related: