KI-Agents haben Ihre DSGVO-Artikel-32-Compliance ausgehebelt

Sechzig Prozent der deutschen Unternehmen nennen die unautorisierte Weitergabe von Daten durch Partner und Lieferanten als zentrales Compliance-Risiko – so der Kiteworks 2026 Data Security and Compliance Risk Forecast Report. Der weltweite Durchschnitt liegt bei 31 %. Die deutsche Zahl ist kein kulturelles Artefakt. Sie ist das vorhersehbare Ergebnis eines Jahrzehnts der Durchsetzung, das Datenschutzbeauftragten, Compliance-Verantwortlichen und CISOs in der DACH-Region eine schmerzhafte Lektion beigebracht hat: Nach Artikel 82 der DSGVO haften Sie für das, was der nachgelagerte Verantwortliche oder Auftragsverarbeiter mit den personenbezogenen Daten macht, die Sie ihm übergeben haben – unabhängig davon, ob Sie die Infrastruktur noch kontrollieren.

Wichtige Erkenntnisse

1. Der nachgelagerte Akteur ist kein menschlicher Verarbeiter mehr. Artikel 32 der DSGVO wurde unter der Annahme von Servicekonten und beauftragten Partnern formuliert. Ist der nachgelagerte Akteur jedoch ein autonomer Agent, der Tool-Calls über verschiedene Rechtsräume hinweg verknüpft, muss sich das Kontroll-Set ändern.
2. Deutsche Unternehmen erkennen das Problem bereits. Sechzig Prozent nennen die unautorisierte Weitergabe von Daten als zentrales Risiko – fast doppelt so viele wie im globalen Durchschnitt. Ein Jahrzehnt DSGVO-Durchsetzung hat die Haftung für nachgelagerte Datennutzung konkret und nicht nur theoretisch gemacht.
3. Vier Regulierungsregime setzen auf dieselbe Architektur. DSGVO Artikel 32, NIS 2, der EU AI Act und DORA verlangen jeweils nachweisbare, Echtzeit-Belege darüber, wo regulierte Daten liegen, wer darauf zugegriffen hat und unter welcher Richtlinie – menschlich oder maschinell.
4. Modellbasierte Guardrails sind keine Sicherheitskontrollen. Wissenschaftliche Studien belegen Erfolgsquoten von Prompt-Injection-Angriffen von über 86 % bei realen LLM-Integrationen. Sicherheitstrainings ersetzen keine authentifizierte Identität, attributbasierte Autorisierung und manipulationssichere Prüfprotokolle.
5. Governance auf Datenebene ist die nachhaltige Antwort. Kontrollen, die an den Daten selbst verankert sind – ABAC, FIPS-validierte Verschlüsselung, Schlüsselaufbewahrung im Rechtsraum, Echtzeit-SIEM-Streaming – überstehen Prompt-Injection, Agentenkompromittierung und die nächste unbekannte Schwachstellenklasse.

Diese Lektion wurde gelernt, als der nachgelagerte Akteur noch ein Mensch war – ein Mitarbeiter eines Dienstleisters, ein Servicekonto, ein beauftragter Verarbeiter mit klar umrissenem Aufgabenbereich. Die Frage, die sich jede deutsche Sicherheits- und Compliance-Führungskraft 2026 stellen muss, lautet: Sind die vor drei Jahren dokumentierten „geeigneten technischen und organisatorischen Maßnahmen“ für Artikel 32 noch angemessen, wenn der nachgelagerte Akteur ein autonomer KI-Agent ist, der mehrstufige Workflows über drei Rechtsräume hinweg in einer einzigen Transaktion ausführt? In den meisten Fällen lautet die ehrliche Antwort: nein.

Das Kontroll-Set von Artikel 32 wurde 2016 entworfen. Es ging von menschlichen Nutzern, Servicekonten und klar abgegrenzten Anwendungen aus. Es berücksichtigte nicht, dass ein Modell durch Prompt Injection Daten exfiltrieren könnte, die weder auf Anwendungsebene protokolliert, noch auf Netzwerkebene erkannt oder vom Endpoint-Agenten beobachtet wurden. Die regulatorische Sprache hat sich nicht geändert, aber die darunterliegende Bedrohungslandschaft schon.

