Ein KI-Agent, der im Testlauf überzeugt, kann im Alltag trotzdem stillschweigend schlechter werden: Eingangsdaten ändern sich, eine angebundene Schnittstelle antwortet langsamer, ein Textbaustein wird veraltet. Wer einen Agenten produktiv einsetzt, braucht deshalb dieselbe Selbstverständlichkeit wie bei jeder anderen betrieblichen Software – nämlich zu wissen, was er gerade tut, wie gut er es tut und wann jemand eingreifen muss. Genau das leistet Monitoring, und die etwas tiefere Variante davon nennt man Observability. Dieser Ratgeber erklärt, worauf es dabei im Mittelstand praktisch ankommt.
Monitoring und Observability – wo liegt der Unterschied?
Die beiden Begriffe werden oft synonym verwendet, meinen aber unterschiedliche Tiefen. Monitoring beantwortet die Frage: Läuft der Agent, und stimmen die Kennzahlen? Es beobachtet vorab definierte Messwerte und schlägt Alarm, wenn ein Schwellenwert überschritten wird – etwa wenn die Fehlerquote steigt oder eine Antwortzeit ausreißt.
Observability geht weiter. Sie beantwortet die Frage: Warum hat sich der Agent so verhalten? Dafür genügt es nicht, nur Zahlen zu zählen. Man muss den einzelnen Vorgang nachvollziehen können: Welche Eingabe kam herein, welche Werkzeuge hat der Agent aufgerufen, welche Zwischenergebnisse entstanden, welche Entscheidung wurde am Ende getroffen. Ein Agent trifft Entscheidungen auf Basis von Wahrscheinlichkeiten – deshalb reicht es nicht, nur das Ergebnis zu sehen. Man muss den Weg dorthin rekonstruieren können. Wie ein Agent intern arbeitet und Werkzeuge nutzt, ist im Beitrag Function Calling ausführlich beschrieben.
Diese vier Signalarten sollten Sie erfassen
Ein belastbares Monitoring stützt sich nicht auf ein Bauchgefühl, sondern auf konkrete Signale. In der Praxis haben sich vier Gruppen bewährt:
- Betriebssignale: Läuft der Agent überhaupt? Wie viele Vorgänge bearbeitet er pro Stunde, wie lange dauert ein Durchlauf, wie oft brechen Aufrufe ab? Das ist die klassische Technik-Ebene und deckt Ausfälle schnell auf.
- Qualitätssignale: Wie gut sind die Ergebnisse? Dazu zählen die Quote der Fälle, die ohne menschliche Korrektur durchlaufen, die Häufigkeit von Rückfragen und die Fehler, die in der Freigabe auffallen.
- Kostensignale: Jeder Vorgang verursacht Rechenkosten, meist abgerechnet nach verarbeiteten Texteinheiten (Token). Ein Agent, der plötzlich das Dreifache verbraucht, ist ein Warnzeichen – technisch wie finanziell.
- Sicherheits- und Compliance-Signale: Wurde eine Aktion ohne die vorgesehene Freigabe ausgeführt? Hat der Agent auf Daten zugegriffen, die außerhalb seines Auftrags liegen? Solche Ereignisse gehören lückenlos protokolliert.
Das Protokoll ist das Herzstück
Ohne ein nachvollziehbares Protokoll bleibt jede Auswertung Stückwerk. Für jeden Vorgang sollte festgehalten werden: der Auslöser, die relevanten Eingabedaten, jeder Werkzeug-Aufruf mit Ergebnis, die getroffene Entscheidung und – falls vorhanden – wer sie freigegeben hat. Dieses Protokoll erfüllt gleich drei Zwecke: Es macht Fehler analysierbar, es liefert im Zweifel den Nachweis gegenüber Kunden oder Prüfern, und es ist die Grundlage, um den Agenten überhaupt verbessern zu können.
Wichtig ist der datenschutzkonforme Umgang damit. Protokolle enthalten häufig personenbezogene Daten, für die Löschfristen, Zugriffsbeschränkungen und ein Verarbeitungszweck gelten. Wie das sauber gelingt, behandelt der Beitrag Datensicherheit bei KI-Agenten.
Von der Beobachtung zum Eingriff: Schwellen und Alarme
Daten zu sammeln nützt nur, wenn daraus rechtzeitig eine Handlung folgt. Legen Sie deshalb vorab fest, welche Werte normal sind und ab wann jemand informiert wird. Beispiele: Fällt die Quote der automatisch abgeschlossenen Vorgänge unter eine definierte Grenze, geht eine Meldung an die verantwortliche Person. Steigt die Token-Menge je Vorgang deutlich, wird eine Prüfung ausgelöst. Häuft sich ein bestimmter Fehlertyp, pausiert der Agent für diesen Fall automatisch und legt ihn dem Menschen vor.
Dieses Sicherheitsnetz greift ineinander mit dem Prinzip, kritische Entscheidungen ohnehin durch einen Menschen freigeben zu lassen. Die Grundlagen dazu erklärt Mensch-in-the-Loop. Monitoring und Freigabeschleifen sind keine Konkurrenz, sondern zwei Schichten desselben Sicherheitsgedankens.
Warum Agenten „driften“ – und wie Sie es bemerken
Ein häufig unterschätztes Phänomen ist die schleichende Verschlechterung, oft „Drift“ genannt. Der Agent selbst ändert sich nicht, aber seine Umwelt schon: Kunden formulieren Anliegen anders, neue Produktnamen tauchen auf, eine Datenquelle liefert plötzlich ein verändertes Format. Ohne Monitoring bemerkt man das erst, wenn sich Beschwerden häufen. Mit einem festen Satz wiederkehrender Testfälle – die man regelmäßig gegen den laufenden Agenten prüft – fällt eine Verschlechterung dagegen früh auf. Dieser Ansatz überschneidet sich mit der Qualitätssicherung vor dem Start, die der Beitrag zum Umgang mit Halluzinationen und Guardrails vertieft.
Realistischer Aufwand für den Mittelstand
Man braucht für den Anfang kein teures Spezialwerkzeug. Für einen einzelnen Agenten mit überschaubarem Volumen genügt oft ein strukturiertes Protokoll in einer Datenbank plus eine wöchentliche Auswertung der vier Signalgruppen und wenige automatische Alarme bei klaren Grenzwerten. Der Aufwand liegt dann eher im Einrichten der Kennzahlen als in der Technik. Erst wenn mehrere Agenten mit hohem Volumen laufen, lohnt sich eine spezialisierte Observability-Plattform. Die Faustregel: Der Überwachungsaufwand sollte im Verhältnis zum Schaden stehen, den ein unbemerkter Fehler anrichten würde – bei einer Rechnungsfreigabe ist er höher als bei einer internen Textzusammenfassung.
Häufige Fragen
Was ist der Unterschied zwischen Monitoring und Observability?
Monitoring beobachtet vorab festgelegte Kennzahlen und schlägt Alarm, wenn ein Schwellenwert überschritten wird – es beantwortet die Frage, ob alles läuft. Observability geht tiefer und macht den einzelnen Vorgang nachvollziehbar, sodass man rekonstruieren kann, warum sich der Agent so verhalten hat. In der Praxis braucht man beides: Kennzahlen für den schnellen Überblick und detaillierte Protokolle für die Ursachenanalyse.
Welche Kennzahlen sollte ich bei einem KI-Agenten überwachen?
Bewährt haben sich vier Gruppen: Betriebssignale wie Durchsatz und Antwortzeit, Qualitätssignale wie die Quote der ohne Korrektur durchlaufenden Fälle, Kostensignale wie der Verbrauch je Vorgang und Sicherheitssignale wie Aktionen ohne die vorgesehene Freigabe. Wichtig ist nicht die Menge der Kennzahlen, sondern dass zu jeder ein normaler Bereich und eine klare Grenze definiert sind, ab der jemand informiert wird.
Was bedeutet „Drift“ bei einem KI-Agenten?
Drift beschreibt eine schleichende Verschlechterung der Ergebnisse, ohne dass sich der Agent selbst geändert hätte. Ursache ist meist eine veränderte Umwelt: andere Formulierungen der Nutzer, neue Begriffe oder ein geändertes Datenformat einer Quelle. Erkennen lässt sich Drift am zuverlässigsten mit einem festen Satz wiederkehrender Testfälle, die man regelmäßig gegen den laufenden Agenten prüft.
Braucht ein kleines Unternehmen dafür teure Spezialsoftware?
Für den Einstieg meist nicht. Ein sauber strukturiertes Protokoll, eine regelmäßige Auswertung der wichtigsten Signale und wenige automatische Alarme bei klaren Grenzwerten reichen bei einem einzelnen Agenten aus. Eine spezialisierte Observability-Plattform lohnt sich erst, wenn mehrere Agenten mit hohem Volumen laufen. Als Maßstab gilt: Der Überwachungsaufwand sollte zum möglichen Schaden eines unbemerkten Fehlers passen.