Data Protection Impact Assessment (DPIA) for AI Agents: Obligation, Thresholds and a Step-by-Step Approach

A data protection impact assessment (DPIA; German DSFA) is mandatory under Art. 35 GDPR where processing is likely to result in a high risk to the rights and freedoms of natural persons. For AI agents it is, in practice, almost always required, because these systems profile, make automated decisions, deploy innovative technology or combine datasets from multiple sources.

This article is part of the hub "GDPR-compliant AI-agent deployment" and provides a robust step-by-step approach as well as a trigger checklist for DACH controllers.

Quick answers

• Threshold: A DPIA is mandatory as soon as a high risk is likely (Art. 35(1)). Art. 35(3) names three standard cases, and Art. 35(4) allows supervisory-authority lists (BfDI blacklist v3.0, BayLDA, DSB Austria, EDÖB).
• AI reality: AI agents almost always trigger a DPIA obligation on account of profiling, automated decision-making and innovative technology.
• Procedure: The DPIA follows a documented process — the description of the processing as a mandatory component, then necessity/proportionality, risk identification, risk evaluation and remedial measures. Where a high residual risk remains, the prior consultation under Art. 36 follows.

What a DPIA under Art. 35 GDPR is

Art. 35(1) GDPR obliges the controller to carry out a DPIA where a type of processing — in particular when using new technologies — is, owing to its nature, scope, context and purposes, likely to result in a high risk to the rights and freedoms of natural persons. The DPIA is therefore an upstream risk-management instrument: it is drawn up before the start of processing and documents whether and how risks are controlled.

Importantly, the controller remains responsible for the DPIA even where it did not develop the AI agent itself. In its guidance "Artificial Intelligence and Data Protection" (Version 1.0, 6 May 2024), the DSK expressly clarifies that a DPIA is required for most LLM deployments and that the controller remains responsible even where it is not also the system provider.

When the DPIA becomes mandatory for AI agents

Art. 35(3) names three statutory standard cases (presumption scenarios):

1. Systematic and extensive evaluation of personal aspects, including profiling with significant effect.
2. Large-scale processing of special categories (Art. 9) or of data relating to criminal convictions (Art. 10).
3. Systematic large-scale monitoring of publicly accessible areas.

In addition, Art. 35(4) empowers the supervisory authorities to publish lists of processing operations requiring a DPIA. Consistently across the BfDI blacklist (current version v3.0), the BayLDA blacklist, the DSB ordinance list in Austria, the EDÖB practice on Art. 22 revFADP and DSK Short Paper No. 5, the following AI-relevant types of processing are listed as triggering a DPIA:

• Automated decisions with legal or significant effect
• Large-scale profiling, including agent-based behavioural analysis
• Processing of biometric or genetic data for identification purposes
• Use of innovative technology, in particular AI
• Combination of datasets from multiple sources
• Employee-monitoring scenarios

The practical consequence: on account of one or more of these points, AI agents almost always trigger a DPIA obligation.

Trigger checklist for AI agents

If even a single criterion clearly applies, the DPIA must be carried out. In case of doubt, a documented preliminary threshold assessment is advisable, justifying why no DPIA would be necessary — this addresses the accountability obligation under Art. 5(2).

The DPIA methodology step by step

The description of the processing is, under Art. 35(7)(a) GDPR, an upstream mandatory component of every DPIA: a systematic depiction of the AI agent together with a data-flow diagram mapping every personal-data hop (user → agent runtime → model API → vector store → MCP server → observability backend → logs), plus the system architecture with a sub-processor map and a role mapping (controller, joint controllers, processor, sub-processors with an unbroken chain under Art. 28(4)).

On this basis, DSK Short Paper No. 5, together with the BfDI DPIA tool, follows a four-step structure that is consistent with EDPB guideline WP248:

1. Necessity and proportionality. Is the processing strictly necessary? Would anonymous, pseudonymous or synthetic data suffice? Are the data volume and storage period minimised? Specifically for RAG: indexing pseudonymised chunks and minimising context payloads.
2. Risk identification. Capturing the AI-specific risks (see next section), in relation to the respective groups of data subjects.
3. Risk evaluation. Assessing each risk by likelihood of occurrence multiplied by severity.
4. Risk treatment and residual-risk acceptance. Technical measures under Art. 32 (encryption, pseudonymisation, access controls, logging, prompt-injection defence), organisational measures (training, governance) and contractual measures (DPA clauses), together with the documented acceptance of the residual risk.

