KI-Agenten Monitoring: Protokollierung, Alarme und Rückrollen im Betrieb

Am Montagmorgen fragt eine Kundin nach, warum sie am Freitagabend eine Terminbestätigung für einen Tag erhalten hat, den sie nie gewünscht hatte. Die Mitarbeiterin im Büro öffnet das Postfach und findet die Nachricht, abgeschickt vom Agenten. Was er gelesen hat, was er daraus geschlossen hat und welche Werkzeuge er dafür benutzte, kann sie nicht sehen. Es gibt nur das Ergebnis.

Dieses Szenario ist erfunden, das Muster nicht. Sobald ein Agent nicht nur Texte erzeugt, sondern Termine anlegt, Tickets zuordnet oder Daten in Systeme schreibt, verschiebt sich die Frage von „Ist die Antwort gut?“ zu „Was hat er eigentlich getan?“. Ein Chatbot, der sich irrt, produziert eine falsche Auskunft. Ein Agent, der sich irrt, hinterlässt Spuren in Ihren Systemen.

Betrieb heißt deshalb mehr als Bereitstellung. Wer einen Agenten einsetzt, übernimmt eine Aufgabe, die man von neuen Mitarbeitern kennt: Man schaut zu Beginn genau hin, lässt sich Entscheidungen erklären und gibt erst nach und nach Verantwortung ab. Der Unterschied ist, dass ein Agent diese Erklärung nur liefern kann, wenn sie im Vorfeld aufgezeichnet wurde. Nachträglich fragen lässt sich nicht.

In kleinen Betrieben wiegt das schwerer als in Konzernen. Es gibt keine eigene Abteilung, die Vorfälle untersucht, und die Person, die den Agenten eingerichtet hat, ist oft dieselbe, die nebenbei das Tagesgeschäft führt. Wenn dann etwas schiefgeht, entscheidet die Qualität der Aufzeichnung darüber, ob die Klärung eine Stunde dauert oder einen halben Tag, und ob die Kundin eine konkrete Antwort bekommt oder eine Ausrede.

Klassische Software fällt auf, wenn sie abstürzt. Agenten fallen selten so auf. Sie laufen weiter, liefern plausibel aussehende Ergebnisse und liegen trotzdem falsch. Das macht die Überwachung anspruchsvoller, denn das einfache Signal „läuft“ oder „läuft nicht“ sagt über die Qualität nichts aus.

Zu den häufigsten Fehlerbildern gehört die Schleife. Der Agent ruft dasselbe Werkzeug immer wieder auf, weil die Antwort nicht in sein erwartetes Muster passt, und verbraucht Rechenzeit und Budget, ohne voranzukommen. Ein zweites Bild ist der falsche Werkzeugaufruf: richtiges Werkzeug mit falschen Parametern oder das falsche Werkzeug für die Aufgabe. Ein drittes sind Zeitüberschreitungen, bei denen eine Schnittstelle nicht antwortet und der Agent entweder aufgibt oder mit unvollständigen Informationen weitermacht.

Das tückischste Bild ist die geänderte Schnittstelle. Ein angebundenes System ändert Feldnamen, Formate oder Antwortcodes, und der Agent interpretiert die neuen Daten nach altem Muster. Er „funktioniert“ weiter, nur eben falsch. Hier hilft kein Alarm auf Abstürze, sondern nur der Vergleich zwischen erwartetem und tatsächlichem Verhalten.

Hinzu kommen Fehler, die in der Anweisung selbst liegen. Eine Formulierung, die in den Tests eindeutig war, wird bei einer ungewohnten Eingabe anders gelesen. Solche Fehler lassen sich nicht allein durch Technik abfangen. Sie brauchen einen Menschen, der regelmäßig echte Vorgänge ansieht und sie mit der Absicht der Anweisung vergleicht.

