KI-Agenten brauchen klare Rechte und Abbruchbedingungen

Ein Chatbot erzeugt Text. Ein KI-Agent kann zusätzlich Werkzeuge aufrufen, Informationen aus Systemen lesen und Aktionen auslösen. Er kann ein Ticket anlegen, einen Datensatz ändern, eine Bestellung vorbereiten oder eine Nachricht versenden.

Damit verschiebt sich die zentrale Frage. Es geht nicht mehr nur darum, ob eine Antwort fachlich richtig ist. Es geht darum, was das System mit einer möglicherweise falschen oder manipulierten Entscheidung tun darf.

Die Qualität des Modells beantwortet diese Frage nicht. Auch ein leistungsfähiges Modell kann Eingaben falsch verstehen, unzuverlässige Daten verwenden oder durch Inhalte in Dokumenten und Webseiten beeinflusst werden. Die zulässige Autonomie muss deshalb aus Wirkung, Rückholbarkeit und Kontrolle der Aktion abgeleitet werden.

Ein Agent ist eine handelnde Systemkomponente

Der Begriff „Agent“ wird uneinheitlich verwendet. Für die betriebliche Steuerung genügt eine pragmatische Definition:

Ein KI-Agent ist ein System, das auf Basis eines Ziels Schritte auswählt und dafür selbstständig Werkzeuge oder Schnittstellen nutzt.

Damit gehören nicht nur Modell und Prompt zum System, sondern auch:

• Identität und Berechtigungen,
• verfügbare Datenquellen,
• Werkzeuge und Schnittstellen,
• Ablauf- und Speicherlogik,
• Freigaben und Grenzen,
• Protokollierung und Überwachung,
• Fehlerbehandlung und Fallback.

Der NIST AI Risk Management Framework betrachtet KI-Risiken über Design, Entwicklung, Nutzung und Evaluation. NIST weist zum Abrufzeitpunkt darauf hin, dass Version 1.0 überarbeitet wird. Für Agenten ist der Lebenszyklusblick entscheidend: Ein erfolgreicher Test sagt wenig darüber aus, wie Rechte, Änderungen und Störungen im Dauerbetrieb beherrscht werden.

Aktionen nach Wirkung und Rückholbarkeit ordnen

Eine einfache Autonomieleiter verhindert die pauschale Diskussion „mit oder ohne Human in the Loop“:

Stufe	Beispiel	Typische Kontrolle
lesen	freigegebene Wissensquelle durchsuchen	Daten- und Zugriffsschutz
vorschlagen	Priorität oder nächste Handlung empfehlen	fachliche Prüfung durch Nutzer
entwerfen	Ticket, Antwort oder Buchung vorbereiten	Freigabe vor Übernahme
reversibel ausführen	gekennzeichneten Entwurf speichern, Aufgabe zuweisen	Limits, Protokoll und Rücknahme
hochwirksam ausführen	Zahlung, Stammdatenänderung, produktiver Change	getrennte Berechtigung und ausdrückliche menschliche Freigabe

Nicht jede Aktion passt eindeutig in eine Stufe. Eine E-Mail kann harmlos sein oder eine verbindliche Zusage enthalten. Eine Benutzeranlage kann reversibel erscheinen, aber sofort weitreichenden Zugriff ermöglichen. Deshalb wird die tatsächliche Wirkung des konkreten Prozesses bewertet.

Acht Leitplanken vor dem produktiven Einsatz

1. Eigene, eindeutig zuordenbare Identität

Ein Agent sollte nicht ununterscheidbar unter dem Konto eines Mitarbeiters handeln. Eine eigene technische Identität ermöglicht:

• gezielte Rechtevergabe,
• nachvollziehbare Aktionen,
• getrennte Sperrung,
• unabhängige Überwachung,
• klare Zuordnung von System- und Nutzerhandlung.

Wenn einzelne Handlungen im Auftrag eines Nutzers stattfinden, müssen beide Ebenen erkennbar bleiben: Wer hat den Auftrag ausgelöst und welche technische Identität hat gehandelt?

2. Minimale Datenrechte

Der Agent erhält nur die Daten, die für seine Aufgabe notwendig sind. „Der Nutzer darf alles sehen, also darf der Agent dasselbe“ ist kein ausreichendes Modell. Ein Mensch bringt Kontext, Zurückhaltung und soziale Verantwortung mit; ein automatisierter Ablauf kann Daten in größerer Menge und Geschwindigkeit verarbeiten.

Zu klären sind:

• erlaubte Datenquellen und Felder,
• Schutz- und Vertraulichkeitsklassen,
• Mandanten-, Kunden- oder Abteilungsgrenzen,
• Speicherung von Ein- und Ausgaben,
• zulässige Weitergabe an Modelle und Werkzeuge,
• Löschung und Protokollierung.