Der Vier-Regime-Regulierungsstack, der 2026 prägt

Vier parallel geltende Regulierungsregime stellen heute unterschiedliche technische Anforderungen an dieselben Datenflüsse, die zunehmend von KI-Agenten vermittelt werden. Zu verstehen, wie sie sich überlagern, ist der Ausgangspunkt für jede verteidigungsfähige Compliance-Strategie 2026.

DSGVO Artikel 32 fordert Verschlüsselung auf dem Stand der Technik, Pseudonymisierung und die Fähigkeit, Verfügbarkeit und Zugang zu personenbezogenen Daten nach einem Vorfall wiederherzustellen. Der Artikel ist prinzipienbasiert, das heißt, Aufsichtsbehörden interpretieren „Stand der Technik“ immer im Kontext der aktuellen Bedrohungslage – nicht der von 2016.

Die NIS 2-Richtlinie, in Deutschland umgesetzt durch das
NIS-2-Umsetzungsgesetz, erweitert den Kreis der wesentlichen und wichtigen Einrichtungen erheblich und führt persönliche Haftung für Leitungsorgane ein, die keine Risikomanagement-Maßnahmen umsetzen. Die ENISA Technical Implementation Guidance vom Juni 2025 macht die Nachweispflichten explizit: Verschlüsselungsrichtlinien, Audit-Logs, Kryptografie-Governance und Integritätsprüfungen von Backups gelten als nachweispflichtige Kontrollen, die jederzeit belegt werden müssen.

Der EU AI Act legt weitere Pflichten obenauf. Die allgemeinen KI-Pflichten gelten seit August 2025; die High-Risk-Vorgaben sind ab August 2026 vollumfänglich durchsetzbar. Laut Kiteworks Forecast sehen 40 % der europäischen Befragten die Pflichten aus dem EU AI Act als direktes Risiko.

DORA gilt seit Januar 2025 für EU-Finanzinstitute und verlangt ICT-Risikomanagement, Vorfallmeldungen und Resilienztests für Drittparteien. Betroffen sind Banken, Versicherer, Investmentfirmen und deren kritische ICT-Dienstleister – zu denen heute regelmäßig auch die Anbieter ihrer KI-Stacks zählen.

Kein einzelnes Kontroll-Set erfüllt alle vier Regime für sich genommen. Aber die zugrundeliegende Architekturfrage, auf die sie hinauslaufen, ist dieselbe: Können Sie im Audit-Tempo nachweisen, wo regulierte Daten liegen, wie darauf zugegriffen wurde, durch welche Identitäten – menschlich oder maschinell – und unter welcher Richtlinie?

Wo Artikel 32 in einer Agenten-Umgebung versagt

Das klassische Implementierungsmuster von Artikel 32 bricht an drei konkreten Stellen, wenn KI-Agenten ins Spiel kommen.

Erstens: Identität. Ein KI-Agent, der eine interne Retrieval-Augmented-Generation-Pipeline aufruft, authentifiziert sich nicht wie ein menschlicher Nutzer. Falls überhaupt, dann meist über ein Servicekonto oder ein weitreichendes API-Token mit dauerhaften Berechtigungen. Die ENISA-NIS-2-Guidance und der
BSI IT-Grundschutz betonen beide das Prinzip des geringsten Privilegs und Identitätsföderation – Konzepte, die eine klar abgegrenzte Identität mit definiertem Zweck voraussetzen. Ein nicht-menschlicher Akteur, der in einer einzigen Prompt-gesteuerten Sitzung 17 Tools über vier Systeme hinweg aufrufen kann, passt nicht ins Modell. OAuth 2.0 mit gezielt vergebenen Refresh Tokens, gebunden an den jeweiligen menschlichen Autorisierer, der den Workflow delegiert hat, ist keine optionale Architektur – sondern Voraussetzung dafür, dass die „autorisierte Personen“-Formulierung von Artikel 32 überhaupt Sinn ergibt, wenn die „Person“ Code ist.

