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?