KI-Agenten-Governance: EU-Regeln treffen auf Googles Agentenidentität

Einleitung

Zwei Ankündigungen aus der ersten Augustwoche 2026 weisen aus entgegengesetzten Richtungen auf denselben Wandel hin. Am 2. August wurden die Transparenzregeln der EU-KI-Verordnung durchsetzbares Recht – jeder, der einen Chatbot, einen Inhaltsgenerator oder ein Emotionserkennungssystem einsetzt, muss dies klar offenlegen oder mit Geldstrafen von bis zu 15 Millionen Euro rechnen. Wenige Tage später brachte Google Cloud sein Agent Identity-System zur allgemeinen Verfügbarkeit – eine native Berechtigungsschicht, die genau nachverfolgt, worauf ein KI-Agent zugreifen kann, und alles protokolliert, was er tut. Das eine ist ein Regulierer, der Offenlegung erzwingt. Das andere ist eine Cloud-Plattform, die Rechenschaftspflicht als Feature verkauft. Beide kommen zu demselben Schluss: Ein KI-Agent, den niemand identifizieren, prüfen oder zur Verantwortung ziehen kann, ist nicht produktionsreif – ob ein Gericht das sagt oder nicht.

Was sich am 2. August geändert hat

Die Transparenzpflichten aus Artikel 50 der EU-KI-Verordnung wurden am 2. August 2026 in der gesamten EU allgemein anwendbar und von nationalen Behörden durchsetzbar. In der Praxis umfasst dies vier Bereiche. Anbieter müssen sicherstellen, dass Personen „klar darüber informiert werden, dass sie mit einem KI-System interagieren, es sei denn, dies ist aus dem Zusammenhang offensichtlich“ – die Chatbot-Offenlegungspflicht. Anbieter von Systemen, die synthetische Audio-, Bild-, Video- oder Textinhalte erzeugen, müssen diese Ausgabe in einem maschinenlesbaren, erkennbaren Format kennzeichnen. Jeder, der ein System einsetzt, das Deepfakes von echten Personen, Orten oder Ereignissen erzeugt, muss dies offenlegen. Und Anbieter von Emotionserkennungs- oder biometrischen Kategorisierungssystemen müssen die betroffenen Personen informieren und im Rahmen der EU-Datenschutzgesetze bleiben.

Nichts davon ist konzeptionell neu – die KI-Verordnung wurde Jahre zuvor verabschiedet. Was sich am 2. August geändert hat, ist, dass diese spezifischen Pflichten aufgehört haben, ein zukünftiges Datum auf einem Compliance-Fahrplan zu sein, und zu etwas geworden sind, das nationale Regulierungsbehörden heute tatsächlich durchsetzen können.

Bereit, Ihr Geschäft zu erweitern?

Starten Sie heute Ihre kostenlose Testversion und sehen Sie innerhalb weniger Tage Ergebnisse.

Demo anfragen Anmelden

Was auf 2027 und 2028 verschoben wurde

Nicht alles im Gesetz ist termingerecht eingetroffen. Durch den Digital Omnibus on AI, der am 8. Juli 2026 unterzeichnet wurde, hat die EU ihre Hochrisiko-Systemanforderungen verschoben. Eigenständige Systeme nach Anhang III – denken Sie an Beschäftigungsscreening, Bildung, Strafverfolgung, kritische Infrastruktur – haben nun bis zum 2. Dezember 2027 Zeit. KI in bereits regulierten Produkten nach Anhang I, wie Medizinprodukte oder Aufzüge, hat bis zum 2. August 2028 Zeit.

Diese Verschiebung sollte man genau betrachten, denn sie kann leicht als „die KI-Verordnung wurde verzögert“ missverstanden werden. Das ist nicht der Fall. Die Liste der verbotenen Praktiken und die Pflichten für KI-Modelle mit allgemeinem Verwendungszweck sind unberührt. Was verschoben wurde, sind speziell die Hochrisiko-Einstufungsanforderungen – der größte Compliance-Aufwand für den schmalsten Bereich von Systemen. Wenn Ihr Agent mit Nutzern spricht oder Inhalte generiert, befinden Sie sich in dem Teil des Gesetzes, der bereits aktiv ist.

