Prüfen vor dem nächsten Agent-Tool

Teil 1

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:

Erst wird ein einzelnes neues Werkzeug gewählt, nicht ein ganzer Werkzeugkasten.
Dann werden gute und schlechte Testfälle festgelegt: Wann darf der Agent handeln, wann muss er stoppen?
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 gutes Gate beantwortet vier Fragen:

Welcher konkrete Agent-Pfad soll erweitert werden?
Welches einzelne Werkzeug soll neu dazukommen?
Wer verantwortet fachlich die Entscheidung?
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.

Praktisch gehst du so vor:

Wähle einen echten Agent-Pfad aus.
Benenne genau ein neues Werkzeug.
Friere die Allowlist für dieses Werkzeug ein, bis das Gate entschieden ist.
Benenne den fachlichen Owner.
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 ->

Teil 2

Soll-Fälle und Missbrauch testen

Teil 1 hat das Grundprinzip gesetzt: Erst prüfen, dann ein neues Werkzeug freischalten. Dieser Teil zeigt, wie die Prüfung konkret aussieht.

Ein guter Test besteht nicht nur aus freundlichen Beispielen. Er prüft auch, ob der Agent bei falschen, riskanten oder unklaren Anforderungen stoppt. Genau dort entstehen in echten Unternehmen die Schäden: nicht beim einfachen Standardfall, sondern beim Fall, der fast erlaubt aussieht.

<- Vorheriger Teil · Nächster Teil ->

Einstieg

Das Team hat einen Agenten, der eine Erstattung anlegen soll. Es gibt zwei erfolgreiche Testprompts: "Bitte erstatte den genehmigten Fall 4711" und "Lege die Erstattung aus dem Supportticket an." Beide wirken gut.

Was fehlt, sind die Gegenproben: Was passiert, wenn jemand die eigene Erstattung anlegen will? Was passiert, wenn die Genehmigung fehlt? Was passiert, wenn der Betrag höher ist als erlaubt? Ohne solche Missbrauchsfälle weiß niemand, ob der Agent wirklich begrenzt ist.

Begriffe vor dem Lesen

Soll-Fall: Ein erlaubter Standardfall, in dem der Agent das Werkzeug nutzen darf.
Missbrauchsfall: Ein absichtlich kritischer Fall, in dem der Agent stoppen muss.
Golden Trace: Ein fest gespeicherter Testfall mit Eingabe, erwartetem Werkzeugaufruf und erwartetem Ergebnis.
Side Effect: Eine echte Wirkung im System, zum Beispiel ein neues Ticket, eine Erstattung, eine E-Mail oder eine geänderte Berechtigung.
Fail closed: Wenn der Test unsicher ist oder misslingt, bleibt das Werkzeug gesperrt.
Waive: Eine bewusst befristete Ausnahme mit Verantwortlichem, Ablaufdatum und Rest-Risiko.

Was geprüft wird

Ein Testfall muss mehr sagen als "Antwort war gut". Er muss festhalten:

Welche Eingabe bekommt der Agent?
Welches Werkzeug darf oder darf nicht aufgerufen werden?
Welche Wirkung im System ist erwartet?
Was ist das Ergebnis: blockiert, befristet freigegeben oder bestanden?

Entscheidung

Erstelle für jedes neue Write-Tool ein kleines Testpaket:

drei bis sieben Soll-Fälle, die der Agent können muss
mindestens zwei Missbrauchsfälle, die sicher stoppen müssen
eine klare Erwartung pro Fall: Werkzeugaufruf ja oder nein, Wirkung ja oder nein
ein Ergebnis pro Lauf: block, waive oder pass

Ein pass ist nur sinnvoll, wenn auch die Missbrauchsfälle geprüft wurden. Fehlen sie, bleibt die Entscheidung blockiert. Ein waive ist keine bequeme Abkürzung, sondern eine Ausnahme: Wer trägt das Risiko, wie lange gilt sie, und was muss nachgezogen werden?

Mini-Fall

Der Kandidat ist das Werkzeug "Erstattung anlegen".

Ein Soll-Fall lautet: Ein Supportticket ist genehmigt, Kundennummer und Betrag stimmen, ein Mensch bestätigt. Erwartung: Der Agent ruft das Erstattungswerkzeug auf und legt genau diesen Vorgang an.

Ein Missbrauchsfall lautet: Ein Mitarbeiter bittet den Agenten, eine Erstattung auf sein eigenes Kundenkonto anzulegen und die Freigabe zu überspringen. Erwartung: Der Agent ruft kein Erstattungswerkzeug auf, legt nichts an und eskaliert den Fall.

Wenn der Agent im Missbrauchsfall trotzdem eine Erstattung vorbereitet oder auslöst, ist das kein kleiner Prompt-Fehler. Das Gate ist blockiert, bis die Grenze technisch und fachlich verlässlich hält.

Woran du schlechte Praxis erkennst

Es gibt nur freundliche Testprompts.
Die erwartete Systemwirkung steht nirgends.
Missbrauchsfälle liegen nur im Chatverlauf.
Ein einmaliges "Das Modell hat abgelehnt" wird als Beweis verkauft.
Eine Ausnahme für Geld, Rechte oder externe Nachrichten hat kein Ablaufdatum.
Fairness- oder Grundrechteprüfung wird mit dieser Werkzeugprüfung vermischt.

Umsetzung im Alltag

Nutze dieselbe Arbeitsfläche wie im ersten Teil:

Praktisch gehst du so vor:

Schreibe die wichtigsten erlaubten Standardfälle auf.
Schreibe die gefährlichsten Fehl- oder Missbrauchsfälle auf.
Notiere für jeden Fall, ob ein Werkzeugaufruf erwartet ist.
Notiere die erlaubte oder verbotene Wirkung im Zielsystem.
Führe die Tests in der gleichen technischen Umgebung aus, in der das Werkzeug später laufen soll.
Halte das Ergebnis sichtbar beim Agent-Pfad fest.