Zweitens: Autorisierungsgranularität. Rollenbasierte Zugriffskontrolle entscheidet, ob ein Principal einen Ordner lesen darf. Sie entscheidet nicht, ob dieser Principal – im Auftrag eines bestimmten Menschen, in einem bestimmten Kontext, für einen bestimmten Zweck – ein spezifisches Dokument mit bestimmter Sensitivität lesen darf. Attributbasierte Zugriffskontrolle (ABAC) tut das. Eine ABAC-Policy-Engine, die jede Anfrage gegen Agentenidentität, Datenklassifizierung (idealerweise durch Microsoft Purview oder MIP-Sensitivitätslabels), Anfragekontext und deklarierten Zweck prüft, ist die einzige Kontrollschicht, die der Zahl KI-basierter Zugriffsentscheidungen eines modernen Unternehmens 2026 und 2027 gerecht wird.

Drittens: Nachweisbarkeit. Ein manipulationssicherer Audit-Trail, der festhält, wer (Agent plus menschlicher Autorisierer), was (Operation plus Datenobjekt), wann (Zeitstempel auf die Millisekunde), wo (Quell- und Zielregion) und warum (Policy-Kontext und Klassifizierung), ist das Artefakt, das Aufsichtsbehörden, Datenschutzbehörden und NIS-2-Kompetenzstellen tatsächlich einfordern. Der Kiteworks Forecast zeigt: Governance-Kontrollen – Monitoring, Logging, Policy-Definition – liegen 15 bis 20 Prozentpunkte vor Containment-Kontrollen wie Agenten-Scope, Kill Switches oder Netzwerkisolation. Deutsche Unternehmen haben in Logging investiert. Die Lücke liegt in der Durchsetzung: in der Fähigkeit, auf Erkenntnisse aus den Logs zu reagieren, bevor die Daten weg sind.

Warum modellbasierte Guardrails keine Sicherheitskontrollen sind

Der häufigste Fehler in KI-Datengovernance-Programmen im DACH-Raum ist, modellbasierte Guardrails als Sicherheitsgrenze zu behandeln. Content-Filter, System-Prompts, Alignment-Trainings und Safety-Fine-Tuning helfen, Missbrauch zu reduzieren. Aber keine davon ist eine Sicherheitskontrolle im Sinne der Aufsichtsbehörden.

Die wissenschaftliche Evidenz ist eindeutig. Eine vielzitierte Studie zu 36 realen LLM-Integrationen fand 31 – 86,1 % – anfällig für
Prompt Injection. Eine 2026 auf dem IEEE Symposium on Security and Privacy vorgestellte Studie analysierte 17 Drittanbieter-Chatbot-Plugins auf über 10.000 öffentlichen Websites und stellte fest, dass 15 indirekte Prompt Injection ermöglichen, weil sie vertrauenswürdige und nicht-vertrauenswürdige Inhalte nicht unterscheiden. Der
CrowdStrike 2026 Global Threat Report dokumentiert einen Anstieg KI-gestützter Angriffe um 89 % im Jahresvergleich, wobei 82 % der Erkennungen inzwischen ohne Malware erfolgen.

Übersetzt in die Sprache von Artikel 32: Das Modell kann sich nicht selbst schützen. Sicherheitstraining ist keine Zugriffskontrolle. Alignment ist keine Authentifizierung. Ein Angreifer, der eine Prompt Injection an den Guardrails des Modells vorbeischleust, hat keinen Randfall ausgenutzt – sondern die primäre Angriffsfläche jeder RAG-Pipeline, jedes agentengesteuerten Workflows und jedes KI-Assistenten im Unternehmen.

Das ist relevant, weil NIS-2-Kompetenzstellen, deutsche Datenschutzbehörden und Marktaufsichtsbehörden für den AI Act „wir haben die Standard-Safety-Einstellungen des Herstellers implementiert“ nicht als Nachweis für angemessene technische Maßnahmen akzeptieren werden. Sie werden fragen, welche unabhängigen Kontrollen bestanden, als – nicht falls – die Guardrails umgangen wurden.

Der Architekturwechsel: Governance auf Datenebene

