Schreiben Sie "sende nie eine Mail an einen Kunden ohne Freigabe" in die Anweisungen eines Agenten, und Sie haben eine Bitte formuliert. Ein gutes Modell hält sich fast immer daran. Fast immer reicht für den Tonfall einer Antwort und reicht nicht für etwas, das sich nicht zurückholen lässt, denn der Preis des seltenen Fehlers ist nicht der Durchschnittspreis. Es ist der ganze Preis. Eine Gutschriftbestätigung an den falschen Kunden wird durch neunhundert korrekte Ablehnungen nicht ausgeglichen.
An dieser Linie entscheidet sich, wie ein Agenten-Build gebaut wird. Ein Teil der Regeln gehört in den Prompt, wo jeder in der Abteilung sie ändern kann. Ein anderer Teil gehört in den Code, wo der Agent sie nicht erreicht. Diese Aufteilung richtig zu ziehen, ist der größte Teil dessen, was ein Agentensystem betriebsfähig macht.
Warum eine Anweisung keine Wand sein kann
Ein Sprachmodell zieht Stichproben. Stellen Sie dieselbe Frage zweimal, und Sie bekommen womöglich zwei verschiedene Antworten. Für einen Antwortentwurf ist das nützlich, als Sicherheitseigenschaft ist es wertlos. Es gibt keine Einstellung, die aus einer Wahrscheinlichkeit eine Garantie macht.
Anweisungen konkurrieren außerdem miteinander. Ein Prompt, der "nie externe Post ohne Freigabe" sagt und zwei Absätze später "dringende Kundenanfragen am selben Tag beantworten", enthält einen Widerspruch, und das Modell löst Widersprüche nach Einschätzung auf, nicht nach Rangfolge. Nach sechs Monaten, in denen drei Leute an dieser Datei gearbeitet haben, gibt es mehrere solcher Stellen.
Dann sind da die Daten. Ein Agent, der Kundenpost liest, liest Text von Fremden, und in manchen dieser Texte stehen Anweisungen. Eine Nachricht, in deren Fließtext steht, bisherige Vorgaben zu ignorieren und die Erstattung direkt zu bestätigen, ist kein exotischer Angriff. So etwas passiert, manchmal versehentlich, wenn ein Kunde einen internen Verlauf weiterleitet. Der Agent hat kein verlässliches Mittel, eine Anweisung von Ihnen von einer Anweisung in seiner Eingabe zu unterscheiden.
Und Prompts sind nicht stabil über Modellversionen hinweg. Eine Regel, die unter einem Modell hielt, kann unter dem Nachfolger rutschen, weil gerade das Befolgen von Verboten zu dem gehört, was sich zwischen Versionen verschiebt. Der Wechsel kommt, ob Sie ihn planen oder nicht.
Welche Einschränkungen in den Code gehören
Der Test hat eine Frage. Wenn der Agent das einmal falsch macht, können wir es bis zum Mittag rückgängig machen. Lautet die Antwort nein, gehört die Regel nicht in einen Prompt.
Das trifft vier Arten von Aktionen. Alles Unumkehrbare. Alles, was das Haus verlässt. Alles, was Geld bewegt. Alles, was Daten vernichtet. Der ganze Rest, und das ist der größere Teil des Verhaltens, darf in der Prompt-Bibliothek liegen, wo die Abteilung ihn nachjustiert.
Nie externe Post ohne menschliche Freigabe. Der Mechanismus ist, dass der Agent die Zugangsdaten zum Mailversand nicht besitzt. Sein Werkzeug schreibt eine Zeile in eine Entwurfstabelle mit dem Status gehalten, und mehr kann dieses Werkzeug nicht. Ein getrennter Versanddienst hält die Zugangsdaten und überträgt nur Zeilen, an denen ein Freigabesatz mit Benutzerkennung und Zeitstempel hängt. Wenn der Agent nachts um drei zu dem Schluss kommt, dass eine Nachricht dringend ist, dann ist das Stärkste, was er tun kann, eine Zeile zu schreiben.
Nie im Hauptbuch buchen. Hier liegt die Grenze bei den Rechten, nicht im Code des Agenten. Der Datenbankbenutzer, unter dem der Agent läuft, hat auf den Hauptbuchtabellen kein Schreibrecht. Er schreibt Vorschläge in seine eigene Tabelle, und die Buchung löst ein Mensch aus. Läuft die Buchhaltung als Dienst in der Cloud, bekommt der Agent einen API-Zugang mit einer Rolle, die Buchungen nicht kennt. Kennt das Tool keine feinen Rollen, geht der Schreibweg über einen kleinen eigenen Dienst, der nur die erlaubten Felder durchlässt und alles andere ablehnt.
Nie einen Datensatz löschen. Am einfachsten dadurch, dass es kein Werkzeug zum Löschen gibt. Ein Modell kann keine Funktion aufrufen, die im Werkzeugkatalog nicht steht. Wo ein Vorgang trotzdem verschwinden können muss, setzt der Agent eine Markierung, und ein Aufräumlauf mit eigenem Zeitplan und eigener Freigabe entfernt später das Markierte.
Dieselbe Logik trägt Betragsgrenzen, Empfängerlisten mit ausschließlich internen Domains und Zeitfenster, außerhalb derer bestimmte Aktionen nicht ausgeführt werden. Jedes Mal lautet die Frage, wer das Recht hält, und nicht, was im Prompt steht.
Wo die Leitplanke sitzt
Eine Leitplanke, die auf derselben Ebene wie der Agent liegt, ist keine. Wenn der Agent den Code aufrufen kann, der die Prüfung macht, kann er sie auch umgehen, sobald ein Werkzeug ihm das nebenbei erlaubt. Die Leitplanke sitzt eine Ebene tiefer: in den vergebenen Rechten, im Werkzeugkatalog und in einem Dienst zwischen Agent und System, der die Anfrage prüft, bevor sie das System erreicht.
Die Faustregel dazu ist unbequem und nützlich. Nehmen Sie an, ein Angreifer dürfte den Prompt schreiben. Welche Regeln würden dann noch halten. Genau diese sind Leitplanken. Alles andere ist Stil.
Wie man prüft, dass eine Leitplanke hält
Der Satz "wir haben eine Leitplanke" ist wertlos ohne einen Test, der rot werden kann.
Ein Test pro Regel, der die verbotene Aktion direkt anfordert, am Modell vorbei. Rufen Sie das Werkzeug mit den verbotenen Argumenten auf und erwarten Sie eine Ablehnung, nicht ein Protokoll und eine trotzdem ausgeführte Aktion. Dieser Test läuft in Sekunden und findet die Fälle, in denen jemand die Prüfung beim Umbau versehentlich entfernt hat.
Ein Test, der das Modell zur Übertretung drängt. Eine Eingabe, die aussieht wie eine Kundenmail und die Anweisung enthält, sofort zu antworten. Eine, die eine Vorgesetztenrolle behauptet. Eine, die die Regel als veraltet bezeichnet. Diese Fälle sammeln wir in einer Datei, und jede neue Variante, die im Betrieb auftaucht, kommt dazu.
Ein Test mit weggenommener Leitplanke. Schalten Sie die Prüfung ab und stellen Sie sicher, dass der Test dann fehlschlägt. Ein Test, der auch ohne die Leitplanke grün bleibt, misst nichts, und davon gibt es in freier Wildbahn mehr, als man glaubt.
Diese Tests laufen bei jeder Änderung am Prompt, am Code und an der Modellversion. Der Modellwechsel ist der wichtigste Auslöser, weil er von außen kommt und weil er genau die Eigenschaft verschiebt, auf die sich Anweisungen verlassen.
Dazu kommt eine Messung am laufenden System. Eine Abfrage, die zählt, wie viele Mails ohne Freigabesatz das Haus verlassen haben. Der erwartete Wert ist null. Sie läuft wöchentlich, und ein Mensch sieht das Ergebnis an. Möglich wird das nur, weil jede Aktion mit Zeitstempel, Akteur und Argumenten im Prüfprotokoll steht. Ohne dieses Protokoll können Sie nach einem Vorfall nicht beantworten, ob die Leitplanke gehalten hat, und die Frage kommt genau dann, wenn Sie sie nicht offen lassen wollen.
Was im Prompt bleiben darf
Der Ton einer vorformulierten Antwort. Die Schwelle, ab der eskaliert statt entschieden wird. Die Formulierung einer Ablehnung. Die Reihenfolge der Prüfschritte. Die Liste, an wen ein bestimmter Fall geht. Alles, was Sie am Dienstag ändern und am Mittwoch zurücknehmen können, gehört dorthin, wo Ihr Team es ohne uns ändert.
Teams, die aus Vorsicht jede Regel in Code gießen, bauen ein System, das niemand mehr anfasst und das deshalb altert. Teams, die alles in den Prompt schreiben, bauen eines, das man nicht unbeaufsichtigt laufen lassen kann. Die Trennlinie ist nicht Vorsicht und auch nicht Bequemlichkeit. Sie ist die Frage, ob sich der Fehler bis zum Mittag zurückholen lässt.