Protokollieren heißt nicht, alles zu speichern. Ein vollständiger Mitschnitt jedes Modellaufrufs erzeugt große Datenmengen, die niemand liest, und enthält oft personenbezogene Informationen, die Sie gar nicht länger als nötig aufbewahren wollen. Die Frage lautet, welche Angaben nötig sind, um einen Vorgang später zu erklären.

Ausreichend ist meist ein Datensatz pro Schritt mit vier Bestandteilen: Was kam herein, was hat der Agent daraus entschieden, welche Aktion hat er ausgelöst, und auf welche Quelle stützt sich die Entscheidung? Ergänzt um eine Vorgangskennung, einen Zeitstempel, die verwendete Anweisungsversion und das Ergebnis des Werkzeugaufrufs lässt sich damit jeder Vorgang rekonstruieren.

Die Kennung ist wichtiger, als sie zunächst wirkt. Ein Vorgang besteht aus vielen Schritten, die über mehrere Systeme verteilt sind. Nur wenn derselbe Schlüssel in Posteingang, Agentenprotokoll und Zielsystem auftaucht, lässt sich ein Vorfall von der Kundenbeschwerde bis zum auslösenden Schritt zurückverfolgen. Ohne ihn bleibt Detektivarbeit.

Eine Grenze gehört dazu: Das Protokoll ist Betriebsdokumentation, kein Dauerarchiv. Legen Sie fest, wie lange es aufbewahrt wird, wer es einsehen darf und welche Felder maskiert werden. Bei personenbezogenen Daten gilt der Grundsatz der Datensparsamkeit; die konkrete Ausgestaltung sollten Sie mit Ihrer Datenschutzbeauftragten klären. Dieser Text ist keine Rechtsberatung.

Ein praktischer Prüfstein für die Qualität der Spur: Lassen Sie jemanden, der den Agenten nicht eingerichtet hat, einen beliebigen Vorgang aus dem Protokoll erklären. Gelingt das ohne Rückfrage an den Entwickler, ist die Spur brauchbar. Muss er raten oder in drei Systemen suchen, fehlt ein Feld, oder die Kennung wird nicht durchgereicht. Dieser Test kostet eine Viertelstunde und deckt Lücken auf, bevor ein echter Vorfall es tut.

Die naheliegende Lösung wäre ein Dashboard mit Kennzahlen: Anzahl der Vorgänge, durchschnittliche Dauer, Fehlerquote. Das ist nützlich und reicht nicht, weil es das Verhalten des Agenten nur im Durchschnitt zeigt. Eine einzelne falsche Terminbestätigung verschwindet in einer Statistik, bleibt aber für die betroffene Kundin ein Vorfall.

Eine zweite Option ist, alles dem Anbieter des Modells oder der Plattform zu überlassen und deren eingebaute Auswertungen zu nutzen. Das spart Aufwand, bindet aber die Nachvollziehbarkeit an eine fremde Oberfläche. Wenn Sie den Anbieter wechseln oder zwei Werkzeuge kombinieren, reißt die Spur ab. Wir würden die Protokolle deshalb in einem eigenen, einfachen Format in Ihrer Umgebung führen und die Werte der Plattform als Ergänzung nutzen.

Als dritte Möglichkeit bietet sich die rein manuelle Kontrolle an: Jemand liest regelmäßig Vorgänge. Das ist unverzichtbar, aber allein nicht tragfähig, denn es skaliert nicht und findet Fehler erst, wenn sie schon passiert sind. Darum kombinieren wir drei Ebenen, die einander ergänzen: automatische Alarme für klare Regelverstöße, laufende Kennzahlen für Trends und Stichproben durch Menschen für das, was kein Regelwerk erkennt.

Diese Kombination ist ein Kompromiss. Mehr Alarme bedeuten mehr Störungen und irgendwann Abstumpfung, mehr Stichproben binden Zeit. Wo die Schwelle liegt, hängt davon ab, was ein Fehler kostet. Ein Agent, der interne Notizen sortiert, darf lockerer überwacht werden als einer, der Kunden schreibt oder Angebote vorbereitet.

