KI-Agenten überwachen: Wie Du blinde Flecken im Arbeitsablauf findest

Ein laufender KI-Agent braucht eine Überwachung, die seine tatsächlichen Aktionen und die Grenzen ihrer eigenen Sichtbarkeit zeigt. Ein grünes Dashboard allein beantwortet nicht, ob alle relevanten Schritte erfasst wurden. Für einen betrieblichen Ablauf musst Du deshalb zuerst festlegen, welche Ereignisse einen Nachweis brauchen und was bei fehlenden Nachweisen passiert.

Das betrifft auch kleine Automatisierungen. Ein Assistent liest eine Anfrage, sucht Informationen und bereitet eine Änderung in einem Ticketsystem vor. Wenn der Schreibzugriff erfolgreich war, die Rückmeldung aber verloren geht, ist der Zustand unklar. Ein erneuter Versuch erzeugt möglicherweise eine zweite Änderung. Ohne Rücklesen des Zielsystems bleibt offen, was tatsächlich passiert ist.

Eine Veröffentlichung von METR gibt einen konkreten Anlass, solche Lücken zu prüfen. Der folgende Leitfaden ist eine eigene Übertragung auf begrenzte Unternehmensabläufe. Er ist keine Sicherheitszertifizierung und kein Befund über Deine vorhandenen Systeme.

Was der veröffentlichte Red-Team-Test abdeckt

METR veröffentlichte am 22. Oktober 2026 eine Zusammenfassung eines gemeinsam mit Redwood Research durchgeführten Tests. Zwei Forschende untersuchten vom 21. Juli bis 11. August interne Überwachung bei OpenAI, bezogen auf den Systemstand am und vor dem 21. Juli.

Der Bericht nennt unter anderem Lücken bei Kontextverdichtung, Unterschiede zwischen den vom Agenten und vom Monitor gesehenen Daten sowie Probleme bei Werkzeugabdeckung und Kontrollgrenzen. OpenAI meldet laut Veröffentlichung die Behebung produktionsrelevanter Befunde. Der vollständige interne Bericht mit 61 Seiten ist nicht öffentlich.

Quelle: METR: Red-Teaming OpenAI’s Internal Agent Monitoring Systems. Die öffentliche Zusammenfassung erlaubt keine vollständige unabhängige Nachprüfung aller technischen Details. Sie beschreibt einen historischen internen Systemstand und belegt keine entsprechenden aktuellen Schwachstellen eines Kundenprodukts. Aus dem Test folgt auch keine allgemeine Ausfallquote für Agentenüberwachung.

Beginne mit der Aktion, die kontrolliert werden muss

Meine Empfehlung: Zeichne den tatsächlichen Ablauf mit seinen Zustandsänderungen auf. Beginne bei einer konkreten Aktion, etwa "Ticketstatus ändern". Welche Eingabe löst sie aus? Welche Quelle begründet sie? Welche Berechtigung erlaubt sie? Wer gibt sie frei? Wie wird der neue Zustand im Ticketsystem festgestellt?

Eine technische Komponentenliste reicht dafür nicht. Sie benennt vielleicht Modell, Datenbank und Connector, lässt aber die Entscheidung zwischen Lesen und Schreiben offen. Für die Überwachung ist genau dieser Übergang relevant. Ein gelesener Status ist ein Befund; eine beabsichtigte Änderung ist ein Vorschlag; der neue gespeicherte Status ist das Ergebnis.

Halte auch Nebenwege fest. Ein Agent kann bei einem Fehler ein anderes Werkzeug verwenden oder nach einer Unterbrechung fortsetzen. Diese Wege brauchen denselben Nachweis wie der normale Ablauf. Andernfalls funktioniert die Kontrolle nur im Demonstrationsfall.

Trenne technische Lebenszeichen von Arbeitsfortschritt

Ein Lebenszeichen zeigt, dass ein Prozess noch reagiert. Es beweist keinen fachlichen Fortschritt. Ein Agent kann dieselbe Quelle wiederholt lesen oder auf eine unerreichbare Schnittstelle warten. Der Prozess lebt, die Aufgabe bleibt unverändert.

Definiere deshalb Fortschritt anhand überprüfbarer Ereignisse: Quelle erfolgreich abgerufen, Pflichtangaben vollständig, Entwurf erstellt, Freigabe eingeholt oder Zielzustand zurückgelesen. Diese Ereignisse müssen eine Reihenfolge und einen Bezug zur Aufgabe haben. Ein beliebiger neuer Logeintrag ist noch kein Fortschritt.

Zeitgrenzen gehören ausserhalb der freien Selbsteinschätzung des Agenten in den Ablauf. Die verantwortliche Person legt fest, welche Wartezeit für die Aufgabe zulässig ist. Bei Überschreitung entsteht ein sichtbarer offener Zustand mit Zuständigkeit. Ein stiller Neustart ohne Kenntnis vorheriger Aktionen ist kein verlässlicher Ersatz.

