AI-Agenten-Risiko: Warum Agenten ein neues Governance-Modell brauchen

12. April 2026 · 8 Min. Lesezeit

KI-Agenten werden schnell zur neuen Standarderzählung im Enterprise-AI-Bereich. Anbieter integrieren Agenten in Produktivitätssuiten, Customer-Service-Plattformen, Entwicklerwerkzeuge, Workflowsysteme und Low-Code-Umgebungen. Microsoft Copilot Studio positioniert sich zum Beispiel inzwischen als Plattform, um KI-Agenten zu erstellen, anzupassen, bereitzustellen und zu verwalten, die mit Geschäftsdaten verbunden sind, Werkzeuge nutzen und in Kanälen wie Microsoft 365 Copilot, Teams, SharePoint und Websites veröffentlicht werden können.

Diese Entwicklung ist wichtig. Aber sie schafft auch ein Sprachproblem.

Nicht jedes Produkt, das als "Agent" bezeichnet wird, trägt dasselbe Risiko.

Ein einfacher Prompt-und-Response-Assistent, der auf einigen Dokumenten basiert, ist nicht dasselbe wie ein autonomer Workflow-Agent, der Ereignisse überwacht, Entscheidungen trifft, Werkzeuge aufruft, Datensätze aktualisiert, Nachrichten versendet, Fälle eskaliert oder im Hintergrund Geschäftsprozesse auslöst. Beide können als Agenten vermarktet werden. Sie brauchen trotzdem nicht dasselbe Governance-Modell.

Kernaussage: Ein Agent ist eine Produktkategorie, aber agentisches Verhalten ist eine Risikoeigenschaft.

Von KI, die antwortet, zu KI, die handelt

Traditionelle KI-Governance beginnt oft mit Fragen wie:

• Ist das Modell akkurat?
• Ist die Ausgabe verzerrt?
• Erklärt das System sein Ergebnis?
• Werden personenbezogene Daten rechtmäßig verarbeitet?
• Können Nutzer der Antwort vertrauen?

Diese Fragen bleiben wichtig. Aber agentische Systeme fügen eine neue Ebene hinzu: Handlung.

Bei Agenten verschiebt sich die Governance-Frage von:

Was hat das Modell gesagt?

Zu:

Was durfte der Agent tun, was hat er tatsächlich getan, warum hat er es getan, wer hat es genehmigt und können wir es nachweisen?

Das ist ein sehr anderes Kontrollproblem.

Ein Chatbot kann eine falsche Antwort geben. Ein Agent kann eine falsche Antwort geben und dann auf dieser Basis handeln. Er kann eine API aufrufen, ein Ticket aktualisieren, einem Kunden eine E-Mail senden, einen Datensatz ändern, sensible Daten abrufen, eine Rückerstattung anstoßen, eine Aufgabe erstellen oder Arbeit an einen anderen Agenten weiterreichen.

In dem Moment, in dem ein KI-System ein anderes System beeinflussen kann, wird KI-Governance zu operativer Governance.

Das Agenten-Label ist zu breit

Microsofts eigene Dokumentation macht das Spektrum sichtbar. Microsoft 365 Copilot beschreibt Agenten als Systeme, die von einfachen Prompt-und-Response-Agenten bis hin zu fortgeschrittenen, vollständig autonomen Agenten reichen. Copilot Studio erweitert dies um autonome Fähigkeiten, bei denen Agenten auf Basis von Triggern, Instruktionen und Guardrails handeln und im Hintergrund arbeiten, statt nur in einer Konversation zu reagieren.

Dieses Spektrum ist hilfreich. Es erzeugt aber auch Verwirrung.

Viele Organisationen hören das Wort "Agent" und nehmen an, dass es sich um eine einzige Kategorie handelt. In der Praxis gibt es mehrere Stufen agentischen Verhaltens.

Stufe 1: Wissensassistent

Das ist ein wenig agentisches Werkzeug. Es beantwortet Fragen mithilfe von Instruktionen und ausgewählten Wissensquellen.

Beispiel:

• Ein interner HR-Assistent, der Fragen zu Richtlinien anhand freigegebener Dokumente beantwortet.
• Ein Copilot-Studio-Agent, der in Teams-Chats mit konfigurierten Themen und Wissensquellen antwortet.

Primäre Risiken:

• Falsche Antworten
• Veraltetes Wissen
• Unangemessene Offenlegung
• Übermäßiges Vertrauen der Nutzer

Governance-Fokus:

• Inhaltsqualität
• Zugriff auf Wissensquellen
• Hinweise und Eskalation
• Grundlegendes Logging

Stufe 2: Geführter Workflow-Assistent

Dieses Werkzeug hilft einem Nutzer bei der Bearbeitung einer Aufgabe, aber der Mensch bleibt am Steuer.

Beispiel:

• Ein Support-Assistent, der eine Antwort entwirft und den nächsten Schritt vorschlägt.
• Ein Sales-Assistent, der Kontoinformationen zusammenfasst und eine Follow-up-E-Mail vorschlägt.

Primäre Risiken:

• Schlechte Empfehlungen
• Unvollständiger Kontext
• Irreführende Zusammenfassungen
• Abnicken ohne echte Prüfung

Governance-Fokus:

• Menschliche Prüfung
• Transparenz der Quellen
• Workflow-Grenzen
• Nutzerschulung

Stufe 3: Werkzeugnutzender Agent

Hier beginnt sich das Risiko materiell zu verändern. Der Agent kann Werkzeuge, APIs, Flows oder Konnektoren aufrufen.

Beispiel:

• Ein IT-Support-Agent, der Tickets erstellt und den Gerätestatus prüft.
• Ein Customer-Service-Agent, der Bestellungen nachschlägt und freigegebene Aktionen anstößt.
• Ein Copilot-Studio-Agent, der mit Power-Automate-Flows oder APIs von Geschäftssystemen verbunden ist.

Primäre Risiken:

• Unbefugte Werkzeugnutzung
• Zu weitreichende Berechtigungen
• Prompt Injection mit Werkzeug-Missbrauch
• Datenabfluss über Tool-Inputs oder -Outputs
• Unvollständige Nachvollziehbarkeit

Governance-Fokus:

• Tool-Permission-Matrix
• Least-Privilege-Zugriff
• Genehmigungsregeln
• Audit-Logs
• Runtime-Policy-Enforcement

Stufe 4: Autonomer Workflow-Agent

Der Agent kann Ereignisse überwachen, Entscheidungen treffen und Aufgaben ausführen, ohne auf einen Nutzer-Prompt zu warten.

Beispiel:

• Ein Agent, der eingehende Lieferanten-E-Mails überwacht, Vertragsänderungen extrahiert, Risiken klassifiziert und Genehmigungen weiterleitet.
• Ein Finanz-Agent, der Abstimmungsabweichungen überwacht und Korrektur-Workflows startet.
• Ein Security-Agent, der Alarme beobachtet, Fälle anreichert und Eindämmungsmaßnahmen einleitet.

Primäre Risiken:

• Nicht genehmigte Aktion
• Falsche Entscheidung im großen Maßstab
• Stiller Fehler
• Fehler bei Eskalationen
• Störung von Geschäftsprozessen
• Lücken bei Compliance-Nachweisen

Governance-Fokus:

• Validierung von Triggern
• Entscheidungsgrenzen
• Menschliche Genehmigung für kritische Aktionen
• Monitoring und Alerting
• Incident Response
• Kill Switches

Stufe 5: Multi-Agenten-Orchestrierung

Mehrere Agenten koordinieren sich, delegieren oder übergeben Arbeit.

Beispiel:

• Ein Customer-Onboarding-Prozess, bei dem ein Agent Dokumente sammelt, ein anderer Compliance prüft, ein weiterer Systeme aktualisiert und ein weiterer mit dem Kunden kommuniziert.

Primäre Risiken:

• Verantwortlichkeitslücken
• Widersprüchliche Instruktionen
• Fehlerfortpflanzung
• Versteckte Delegation
• Schwierige Ursachenanalyse

Governance-Fokus:

• Agenten-Identität
• Delegationsregeln
• End-to-End-Nachvollziehbarkeit
• Systemweites Testing
• Ownership-Modell

Praktische Regel: Nicht das Label governen, sondern das Verhalten.

Beispielhafte Anwendungsfälle nach Agentenstufe

Die Stufen sind nicht als perfekte Schubladen gedacht. Sie sind ein praktischer Weg zu fragen: Wie viel Agency hat dieses System wirklich?

Wenig agentische Werkzeuge brauchen trotzdem Governance

