DSGVO-konformer AI-Agent-Einsatz

DSGVO-konformer AI-Agent-Einsatz: Worum es geht

Ein AI Agent ist kein klassisches Software-Tool, sondern ein System, das laufend personenbezogene Daten verarbeitet – oft an Stellen, die Projektteams zunächst übersehen. Wer in der DACH-Region einen AI Agent als Verantwortlicher (Controller) betreibt, muss daher jede Verarbeitungsschicht einzeln datenschutzrechtlich begründen und dokumentieren. Diese Hub-Seite gibt den Überblick über die fünf zentralen Stellschrauben: Rechtsgrundlage (Art. 6, ggf. Art. 9 DSGVO), automatisierte Einzelentscheidungen (Art. 22), Auftragsverarbeitung (Art. 28), Datenschutz-Folgenabschätzung (Art. 35) und Datenresidenz in der EU.

Wichtig vorab: Die beiden für AI Agents relevantesten Rechtsregime – DSGVO und EU AI Act – überlappen, gelten aber unabhängig voneinander. Eine Verarbeitung kann DSGVO-relevant sein, ohne unter eine Hochrisiko-Einstufung des AI Act zu fallen; umgekehrt muss ein Hochrisiko-System nach Annex III jedes DSGVO-Prinzip eigenständig erfüllen. Dieser Beitrag ist informational und stellt keine Rechtsberatung dar.

Wo die DSGVO im Agent-Stack greift

Nach Art. 4(1)/(2) DSGVO löst jede Operation an personenbezogenen Daten die Verordnung aus. In einem agentischen System sind das in der Regel:

• Inference-Inputs – Prompts, System-Prompts, hochgeladene Dateien, Sprach- und Bildsamples.
• Inference-Outputs – Texte und Zusammenfassungen, die Personen benennen oder beschreiben, einschließlich halluzinierter Personendaten (sowohl die Hamburger ChatGPT-Beschwerde als auch das Garante-Verfahren bestätigen: erfundene Personeninformationen bleiben personenbezogene Daten).
• Agent-Memory – kurzfristige Context-Windows, episodisches und semantisches Gedächtnis, persistente Vektor-Stores (mem0, LangGraph, Letta, eigene Datenbanken).
• Tool-Call-Payloads – jeder JSON-Body an eine interne API oder einen MCP-Server trägt Personendaten in eine neue Processor-Sphäre.
• Multi-Agent-Kommunikation – A2A-Nachrichten sind auch dann Verarbeitungsereignisse, wenn beide Agents beim selben Verantwortlichen liegen.
• Logs und Traces sowie Embeddings.

Besonders unterschätzt: Embeddings sind nicht automatisch anonym. Text-Inversion-Attacken (Morris et al., 2023) und Membership-Inference-Angriffe zeigen, dass Embeddings über Ähnlichkeitssuche re-identifizierbar sind. CNIL und die Hamburger Datenschutzbehörde behandeln Embeddings daher standardmäßig als pseudonyme personenbezogene Daten.

Rechtsgrundlage: Art. 6 DSGVO

Jede Verarbeitung braucht eine der sechs Rechtsgrundlagen aus Art. 6(1). Für AI Agents sind in der Praxis vor allem drei relevant:

Der dreistufige Test nach Art. 6(1)(f) – gemäß EDPB-Leitlinien 1/2024 (8.10.2024) und EDPB-Opinion 28/2024 – verlangt: (1) ein konkret artikuliertes, reales Interesse („Verbesserung unseres HR-Screening-Agents für eigene Mitarbeiter" statt abstrakt „KI verbessern"), (2) Erforderlichkeit (ginge es mit weniger oder anonymisierten Daten?) und (3) eine Abwägung gegen die vernünftigen Erwartungen der Betroffenen.

Die „öffentlich verfügbar"-Falle: Ein hartnäckiger Irrtum ist, dass frei zugängliche Webdaten DSGVO-frei seien. Clearview AI wurde u. a. in Italien (20 Mio. Euro, 10.2.2022) und Frankreich (20 Mio. Euro, 17.10.2022) sanktioniert – öffentliche Verfügbarkeit ersetzt weder Einwilligung noch eine andere Rechtsgrundlage. Das EuGH-Urteil Meta v Bundeskartellamt (C-252/21) bestätigt: Auch bei öffentlichen Daten ist die Abwägung nach Art. 6(1)(f) separat durchzuführen.

Enforcement-Benchmark: Das italienische Garante verhängte am 2.11.2024 15 Mio. Euro gegen OpenAI – wegen Trainings ohne identifizierte Rechtsgrundlage (Verstoß gegen Art. 5(1)(a), 5(2), 6), unzureichender Transparenz und fehlender Altersverifikation. Die Replika-Entscheidung gegen Luka Inc. (10.4.2025, 5 Mio. Euro) ergänzt: Vertragserfüllung (Art. 6(1)(b)) trägt nicht, wenn der Nutzerkreis Minderjährige ohne Geschäftsfähigkeit umfasst.

