DSGVO und Agentic AI in Production: Was Datenschutzbeauftragte 2026 prüfen, und was sie nicht durchgehen lassen

Schlüsselzahlen auf einen Blick

• AI Act und DSGVO sind komplementär, nicht ersetzend (siehe AI Act Erwägungsgrund 10 und Art. 2 Abs. 7), wer Agentic-AI in Production betreibt, muss beide Pflichtenkataloge gleichzeitig erfüllen, nicht einen davon "abwählen".
• DSGVO Art. 35 verlangt eine Datenschutz-Folgenabschätzung (DSFA) bei "voraussichtlich hohem Risiko", bei generativer KI mit Personenbezug ist das nahezu immer der Fall, insbesondere bei automatisierten Einzelentscheidungen (Art. 22).
• AI Act Art. 27 verlangt für bestimmte Deployer von Hochrisiko-KI-Systemen (öffentliche Stellen, Privatstellen, die öffentliche Dienste erbringen, sowie Banken/Versicherungen bei Bonitäts- und Risikoeinstufung, Annex III(5)(b)/(c)) zusätzlich eine Fundamental Rights Impact Assessment (FRIA). DSFA und FRIA überlappen, ersetzen sich aber nicht, wo beide greifen, sind beide zu führen.
• AI Act Art. 26 legt die Pflichten für Deployer von Hochrisiko-KI-Systemen fest. Das ist nicht der Provider (z.B. OpenAI), sondern Sie als Mittelständler, der den Agent in Production betreibt.

Warum dieser Post jetzt relevant ist

Im DACH-Mittelstand sehen wir 2026 einen wiederkehrenden Pattern: Engineering-Teams bauen einen Agentic-AI-Use-Case, der Pilot läuft, der erste Production-Rollout steht, und dann meldet sich der externe Datenschutzbeauftragte. Drei typische Reaktionen:

1. "Wir nutzen doch nur die OpenAI-API, das ist deren Problem", falsch. Sie sind Verantwortlicher im Sinne der DSGVO (Art. 4 Nr. 7), wenn Sie über Zwecke und Mittel der Verarbeitung entscheiden. Die Einbindung eines Auftragsverarbeiters (Art. 28) ändert daran nichts.

2. "Wir haben einen DPA mit OpenAI/Anthropic/Microsoft, das reicht", der Auftragsverarbeitungsvertrag ist Pflicht, aber nur Bestandteil. Die Rechtsgrundlage (Art. 6), die Datenminimierung (Art. 5 Abs. 1 lit. c), der Auskunfts- und Löschanspruch (Art. 15-17) bleiben Ihre Pflicht.

3. "Der AI Act löst die DSGVO-Fragen", auch falsch. AI Act Art. 2 Abs. 7 stellt explizit klar: Die DSGVO bleibt unberührt. Wer Agentic AI in Production betreibt, hat zwei Pflichtenkataloge zu erfüllen, nicht einen.

Dieser Post übersetzt das in eine konkrete Prüfliste mit Artikel-Verweisen, das, was ein Datenschutzbeauftragter 2026 wirklich abfragt.

Die sieben kritischen DSGVO-Artikel für Agentic-AI in Production

1. Art. 6, Rechtsgrundlage

Was es verlangt: Jede Verarbeitung personenbezogener Daten braucht eine Rechtsgrundlage. Bei Agentic-AI typisch: Art. 6 Abs. 1 lit. b (Vertragserfüllung), lit. c (rechtliche Verpflichtung), lit. f (berechtigtes Interesse). Letzteres setzt eine dokumentierte Interessenabwägung voraus.

Wo es schiefgeht: "Wir trainieren das Modell mit Kundendaten, weil das halt notwendig ist", keine Interessenabwägung dokumentiert, kein Opt-Out-Mechanismus, kein Hinweis im Datenschutzhinweis. Das fällt im ersten Audit auf.

Was zu tun ist: Pro Use-Case eine schriftliche Rechtsgrundlage festhalten. Bei Art. 6 Abs. 1 lit. f zusätzlich die Interessenabwägung mit Kriterien (Zweck, Notwendigkeit, schutzwürdige Interessen der Betroffenen).

2. Art. 22, Automatisierte Einzelentscheidungen

Was es verlangt: Wenn der Agent eine Entscheidung trifft, die rechtliche Wirkung entfaltet oder die Person erheblich beeinträchtigt (z.B. Kreditprüfung, Bewerbung, Tarifeinstufung), greift Art. 22, Verbot mit Erlaubnisvorbehalt. Eine menschliche Überprüfung der finalen Entscheidung ist Pflicht.

