Eine Liste der KI-Agenten ist noch keine Steuerung.

Die meisten Programme für KI-Governance in Unternehmen können Ihnen sagen, ob ein KI-System existiert.

Deutlich weniger können Ihnen sagen, was es heute Morgen um 10:43 Uhr tun darf.

Dieser Unterschied entwickelt sich zur entscheidenden Governance-Lücke bei agentischer KI.

Ein Inventar ist eine Landkarte. Eine Richtlinie ist ein Regelwerk. Keines von beiden ist für sich genommen eine operative Kontrolle.

Wenn KI-Systeme nicht mehr nur Fragen beantworten, sondern Werkzeuge aufrufen, auf Daten zugreifen, Arbeitsabläufe koordinieren und über verschiedene Unternehmensanwendungen hinweg handeln, müssen Organisationen ein veränderliches System aus Berechtigungen, Abhängigkeiten, Evidenz und Folgen steuern.

KI-Inventare bleiben unverzichtbar. Sie können Systemidentität, Verantwortliche, Zweck, Anbieter, Modellfamilie, Datenkategorien, Einführungsstatus und Risikokontext erfassen. Sowohl ISO/IEC 42001 als auch die Arbeit des NIST zum KI-Risikomanagement unterstreichen die Notwendigkeit einer Governance über den gesamten Lebenszyklus anstelle von Ad-hoc-Experimenten.

Quellenkontext: ISO/IEC 42001:2023 ↗ · NIST AI Risk Management Framework ↗

Ein Inventar beschreibt jedoch ein System. Es entscheidet nicht fortlaufend darüber, ob eine bestimmte Handlung autorisiert ist.

Betrachten Sie einen Agenten mit folgendem Eintrag:

Zweck: Unterstützung im Kundenservice Werkzeuge: CRM, Bestelldatenbank, E-Mail Verantwortlich: Customer Operations Risiko: mittel Menschliche Aufsicht: bei Ausnahmen erforderlich

Das sieht nach Governance aus.

Fragen Sie nun:

Darf er eine Erstattung veranlassen? Bis zu welchem Betrag? Darf er die Erstattung ohne Freigabe ausführen? Darf er dem Kunden interne Notizen offenlegen? Was geschieht, wenn eine von ihm gelesene Webseite bösartige Anweisungen enthält? Was geschieht, wenn das Kundenkonto zu einem anderen Mandanten gehört? Was geschieht, wenn die Berechtigung des Agenten gestern widerrufen wurde?

Das Inventar beantwortet diese Fragen nicht.

Richtlinien definieren Erwartungen. Sie können festlegen, dass sensible Daten stärkere Kontrollen erfordern, dass bestimmte Handlungen eine Freigabe benötigen, dass Anwendungen mit weitreichenden Auswirkungen geprüft werden müssen oder dass KI-generierte Inhalte unter festgelegten Umständen offenzulegen sind.

Der Text einer Richtlinie wird jedoch erst dann operativ wirksam, wenn Systeme ihn in durchsetzbare Entscheidungen übersetzen.

Ein Satz wie „Erstattungen hoher Beträge erfordern eine menschliche Freigabe“ benötigt mindestens:

• einen verbindlichen Schwellenwert für Erstattungen;
• den Kontext von Identität und Nutzungsberechtigung;
• eine Klassifikation der Handlung;
• einen Freigabemechanismus;
• eine dauerhafte Aufzeichnung der Entscheidung;
• ein Verhalten, das bei fehlendem oder fehlerhaftem erforderlichem Zustand sicher ablehnt.

Ohne diese Mechanismen bleibt die Richtlinie eine Hoffnung.

Agenten erzeugen nicht nur Text. Sie können Funktionen aufrufen, Werkzeuge nutzen, APIs ansprechen, mit anderen Agenten kommunizieren und Zustände über mehrstufige Arbeitsabläufe hinweg mitführen.

Die OWASP-Arbeit zur Sicherheit agentischer Systeme aus den Jahren 2025/2026 spiegelt diesen Wandel wider. Zu den Risiken gehören die Übernahme von Zielen, Werkzeugmissbrauch, Missbrauch von Identitäten und Privilegien, Schwachstellen in der Lieferkette und unerwartete Codeausführung. Bereits die frühere Kategorie „excessive agency“ benannte übermäßige Funktionalität, Berechtigungen und Autonomie als grundlegende Ursachen schädlichen Verhaltens.

Protokolle wie MCP und A2A erleichtern die Integration. Das ist nützlich – und macht eine ausdrückliche Steuerung von Befugnissen umso wichtiger. Standardisierte Anbindung darf nicht mit standardisierter Erlaubnis verwechselt werden.

Quellenkontext: MCP · authorization specification · 2026-07-28 ↗ · Agent2Agent · v1.0 specification ↗

