KI-Agenten werden vom Assistenten zum Akteur in der Unternehmens-IT. Damit verschiebt sich auch die Governance-Frage: Nicht mehr nur die Qualität einer Antwort zählt, sondern welche Systeme, Daten und Werkzeuge ein Agent nutzen darf – und welche Aktionen er selbstständig ausführen kann.
Wie aktuell diese Frage ist, zeigen neue Initiativen rund um die Absicherung agentischer Systeme. Das US-amerikanische NIST hat seine Arbeiten rund um Agentic AI weiter konkretisiert. Im Fokus steht unter anderem die Frage, wie KI-Agenten identifiziert, authentifiziert und autorisiert werden können. Auch OWASP adressiert mit neuen Sicherheitsstandards die Kontrolle agentischer Systeme.
Ein KI-Agent, der Tickets priorisiert, Lieferanten kontaktiert oder Code in ein Produktivsystem einspielt, ist deshalb nicht einfach ein Chatbot mit besseren Prompts. Er kombiniert Ziele, Kontext, Werkzeuge und wiederholte Entscheidungen. Genau deshalb wird Agentic AI Governance Unternehmen zunehmend beschäftigen: Es geht um Identitäten, Berechtigungen, Kontrollpunkte und nachvollziehbare Verantwortung.
Warum Agenten ein anderes Governance-Problem schaffen
Klassische generative KI erzeugt Inhalte: Text, Code, Zusammenfassungen oder Analysen. Das Risiko liegt häufig in falschen Aussagen, Urheberrechtsfragen, Datenabflüssen oder einer ungeeigneten Nutzung durch Mitarbeitende. Agentische Systeme können diese Risiken ebenfalls verursachen. Hinzu kommt jedoch eine operative Ebene: Sie planen mehrstufige Abläufe, wählen Tools aus, rufen APIs auf und bewerten Zwischenergebnisse, bevor sie weiterarbeiten.
Damit entsteht eine Kette von Entscheidungen, die sich nicht sinnvoll über eine einzelne Freigabe am Ende kontrollieren lässt. Ein Agent zur Incident-Bearbeitung kann etwa Telemetriedaten auswerten, Runbooks auswählen, Konfigurationen ändern und ein Ticket schließen. Jede dieser Aktionen kann für sich plausibel sein. Zusammengenommen kann sie trotzdem einen Ausfall verlängern, Beweise überschreiben oder eine Sicherheitslücke öffnen.
Auch die Verantwortlichkeiten werden komplexer. Das Fachteam definiert ein Ziel, die Plattform- oder Entwicklungsteams integrieren Modelle und Werkzeuge, Security verantwortet Schutzmechanismen und Compliance beurteilt regulatorische Folgen. Wenn diese Rollen erst nach dem Pilotprojekt geklärt werden, ist die Architektur meist bereits auf Geschwindigkeit statt Kontrollierbarkeit optimiert.
Agentic AI Governance im Unternehmen beginnt mit Einsatzgrenzen
Der wirksamste erste Schritt ist keine umfangreiche Policy, sondern eine belastbare Entscheidung darüber, welche Handlungen ein Agent ausführen darf. Dafür reicht die Einteilung in „intern“ und „extern“ nicht aus. Ein interner Agent mit Schreibzugriff auf eine Identitätsverwaltung kann ein höheres Risiko darstellen als ein externer Assistent, der ausschließlich öffentlich freigegebene Dokumente durchsucht.
Sinnvoll ist eine risikobasierte Betrachtung entlang von Wirkung, Berechtigung und Reversibilität. Wirkung beschreibt, was eine falsche Entscheidung auslöst: einen fehlerhaften Report, einen unberechtigten Zugriff oder eine irreversible Finanztransaktion. Berechtigung meint die Reichweite der angebundenen Systeme und Daten. Reversibilität fragt, ob ein Fehler automatisiert zurückgenommen werden kann und ob die nötigen Nachweise dafür erhalten bleiben.
Daraus lassen sich abgestufte Betriebsmodelle ableiten. Ein Agent darf Informationen recherchieren und einen Entwurf liefern. Er darf einen Vorgang vorbereiten, aber die Ausführung erst nach menschlicher Freigabe anstoßen. Oder er darf innerhalb klar definierter Grenzen selbstständig handeln, etwa bei standardisierten, reversiblen Infrastrukturaufgaben. Die höchste Autonomiestufe sollte nicht der Standard sein, nur weil die technische Integration sie ermöglicht.
Besonders kritisch sind sogenannte Delegationsketten: Ein Agent beauftragt einen weiteren Dienst, dieser ruft ein Tool auf, das wiederum Rechte im Zielsystem besitzt. Governance muss diese Kette Ende zu Ende abbilden. Andernfalls ist im Audit sichtbar, welcher Service eine Änderung durchgeführt hat, aber nicht, welches Ziel, welcher Kontext und welche Agentenentscheidung dazu geführt haben.
Auch das NIST beschäftigt sich ausdrücklich mit Identität und Autorisierung von AI Agents. Dabei geht es unter anderem um Identifikation, Autorisierung, Auditing und die Frage, wie sich nachvollziehen lässt, in wessen Auftrag ein Software-Agent handelt.
Architekturentscheidungen sind Governance-Entscheidungen
Governance wird schnell wirkungslos, wenn sie nur als Dokument existiert. Sie muss in die Agentenarchitektur übersetzt werden. Dazu gehören getrennte Identitäten pro Agent und Aufgabe, minimal nötige Berechtigungen, kurzlebige Tokens und eine eindeutige Zuordnung zwischen menschlichem Auftraggeber, Agenteninstanz und Tool-Aufruf.
Ein verbreiteter Fehler ist, einem Agenten aus Integrationsgründen ein breit berechtigtes Service-Konto zu geben. Damit wird zwar der erste Prototyp einfacher. Im Produktivbetrieb verschwimmt jedoch, ob der Agent eine zulässige Aktion ausgeführt oder lediglich eine vorhandene technische Überberechtigung genutzt hat. Least Privilege und fein granulierte Tool-Berechtigungen sind bei Agenten kein Security-Detail, sondern eine Voraussetzung für verantwortbare Autonomie.
Ebenso wichtig ist die Trennung von Planen und Ausführen. Ein Agent kann einen Maßnahmenplan erstellen, während ein separater Kontrollschritt prüft, ob die vorgeschlagenen Tool-Aufrufe zu Richtlinie, Kontext und Risiko passen. Bei sensiblen Aktionen sollte diese Prüfung nicht allein vom selben Modell abhängen, das die Aktion vorgeschlagen hat. Deterministische Regeln, Policy Engines, Freigabe-Workflows und technische Allow-Lists sind weniger elegant als ein autonomer End-to-End-Flow, aber oft besser prüfbar.
Prompt Injection zeigt, warum diese Trennung nötig ist. OWASP beschreibt damit Angriffe, bei denen manipulierte Eingaben das Verhalten eines Sprachmodells unbeabsichtigt verändern. Für Agenten ist insbesondere indirekte Prompt Injection relevant: Erhält ein Agent Inhalte aus Tickets, Webseiten, E-Mails oder Dokumenten, können darin Anweisungen verborgen sein, die seine ursprüngliche Aufgabe unterlaufen.
Gute Governance behandelt externe Inhalte deshalb als untrusted input. Sie begrenzt Werkzeuge und Berechtigungen, kontrolliert Datenausgaben, setzt Transaktionsgrenzen und verhindert, dass unbestätigte Informationen direkt privilegierte Aktionen auslösen.
Nachvollziehbarkeit: Protokolliere Entscheidungen, nicht nur Events
Übliche Logs reichen für Agenten oft nicht aus. Ein API-Log belegt, dass ein System einen Nutzer gesperrt hat. Für die Untersuchung brauchst du zusätzlich den Auftrag, die verwendete Kontextversion, das gewählte Werkzeug, die Policy-Entscheidung, die menschliche Freigabe und das Ergebnis der Aktion. Dabei geht es nicht darum, jeden internen Modellzustand vollständig rekonstruieren zu wollen. Das wäre bei probabilistischen Systemen häufig unrealistisch.
Gefordert ist eine nachvollziehbare Entscheidungskette mit ausreichender Granularität. Sie erlaubt Security-Teams, Fehlverhalten einzugrenzen, und hilft Betriebsteams, fehlerhafte Automatisierung zu korrigieren. Gleichzeitig müssen Protokolle selbst geschützt werden: Prompts und Kontexte enthalten möglicherweise personenbezogene Daten, Geschäftsgeheimnisse oder Zugangsinformationen. Logging ohne Datenklassifizierung schafft ein neues Risiko.
Messgrößen sollten über Modellqualität hinausgehen. Relevanter sind etwa die Quote blockierter Tool-Aufrufe, Überschreitungen von Berechtigungsgrenzen, Eskalationen an Menschen, Korrekturen nach Agentenaktionen und die Zeit bis zur Erkennung eines Fehlverhaltens. Eine niedrige Eskalationsrate ist nicht automatisch ein Erfolg. Sie kann auch bedeuten, dass ein Agent zu viele Entscheidungen ohne angemessene Kontrolle trifft.
Regulierung und Standards geben Orientierung, ersetzen aber keine Entscheidungen
Der EU AI Act ist für die Governance-Planung relevant. Die regulatorische Einordnung hängt dabei nicht allein davon ab, ob ein System als „Agent“ bezeichnet wird. Entscheidend sind insbesondere Funktion, Zweckbestimmung und Einsatzkontext des jeweiligen KI-Systems.
In Hochrisikobereichen können unter anderem Anforderungen an Risikomanagement, technische Dokumentation, Protokollierung, menschliche Aufsicht und Qualitätsmanagement relevant werden. Für Anbieter von General-Purpose-AI-Modellen bestehen wiederum eigene Transparenz- und Dokumentationspflichten.
Als Strukturhilfen eignen sich das NIST AI Risk Management Framework und ISO/IEC 42001. Sie liefern gemeinsame Begriffe und Managementmechanismen, etwa für Risikobewertung, Verantwortlichkeiten und kontinuierliche Verbesserung. Sie beantworten aber nicht, ob dein Incident-Agent Produktionszugriffe erhalten soll. Diese Entscheidung bleibt kontextabhängig und muss von Risikoappetit, Architektur und Betriebsfähigkeit getragen werden.
Datenschutz, Informationssicherheit und Auslagerungsmanagement gehören dabei nicht in getrennte Prüfspuren. Wenn ein Agent auf personenbezogene Daten zugreift, externe Modelle nutzt oder Tools eines SaaS-Anbieters ansteuert, treffen Datenflüsse, Auftragsverarbeitung, Zugriffsmodelle, Löschkonzepte und Exit-Szenarien unmittelbar aufeinander.
Gerade bei Multi-Agent-Architekturen lohnt sich deshalb ein klares Inventar: Welche Agenten, Modelle, Tools, Datenquellen und externen Dienste sind beteiligt? Welche Identitäten und Berechtigungen besitzen sie? Und welche Abhängigkeiten entstehen entlang der gesamten Agentenkette?
Ein Betriebsmodell, das Innovation nicht ausbremst
Zentrale Freigaben für jeden Prompt würden Teams lähmen. Vollständig dezentrale Experimente erzeugen dagegen Schattenagenten mit unbekannten Berechtigungen. Praktikabel ist ein föderiertes Modell: Eine zentrale Funktion definiert Mindeststandards, Risikoklassen, Referenzarchitekturen und Prüfprozesse. Produkt- und Plattformteams verantworten die konkrete Umsetzung, Tests und den sicheren Betrieb in ihrem Kontext.
Für neue Use Cases sollte ein kurzer, verbindlicher Intake genügen: Geschäftsziel, betroffene Daten, angebundene Tools, vorgesehene Handlungsrechte, menschliche Eingriffspunkte, Abbruchkriterien und verantwortliche Rollen. Bei hohem Risiko folgt eine vertiefte Prüfung. Bei niedrigem Risiko ermöglicht ein standardisierter „read-only“-Pfad schnelle Experimente.
Entscheidend ist, dass Teams wissen, wie sie rechtssicher und technisch sauber vorankommen – nicht nur, wo sie gestoppt werden.
Was IT-Verantwortliche jetzt prüfen sollten
Vier Fragen bieten einen pragmatischen Einstieg in die Agentic AI Governance:
- Identitäten: Hat jeder produktiv eingesetzte Agent eine eindeutig zuordenbare Identität und lässt sich nachvollziehen, in wessen Auftrag er handelt?
- Berechtigungen: Sind Zugriffe auf Tools, Daten und Systeme nach dem Least-Privilege-Prinzip begrenzt – oder nutzt der Agent breit berechtigte Service-Konten?
- Kontrollpunkte: Welche Aktionen darf ein Agent autonom ausführen, wann ist eine menschliche Freigabe erforderlich und welche Aktionen sind grundsätzlich ausgeschlossen?
- Nachvollziehbarkeit: Lässt sich im Nachhinein rekonstruieren, warum eine Aktion ausgeführt wurde, welche Informationen und Policies zugrunde lagen und welche Systeme oder weiteren Agenten beteiligt waren?
Agentic AI Governance ist damit keine Bremse vor dem Produktivstart. Sie ist die Disziplin, durch die aus einem überzeugenden Demo-Agenten ein betreibbares System wird.
Beginne dort, wo Autonomie auf echte Rechte trifft: bei Identitäten, Werkzeugen, Daten und klaren Eskalationspunkten. Genau an dieser Stelle entscheidet sich, ob dein Unternehmen KI-Agenten kontrolliert erweitert oder später mühsam wieder einfangen muss.