Warum Transparenzregeln wichtig sind

Die Transparenzanforderung klingt neben „Hochrisikosystem“ bescheiden, aber sie ist die Regel, auf die die meisten KI-Agenten-Entwickler tatsächlich zuerst stoßen werden. Ein kundenorientierter Support-Agent, ein Content-Generierungs-Workflow, ein Sprachassistent – all das sind Systeme, die mit Menschen kommunizieren, was bedeutet, dass Artikel 50 unabhängig davon gilt, ob sie jemals als Hochrisiko eingestuft würden. Dies richtig zu machen, ist nicht kompliziert: klar sagen, dass der Nutzer mit einer KI spricht, generierte Inhalte kennzeichnen und Aufzeichnungen führen, die dies belegen. Es falsch zu machen, ist der Punkt, an dem die Compliance-Berichterstattung aufhört, Papierkram zu sein, und zu einer rechtlichen Gefahr mit einer echten Zahl wird.

Abonnieren Sie unseren Newsletter

Erhalten Sie die neuesten Tipps, Trends und Angebote kostenlos.

E-Mail-Adresse

Abonnieren

Google liefert Agent Identity aus

Google Clouds Antwort auf dasselbe zugrundeliegende Problem kam aus einer völlig anderen Richtung: Infrastruktur, nicht Gesetz. Das Unternehmen brachte seine Gemini Enterprise Agent Platform mit einer Reihe neuer Agenten-Governance-Primitiven zur allgemeinen Verfügbarkeit – Agent Memory Bank, Agent Runtime, Agent Gateway, Agent Registry, Agent Evaluation und, am bemerkenswertesten, Agent Identity.

Agent Identity ist ein nativer IAM-Berechtigungstyp, der auf offenen Standards basiert und speziell für autonome Systeme entwickelt wurde, anstatt von menschlichen Benutzerkonten abgeleitet zu sein. Es setzt Zugriff mit geringsten Privilegien durch, indem Berechtigungen direkt an die Laufzeit des Agenten gebunden werden, was einen häufigen Angriffspfad schließt, bei dem ein gestohlenes Agenten-Token an anderer Stelle wiederverwendet werden könnte. Es erstellt nicht-abstreitbare Protokolle aller Aktionen, die ein Agent ausführt. Und es verwaltet den Berechtigungslebenszyklus automatisch, sodass ein stillgelegter Agent keine ruhenden, vergessenen Berechtigungen hinterlässt, die auf Missbrauch warten.

Was Agent Identity tatsächlich tut

Der praktische Effekt ist, dass „welcher Agent hat das getan, und war es ihm erlaubt?“ zu einer Frage mit einer definitiven Antwort wird, anstatt einer Vermutung, die nachträglich aus Anwendungsprotokollen rekonstruiert werden muss. Das wird umso wichtiger, je mehr Agenten von der Beantwortung von Fragen zur Ausführung von Aktionen übergehen – Dinge buchen, Aufzeichnungen bearbeiten, Geld bewegen, Dateien löschen. Eine LLM-Sicherheitsstrategie, die sich nur um Prompt-Injection in das Modell selbst kümmert, übersieht diese gesamte Angriffsfläche: die tatsächlichen Berechtigungen des Agenten und was er damit getan hat.

Hier verbinden sich die beiden Ankündigungen auch mehr, als es zunächst den Anschein hat. Artikel 50 fragt: „Haben Sie offengelegt, dass dies KI war?“ Agent Identity beantwortet eine verwandte, aber eigene Frage: „Können Sie genau nachweisen, was dieser bestimmte Agent getan hat, mit welchen Berechtigungen und auf wessen Autorität hin?“ Ein System, das die zweite Frage sauber beantworten kann, findet die erste viel einfacher.

Zwei verschiedene Wege, dasselbe Ziel