Ein Werkzeug kann auffindbar sein, ohne genutzt werden zu dürfen. Ein Agent kann eine Fähigkeit besitzen, ohne dazu autorisiert zu sein. Ein entfernter Agent kann eine Fähigkeit ausweisen, ohne dadurch vertrauenswürdig zu werden.

Das System muss wissen, was der Agent jetzt tun darf – nicht, was jemand vor sechs Monaten genehmigt hat.

Befugnisse sollten, wo relevant, nach handelndem Subjekt, Organisation, Rolle, Daten, Werkzeug, Handlung, Betrag, Zeit, Rechtsraum und Folgen begrenzt werden.

Eine Entscheidung kann von Evidenz abhängen, die belastbar, spärlich, veraltet, widersprüchlich oder nicht vorhanden ist. Governance sollte Unsicherheit nicht in Gewissheit verwandeln, nur weil ein Arbeitsablauf eine binäre Antwort erwartet.

Eine Kundengutschrift von 20 € und eine Zahlungsanweisung über 20.000 € sollten nicht identische Kontrollen erfordern, nur weil beides „finanzielle Handlungen“ sind. Größere mögliche Folgen sollten nicht zu weniger Prüfung führen.

Agenten können Kontext aus mehreren Werkzeugen zusammenführen. Die Governance-Ebene muss verhindern, dass sensible Daten, Geheimnisse und Mandantenkontext Grenzen überschreiten – auch wenn das Modell selbst bereit wäre, fortzufahren.

Anbieter aktualisieren Modelle. Werkzeuge ändern ihren Berechtigungsumfang. Vorschriften entwickeln sich weiter. Evidenz verliert ihre Gültigkeit. Beschäftigte wechseln ihre Rollen. Eine Momentaufnahme des Inventars kann falsch werden und dennoch vollständig aussehen.

Deshalb haben wir die Operational AI Governance Gap Study 2026–27 definiert.

Die zentrale Frage lautet nicht: „Hat Ihre Organisation eine KI-Richtlinie?“

Sie lautet:

Wie groß ist die Lücke zwischen dokumentierter KI-Governance und der Fähigkeit, operative Kontrolle über KI-Systeme, Agenten, Befugnisse, Daten, Veränderungen und Ergebnisse zu belegen?

Das Studienprotokoll trennt bewusst:

SELBSTAUSKUNFT was Organisationen nach eigener Aussage tun;

DOKUMENTIERTE EVIDENZ was Richtlinien, Register, Bewertungen und Aufzeichnungen zeigen;

BEOBACHTETE BETRIEBLICHE EVIDENZ was Kontrollen zur Laufzeit, Protokolle, Freigaben, Tests und Änderungsaufzeichnungen belegen.

Diese Unterscheidung ist wichtig. Die Readiness Assessment Methodology der UNESCO trifft auf nationaler Ebene eine ähnliche methodische Unterscheidung: Sie fragt nicht nur, ob Strategien, Gesetze und Richtlinien existieren, sondern auch, ob ihre Wirksamkeit bewertet wurde, ob Umsetzungspläne vorliegen, ob Budgets und Monitoring vorhanden sind und wo Daten fehlen.

Eine hypothetische Organisation hat einen freigegebenen Inventareintrag für einen Rechercheassistenten. Er soll interne Dokumente abrufen und Zusammenfassungen vorbereiten. Bei einer späteren Aktualisierung erhält eine Schnittstelle die Möglichkeit, Aufgaben anzulegen und externe Personen einzuladen. Der Inventareintrag kann die Produktidentität weiterhin richtig beschreiben und zugleich die möglichen Folgen unvollständig erfassen. Entscheidend ist, welche frühere Entscheidung dadurch erneut betrachtet werden muss.

Eine vierteljährliche Tabellenpflege kann solche Änderungen entdecken, kommt aber möglicherweise erst nach der ersten externen Einladung. Umgekehrt überfordert die Sammlung jedes technischen Ereignisses diejenigen, die darauf reagieren sollen. Ein praktikabler Entwurf bestimmt wenige wesentliche Änderungen: neue Außenhandlungen, breiterer Datenzugriff, andere Anbieterbedingungen, ein neuer Zweck oder zusätzliche betroffene Menschen. Jede Änderung erhält eine Zuständigkeit und eine passende Reaktion.

Hier liegt der Unterschied zwischen dem Wissen um ein System und der Steuerung seines Handlungsspielraums. Die Lösung ist nicht zwingend ein größeres Verzeichnis. Benötigt wird eine Verbindung von der veränderten Tatsache zu der Person und Kontrolle, die eine betriebliche Erlaubnis verändern können. Das ursprüngliche Inventar bleibt als Ausgangspunkt dieser Verbindung sinnvoll.