Besondere Datenkategorien: Art. 9 DSGVO

Sobald ein Agent Gesundheits-, Biometrie- oder andere sensible Daten verarbeitet, greift das grundsätzliche Verbot des Art. 9(1). Praktisch relevante Ausnahmen sind die explizite Einwilligung (Art. 9(2)(a)), arbeits- und sozialrechtliche Grundlagen (Art. 9(2)(b), z. B. §26(3) BDSG) sowie das erhebliche öffentliche Interesse (Art. 9(2)(g)). Achtung beim Zusammenspiel mit dem AI Act: Dessen Art. 10(5) erlaubt die Verarbeitung sensibler Daten zur Bias-Erkennung, ist aber keine eigenständige Art.-9(2)-DSGVO-Ausnahme – die Rechtsgrundlage muss zusätzlich aus Art. 9(2) (meist (g)) stammen, was in den meisten Mitgliedstaaten noch nationaler Gesetzgebung bedarf.

Automatisierte Einzelentscheidungen: Art. 22 nach SCHUFA und Dun & Bradstreet

Art. 22 ist die meistprozessierte DSGVO-Norm im AI-Agent-Umfeld. Zwei EuGH-Urteile haben den Anwendungsbereich erheblich erweitert:

• SCHUFA (C-634/21, 7.12.2023): Bereits ein automatisierter Wahrscheinlichkeitswert (Score) ist selbst eine automatisierte Einzelentscheidung im Sinne von Art. 22(1), wenn ein Dritter (z. B. die Bank) maßgeblich darauf abstellt. Art. 22 enthält ein grundsätzliches Verbot, nicht nur ein geltend zu machendes Recht – der Verantwortliche trägt die Beweislast für eine Ausnahme.
• Dun & Bradstreet (C-203/22, 27.2.2025): „Aussagekräftige Informationen über die involvierte Logik" (Art. 15(1)(h)) bedeuten eine konkrete, verständliche Erklärung, die Betroffenen erlaubt, die Entscheidung zu verstehen, zu prüfen und anzufechten. Die Offenlegung des Algorithmus oder einer mathematischen Formel genügt nicht. Geschäftsgeheimnisse stehen der Offenlegung nicht automatisch entgegen – im Streitfall entscheidet die Aufsichtsbehörde oder das Gericht im Einzelfall.

Für die Praxis heißt das: Score-getriebene Agents (HR-Screening, Kreditentscheidung, Versicherungs-Underwriting, dynamisches Pricing) lösen Art. 22 fast standardmäßig aus. Der häufigste Audit-Befund 2024–2025 ist der Rubber-Stamp-Review – eine bloß formale menschliche Bestätigung. Damit eine Entscheidung nicht „ausschließlich automatisiert" ist, muss der Mensch Kompetenz und Befugnis zum Überstimmen haben, die Daten tatsächlich prüfen, und plausible Override-Raten aufweisen. Die österreichische DSB ist als Ausgangsbehörde des Dun-&-Bradstreet-Falls hier ein direkter Maßstabgeber für den DACH-Raum.

Auftragsverarbeitung: Art. 28 DSGVO

Die meisten Enterprise-AI-Verträge (Microsoft Azure OpenAI, OpenAI Enterprise, Anthropic Claude for Work, Google Vertex AI, AWS Bedrock, Mistral, Aleph Alpha) sind als Controller-zu-Processor strukturiert, mit der ausdrücklichen Zusage, Kundendaten nicht für das Modelltraining zu nutzen. Diese Zusagen sind jedoch vertraglicher, nicht gesetzlicher Natur und reservieren häufig enge Rechte für Abuse-Monitoring oder Safety-Review.

Ein moderner Agent-Stack erzeugt typischerweise einen fünf- bis achtschichtigen Sub-Processor-Cascade: Foundation-Model-Provider → Cloud/Hosting → Orchestrierungsruntime → Vektor-Store → Memory-Provider → MCP-Server → Observability → Evaluation. Für jede Schicht muss ein AVV bestehen, die Kette nach Art. 28(4) lückenlos sein und die Datenresidenz konsistent. Die häufigsten Audit-Befunde: nicht offengelegte MCP-Server-Flows, Observability-Anbieter ohne AVV und Evaluation-Dienste, die Prompt-Traces sammeln. Über die reine Processor-Frage hinaus droht zudem Joint Controllership (Art. 26): Sobald ein Anbieter Daten für eigene Zwecke nutzt – etwa wenn ein Web-Search-Tool (Bing in Copilot, Google Search in Gemini) die öffentliche Web abfragt – verlässt der Datenfluss die Processor-Sphäre.

Datenschutz-Folgenabschätzung (DSFA): Art. 35 DSGVO