Entwirf eine kleine Ereignisliste

Für einen begrenzten Pilot empfehle ich wenige, klar definierte Ereignisse. Jedes Ereignis enthält eine Laufkennung, eine Aufgabenkennung und einen Zeitstempel. Ergänze die verwendete Version und das betroffene Objekt, soweit diese Angaben für die Nachprüfung erforderlich und erlaubt sind.

Das Raster ist eine eigene Empfehlung, kein eingeführter Standard. Passe es an den konkreten Ablauf an. Ein reiner Leseassistent benötigt andere Ereignisse als eine Automatisierung mit Schreibrechten. Die Freigaben in KI-Workflows erklären die organisatorische Seite dieser Grenze.

Plane einen eigenen Zustand für fehlende Sichtbarkeit

Ein fehlendes Protokoll ist weder Erfolg noch automatisch ein fachlicher Fehler. Es bedeutet zunächst, dass der Nachweis fehlt. Dieser Zustand braucht eine eigene Behandlung. Sonst werden technische Lücken in einer Erfolgsstatistik verborgen oder unnötig als endgültig gescheiterte Aufgaben gezählt.

Für eine vorbereitende Textaufgabe kann es genügen, die Ausgabe als ungeprüft zu markieren. Vor einem folgenreichen Schreibzugriff empfehle ich, den Ablauf zu stoppen, wenn die vorgeschriebene Freigabe oder Protokollierung nicht verfügbar ist. Welche Aktionen davon betroffen sind, muss vor dem Einsatz festgelegt werden.

Dagegen spricht die geringere Verfügbarkeit: Auch ein Protokollierungsfehler stoppt dann die eigentliche Arbeit. Dieser Zielkonflikt muss bewusst entschieden werden. Für einen dringenden Prozess braucht es einen benannten manuellen Ersatzweg. Die Antwort darf nicht darin bestehen, Kontrollen bei jeder Störung unbemerkt auszuschalten.

Ein fiktiver Test: Ticketänderung mit unterbrochener Rückmeldung

Ein internes System soll ein Ticket nach bestätigter fachlicher Prüfung auf "bearbeitet" setzen. Der Test läuft mit einem ausdrücklich dafür angelegten Testticket und ohne externe Benachrichtigung. Die Bestätigung des Schreibwerkzeugs wird im Testablauf unterbrochen. Der Agent kennt den Ausgang der Aktion daher nicht.

Die erwartete Reaktion lautet: Status als unklar markieren und das Zielsystem lesen. Steht das Ticket bereits auf "bearbeitet", wird die vorhandene Änderung dokumentiert. Steht es weiterhin auf dem alten Status, folgt der definierte Wiederholungsweg. Ist das Zielsystem nicht erreichbar, bleibt der Vorgang offen.

Ein blind wiederholter Schreibaufruf fällt in diesem Test durch, wenn er doppelte Aktivitäten oder Benachrichtigungen auslöst. Die technische Umsetzung muss deshalb festlegen, wie Wiederholungen erkannt werden. Eine eindeutige Vorgangskennung und eine Prüfung des aktuellen Zustands helfen dabei; die konkrete Unterstützung hängt vom angeschlossenen System ab.

Der Abnahmenachweis besteht aus Eingangsstand, ausgelöstem Testfehler, sichtbarer Reaktion und abschliessendem Zielzustand. Die reine Aussage des Agenten, er hat den Fehler behandelt, reicht nicht. Es muss erkennbar sein, dass die erwartete Änderung genau im erlaubten Umfang vorliegt.

Prüfe die Übergänge mit absichtlichen Fehlern

Ein Monitor muss an bekannten Fehlern getestet werden. Wähle ungefährliche Testkopien und eine Umgebung ohne unbeabsichtigte Aussenwirkung. Die Testperson muss den erwarteten Befund kennen. Produktive Zugriffsgrenzen zu umgehen ist für diesen Praxistest weder nötig noch Teil der Anleitung.

Geeignete Testfälle sind ein nicht erreichbarer Lesedienst, ein fehlendes Pflichtfeld, eine zurückgezogene Freigabe oder ein unbekannter Werkzeugname im Testprotokoll. Ergänze einen abgebrochenen Lauf und eine spätere Fortsetzung. Prüfe jeweils, ob die Überwachung den Unterschied zwischen blockiert, wartend und abgeschlossen erkennt.

Wichtig ist auch ein korrekter Normalfall. Eine Kontrolle, die alles blockiert, erkennt zwar jeden Fehler, verhindert aber den Zweck des Systems. Dokumentiere daher falsch akzeptierte und falsch blockierte Fälle getrennt. Die Evaluation von KI-Agenten verbindet diese Tests mit der fachlichen Ergebnisprüfung.