Der Beitrag zum Betriebsmodell von Sprachmodellen zeigt, warum der vollständige Datenfluss wichtiger ist als die pauschale Wahl „lokal oder Cloud“.

3. Begrenzte Werkzeuge und Aktionen

Ein Agent für Ticketklassifikation benötigt keinen allgemeinen Datenbankzugriff. Ein Agent für Bestellvorschläge benötigt kein Werkzeug zur Zahlung.

Werkzeuge sollten möglichst:

• eine enge fachliche Funktion besitzen,
• Eingaben technisch validieren,
• erlaubte Objekte und Werte begrenzen,
• keine freien Systembefehle akzeptieren,
• eine eindeutige Rückmeldung liefern,
• Fehler sicher und sichtbar behandeln.

Je allgemeiner ein Werkzeug ist, desto mehr Sicherheits- und Prozesslogik muss der Agent selbst zuverlässig beherrschen. Das ist häufig die falsche Verteilung.

4. Unvertrauenswürdige Eingaben behandeln

Dokumente, E-Mails, Webseiten, Suchergebnisse und auch Ausgaben anderer Werkzeuge können fehlerhaft oder absichtlich manipuliert sein. Ein dort enthaltener Satz ist keine verbindliche Systemanweisung.

Die aktuelle OWASP-Leitlinie zu agentischer KI empfiehlt unter anderem, Eingaben, abgerufene Inhalte, Werkzeugausgaben und Agentennachrichten bis zur Validierung als nicht vertrauenswürdig zu behandeln. OWASP ist eine gemeinschaftlich entwickelte Sicherheitsquelle, keine gesetzliche oder behördliche Vorgabe. Für die technische Gestaltung liefert sie dennoch einen brauchbaren Prüfkatalog.

Praktisch bedeutet das:

• Daten und Anweisungen technisch trennen,
• Werkzeugparameter gegen Regeln validieren,
• kritische Werte mit führenden Systemen abgleichen,
• externe Inhalte nicht zur Änderung von Rechten oder Zielen verwenden,
• ungewöhnliche Aktionsfolgen blockieren oder eskalieren.

5. Menschliche Freigabe an der richtigen Stelle

Eine Freigabe ist sinnvoll, wenn die Aktion:

• schwer oder nicht rückgängig zu machen ist,
• finanzielle oder rechtliche Wirkung besitzt,
• privilegierte Rechte verändert,
• viele Personen, Systeme oder Daten betrifft,
• auf unsicherer Evidenz beruht.

Die Freigabe muss die entscheidungsrelevanten Informationen zeigen: geplante Aktion, betroffene Objekte, Quelle, wesentliche Annahmen und erwartete Wirkung. Ein „OK“-Knopf nach einer langen automatischen Kette schafft sonst nur Scheinkontrolle.

Für niedrigwirksame und vollständig reversible Schritte kann eine pauschale menschliche Freigabe unverhältnismäßig sein. Dort sind technische Grenzen, Stichproben und Überwachung oft wirksamer.

6. Mengen-, Zeit- und Kostenlimits

Ein Fehler darf nicht unbegrenzt schnell skaliert werden. Sinnvolle Grenzen sind beispielsweise:

• Zahl der Datensätze pro Lauf,
• Zahl der Werkzeugaufrufe,
• maximale Laufzeit,
• zulässiger Kosten- oder Verbrauchsrahmen,
• Zahl fehlgeschlagener Versuche,
• maximale Wirkung pro Transaktion.

OWASP nennt hierfür Ressourcenbudgets und Circuit Breaker. Diese Grenzen dienen nicht nur der Kostenkontrolle. Sie begrenzen den Wirkungsradius einer Fehlentscheidung oder Manipulation.

7. Protokoll, Überwachung und Stoppsignal

Für jede relevante Aktion sollte nachvollziehbar sein:

• welches Ziel vorlag,
• welche Datenquellen verwendet wurden,
• welche Werkzeuge mit welchen Parametern aufgerufen wurden,
• welche Freigabe erteilt wurde,
• welches Ergebnis und welcher Fehler entstand.

Protokollierung darf dabei selbst keine unnötigen vertraulichen Inhalte sammeln.

Abbruchbedingungen werden vor dem Betrieb festgelegt, etwa:

• unerlaubter Werkzeugaufruf,
• wiederholter Validierungsfehler,
• Überschreitung eines Limits,
• Abweichung von erwarteten Aktionsmustern,
• fehlende oder widersprüchliche Quelldaten,
• Qualitätsabfall nach Modell- oder Prozessänderung,
• Incident oder manueller Stop durch den Owner.

