Agentic AI Governance Gap: Warum 79 Prozent deployen, aber nur 21 Prozent bereit sind
AWS hat diese Woche die AWS Agent Registry in der Preview angekündigt. Agents bekommen eine Art digitalen Ausweis: eine stabile Identität, nachverfolgbare Berechtigungen, ein Audit-Trail. Das ist das richtige Feature zum richtigen Zeitpunkt - denn die Zahlen zeigen, dass der Markt gerade an einem Punkt ist, an dem Governance nicht mehr optional ist.
Deloitte hat kürzlich erhoben: 79 Prozent der Unternehmen deployen oder testen Agentic AI. Nur 21 Prozent haben ein ausgereiftes Governance-Modell dafür. Gleichzeitig hat Gravitee gemessen, dass 88 Prozent der Unternehmen, die KI-Agents einsetzen, bereits Sicherheitsvorfälle hatten.
Ich habe dieses Muster schon zweimal gesehen.
Das Muster ist nicht neu
Erst mit Shadow IT: Fachbereiche haben sich Cloud-Dienste und SaaS-Tools beschafft, ohne dass die IT Bescheid wusste. Es hat etwa zehn Jahre gedauert, bis Identity Governance zu einem Standard in deutschen Unternehmen wurde - bis IAM-Lösungen, Rezertifizierungszyklen und Access Reviews Pflichtprogramm waren.
Dann mit Cloud-Adoption selbst: AWS-Accounts wurden angelegt, ohne Governance-Rahmen, ohne Landing Zone, ohne Control Tower. Der Standardlauf sah so aus: erst drei bis fünf Accounts ohne Guardrails, dann ein Security-Incident oder ein C5-Audit, dann das Governance-Projekt. Rückwirkend aufräumen kostet das Dreifache.
Mit Agentic AI passiert dasselbe - nur schneller. Gartner projiziert, dass bis Ende 2026 vierzig Prozent aller Enterprise-Applikationen KI-Agents eingebaut haben werden. Das ist nicht in fünf Jahren. Das ist in acht Monaten. Die Proliferation ist höher als bei Shadow IT oder Cloud, und der Blast Radius ist größer: Agents handeln autonom.
Was "Governance-Gap" konkret bedeutet
Ein Agent ohne Governance ist nicht einfach unübersichtlich. Er ist ein autonomer Akteur, der API-Calls macht, Daten liest, Entscheidungen trifft - und für den niemand im Unternehmen sagen kann, wer er ist, was er darf, und was er in den letzten 30 Tagen getan hat.
Das klingt abstrakt. Hier ist es konkret: In einem BSI C5:2026-Audit müsst ihr heute schon Nachvollziehbarkeit für KI-Systeme nachweisen. Die neuen Anforderungen für AI-System-Traceability sind kein Zukunftsprojekt. Wer das erst beim nächsten Audit merkt, hat ein teures Nacharbeitsproblem.
Die drei Fragen, die jedes CISO-Team vor dem nächsten Agent-Deployment beantworten muss:
Frage 1: Identität
Wer ist dieser Agent? Was kann er tun? Wie wird er in Audit-Logs identifiziert?
Das klingt nach einer IT-Grundlagenfrage. Ist sie auch. Und trotzdem kann ich in DACH-Kundengesprächen selten eine klare Antwort hören. Agents werden deployed wie Batch-Jobs: ein Service-Account, ein paar Permissions, fertig. Kein Name, kein Owner, kein Lifecycle.
Die AWS Agent Registry ändert das: Agents bekommen eine verwaltete Identität mit Permissions-Tracking und Audit-Trail. Das ist das Feature, das ich in Kundenprojekten bisher manuell nachgebaut habe - über IAM-Tagging-Konventionen, CloudTrail-Filter und ein bisschen Terraform-Disziplin. Gut, dass AWS das jetzt als First-Class-Feature anbietet.
Die Frage nach der Identität muss beantwortet sein, bevor ein Agent in Produktion geht - nicht nach dem ersten Vorfall.
Frage 2: Berechtigungen
Was darf dieser Agent tun, in welchem Kontext, mit welchen Daten?
IAM-Policies für Agents folgen denselben Prinzipien wie für Menschen: least privilege, regelmäßig reviewed, auf die Aufgabe beschränkt. Das Wissen ist da. Die Praxis hinkt hinterher.
Was ich in Projekten sehe: Agents bekommen Berechtigungen, die für die initiale Entwicklungsphase gepasst haben - also zu breit, zu dauerhaft, nicht auf Produktionskontext zugeschnitten. Das ist dasselbe Anti-Pattern wie bei EC2-Instanz-Rollen mit *-Permissions. Die Konsequenz ist nicht "Agent macht etwas Böses". Die Konsequenz ist: Wenn etwas schiefgeht, hat der Angreifer oder der fehlerhafte Agent mehr Handlungsspielraum als nötig.
Concrete steps: Agents bekommen einen eigenen IAM-Service-Account, nicht den Service-Account des umliegenden Systems. Scoped policies, Bedingungen auf aws:RequestedRegion und aws:SourceVpc wo sinnvoll. Review-Zyklus mindestens quartalsweise.
Frage 3: Audit-Trail
Was hat dieser Agent getan, wann, im Auftrag von wem?
CloudTrail loggt jeden API-Call. Security Lake aggregiert über Accounts hinweg. Wer AWS nutzt, hat die technischen Mittel für einen vollständigen Audit-Trail - aber nur, wenn die Agents ordentlich identifiziert sind. Ein Agent, der unter einem generischen Service-Account läuft, erscheint in CloudTrail als undifferenzierter Strom von API-Calls. Ein Agent mit einer verwalteten Identität aus der Agent Registry erscheint als auditierbare Einheit.
BSI C5:2026 nimmt das ernst. Die Anforderungen an Nachvollziehbarkeit von KI-Systemen sind nicht optional. Wer keinen traceability-fähigen Audit-Trail für seine Agents hat, wird beim nächsten Audit ein Finding kassieren.
Wie gutes Governance aussieht
Ich beschreibe das nicht als Zielzustand für 2028. Das ist das Minimum für heute.
Agent Inventory: Kein Spreadsheet. Eine geführte Registry mit Identitäten und Berechtigungen. Die AWS Agent Registry ist ein guter Startpunkt. Wer noch nicht auf Bedrock standardisiert ist, baut das Äquivalent mit IAM-Tagging und einem zentralen Account-Level-Inventory auf.
Menschliche Verantwortung: Jeder Agent hat einen namentlichen Owner. Diese Person ist für das Verhalten des Agents verantwortlich - nicht die Plattform, nicht das Tool, nicht "die KI". Wenn in einem Incident-Response-Call die Frage kommt "Wer ist für Agent X zuständig?", muss es eine Antwort geben.
Review-Zyklus: Berechtigungen, Scope und Verhalten werden mindestens quartalsweise reviewed. Das ist kein Mehraufwand, wenn die Governance von Anfang an eingebaut ist. Es ist erheblicher Mehraufwand, wenn man es rückwirkend aufbaut.
C5/NIS2-Integration: Agent-Governance ist keine parallele Disziplin zur bestehenden Compliance. Sie ist Teil davon. BSI C5:2026 hat explizite Anforderungen für AI-System-Traceability. NIS2 enthält Anforderungen an Risikomanagement, die Agents als Komponenten kritischer Prozesse einschließen. Das Compliance-Programm muss Agents abdecken, nicht drumherum arbeiten.
Was die AWS Agent Registry bedeutet
Die Ankündigung heute ist ein Signal, nicht nur ein Feature. AWS baut an einer Plattform für Agentic AI, bei der Identity, Runtime, Observability und - wie ich erwarte - weitere Governance-Bausteine als kohärenter Stack zusammenwachsen. Das ist dasselbe Muster, mit dem AWS Lambda zur Standardlaufzeit gemacht hat: erst die Plattform, dann das Ökosystem.
Für DACH-Enterprises bedeutet das: Wer heute auf AWS Bedrock und Agent Registry setzt, baut auf einem Stack auf, der Governance von Anfang an mitdenkt. Wer eigene Agents baut und die Registry ignoriert, baut technische Schulden auf, die später teuer werden - nicht weil das Tool fehlt, sondern weil das Inventar fehlt.
Das Muster ist bekannt. Der Zeitplan ist enger als bei Shadow IT und Cloud. Die Frage ist, wann das eigene Haus Governance als Voraussetzung behandelt - nicht als Nacharbeit.
Ich arbeite in TM Forum Catalyst-Projekten und DACH-Kundenprojekten an Governance-Frameworks für Agentic AI. Wer konkrete Fragen zu Agent Registry, IAM-Policies für Agents oder C5:2026-Mapping hat: Kommentar oder direkt vernetzen.