Es lohnt sich, das Muster direkt zu benennen, denn es wird sich wiederholen. Regulierungsbehörden konvergieren aus einer rechtlichen Risikoperspektive auf Offenlegung und Rechenschaftspflicht. Cloud-Plattformen konvergieren aus einer Sicherheits- und Zuverlässigkeitsperspektive auf Identität und Berechtigungen. KI-Agenten-Frameworks haben Identität früher als nachträglichen Einfall behandelt – ein API-Schlüssel in einer Umgebungsvariable, der von jedem Agenten im gesamten Bestand gemeinsam genutzt wird. Dieses Modell überlebt weder die behördliche Prüfung noch einen echten Sicherheitsvorfall, weshalb beide Richtungen jetzt auf dieselbe Lösung verweisen: wissen, welcher Agent was getan hat, mit welchem Zugriff, und in der Lage sein, dies nachzuweisen.

Teams, die bereits mit praxisnahen KI-Agenten-Beispielen experimentieren – Kundensupport-Bots, Forschungsassistenten, Codierungsagenten – werden diesen Wandel zuerst spüren, einfach weil sie mehr Agenten in Produktion haben, die mehr Aktionen generieren, die nachvollzogen werden müssen. Es ist dasselbe Muster, das wir sahen, als Claude Cowork und seine Konkurrenten Agenten von Ein-Sitzungs-Chats zu persistenten, mehrtägigen Aufgaben trieben: Mehr Autonomie kommt immer einen Schritt vor den Werkzeugen, um sie zu regieren.

Von Anfang an regierbare Agenten entwickeln

Prüfpfade nachträglich in eine Agentenflotte einzubauen, die nie dafür ausgelegt war, sie zu erzeugen, ist ein miserables Projekt – jede Aktion muss aus den vorhandenen Protokollen rekonstruiert werden, und die Hälfte der Zeit existieren sie nicht. Der günstigere Weg ist, auf Werkzeugen aufzubauen, bei denen jeder Schritt eines Agenten von Anfang an sichtbar und nachvollziehbar ist – so wie die Datengovernance die Datenherkunft als erstklassiges Anliegen behandelt und nicht als etwas, das man nach einem Sicherheitsvorfall nachrüstet.

Hier spielt auch das Tempo der zugrundeliegenden Modelle eine Rolle. Aktuelle Veröffentlichungen wie Microsofts Orchard-Framework und der allgemeine Wandel hin zu spezialisierten, prüfbaren Agenten (anstatt einem riesigen General-Purpose-Modell, das alles macht) machen es praktikabler, Agenten zu entwickeln, deren Umfang – und damit deren Berechtigungen – von Natur aus eng und klar definiert sind. Ein eng begrenzter Agent ist von Natur aus leichter zu regieren als einer, der theoretisch alles tun kann.

FlowHunts Ansatz folgt derselben Logik: Als KI-Agenten-Plattform ist jede Automatisierung ein sichtbarer Ablauf, keine Blackbox. Wenn also eine Compliance-Frage eingeht – was hat dieser Agent getan, warum und unter welcher Autorisierung – liegt die Antwort bereits im Workflow und muss nicht von Ihrem Team unter Zeitdruck rekonstruiert werden.

Fazit

Die Transparenzregeln der EU-KI-Verordnung und Googles Agent Identity-System haben sich nicht miteinander abgestimmt, und sie lösen nominell unterschiedliche Probleme – das eine ist rechtliche Compliance, das andere ist Cloud-Infrastruktur. Aber sie landeten in derselben Woche und verwiesen auf dieselbe zugrundeliegende Wahrheit: Da KI-Agenten immer autonomere und folgenreichere Arbeiten übernehmen, hört „wir wissen nicht wirklich, was es getan hat“ auf, eine akzeptable Antwort zu sein, egal ob die fragende Person ein Regulierer oder Ihr eigenes Sicherheitsteam ist. Die Teams, die Identität, Offenlegung und Prüfbarkeit jetzt als Kernanforderungen behandeln – nicht als Funktionen, die später hinzugefügt werden – werden sowohl Compliance als auch Produktionsvorfälle als weitaus weniger schmerzhaft empfinden, wenn sie auftreten.