Wie wir alle wissen, können KI-Agenten jetzt Tools verwenden, auf Systeme zugreifen oder Workflows auslösen. Sie sind sehr praktisch und können viele manuelle Prozesse im Unternehmen beschleunigen. Aber mit Geschwindigkeit kommt Risiko, das beginnt, wenn Software erlaubt wird, innerhalb des Unternehmens zu handeln.

Deshalb kann das Risikomanagement für KI-Agenten nicht als ein nach der Entwicklung hinzugefügtes Richtliniendokument behandelt werden und muss in das System selbst eingebaut werden.  

Unternehmen müssen wissen, worauf der Agent zugreifen kann, was Genehmigung erfordert, wie Aktionen protokolliert werden und wer für das Ergebnis verantwortlich ist, wenn etwas schief geht, bevor er Ihr wichtiges Dokument oder Konto löscht.

Dieses Risiko wird deutlicher, als der IBM 2025 Cost of a Data Breach Report feststellte, dass 97 % der Organisationen, die einen KI-bezogenen Sicherheitsvorfall meldeten, keine ordnungsgemäßen KI-Zugriffskontrollen hatten. Und auch 63 % fehlten KI-Governance-Richtlinien, um KI zu verwalten oder Schatten-KI zu verhindern. 

In diesem Artikel bedeutet „KI-Agent" ein KI-System, das planen, Tools verwenden und mehrstufige Aktionen innerhalb eines Workflows ausführen kann, nicht nur Fragen beantworten.

Dies ist keine umfassende Liste von KI-Risiken. Sie konzentriert sich auf eine praktische Frage: Wie viel Autorität sollte ein KI-Agent haben, und wie sollte diese Autorität kontrolliert werden, bevor das System die Produktion erreicht? Dort beginnt sichere Automatisierung.

Das Agent Authority Model

Bevor ein Unternehmen einen KI-Agenten einsetzt, muss es eine sehr einfache Frage beantworten: Was darf dieses System tun?

Aber nicht, welches Modell es verwendet, und nicht, wie beeindruckend die Demo aussieht. Das eigentliche Designproblem ist Autorität.

Ein KI-Agent wird riskant, wenn er die Erlaubnis erhält, eigenständig zu handeln. Diese Autorität muss entworfen werden, bevor der Agent die Produktion erreicht.

Unser Agent Authority Model teilt dieses Design in fünf Ebenen auf, die nicht als separate Governance-Boxen behandelt werden sollten. Sie sind verbunden. Wenn ein Agent zu viel lesen, ohne Genehmigung ausführen und ohne Eigentümer operieren kann, hat das Unternehmen keine sichere Automatisierung aufgebaut.

Ebene 1: Datenzugriffsautorität

Viele Agentendesigns scheitern, weil dem Agenten breiter Zugriff auf Unternehmensdaten gewährt wird, anstatt der spezifischen Daten, die für einen Workflow erforderlich sind. Das mag während der Entwicklung bequem erscheinen, erhöht aber sehr schnell den Explosionsradius.

Beispielsweise benötigt ein KI-Verkaufsassistent nicht die gleiche Sichtbarkeit wie ein Verkaufsleiter, oder ein Gesundheits-Workflow-Agent sollte keine Patientendaten außerhalb der Aufgabe sehen, die er unterstützt.

Ein praktisches Zugriffsmodell in der Produktion sollte definieren:

Denken Sie daran, dass Agenten workflow-spezifischen Zugriff erhalten sollten, nicht rollenbasierten Zugriff.

Ein menschlicher Manager benötigt möglicherweise einen breiten Kontext, weil Menschen Urteilsvermögen über Situationen hinweg anwenden. Ein Agent sollte enger sein. Wenn seine Aufgabe die Lead-Priorisierung ist, benötigt er möglicherweise Lead-Profil, Quelle, aktuelle Interaktionen und Kontoverantwortlichen. Er benötigt wahrscheinlich keine vollständigen Umsatzprognosen oder interne Vergütungsdaten.

Für Führungskräfte ist dies wichtig, weil Datenzugriffsentscheidungen den zukünftigen Vorfallumfang definieren. Ein enger Agent kann innerhalb einer engen Grenze scheitern. Ein breit verbundener Agent kann einen kleinen Fehler in ein unternehmensweites Sicherheits- oder Kundenvertrauensproblem verwandeln.

Ebene 2: Tool-Autorität

Ein Tool ist eine Geschäftsberechtigung, und wenn das Team sagt: „Wir haben den Agenten mit E-Mail verbunden." In Wirklichkeit haben sie der Software die Erlaubnis gegeben, mit Kunden zu kommunizieren. 

