KI-Agenten unter DSGVO und AI Act: Wenn die Software entscheidet und handelt, wer ist verantwortlich?

KERNTHESE Ein KI-Agent verarbeitet nicht bloß personenbezogene Daten — er nimmt wahr, plant und handelt, ruft Werkzeuge auf und erreicht Systeme, die niemand im Voraus aufgeführt hat. Diese Autonomie ändert nichts daran, wer verantwortlich ist: Der Agent ist ein technisches Mittel, und die einsetzende Organisation bleibt der Verantwortliche für — oder zumindest rechenschaftspflichtig für — das, was der Agent in ihrem Namen tut. Was sie ändert, ist, wo die Compliance leben muss. Zweckbindung, Art. 22 und Werkzeugzugriff nach dem Least-Privilege-Prinzip können nicht länger in einem vor dem Start unterzeichneten Dokument sitzen; sie müssen zur Laufzeit durchgesetzt werden, weil der Agent seinen eigenen Plan mitten in der Aufgabe umschreibt. Die entscheidende Frage lautet nicht länger „welche Daten haben wir verarbeitet?”, sondern „als der Agent handelte, wer entschied — und wer kann ihn zurückholen?”

Ein Chatbot beantwortet eine Frage und hört auf. Einem Agenten wird ein Ziel gegeben, und er hört nicht auf — er liest die Vorgabe, entwirft einen Plan, zieht Daten über APIs, ruft ein Werkzeug auf, prüft das Ergebnis, ändert den Kurs, wenn ein Schritt scheitert, und schließt die Schleife. Der Unterschied ist keine Frage des Grades. Ein universell einsetzbares Modell ist etwas, das man abfragt; ein Agent ist etwas, an das man delegiert. Und in dem Moment, in dem eine Organisation ein Ziel an ein autonomes System delegiert, das personenbezogene Daten berührt, hat sie eine Compliance-Situation geschaffen, die die für gewöhnliche Software gebauten Verträge, Bewertungen und Kontrollen nicht abdecken.

Betrachten Sie einen konkreten Fall der Art, die nun in Kundensupport-, Finanz- und HR-Funktionen auftaucht. Eine Organisation setzt einen Agenten ein, um ein Postfach zu sichten, Antworten zu entwerfen und einen Kalender zu verwalten. Eine Nutzerin tippt eine einzige Anweisung: „Vereinbare einen Folgetermin mit Dr. Rossi in der Woche des 14. Oktober.” Harmlos. Aber um sie zu erfüllen, zieht der Agent jüngste E-Mail-Threads zum Kontext, prüft Kalender, kontrolliert die Reisezeit über eine Maps-API, lädt die letzte Nachricht des Arztes zu einem Drittanbieter-Zusammenfasser hoch, um vorgeschlagene Termine zu extrahieren, lässt eine italienische Phrase durch einen außerhalb des EWR gehosteten Übersetzungsdienst laufen und speichert eine abgeleitete Notiz für das nächste Mal.¹ In einem Satz Nutzerabsicht hat der Agent eine Kette von Verarbeitungen über mindestens drei externe Dienste hinweg durchgeführt — mindestens einer davon eine Drittlandübermittlung — von denen keiner in der Vorgabe auftauchte und ganz möglicherweise keiner in der Datenschutz-Folgenabschätzung der Organisation.

Dies ist die strukturelle Tatsache, die Agenten anders macht. Bei einem Prompt entscheiden Sie, was Sie senden. Bei einem Agenten entscheiden Sie das Ziel, und der Agent bestimmt die Schritte — einschließlich, innerhalb seiner konfigurierten Berechtigungen, auf welche personenbezogenen Daten er zugreift und welche Werkzeuge er aufruft. Die Frage, die dieser Artikel beantwortet, ist die unmittelbar folgende: Als der Agent handelte, wer entschied, und wer kann ihn zurückholen? Alles, was unter sowohl der DSGVO als auch dem AI Act zählt, ergibt sich daraus, wie ernst eine Organisation diese Frage nimmt, bevor sie einem Agenten die Autonomie zu handeln gewährt.

Der Agent ist kein rechtlicher Akteur — Sie sind es