Protokolliere nur die benötigten Inhalte

Mehr Protokolldaten sind nicht automatisch besser. Vollständige Dokumente und Nachrichten in jedem Log vergrössern die Menge vertraulicher Inhalte. Lege fest, welche Information zur Fehlerklärung nötig ist und wer sie lesen darf. In vielen Prüfungen reicht zunächst eine Objektkennung mit Version und kontrolliertem Verweis auf die Quelle.

Wenn der Inhalt selbst für die Nachprüfung gebraucht wird, muss seine Speicherung in den freigegebenen Rahmen passen. Testdaten und produktive Daten bleiben getrennt. Zugangsdaten gehören nicht in Ereignisprotokolle. Auch Fehlermeldungen und Debug-Ausgaben müssen auf solche Inhalte geprüft werden.

Eine Löschung oder Änderung von Quelldaten kann spätere Nachprüfungen erschweren. Das Team muss daher Aufbewahrung und Nachweisbedarf gemeinsam klären. Dieser Artikel legt keine rechtlichen Fristen fest. Er beschreibt die technische und organisatorische Frage, welche erlaubten Informationen für eine spätere Prüfung verfügbar bleiben müssen.

Die Überwachung braucht eine zuständige Person

Ein Alarm ohne Bearbeitungsweg verlagert das Problem in einen weiteren Posteingang. Benenne deshalb pro Fehlerklasse eine zuständige Rolle. Technische Nichterreichbarkeit geht an den Betrieb; widersprüchliche Fachangaben an die zuständige Fachperson. Eine fehlende Freigabe darf nicht durch den technischen Betreiber ersetzt werden, wenn ihm diese Entscheidung nicht zusteht.

Lege fest, wie die Vertretung funktioniert und welche Informationen sie erhält. Eine Meldung muss die betroffene Aufgabe, den letzten bestätigten Zustand und den nächsten erlaubten Schritt nennen. Fehlt der letzte bestätigte Zustand, muss die Meldung genau diese Lücke sichtbar machen.

Nach einer Störung folgt eine kurze Ursachenprüfung. Lag ein Fehler im Werkzeug, eine unvollständige Ereignisliste oder eine falsche Erwartung vor? Ändert ihr den Ablauf, müssen die betroffenen Tests erneut laufen. Eine neue Regel im Prompt allein beweist nicht, dass der nächste Lauf sie technisch einhält.

Prüfe nach Änderungen erneut die Abdeckung

Ein neuer Connector oder ein zusätzlicher Bearbeitungsschritt erweitert den tatsächlichen Ablauf. Damit kann sich die Abdeckung der Überwachung ändern. Jede solche Erweiterung braucht einen Abgleich mit der Ereignisliste. Die Frage lautet: Wird die neue Aktion erkannt, begrenzt und nach ihrem Ergebnis geprüft?

Dasselbe gilt für Änderungen an Zusammenfassungen oder der Speicherung von Zwischenständen. Der nächste Schritt muss weiterhin die für seine Entscheidung notwendigen Angaben erhalten. Wenn eine Verdichtung eine offene Freigabe als erteilte Freigabe erscheinen lässt, ist die fachliche Zustandsinformation verloren.

Ich empfehle, einen bekannten Fehlerfall im Prüfbestand zu behalten, sobald ein entsprechender Fehler einmal aufgetreten ist. So entsteht ein gezielter Regressionstest. Die Prüfung gespeicherter Agentenerinnerungen ergänzt den Umgang mit Informationen, die zwischen Läufen weiterleben.

Der erste Abnahmetermin braucht einen sichtbaren Ablauf

Für den Einstieg genügt ein begrenzter Prozess mit einer eindeutig benannten Aktion. Der fachliche Verantwortliche und der technische Betreiber gehen gemeinsam den Normalfall und ausgewählte Fehlerfälle durch. Haltet dabei für jede offene Lücke den nächsten Prüfschritt fest. Der Termin endet mit einer Liste bestätigter Kontrollen, offener Lücken und erlaubter Einsatzgrenzen.

Ein produktiver Start ist erst im vereinbarten Umfang freigegeben. Spätere Erweiterungen sind neue Entscheidungen. Damit bleibt die Überwachung ein überprüfbarer Bestandteil des Arbeitsablaufs, statt lediglich ein Statusfeld im Dashboard zu sein.

Quellenstand: 23. Oktober 2026. Geprüft wurde die öffentliche METR-Zusammenfassung; der nicht öffentliche interne Bericht war nicht zugänglich. Ereignisliste, Ticketfall und Abnahmeverfahren sind eigene redaktionelle Vorschläge.