Tool-Autorität definiert, welche Geschäftsaktionen der Agent über verbundene Systeme anfordern kann.

Beispiele:

• Ein CRM-Update-Tool ändert kommerzielle Datensätze.
• Ein E-Mail-Tool kommuniziert extern.
• Ein Kalender-Tool bucht jemandes Zeit.
• Ein Zahlungs- oder Erstattungs-Tool betrifft Geld.
• Eine Gesundheitsintegration kann die klinische Workflow-Priorität beeinflussen.
• Eine LMS- oder EdTech-Integration kann den Lernpfad oder Bewertungsfluss eines Lernenden beeinflussen.

Der Architekturfehler besteht darin, zu breite Tools bereitzustellen.

Dieser auf den ersten Blick subtile Unterschied ist wichtig, da ein breites Tool dem Modell Raum zum Improvisieren gibt. Ein enges Tool zwingt das System, innerhalb der Workflow-Grenze zu bleiben.

Ein gutes Tool-Autoritätsdesign sollte definieren:

• was das Tool tun kann;
• welche Parameter erlaubt sind;
• welche Datensätze es beeinflussen kann;
• welche Validierung vor der Ausführung erfolgt;
• ob Genehmigung erforderlich ist;
• was protokolliert wird;
• was passiert, wenn die Anfrage gegen Richtlinien verstößt.

Das Modell kann eine Aktion vorschlagen. Es sollte nicht erlaubt sein, seine eigenen Betriebsrechte zu erfinden.

Dies ist besonders wichtig, weil Agenten scheitern, wenn eine korrekt klingende Anfrage durch ein zu mächtiges Tool geht. Ein vages update_customer_record-Tool mag für die Entwicklung bequem sein. Es ist auch eine große Berechtigungsfläche.

Ebene 3: Entscheidungsautorität

Entscheidungsautorität definiert, was der Agent ohne menschliche Genehmigung entscheiden kann. Dies sollte auf Geschäftsauswirkungen, Reversibilität und Risikoexposition basieren.

Ein schwaches System sagt, dass Menschen wichtige Dinge überprüfen werden, und nennt es Human-in-the-Loop. Aber ein starkes System sollte eine Definition dessen enthalten, was „wichtig" bedeutet: in Code, Workflow-Regeln, Genehmigungswarteschlangen und Betriebsverfahren.

Für jede Entscheidungskategorie sollte die Architektur definieren:

• welche Ereignisse Überprüfung erfordern;
• wer sie überprüft;
• welchen Kontext der Prüfer erhält;
• wie lange der Prüfer Zeit zum Antworten hat;
• was passiert, wenn niemand antwortet;
• ob die Aktion blockiert, eskaliert oder herabgestuft wird;
• wie die Entscheidung und Überprüfung protokolliert werden.

Dies ist wichtig, weil menschliche Überprüfung leicht unzuverlässig werden kann. Wenn der Prüfer eine vage KI-Empfehlung ohne Beweise und ohne klare Genehmigungskriterien erhält, hat das System nur Verwirrung auf einen Menschen übertragen.

Für Führungskräfte ist dies der Punkt, an dem die Entscheidungsautorität ein Betriebsmodell ist. Es definiert, wo die Automatisierung endet und verantwortliches menschliches Urteilsvermögen beginnt.

Ebene 4: Ausführungsautorität

Ausführungsautorität ist die Linie zwischen Beratung und Aktion. Sie definiert, was der Agent tatsächlich innerhalb von Geschäftssystemen tun darf. 

Ein Agent, der eine Rückerstattung empfiehlt, ist eine Art von System, aber ein Agent, der die Rückerstattung ausstellt, ist eine andere.

Diese Ebene sollte um vier Fragen herum gestaltet werden:

1. Kann die Aktion rückgängig gemacht werden? Ein Entwurf kann gelöscht werden. Eine gesendete E-Mail kann nicht in einem sinnvollen geschäftlichen Sinne rückgängig gemacht werden.
2. Wen oder was betrifft die Aktion? Internes Task-Routing unterscheidet sich von Kundenkommunikation, Zahlungsbewegung, Kandidatenablehnung oder klinischer Priorisierung.
3. Was sind die Kosten einer falschen Aktion? Einige Fehler schaffen Unannehmlichkeiten. Andere schaffen rechtliche, finanzielle, Sicherheits- oder Reputationsrisiken.
4. Ändert die Aktion den Systemzustand? Lesen und Zusammenfassen sind risikoärmer. Schreiben, Löschen, Genehmigen, Veröffentlichen, Eskalieren oder Auslösen nachgelagerter Workflows sind risikoreichere Aktionen.

