DPIA for AI Agents: How the German Mittelstand Implements GDPR Article 35 for Agent Rollouts in 2026

Forty-one percent of German companies now actively use AI, more than double the share from 2024²². Most of them are pushing AI agents into HR, finance, customer service, and operations without ever doing a proper Datenschutz-Folgenabschätzung. The supervisory authorities have noticed. The DSK published its first AI orientation in May 2024¹², followed by the RAG guidance in October 2025¹³, and the BfDI issued a federal handreichung in December 2025¹⁴. The signal is unmistakable: enforcement on AI deployments is now active, and the missing DPIA is the easiest finding to write up.

The good news: the DPIA process for AI agents is not exotic. Article 35 GDPR has been in force since 2018, the Article 29 Working Party guidelines (WP248) have been the playbook since 2017⁵, and the German DSK, EDPB, and EDPS have now spent two years adapting those rules to LLMs, RAG systems, and autonomous agents. There is a clear path from intention to a defensible, signed-off DPIA, and that path takes weeks, not months, when you set it up correctly the first time.

This is the practical guide for the CTO, CIO, Datenschutzbeauftragte, or Geschäftsführer at a German Mittelstand company about to deploy its first - or fifth - AI agent. It covers when a DPIA is mandatory, what the German Aufsichtsbehörden actually expect, how the new FRIA under the EU AI Act fits in, and the seven-step process that gets you from blank document to production sign-off. No theatre. Just what works in 2026.

Why Almost Every AI Agent Triggers a DPIA

The Datenschutz-Folgenabschätzung is not a niche obligation. Article 35(1) GDPR applies whenever the controller deploys a new technology that is likely to result in a high risk to the rights and freedoms of natural persons. The wording is broad on purpose, and the AI agent pattern hits the trigger in multiple ways simultaneously.

• Innovative technology - AI agents combining LLMs, tool calling, and autonomous planning are textbook new technology under WP248. Even the EDPS now lists agentic AI as a category that requires its own risk assessment²¹.
• Systematic processing - every action an agent takes (email read, record updated, workflow triggered) generates traceable processing of personal data. The Hamburg LfD has flagged exactly this point as a regulatory focus for 2026¹⁰.
• Cross-system reach - the agent ingests data from ERP, CRM, HRIS, email, and ticketing systems. That combination of datasets is itself a WP248 criterion⁵.
• Employee data exposure - any agent operating on behalf of a user processes employee data and often telemetry about colleagues. The Datenschutzkonferenz treats employees as vulnerable data subjects¹².
• Automated decisions - an agent that approves, rejects, or scores anything for a human falls into Article 22 GDPR. That trigger alone forces a DPIA⁵.
• Third-country transfers - most LLM providers terminate in the US. Without proper Standardvertragsklauseln and Transfer Impact Assessments the agent generates a textbook Art. 44-49 risk¹⁷.

The Bitkom KI-Studie 2026 shows 41 percent of German companies already use AI actively, with more than 60 percent of firms above 500 employees on board²². The gap between AI adoption and AI compliance is widening. The Aufsichtsbehörden have responded by publishing concrete playbooks - and by sharpening their audit focus.

What a DPIA Actually Is (and What It Is Not)

The DPIA is a structured assessment of risks to data subjects from a specific processing activity, with concrete mitigations and a residual risk decision. It is a controller obligation, not a checkbox. The output is a living document that a supervisory authority can read in 30 minutes and audit in 90.

What it contains by law

Article 35(7) GDPR sets the minimum content. The DSK Orientierungshilfe and the CNIL methodology fill in the operational detail^{12, 28}.

• Systematic description of the processing - purposes, legal basis, categories of data, categories of data subjects, recipients, retention. The Art. 30 records of processing entry is the starting point, not the end point.
• Necessity and proportionality assessment - is the AI agent actually necessary for the stated purpose, or could a less invasive option deliver the same outcome.
• Risk assessment to data subjects - probability and severity of harm, mapped to the actual data flows of the agent.
• Mitigation measures - technical, organisational, and contractual controls that reduce identified risk. Residual risk must be explicitly named, not buried.
• Consultation with the DSB - Art. 35(2) is not optional. The advice of the data protection officer must be sought and documented.
• Stakeholder consultation where appropriate - employees, works council, customer representatives. Not always required, often advisable.

What a DPIA is not

• Not a vendor questionnaire - the SOC 2 or ISO 27001 report from your LLM provider is input. It is not a DPIA.
• Not a privacy notice - the data subject information (Art. 13/14) is a separate document. The DPIA is the internal risk assessment.
• Not a one-off PDF - the obligation under Art. 35(11) is continuous review. Treat it as a living document tied to version control.
• Not the AI vendor's responsibility - the controller owns the DPIA. The vendor cannot do it for you¹⁷.
• Not a Konformitätsbewertung under the AI Act - those are separate obligations for providers of high-risk AI. The DPIA covers data protection risk specifically.