Ein Stoppsignal muss technisch wirken. Eine Richtlinie ohne Sperrmöglichkeit beendet keinen laufenden Agenten.

8. Fallback und Wiederanlauf

Wenn der Agent nicht handeln darf oder kann, braucht der Prozess einen definierten Weg:

• Übergabe an eine Rolle,
• Warteschlange mit vollständigem Kontext,
• manueller Standardprozess,
• Rücknahme bereits reversibler Schritte,
• Wiederanlauf erst nach Prüfung.

Der Beitrag zur Produktionsreife von KI-Piloten behandelt Owner, Qualitätsgrenze, Monitoring, Incident und Fallback als Teile einer betrieblichen Fähigkeit. Für Agenten kommen Aktionsrechte und Wirkungsbegrenzung ausdrücklich hinzu.

Konstruiertes Beispiel: Rechnung verarbeiten, Zahlung verhindern

Das folgende Beispiel ist konstruiert.

Ein Agent soll E-Mails von Lieferanten lesen, Rechnungsdaten extrahieren und im ERP einen Buchungsentwurf vorbereiten. Im Postfach trifft eine manipulierte Anlage ein. Ihr Text fordert das System auf, eine neue Bankverbindung zu verwenden und die Rechnung sofort zu bezahlen.

In einem zu weit gefassten Modell besitzt der Agent Zugriff auf Lieferantenstammdaten und Zahlungsläufe. Die schädliche Anweisung könnte dadurch weitreichende Wirkung entfalten.

Im begrenzten Modell:

• liest der Agent nur ein freigegebenes Postfach,
• gleicht Lieferant und Bestellbezug mit führenden Daten ab,
• darf er ausschließlich einen gekennzeichneten Entwurf anlegen,
• kann er keine Stammdaten ändern,
• kann er keine Zahlung freigeben,
• werden Abweichungen an die Kreditorenrolle übergeben,
• führen ungewöhnliche Werte oder wiederholte Fehler zum Abbruch.

Die menschliche Freigabe wird nicht nach beliebiger Agentenarbeit ergänzt. Die technische Architektur verhindert bereits, dass der Agent die hochwirksamen Aktionen ausführen kann.

Ein Berechtigungsrahmen für jeden Agenten

Feld	Zu klärende Entscheidung
Zweck	genau abgegrenzte Aufgabe und zulässiges Ergebnis
Owner	fachliche Wirkung, technischer Betrieb und Risikofreigabe
Identität	technisches Konto und Zuordnung zum auslösenden Nutzer
Daten	erlaubte Quellen, Felder, Schutzklassen und Speicherung
Werkzeuge	explizit erlaubte Funktionen und technische Validierung
Aktionen	lesen, vorschlagen, entwerfen oder ausführen
Freigaben	welche Rolle welche Wirkung bestätigen muss
Limits	Menge, Zeit, Kosten, Versuche und Transaktionswirkung
Protokoll	notwendige Nachvollziehbarkeit ohne unnötige Datensammlung
Abbruch	automatische und manuelle Stoppsignale
Fallback	Übergabe, Rücknahme und sicherer Wiederanlauf
Überprüfung	Ereignisse und Termin für erneute Freigabe

Der BSI-Kriterienkatalog für KI-Modelle und KI-Systeme ordnet Risiken, Folgen, Maßnahmen und Zuständigkeiten anwendungsbezogen über den Lebenszyklus. Er liefert keine fertige Agentenrolle für jedes Unternehmen. Er stützt aber den entscheidenden Ansatz: Schutzmaßnahmen folgen dem konkreten Einsatz und seiner möglichen Wirkung.

Wann ein Agent die falsche Lösung ist

Ein Agent sollte nicht produktiv handeln, wenn:

• der Prozess selbst unklar oder widersprüchlich ist,
• notwendige Daten nicht verlässlich sind,
• Entscheidungen nicht durch Regeln und verantwortete Ausnahmen begrenzbar sind,
• hochwirksame Aktionen technisch nicht getrennt werden können,
• Protokollierung, Stop und Fallback fehlen,
• niemand die fachliche Wirkung und den Betrieb übernimmt.

In diesen Fällen kann ein rein unterstützender Assistent sinnvoller sein: Er sucht, fasst zusammen oder erstellt einen Entwurf, ohne selbst den Geschäftsprozess zu verändern.

Der erste sinnvolle Schritt ist keine Auswahl eines Agenten-Frameworks. Schreiben Sie für einen Anwendungsfall alle möglichen Aktionen auf und ordnen Sie sie nach Wirkung und Rückholbarkeit. Erst danach werden Identität, Werkzeuge und Rechte vergeben. Ein Agent darf nur so autonom sein, wie seine schlimmste zulässige Aktion beherrschbar ist.