Executive Summary

TOM-Dokumentationen (Art. 32 DSGVO) sind veraltet, weil sie zwischen 2018–2022 entstanden und nicht auf autonome KI‑Agenten, Prompt‑Injection‑Risiken oder dynamische Modelle ausgelegt sind.
Art. 32 basiert auf einem Akteursmodell, das nicht mehr existiert: DSGVO setzt vorhersehbare, zweckgebundene menschliche oder systemische Akteure voraus – KI‑Agenten brechen diese Logik.
Drei neue technische Anforderungen werden notwendig:
1. Authentifizierung gegen den menschlichen Nutzer, nicht gegen Agent‑Identitäten
2. Attributbasierte Zugriffskontrolle (ABAC) statt rein rollenbasiert
3. Manipulationssichere Audit‑Trails unterhalb der Modell‑/Runtime‑Schicht.
Fehlende AI‑Governance ist ein systemisches Risiko: 63 % können Zweckbindung für KI‑Agenten nicht durchsetzen, 60 % können fehlverhaltende Agenten nicht terminieren, nur 43 % besitzen zentrale AI‑Governance.
Die zweite Dekade der DSGVO prüft die Architektur, nicht die Dokumente: Unternehmen müssen ihre technischen Grundlagen modernisieren, bevor Aufsichtsbehörden dies erzwingen.

Die Datenschutzgrundverordnung feiert ihren 10. Geburtstag. Am 25. Mai 2016 trat sie in Kraft, zwei Jahre später kam sie verbindlich zur Anwendung. Aus deutscher Sicht ist sie eine Erfolgsgeschichte, allerdings mit einer aktuellen Einschränkung.

Viele Maßnahmen zur Einhaltung des Datenschutzes für Unternehmen und Behörden sind etabliert: Die Verzeichnisse von Verarbeitungstätigkeiten nach Art. 30 sind Standard, Datenschutz-Folgenabschätzungen nach Art. 35 gehören zum Projektalltag und Meldeprozesse nach Art. 33 funktionieren in den meisten Konzernen reibungslos. Die besagte Einschränkung: Die technisch-organisatorischen Maßnahmen (TOM) nach Art. 32 – die sogenannte TOM-Dokumentation, die fast jede deutsche Organisation in irgendeiner Form pflegt – wurden überwiegend zwischen 2018 und 2022 verfasst. Die meisten dieser Dokumente sind handwerklich solide, aber es ist davon auszugehen, dass sie die nächste Prüfung nicht bestehen.

Der Grund liegt nicht in der Verordnung selbst, sondern darin, dass Art. 32 DSGVO mit einem Akteursmodell formuliert wurde, das mit dem breiten Einzug von künstlicher Intelligenz vor anderthalb Jahren eigentlich aufgehört hat zu existieren.

Art. 32 setzt Akteure mit gebundenem Verhalten voraus

Art. 32 der DSGVO verlangt unter Berücksichtigung des Stands der Technik, der Implementierungskosten, der Art und des Umfangs der Verarbeitung die Umsetzung »geeigneter technischer und organisatorischer Maßnahmen«. Genannt werden beispielsweise Pseudonymisierung und Verschlüsselung (Abs. 1 lit. a), die Sicherstellung von Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme (lit. b), die Wiederherstellung nach einem Zwischenfall (lit. c) sowie ein Verfahren zur regelmäßigen Überprüfung der Wirksamkeit (lit. d).

Alles an diesem Text setzt voraus, dass die Akteure, die auf personenbezogene Daten zugreifen, sich vorhersehbar und mit dokumentierter Zweckbindung verhalten. Sprich, Menschen mit benannter Rolle, Service-Accounts mit definierten Aufgaben oder Anwendungen mit klaren Funktionen. Auf dieser Basis lassen sich TOMs entwerfen und ihre Wirksamkeit regelmäßig überprüfen – weil die Akteure das tun, was die Architektur erlaubt, und sie nicht versuchen, sie zu umgehen.

Doch diese Voraussetzung gilt für autonome KI-Agenten nicht mehr. Ein Agent, der durch Prompt Injection manipuliert wurde, hält sich nicht an die Zweckbindung der Sitzung, in der er läuft. Eine RAG-Pipeline, die mehr Kontext aus dem Vektorspeicher zieht, als der Prompt erfordert, verletzt die Datenminimierung, ohne dass eine Policy-Verletzung dokumentiert wird. Ein Modell, das auf personenbezogenen Daten feinjustiert wurde, kann diese Daten in Antworten reproduzieren, ohne dass der nachgelagerte Verantwortliche merkt, wann das passiert. Die TOM-Dokumentation aus 2018 hat für all dies kein Vokabular.

Das muss eine architektonisch belastbare Art. 32-Implementierung heute leisten