Der erste Instinkt, wenn ein System autonom handelt, ist, seine Autonomie als eine Übertragung von Verantwortung zu behandeln: Der Agent entschied, also ist der Agent verantwortlich. Dieser Instinkt ist falsch, und die spanische Aufsichtsbehörde (AEPD) räumt in der detailliertesten bisher veröffentlichten aufsichtsrechtlichen Orientierungshilfe zu agentischer KI jeden Zweifel daran aus. Ein KI-Agent ist ein technisches Mittel, durch das die Verarbeitung ausgeführt wird — kein autonomer rechtlicher Akteur.² Autonomie auf der technischen Ebene ändert nichts an der rechtlichen Qualifizierung der Verarbeitung oder der Verteilung der Verantwortung zwischen Verantwortlichen, gemeinsam Verantwortlichen und Auftragsverarbeitern. Die AEPD formuliert die Unterscheidung präzise: Die Linie, auf die es ankommt, verläuft zwischen Ausführung und Verantwortung. Der Agent führt aus; die Organisation, die ihn einsetzt und seine Zwecke und wesentlichen Mittel bestimmt, bleibt der Verantwortliche für alles, was er tut.³

Das klingt beruhigend, bis sein volles Gewicht landet. Es bedeutet, dass jeder API-Aufruf, den der Agent aus eigener Initiative tätigt, jedes Drittanbieter-Werkzeug, das er aufzurufen beschließt, jedes Stück personenbezogener Daten, das er in den Kontext zu ziehen wählt, rechtlich die Verarbeitung des Verantwortlichen ist, dem Verantwortlichen zurechenbar, durch die Pflichten des Verantwortlichen geregelt. Die Autonomie des Agenten schafft keinen Puffer der Abstreitbarkeit. Sie schafft eine Spanne von Verarbeitung, für die der Verantwortliche einzustehen hat, die er aber nicht einzeln autorisiert hat. „Das System hat es getan” ist keine Verteidigung; es ist ein Geständnis, dass der Verantwortliche einen autonomen Auftragsverarbeiter ohne angemessene Kontrolle darüber eingesetzt hat, was er tun würde.

Die Rollenzuordnung wird verwickelter, nicht weniger. Die AEPD merkt an, dass die einsetzende Organisation typischerweise der Verantwortliche ist, während der externe LLM-Anbieter, die Workflow-Automatisierungsplattform und der Cloud-Speicher-Dienst Auftragsverarbeiter sein können — oder, in manchen Konfigurationen, eigenständige Verantwortliche für sich.⁴ Jeder muss identifiziert werden, und mit jedem muss ein Auftragsverarbeitungsvertrag vorliegen. Die gefestigte Position des EDSA gilt hier mit voller Kraft: Die Rollenverteilung ist funktional, bestimmt dadurch, wer tatsächlich Zwecke und Mittel entscheidet, nicht durch das, was ein Vertragsetikett sagt.⁵ Ein Agent, der stillschweigend ein neues Werkzeug erreicht, hat in diesem Augenblick die Verarbeitungskette des Verantwortlichen auf eine Partei ausgedehnt, mit der möglicherweise überhaupt kein Vertrag vorliegt.

Art. 22 und der AI Act: wann eine Handlung zu einer Entscheidung wird

Die tiefste Verschiebung, die Agenten einführen, ist, dass sie nicht nur verarbeiten — sie entscheiden und handeln. Das verschiebt die Analyse aus der reinen Datenhandhabung in das Gebiet der automatisierten Entscheidungsfindung, wo die DSGVO und der AI Act sich direkt überschneiden.

Nach Art. 22 DSGVO hat eine Person das Recht, nicht einer ausschließlich auf automatisierter Verarbeitung beruhenden Entscheidung unterworfen zu werden, die rechtliche oder ähnlich erhebliche Wirkungen entfaltet. Der häufige Fehler ist anzunehmen, dass Agenten automatisch Art. 22 auslösen, weil sie autonom sind. Die AEPD ist hier vorsichtig: Ob eine agentische Handlung eine automatisierte Entscheidungsfindung nach Art. 22 darstellt, hängt von den Wirkungen der Entscheidung und dem Grad maßgeblichen menschlichen Eingreifens ab — nicht von der bloßen Nutzung autonomer Technologie.⁶ Ein Agent, der eine Antwort für einen Menschen zum Senden entwirft, hat einen Menschen in der Schleife. Ein Agent, der autonom eine Rückerstattung ablehnt, einen Patienten umterminiert oder eine Bewerberin herausfiltert — ohne maßgebliche menschliche Überprüfung — trifft eine Entscheidung mit Wirkung, und die Beschränkungen des Art. 22 sowie seine Transparenzpflicht (auf Anfrage aussagekräftige Informationen über die involvierte Logik) greifen.⁷ Die Warnung der AEPD ist noch schärfer: Selbst Handlungen, die Einzelpersonen indirekt betreffen, durch nachgelagerte Prozesse, müssen bewertet werden — weil die Konsequenzen eines Agenten nicht auf den Schritt beschränkt sind, den ein Mensch beobachtete.⁸

