KI-Agenten im Betrieb überwachen: stille Fehler erkennen, rechtzeitig eingreifen

Das gefährlichste Missverständnis: „Läuft ja durch"

Ein KI-Agent ist seit drei Wochen produktiv. Er sortiert Rechnungen, beantwortet Standardanfragen, pflegt Datensätze. Niemand hat sich beschwert, das Dashboard ist grün, der Prozess läuft. Genau hier entsteht das gefährlichste Missverständnis im Betrieb autonomer Agenten: „Läuft ja durch." Denn ein Agent, der durchläuft, ist nicht dasselbe wie ein Agent, der richtig arbeitet.

Klassische Software scheitert laut. Ein Programm stürzt ab, wirft eine Exception, gibt einen Fehlercode zurück — und ein Monitoring-System schlägt Alarm. Ein KI-Agent scheitert anders: Er scheitert leise. Er stürzt nicht ab, er handelt einfach falsch. Er kategorisiert eine Rechnung in das falsche Konto, fasst ein Dokument plausibel, aber inhaltlich verkehrt zusammen, beantwortet eine Kundenanfrage selbstbewusst mit einer veralteten Information. Aus Sicht des Systems ist alles in Ordnung: keine Exception, kein roter Status, Antwortzeit normal. Aus Sicht des Geschäfts ist gerade ein Fehler passiert, den niemand gesehen hat.

Deshalb fängt klassisches Uptime-Monitoring beim Agentenbetrieb fast nichts. „Ist der Dienst erreichbar?", „Antwortet die API in unter zwei Sekunden?", „Liegt die Fehlerrate unter einem Prozent?" — all diese Fragen kann ein Agent mit „ja" beantworten und trotzdem den ganzen Tag Unsinn produzieren. Uptime misst, ob etwas passiert. Im Agentenbetrieb müssen Sie messen, was passiert und ob es das Richtige war. Das ist ein anderer Anspruch, und er erfordert andere Instrumente.

Eine Abgrenzung vorweg, weil beides leicht durcheinandergerät: Dieser Artikel behandelt die Betriebssicht — niemand greift den Agenten an, er handelt aus sich heraus still falsch, und Sie müssen das bemerken, bevor Schaden entsteht. Die Angriffssicht — jemand manipuliert den Agenten gezielt über Prompt Injection, um Daten abzuziehen — ist ein eigenes Thema und in unserem Artikel KI-Agenten absichern behandelt. Beides ist nötig, keines ersetzt das andere. Hier geht es um den unspektakuläreren, aber alltäglicheren Fall: Der Agent meint es gut und liegt trotzdem daneben.

Vier Betriebs-Signale, die man instrumentieren muss