The required consultation records form part of this: the opinion of the data protection officer (Art. 35(2)), the involvement of the works council or staff representation where applicable (Section 87 BetrVG, the Austrian ArbVG, Swiss participation rules), and — where feasible — the consultation of affected groups of data subjects (Art. 35(9)).

AI-specific risks in the risk register

For AI agents, the risk catalogue is considerably broader than for classic data processing. The DPIA must, at a minimum, take into account:

• Hallucination — fabricated yet plausible personal data; at once inaccurate (Art. 5(1)(d)) and a re-identification risk
• Bias and discrimination in scoring and ranking outputs
• Prompt injection, including cross-tenant attacks that extract third-party data
• Memory leakage between sessions via shared storage or system prompts
• Output regurgitation of training PII
• Scope creep and unauthorised inference
• Data exfiltration via tool calls to undocumented sub-processors
• Re-identification via embedding inversion — embeddings are not automatically anonymous and qualify as pseudonymous personal data
• Supply-chain risk across the five- to eight-tier sub-processor stack

The DSK guidance on RAG (2025) adds two RAG-specific risks: membership inference attacks and data poisoning. The DSK publication "Data protection requirements for AI systems" (17 June 2025) additionally provides the operational mapping to the Standard Data Protection Model (SDM).

A concrete example with figures: customer-service agent

A mid-sized company (800 employees) in Austria is planning a customer-service agent based on Azure OpenAI. Each month the agent processes around 40,000 conversations, of which an estimated 30 per cent (i.e. about 12,000) contain identifying customer data in prompts. Escalation decisions are initially prepared automatically.

In the DPIA, the risk "output regurgitation of training PII" is assessed with likelihood "medium" and severity "high". Remedy: output filters, a red-team test for memorisation, a documented balancing of interests. For the risk "memory leakage between sessions", strict tenant isolation lowers the likelihood from "medium" to "low". Prompt retention is limited to 30 days with redaction prior to permanent storage — consistent with the OpenAI API standard of a maximum of 30 days; for Anthropic API logs, 7 days apply as of 14 September 2025 (previously 30). Because every consequential decision is escalated to a human and the agent prepares rather than decides, the Art. 22 residual risk falls to an acceptable level. Result: no prior consultation under Art. 36 is required.

Prior consultation under Art. 36

Where a high residual risk remains after all measures, the supervisory authority must be consulted under Art. 36 before the start of processing. In the AI-agent context this is rare but plausible for HR screening agents with significant effect on applicants, for autonomous health-triage agents and for insurance underwriting agents. In DACH, processing times of 6 to 14 weeks at the BfDI, LfDI, DSB or EDÖB should be expected.

Integration with the EU AI Act's FRIA

For deployers of high-risk systems under Annex III that are public bodies or private providers of public services, or that operate in specified domains, Art. 27 EU AI Act requires a fundamental rights impact assessment (FRIA). Art. 27(4) expressly permits the FRIA to complement the GDPR DPIA and to reuse overlapping content. The recommended approach:

• Carry out the DPIA first (or in parallel) using the GDPR methodology.
• Extend it with FRIA-specific elements: impacts on fundamental rights beyond data protection (non-discrimination, dignity, freedom of expression, effective remedy), affected groups of persons, harms, oversight, complaint mechanisms.
• Create a single merged artefact with cross-references to Art. 35 GDPR and Art. 27 AI Act.

A note on the interplay: the data subject's right to an explanation of individual decisions under Art. 86 EU AI Act applies from 2 August 2026. It is broader in its scope of beneficiaries — it is available to any person affected by a high-risk AI decision, whereas the right under Art. 22 GDPR is available only to GDPR data subjects.

For agencies and B2B

Marketing agencies and B2B providers that roll out AI agents for clients are often themselves processors or joint controllers — and underestimate the fact that the DPIA obligation lies with the client as controller, while they must supply the robust processing description and sub-processor map. Those who already bring a DPIA template, a data-flow diagram and a vetted catalogue of measures to the proposal stage significantly shorten approval cycles and reduce the most common audit finding: a Copilot or agent rollout without a DPIA and without works-council consultation. Blck Alpaca supports DACH companies in setting up the DPIA, from the threshold assessment through to the merged DPIA/FRIA artefact.

Legal notice: This article is for general information purposes and does not constitute legal advice. For a binding assessment of a specific AI-agent processing operation, please seek qualified legal advice and consult your competent supervisory authority.