Die Kosten, dies falsch zu machen, sind nicht hypothetisch, und das lehrreichste Beispiel geht der Agenten-Ära um Jahre voraus. In der niederländischen toeslagenaffaire — dem Kinderbetreuungsbeihilfen-Skandal — nutzte die Steuerverwaltung einen selbstlernenden Risikoklassifizierungsalgorithmus, um Familien zur Betrugsuntersuchung zu markieren, teils auf der Grundlage von Staatsangehörigkeit und doppelter Staatsbürgerschaft.⁹ Zwischen 26.000 und 35.000 Familien wurden, je nach Zählung, zu Unrecht beschuldigt; viele wurden in den finanziellen Ruin getrieben, einigen wurden Kinder in Obhut genommen, und der resultierende politische Fallout brachte im Januar 2021 die niederländische Regierung zu Fall. Die niederländische Datenschutzbehörde verhängte später eine Geldbuße von 2,75 Millionen Euro gegen die Steuerverwaltung und befand die Verarbeitung für rechtswidrig und diskriminierend.¹⁰ Zwei Merkmale dieser Katastrophe übertragen sich direkt auf agentische KI. Erstens gab es nominell einen „Menschen in der Schleife” — Beamte handelten auf die Markierungen des Algorithmus hin — aber die menschliche Überprüfung war nicht maßgeblich; sie stempelte eine Maschinenausgabe ab, die sie in der Praxis weder hinterfragen noch außer Kraft setzen konnte. Dies ist genau der Fehlermodus, vor dem die AEPD warnt: Die Anwesenheit eines Menschen ist nicht dasselbe wie maßgebliches menschliches Eingreifen, und Art. 22 schaut auf Letzteres. Zweitens propagierte der Schaden nachgelagert — die Ausgabe des Modells wurde mit anderen öffentlichen und privaten Stellen geteilt, sodass eine einzige fehlerhafte Klassifizierung in Kontoschließungen und Sorgerechtsentscheidungen weiterwogte. Ein Agent, der Werkzeuge aufruft und seine Schlussfolgerungen an andere Systeme weitergibt, reproduziert genau dieses nachgelagerte Propagierungsrisiko, in Maschinengeschwindigkeit und mit weniger Sichtbarkeit. Die toeslagenaffaire ist, wie eine automatisierte Entscheidung mit „rechtlicher oder ähnlich erheblicher Wirkung” aussieht, wenn niemand sie zurückholen kann.

Der AI Act fügt eine zweite, parallele Schicht hinzu. Wo ein Agent ein Hochrisiko-KI-System darstellt oder in eines eingebettet ist, das Entscheidungen über natürliche Personen trifft oder unterstützt, muss der Betreiber nach Art. 26 Abs. 11 die betroffenen Einzelpersonen darüber informieren, dass sie seiner Nutzung unterliegen.¹¹ Das Timing zählt und ist leicht falsch zu machen. Die Transparenzpflichten des Art. 50 des AI Act — einschließlich der Pflicht offenzulegen, wenn eine Person mit einem KI-System interagiert — gelten ab dem 2. August 2026. Das Hochrisiko-Regime jedoch, zu dem Art. 26 Abs. 11 gehört, wurde durch die Digital-Omnibus-Vereinbarung vom 7. Mai 2026 aufgeschoben: Für eigenständige Hochrisiko-Systeme nach Anhang III sollen die Betreiber- und Anbieterpflichten ab dem 2. Dezember 2027 gelten (vorbehaltlich der förmlichen Annahme), statt des ursprünglichen Datums August 2026.¹² Die praktische Konsequenz ist nicht, dass die Pflicht ignoriert werden kann — sie ist, dass die DSGVO jetzt die lebendige Arbeit leistet, während die Hochrisiko-Pflichten des AI Act an einem nahen, vereinbarten-aber-noch-nicht-endgültigen Horizont sitzen. Eine Organisation, die heute einen entscheidungsfindenden Agenten betreibt, steht bereits vor einer Art.-22-Analyse unter der DSGVO und sollte auf die Hochrisiko-Klassifizierung und die Transparenzpflichten nach dem Zeitplan bauen, den die Mitgesetzgeber vereinbart haben — das Datum Dezember 2027 als Planungsgrundlage behandelnd, die die förmliche Annahme voraussichtlich bestätigt, nicht als Erlaubnis, das Design bis dahin aufzuschieben.