Benennen Sie für jede folgenreiche Handlung die Regel, die durchsetzende Komponente und die Beobachtung, die deren Wirksamkeit zeigt. Verlangt die Richtlinie eine Freigabe vor externer Weitergabe, suchen Sie die tatsächliche Sperre. Eine schriftliche Anweisung im Prompt und eine unabhängig durchgesetzte Berechtigung sind unterschiedliche Kontrollen. Ihre Fehlerarten dürfen nicht als gleichwertig behandelt werden.

Klären Sie fehlende Voraussetzungen. Verweigert ein nicht erreichbarer Berechtigungsdienst die Handlung, stellt er sie zur Prüfung zurück oder übernimmt er einen alten Zustand? Was geschieht bei einem Objekt eines anderen Unternehmens? Kann eine frühere Freigabe für einen inzwischen veränderten Datensatz wiederverwendet werden? Diese betrieblichen Fragen beantwortet weder ein Inventartitel noch ein Modellrang.

Halten Sie die Übersicht benutzbar. Beginnen Sie mit einem Ablauf und seinen wichtigen Handlungen. Im Service können Lesen, Antwortentwurf, Kundenkommunikation und finanzielle Änderung getrennte Befugnisse sein. Sie sollten getrennt bleiben, auch wenn eine Oberfläche sie zusammen anbietet. Dann lässt sich hilfreiche Unterstützung erhalten, während eine Handlung mit größeren Folgen zurückgestellt wird.

Ergänzen Sie den fachlichen Zweck jeder Grenze. Eine Sperre ist leichter zu pflegen, wenn bekannt ist, welche Folge sie verhindern soll. Sonst kann eine spätere Optimierung eine scheinbar umständliche Prüfung entfernen, ohne ihre Bedeutung zu erkennen. Die Begründung hilft damit sowohl der Weiterentwicklung als auch der Fehlersuche.

Verändern Sie in einer kontrollierten Übung eine Voraussetzung. Entziehen Sie eine Berechtigung, ersetzen Sie eine Quelle durch eine widersprüchliche Fassung oder entfernen Sie ein notwendiges Dokument. Beobachten Sie das tatsächliche Verhalten. Erklärt der Assistent die fehlende Bedingung? Erhält das externe System einen Schreibversuch? Kann ein Bediener den betroffenen Fall erkennen und einen zulässigen Weg wiederherstellen?

Prüfen Sie danach eine wiederholte Anfrage bei unklarer Antwort. Ein Modell kann einen Vorgang erneut versuchen, weil die Bestätigung fehlt, obwohl der externe Dienst bereits gehandelt hat. Der Ablauf sollte vor einer Wiederholung den wirklichen Zustand feststellen. Eine passende Vorgangskennung verbindet Beobachtung und Wiederaufnahme. Eine erfolgreiche zweite Antwort beweist nicht, dass der erste Vorgang nie ausgeführt wurde.

Dokumentieren Sie Ergebnis, Konfiguration und Umfang. Eine Übung mit einer Schnittstelle zertifiziert nicht jede Integration. Sie kann aber eine Fehlerklasse zeigen, die an anderer Stelle untersucht werden sollte. Erhalten Sie Fehler und Korrektur. Besonders nützlich kann die Begründung sein, weshalb eine Erweiterung verschoben wurde. Sie beschreibt die tatsächliche Grenze der heutigen Umsetzung.

Beobachtung ist hilfreich, wenn sie zu einer bestimmten Entscheidung führen kann. Eine angekündigte Modellabkündigung betrifft die davon abhängigen Abläufe. Geänderte Aufbewahrung betrifft Datenflüsse des ausgewählten Dienstes. Mehr wiedereröffnete Fälle betreffen die Prozessverantwortung. Das Signal sollte genügend Kontext enthalten, damit seine Bedeutung beurteilt werden kann.

Bezeichnen Sie nicht jede Quellenaktualisierung als Verifizierung. Ein neues Dokument zeigt zunächst eine Quellenänderung. Es belegt nicht automatisch Rechtskonformität oder Ungeeignetheit. Eine Prüfung kann ergeben, dass die Änderung keine wesentliche Auswirkung hat. Diese Unterscheidung verhindert, dass aus einem Hinweissystem unbemerkt eine nicht autorisierte Entscheidungsinstanz wird.

Planen Sie die menschliche Arbeit. Wer erhält ein Signal, wie wird seine Dringlichkeit eingeschätzt und was geschieht bei Abwesenheit? Ein System ohne zuständigen Empfänger schließt die Governance-Lücke nicht. Ebenso wenig hilft eine Übersicht, die Meldungen zählt, aber die Klärung der zugrunde liegenden Frage nicht zeigt. Zum nützlichen Nachweis gehören Entscheidung und Grund, nicht nur die Zustellung einer Nachricht.