Es wäre ein Fehler, wenig agentische Plattformen als harmlos abzutun. Ein einfacher Copilot-Studio-Agent kann dennoch sensible Informationen offenlegen, irreführende Antworten geben, sich auf veraltetes Wissen stützen oder ein falsches Gefühl von Autorität erzeugen.

Aber wenig agentische Werkzeuge passen meist in ein leichteres Governance-Modell, weil das System hauptsächlich reagiert und nicht eigenständig handelt.

Für wenig agentische Werkzeuge sind die wichtigsten Fragen:

• Auf welche Wissensquellen kann der Agent zugreifen?
• Werden Berechtigungen korrekt aus Microsoft 365, SharePoint oder anderen Systemen übernommen?
• Sind Antworten in freigegebenen Inhalten verankert?
• Wissen Nutzer, wann sie verifizieren oder eskalieren müssen?
• Werden Konversationen angemessen protokolliert?
• Wem gehört der Agent nach dem Launch?

Das ist Governance, aber sie besteht hauptsächlich aus Content-, Zugriffs-, Qualitäts- und Ownership-Governance.

Das größere Risiko beginnt, wenn der Agent Werkzeuge, Autonomie, Memory, Trigger oder die Fähigkeit, Geschäftssysteme zu beeinflussen, hinzubekommt.

Ab diesem Punkt muss das Governance-Modell Kontrolldesign enthalten, nicht nur Content-Review.

Warum bestehende KI-Governance nicht ausreicht

Viele KI-Governance-Programme wurden um Modelle und Use Cases herum aufgebaut. Teams sollen das Modell dokumentieren, den Use Case klassifizieren, Datenschutzfolgen bewerten, Bias testen und die Einführung genehmigen.

Das ist ein guter Anfang. Aber Agenten bringen Risiken mit sich, die von modellzentrierter Governance nicht vollständig erfasst werden.

1. Agenten haben Berechtigungen

Modelle erzeugen Ausgaben. Agenten haben oft Berechtigungen.

Sie können auf Dateien zugreifen, Datenbanken abfragen, APIs aufrufen, E-Mails versenden, Datensätze erstellen oder Workflows auslösen. Das bedeutet: Agent Governance muss sich bei Identity and Access Management bedienen.

Die zentrale Frage lautet:

Was darf dieser Agent unter welchen Bedingungen tun, und wer hat diese Berechtigungen genehmigt?

2. Agenten haben Werkzeuge

Werkzeuge schaffen eine neue Angriffsfläche. Eine bösartige Instruktion, versteckt in einem Dokument, einer E-Mail, einer Webseite, einem Ticket oder einer abgerufenen Wissensquelle, kann versuchen, den Agenten dazu zu bringen, seine Werkzeuge falsch einzusetzen.

Bei Agenten geht es bei Prompt Injection nicht nur darum, Text zu beeinflussen. Es kann darum gehen, Handlungen zu beeinflussen.

3. Agenten haben Laufzeitverhalten

Eine Modellbewertung vor dem Launch reicht nicht aus. Agenten können sich je nach Triggern, Kontext, Tool-Antworten, abgerufenen Daten, Nutzerinstruktionen und Workflow-Zustand unterschiedlich verhalten.

Governance muss zur Laufzeit über Logging, Monitoring, Alerts und Incident Response fortgeführt werden.

4. Agenten brauchen Aktionsgrenzen

Eine akzeptable Antwort ist nicht dasselbe wie eine akzeptable Aktion.

Ein Agent darf zum Beispiel vielleicht eine Rückerstattungsempfehlung entwerfen, aber die Rückerstattung nicht selbst ausführen. Er darf vielleicht ein Ticket erstellen, aber nicht schließen. Er darf vielleicht Vertragsrisiken zusammenfassen, aber den überarbeiteten Vertrag nicht an die Gegenpartei senden.

Diese Grenzen müssen explizit sein.

5. Agenten erzeugen Nachweisanforderungen

Wenn etwas schiefgeht, muss die Organisation die Sequenz rekonstruieren können:

• Was hat den Agenten ausgelöst?
• Welche Daten hat er gesehen?
• Welcher Instruktion ist er gefolgt?
• Welche Werkzeuge hat er aufgerufen?
• Welche Policy-Entscheidung wurde getroffen?
• War menschliche Freigabe erforderlich?
• Wer hat die Aktion genehmigt oder abgelehnt?
• Was hat sich im Geschäftssystem geändert?