Speicher, Zweckdrift und der „technologische Nebel”

Agenten tragen ein Merkmal, das gewöhnliche Software nicht hat: persistenten Speicher. Um die Leistung zu verbessern, speichert ein Agent Kontext, Nutzerpräferenzen und vergangene Interaktionen — und die AEPD kennzeichnet dies als ein erhebliches Compliance-Risiko für sich.¹³ Speicher, der sich „für alle Fälle” oder zur „Leistungsoptimierung” ansammelt, kollidiert frontal mit Zweckbindung und Datenminimierung. Schlimmer noch, wenn ein einzelner Agent mehreren Verarbeitungstätigkeiten dient, wird sein Speicher zu einem Vektor für Zweckdrift: Daten, die zu einem Zweck gesammelt wurden, informieren stillschweigend einen anderen. Das Heilmittel der AEPD ist konkret — Speicher muss zwischen verschiedenen Verarbeitungstätigkeiten und verschiedenen Nutzern kompartimentiert, unter strengen Aufbewahrungsfristen gehalten und so gestaltet sein, dass Betroffenenrechte (Auskunft, Berichtigung, Löschung) in ihn hineinreichen.¹⁴ Der Speicher eines Agenten ist kein Bequemlichkeits-Cache; er ist eine Aufzeichnung der Verarbeitung, jeder Pflicht unterworfen, die einer solchen anhaftet.

Um dies herum sitzt ein Problem, das die AEPD einprägsam benennt: der technologische Nebel. Weil die Entscheidungen eines Agenten aus Ketten von Schlussfolgerungen entstehen, die über mehrere Werkzeuge und Sub-Agenten verteilt sind, haben die betroffenen Menschen — und oft die Betreiber selbst — keine Sichtbarkeit darüber, welche Dienste abgefragt wurden, welche Daten verwendet wurden oder wie Zwischenergebnisse das Resultat formten.¹⁵ Der Nebel hat eine Compliance-Konsequenz und eine kulturelle. Die Compliance-Konsequenz ist, dass Transparenzpflichten wirklich schwer zu erfüllen werden: Sie können eine Entscheidungslogik nicht offenlegen, die Sie nicht rekonstruieren können. Die kulturelle ist heimtückischer — die Versuchung, ein agentisches System als legitim zu akzeptieren, einfach weil es „KI” ist, ohne Verständnis oder Beleg. Der Nebel ist kein Grund, dem System zu vertrauen. Er ist genau das, was die Rechenschaftspflicht des Verantwortlichen zu zerstreuen existiert.

Warum statische Kontrollen zusammenbrechen — und was sie ersetzt

Hier ist das operative Herz der Sache. Die Grundsätze der DSGVO weisen weiterhin richtig: Zweckbindung, Minimierung, Transparenz, Speicherbegrenzung, Rechenschaftspflicht. Was bei Agenten versagt, sind nicht die Grundsätze, sondern das Betriebsmodell, das um sie herum gebaut wurde — die Annahme stabiler Datenflüsse, vorhersehbarer Werkzeugketten und menschlicher Freigabe an festen Punkten.¹⁶ Wenn ein Agent seinen Plan mitten im Lauf umschreibt und eine API aufruft, die es nie in die DSFA schaffte, ist eine Kontrolle, die nur in einem vor dem Start unterzeichneten Dokument lebt, bereits umgangen. Die Bewertung beschrieb einen Workflow, dem der Agent nicht mehr folgt.

Die Behebung, wie die IAPP-Formulierung es ausdrückt, besteht darin, die Compliance von Dokumenten zu Mechanismen zu verschieben — die Governance zur Laufzeit mit dem System reisen zu lassen.¹⁷ In der Praxis bedeutet das, gestützt auf sowohl die Minimierungs-Orientierungshilfe der AEPD als auch die Laufzeit-Governance-Praxis, mehrere konkrete Kontrollen:

Werkzeug- und Datenzugriff nach dem Least-Privilege-Prinzip. Definieren Sie explizite Richtlinien für jedes Repository und Werkzeug, das der Agent erreichen kann; der Agent erhält Zugriff auf das, was sein Zweck erfordert, und nichts darüber hinaus. Die Minimierungs-Orientierungshilfe der AEPD ist hier spezifisch — katalogisieren und taggen Sie Daten, um zu identifizieren, was für den Agenten zu verwenden angemessen ist, kennzeichnen Sie problematische unstrukturierte Quellen und setzen Sie wirksame Zugriffsbeschränkungen pro Repository durch.¹⁸ Ein Agent, der als Identität verwaltet wird, mit denselben Zugriffskontrollen und Audit-Trails wie ein menschlicher Nutzer, ist die funktionierende Form der Datenminimierung für autonome Systeme.

Laufzeit-Schutzgeländer statt einmaliger Überprüfung. Allow-Lists für Werkzeuge und Plugins, Datenausgangsfilter, Geofencing, um die Verarbeitung innerhalb des EWR zu halten, Detektoren für sensible Kategorien und ein Notausschalter, wenn der Agent über die Grenzen hinausläuft — diese setzen die Richtlinie im Moment der Handlung durch, nicht in einem vierteljährlichen Audit.¹⁹ Ein Vor-Einsatz-Test gegen synthetische und Grenzfall-Szenarien, um Übererhebung, unautorisierte Werkzeugnutzung und Zweckdrift vor dem Start zu erkennen, ist das agentische Äquivalent der DSFA, ausgeführt als Engineering.

Nachvollziehbarkeit pro Lauf und pro Nutzer. Weil der Nebel der Feind der Transparenz ist, ist das Gegenmittel die Lineage: eine vollständige Aufzeichnung dessen, was der Agent tat, auf welche Daten er zugriff, welche Werkzeuge er aufrief und wie er zu einer Entscheidung gelangte — verankert pro Lauf und pro Nutzer, sodass ein Auskunftsersuchen oder ein Art.-22-Erläuterungsersuchen aus Belegen statt aus Mutmaßung beantwortet werden kann.²⁰ Protokollierung ist jedoch selbst Verarbeitung: Die AEPD warnt, dass exzessive Protokolle ihr eigenes Risiko der Übererhebung und intrusiven Überwachung schaffen, sodass Nachvollziehbarkeit gestaltet, nicht maximiert werden muss.²¹

Diese drei sind kein Menü zur Auswahl, sondern eine Abfolge, die in Reihenfolge zu bauen ist: den Zugriff des Agenten umreißen, bevor er läuft (Least Privilege), den Umfang durchsetzen, während er läuft (Laufzeit-Schutzgeländer), und erfassen, was er tat, nach jedem Lauf (Nachvollziehbarkeit) — jede Schicht setzt die davor voraus. Ein Agent, der die dritte ohne die erste hat, ist lediglich gut dokumentiert, während er übertritt.

Die DSFA verschwindet in diesem Modell nicht — sie ändert ihren Charakter. Sie wird zum Dokument, das diese Mechanismen und die Grenze der Befugnis des Agenten spezifiziert, statt einer Momentaufnahme eines Workflows, den der Agent nicht respektieren wird. Und weil der Einsatz eines autonomen Systems, das personenbezogene Daten im großen Maßstab verarbeitet, folgenreiche Handlungen vornimmt und die Hochrisiko-Schwelle erreichen kann, fast sicher die Linie des Art. 35 überschreitet, ist die DSFA nicht optional — sie ist das Instrument, in dem der Zweck des Agenten, seine Werkzeuggrenze, seine Speicherregeln und seine Punkte menschlicher Aufsicht festgelegt werden, bevor ihm die Autonomie zu handeln gegeben wird.

Vier Fragen, bevor einem Agenten ein Ziel gegeben wird

Die Architektur reduziert sich auf eine kurze Diagnostik, die eine Datenschutzbeauftragte oder ein Systemeigner durchlaufen kann, bevor er einem Agenten Autonomie über personenbezogene Daten gewährt.

Erstens: Was ist der Zweck des Agenten, und ist sein Werkzeug- und Datenzugriff genau darauf begrenzt? Wenn der Agent Repositories erreichen oder Werkzeuge aufrufen kann, die über das hinausgehen, was sein Zweck erfordert, hat die Minimierung bereits versagt — Autonomie plus zu breiter Zugriff ist Zweckdrift, die nur darauf wartet zu geschehen.