Die architektonische Konsequenz: Sicherheitskontrollen am Netzwerk-Perimeter, Endpoint oder sogar auf Anwendungsebene reichen für KI-gestützte Datenflüsse nicht mehr aus. Sie waren ausreichend, als Anwendungen die Endpunkte waren. Sie reichen nicht mehr, wenn das Modell der Endpunkt ist, der prompt-injiziert werden kann, Tool-Calls verkettet und Daten über Kanäle exfiltriert, die Endpoint-Agents nie sehen.

Was funktioniert, ist eine Kontroll-Ebene auf Datenebene selbst – dort, wo jede Anfrage, unabhängig von Absender, gegen einheitliche Checkpoints geprüft wird, bevor Daten bewegt werden.

Authentifizierte Identität, via OAuth 2.0 an einen menschlichen Autorisierer gebunden, mit gezielten Refresh Tokens, die Agenten-Sessions an delegierte menschliche Entscheidungen koppeln. Keine anonymen KI-Agenten. Keine dauerhaften Service-Account-Zugriffe auf regulierte Repositorys.

Echtzeit-ABAC-Prüfung gegen Agentenidentität, Datenklassifizierung und Anfragekontext. Dieselbe Policy-Logik, die das Unternehmen bereits für menschliche Nutzer anwendet, erweitert auf Maschinenakteure – aber auf Dokumenten- statt Ordnerebene.

FIPS 140-3 Level 1 validierte Verschlüsselung für Daten während der Übertragung und AES 256 Verschlüsselung im ruhenden Zustand, mit Schlüsselaufbewahrung im eigenen Rechtsraum – eine Anforderung, die deutsche Datenschutzbehörden nach Schrems II immer wieder betonen und die laut Data Forms Survey Report 2025 von 58 % der deutschen Befragten als kritisch eingestuft wird.

Manipulationssicheres Audit-Streaming in Echtzeit ins SIEM – ohne Drosselung, ohne Verzögerung. Wenn der nächste Vorfall passiert, sollte die Rekonstruktion, welche Daten wann wohin bewegt wurden, eine Reporting-Abfrage sein, keine forensische Untersuchung.

Gehärtete Deployment-Oberfläche. Eine Defense-in-Depth gehärtete virtuelle Appliance mit eingebettetem WAF, IDPS und automatisierten Härtungsregeln – das Architektur-Muster, das es Kunden ermöglichte, Branchen-CVSS-10-Schwachstellen wie Log4Shell als interne CVSS-4-Vorfälle zu erleben, weil die Datenebenen-Kontrollen auch dann griffen, wenn die Anwendungsebene kompromittiert war.

Der Kiteworks-Ansatz: Architektur statt Absichtserklärung

Kiteworks wurde von Grund auf als Governance-Plattform auf Datenebene entwickelt – genau für die regulierten Datenflüsse, die heute von KI-Agenten vermittelt werden. Das Architektur-Muster bleibt gleich, egal ob der anfragende Akteur ein menschlicher Nutzer, ein Servicekonto, ein Claude- oder Copilot-basierter Assistent über den Secure MCP Server oder eine produktive RAG-Pipeline ist, die Unternehmensinhalte über das AI Data Gateway abruft.

Jede Zugriffsanfrage durchläuft vier Governance-Checkpoints: Authentifizierte Identität via OAuth 2.0, verknüpft mit dem menschlichen Autorisierer, der den Workflow delegiert hat; Echtzeit-ABAC-Prüfung gegen Agentenidentität, Datenklassifizierung und Kontext über die Kiteworks Data Policy Engine; FIPS 140-3 Level 1 validierte Verschlüsselung für Daten während der Übertragung und AES 256 Verschlüsselung im ruhenden Zustand mit Schlüsselaufbewahrung im eigenen Rechtsraum; und ein manipulationssicherer Audit-Trail, der in Echtzeit über den Real-time SIEM Feed ins SIEM des Kunden gestreamt wird. Die Kontrollen greifen auf Datenebene, nicht auf Modellebene – Prompt Injection, kompromittierte Agenten und unbekannte künftige Schwachstellenklassen können sie also nicht durch Angriffe auf die KI umgehen.

