DPIA for High-Risk AI: Art.35 GDPR + Art.9 EU AI Act Risk Management Developer Guide 2026

Post #2 in the sota.io EU AI Act + GDPR Intersection Series

If you build or deploy a high-risk AI system under the EU AI Act, you almost certainly also owe your users a Data Protection Impact Assessment (DPIA) under GDPR Art.35. Two separate legal obligations, two separate regulatory regimes — but they share a large evidence base. Done right, you run one combined exercise and satisfy both.

This guide shows you exactly how.

The Double Obligation Problem

A high-risk AI system that processes personal data triggers requirements from two parallel frameworks:

Most developers treat these as separate workstreams. That is expensive, slow, and produces duplicate documentation. A better approach: run one integrated assessment, map the outputs to both frameworks, and maintain a single evidence repository.

When Does GDPR Art.35 Mandate a DPIA?

GDPR Art.35 requires a DPIA before starting processing that is "likely to result in a high risk to the rights and freedoms of natural persons." The European Data Protection Board (EDPB) has identified nine criteria that raise this threshold — two or more criteria present generally mandate a DPIA.

EDPB's nine criteria (at least two trigger mandatory DPIA):

1. Evaluation or scoring — profiling, credit scoring, health prediction, behavioural analysis
2. Automated decision-making with legal or significant effects — covered also by GDPR Art.22
3. Systematic monitoring — tracking in publicly accessible areas, employee surveillance
4. Sensitive data or special categories — health data, biometric identifiers, genetic data per GDPR Art.9
5. Large-scale processing — volume, geographic spread, number of data subjects
6. Matching or combining datasets — where data subjects would not reasonably expect the combination
7. Vulnerable data subjects — children, employees, patients, asylum seekers
8. Innovative use or applying new technical solutions — AI/ML explicitly triggers this criterion
9. Processing that prevents subjects from exercising rights or using services

For high-risk AI systems under the EU AI Act: every Annex III system that processes personal data will likely satisfy at least two criteria (automated decision-making + innovative technology, at minimum). A DPIA under Art.35 is effectively mandatory.

EU AI Act Art.9: Risk Management System for High-Risk AI

Art.9 of the EU AI Act requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system throughout the system's entire lifecycle.

Core Art.9 requirements:

1. Identify and analyse known and foreseeable risks associated with the high-risk AI system when used as intended and under conditions of reasonably foreseeable misuse
2. Estimate and evaluate risks that may emerge based on post-market data
3. Evaluate risks after application of risk management measures to determine residual risk
4. Adopt suitable risk management measures in accordance with Art.9(4), giving particular consideration to risks to vulnerable groups

Art.9(4) prioritises risk mitigation measures in this order:

• Design and development measures that eliminate or reduce risks as far as possible
• Where appropriate, mitigation and control measures for risks that cannot be eliminated
• Provision of adequate information pursuant to Art.13 obligations

What triggers Art.9 obligations: being a provider (you placed the system on the market or put it into service) of any system listed in EU AI Act Annex III. Deployers have separate but lighter obligations under Art.26.

The Overlap Matrix: What You Can Reuse

Running a DPIA and an Art.9 risk assessment covers overlapping ground. Map the evidence once:

Key differences — do not conflate:

• GDPR Art.35 DPIA is initiated by the controller (the entity that determines purpose and means of processing). EU AI Act Art.9 obligations rest with the provider (entity that placed system on market). Same company usually, but different legal personas under each regulation.
• GDPR Art.35 focusses on risks to rights and freedoms of individuals. Art.9 is broader — it covers risks to health, safety, fundamental rights, and society.
• GDPR Art.36 prior consultation applies when the residual risk after mitigation remains high under Art.35(1). There is no equivalent blanket prior-approval obligation in the EU AI Act for most Annex III systems (conformity assessment per Art.43 is the parallel mechanism).

Step-by-Step: Combined DPIA + AI Risk Assessment

Phase 1: Scoping (Day 1–3)

DPIA side (Art.35):

• Map all personal data inputs, outputs, intermediate processing steps
• Identify data subjects and their relationships to the system
• Document legal basis for processing (Art.6, or Art.9 for special categories)
• Appoint DPO and involve them from the start (GDPR Art.37–39)

Art.9 side:

• Identify the applicable Annex III category
• Document intended purpose, intended users, intended use environment
• List all user groups including vulnerable populations
• Define "reasonably foreseeable misuse" scenarios

Shared deliverable: a combined system description document covering all of the above.

Phase 2: Risk Identification (Day 3–10)

Run a structured brainstorming session with engineering, product, legal, and DPO. Cover both dimensions:

GDPR angles:

• Unauthorised access or disclosure
• Inaccurate decisions (Art.22 right to not be subject to solely automated decisions)
• Inability to exercise erasure rights (Art.17)
• Purpose creep / secondary use without legal basis
• Cross-border transfer risks (standard contractual clauses per Art.46)

AI Act Art.9 angles:

• Bias and discrimination risks (gender, race, disability — relevant for credit, HR, public services)
• Safety risks (physical, psychological, financial harm)
• Systemic effects if deployed at scale
• Adversarial manipulation (robustness per Art.15)
• Cascading failures in multi-agent systems

Output: a unified risk register. Each risk entry should carry: description, affected parties, likelihood (1–5), severity (1–5), risk score (L×S), applicable regulation(s).

Phase 3: Mitigation Measures (Day 10–20)

For each identified risk, document the mitigation controls. Cross-reference to both frameworks:

Phase 4: Residual Risk Evaluation and Art.36 Decision (Day 20–25)

After applying mitigation measures, re-score each risk. The residual risk assessment determines two things:

