Erst prüfen, dann schreiben lassen

Agent-Tool-Calling-Ops beschreibt den Betrieb mit menschlicher Freigabe, Grenzen und Rückbau. KI-Assurance betreiben prüft Fairness, Grundrechte und Risiko. Diese Serie sitzt dazwischen: Sie klärt, wann ein Agent überhaupt das nächste Werkzeug bekommen darf.

Ein Agent-Tool ist eine Funktion, die ein KI-Agent aufrufen kann. Lesen ist meist weniger kritisch: Der Agent holt Informationen. Schreiben ist anders: Der Agent ändert Daten, verschickt etwas, sperrt etwas, startet eine Zahlung oder nutzt eine Identität. Dafür reicht eine gute Demo nicht.

Nächster Teil ->

Einstieg

Ein Support-Team nutzt einen Agenten, der in Richtlinien sucht und Antworten vorschlägt. Das funktioniert gut. Nun soll derselbe Agent auch Erstattungen anlegen. Im Meeting klingt das logisch: Der Agent kennt den Fall, der Mensch spart Zeit, der Prozess wird schneller.

Das Problem entsteht, wenn aus "der Agent kann lesen" stillschweigend "der Agent darf handeln" wird. Eine Erstattung ist kein Textvorschlag. Sie erzeugt einen echten Vorgang im Unternehmen. Deshalb braucht dieses neue Werkzeug ein Gate: eine dokumentierte Entscheidung, ob der Agent es bekommen darf.

Diese Serie ist für dich, wenn ein Agent schon eingesetzt wird oder kurz vor dem Start steht und ein neues Werkzeug bekommen soll, das Daten verändert, Geld bewegt, Rechte nutzt oder externe Systeme anspricht.

Nicht diese Serie, wenn du gerade den kompletten Betrieb mit Eskalation, menschlicher Freigabe und Rückbau entwirfst. Dafür ist Agent & Tool-Calling Operations der passendere Einstieg.

Begriffe vor dem Lesen

• Agent: Eine KI-Anwendung, die nicht nur antwortet, sondern auch Werkzeuge aufrufen kann.
• Tool: Eine technische Funktion, die der Agent nutzt, zum Beispiel "Ticket lesen", "Adresse ändern" oder "Erstattung anlegen".
• Read-Tool: Ein Werkzeug, das Informationen liest, aber nichts verändert.
• Write-Tool: Ein Werkzeug, das etwas verändert oder auslöst. Dazu zählen auch Geldvorgänge, Berechtigungen und externe Nachrichten.
• Allowlist: Die Liste der Werkzeuge, die ein Agent nutzen darf.
• Eval-Gate: Der dokumentierte Prüfpunkt vor einer Erweiterung: bestanden, blockiert oder bewusst befristet freigegeben.
• Owner: Die Person oder Rolle, die fachlich verantwortet, ob der Agent dieses Werkzeug bekommen darf.

Was diese Serie klärt

Diese Serie zeigt drei Entscheidungen:

1. Erst wird ein einzelnes neues Werkzeug gewählt, nicht ein ganzer Werkzeugkasten.
2. Dann werden gute und schlechte Testfälle festgelegt: Wann darf der Agent handeln, wann muss er stoppen?
3. Nach einer relevanten Änderung wird erneut geprüft, statt sich auf einen alten Test zu berufen.

Entscheidung

Die wichtigste Regel lautet: Ein erfolgreicher Leseprozess ist keine Freigabe für einen Schreibprozess.

Wenn der Agent bisher nur Antworten vorschlägt, ist noch nicht bewiesen, dass er auch Erstattungen, Sperren, Bestellungen oder Zugriffe sicher auslösen kann. Dafür braucht es einen eigenen Prüfnachweis. Der Prüfnachweis muss vor der technischen Freischaltung vorliegen, nicht danach.

Ein fehlgeschlagenes erforderliches Gate hält den erweiterten Scope geschlossen. Eine Ausnahme ist nur innerhalb tatsächlich abdingbarer Vorgaben zulässig, mit ausdrücklicher Entscheidung, begrenztem Scope, kompensierenden Kontrollen, Owner und Ablaufdatum. Sie ersetzt weder nicht abdingbare Pflichten noch den Nachweis für einen uneingeschränkten Rollout. Auch nach bestandenem Gate bleiben Laufzeitüberwachung, Berechtigungsgrenzen, Eskalation und Rücknahmewege erforderlich.

Ein gutes Gate beantwortet vier Fragen:

1. Welcher konkrete Agent-Pfad soll erweitert werden?
2. Welches einzelne Werkzeug soll neu dazukommen?
3. Wer verantwortet fachlich die Entscheidung?
4. Welche Testfälle müssen bestehen, bevor das Werkzeug freigeschaltet wird?

Mini-Fall

Der Support-Agent beantwortet Kundenfragen zu Rückerstattungen. Nun soll er direkt eine Erstattung im System anlegen können. Im ersten Schritt darf nicht das gesamte Finanz-Werkzeugpaket freigegeben werden. Es geht nur um ein Werkzeug: "Erstattung anlegen".

Der Owner legt fest, wann das Werkzeug erlaubt ist: zum Beispiel bei einem genehmigten Supportfall, für einen begrenzten Betrag und nur mit menschlicher Freigabe. Gleichzeitig wird festgelegt, wann der Agent stoppen muss: wenn der Fall unklar ist, der Kunde nicht eindeutig passt oder der Betrag über der Grenze liegt.

Erst wenn diese Prüfung dokumentiert ist, darf der technische Betreiber das Werkzeug auf die Allowlist setzen.

Woran du schlechte Praxis erkennst

• Eine Demo wird als Freigabe verstanden.
• Mehrere Werkzeuge werden auf einmal freigeschaltet.
• Niemand kann sagen, wer die fachliche Entscheidung verantwortet.
• Die Tests werden erst nach dem ersten echten Vorgang geplant.
• Menschliche Freigabe wird mit Eval verwechselt. Beides ist wichtig, aber nicht dasselbe.

Umsetzung im Alltag

Nutze den Plan als Arbeitsfläche, aber halte die Entscheidung so fest, dass ein neuer Kollege sie ohne Vorwissen versteht.

• Arbeitsplan - Prüfen vor dem nächsten Agent-Tool
• Lernpfad - Prüfen vor dem nächsten Agent-Tool

Praktisch gehst du so vor:

1. Wähle einen echten Agent-Pfad aus.
2. Benenne genau ein neues Werkzeug.
3. Friere die Allowlist für dieses Werkzeug ein, bis das Gate entschieden ist.
4. Benenne den fachlichen Owner.
5. Schreibe die Go/No-Go-Frage in Alltagssprache: "Was muss sicher funktionieren, bevor dieser Agent dieses Werkzeug nutzen darf?"

Nächster Schritt

Im nächsten Teil geht es um die Testfälle selbst: erlaubte Standardfälle, Missbrauchsfälle und die Frage, was als bestanden gilt.

Nächster Teil ->