Ein Alarm ist nur dann hilfreich, wenn jemand weiß, was danach zu tun ist. Wir koppeln deshalb jeden Alarm an eine kurze Handlungsanweisung: Wer wird informiert, was wird geprüft, darf der Agent weiterlaufen oder wird er pausiert? Alarme ohne definierten nächsten Schritt landen erfahrungsgemäß im Postfach und werden ignoriert.

Beim Kostenmonitoring zählt weniger der Gesamtbetrag als die Abweichung vom Normalverlauf. Ein Agent, der pro Vorgang plötzlich ein Vielfaches an Modellaufrufen benötigt, hat meist ein Problem mit Schleifen, zu langem Kontext oder fehlerhaften Wiederholungen. Eine harte Obergrenze pro Vorgang und eine Tagesgrenze begrenzen den Schaden, bevor ein Mensch eingreifen kann. Beim Erreichen der Grenze sollte der Vorgang an eine Person übergeben werden, nicht stillschweigend verworfen.

Stichproben-Reviews schließen die Lücke, die Alarme nicht sehen. Wir würden mit einem festen Rhythmus beginnen, etwa einer kleinen Zahl zufällig gezogener Vorgänge pro Woche, ergänzt um alle Vorgänge, bei denen der Agent unsicher war oder an einen Menschen übergeben wurde. Die Prüferin sieht Eingabe, Spur und Ergebnis nebeneinander und bewertet nach einem kurzen Raster: richtig, vertretbar, falsch.

Aus dem Raster entsteht Wissen. Häufen sich „vertretbar“-Urteile bei einer bestimmten Anfrageart, ist die Anweisung dort zu offen. Häufen sich „falsch“-Urteile nach einem bestimmten Datum, lohnt der Blick auf eine Änderung an der Schnittstelle oder an der Anweisung. Das Review ist also zugleich Qualitätskontrolle und Frühwarnsystem.

Der Aufwand dafür ist überschaubar, wenn die Spur gut lesbar ist. Eine Prüferin braucht pro Vorgang wenige Minuten, sofern sie nicht erst Daten aus drei Systemen zusammensuchen muss. Das ist ein weiterer Grund, in die Struktur des Protokolls zu investieren, bevor der erste Agent produktiv geht.

Die Anweisung, die einem Agenten sagt, wie er handeln soll, ist der wirksamste Hebel und zugleich die häufigste Fehlerquelle. Ein geänderter Satz kann das Verhalten in Fällen verschieben, an die niemand beim Ändern gedacht hat. Trotzdem werden Anweisungen oft in einem Textfeld bearbeitet, ohne Historie und ohne Freigabe.

Wir behandeln sie deshalb wie Code. Jede Änderung bekommt eine Versionsnummer, eine kurze Begründung und einen Verantwortlichen. Das Protokoll hält fest, mit welcher Version ein Schritt entstand. So lässt sich bei einem Vorfall beantworten, ob er vor oder nach einer Änderung auftrat, und welche Vorgänge von einer fehlerhaften Fassung betroffen sind.

Vor der Aktivierung prüft eine feste Testmenge die neue Fassung: Standardfälle, bekannte Sonderfälle und frühere Fehlerfälle, die nie wieder auftreten sollen. Das ersetzt keine Beobachtung im Betrieb, fängt aber grobe Rückschritte ab. Danach läuft die neue Version zunächst für einen kleinen Teil der Vorgänge oder nur für unkritische Anfragearten.

Entscheidend ist der Rückweg. Eine frühere Version muss mit einem Handgriff wieder aktivierbar sein, ohne dass jemand die alte Fassung aus einer E-Mail rekonstruieren muss. Vorgänge, die in der Zwischenzeit mit der fehlerhaften Version bearbeitet wurden, lassen sich über das Protokoll gezielt finden und nachprüfen. Nicht jede Aktion ist rückholbar, etwa eine bereits versandte Nachricht. Deshalb gehört zum Rückrollen auch die Frage, was der Agent in der kritischen Zeit überhaupt eigenständig auslösen durfte.