Zweitens: Trifft der Agent Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung auf Menschen, ausschließlich automatisiert — und gibt es maßgebliche menschliche Aufsicht, wo er es tut? Wenn Ja zum Ersten und Nein zum Zweiten, gelten die Beschränkungen des Art. 22 DSGVO jetzt, und die Hochrisiko-Betreiberpflicht des AI Act nach Art. 26 Abs. 11 ist auf dem Weg (Anhang III: ab dem 2. Dezember 2027 unter dem Omnibus, vorbehaltlich der förmlichen Annahme). Die Wirkung plus das Fehlen maßgeblicher menschlicher Überprüfung, nicht die Autonomie selbst, ist der Auslöser.

Drittens: Wo lebt der Speicher des Agenten, was ist darin, und können Betroffenenrechte ihn erreichen? Speicher kompartimentiert nach Zweck und Nutzer, mit Aufbewahrungsgrenzen und Löschpfaden, oder ein undifferenzierter Speicher, der Kontext „für alle Fälle” ansammelt? Das Zweite ist ein offener Befund.

Viertens: Wenn der Agent abweicht — ein nicht aufgeführtes Werkzeug aufruft, Daten außerhalb des EWR übermittelt, seinen Zweck überschreitet — was stoppt ihn, in Echtzeit? Wenn die einzige Antwort „das nächste Audit” ist, sind die Kontrollen statisch, und der Agent hat sie bereits überholt. Es muss einen Laufzeit-Mechanismus geben: eine Allow-List, einen Ausgangsfilter, einen Notausschalter.

Wenn eine dieser Fragen keine Antwort hat, ist der Agent nicht bereit, das Ziel zu erhalten.

Ein Belastungstest: der Agent, der das falsche Ergebnis bucht

Nehmen Sie den Postfach-und-Kalender-Agenten aus der Eröffnung und geben Sie ihm etwas mehr Befugnis — die Version, die Organisationen 2026 tatsächlich einsetzen. Er entwirft nicht nur Antworten; ihm ist erlaubt zu handeln: Termine abzusagen und neu zu buchen, Besprechungsanfragen abzulehnen, die eine Regel nicht bestehen, und „hochriskante” Absender in eine separate Warteschlange zu eskalieren. Eines Morgens verarbeitet er eine Nachricht von einer Patientin, die bittet, einen Termin zu verschieben. Der Agent liest den Thread, schließt aus einer Formulierung, dass die Patientin eine „häufige Stornierin” ist, wendet eine interne Regel an, die solche Patientinnen depriorisiert, lehnt die Anfrage ab und bietet einen Termin sechs Wochen später an. Kein Mensch sah die Entscheidung; sie war eine von vierhundert, die der Agent vor dem Mittagessen abwickelte.

Gehen Sie sie durch die vier Fragen, und die Versäumnisse stapeln sich. War die Handlung eine Entscheidung mit erheblicher Wirkung? Für eine Patientin, die auf Versorgung wartet, plausibel ja — und wenn es eine ausschließlich automatisierte Entscheidung mit rechtlichen oder ähnlich erheblichen Wirkungen war, ist Art. 22 im Spiel, und die Schlussfolgerung „häufige Stornierin” ist ein automatisiertes Urteil, das die Patientin anzufechten und erläutert zu bekommen berechtigt ist. Gab es maßgebliche menschliche Aufsicht? Keine — und wie die toeslagenaffaire zeigte, würde selbst ein nomineller menschlicher Kontrollpunkt den Standard nicht erfüllen, sofern der Überprüfer die Schlussfolgerung nicht tatsächlich hinterfragen und außer Kraft setzen könnte. Propagierte der Schaden nachgelagert? Der Sechs-Wochen-Termin und das „hochriskant”-Tag sitzen nun im Speicher des Agenten und können jede künftige Interaktion mit dieser Patientin formen — Zweckdrift, codiert als persistentes Etikett. Und als es schiefging, was stoppte es? Nichts, bis sich jemand beschwerte — zu welchem Zeitpunkt die Entscheidung Wochen alt war und die Begründung im „technologischen Nebel” einer Schlussfolgerungskette verloren war, die niemand aufzeichnete.