Wo es schiefgeht: Agent automatisiert die ersten 95 Prozent eines Bewerbungsprozesses, der Mensch winkt nur noch durch. Das ist keine "menschliche Überprüfung" im Sinne von Art. 22 Abs. 3.

Was zu tun ist: Definieren, an welcher Stelle eine substanzielle menschliche Entscheidung stattfindet. Den Workflow so bauen, dass der Mensch tatsächlich die Möglichkeit hat, die Entscheidung umzukehren, und das im Audit-Log dokumentieren.

3. Art. 25, Privacy by Design and by Default

Was es verlangt: Datenschutz muss bereits beim Design des Systems berücksichtigt sein, nicht nachträglich angeflanscht. Voreinstellungen müssen datenschutzfreundlich sein.

Wo es schiefgeht: Der Agent loggt standardmäßig den vollen Prompt-Text inklusive Personendaten in CloudWatch, weil "wir das vielleicht später für Debugging brauchen". Privacy by Default verletzt.

Was zu tun ist: Logs strukturieren, Prompt-Hashes statt Klartext, oder PII-Redaction im Logging-Pipeline. Aufbewahrungsdauern definieren und automatisch durchsetzen.

4. Art. 28, Auftragsverarbeitung

Was es verlangt: Bei jedem externen LLM-Anbieter (OpenAI, Anthropic, Microsoft, Google) ist ein DPA (Data Processing Agreement) Pflicht. Bei Sub-Auftragsverarbeitern (z.B. Anthropic über AWS Bedrock) muss eine Subprozessor-Liste vorliegen.

Wo es schiefgeht: DPA mit OpenAI ist unterschrieben, aber niemand hat die Subprozessor-Liste geprüft. Wenn OpenAI auf Microsoft-Azure-Infrastruktur läuft, ist das ein Sub-Auftragsverarbeiter, Sie müssen wissen, welche.

Was zu tun ist: Pro LLM-Anbieter dokumentieren: DPA vorhanden (Datum), Subprozessor-Liste eingesehen (Datum), Verarbeitungszweck dokumentiert. Im Verzeichnis von Verarbeitungstätigkeiten (Art. 30) nachhalten.

5. Art. 32, Sicherheit der Verarbeitung

Was es verlangt: Geeignete technische und organisatorische Maßnahmen, um Risiken einzudämmen. Bei Agentic-AI heißt das konkret: Authentifizierung, Verschlüsselung, Zugriffskontrollen, Backup, Wiederherstellung, regelmäßige Tests.

Wo es schiefgeht: Der Agent-API-Key liegt in einer .env-Datei im Repo, wurde 18 Monate nicht rotiert, hat Admin-Rechte auf alle Endpoints. Ein Sicherheitsvorfall, und die Bußgeld-Relevanz steigt deutlich.

Was zu tun ist: Secrets-Management (z.B. Vault, AWS Secrets Manager), Key-Rotation-Policy, Least-Privilege-Berechtigungen pro Use-Case, dokumentierte Vorfall-Reaktion.

6. Art. 35, Datenschutz-Folgenabschätzung (DSFA)

Was es verlangt: Bei voraussichtlich hohem Risiko ist eine DSFA Pflicht. Bei generativer KI mit Personenbezug ist die Schwelle praktisch immer erreicht, die DSK-Liste der Verarbeitungstätigkeiten mit DSFA-Pflicht enthält explizit "Einsatz von Künstlicher Intelligenz".

Wo es schiefgeht: "Brauchen wir nicht, ist ja nur Vertrieb", die DSFA ist nicht use-case-abhängig, sondern risiko-abhängig. Vertriebs-AI mit personenbezogenen Lead-Daten = DSFA.

Was zu tun ist: DSFA pro AI-Use-Case durchziehen, typisch 1-3 Tage Aufwand mit DSB-Begleitung. Output: dokumentierte Risiken, Maßnahmen, Restrisiko-Bewertung.

7. Art. 44 ff, Drittlandtransfer

Was es verlangt: Bei Übermittlung in Drittländer (USA, UK, etc.) braucht es eine Rechtsgrundlage. Für USA seit Juli 2023 das EU-US Data Privacy Framework (DPF), sofern der Anbieter zertifiziert ist.

Wo es schiefgeht: OpenAI ist seit Februar 2024 DPF-zertifiziert, Anthropic auch, aber ältere Open-Source-Provider oder Spezial-LLMs nicht zwingend. Nicht prüfen heißt: kein gültiger Übermittlungsmechanismus, Verstoß gegen Art. 44.