Stille Fehler sind nicht unsichtbar — man muss nur an den richtigen Stellen messen. Vier Signale verraten in der Regel früh, dass ein Agent vom Kurs abkommt. Keines davon ist ein Inhaltsurteil („war diese Antwort gut?"), alle vier sind ohne KI auswertbar. Genau das macht sie als Frühwarnsystem belastbar: Sie funktionieren auch dann, wenn niemand jede einzelne Ausgabe liest.

1. Aufgaben-Erfolg vs. Abbruch und Retry

Wie viele Aufgaben schließt der Agent sauber ab, wie viele bricht er ab, und wie oft muss er einen Schritt wiederholen? Eine steigende Retry-Quote ist eines der ehrlichsten Frühsignale überhaupt. Sie bedeutet: Der Agent kommt mit etwas nicht zurecht und versucht es erneut — mal mit Erfolg, mal nicht. Alarm, wenn die Abbruch- oder Retry-Quote über mehrere Tage deutlich vom eingespielten Normalwert abweicht. Es gibt keinen universellen Schwellenwert; entscheidend ist die Abweichung von der eigenen Baseline, die Sie in den ersten Betriebswochen aufnehmen. Ein Agent, der gestern 5 Prozent seiner Aufgaben wiederholen musste und heute 20 Prozent, sagt Ihnen etwas — lange bevor sich ein Kunde meldet.

2. Eskalations-Rate

Wie oft fragt der Agent zurück, statt eigenständig zu handeln? Dieses Signal ist tückisch, weil es in beide Richtungen alarmiert. Eine steigende Eskalations-Rate kann heißen, dass die eingehenden Fälle schwieriger geworden sind oder der Agent unsicherer wird — beides will man wissen. Eine plötzlich fallende Eskalations-Rate ist oft das gefährlichere Zeichen: Der Agent fragt nicht mehr nach, sondern entscheidet jetzt selbst Fälle, bei denen er früher angehalten hätte. Das sieht im Dashboard nach Reife und Autonomie aus und ist in Wahrheit häufig der Moment, in dem stille Fehler beginnen. Wer nur „weniger Rückfragen = besser" denkt, übersieht genau das.

3. Kosten und Token pro Aufgabe

Was kostet eine einzelne Aufgabe an Modell-Aufrufen und Tokens? Dieses Signal ist mehr als eine Budgetfrage (dazu unten mehr) — es ist ein erstaunlich guter Verhaltensindikator. Eine Aufgabe, die normalerweise drei Modell-Aufrufe braucht und plötzlich fünfzehn, deutet meist darauf hin, dass der Agent im Kreis läuft: Er probiert, scheitert, probiert anders, kommt nicht zum Ziel. Alarm, wenn die Kosten pro Aufgabe deutlich über den eingespielten Schnitt steigen — oft sehen Sie das Fehlverhalten an den Tokens, bevor Sie es am Ergebnis sehen.

4. Latenz und Durchsatz

Wie lange braucht der Agent pro Aufgabe, und wie viele schafft er in einem Zeitfenster? Latenz ist das klassischste der vier Signale und wird trotzdem unterschätzt. Steigende Bearbeitungszeit korreliert häufig mit den ersten drei Signalen — der Agent, der im Kreis läuft, ist auch langsamer. Ein Einbruch im Durchsatz kann auf eine Warteschlange hindeuten, die sich aufstaut, weil zu viele Fälle eskaliert oder wiederholt werden. Alarm bei anhaltender Abweichung von der Baseline, nicht bei einzelnen Ausreißern.

Der gemeinsame Nenner dieser vier Signale: Sie messen nicht den Inhalt, sondern das Verhalten. Ein Agent, der inhaltlich abdriftet, verrät sich fast immer zuerst im Verhalten — er wird unsicherer, teurer, langsamer, wiederholt mehr. Diese vier Kurven nebeneinander auf einem Dashboard, jeweils mit einer eingespielten Baseline, sind das Minimum, das ein produktiver Agent verdient.

Der Audit-Trail als Betriebswerkzeug, nicht nur als Forensik

Wenn ein Signal anschlägt, kommt die nächste Frage: Was genau hat der Agent getan? Hier zeigt sich der Wert eines vollständigen Audit-Trails. Jede Aktion des Agenten wird protokolliert — welches Werkzeug mit welchen Parametern aufgerufen wurde, welche Daten gelesen wurden, welche Entscheidung mit welcher Begründung getroffen wurde, was am Ende herauskam. Nicht als nachträglicher Logeintrag, sondern als nachvollziehbare, im Idealfall reproduzierbare Kette.

Viele denken beim Audit-Trail zuerst an Forensik: Wenn etwas schiefgegangen ist, schaut man hinterher nach. Das ist richtig, aber zu kurz gedacht. Im Betrieb ist der Audit-Trail vor allem ein diagnostisches Werkzeug. Ein stiller Fehler hinterlässt keine Exception und keinen Stacktrace — die einzige Spur, an der Sie ihn zurückverfolgen können, ist die protokollierte Handlungskette. Ohne sie steht man vor einem falschen Ergebnis und kann nur raten, an welchem der zehn Schritte der Agent abgebogen ist. Mit ihr sieht man genau, welches Dokument er gelesen, welche Annahme er getroffen und welches Werkzeug er falsch parametrisiert hat.

Drei Eigenschaften machen einen Audit-Trail betriebstauglich: Er ist vollständig (jeder folgenreiche Schritt, nicht nur das Endergebnis), er ist nachvollziehbar (mit Begründung, nicht nur mit Daten), und er ist durchsuchbar (man kann gezielt nach allen Aufgaben eines Typs oder eines Zeitraums fragen). Erst diese Kombination macht aus Logzeilen ein Instrument, mit dem man im Steady State arbeitet — nicht erst im Schadensfall.

Der Audit-Trail hat auch eine Sicherheitsdimension — er ist die Voraussetzung, einen Missbrauch überhaupt zu erkennen. Diese Perspektive behandeln wir getrennt im Artikel zur Absicherung von KI-Agenten; hier interessiert uns dasselbe Protokoll als Werkzeug, um unabsichtliche stille Fehler aufzuspüren.

Eskalationspfade: Wann der Agent selbst stoppen und fragen muss

Das beste Monitoring nützt wenig, wenn der Agent zwischen Messung und Eingriff bereits Irreversibles getan hat. Deshalb gehört zum Betrieb eine zweite Disziplin: klare Eskalationspfade, an denen der Agent von sich aus anhält und einen Menschen fragt. Die Leitfrage dabei ist nicht „kann der Agent das?", sondern „ist es umkehrbar?".

Reversible Aktionen — einen Datensatz mit Entwurfsstatus anlegen, eine interne Notiz schreiben, einen Vorschlag vorbereiten — kann der Agent in der Regel eigenständig ausführen. Geht etwas schief, korrigiert man es. Irreversible oder nach außen gerichtete Aktionen sind eine andere Kategorie: Geld überweisen, eine E-Mail an einen Kunden senden, Daten löschen, einen Vertrag verschicken. Was draußen ist, ist draußen; was gelöscht ist, ist weg. Genau hier gehört ein Halt eingebaut.

In der Praxis bewähren sich konkrete Schwellenwerte statt vager Regeln:

• Geldbeträge: Bis zu einer definierten Grenze handelt der Agent selbst, darüber holt er eine Freigabe ein. Die Grenze richtet sich nach dem, was im schlimmsten Fall verschmerzbar ist.
• Externe Kommunikation: Antworten an Dritte — Kunden, Lieferanten, Behörden — durchlaufen ein Gate, sobald sie über reine Standardbausteine hinausgehen.
• Löschungen und Massenänderungen: Alles, was viele Datensätze auf einmal verändert oder entfernt, hält grundsätzlich an. Eine versehentliche Massenoperation ist der teuerste stille Fehler.

Über allem steht ein Default-Verhalten, das sich bewährt hat: im Zweifel anhalten. Wenn der Agent unsicher ist — niedrige Konfidenz, widersprüchliche Daten, ein Fall außerhalb des Gewohnten —, lautet die richtige Reaktion nicht „bestes Raten", sondern „eskalieren". Ein Agent, der lieber einmal zu oft fragt, ist im Betrieb günstiger als einer, der lieber einmal zu oft handelt. Das kostet ein paar Rückfragen mehr — und erspart die Fehler, die man hinterher mühsam zurückdrehen muss.

Drift erkennen, bevor der Kunde ihn meldet

Drift ist die heimtückischste Form des stillen Fehlers, weil sie sich über Zeit einschleicht: gleiche Spezifikation, schlechter werdende Ergebnisse. Am ersten Tag arbeitet der Agent einwandfrei. Drei Monate später erledigt er dieselbe Aufgabe nach denselben Vorgaben spürbar schlechter — ohne dass jemand etwas geändert hätte. Genau weil sich nichts geändert zu haben scheint, fällt Drift im Tagesgeschäft so lange nicht auf, bis ein Kunde sich beschwert.

Die Ursachen liegen meist außerhalb des eigenen Codes:

• Modell-Updates: Der zugrundeliegende Modellanbieter aktualisiert sein Modell. Verhalten, das gestern verlässlich war, verschiebt sich subtil — oft zum Besseren, manchmal genau bei den Fällen, die für Sie wichtig sind.
• Kontext-Verschiebung: Die Realität, in der der Agent arbeitet, verändert sich. Neue Produktnamen, neue Rechtslage, neue Kundentypen, neue Formulierungen — die Aufgabe heißt gleich, aber ihr Inhalt ist ein anderer geworden.
• Veraltete Tools und Daten: Eine Wissensquelle, auf die der Agent zugreift, ist nicht mehr aktuell. Ein Werkzeug verhält sich nach einem Update anders. Der Agent arbeitet weiter brav mit dem, was er hat — nur stimmt es nicht mehr.

Gegen Drift hilft kein einmaliger Test, sondern nur eine laufende Messung: Stichproben gegen einen Goldstandard. Man legt einen festen Satz repräsentativer Aufgaben mit bekannten, von Menschen geprüften Soll-Ergebnissen an — den Goldstandard. In regelmäßigen Abständen lässt man den Agenten diese Aufgaben erneut bearbeiten und vergleicht. Sinkt die Übereinstimmung, driftet der Agent — und Sie wissen es, bevor es der Kunde tut. Der Aufwand ist überschaubar, der Nutzen groß: Eine Handvoll Goldstandard-Fälle, regelmäßig nachgemessen, ist nach aktuellem Stand der einzige verlässliche Weg, schleichende Verschlechterung sichtbar zu machen.

Kostenkontrolle: das Budget als Frühwarnsystem

Kosten sind im Agentenbetrieb zwei Dinge gleichzeitig: eine betriebswirtschaftliche Größe und ein Verhaltenssignal. Beide rechtfertigen harte Grenzen. Ein Budget-Deckel pro Aufgabe und pro Tag gehört zur Grundausstattung: Erreicht eine einzelne Aufgabe ihr Limit an Modell-Aufrufen, wird sie gestoppt und eskaliert, statt weiterzulaufen. Erreicht der Agent sein Tagesbudget, hält er an. Das schützt nicht nur die Rechnung, sondern auch vor dem Schaden, den ein außer Kontrolle geratener Agent in der Zwischenzeit anrichten würde.

Der zweite, oft übersehene Punkt: Explodierende Token sind ein Frühwarnsignal für Fehlverhalten. Wenn ein Agent für eine Routineaufgabe plötzlich das Vielfache seiner üblichen Tokens verbraucht, dreht er fast immer im Kreis — er kommt nicht zum Ziel, versucht es immer wieder, sammelt Kontext an, verheddert sich. Die Kostenkurve schlägt aus, bevor das schlechte Ergebnis sichtbar wird. Ein Kostenlimit pro Aufgabe ist damit zugleich eine Notbremse gegen genau diese Schleifen.

Wo mehrere Varianten oder Agenten parallel laufen, lohnt sich ein nüchternes Prinzip aus der Optimierung: Verlierer früh aussortieren. Was bei vergleichbarer Aufgabe konstant teurer ist und schlechtere Ergebnisse liefert, wird abgeschaltet, statt aus Gewohnheit weiterbezahlt zu werden. Kostenkontrolle ist im Agentenbetrieb keine reine Sparübung — sie ist eine der billigsten Methoden, Fehlverhalten überhaupt zu bemerken.

Mensch im Loop — richtig dosiert

Die naheliegende Antwort auf all das lautet: „Dann schaut eben immer ein Mensch drüber." So einfach ist es nicht. Menschliche Aufsicht ist wertvoll, aber nur, wenn sie dosiert ist. Der häufigste Fehler heißt „Oversight Theatre": Es gibt formal ein Freigabe-Gate, aber weil ständig Bestätigungen aufpoppen, winkt der Mensch reflexhaft alles durch. Das sieht nach Kontrolle aus und ist keine. Gewöhnung schlägt Aufmerksamkeit — wer den ganzen Tag „OK" klickt, liest beim hundertsten Mal nicht mehr, was er freigibt.

Die Konsequenz ist nicht „mehr Review", sondern gezielteres Review. Menschliche Freigabe gehört auf die wenigen, wirklich folgenreichen Punkte — die irreversiblen und nach außen gerichteten Aktionen aus dem Eskalations-Abschnitt — und auf die Fälle, die das Monitoring als auffällig markiert. Lieber drei Freigaben am Tag, die jemand ernst nimmt, als hundert, die niemand mehr liest. Review schafft dort echten Wert, wo eine Entscheidung schwer rückgängig zu machen ist oder wo die Signale Unsicherheit anzeigen — nicht als gleichmäßiger Nebel über allem.

Dieselbe Logik gilt für die Aufsicht über manipulierte Eingaben; weil das eine eigene Disziplin ist, behandeln wir sie nicht hier, sondern im Artikel zur Absicherung von KI-Agenten. Für den laufenden Betrieb gilt: Aufsicht ist ein knappes Gut. Wer sie verschwendet, hat sie nicht, wenn es darauf ankommt.

Checkliste: 8 Fragen — Ist dein KI-Agent betriebsbereit?

Bevor ein Agent ohne ständige Beobachtung produktiv laufen darf, sollten Sie diese acht Fragen klar beantworten können. Bleibt eine offen, fehlt ein Stück Betriebsreife.

• Verhaltens-Signale: Messen Sie Aufgaben-Erfolg, Eskalations-Rate, Kosten pro Aufgabe und Latenz laufend — jeweils gegen eine eingespielte Baseline?
• Stille Fehler: Wie würden Sie merken, dass der Agent richtig durchläuft, aber inhaltlich falsch handelt — ohne dass sich ein Kunde meldet?
• Audit-Trail: Können Sie für jede einzelne Aufgabe nachvollziehen, welche Daten gelesen, welche Werkzeuge aufgerufen und welche Entscheidung mit welcher Begründung getroffen wurde?
• Eskalationspfade: Ist definiert, welche Aktionen der Agent selbst ausführen darf und bei welchen er anhalten und fragen muss — getrennt nach reversibel und irreversibel?
• Schwellenwerte: Gibt es konkrete Grenzen für Geldbeträge, externe Kommunikation und Löschungen — und gilt im Zweifel „anhalten"?
• Drift-Messung: Haben Sie einen Goldstandard, gegen den Sie regelmäßig per Stichprobe prüfen, ob die Ergebnisqualität über die Zeit nachlässt?
• Budget-Deckel: Gibt es ein Kostenlimit pro Aufgabe und pro Tag, das den Agenten stoppt — auch als Notbremse gegen Schleifen?
• Dosierte Aufsicht: Konzentriert sich menschliches Review auf wenige folgenreiche Entscheidungen, statt im „Oversight Theatre" alles reflexhaft durchzuwinken?

Fazit: Betrieb ist kein Nebenprodukt, sondern die eigentliche Arbeit

Einen KI-Agenten zum Laufen zu bringen, ist der leichtere Teil. Ihn über Monate richtig laufen zu halten, ist der eigentliche Anspruch — und er ist eine Daueraufgabe, kein einmaliges Projekt. Der ehrliche Kern: Agenten scheitern leise, nicht laut. Deshalb braucht ihr Betrieb kontinuierliche Beobachtung, nicht weil etwas schlecht gebaut wäre, sondern weil stille Fehler in der Natur der Sache liegen. Niemand kann „100 Prozent zuverlässig" versprechen — und Sie sollten niemandem trauen, der es tut.

Wer die vier Verhaltens-Signale instrumentiert, jede Aktion protokolliert, klare Eskalationspfade zieht, Drift gegen einen Goldstandard misst, Kosten als Frühwarnsystem nutzt und Aufsicht dort einsetzt, wo sie zählt, hat das Risiko nicht beseitigt — aber beherrschbar gemacht. Das ist der Unterschied zwischen einem Agenten, der „durchläuft", und einem, dem man vertrauen kann.

Solytics betreibt selbst autonome Agenten produktiv — nach dem Prinzip operator-reviewed autonomous engineering: Agenten arbeiten eigenständig, ihr Verhalten wird laufend überwacht, folgenreiche Schritte laufen über menschliche Review-Gates, jede Aktion ist protokolliert. Diese Betriebserfahrung fließt in jede Lösung ein, die wir bauen — von der ersten Einführung über die Frage, welche Fähigkeiten ein Agent überhaupt braucht, bis zum dauerhaften Betrieb. Wenn Sie grundsätzlich überlegen, KI-Agenten zur Prozessautomatisierung einzusetzen, gehört der Betrieb von Anfang an in die Planung — nicht als Nachgedanke. Sprechen Sie mit uns über KI-Automatisierung, die nicht nur startet, sondern verlässlich läuft: Unsere Beratungspakete im Überblick.