Wiederkehrende Hinweise verdienen eine Ursachenbetrachtung. Muss dieselbe Frage häufig manuell geklärt werden, kann eine klarere Datenquelle oder Regel erforderlich sein. Mehr Meldungen sind dann nicht automatisch besser. Ziel ist ein verlässlicher Weg von relevanter Veränderung zu angemessener Handlung mit möglichst wenig unnötigem Aufwand.

Prüfen Sie einen begrenzten Ablauf anhand beobachtbarer Eigenschaften: notwendige Befugnisse werden kontrolliert, widersprüchliche Nachweise erhalten, unerlaubte Handlungen verhindert, menschliche Eingriffe ermöglicht und wesentliche Änderungen richtig zugeordnet. Diese Eigenschaften lassen sich einzeln testen. Eine einzige Prozentzahl kann einen kritischen Fehler hinter vielen weniger wichtigen Erfolgen verstecken.

Verwenden Sie eine verständliche Freigabeaussage für den tatsächlichen Einsatz. Beispielsweise darf der Assistent anhand benannter Quellen eine Antwort vorbereiten, während der Versand bei einer bestimmten Servicerolle bleibt. Das ist handlungsnäher als ein pauschaler Reifegrad von 87 Prozent. Beschäftigte erkennen die Erlaubnis; Prüfer wissen, welche Grenze sie testen sollen. Änderungen an Zweck oder Befugnis verlangen eine neue Entscheidung.

Rekonstruieren Sie nach einer unerwarteten Handlung die Folge von Anfrage bis Auswirkung. Welche Identität wurde verwendet, welche Berechtigung galt, welche Quelle beeinflusste den Vorschlag und welches System stellte den Endzustand fest? Halten Sie auseinander, was der Assistent sagte und was extern geschah. Sonst wird möglicherweise nur die Erklärung verbessert, während die falsche Befugnis bestehen bleibt.

Bestimmen Sie den frühesten praktikablen Punkt für Verhinderung oder Begrenzung. Die Lösung kann eine klarere Quelle, eine engere Berechtigung, eine bessere Freigabeansicht oder ein unabhängiger Zustandsabgleich sein. Sie ist nicht zwangsläufig ein neues Modell. Die Korrektur gehört zur bestehenden Verantwortung für diese Aufgabe.

Prüfen Sie danach sowohl den Fehlerfall als auch einen gewöhnlichen zulässigen Vorgang. Eine Änderung, die jede nützliche Handlung blockiert, kann den Vorfall begrenzen und trotzdem weitere Betriebsarbeit verlangen. Dokumentieren Sie die neue Grenze und informieren Sie die darauf angewiesenen Menschen. Nützliches Lernen zeigt sich im veränderten Ablauf und nicht allein in einem abgelegten Bericht. Bewahren Sie die ursprüngliche Beobachtung auf, damit eine spätere Prüfung erkennen kann, welche Annahme tatsächlich korrigiert wurde.

Das Good AI Prisma unterstützt die Marktübersicht. Danach folgen quellenbezogenes Profil und Vergleich. Die AI-Estate-Demonstration zeigt, wie Systemkontext zusammenhängen kann. Sie belegt nicht, dass eine betriebliche Kontrolle in Ihrem Unternehmen installiert ist. Diese Trennung bleibt auch im Architekturgespräch wichtig.

Ein AI Trust Record kann Nachweise und Verantwortung eines benannten Systems ordnen. Ein AI Trust Pilot kann eine kontrollierte Erprobung mit ausdrücklichen Grenzen strukturieren. Bringen Sie Inventareintrag, heutigen Handlungsspielraum und die fragliche Änderung mit. Der nächste Schritt sollte eine betriebliche Entscheidung klären, statt ein bestehendes Verzeichnis durch eine weitere unverbundene Liste zu ersetzen.

Eine reife Organisation sollte Fragen wie diese beantworten können:

Welche KI-Systeme und Agenten sind hier im Einsatz? Welche Missions unterstützen sie? Auf welche Daten und Werkzeuge dürfen sie zugreifen? Welche Befugnisse wurden ihnen erteilt? Welche Handlungen erfordern eine Freigabe? Welche Belege stützen wichtige Entscheidungen? Was hat sich seit der letzten Prüfung verändert? Welche Vorfälle oder Ausnahmen sind aufgetreten? Welches Geschäftsergebnis war beabsichtigt? Welches Ergebnis wurde tatsächlich beobachtet? Welcher Wert wurde modelliert, beobachtet und zugerechnet?

Wenn diese Antworten in voneinander getrennten Tabellen, Richtlinien-PDFs und Ticketsystemen liegen, besteht die nächste Governance-Aufgabe nicht in einem weiteren Dokument.

Sie besteht darin, diese Informationen und Kontrollen zusammenzuführen.

Das ist die AI Governance Gap.