The 9-Criteria Test (WP248) Applied to AI Agents

WP248 rev.01 - the Article 29 Working Party guidelines adopted by the EDPB - is the operational filter for the Article 35(1) high-risk test. The guidance is simple: when a processing activity meets two or more of nine criteria, a DPIA is normally required. AI agents almost never meet just two⁵.

Mapping the nine criteria to typical agent use cases

Run this matrix against your planned agent. If you cannot mark two boxes after one minute of analysis, you are either looking at a very narrow workflow or you have not understood the agent yet. The DSK confirms that combinations of these criteria are typical in AI deployments and that the DPIA threshold is generally met.

The German Regulatory Landscape

German Aufsichtsbehörden have published more AI-specific guidance in the last 24 months than in the previous five years combined. The Mittelstand has to track four interlocking layers: federal BfDI, state-level Landesdatenschutzbeauftragte, the joint DSK, and the European EDPB. Each layer has issued something that bears directly on AI agent DPIAs.

The DSK output stack

1. Orientierungshilfe Künstliche Intelligenz und Datenschutz (May 2024) - the foundational document. Treats LLMs as a primary use case. States that a DSFA is frequently required for AI applications. Covers selection, implementation, and operation phases¹².
2. Orientierungshilfe RAG-Systeme (October 2025) - the most important update for 2026. Explicitly requires a DSFA covering all RAG components - retriever, vector database, and LLM. States that an unlawfully trained model remains unlawful inside a RAG. Sets the expectation for purpose definitions, Art. 30 documentation, tenant separation, and access controls¹³.
3. DSFA Muss-Liste v1.1 - the technology-neutral blacklist. Does not name AI explicitly, but the criteria (large-scale automated profiling with significant effect, etc.) catch most enterprise AI use cases³.
4. Hambacher Erklärung zur KI - the political position. Self-learning systems making automated individual decisions are subject to data protection law in full. Reaffirmed in 2024¹⁵.

Federal BfDI

• Handreichung KI in Behörden (December 2025) - Prof. Dr. Louisa Specht-Riemenschneider's first major AI document. Focused on federal agencies, but the reasoning on LLM training data, memorised personal data, transparency, and lawfulness is directly applicable to enterprise deployments¹⁴.
• BfDI DSFA portal - federal-level blacklist and templates. Useful even for private-sector controllers as a structure reference⁴.

Landes-level supervisory authorities

• HmbBfDI Diskussionspapier LLM (July 2024) - the pragmatic position. An LLM does not store personal data in the conventional sense. Unlawful training does not automatically make deployment illegal, but exposes both trainer and deployer to liability. Specific use - not the model itself - is what counts legally¹⁰.
• LfDI Baden-Württemberg Diskussionspapier v2.0 (October 2024) - the legal-basis playbook. Walks through GDPR, BDSG, LDSG BW legal bases for AI use, with worked examples and a practical framework for use-case evaluation¹¹.
• BayLDA KI-Beratungsstelle - the SME-friendly entry point. Bavaria stood up a dedicated AI advisory unit for start-ups and SMEs, with a checklist (v0.9) and direct consultation options. Use it^{15, 16}.

European layer

• EDPB Opinion 28/2024 on AI models (December 2024) - the threshold reference. Anonymity of AI models, legitimate interest test, deployer liability for unlawfully processed training data. Sets the bar for any vendor due diligence step in your DPIA^{17, 18}.
• EDPB AI Auditing Checklist (June 2024) - the EDPB Support Pool of Experts methodology. Covers model card, system map, bias testing, adversarial audit, final report. Use it as your DPIA technical annex template¹⁹.
• EDPB AI Enforcement Task Force (February 2025) - the enforcement infrastructure. Coordinates DPA actions on AI complaints across the EU, with a quick-response team for urgent matters²⁰.
• EDPS Revised Generative AI Orientations (October 2025) - the agentic AI specifics. Addresses autonomous AI agents that perform tasks and make decisions without human intervention. Mandates Art. 30 register entries, defined purposes, role determination, and DPIAs²¹.

DPIA, FRIA and the EU AI Act

The EU AI Act becomes fully applicable on 2 August 2026, with high-risk obligations under Annex III enforceable from that date^{6, 8}. Article 27 introduces a new instrument - the Fundamental Rights Impact Assessment (FRIA) - that overlaps with the GDPR DPIA but does not replace it. Mittelstand teams need to understand both, and the practical interaction.

Who needs a FRIA

• Public bodies deploying high-risk AI systems
• Private entities providing public services - utilities, healthcare, education contractors
• Private deployers using high-risk AI for creditworthiness assessment or insurance pricing on natural persons
• Anyone deploying Annex III high-risk AI in HR or biometric contexts will face FRIA-adjacent expectations even if the strict legal trigger is narrower^{7, 8}