Der Belastungstest macht die These konkret: Nichts hier erforderte einen böswilligen Akteur oder ein dramatisches Versagen. Es erforderte nur einen Agenten mit Befugnis zu handeln, eine plausibel aussehende Regel und das Fehlen einer Laufzeit-Kontrolle, die die folgenreiche Entscheidung fangen könnte, während sie getroffen wurde. Der Agent tat genau das, wozu er delegiert wurde. Das ist genau das Problem — und es ist der Grund, warum die Kontrollen zur Laufzeit leben müssen, wo die Entscheidung geschieht, nicht in einer DSFA, die abgelegt wurde, bevor der Agent je eine echte Patientin sah.

Das Fazit

ZUSAMMENFASSUNG FÜR ENTSCHEIDUNGSTRÄGER Die Autonomie eines KI-Agenten überträgt keine Verantwortung: Er ist ein technisches Mittel, und die einsetzende Organisation ist im typischen Einsatz der Verantwortliche — oder zumindest rechenschaftspflichtig für die Bestimmung der Zwecke und wesentlichen Mittel der Verarbeitung — für die Werkzeuge, die der Agent aufruft, und die Daten, die er berührt, auch die, die er erreichte, ohne dass es ihm gesagt wurde, während das externe Modell, die Automatisierungs- und Speicherdienste als Auftragsverarbeiter oder, in manchen Konfigurationen, eigenständige Verantwortliche handeln. Agenten verarbeiten nicht nur — sie handeln, sodass dort, wo die Handlung eines Agenten eine ausschließlich automatisierte Entscheidung mit rechtlichen oder ähnlich erheblichen Wirkungen ist, ohne maßgebliche menschliche Beteiligung, Art. 22 DSGVO greift (nicht jede Agentenhandlung erreicht diese Schwelle — Wirkung und das Fehlen maßgeblicher menschlicher Überprüfung sind, was sie auslöst); und die Hochrisiko-Betreiberpflichten des AI Act (Art. 26 Abs. 11, für Hochrisiko-Systeme, die Entscheidungen über natürliche Personen treffen oder unterstützen) sitzen auf einem vereinbarten Zeitplan (Anhang III: 2. Dezember 2027 unter dem Omnibus, vorbehaltlich der förmlichen Annahme). Der persistente Speicher des Agenten ist durchweg eine Aufzeichnung der Verarbeitung, unterworfen der Minimierung, Aufbewahrung und Löschung. Die Kontrollen können nicht in einem vor dem Start unterzeichneten Dokument leben, weil der Agent seinen eigenen Plan mitten in der Aufgabe umschreibt; Zweckgrenzen, Werkzeugzugriff nach dem Least-Privilege-Prinzip, Ausgangsfilter und ein Notausschalter müssen zur Laufzeit durchgesetzt werden — und die eine Frage, die all dies regiert, lautet: Als der Agent handelte, wer entschied, und wer kann ihn zurückholen?

Die Autonomie eines Agenten ist keine Übertragung der Rechenschaftspflicht. Das System führt aus; die Organisation ist verantwortlich — für die Schritte, die sie beobachtete, und, gefährlicher, für die Schritte, die sie nicht beobachtete. „Der Agent hat es getan” benennt das Problem; es steht nicht dafür ein.

Agenten verschieben die Frage von der Verarbeitung zur Handlung. In dem Moment, in dem ein System entscheidet und mit Wirkung auf eine Person handelt, geht es in der Analyse nicht mehr nur um Daten — es geht um automatisierte Entscheidungsfindung unter der DSGVO jetzt und um die Hochrisiko-Betreiberpflichten des AI Act, wie sie sich einphasen, auf demselben Einsatz.

Statische Kontrollen brechen gegen ein System zusammen, das seinen eigenen Plan umschreibt. Die Verteidigung ist keine dickere DSFA; es ist Governance, die läuft — begrenzter Werkzeugzugriff, Ausgangs- und Geofencing-Filter, Nachvollziehbarkeit pro Lauf und ein Notausschalter. Entscheiden Sie, wer den Agenten zurückholen kann, bevor Sie ihn handeln lassen, und die Autonomie ist ein Vermögenswert statt einer nicht zugewiesenen Haftung.

Glossar der Abkürzungen

Rechtlicher Hinweis: Dieser Artikel dient allgemeinen Informationszwecken und stellt keine Rechtsberatung dar. Für eine rechtssichere Beurteilung im konkreten Einzelfall wird die Konsultation einer auf Datenschutz spezialisierten Anwältin oder eines Anwalts empfohlen. Stand: Juni 2026.