Ausführungsautorität sollte dort am engsten sein, wo Aktionen nach außen gerichtet, schwer rückgängig zu machen, reguliert oder finanziell sensibel sind.

Beispiele:

Der sicherste Agent ist derjenige, dessen Ausführungsrechte mit dem Geschäftsrisiko des Workflows übereinstimmen.

Hier ist architekturorientiertes Denken am wichtigsten. In ernsthaftem SaaS, HealthTech, SalesTech, EdTech, FinTech oder Compliance-intensiven Workflows sollte die Ausführungsgrenze wie jede andere Produktionsgrenze behandelt werden. Sie benötigt Berechtigungen, Validierung, Genehmigungstore und Vorfallreaktion.

Ebene 5: Verantwortlichkeitsautorität

Die letzte Ebene ist Eigentümerschaft. Wenn niemand die Aktionen des Agenten besitzt, hat das Unternehmen eine Verantwortlichkeitslücke eingesetzt.

Diese Ebene beantwortet die Fragen, die normalerweise zu spät erscheinen:

• Wer genehmigt den Agenten vor dem Einsatz?
• Wer besitzt den Workflow, innerhalb dessen der Agent operiert?
• Wer überprüft Fehlermuster?
• Wer kann den Agenten deaktivieren?
• Wer genehmigt neue Tools oder Berechtigungen?
• Wer überprüft Eskalationen?
• Wer ist für den Vorfall verantwortlich, wenn der Agent gemäß Anweisungen korrekt, aber gemäß Geschäftskontext falsch handelt?
• Wer entscheidet, ob der Agent vom Entwurfsmodus in den Ausführungsmodus übergehen kann?

Verantwortlichkeitsautorität ist entscheidend, weil KI-Agenten keine statischen Software-Features sind. Ihre Prompts, Tools und Datenquellen ändern sich. Ein ernsthaftes Verantwortlichkeitsmodell sollte vier Verantwortlichkeiten trennen:

In kleineren Unternehmen kann eine Person mehr als eine Rolle abdecken. Das ist in Ordnung. Was nicht in Ordnung ist, ist, niemanden explizit verantwortlich zu haben.

Verantwortlichkeitsautorität sollte auch Änderungskontrolle definieren. Wenn der Agent ein neues Tool, breiteren Datenzugriff, höhere Ausführungsrechte oder niedrigere Genehmigungsschwellen benötigt, sollte dies nicht beiläufig innerhalb eines Sprints geschehen. Es sollte eine Überprüfung auslösen, weil jede neue Berechtigung das Risikoprofil des Systems ändert.

Dies ist die Ebene, die das Risikomanagement für KI-Agenten von einem Richtliniengespräch in eine Betriebsdisziplin verwandelt.

Ein Produktions-KI-Agent benötigt einen menschlichen Eigentümer, eine technische Grenze, einen Genehmigungspfad, einen Vorfallprozess und eine Möglichkeit, gestoppt zu werden. Ohne diese Teile bittet die Organisation die Automatisierung, Wert zu schaffen, während die Verantwortung undefiniert bleibt.

Checkliste: Bereitschaft für KI-Agenten-Risikomanagement

Workflow und Geschäftseignung

• Ist der Workflow klar definiert, einschließlich Eingaben, Entscheidungen, Aktionen, Ausnahmen und Übergaben?
• Ist das Geschäftsergebnis messbar?
• Löst der Agent einen echten Engpass, oder fügt er einem Prozess KI hinzu, der sie nicht benötigt?
• Ist der Workflow wiederholbar genug für Automatisierung?
• Sind bekannte Ausnahmen dokumentiert?
• Wurde der Workflow für agentische Automatisierung neu gestaltet, nicht nur vom aktuellen menschlichen Prozess kopiert?

Wenn der Workflow selbst unklar ist, wird der Agent ihn nicht reifer machen. Er wird nur die Verwirrung schneller machen.

Datenzugriff

• Greift der Agent nur auf die Daten zu, die für diesen spezifischen Workflow erforderlich sind?
• Werden sensible Felder wo möglich maskiert, eingeschränkt oder ausgeschlossen?
• Werden Mandanten-, Kunden-, Patienten- oder Kontogrenzen durchgesetzt?
• Sind Datenaufbewahrungsregeln definiert?
• Wird jedes Zugriffsereignis protokolliert?
• Kann das Unternehmen erklären, warum jede Datenquelle notwendig ist?