The DPIA / FRIA boundary

Article 27(4) of the EU AI Act is the explicit reconciliation clause: a DPIA conducted under Article 35 GDPR complements the FRIA. The deployer may be deemed to have met FRIA obligations to the extent they are already covered by the DPIA. In practice, the DPIA covers data protection rights specifically while the FRIA scope is broader - covering all fundamental rights including non-discrimination, freedom of expression, due process, and economic equality^{6, 9}.

What the FRIA requires beyond the DPIA

• Process description - how the high-risk AI fits into the deployer's operations and decision-making chain
• Period and frequency of use - explicit time bounds rather than open-ended deployment
• Categories of affected persons and groups - including third parties beyond direct data subjects
• Specific risks of harm to those identified persons - mapped to fundamental rights, not only data rights
• Description of human oversight measures - per Article 14 AI Act, going beyond Art. 22 GDPR human review
• Mitigations including internal governance and complaint-handling - the FRIA expects organisational depth

The 7-Step DPIA Process for AI Agents

The DPIA is not free-form. Article 35(7) GDPR plus the DSK Orientierungshilfen plus the EDPB AI Auditing Checklist combine into a clear sequence. The seven steps below collapse them into one operational playbook. Run them in order. Do not skip the boring ones.

Step 1: Scoping and trigger documentation (Week 1)

1. Define the use case in one paragraph - what does the agent do, for whom, with what data, with what consequence for the data subject
2. Run the WP248 nine-criteria matrix - document which criteria fire and why. Two is the threshold, but most agents hit four to six
3. Check the DSK Muss-Liste - does the use case fall within any named entry. Most AI agents do not, but check³
4. Record the trigger decision - if no DPIA is required, document why. If yes, document the assumptions

Step 2: Asset and data flow mapping (Week 1-2)

5. Build the system map - LLM provider, vector store, retrieval source systems, MCP tools, integrations. The EDPB AI Auditing Checklist has a usable template¹⁹
6. List every data category - employee data, customer data, prospect data, special category data (health, financial), system telemetry
7. Map the data flows - from source system to retrieval, from retrieval to prompt, from prompt to LLM, from LLM to action, from action to log
8. Identify all parties - controllers, processors, sub-processors, joint controllers. Article 28 AVVs must exist for each processor
9. Document third-country transfers - LLM provider locations, fallback regions, telemetry destinations. Standardvertragsklauseln plus Transfer Impact Assessments where required

Step 3: Legal basis assessment (Week 2-3)

10. Pick the Art. 6 legal basis for each processing purpose - contract, legitimate interest, consent, legal obligation. The LfDI BW Diskussionspapier v2.0 walks through the realistic options¹¹
11. Run the three-step legitimate interest test when relying on Art. 6(1)(f). EDPB Opinion 28/2024 cites conversational AI agents as a worked example¹⁷
12. Check Art. 9 if special category data is in scope - explicit consent, employment law, vital interest, or one of the other narrow exceptions
13. Check Art. 22 for automated decision-making - if the agent's outputs influence a decision with legal or similar effect, contract / law / consent plus safeguards
14. Cross-check Art. 88 BDSG for employee data - works council agreement or BDSG § 26 are the usual bases for employment-context AI

Step 4: Necessity and proportionality (Week 3)

15. Test data minimisation - does the agent actually need each data category, or can a redacted version do the job
16. Test alternative means - could a non-AI tool, simpler ML, or rule-based logic achieve the same outcome with less risk
17. Test retention - prompt logs, action logs, telemetry. Retain only as long as the operational and audit purpose justifies
18. Document the proportionality conclusion - the benefit of the agent against the residual risk to data subjects

Step 5: Risk assessment (Week 3-4)

19. Identify risk scenarios - unauthorised access, data leakage in prompts, hallucinated personal data, biased output, opaque automated decision, lock-in to third country
20. Score probability and severity - the CNIL PIA tool uses a four-level scale that maps cleanly to most internal risk matrices²⁸
21. Score residual risk after baseline controls - encryption, access control, deletion, logging. The starting position before AI-specific mitigations
22. Name the risks the agent introduces specifically - prompt injection, model hallucination, training data memorisation, RAG poisoning. Do not pretend these are theoretical²¹

Step 6: Mitigation design (Week 4-6)

23. Technical measures - data redaction before prompts, output filtering, tenant isolation in the vector store, role-based access, encryption at rest and in transit
24. Human-in-the-loop checkpoints - for any agent action above a risk threshold, require human approval. Document the threshold criteria
25. Logging and observability - immutable audit log for every agent action, prompt, and tool call. Enables Art. 30 records and Art. 82 investigation
26. Contractual measures - AVV with LLM provider, sub-processor list, EU data residency clauses, model version transparency, breach notification timelines
27. Organisational measures - AI literacy training per EU AI Act Art. 4, internal AI policy, escalation paths, complaint-handling for data subjects
28. Test the mitigations - red-team the agent, attempt prompt injection, simulate a data subject access request. Document what failed and what was fixed

