Deploying AI Agents in a GDPR-Compliant Way

GDPR-compliant AI Agent deployment: what it is about

An AI Agent is not a classic software tool but a system that continuously processes personal data — often in places that project teams initially overlook. Anyone operating an AI Agent as a controller in the DACH region must therefore justify and document each processing layer individually under data protection law. This hub page provides an overview of the five central levers: legal basis (Art. 6, and where applicable Art. 9 GDPR), automated individual decisions (Art. 22), processing on behalf of a controller (Art. 28), Data Protection Impact Assessment (Art. 35) and data residency in the EU.

Important upfront: the two legal regimes most relevant to AI Agents — the GDPR and the EU AI Act — overlap but apply independently of one another. A processing operation can be GDPR-relevant without falling under a high-risk classification of the AI Act; conversely, a high-risk system under Annex III must satisfy every GDPR principle on its own. This article is informational and does not constitute legal advice.

Where the GDPR applies within the agent stack

Under Art. 4(1)/(2) GDPR, any operation on personal data triggers the regulation. In an agentic system, these are typically:

• Inference inputs — prompts, system prompts, uploaded files, voice and image samples.
• Inference outputs — texts and summaries that name or describe individuals, including hallucinated personal data (both the Hamburg ChatGPT complaint and the Garante proceeding confirm: fabricated personal information remains personal data).
• Agent memory — short-term context windows, episodic and semantic memory, persistent vector stores (mem0, LangGraph, Letta, custom databases).
• Tool-call payloads — every JSON body sent to an internal API or an MCP server carries personal data into a new processor sphere.
• Multi-agent communication — A2A messages are processing events even when both agents reside with the same controller.
• Logs and traces as well as embeddings.

Particularly underestimated: embeddings are not automatically anonymous. Text inversion attacks (Morris et al., 2023) and membership inference attacks show that embeddings are re-identifiable via similarity search. The CNIL and the Hamburg Data Protection Authority therefore treat embeddings as pseudonymous personal data by default.

Legal basis: Art. 6 GDPR

Every processing operation needs one of the six legal bases under Art. 6(1). In practice, three are especially relevant for AI Agents:

The three-part test under Art. 6(1)(f) — pursuant to EDPB Guidelines 1/2024 (8 Oct 2024) and EDPB Opinion 28/2024 — requires: (1) a concretely articulated, real interest ("improving our HR screening agent for our own employees" rather than abstractly "improving AI"), (2) necessity (could it be done with less or anonymized data?) and (3) a balancing against the reasonable expectations of the data subjects.

The "publicly available" trap: A persistent misconception is that freely accessible web data is GDPR-free. Clearview AI was sanctioned in, among others, Italy (EUR 20 million, 10 Feb 2022) and France (EUR 20 million, 17 Oct 2022) — public availability substitutes neither for consent nor for any other legal basis. The CJEU ruling Meta v Bundeskartellamt (C-252/21) confirms: even with public data, the balancing under Art. 6(1)(f) must be carried out separately.

Enforcement benchmark: On 2 Nov 2024, the Italian Garante imposed EUR 15 million on OpenAI — for training without an identified legal basis (violation of Art. 5(1)(a), 5(2), 6), insufficient transparency and missing age verification. The Replika decision against Luka Inc. (10 Apr 2025, EUR 5 million) adds: performance of a contract (Art. 6(1)(b)) does not hold up where the user base includes minors without legal capacity.

Special categories of data: Art. 9 GDPR

As soon as an agent processes health, biometric or other sensitive data, the fundamental prohibition of Art. 9(1) applies. Practically relevant exceptions are explicit consent (Art. 9(2)(a)), employment and social security law grounds (Art. 9(2)(b), e.g. §26(3) BDSG) and substantial public interest (Art. 9(2)(g)). Caution regarding the interplay with the AI Act: its Art. 10(5) permits the processing of sensitive data for bias detection but is not a standalone Art. 9(2) GDPR exception — the legal basis must additionally derive from Art. 9(2) (usually (g)), which in most member states still requires national legislation.

Automated individual decisions: Art. 22 after SCHUFA and Dun & Bradstreet

Art. 22 is the most-litigated GDPR provision in the AI Agent environment. Two CJEU rulings have considerably broadened its scope of application:

• SCHUFA (C-634/21, 7 Dec 2023): Even an automated probability value (score) is itself an automated individual decision within the meaning of Art. 22(1) if a third party (e.g. the bank) substantially relies on it. Art. 22 contains a fundamental prohibition, not merely a right that must be invoked — the controller bears the burden of proof for an exception.
• Dun & Bradstreet (C-203/22, 27 Feb 2025): "Meaningful information about the logic involved" (Art. 15(1)(h)) means a concrete, comprehensible explanation that allows data subjects to understand, verify and contest the decision. Disclosure of the algorithm or of a mathematical formula does not suffice. Trade secrets do not automatically preclude disclosure — in the event of a dispute, the supervisory authority or the court decides on a case-by-case basis.

