Die Governance von KI-Agenten in Unternehmen verlagert sich von Richtlinien zu Laufzeitkontrollen
Die Governance von KI-Agenten in Unternehmen hat ihre erste operative Grenze überschritten: Richtliniendokumente allein können Software, die eigenständig reale Aktionen ausführt, nicht kontrollieren. Das aufkommende Modell verlagert die Durchsetzung in den Moment, bevor ein Agent Daten sendet, einen Datensatz ändert, ein Tool aufruft oder Geld ausgibt.
Dieser Wandel bildet das Kernargument der jüngsten Point-of-Action-These. Governance beschränkt sich nicht länger darauf, ein Modell zu genehmigen, seine Risiken zu dokumentieren oder seine Ergebnisse nach der Bereitstellung zu prüfen. Sie wird zunehmend zu einem Problem der Laufzeitsicherheit.
Der Druck liegt bei Sicherheitsteams, Identitätsanbietern, Anwendungsverantwortlichen und jedem Anbieter, der Agentenplattformen entwickelt. Der Konflikt ist eindeutig: Unternehmen wollen, dass Agenten längere Workflows mit weniger Aufsicht abschließen, während Sicherheitsteams sicherstellen müssen, dass jede folgenschwere Aktion zurechenbar und reversibel bleibt.
Dies ist keine weitere Debatte darüber, ob künstliche Intelligenz Regeln braucht. Die dringendere Frage lautet, wo diese Regeln greifen müssen. Bei autonomen Systemen liegt die Antwort zunehmend unmittelbar an der Aktion selbst.
Was sich bei der Governance von KI-Agenten in Unternehmen geändert hat
Das Governance-Objekt ist nicht länger nur ein Modell oder eine Anwendung. Es ist eine handelnde Identität mit Tools, Speicher, Berechtigungen und wechselndem Kontext.
Traditionelle KI-Aufsicht konzentriert sich auf eine relativ stabile Abfolge. Eine Person gibt eine Eingabe ein, ein Modell erzeugt eine Ausgabe, und jemand prüft oder nutzt diese Ausgabe. Governance kann das Modell, seine Trainingsdaten, den vorgesehenen Einsatz, Evaluierungsergebnisse und generierte Inhalte untersuchen.
Ein KI-Agent verändert diese Abfolge. Er kann ein Ziel in Schritte zerlegen, Tools auswählen, Informationen abrufen, externe Dienste aufrufen und Systeme verändern. Er kann diesen Prozess auch wiederholen, bis er das Ziel für erreicht hält.
Jeder Schritt kann das Risiko des nächsten verändern. Eine harmlose Anfrage zur Zusammenfassung von Kundenfeedback wird sensibler, wenn der Agent eine Kundendatenbank öffnet. Das Risiko ändert sich erneut, wenn er Datensätze exportiert, Nachrichten entwirft oder diese ohne Prüfung versendet.
Dadurch entsteht eine Lücke zwischen der Genehmigung zur Entwicklungszeit und dem Verhalten zur Laufzeit. Ein Governance-Gremium kann einen Agenten für den Vertriebsservice genehmigen, doch diese Bezeichnung sagt wenig über eine konkrete Datenbankabfrage aus. Sie kann auch nicht bestimmen, ob eine bestimmte E-Mail um 2 Uhr morgens über ein Führungskräftekonto gesendet werden sollte.
Das NIST AI framework bietet Organisationen eine breite Struktur, um KI-Risiken zu steuern, abzubilden, zu messen und zu managen. Diese Struktur bleibt nützlich, doch Agenten zwingen Teams dazu, ihre Prinzipien mit deutlich höherer Granularität umzusetzen.
Eine Risikoklassifizierung für eine gesamte Anwendung kann nicht jede Laufzeitfrage beantworten. Das System muss wissen, wer die Aufgabe angefordert hat, welcher Agent handelt, auf welche Daten er zugegriffen hat und welches Tool er ausgewählt hat. Es muss außerdem wissen, ob die angeforderte Aktion die Befugnisse des Nutzers überschreitet.
Das ist die praktische Bedeutung von Point-of-Action-Governance. Eine Kontrolle bewertet eine versuchte Aktion anhand aktueller Signale zu Identität, Berechtigung, Daten und Umgebung. Anschließend lässt sie die Aktion zu, blockiert, begrenzt oder eskaliert sie.
Die Kontrolle könnte eine menschliche Genehmigung verlangen, bevor Geld bewegt wird. Sie könnte sensible Felder schwärzen, bevor Informationen ein Modell erreichen. Sie könnte einen Agenten daran hindern, eine externe E-Mail-Adresse anzuschreiben, selbst wenn derselbe Agent einen internen Entwurf erstellen darf.
Diese Entscheidungen müssen während der Ausführung getroffen werden. Eine vierteljährliche Richtlinienprüfung kann einen gefährlichen API-Aufruf nicht unterbrechen. Ein Audit nach der Bereitstellung kann einen Vorfall erklären, aber die ursprüngliche Aktion nicht verhindern.
Der Wandel verändert auch, was als Nachweis gilt. Organisationen benötigen mehr als einen Eintrag, der zeigt, dass ein Agent genehmigt wurde. Sie benötigen Protokolle, die die ursprüngliche Anfrage mit den Entscheidungen des Modells, Tool-Aufrufen, abgerufenen Daten, Genehmigungen und dem Endergebnis verknüpfen.
Diese Kette ist wichtig, wenn ein Agent über mehrere Dienste hinweg arbeitet. Ein Workflow kann in einer Chat-Oberfläche beginnen, einen Vertrag abrufen, einen Kundendatensatz aktualisieren und eine Zahlungsanforderung erstellen. Jeder Übergang schafft einen weiteren Punkt, an dem sich Befugnisse ausweiten oder Kontext verloren gehen kann.
Point-of-Action-Governance behandelt diese Übergänge als Sicherheitsgrenzen. Der Ansatz setzt nicht voraus, dass ein genehmigter Agent während eines gesamten Workflows sicher bleibt. Er prüft, ob jede wesentliche Aktion weiterhin zum ursprünglichen Zweck und zur delegierten Befugnis passt.
Warum statische KI-Richtlinien zur Laufzeit die Kontrolle verlieren
Eine schriftliche Richtlinie beschreibt akzeptables Verhalten, doch ein autonomer Workflow benötigt vor jedem folgenschweren Schritt durchsetzbare Entscheidungen.
Statische Governance ist am wirksamsten, wenn Systeme vorhersehbar agieren. Teams können genehmigte Anwendungsfälle definieren, sensible Eingaben verbieten, einen festen Workflow testen und Mitarbeitende schulen. Diese Maßnahmen werden weniger zuverlässig, wenn ein Agent seinen eigenen Weg durch verbundene Tools wählt.
Ein Agent kann mit einem zulässigen Ziel beginnen und dennoch eine unzulässige Aktion ausführen. Er kann eine Anweisung missverstehen, bösartige Inhalte aus einem Dokument befolgen oder einzeln harmlose Berechtigungen kombinieren. Die daraus entstehende Fähigkeit kann über das hinausgehen, was eine einzelne Berechtigung vermuten lässt.
Prompt Injection veranschaulicht dieses Problem. Eine feindliche Anweisung kann innerhalb einer Webseite, E-Mail, eines Dokuments oder Support-Tickets erscheinen, das der Agent abruft. Der Inhalt weist den Agenten an, sein ursprüngliches Ziel zu ignorieren, Informationen offenzulegen oder ein weiteres Tool zu aktivieren.
Ein herkömmlicher Filter kann den anfänglichen Prompt des Nutzers prüfen und nichts Gefährliches finden. Die schädliche Anweisung gelangt später hinein, nachdem der Workflow bereits begonnen hat. Governance muss dem Agenten daher durch seine Kontextwechsel folgen.
Die OWASP agentic guidance beschreibt Risiken wie übermäßige Handlungsbefugnisse, Tool-Missbrauch, Manipulation des Speichers, kaskadierende Ausfälle und kompromittierte Interaktionen zwischen Agenten. Dies sind Ausführungsrisiken, nicht lediglich unerwünschte Textausgaben.
Übermäßige Handlungsbefugnisse entstehen, wenn ein Agent mehr Autorität erhält, als seine Aufgabe erfordert. Ein Terminassistent muss möglicherweise Kalender lesen und Besprechungszeiten vorschlagen. Selten benötigt er uneingeschränkten Zugriff, um Termine zu löschen, externe Teilnehmer einzuladen oder jeden privaten Anhang zu lesen.
Die Unterscheidung klingt einfach, bis Workflows dynamisch werden. Ein Agent kann für eine Aufgabe berechtigterweise erweiterten Zugriff benötigen, für eine andere jedoch nicht. Dauerhafte, weitreichende Berechtigungen lösen das operative Problem, schaffen jedoch eine fortlaufende Sicherheitslücke.
Laufzeitkontrollen bieten einen anderen Ansatz. Das System kann nach Bewertung der Aufgabe und ihres Kontexts eine eng begrenzte, temporäre Autorisierung ausstellen. Diese Autorisierung kann nach einer Aktion ablaufen oder eine Genehmigung verlangen, wenn sich der angeforderte Umfang ändert.
Dasselbe Prinzip gilt für Daten. Ein Agent, der eine Quartalszusammenfassung erstellt, benötigt möglicherweise aggregierte Umsatzinformationen, aber nicht die persönlichen Datensätze aller Kunden. Eine Kontrolle nahe der Datenquelle kann einschränken, was der Agent abruft, bevor das Modell die Daten überhaupt sieht.
Das ist wichtig, weil Schutzmaßnahmen auf Modellebene nur eine Schicht darstellen. Ein Modell kann angewiesen werden, keine sensiblen Informationen preiszugeben, doch Anweisungen können miteinander in Konflikt geraten oder versagen. Datenminimierung und Tool-Autorisierung verringern die Folgen, wenn das Verhalten des Modells unzuverlässig wird.
Der Laufzeitansatz trennt zudem risikoarmes Denken von risikoreicher Ausführung. Ein Agent kann Optionen analysieren, eine Empfehlung entwerfen und eine Aktion simulieren, ohne die Berechtigung zu erhalten, sie auszuführen. Die Befugnis wird erst erteilt, wenn der Workflow eine kontrollierte Grenze erreicht.
Menschliche Genehmigung bleibt wichtig, kann jedoch nicht zur universellen Antwort werden. Für jeden Tool-Aufruf eine Genehmigung zu verlangen, nimmt Agenten einen großen Teil der versprochenen Effizienz. Es kann auch zu Genehmigungsmüdigkeit führen, bei der Menschen Anfragen akzeptieren, ohne ihren Kontext zu prüfen.
Gute Governance reserviert Eingriffe für wesentliche Schwellenwerte. Das Lesen einer öffentlichen Produktseite kann automatisch erfolgen. Der Export von Kundendatensätzen, Änderungen an Produktionscode oder das Versenden von Geld sollten strengere Prüfungen auslösen.
Die genaue Grenze hängt von der Organisation und der Aufgabe ab. Der Mechanismus bleibt jedoch konsistent: Bewerten Sie die Aktion, ihr Ziel, ihren Auslöser und ihre potenziellen Auswirkungen. Wenden Sie dann die engste Befugnis an, die legitime Arbeit fortsetzen lässt.
Das generative AI profile von NIST betont das Risikomanagement über den gesamten KI-Lebenszyklus hinweg. Agentische Systeme erweitern diesen Lebenszyklus zu einer Kette von Entscheidungen, die unmittelbare Auswirkungen haben können.
Governance ähnelt daher weniger der Veröffentlichung eines Regelwerks als dem Betrieb eines Autorisierungssystems. Richtlinien definieren weiterhin, was geschehen soll. Laufzeitkontrollen übersetzen diese Richtlinien in technische Entscheidungen, die getroffen werden, bevor Folgen real werden.
Identität wird zur Kontrollinstanz für KI-Agenten
Ein Agent benötigt eine eigene, nachvollziehbare Identität, weil übernommene Mitarbeiteranmeldedaten die Rechenschaftspflicht aufheben und jede nachgelagerte Kontrolle schwächen.
Viele frühe Agenten arbeiten über das bestehende Konto eines menschlichen Nutzers. Der Agent übernimmt eine Sitzung, ein API-Token oder eine Service-Anmeldung. Dieses Design erleichtert Prototypen, schafft jedoch Unklarheit bei Untersuchungen und Zugriffsprüfungen.
Ein Systemprotokoll kann zeigen, dass ein Mitarbeiter eine Datei heruntergeladen hat. Es zeigt möglicherweise nicht, ob die Person den Download selbst ausgelöst hat, ein genehmigter Agent sie abgerufen hat oder ein kompromittierter Workflow über ihr Konto handelte. Dem Autorisierungsnachweis fehlt der tatsächliche Akteur.
Eine separate Agentenidentität löst einen Teil dieses Problems. Sie ermöglicht Administratoren, dem Agenten Berechtigungen zuzuweisen, sein Verhalten zu überwachen und seinen Zugriff zu widerrufen, ohne den menschlichen Sponsor zu deaktivieren. Sie erlaubt außerdem Richtlinien, menschliche Aktionen von Maschinenaktionen zu unterscheiden.
Die Identität muss weiterhin mit einer verantwortlichen Person oder einem Geschäftsprozess verbunden sein. Andernfalls schaffen Organisationen eine wachsende Population von Maschinenkonten ohne klaren Eigentümer. Ruhende Agenten können dann noch lange nach dem Ende ihres ursprünglichen Projekts Zugriff behalten.
Microsoft hat Agent ID controls als Identitätsschicht zum Erkennen, Steuern und Absichern von Agenten vorgestellt. Die Richtung spiegelt eine breitere Branchenauffassung wider: Agenten benötigen ein Lebenszyklusmanagement, das mit anderen nichtmenschlichen Identitäten vergleichbar ist.
Die Erkennung steht an erster Stelle, weil Sicherheitsteams keine Agenten steuern können, die sie nicht sehen. Fachbereiche können Agenten in Softwareplattformen, Low-Code-Systemen, Entwicklungsframeworks und Cloud-Diensten erstellen. Jeder Weg kann eine weitere Identität, ein weiteres Token oder eine weitere Integration hervorbringen.
Die Registrierung sollte Eigentümer, Zweck, Umgebung, genehmigte Tools und erwarteten Datenzugriff des Agenten erfassen. Sie sollte außerdem dokumentieren, ob der Agent automatisch handeln darf oder eine Bestätigung benötigt. Diese Attribute geben Laufzeitsystemen eine Grundlage für die Autorisierung.
Die Authentifizierung beantwortet, ob der Aufrufer der registrierte Agent ist. Die Autorisierung beantwortet, ob dieser Agent diese Aktion unter diesen Bedingungen ausführen darf. Governance scheitert, wenn Teams die erste Frage lösen, für die zweite jedoch weitreichenden, dauerhaften Zugriff gewähren.
Kontext macht Autorisierungen präziser. Eine Richtlinie kann den anfragenden Nutzer, den Gerätezustand, die Datenklassifizierung, das Ziel, den Transaktionswert und das jüngste Agentenverhalten prüfen. Sie kann dann unterschiedliche Kontrollen anwenden, ohne den gesamten Agenten neu zu definieren.
Ein Assistent darf während der normalen Arbeit die eigenen Besprechungsnotizen eines Mitarbeiters lesen. Dieselbe Anfrage sollte genauer geprüft werden, wenn sie auf eingeschränkte Dateien einer anderen Abteilung zielt. Ein plötzlicher Massendownload sollte anders bewertet werden als der Abruf eines einzelnen Dokuments.
Speicher bringt ein weiteres Identitätsproblem mit sich. Agenten können Aufgabenverläufe, Präferenzen, abgerufene Fakten und Zwischenergebnisse speichern. Dieser Speicher kann nach Ende der ursprünglichen Nutzersitzung bestehen bleiben und dennoch spätere Aktionen bei einer anderen Anfrage beeinflussen.
Teams müssen wissen, welche Identität den Speicher besitzt und wer ihn verändern darf. Sie benötigen außerdem Herkunftsnachweise, also Aufzeichnungen darüber, woher gespeicherte Informationen stammen und wie sie verändert wurden. Ohne Herkunftsnachweise kann manipuliertes Gedächtnis spätere Workflows unbemerkt umlenken.
Wissenssysteme können einen sichereren Abruf unterstützen, wenn sie Quellgrenzen und Zugriffskontrollen bewahren. Eine Engineering-Wissensdatenbank ist am nützlichsten, wenn ein Agent nur die Dokumente erhält, auf die sein aktueller Anfragender zugreifen darf.
Multi-Agenten-Workflows machen Identität noch wichtiger. Ein Agent kann Recherche an einen anderen delegieren und anschließend einen dritten Agenten bitten, ein System zu aktualisieren. Der empfangende Dienst muss wissen, ob die delegierte Befugnis entlang dieser Kette weiterhin gültig ist.
Delegation sollte nicht versehentlich neue Privilegien schaffen. Wenn der erste Agent keine Zahlung genehmigen darf, sollte ein delegierter Agent diese Fähigkeit nicht erhalten. Jede Übertragung sollte die ursprünglichen Grenzen, den Zweck und das Ablaufdatum bewahren.
Diese Anforderung ähnelt etablierten Konzepten der Identitätssicherheit, doch Agenten bringen ungewöhnliche Geschwindigkeit und Skalierung mit sich. Ein Mensch kann während einer Sitzung mehrere sensible Aktionen durchführen. Ein automatisierter Agent kann viele Aktionen über mehrere Systeme hinweg auslösen, bevor ein Prüfer dies bemerkt.
Die Kontrollebene muss Identität daher mit Ratenbegrenzungen, Verhaltensüberwachung und Transaktionsrichtlinien verbinden. Identität zeigt der Organisation, wer gehandelt hat. Runtime Governance bestimmt, ob dieser Akteur weitermachen darf.
Kontrolle am Ausführungspunkt bringt eigene Zielkonflikte mit sich
Runtime-Durchsetzung verringert unkontrollierte Befugnisse, führt jedoch auch zu Latenz, komplexeren Richtlinien, Integrationsrisiken und neuen Kontrollpunkten, die Angreifer ins Visier nehmen können.
Die stärkste Fassung des Governance-Arguments kann täuschend vollständig wirken. Jeder Agent erhält eine Identität, jede Aktion wird bewertet, jede Entscheidung protokolliert und für gefährliche Vorgänge wird eine Genehmigung verlangt. In der Praxis kann jede Komponente versagen.
Die Qualität der Richtlinien ist die erste Einschränkung. Eine Runtime-Engine kann keine Absichten durchsetzen, die Teams nicht in präzise Regeln übersetzt haben. Begriffe wie sensibel, angemessen, wesentlich oder vertrauenswürdig erfordern oft geschäftliches Urteilsvermögen, das sich zwischen Abteilungen unterscheidet.
Zu weit gefasste Regeln lassen gefährliche Aktionen zu. Zu strenge Regeln unterbrechen legitime Arbeit und ermutigen Mitarbeiter, das System zu umgehen. Die Organisation muss Richtlinien anhand realer Workflows abstimmen, nicht allein anhand abstrakter Risikokategorien.
Auch der Kontext kann unvollständig sein. Ein Sicherheitsdienst sieht möglicherweise eine API-Anfrage, ohne die Unterhaltung zu verstehen, aus der sie entstanden ist. Ein Model-Gateway versteht vielleicht den Prompt, verfügt jedoch nicht über Informationen zur Datenklassifizierung des Zielsystems.
Angreifer können diese Lücken ausnutzen. Sie können ein verbotenes Ziel in mehrere erlaubte Aktionen aufteilen. Jeder Schritt wirkt bei isolierter Prüfung harmlos, während die vollständige Abfolge zu einem nicht autorisierten Ergebnis führt.
Kontrollen, die Sequenzen berücksichtigen, können einige Muster erkennen, benötigen jedoch umfangreicheren Zustand und längere Aufbewahrung. Das schafft Datenschutz- und Betriebsbedenken. Detaillierte Traces können Mitarbeiteranfragen, Kundendaten, Modellausgaben und vertrauliche Geschäftsentscheidungen enthalten.
Organisationen müssen Governance-Telemetrie genauso sorgfältig schützen wie die Systeme, die sie überwacht. Ein kompromittiertes Protokoll kann einen Angriff verbergen oder einen Nutzer fälschlich belasten. Ein offengelegter Trace kann genau die Informationen preisgeben, die die Kontrollen schützen sollten.
Die Leistung stellt einen weiteren Zielkonflikt dar. Ein Agent kann zur Erledigung einer Aufgabe viele kleine Tool-Aufrufe ausführen. Jeden Aufruf durch mehrere Richtlinien-Engines zu leiten, kann Verzögerungen, Kosten und zusätzliche Fehlerpunkte verursachen.
Risikobasierte Durchsetzung kann diese Belastung verringern. Reversible Aktionen mit geringer Auswirkung erhalten schlanke Prüfungen. Aktionen mit hoher Auswirkung oder irreversiblen Folgen erhalten stärkere Autorisierung, umfangreichere Protokollierung oder menschliche Prüfung.
Diese Unterscheidung erfordert eine sorgfältige Klassifizierung. Einen Entwurf an eine interne Prüfwarteschlange zu senden, ist reversibel. Den gleichen Text für Kunden zu veröffentlichen, ist es nicht. Das Lesen eines Kundendatensatzes unterscheidet sich vom Export einer gesamten Datenbank.
Agenten können sich auch nach Modellaktualisierungen anders verhalten. Ein neues Modell kann Tools in einer anderen Reihenfolge auswählen, andere Argumente erzeugen oder mehr Schritte versuchen. Bestehende Richtlinien könnten das neue Verhalten blockieren oder einen neu eingeführten Pfad übersehen.
Das macht kontinuierliche Tests zu einem Bestandteil der Governance. Teams sollten repräsentative Workflows mit aktualisierten Modellen, Tools und Richtlinien erneut ausführen. Tests sollten gegnerische Dokumente, mehrdeutige Anweisungen, entzogene Berechtigungen und nicht verfügbare Dienste einschließen.
Interoperabilität schafft eine weitere Unsicherheit. Die Branche entwickelt Protokolle, die Agenten beim Erkennen von Fähigkeiten und bei der Kommunikation über Systeme hinweg helfen. Google führte sein Agent2Agent-Protokoll ein, um die Zusammenarbeit zwischen Agenten aus unterschiedlichen Frameworks zu unterstützen.
Interoperabilität kann Integrationsaufwand senken, erweitert aber auch Vertrauensbeziehungen. Ein lokaler Agent kann sich auf die Beschreibung eines Remote-Agenten zu dessen Fähigkeiten, Identität oder erledigter Arbeit verlassen. Diese Behauptung benötigt technische Verifizierung.
Ein gemeinsames Protokoll schafft nicht automatisch gemeinsame Governance. Organisationen brauchen weiterhin Regeln für die Annahme delegierter Aufgaben, die Übertragung sensiblen Kontexts und die Validierung zurückgelieferter Ergebnisse. Sie müssen entscheiden, welche Remote-Agenten innerhalb welcher Vertrauensgrenze liegen.
Anbieterkonzentration stellt ein verwandtes Risiko dar. Wenn eine Identitäts- oder Richtlinienplattform jede Agentenaktion vermittelt, kann ein Ausfall kritische Workflows stoppen. Ein Konfigurationsfehler kann eine gesamte Organisation blockieren oder im großen Maßstab übermäßige Zugriffe gewähren.
Teams benötigen vor der Bereitstellung ein Fallback-Verhalten. Einige Aktionen sollten fail closed erfolgen, das heißt, das System blockiert sie, wenn eine Kontrolle nicht verfügbar ist. Andere Vorgänge mit geringem Risiko können mit strengeren Grenzen und verbesserter Protokollierung fortgesetzt werden.
Governance am Ausführungspunkt sollte daher als mehrschichtige Verteidigung und nicht als Garantie betrachtet werden. Sie funktioniert am besten zusammen mit eingeschränkten Tools, minimalem Datenzugriff, isolierter Ausführung, Ausgabevalidierung, Überwachung und Incident Response.
Die skeptische Schlussfolgerung ist einfach. Kontrollen näher an die Ausführung zu verlagern, verbessert die Fähigkeit der Organisation, Schaden zu verhindern. Es macht autonomes Verhalten nicht vorhersehbar und ersetzt auch nicht die Prüfung zur Entwurfszeit.
Der Druck reicht über Sicherheitsteams hinaus
Die Governance von KI-Agenten zwingt Anwendungsanbieter und Geschäftsverantwortliche dazu, Kontrollen offenzulegen, die Sicherheitsteams nicht außerhalb des Workflows ergänzen können.
Ein Sicherheitsteam kann Identitäten und Netzwerkzugriff verwalten, versteht jedoch nicht immer die geschäftliche Bedeutung einer Anwendung. Ein API-Aufruf, der ein Feld verändert, kann eine Rückerstattung genehmigen, ein Dokument veröffentlichen oder ein Kundenkonto schließen.
Anwendungsanbieter müssen folgenreiche Aktionen kennzeichnen und Autorisierungspunkte um sie herum bereitstellen. Sie müssen außerdem genügend Kontext zurückgeben, damit Richtliniensysteme eine Vorschau von einer verbindlichen Aktion unterscheiden können. Ohne diese Details bleibt die Durchsetzung grob.
Anbieter von Agentenplattformen haben eine ähnliche Verpflichtung. Sie benötigen dauerhafte Aufzeichnungen über Planungsschritte, Tool-Auswahlen, Argumente, Antworten und Genehmigungen. Sicherheitsteams müssen diese Aufzeichnungen durchsuchen können, ohne uneingeschränkte Chain-of-Thought-Daten offenzulegen.
Modellanbieter bleiben für Schutzmaßnahmen, Evaluierungen und vorhersehbares Verhalten bei der Tool-Nutzung verantwortlich. Sie können jedoch nicht die Autorisierungsrichtlinien jedes Kunden festlegen. Dieselbe Modellaktion kann in einer Umgebung harmlos und in einer anderen verboten sein.
Geschäftsverantwortliche müssen diese Unterschiede definieren. Finanzverantwortliche wissen, welche Transaktionen Funktionstrennung erfordern. Personalteams wissen, welche Mitarbeiterdaten strengeren Zugriff benötigen. Rechtsteams wissen, wann ein erzeugter Entwurf zu einer offiziellen Kommunikation wird.
Entwickler übersetzen diese Anforderungen dann in technische Grenzen. Sie entscheiden, welche Tools der Agent aufrufen kann, welche Parameter er liefern darf und welche Antworten er erhalten kann. Sie bestimmen auch, was geschieht, wenn eine Kontrolle einen Schritt ablehnt.
Diese Aufteilung der Verantwortung erzeugt Druck, weil kein Beteiligter das Problem allein lösen kann. Identitätsplattformen fehlt die vollständige Bedeutung der Aufgabe. Anwendungsanbietern fehlt der vollständige organisatorische Kontext. Modellanbieter haben keine Befugnis über Kundenrichtlinien.
Die schwächste Integration kann die gesamte Kette untergraben. Ein Agent kann eine starke Identität haben, aber ein Tool über ein gemeinsames Servicekonto aufrufen. Ein Tool kann Berechtigungen durchsetzen, aber nicht validierte Anweisungen aus einem externen Dokument akzeptieren.
Beschaffungsteams sollten von Agentenanbietern konkretere Antworten erwarten. Eine allgemeine Aussage zu verantwortungsvoller KI reicht nicht aus. Käufer müssen wissen, wie das Produkt Identitäten, Delegation, Genehmigungen, Protokolle, Speicher und Widerruf behandelt.
Sie sollten außerdem fragen, ob die Kontrollen über Connectoren hinweg wirksam bleiben. Ein Agent kann Einschränkungen innerhalb seiner primären Plattform respektieren, sie jedoch verlieren, wenn er einen Drittanbieterdienst aufruft. Die Berechtigungsvererbung muss diesen Übergang überstehen.
Die operative Verantwortung ist nach dem Kauf wichtig. Jemand muss Zugriffe prüfen, Anomalien untersuchen, ungenutzte Agenten entfernen und Richtlinien aktualisieren, wenn sich Workflows ändern. Ein Agenteninventar ohne Betriebsprozess wird zu einer weiteren veralteten Asset-Liste.
Entwickler und Wissensarbeiter sollten sich dafür interessieren, weil strengere Governance die Produkterfahrung prägen wird. Einige Agenten werden vor sensiblen Aktionen pausieren. Andere werden Vorschauen, eingeschränkte Modi oder explizite Berechtigungsanfragen anbieten.
Diese Unterbrechungen sind nicht immer Fehler. Ein sichtbarer Genehmigungsschritt kann verdeutlichen, was ein Agent beabsichtigt und welche Daten er verwenden wird. Er gibt dem Nutzer die Möglichkeit, ein missverstandenes Ziel vor der Ausführung zu erkennen.
Schlecht gestaltete Kontrollen führen zum gegenteiligen Ergebnis. Wiederholte vage Aufforderungen werden Nutzer darauf trainieren, Anfragen automatisch zu genehmigen. Die Oberfläche muss die konkrete Aktion, das Ziel, den Umfang und die Folge in klarer Sprache erklären.
Der Marktdruck begünstigt daher Produkte, die nützliche Autonomie mit verständlichen Grenzen verbinden. Die reine Aufgabenerledigung bleibt wichtig. Vertrauenswürdige Delegation wird ebenso wichtig werden, wenn Agenten Zugriff auf wertvolle Systeme erhalten.
Drei Signale werden zeigen, ob Runtime Governance funktioniert
Der nächste Test ist keine weitere Richtlinienankündigung. Entscheidend ist, ob Identität, Autorisierung und Nachweise über reale mehrstufige Workflows hinweg intakt bleiben.
Das erste Signal ist die Einführung separater Agentenidentitäten auf großen Unternehmensplattformen. Zu den wichtigen Nachweisen gehören Lifecycle-Kontrollen, benannte Verantwortliche, eng gefasste Berechtigungen, Ablaufdaten und Widerruf.
Eine Produktbezeichnung allein wird nicht genügen. Sicherheitsteams müssen einen Agenten sowohl von seinem unterstützenden Mitarbeiter als auch von den Servicekonten hinter seinen Tools unterscheiden können. Breitere Unterstützung würde die These der Runtime Governance stärken.
Das zweite Signal ist die Durchsetzung an Anwendungsgrenzen. Anbieter von Unternehmenssoftware sollten Richtlinien für folgenreiche Aktionen bereitstellen, einschließlich externer Nachrichten, Datensatzänderungen, Code-Bereitstellungen und Finanzvorgänge.
Beobachten Sie, ob diese Kontrollen den Geschäftskontext verstehen oder lediglich Texte filtern. Kontextbewusste Autorisierung würde zeigen, dass Governance in die Ausführung übergegangen ist. Allgemeine Warnungen und optionale Protokolle würden darauf hindeuten, dass dieser Wandel noch unvollständig ist.
Das dritte Signal sind Erkenntnisse aus Fehlern und unabhängigen Tests. Forschende sollten Prompt Injection, delegierte Befugnisse, manipulierte Speicher, übermäßige Berechtigungen und Interaktionen zwischen Remote-Agenten testen.
Transparente Incident-Berichte werden ebenso wichtig sein wie erfolgreiche Demonstrationen. Sie können aufzeigen, ob Kontrollen schädliche Handlungen blockiert, ihren Umfang begrenzt oder Schäden lediglich im Nachhinein dokumentiert haben. Wiederholte Umgehungen würden Behauptungen schwächen, dass die Durchsetzung am Handlungspunkt ausgereift ist.
In den kommenden Monaten sollten Käufer Anbieter bitten, eine vollständige Kette zu demonstrieren. Beginnen Sie mit einem benannten Nutzer, delegieren Sie eine klar begrenzte Aufgabe, rufen Sie geschützte Daten ab, verwenden Sie ein Tool, verlangen Sie eine Genehmigung und entziehen Sie den Zugriff.
Untersuchen Sie anschließend die Nachweise. Kann der Anbieter zeigen, wer die Aufgabe initiiert hat, welcher Agent gehandelt hat, worauf er zugegriffen hat, welche Richtlinie galt und ob die Delegation die Befugnisse verändert hat?
Die Governance von KI-Agenten in Unternehmen wird nur dann erfolgreich sein, wenn diese Antworten realen Implementierungen standhalten. Wenn Ihre Organisation Agenten pilotiert, identifizieren Sie in jedem Workflow die erste irreversible Handlung. Platzieren Sie dort die stärkste Kontrolle, testen Sie den Ablehnungspfad und stellen Sie sicher, dass jede Entscheidung nachvollziehbar zugeordnet werden kann.