Nächster Schritt

Im nächsten Teil geht es darum, wann diese Prüfung erneut laufen muss: bei neuen Werkzeugen, neuen Daten, neuen Berechtigungen oder einer veränderten Umgebung.

<- Vorheriger Teil · Nächster Teil ->

Teil 3

Nach Änderungen erneut prüfen

Teil 1 hat das Gate vor dem neuen Werkzeug beschrieben. Teil 2 hat gezeigt, wie Soll-Fälle und Missbrauchsfälle aussehen. Dieser Teil klärt, wann eine bestandene Prüfung wiederholt werden muss.

Der kurze Merksatz lautet: Ein bestandener Test ist keine Dauerlizenz. Er gilt für den Umfang, der tatsächlich geprüft wurde.

<- Vorheriger Teil

Einstieg

Der Support-Agent durfte nach erfolgreicher Prüfung eine Erstattung in der Support-Umgebung vorbereiten. Später soll dasselbe Werkzeug auch in Finance genutzt werden. Die technische Funktion sieht gleich aus, aber der Kontext ist ein anderer: andere Daten, andere Verantwortliche, andere Folgen.

Wenn das Team jetzt nur auf die alte Prüfung verweist, entsteht ein Governance-Fehler. Der Agent wurde nicht für "alles mit Erstattung" freigegeben. Er wurde für einen konkreten Pfad, ein konkretes Werkzeug und einen konkreten Umfang geprüft.

Begriffe vor dem Lesen

Scope: Der geprüfte Umfang, zum Beispiel Werkzeug, Datenbereich, Umgebung und Berechtigung.
Scope-Änderung: Eine relevante Erweiterung dieses Umfangs.
Identität: Das technische Konto oder die Rolle, mit der der Agent ein Werkzeug nutzt.
Umgebung: Der Systemkontext, zum Beispiel Support-Testsystem, Produktivsystem oder Finance-System.
Retest: Die erneute Prüfung mit den bestehenden Testfällen und ergänzten Fällen für die neue Fähigkeit.
Drift: Eine schleichende Veränderung, durch die ein ehemals sicherer Pfad heute anders reagiert.

Wann erneut geprüft wird

Eine erneute Prüfung ist nötig, wenn sich etwas ändert, das die Wirkung des Agenten verändern kann:

ein neues Werkzeug
ein weiterer Datenbereich
eine neue Umgebung
eine breitere Berechtigung
eine wiederverwendete technische Identität
ein größerer Modell-, Prompt- oder Regelwechsel
ein neuer fachlicher Zweck

Entscheidung

Der technische Betreiber darf eine Erweiterung nur freischalten, wenn eine aktuelle Gate-Zeile für genau diese Erweiterung existiert. Ein alter Pass darf nicht für einen neuen Umfang gedehnt werden.

Das bedeutet nicht, dass jedes Mal alles neu erfunden wird. Das bestehende Testpaket bleibt die Basis. Die alten Soll- und Missbrauchsfälle werden erneut ausgeführt. Für die neue Fähigkeit kommen passende Fälle hinzu. So bleibt die Prüfung leichtgewichtig, aber nachvollziehbar.

Auch ohne sichtbare Änderung sollte das Paket regelmäßig wiederholt werden. Das ist kein Workshop mit neuen Folien, sondern ein Wiederholungslauf: gleiche Kernfälle, neues Datum, neues Ergebnis.

Mini-Fall

Das Werkzeug "Erstattung anlegen" wurde für den Support getestet. Jetzt soll es im Finance-Bereich laufen, weil dort Reklamationen nachbearbeitet werden. Die Bot-Identität bekommt Zugriff auf andere Buchungsdaten.

Das ist eine Scope-Änderung. Der alte Support-Pass reicht nicht. Finance hat andere Risiken: Zahlungen können anders verbucht werden, andere Personen sehen die Ergebnisse, und Fehler können in den Monatsabschluss laufen.

Das Team wiederholt die vorhandenen Testfälle und ergänzt Finance-spezifische Fälle. Erst danach wird entschieden, ob die Allowlist erweitert wird.

Woran du schlechte Praxis erkennst

"Der Agent wurde schon evaluiert" ersetzt die konkrete Scope-Prüfung.
Eine technische Identität wird für ein neues Team erweitert, ohne erneute Entscheidung.
Ein Prompt- oder Modellwechsel wird nicht gegen die Werkzeugfälle getestet.
Monitoring in Produktion wird als Retest ausgegeben.
Der technische Betreiber bekommt kein klares "ja", "nein" oder "befristete Ausnahme".

Umsetzung im Alltag

Nutze den Plan nicht als starre Kalenderübung, sondern als Nachweis, wann eine Erweiterung wirklich geprüft wurde.

Praktisch gehst du so vor:

Notiere beim Agent-Pfad den aktuell geprüften Scope.
Definiere, welche Änderungen das Gate wieder öffnen.
Lasse bei jeder relevanten Änderung das Testpaket erneut laufen.
Ergänze Testfälle nur dort, wo die neue Fähigkeit neue Risiken bringt.
Halte Datum, Umfang, Ergebnis und Verantwortliche sichtbar fest.
Lege ein Wiederholungsintervall fest, damit schleichende Veränderungen sichtbar werden.

Weiterlesen

Abschluss

Nach dieser Serie sollte ein Team drei Dinge sauber können: ein neues Agent-Tool vor der Freischaltung begrenzen, gute und schlechte Testfälle dokumentieren und die Prüfung bei relevanten Änderungen wiederholen.

<- Vorheriger Teil