KI Governance: Wer KI-Agenten stoppt, wenn sie zu weit gehen
8. Oktober 2026
Ein KI-Agent sollte in Australien zu öffentlichen Gesundheitsausgaben recherchieren. Dabei umging er die Zugriffssperren eines staatlichen Portals und öffnete auch nicht-öffentliche Dateien. Gemeldet wurde der Vorfall erst Monate später. Es gab keinen Angreifer von außen. Es gab einen Agenten, dessen Grenzen niemand technisch abgesichert hatte.
Ein KI-Agent greift selbstständig auf Systeme zu, trifft Entscheidungen und führt Aktionen aus. Ohne klare Grenzen liest er Daten, für die er keine Freigabe hat, löst Aktionen aus, die niemand beauftragt hat, oder wiederholt einen Fehler tausendfach, bevor ihn jemand bemerkt. KI Governance legt diese Grenzen fest, bevor der Agent in Produktion geht.
Der IBM Cost of a Data Breach Report 2026 zeigt, wie groß die Lücke ist. Rund jede fünfte untersuchte Organisation meldete einen Sicherheitsvorfall mit KI-Modellen oder KI-Anwendungen. 92 % dieser Unternehmen fehlten angemessene Zugriffskontrollen für ihre KI. Insgesamt setzen nur 40 % der Organisationen Zugriffskontrollen auf KI-Modelle und Daten ein.
Warum KI-Agenten eine eigene KI Governance brauchen
Klassische KI Governance regelt Modelle, Trainingsdaten und Nutzungsrichtlinien. Bei KI-Agenten kommt eine Identität hinzu, die handelt. Jeder Agent erhält Zugangsdaten, API-Schlüssel und Rechte in Fachsystemen. Damit wird er zu einer nicht-menschlichen Identität mit eigenem Risikoprofil.
KI Risikomanagement für Agenten setzt deshalb an drei Stellen an: was der Agent darf, wer ihn stoppt und wie seine Handlungen später belegt werden. Der EU AI Act verlangt für Hochrisiko-Systeme ein Risikomanagement, automatische Protokollierung und menschliche Aufsicht. Wer Agenten in regulierten Prozessen einsetzt, braucht diese Kontrollen ohnehin für die KI Compliance.
Fünf Kontrollen vor dem Go-live
01 · Definierter Scope und minimale Berechtigungen
Der Agent erhält Zugriff ausschließlich auf die Systeme und Daten, die seine Aufgabe erfordert. Jede zusätzliche Berechtigung vergrößert die Angriffsfläche. Agenten bekommen eigene Identitäten mit zeitlich begrenzten Tokens, getrennt von den Service-Accounts menschlicher Teams.
02 · Human in the Loop bei kritischen Entscheidungen
Aktionen mit hoher Tragweite erfordern die Freigabe durch eine verantwortliche Person. Dazu zählen Zahlungen, Löschvorgänge und Änderungen an Kundendaten. Welche Aktionen als kritisch gelten, legt der Fachbereich fest, bevor der Agent startet.
03 · Vollständige Nachvollziehbarkeit
Jede Entscheidung und jede Aktion wird protokolliert, inklusive Eingabe, verwendeter Daten und ausgelöstem Systemaufruf. So lässt sich im Audit belegen, was der Agent getan hat und aus welchem Grund. Die Logs liegen dort, wo das Unternehmen sie selbst einsehen und exportieren kann.
04 · Limits und Stopp-Mechanismen
Schwellenwerte für die Zahl der Aktionen, das Datenvolumen, die Kosten pro Lauf oder Zugriffe auf neue Ziele halten den Agenten automatisch an. Ein abgelehnter Zugriff gilt als Stoppsignal. Der Agent sucht keinen zweiten Weg. Ein Kill-Switch beendet alle laufenden Aktionen sofort und liegt in der Hand des Unternehmens.
05 · Kontinuierliches Monitoring
Das Verhalten des Agenten wird über die gesamte Laufzeit beobachtet, auch nach Modell-Updates oder geänderten Schnittstellen. Abweichungen vom erwarteten Muster lösen einen Alarm aus. Wie Monitoring für KI-Systeme aufgebaut wird, beschreibt unser Beitrag zu KI Observability.
KI-Agenten im Unternehmen: Kriterien für die Anbieterauswahl
Bei Vergleich von Anbietern lassen sich die fünf Kontrollen direkt als Bewertungskriterien übernehmen. Die Übersicht zeigt, welchen Nachweis ein Angebot liefern sollte und woran Sie ein Risiko erkennen. Testen Sie die Stopp-Mechanismen im Proof of Concept mit einem bewusst überschrittenen Grenzwert. Erst wenn der Agent dort zuverlässig anhält, gilt das Kriterium als erfüllt.
| Kontrolle | Nachweis im Angebot | Warnsignal |
| 01 Scope und Berechtigungen | Rollenmodell je Agent, eigene Identitäten, Least-Privilege-Konzept | Agent arbeitet mit Admin- oder Sammelkonten |
| 02 Human in the Loop | Definierte Freigabestufen je Aktionstyp | Freigaben sind optional oder nicht dokumentiert |
| 03 Nachvollziehbarkeit | Vollständige, exportierbare Logs mit Aufbewahrung nach Kundenvorgabe | Logs nur im Portal des Anbieters einsehbar |
| 04 Limits und Stopp | Konfigurierbare Schwellenwerte, Kill-Switch, Test im Proof of Concept | Stopp nur über ein Support-Ticket möglich |
| 05 Monitoring | Laufende Verhaltensanalyse, Alarmierung, feste Review-Zyklen | Monitoring endet mit der Abnahme |
| Datensouveränität | Verarbeitung und Speicherung in der EU, kein Zugriff aus Drittstaaten | Rechtsraum für Modell und Logs ungeklärt |
Souveräne KI: wo Daten, Modelle und Logs liegen
Jede der fünf Kontrollen hängt davon ab, wer die Infrastruktur kontrolliert. Logs bei einem Anbieter außerhalb der EU unterliegen dessen Rechtsraum. Ein Kill-Switch, den nur der Anbieter auslösen kann, schützt das eigene Unternehmen nur bedingt.
Souveräne KI-Projekte setzen deshalb auf Datenverarbeitung und Speicherung auf europäischem Boden, konform mit DSGVO und AI Act und ohne Zugriffsmöglichkeit aus Drittstaaten. Unternehmen behalten so die volle Kontrolle über Infrastruktur, Modelle und Informationen, und alle Stellschrauben der KI Governance liegen im eigenen Einflussbereich.
Was vor der Vergabe feststehen sollte
Jeder Agent braucht im Fachbereich eine verantwortliche Person. Sie legt fest, welche Aufgaben der Agent übernimmt, und entscheidet über Änderungen an seinen Rechten. Ein zentrales Agenten-Register hält fest, welche Agenten mit welchen Rechten im Einsatz sind. Sobald mehrere Fachbereiche eigene Agenten starten, ist dieses Register die einzige Gesamtsicht auf das Risiko.
Vertraglich gehören drei Punkte dazu: die Haftung bei Fehlhandlungen des Agenten, verbindliche Meldefristen für Vorfälle und ein geregelter Exit. Logs, Konfigurationen und Prompts werden bei einem Anbieterwechsel vollständig übergeben.
Für das Budget zählen Monitoring, Log-Aufbewahrung und regelmäßige Reviews zu den laufenden Kosten des Agenten. Sie gehören in die Kalkulation, bevor der Business Case freigegeben wird.
Der Einstieg erfolgt mit einem Anwendungsfall begrenzter Tragweite. Weitere Systeme werden erst angebunden, wenn Freigaben und Stopp-Mechanismen dort nachweislich greifen.