Es ergeben sich drei konkrete Anforderungen, wenn man Art. 32 im Licht der KI-Realität von 2026 liest. Alle drei lassen sich technisch präzise formulieren und sind unterhalb der Modell- und Runtime-Schicht zu implementieren – denn alles, was oberhalb der Datenebene liegt, kann aktualisiert, ersetzt oder durch Prompt Injection beeinflusst werden. Das hat die Folge, dass der Nachweis verschwindet.

Authentifizierung gegen den menschlichen Nutzer, nicht gegen die Agent-Identität

Jede Software-Development-Kit-Operation (SDK) eines KI-Agenten mit personenbezogenen Daten muss an eine OAuth-2.0-Sitzung mit benannter natürlicher Person gebunden sein – nicht an einen Service-Account, dessen Berechtigungen »im Namen« eines unbekannten Nutzers ausgeübt werden. Ein durch Prompt Injection manipulierter Agent kann keine Daten entnehmen, die er ohne menschliches Mandat nie erreichen dürfte. Das ist die Art. 32-konforme Übersetzung des Konzepts »autorisiertes Personal« in die KI-Welt.

Autorisierung über attributbasierte Richtlinien (ABAC) statt rein rollenbasierter (RBAC) Modelle

Rollen entscheiden, ob ein Principal grundsätzlich auf einen Ordner zugreifen darf. Attribute – Klassifizierung des Dokuments, deklarierter Zweck der Sitzung, Jurisdiktion des Nutzers, Konsens der betroffenen Person – entscheiden, ob dieser Akteur auf dieses spezifische Dokument in diesem exakten Moment zugreifen darf. Das ist die operative Form, in der Art. 5 Abs. 1 lit. b («Zweckbindung«) und Art. 25 («Datenschutz durch Technikgestaltung«) in der KI-Welt durchsetzbar werden.

Manipulationssichere Audit-Trails, die das Modell überleben

Modelle werden zurückgezogen, ersetzt, neu trainiert. Wenn das Audit-Log auf der Modell- oder Runtime-Schicht liegt, verschwindet die Beweisgrundlage mit dem Modell. Art. 5 Abs. 2 der DSGVO verlangt aber genau diesen Beweis: Der Verantwortliche muss die Einhaltung »nachweisen können« – auch drei Jahre später, wenn die ursprünglich beauftragte Verarbeitung längst durch andere Modelle ersetzt wurde. Eine Protokollierung, die Manipulation (Tamper-evident Logging) direkt an der Datenebene erkennt, löst dieses Problem.

Die Architektur kommt auf den Prüfstand, nicht die Policy

Die erste Dekade der DSGVO hat deutsche Organisationen gelehrt, TOM-Dokumente zu schreiben. Die zweite wird zum Test, ob die Architektur auch einlöst, was die Dokumente versprechen. Aktuelle Zahlen zeigen hier Handlungsbedarf: Laut einem aktuellen Report können 63 Prozent der Organisationen Zweckbeschränkungen für KI-Agenten nicht durchsetzen und 60 Prozent einen sich fehlverhaltenden Agenten nicht zeitnah terminieren [1]. 55 Prozent sehen sich nicht imstande, KI-Systeme vom übrigen Netzwerkzugang zu isolieren. Nur 43 Prozent verfügen heute über eine zentralisierte AI-Governance-Schicht, ohne die die obigen Anforderungen architektonisch gar nicht prüfbar sind.

Jede dieser Lücken wird in einer DSGVO-Prüfung zu einer Feststellung nach Art. 32 – sofern der Prüfer die richtigen Fragen stellt, was bei den Aufsichtsbehörden zunehmend zu beobachten ist. Deshalb gilt: Es ist Zeit, die TOMs zu aktualisieren, bevor eine Aufsichtsbehörde es für die Unternehmen übernimmt.

Marc ten Eikelder, Head of EMEA Marketing und Sr. Director of Industry Research bei Kiteworks

[1] Kiteworks Data Security and Compliance Risk: 2026 Forecast Report: https://www.kiteworks.com/cybersecurity-risk-management/2026-data-security-forecast-ai-governance-predictions/

2406 Artikel zu „DSGVO“

News | Business | IT-Security | Kommunikation | Lösungen

Automatisch, sicher, DSGVO-konform: So lösen IT-Admins das Problem der Kontaktsynchronisation auf Diensthandys!

15. Mai 2026

Abbildung 1 Bildquelle: magnific In vielen Unternehmen liegen die nativen Kontakte-Apps auf Diensthandys brach. Mitarbeitende verlieren daher Zeit mit der Suche nach Kontaktinformationen in Outlook, Intranet- oder Excel-Listen. Für IT-Verantwortliche ist das jedoch mehr als ein Komfortproblem – es ist ein Risiko für Governance und Security. Die »Mobile Gap«: Das unsichtbare Effizienz-Leck Fehlende Kontaktsynchronisation…