Der Agent sollte keinen breiten Zugriff erben, weil es technisch einfacher ist. Der Zugriff sollte durch den Workflow gerechtfertigt sein.

Tool-Nutzung

• Hat jedes Tool einen klaren Geschäftszweck?
• Sind Tools eng und aufgabenspezifisch statt offen?
• Werden gefährliche Tools wie „run command", „query anything" oder „update any record" vermieden oder streng isoliert?
• Werden Tool-Eingaben vor der Ausführung validiert?
• Basieren Tool-Berechtigungen auf dem Prinzip der geringsten Berechtigung?
• Werden alle Tool-Aufrufe protokolliert und überprüfbar?

Ein Tool ist kein Feature. Es ist eine Berechtigung für den Agenten, das Geschäft zu beeinflussen.

Entscheidungs- und Ausführungsrechte

• Sind Agentenaktionen nach Geschäftsauswirkung klassifiziert?
• Sind risikoarme Aktionen von finanziellen, rechtlichen, klinischen, Compliance-sensitiven oder nach außen gerichteten Aktionen getrennt?
• Sind Aktionen mit hoher Auswirkung durch obligatorische menschliche Genehmigung geschützt?
• Werden nach außen gerichtete Kommunikationen durch genehmigte Vorlagen, Schemas oder Prüfungsregeln kontrolliert?
• Ist es technisch unmöglich für den Agenten, seine eigene Autorität zu erweitern?
• Werden irreversible oder schwer rückgängig zu machende Aktionen anders behandelt als reversible Aktionen?

Das System sollte sich nicht darauf verlassen, dass das Modell „weiß", wann es handeln darf. Diese Grenze muss außerhalb des Modells existieren.

Menschliche Kontrolle und Verantwortlichkeit

• Gibt es einen Geschäftseigentümer für den Workflow des Agenten?
• Gibt es einen technischen Eigentümer für Zuverlässigkeit, Berechtigungen, Integrationen und Überwachung?
• Sind Prüfungseigentümer für Genehmigungswarteschlangen zugewiesen?
• Sind Eskalationspfade definiert?
• Gibt es einen dokumentierten Vorfallreaktionsprozess?
• Gibt es einen Kill Switch?
• Werden neue Tools, Berechtigungen oder Ausführungsrechte überprüft, bevor sie hinzugefügt werden?

Wenn niemand das Verhalten des Agenten besitzt, hat das Unternehmen keinen Workflow automatisiert. Es hat eine Verantwortlichkeitslücke geschaffen.

Überwachung und Verbesserung

• Werden Tool-Aufrufe, fehlgeschlagene Aktionen, blockierte Aktionen, Genehmigungen, Überschreibungen und Eskalationen überwacht?
• Werden Berechtigungsverletzungen oder ungewöhnliche Zugriffsmuster überprüft?
• Werden wiederholte Unsicherheit, wiederholte menschliche Korrektur oder wiederholte Geschäftsausnahmen verfolgt?
• Wird das System sowohl nach eingesparter Zeit als auch nach eingeführten Fehlern gemessen?
• Werden Risikoschwellen basierend auf Produktionsverhalten angepasst?
• Wird der Agent regelmäßig revalidiert, wenn sich Workflows, Daten und Geschäftsregeln ändern?

Fazit

Beim Risikomanagement für KI-Agenten geht es darum, das System so zu gestalten, dass Vertrauen nicht die schwere Arbeit übernimmt. Eine sichere Agentenarchitektur definiert, worauf der Agent zugreifen kann, welche Tools er aufrufen kann, was er entscheiden kann, was er ausführen kann, wann ein Mensch genehmigen muss, wie jede Aktion protokolliert wird und wer für das Ergebnis verantwortlich ist, wenn etwas kaputt geht.

Dies ist es, was nützliche Automatisierung von unkontrollierter Delegation unterscheidet.

Führungskräfte müssen sich nicht zwischen schnellem Voranschreiten mit Agenten und dem Vermeiden von ihnen entscheiden, weil sie riskant sind. Die bessere Option besteht darin, Autorität explizit zu machen. Geben Sie dem Agenten genug Berechtigung, um Wert zu schaffen, aber nicht genug Freiheit, um stillschweigend Schaden anzurichten.

Die Unternehmen, die am meisten von KI-Agenten profitieren, werden nicht diejenigen sein, die Agenten die meiste Freiheit geben. Es werden diejenigen sein, die Agenten die richtige Menge an Autorität für den Workflow, das Risiko und das Geschäftsergebnis geben.

Dort hört das Risikomanagement für KI-Agenten auf, eine Governance-Übung zu sein, und wird zu Softwarearchitektur.