Die gleiche Plattform liefert auf Abruf Framework-spezifische Compliance-Nachweise. Vorgefertigte Compliance-Berichte decken DSGVO-Compliance, HIPAA, CMMC 2.0-Compliance, Insider- und Outsider-Threats ab. Die Interactive Audit Log Map ermöglicht es Compliance-Verantwortlichen, Audit-Events geografisch zu visualisieren – was für NIS2-Compliance-Incident-Reporting und jede grenzüberschreitende Transferanfrage einer Datenschutzbehörde direkt relevant ist. Die Architektur ist keine Absichtserklärung – sie ist genau die, mit der Kiteworks-Kunden Log4Shell als internes Ereignis eindämmen konnten, während der Rest der Branche noch aufbaute.

Was deutsche Unternehmen 2026 tun müssen

Für CISOs, DPOs und NIS-2-Programmverantwortliche, die dieses Jahr ihre technischen und organisatorischen Maßnahmen neu bewerten, gliedert sich die Mindestarchitektur für KI-gestützte Datengovernance in fünf konkrete Schritte.

Erstens: Authentifizieren Sie jeden KI-Agenten und jeden automatisierten Workflow via OAuth 2.0 mit einem Refresh-Token-Modell, das die Agenten-Session an einen identifizierten menschlichen Autorisierer bindet. Keine geteilten Servicekonten mit dauerhaften API-Tokens für den Zugriff auf regulierte Repositorys. Wenn Sie die Frage „Welcher Mensch hat diesem Agenten gerade Zugriff auf diese Daten gewährt?“ nicht beantworten können, können Sie Ihre Artikel-32-Position nicht verteidigen.

Zweitens: Prüfen Sie jede Datenzugriffsanfrage durch eine ABAC-Policy-Engine, die Sensitivitätslabels – Microsoft Purview, MIP oder Äquivalente – verarbeitet und zweckgebundene Entscheidungen auf Dokumentenebene erzwingt, nicht auf Ordnerebene. Rollenbasierte Kontrollen reichten, als Nutzer Jobs hatten und Jobs Datenzugriff implizierten. Agenten haben Sessions, keine Jobs.

Drittens: Verschlüsseln Sie alle ruhenden Daten mit AES 256 und bewahren Sie die Schlüssel in einem kundengesteuerten HSM oder einer gleichwertigen Schlüsselverwahrung innerhalb des Verarbeitungsrechtsraums auf. Für Bundes-, Verteidigungs- oder Kritische-Infrastruktur-Bereiche: FIPS 140-3 Level 1 validierte Verschlüsselungsmodule sind Pflicht. Nach Schrems II gilt: „Der Cloud-Anbieter verschlüsselt“ ist nicht gleichbedeutend mit „Verschlüsselungsschlüssel dürfen unseren Rechtsraum nicht verlassen“.

Viertens: Erzeugen Sie für jede Interaktion – Agent oder Mensch – manipulationssichere Audit-Records, die in Echtzeit mit ausreichend Metadaten zur vollständigen Datenherkunft ins SIEM gestreamt werden. Der Kiteworks Forecast zeigt: Nur 43 % der Unternehmen verfügen heute über ein zentrales AI Data Gateway. Diese Lücke zu schließen, trennt Unternehmen, die eine DPA-Anfrage in Stunden beantworten können, von denen, die Wochen brauchen.

Fünftens: Implementieren und testen Sie Containment-Kontrollen. Die Fähigkeit, einen fehlverhaltenden Agenten zu beenden, eine delegierte Session zu widerrufen und einen kompromittierten Workflow zu isolieren, wird meist übersprungen, weil sie operativ anspruchsvoller ist als Logging. Der Kiteworks Forecast zeigt: 60 % der Unternehmen können derzeit keinen fehlverhaltenden Agenten beenden, 63 % können keine Zweckbindung durchsetzen und 55 % keine laterale Bewegung verhindern. Diese Zahlen stehen ganz oben auf der Liste für die nächste NIS-2-Prüfung.

Unternehmen, die 2026 diese fünf Punkte umsetzen, werden – entgegen der Intuition – schneller KI einführen als Wettbewerber in weniger regulierten Märkten. Denn ihre Kontrollen halten, wenn die erste große europäische Durchsetzungsmaßnahme wegen eines KI-getriebenen Datenschutzvorfalls kommt.