Wenn Sie diese Fragen nicht beantworten können, haben Sie keine Agent Governance. Dann haben Sie Agenten-Hoffnung.

Ein praktisches Governance-Modell für KI-Agenten

Ein nützliches Governance-Modell für Agenten sollte mindestens acht Kontrollebenen umfassen.

1. Agenten-Inventar

Was Sie nicht sehen, können Sie nicht governen.

Erfassen Sie jeden Agenten mit:

• Owner
• Zweck
• Nutzergruppe
• Modell oder Plattform
• Datenquellen
• Werkzeuge und Konnektoren
• Autonomiegrad
• Risikostufe
• Freigabestatus
• Review-Datum
• Monitoring-Verantwortlichem

2. Agentische Risikostufung

Klassifizieren Sie Agenten nach Verhalten, nicht nach Anbieterlabel.

Nützliche Dimensionen sind:

• Kann er auf sensible Daten zugreifen?
• Kann er Werkzeuge aufrufen?
• Kann er in Systeme schreiben?
• Kann er ohne Nutzer-Prompt handeln?
• Kann er externe Kommunikation auslösen?
• Kann er High-Impact-Entscheidungen treffen oder beeinflussen?
• Kann er an andere Agenten delegieren?

3. Tool-Permission-Matrix

Jedes Werkzeug sollte eine explizite Policy haben.

Definieren Sie für jedes Werkzeug:

• Erlaubt oder blockiert
• Read-only oder write-fähig
• Freigabe erforderlich oder nicht
• Maximalgrenzen
• Erlaubte Datenklassen
• Erlaubte Nutzergruppen
• Logging-Anforderungen

Ein Rückerstattungs-Tool könnte zum Beispiel Entwürfe ohne Freigabe erlauben, unterhalb eines Schwellwerts Freigabe verlangen und autonome Rückerstattungen oberhalb eines Schwellwerts blockieren.

4. Menschliche Freigabepunkte

Human-in-the-loop sollte kein Slogan sein. Es sollte in den Workflow eingebaut werden.

Freigaben sollten erforderlich sein für:

• Rechtliche Verpflichtungen
• Finanztransaktionen
• HR-Entscheidungen
• Kundenwirksame Aktionen
• Sicherheitskritische Änderungen
• Irreversible Aktionen
• Automatisierte Entscheidungen in hohem Volumen

Die Freigabe sollte Teil des Audit Trails werden.

5. Prompt-Injection- und Tool-Misuse-Testing

Agenten sollten vor der Produktion gegen adversariale Szenarien getestet werden.

Testen Sie auf:

• Bösartige abgerufene Dokumente
• Widersprüchliche Instruktionen
• Versuche der Datenexfiltration
• Versuche, Freigaben zu umgehen
• Versuche, unautorisierte Werkzeuge zu nutzen
• Versuche, Systeminstruktionen zu überschreiben
• Versuche, Aktionen aus nicht vertrauenswürdigen Inputs auszulösen

6. Runtime-Audit-Logging

Logs sollten mehr erfassen als nur die endgültige Antwort.

Mindestens protokolliert werden sollten:

• Nutzer- oder Event-Trigger
• Agent-ID
• Prompt- oder Instruktionsversion
• Modellversion
• Abgerufener Kontext
• Tool-Aufrufe
• Tool-Inputs und -Outputs
• Policy-Entscheidungen
• Menschliche Freigaben
• Endgültige Aktion
• Trace-ID

7. Monitoring und Kill Switches

Agenten brauchen operative Kontrollen.

Beobachtet werden sollte:

• Unerwartete Werkzeugnutzung
• Ungewöhnlicher Datenzugriff
• Wiederholte Fehler
• Eskalationsspitzen
• Kostenanomalien
• Schleifenverhalten
• Aktionen außerhalb normaler Muster

Ein High-Risk-Agent sollte eine klare Pause-, Entzugs- oder Kill-Switch-Prozedur haben.

8. Lifecycle Reviews

Agenten entwickeln sich weiter. Ihre Werkzeuge, Prompts, Datenquellen, Modelle, Nutzer und geschäftlichen Kontexte ändern sich.

Reviewen Sie Agenten, wenn:

• Ein neues Werkzeug hinzugefügt wird
• Eine neue Datenquelle verbunden wird
• Die Autonomie zunimmt
• Das Modell wechselt
• Der Agent in einem neuen Kanal veröffentlicht wird
• Sich der Geschäftsprozess ändert
• Ein Vorfall eintritt

Die Lehre aus Microsoft Copilot Studio

Microsofts Ansatz ist nützlich, weil er das entstehende Enterprise-Muster zeigt. Copilot Studio bringt Low-Code-Agentenerstellung, Grounding auf Geschäftsdaten, Werkzeuge, Flows, APIs, Publishing-Kanäle, Management-Funktionen, Analytics und Governance-Features zusammen.

Es zeigt aber auch, warum Unternehmen ihre eigene Sprache für Agentenrisiken brauchen.

Ein einfacher deklarativer oder Prompt-und-Response-Agent kann eine beherrschbare Erweiterung von Knowledge Management sein. Ein autonomer Copilot-Studio-Agent, der mit Geschäftsworkflows verbunden ist, ist eher ein digitaler Prozessakteur. Ein Multi-Agenten-System, das über Werkzeuge und Abteilungen hinweg koordiniert, ist eher ein verteiltes operatives System.

Diese Systeme sollten nicht durch dieselbe Freigabe-Checkliste laufen.

Die Risikofrage ist nicht:

Wurde das in Copilot Studio, Azure AI Foundry, LangGraph, OpenAI, CrewAI oder einem anderen Framework gebaut?

Die bessere Frage ist:

Welchen Grad an Agency hat dieses System, und welche Kontrollen passen zu diesem Grad an Agency?

Diese Sichtweise hilft auch, anbieterbezogene Blind Spots zu vermeiden. Eine Low-Code-Plattform kann nützliche Guardrails, Admin-Kontrollen und Integrationen mit Enterprise-Governance-Werkzeugen bieten. Das ist wertvoll. Aber die Organisation muss trotzdem entscheiden, welche Aktionen akzeptabel sind, welche Freigaben erforderlich sind, welche Nachweise aufbewahrt werden müssen und wem der Agent nach dem Deployment gehört.

Eine einfache Faustregel

Je mehr ein KI-System handeln kann, desto stärker muss Governance von Dokumentation zu Kontrolle werden.

Nutzen Sie diese Regel:

• Wenn es nur antwortet, governen Sie Content, Zugriff und Genauigkeit.
• Wenn es empfiehlt, governen Sie Decision Support und menschliche Review.
• Wenn es Werkzeuge nutzt, governen Sie Berechtigungen und Tool-Call-Policies.
• Wenn es autonom handelt, governen Sie Trigger, Freigaben, Monitoring und Incident Response.
• Wenn es mit anderen Agenten koordiniert, governen Sie Identität, Delegation und End-to-End-Nachvollziehbarkeit.

Das ist das Fundament von AI Agent Risk.

Was jetzt zu tun ist

Für Organisationen, die jetzt starten, sind die ersten Schritte praktisch:

1. Erstellen Sie ein Inventar aller Agenten und agentenähnlichen Systeme.
2. Klassifizieren Sie sie nach Agency-Stufe, nicht nach Produktnamen.
3. Identifizieren Sie, welche Agenten auf Daten zugreifen, Werkzeuge aufrufen oder Aktionen auslösen können.
4. Definieren Sie für jeden werkzeugnutzenden Agenten eine Tool-Permission-Matrix.
5. Verlangen Sie menschliche Freigaben für sensible oder irreversible Aktionen.
6. Protokollieren Sie Agentenaktionen so, dass Audit und Incident Response unterstützt werden.
7. Testen Sie Agenten auf Prompt Injection, Datenabfluss und Umgehung von Freigaben.
8. Reviewen Sie Agenten jedes Mal, wenn ihre Autonomie, Werkzeuge oder Datenzugriffe erweitert werden.

Die Zukunft der KI-Governance wird nicht nur von Modellen handeln. Sie wird von Systemen handeln, die wahrnehmen, entscheiden und handeln innerhalb von Geschäftsprozessen.

Deshalb brauchen Agenten ein neues Governance-Modell.

Quellen

• Microsoft Copilot Studio: KI-Agenten erstellen, anpassen und starten
• Microsoft Learn: Verwendung von Agenten im Microsoft 365 Copilot Chat
• Microsoft Learn: Autonome Agentenfähigkeiten in Copilot Studio gestalten