For practice this means: score-driven agents (HR screening, credit decisions, insurance underwriting, dynamic pricing) trigger Art. 22 almost as standard. The most common audit finding in 2024–2025 is the rubber-stamp review — a merely formal human confirmation. For a decision not to be "solely automated," the human must have the competence and authority to override, must actually examine the data, and must exhibit plausible override rates. As the originating authority of the Dun & Bradstreet case, the Austrian DSB is a direct yardstick-setter here for the DACH region.

Processing on behalf of a controller: Art. 28 GDPR

Most enterprise AI contracts (Microsoft Azure OpenAI, OpenAI Enterprise, Anthropic Claude for Work, Google Vertex AI, AWS Bedrock, Mistral, Aleph Alpha) are structured as controller-to-processor, with the explicit commitment not to use customer data for model training. These commitments are, however, contractual rather than statutory in nature and frequently reserve narrow rights for abuse monitoring or safety review.

A modern agent stack typically generates a five- to eight-layer sub-processor cascade: foundation model provider → cloud/hosting → orchestration runtime → vector store → memory provider → MCP server → observability → evaluation. For each layer a DPA must exist, the chain must be seamless under Art. 28(4), and data residency must be consistent. The most common audit findings: undisclosed MCP server flows, observability providers without a DPA, and evaluation services that collect prompt traces. Beyond the pure processor question, joint controllership (Art. 26) also looms: as soon as a provider uses data for its own purposes — for example when a web search tool (Bing in Copilot, Google Search in Gemini) queries the public web — the data flow leaves the processor sphere.

Data Protection Impact Assessment (DPIA): Art. 35 GDPR

AI Agents almost always trigger a DPIA because they regularly meet at least one of the triggers under Art. 35(3) and the DPA blacklists: automated decision with effect, large-scale profiling, biometric processing, innovative technology application or employee monitoring. The DSK guidance "Artificial Intelligence and Data Protection" (Version 1.0, 6 May 2024) explicitly requires the DPIA for most LLM deployments.

The DPIA methodology (DSK short paper No. 5, BfDI tool, EDPB WP248) comprises: (1) necessity and proportionality assessment, (2) risk identification (for AI Agents: hallucination, bias, prompt injection, memory leakage, output regurgitation, tool-call exfiltration, re-identification), (3) risk evaluation and (4) risk treatment. Required artifacts are data-flow diagrams across every personal-data hop, a roles map (controller, joint controller, processor with the Art. 28(4) chain), a risk register and consultation records (DPO opinion under Art. 35(2); works council / staff representation involvement under §87 BetrVG or the ArbVG). Where Annex III high risk applies, the DPIA can be merged with the Fundamental Rights Impact Assessment (FRIA, Art. 27 AI Act) into a joint artifact (Art. 27(4) AI Act).

EU data residency and cross-border transfers

For DACH decision-makers, EU data residency is a central lever for risk reduction. It is achievable via the EU Data Boundary (Microsoft), EU regions (Vertex AI with EU regional endpoints, AWS) or via sovereign providers such as Aleph Alpha (Pharia), IONOS AI Model Hub, STACKIT, T-Systems Open Telekom Cloud (DE/EU) and Swisscom Sovereign AI (CH).

For transfers to third countries, the Schrems II standard applies: SCCs only with a case-specific Transfer Impact Assessment (TIA). The EU-US Data Privacy Framework (adequacy decision of 10 Jul 2023) is currently valid; on 3 Sep 2025 the EU General Court dismissed the first action in Latombe v Commission, but an appeal before the CJEU is pending. Operational recommendation: use the DPF certification, but keep SCCs as a fallback and carry out TIAs even for DPF-certified recipients. For US providers, the CLOUD Act and FISA 702 remain risks to be addressed in the TIA. Switzerland has been recognized as adequate since 15 Jan 2024; the Swiss-US DPF has been in force since 15 Sep 2024.

DACH specifics and the Swiss tightening

Within the DACH region, the supervisory authorities diverge. The Hamburg Data Protection Authority takes the position that the mere storage of an LLM is not a processing operation (discussion paper, 15 Jul 2024) — EDPB Opinion 28/2024 implicitly disagrees. For deployers, the safe stance is: treat the model as potentially personal and concentrate the compliance work on the deployer-controlled layers (RAG indices, memory, logs), where deletion is technically possible.

In Switzerland, Art. 21 revFADP is stricter than Art. 22 GDPR: the duty to inform in the case of automated individual decisions is the rule, not the exception. In addition, intentional violations carry the threat of criminal sanctions against natural persons (management, DPO) of up to CHF 250,000. For FINMA-regulated financial service providers, outsourcing notifications and banking secrecy analyses are added, which push many deployers toward the sovereign cloud.

Practical outlook

GDPR compliance with AI Agents is not a one-time document but an architectural principle: separate the inference layer (managed API with a "no-training" DPA) from the deployer-controlled layers, which must remain fully deletable, and add a filter layer for DSAR and Art. 17 requests. Anyone who factors in the legal basis, Art. 22 architecture, a seamless DPA cascade, the DPIA and data residency from the outset avoids the most common audit findings — from unprotected memory stores through prompt logs without a deletion concept to undisclosed MCP flows. For the concrete contractual and technical design, controllers should always obtain expert legal advice; this overview does not replace it.