Technisch genügt für den Anfang eine überschaubare Struktur. Jeder Schritt wird als strukturierter Datensatz geschrieben, nicht als freier Text, etwa im JSON-Format in einer Datenbank oder einem Log-System. Strukturiert heißt: Felder wie Vorgangskennung, Schritt, Werkzeug, Parameter, Antwortstatus, Dauer und Anweisungsversion sind einzeln durchsuchbar. Freitext bleibt für Begründungen und Zitate der Quelle.

Die Aufzeichnung gehört in die Schicht, die Werkzeuge aufruft, nicht in die Anweisung. Wenn der Agent selbst „protokollieren“ soll, hängt die Vollständigkeit von seiner Folgsamkeit ab. Wenn jeder Werkzeugaufruf durch eine Zwischenschicht läuft, die Eingabe und Ergebnis automatisch festhält, ist die Spur auch dann lückenlos, wenn sich der Agent anders verhält als gedacht.

Auf dieser Schicht lassen sich auch die Schutzmechanismen anbringen: eine Obergrenze für Aufrufe pro Vorgang, eine Zeitgrenze pro Schritt, eine Prüfung des Antwortformats gegen das erwartete Schema. Weicht das Schema ab, etwa weil ein Feld fehlt oder anders benannt ist, wird nicht geraten, sondern der Vorgang angehalten und gemeldet. Das fängt die stillen Schnittstellenänderungen ab, die ein Agent allein nicht bemerkt.

Für Alarme reichen zu Beginn einfache Regeln: gleicher Aufruf mehr als dreimal in Folge, Schritt länger als die festgelegte Zeit, Kosten über Grenzwert, Antwortschema verletzt. Meldungen gehen an einen Kanal, den jemand tatsächlich liest. Aufwendige Anomalieerkennung lohnt sich erst, wenn genügend Betriebsdaten vorliegen, um zu wissen, was normal ist.

Ein Sonderfall ist die schleichende Veränderung. Nichts bricht, aber die Qualität driftet: Neue Anfragearten tauchen auf, ein Produktname ändert sich, eine interne Regel wird angepasst, ohne dass die Anweisung nachzieht. Solche Abweichungen zeigen weder Alarme noch Fehlerquoten. Auffallen tun sie in Stichproben, besonders wenn Prüferinnen auch nach Mustern fragen und nicht nur einzelne Vorgänge bewerten.

Ein zweiter Fall sind Fehler mit Verzögerung. Der Agent legt heute einen Eintrag falsch an, und das Problem zeigt sich erst Wochen später, wenn jemand darauf zugreift. Hier zahlt sich die Spur aus, weil sie zeigt, welche Vorgänge dieselbe Ursache hatten. Wer nur das Zielsystem betrachtet, sieht ein einzelnes falsches Datum. Mit dem Protokoll lassen sich alle gleichartigen Fälle finden und gemeinsam korrigieren.

Drittens die Wechselwirkung zwischen mehreren Agenten oder mit anderen Automatisierungen. Wenn ein Agent eine Mail schreibt, auf die ein zweites System automatisch reagiert, können Kettenreaktionen entstehen, die keine der beiden Seiten allein verursacht hat. Gegenmittel sind Obergrenzen für automatisch ausgelöste Folgeaktionen und eine Markierung, welche Nachrichten maschinell erzeugt wurden.

Und schließlich der Ausfall der Überwachung selbst. Läuft das Protokoll nicht mehr, merkt es niemand, solange der Agent weiterarbeitet. Wir würden deshalb einen Gegenalarm einrichten: Kommen innerhalb eines erwarteten Zeitraums keine Protokolleinträge an, obwohl Vorgänge laufen, wird gemeldet. Ein überwachter Agent mit einer unbemerkt ausgefallenen Überwachung ist riskanter als ein bewusst eng geführter.