AI Agents lösen fast immer eine DSFA aus, weil sie regelmäßig mindestens einen der Trigger nach Art. 35(3) und den DPA-Blacklists erfüllen: automatisierte Entscheidung mit Wirkung, großflächiges Profiling, biometrische Verarbeitung, innovative Technologieanwendung oder Mitarbeitermonitoring. Die DSK-Orientierungshilfe „Künstliche Intelligenz und Datenschutz" (Version 1.0, 6.5.2024) verlangt die DSFA explizit für die meisten LLM-Deployments.

Die DSFA-Methodik (DSK-Kurzpapier Nr. 5, BfDI-Tool, EDPB WP248) umfasst: (1) Notwendigkeits- und Verhältnismäßigkeitsprüfung, (2) Risikoidentifikation (für AI Agents: Halluzination, Bias, Prompt-Injection, Memory-Leakage, Output-Regurgitation, Tool-Call-Exfiltration, Re-Identifikation), (3) Risikobewertung und (4) Risikobehandlung. Erforderliche Artefakte sind Datenfluss-Diagramme über jeden Personendaten-Hop, eine Rollen-Map (Controller, Joint Controller, Processor mit Art.-28(4)-Kette), ein Risikoregister und Konsultationsnachweise (DPO-Stellungnahme nach Art. 35(2); Betriebsrats-/Personalvertretungs-Beteiligung nach §87 BetrVG bzw. ArbVG). Wo Annex-III-Hochrisiko vorliegt, lässt sich die DSFA mit der Grundrechte-Folgenabschätzung (FRIA, Art. 27 AI Act) zu einem gemeinsamen Artefakt verschmelzen (Art. 27(4) AI Act).

Datenresidenz EU und grenzüberschreitende Transfers

Für DACH-Entscheider ist EU-Datenresidenz ein zentraler Hebel zur Risikoreduktion. Erreichbar ist sie über die EU Data Boundary (Microsoft), EU-Regionen (Vertex AI mit EU-Regional-Endpoints, AWS) oder über souveräne Anbieter wie Aleph Alpha (Pharia), IONOS AI Model Hub, STACKIT, T-Systems Open Telekom Cloud (DE/EU) und Swisscom Sovereign AI (CH).

Beim Transfer in Drittländer gilt der Schrems-II-Maßstab: SCCs nur mit fallbezogenem Transfer Impact Assessment (TIA). Das EU-US Data Privacy Framework (Adäquanzbeschluss vom 10.7.2023) ist derzeit gültig; das EU-Gericht wies am 3.9.2025 in Latombe v Commission die erste Klage ab, doch eine Berufung beim EuGH ist anhängig. Operative Empfehlung: DPF-Zertifizierung nutzen, aber SCCs als Fallback vorhalten und TIAs auch für DPF-zertifizierte Empfänger durchführen. Für US-Anbieter bleiben CLOUD Act und FISA 702 als Risiken im TIA zu adressieren. Die Schweiz ist seit 15.1.2024 als angemessen anerkannt; das Swiss-US DPF gilt seit 15.9.2024.

DACH-Besonderheiten und Schweizer Verschärfung

Innerhalb des DACH-Raums divergieren die Aufsichtsbehörden. Die Hamburger Datenschutzbehörde vertritt die These, die bloße Speicherung eines LLM sei keine Verarbeitung (Diskussionspapier, 15.7.2024) – EDPB-Opinion 28/2024 widerspricht implizit. Für Deployer ist die sichere Haltung: das Modell als potenziell personenbezogen behandeln und die Compliance-Arbeit auf die deployer-kontrollierten Schichten (RAG-Indizes, Memory, Logs) konzentrieren, wo Löschung technisch möglich ist.

In der Schweiz ist Art. 21 revDSG strenger als Art. 22 DSGVO: Die Informationspflicht bei automatisierten Einzelentscheiden ist die Regel, nicht die Ausnahme. Zudem drohen bei vorsätzlichen Verstößen strafrechtliche Sanktionen gegen natürliche Personen (Geschäftsleitung, DPO) bis CHF 250.000. Für FINMA-regulierte Finanzdienstleister kommen Outsourcing-Notifikationen und Bankgeheimnis-Analysen hinzu, die viele Deployer Richtung Sovereign Cloud drängen.

Praxis-Ausblick

DSGVO-Konformität bei AI Agents ist kein einmaliges Dokument, sondern ein architektonisches Prinzip: Trennen Sie die Inference-Schicht (managed API mit „No-Training"-AVV) von den deployer-kontrollierten Schichten, die vollständig löschbar bleiben müssen, und ergänzen Sie eine Filter-Schicht für DSAR- und Art.-17-Anfragen. Wer Rechtsgrundlage, Art.-22-Architektur, lückenlosen AVV-Cascade, DSFA und Datenresidenz von Anfang an mitdenkt, vermeidet die häufigsten Audit-Befunde – von ungeschützten Memory-Stores über Prompt-Logs ohne Löschkonzept bis zu nicht offengelegten MCP-Flows. Für die konkrete vertragliche und technische Ausgestaltung sollten Verantwortliche stets fachkundige Rechtsberatung einholen; dieser Überblick ersetzt sie nicht.