Step 7: DSB consultation, sign-off, and review schedule (Week 6-8)

29. Formal DSB consultation - written advice from the data protection officer per Art. 35(2). Document the input, any disagreements, and the resolution
30. Works council alignment - where employee data is involved, run the same evidence base through Section 87 BetrVG and finalise the Betriebsvereinbarung
31. Article 36 prior consultation check - only if residual risk remains high after mitigation. The DSK confirms this is the exception, not the rule
32. Controller sign-off - the responsible management function (CTO, Geschäftsführer) signs the DPIA. The DPIA is the controller's document, not the DSB's
33. Review schedule - calendar entries for annual review plus triggers for material change (LLM version bump, new tool integration, new data category)

RAG and Vector Stores: The Hidden DPIA Risks

The DSK Orientierungshilfe RAG-Systeme from October 2025 is the most consequential AI document for the German Mittelstand right now. It applies directly to any agent that retrieves company knowledge - SharePoint, Confluence, file shares, ERP help, CRM notes - and uses it to ground LLM outputs. Read it before designing the architecture, not after¹³.

The RAG-specific risk surface

• The vector database is itself a processing activity - embeddings derived from personal data are personal data. Storage, access control, deletion all apply
• Unlawful training does not become lawful inside a RAG - the DSK is explicit on this point. Using a model trained on unlawfully processed data inside a RAG does not cure the original violation¹³
• Combining vectorised data with model knowledge creates new risk - the DSK names this combination as a specific data protection concern requiring DSFA treatment
• Tenant separation is non-negotiable - multi-tenant vector stores must guarantee that one customer's data cannot leak into another customer's prompts
• Access controls inherited from source systems - if a document is only accessible to HR in SharePoint, the RAG retrieval must respect that. Oversharing is the most common Mittelstand pattern
• Deletion of retrieved chunks - the Art. 17 right to erasure must propagate to vectors, not just to source documents
• Logging of retrieval events - what data was retrieved for which user is itself a processing activity to log
• Prompt and answer logging - prompts containing personal data and answers containing inferred personal data are processing activities, retained under defined retention rules

RAG-specific DPIA requirements

Cost of getting RAG wrong

• Bußgeld exposure - missing DPIA plus exposed special category data combines Art. 83(4) and Art. 83(5)
• Civil claims - Art. 82 damages claims have a low bar. A handful of plaintiffs combined with EUR 500-2,000 settlements per case adds up
• Audit aftermath - an Aufsichtsbehörde finding triggers a follow-up audit cycle that occupies the DSB for months
• Project halt - cease-and-desist orders force the agent offline mid-deployment. Sunk cost goes to zero
• Reputational - public press releases on AI-related fines are now a standard pattern

How Superkind Fits

Superkind builds custom AI agents for the German Mittelstand. The DPIA is not a separate compliance project we hand off - it is part of the build process. We treat the assessment as a design input, not a post-hoc tick-box, and we structure deployments so the DPIA documentation falls out of the architecture rather than being reconstructed afterwards.

• DPIA-aware scoping - the first workshop maps the use case against the WP248 criteria so risk shapes the architecture from day one
• Sits on your stack - the agent connects to existing ERP, CRM, HRIS, and SharePoint through governed APIs. No new platform to assess separately
• EU-resident by default - Frankfurt AWS, Deutschland Azure, IONOS, Open Telekom Cloud, or on-prem. Third-country transfers are an opt-in decision, not a default
• Tenant-separated vector store - per use case, with deletion propagation and retention rules wired into the deployment
• Action audit log - immutable record of every prompt, retrieval, tool call, and agent action. The Art. 30 register entry writes itself
• Human-in-the-loop thresholds - configurable per action class, mapped to the risk tier identified in the DPIA
• AVV and sub-processor documentation - delivered with the system, not requested six months in
• Works council ready - documentation packaged for Section 87 BetrVG, with a Betriebsvereinbarung draft as part of the handover

Decision Framework: Is Your DPIA Approach Audit-Ready?

The Aufsichtsbehörden will not ask for a perfect DPIA. They will ask whether one exists, whether it is plausible, and whether the controller engaged seriously with the risks. Use the framework below to test your own readiness before they do.

Frequently Asked Questions

Henri Jung

Co-founder of Superkind, where he helps SMEs and enterprises deploy custom AI agents that actually fit how their teams work. Henri is passionate about closing the gap between what AI can do and the value it creates in real companies. He believes the Mittelstand has everything it needs to lead in AI - it just needs the right approach.