Was zu tun ist: Pro LLM-Anbieter den DPF-Status auf der Data Privacy Framework List prüfen (Stand Mai 2026). Bei Nicht-Zertifizierung: Standard Contractual Clauses (SCC) plus Transfer Impact Assessment.

Die AI-Act-Schicht obendrauf

Art. 26, Pflichten der Deployer von Hochrisiko-KI

Wenn Ihr Agent in einen der Anhang-III-Bereiche fällt (Beschäftigung/HR, Bildung, kritische Infrastruktur, Strafverfolgung etc.), gelten zusätzlich die Deployer-Pflichten nach Art. 26: Anweisungen des Providers befolgen, menschliche Aufsicht sicherstellen, Eingabedaten überwachen, Logs aufbewahren (in der Regel sechs Monate, Art. 26 Abs. 6).

Art. 27, Fundamental Rights Impact Assessment (FRIA)

Für bestimmte Deployer von Hochrisiko-KI (öffentliche Stellen und Privat-Stellen, die öffentliche Dienste erbringen, sowie Banken und Versicherungen bei Bonitäts- und Risikoeinstufungen) verlangt Art. 27 eine FRIA, analog zur DSFA, aber mit Fokus auf Grundrechte (nicht nur Datenschutz).

Wichtig: FRIA ersetzt nicht die DSFA. Wer beide Voraussetzungen erfüllt, macht beides. In der Praxis lassen sich Teile zusammen erheben, aber das Output-Dokument ist getrennt zu führen.

Ein konkreter Audit-Trail-Vorschlag

Was ein DSB 2026 typisch in einem Audit sehen will:

1. Verzeichnis von Verarbeitungstätigkeiten (Art. 30) mit dem AI-Use-Case als eigenem Eintrag, Zwecke, Datenkategorien, Empfänger, Drittland-Übermittlungen, Löschfristen, technisch-organisatorische Maßnahmen.
2. DPA-Mappe pro LLM-Anbieter, DPA-Vertrag, Subprozessor-Liste, Datum letzter Prüfung.
3. DSFA-Dokument für den Use-Case, Risikoanalyse, Maßnahmen, Restrisiko-Bewertung. Bei Bedarf zusätzlich FRIA.
4. Logging-Konzept mit Aufbewahrungsdauern, was wird geloggt (Hash vs. Klartext), wo (welches System), wie lange, wer hat Zugriff.
5. Incident-Response-Plan für AI-spezifische Vorfälle, Halluzination mit Personenbezug, Datenleck via Prompt-Injection, fehlerhafte automatisierte Entscheidung.
6. Schulungsnachweise, KI-Kompetenz nach AI Act Art. 4 (siehe unseren KI-Kompetenz-Pflicht-Post) plus DSGVO-Schulung der beteiligten Engineers.

Wer diese sechs Bausteine hat und sie quartalsweise reviewt, hat 80 Prozent der typischen Audit-Fragen abgedeckt.

Zwei häufige Streitfragen

"Müssen wir personenbezogene Daten anonymisieren bevor sie ans LLM gehen?"

Nicht zwingend, aber oft sinnvoll. Anonymisierung (irreversibel) entzieht die Daten der DSGVO komplett. Pseudonymisierung (Art. 4 Nr. 5) bleibt unter DSGVO, reduziert aber das Risiko deutlich. Welcher Weg passt, hängt vom Use-Case ab, bei Vertrieb oft Pseudonymisierung mit Re-Identifikation am Ende, bei Analytics oft Anonymisierung.

"Reicht ein DPA, oder brauchen wir Standard Contractual Clauses?"

Ein DPA ist immer Pflicht. SCC werden zusätzlich relevant, wenn der Anbieter nicht DPF-zertifiziert ist, dann sind SCC plus Transfer Impact Assessment der Standardweg. DPF-zertifizierte US-Anbieter brauchen nur den DPA, kein zusätzliches SCC-Konstrukt.

Bottom Line

DSGVO und AI Act sind kein Entweder-Oder, sondern ein Sowohl-als-Auch. Wer Agentic-AI in Production betreibt, sollte den Audit-Trail aufbauen, bevor der DSB anruft, nicht danach. Die sechs Bausteine oben sind in 4-6 Wochen pro Use-Case machbar, wenn Engineering und Datenschutz-Verantwortliche von Anfang an zusammenarbeiten.

Welcher der sieben DSGVO-Artikel ist bei euch 2026 die größte Baustelle, und habt ihr DSFA + FRIA bereits getrennt, oder noch in einem Dokument vermischt?