1. Under GDPR Art.35(10) / Art.36: if residual risk remains high, you must consult your supervisory authority before processing begins. "High residual risk" typically means a risk score ≥ 12 (severity 4+ × likelihood 3+) after mitigation. Your DPO signs off on whether consultation is required.

2. Under EU AI Act Art.9(9): you must document residual risks in the technical documentation and include information about them in instructions for use.

CRITICAL distinction from the GDPR facts database:

• Art.35 = the DPIA itself
• Art.36 = prior consultation with the supervisory authority — only triggered when the DPIA concludes high residual risk remains
• Do not conflate these two articles

Phase 5: Documentation and Sign-off (Day 25–30)

The combined assessment produces three documents that satisfy both frameworks:

Document 1: Risk Assessment Report (satisfies DPIA documentation requirement under Art.35(7) and Art.9 risk documentation under EU AI Act)

• Systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller
• Assessment of the necessity and proportionality of the processing operations in relation to the purposes
• Assessment of the risks to the rights and freedoms of data subjects
• Measures envisaged to address the risks

Document 2: Technical Controls Register (satisfies Art.32 GDPR and Art.9/Art.15 EU AI Act)

• Technical and organisational measures for each identified risk
• Responsibility assignment (who owns each control)
• Review schedule

Document 3: AI Act Technical Documentation Annex (satisfies Art.11 and Annex IV EU AI Act)

• References the risk assessment as required component
• Documents residual risks per Art.9(9)
• Links to post-market monitoring plan per Art.72

Art.36 Prior Consultation: Handling High Residual Risk

Art.36 applies when your DPIA under Art.35 concludes that processing would result in high risk if the controller does not take measures to mitigate it. In practice, this happens when:

• You cannot reduce a risk below "high" through technical or organisational measures
• The data subjects affected include vulnerable groups
• The processing involves special categories of data at large scale
• The automated decision-making has legal or similarly significant effects with limited human oversight

The Art.36 process:

1. DPIA is completed and identifies high residual risk
2. DPO reviews and confirms Art.36 consultation is required
3. You submit the DPIA to your lead supervisory authority (LSA) — the DPA in the EU member state of your establishment
4. The DPA has 8 weeks to respond (extendable by 6 weeks for complex cases — Art.36(2))
5. You may not start processing until consultation is complete and the DPA has either approved or not objected

EU AI Act parallel: For the highest-risk Annex III systems requiring conformity assessment by a notified body (Art.43(1)), there is a comparable ex-ante checkpoint. The two timelines can be run in parallel, but the EU AI Act does not grant an automatic "processing start" after the notified body issues a certificate — the GDPR Art.36 DPA consultation is independent.

Developer Checklist: GDPR Art.35 + EU AI Act Art.9

Use this before your first production deployment:

DPIA triggers (Art.35):

• System processes personal data AND is a high-risk AI system (Annex III) — DPIA mandatory
• Two or more EDPB criteria are present — DPIA mandatory regardless of AI Act classification
• DPO involved from the outset (if DPO required under Art.37)

Combined assessment deliverables:

• Unified system description (purpose, data flows, data subjects, use environment)
• Risk register covering both GDPR rights-and-freedoms risks AND AI Act safety/bias risks
• Mitigation controls mapped to both frameworks
• Residual risk score for each risk after mitigation
• Art.35(7) DPIA documentation completed

GDPR design obligations:

• Data minimisation implemented per Art.5(1)(c) and Art.25
• Data protection by design measures documented (Art.25)
• Retention limits defined (Art.5(1)(e) storage limitation)
• Data processor agreements in place per Art.28

AI Act Art.9 documentation:

• Risk management system established and documented
• Residual risks documented in technical documentation per Art.9(9)
• Risk management procedure covers full lifecycle including post-market
• Vulnerable user groups explicitly addressed per Art.9(7)

Art.36 gate:

• Residual risk review completed with DPO sign-off
• If high residual risk: Art.36 prior consultation initiated with LSA
• Processing NOT started until Art.36 consultation complete (if required)

Ongoing obligations:

• DPIA review triggered by material change (new purpose, new data types, new user groups, significant technical change)
• Art.9 risk management system updated with post-market monitoring data per Art.72

Practical Notes for sota.io Users

When deploying AI workloads on EU-native infrastructure, the infrastructure layer affects the DPIA and risk assessment in two specific ways:

Data residency and international transfer risk: GDPR Art.46 standard contractual clauses (SCCs) are required for transfers outside the EEA. If your AI inference runs on US-based cloud infrastructure (even within an EU datacenter), the CLOUD Act creates a risk the SCC-based transfer mechanism alone cannot fully mitigate. Deploying on Hetzner Germany via sota.io eliminates the US-entity transfer risk entirely — this simplifies the Art.35 DPIA because you have fewer residual risks in the cross-border transfer dimension.

Audit trail and evidence storage: Your DPIA documentation, technical controls register, and Art.9 risk management records are themselves personal data in some cases (they reference processing activities). Storing them on EU-controlled infrastructure ensures the compliance documentation is not itself subject to CLOUD Act reach.

What Comes Next in This Series

• Post #3: Art.17 Right to Erasure in AI systems — LLM training data removal and vector store deletion
• Post #4: Data minimisation for AI training and inference — Art.5(1)(c) GDPR + EU AI Act Art.10
• Post #5: Full AI + GDPR compliance stack — DPO role, accountability chain, audit trail finale

This post is part of the sota.io EU AI Act + GDPR Intersection Series. Previous post: EU AI Act + GDPR Art.22: Automated Decision-Making Double Compliance Guide 2026.