Monitoring macht einen Agenten nicht klüger, es macht ihn kontrollierbar. Der Nutzen liegt darin, dass Fehler früher auffallen, Ursachen schneller gefunden werden und Änderungen weniger riskant sind. Wie stark sich das im Alltag bemerkbar macht, hängt vom Einsatz ab: von der Zahl der Vorgänge, von den angebundenen Systemen und davon, wie folgenreich ein Fehler ist.

Messen lässt sich das an Größen, die nah am Betrieb liegen. Dazu gehören die Zeit zwischen Auftreten und Entdeckung eines Fehlers, der Anteil der Vorgänge, die an Menschen übergeben werden, die Verteilung der Stichprobenurteile über die Wochen und die Kosten pro Vorgang im Verlauf. Erfassen Sie diese Werte von Anfang an, auch wenn sie anfangs unspektakulär aussehen. Erst ein Verlauf über mehrere Wochen erlaubt ein Urteil.

Was sich nicht versprechen lässt: Fehlerfreiheit. Ein Agent bleibt ein System, das mit Wahrscheinlichkeiten arbeitet, und gute Überwachung verringert Schäden, schließt sie aber nicht aus. Ebenso wenig lässt sich vorab sagen, wie viele Alarme zu Beginn auftreten. In der Einführungsphase sind es meist mehr als später, weil Schwellen noch nicht auf den echten Betrieb abgestimmt sind.

Ein ehrlicher Nutzen ist außerdem Ruhe. Wenn Sie wissen, dass jede Handlung nachvollziehbar ist, können Sie dem Agenten schrittweise mehr Aufgaben übertragen. Ohne diese Grundlage bleibt der Einsatz auf Bereiche beschränkt, in denen ein Fehler nichts kostet, und das ist selten der Bereich, in dem ein Agent am meisten entlastet.

Aus dieser Analyse lassen sich wenige Regeln ableiten. Erstens: Protokollieren Sie, bevor der Agent produktiv geht, nicht danach. Eine nachträglich ergänzte Spur zeigt nur die Zukunft, nicht den Vorfall, der sie ausgelöst hat. Zweitens: Halten Sie die Spur klein und strukturiert, mit den vier Fragen Eingabe, Entscheidung, Aktion und Quelle. Drittens: Nehmen Sie Anweisungen wie Software ernst, mit Versionen, Tests und Rückweg.

Viertens ist die Verantwortung zu klären. Wer liest die Alarme, wer zieht die Stichproben, wer darf eine Version zurückrollen? Ohne benannte Personen bleibt das beste Monitoring ein Ordner voller Daten. Fünftens hilft ein enger Start: ein Prozess, eine Anfrageart, wenige Werkzeuge. Wie ein solcher Pilotprozess ausgewählt wird, haben wir in einer eigenen Studie beschrieben.

Sechstens gilt, Alarme sparsam und mit Bedacht einzuführen. Fünf Regeln, die jemand ernst nimmt, sind besser als zwanzig, die nach einer Woche stummgeschaltet werden. Neue Regeln kommen erst dazu, wenn ein echter Vorfall zeigt, dass eine Lücke besteht. So wächst das Regelwerk entlang der tatsächlichen Erfahrung und nicht entlang einer Checkliste aus dem Lehrbuch.

Ihr nächster Schritt ist klein. Nehmen Sie einen Vorgang, den ein Agent oder eine Automatisierung heute bearbeitet, und fragen Sie sich: Könnte ich in fünf Minuten erklären, warum genau dieser Schritt so entschieden wurde? Wenn nicht, fehlt die Spur. Wir schauen uns Ihren Ablauf gern gemeinsam an und sagen ehrlich, welche Überwachung bei Ihrem Einsatz angemessen ist und welche übertrieben wäre.