Stand: 29. August 2026
Auf einem Arbeitsrechner blitzte gelegentlich ein Konsolenfenster auf. Eine Zehntelsekunde, dann war es wieder weg. Ein kosmetisches Ärgernis, mehr nicht, und die naheliegende Reaktion wäre gewesen, das Fenster zu verstecken. Die Nachfrage, was da eigentlich aufblitzt, förderte etwas anderes zutage.
Hinter dem Fenster stand eine Überwachungsroutine. Sie lief seit zwanzig Tagen jede Minute. Zehntausendachtundfünfzig Ausführungen, rund dreißigtausend Prozessstarts. In jeder einzelnen dieser Ausführungen tat sie nichts.
Ein Wächter braucht ein Wachobjekt
Die Routine sollte die Unversehrtheit eines Protokolls prüfen. Dafür vergleicht sie dessen aktuellen Zustand mit einem zuvor gesicherten Referenzpunkt. Findet sie eine Abweichung, schlägt sie Alarm.
Der Referenzpunkt entsteht allerdings nur, wenn ein bestimmter vorgelagerter Schritt läuft. Genau dieser Schritt war nie eingebunden worden. Kein Referenzpunkt, kein Protokoll, nichts zu vergleichen. Die Routine startete zuverlässig, stellte jede Minute fest, dass ihr die Vergleichsgrundlage fehlt, und beendete sich mit einem entsprechenden Vermerk.
Das Bemerkenswerte ist nicht der Konstruktionsfehler. Solche Lücken entstehen ständig. Bemerkenswert ist, dass zwanzig Tage lang niemand davon erfuhr, obwohl der Vorgang minütlich ablief und seinen Zustand jedes Mal korrekt festhielt.
Drei Kontrollschichten, drei Gründe zu schweigen
Die erste Schicht war das Protokoll der Routine selbst. Es war bewusst so gebaut, dass es nur bei einer Zustandsänderung schreibt. Eine sinnvolle Entscheidung, denn ein minütlicher Eintrag mit immer derselben Meldung hätte das Protokoll unlesbar gemacht. Der Nebeneffekt dieser Sparsamkeit ist, dass ein unveränderter Fehlzustand exakt null Zeilen erzeugt. Je länger der Defekt bestand, desto stiller wurde er.
Die zweite Schicht war der Rückgabewert. Die Routine meldete ihn ordnungsgemäß an die Aufgabenverwaltung des Betriebssystems, wo er auch gespeichert wurde. Niemand las ihn aus. Ein Urteil, das gefällt, aber nie gelesen wird, ist Dekoration.
Die dritte Schicht war ein wöchentliches Audit, das genau solche stillstehenden Routinen finden soll. Es kannte den Ort nicht, an dem diese Aufgabe eingetragen war. Es prüfte gewissenhaft eine andere Liste und meldete jede Woche, dass dort alles in Ordnung sei. Diese Meldung war zutreffend und gleichzeitig wertlos.
Übrig blieb ein aufblitzendes Fenster als einziger funktionierender Melder. Hätte jemand es zu Beginn versteckt, wie es die naheliegende Reaktion gewesen wäre, liefe die Routine bis heute.
Der dritte Zustand
In der Vorstellung der meisten Verantwortlichen hat eine Automatisierung zwei Zustände. Sie läuft, oder sie ist ausgefallen. Der Ausfall wird bemerkt, weil etwas Erwartetes nicht eintrifft. Ein nicht verschickter Bericht, eine ausbleibende Datei, ein leeres Postfach am Montagmorgen.
Der gefährlichste Zustand ist ein dritter. Die Automatisierung läuft, meldet sich planmäßig, erzeugt Prozesslast und Protokolleinträge, und bewirkt dabei nichts. Sie sieht aus wie Betrieb und ist keiner.
Dieser Zustand ist schlimmer als ein sauberer Ausfall, weil er Vertrauen erzeugt, für das es keine Deckung gibt. Wer weiß, dass eine Prüfung ausgefallen ist, prüft eben von Hand. Wer glaubt, sie laufe, prüft gar nicht.
Vier Tage vor diesem Fund gab es im selben Betrieb bereits einen ähnlichen. Eine Backup-Überwachung hatte zehn Tage lang das falsche Datenverzeichnis kontrolliert und dabei zuverlässig grüne Meldungen geliefert. Auch dort steht im Protokoll, aufgefallen sei es beim Nachgehen einer unabhängigen Frage, nicht durch die Alarmierung. Zwei Fälle in vier Tagen sind kein Zufall, sondern eine Bauart-Schwäche. Wer einen Wächter baut, baut selten den Wächter für den Wächter.
Warum Lebenszeichen nichts beweisen
Die verbreitetste Antwort auf diese Sorge ist ein Lebenszeichen, im Fachjargon ein Heartbeat. Die Automatisierung schreibt bei jedem Lauf einen Zeitstempel. Bleibt der Zeitstempel stehen, weiß man, dass etwas klemmt.
Im geschilderten Fall funktionierte dieses Lebenszeichen tadellos. Es war jede Minute frisch, über zwanzig Tage hinweg, ohne eine einzige Lücke. Es bewies zuverlässig, dass die Routine startete. Über die Frage, ob sie etwas ausrichtete, sagte es nichts.
Lauf und Wirkung sind zwei verschiedene Signale. Sie müssen getrennt gemessen werden, weil sie unabhängig voneinander ausfallen können. Eine Automatisierung kann laufen ohne zu wirken, und in selteneren Fällen sogar wirken, während ihre Statusmeldung klemmt.
Was tatsächlich zu messen ist
Aus dem Fall lassen sich drei Prüffragen ableiten, die jede automatisierte Kontrolle beantworten können muss.
Erstens, liest jemand das Urteil. Ein Rückgabewert, ein Statuscode oder eine Ampel muss irgendwo ankommen, wo eine Reaktion möglich ist. Ohne diesen Empfänger ist die Prüfung eine Selbstbeschäftigung.
Zweitens, altert das Ergebnis. Nicht das Lebenszeichen, sondern das Arbeitsergebnis. Eine tägliche Auswertung, deren Berichtsdatei seit drei Wochen unverändert ist, arbeitet nicht mehr, ganz gleich wie pünktlich sie startet.
Drittens, und das ist die unbequemste Frage, wurde die Prüfung jemals unter echten Bedingungen ausgelöst. Im geschilderten Fall war der fehlende Baustein durchaus entwickelt und getestet worden. Die Tests liefen in einer eigens angelegten Testumgebung und bestanden. Was niemand prüfte, war die Verbindung zum tatsächlichen Betrieb. Ein bestandener Test in einer sauberen Umgebung belegt, dass eine Funktion arbeitet. Er belegt nicht, dass sie angeschlossen ist.
Die Verschärfung durch KI-Agenten
Bei einer klassischen Automatisierung ist der Prüfumfang überschaubar. Ein Skript tut, was dort steht, und der Zustandsraum ist endlich.
Handelnde KI-Agenten verschieben diese Lage in zwei Richtungen. Sie treffen Entscheidungen, die vorher nicht vollständig aufgeschrieben wurden, und sie erzeugen Ausgaben, die selbst dann überzeugend aussehen, wenn sie falsch sind. Ein Agent, der eine Prüfung durchführen soll, kann eine plausibel formulierte Bestätigung liefern, ohne die Prüfung vorgenommen zu haben. Bei einem Skript mit fehlerhaftem Rückgabewert bemerkt man den Widerspruch. Bei einem gut formulierten Absatz nicht.
Daraus folgt eine Regel, die sich in der Praxis bewährt hat. Ein Sprachmodell darf eine Freigabe verweigern, es sollte sie nicht erteilen. Die zustimmende Entscheidung gehört an eine überprüfbare, wiederholbare Prüfung ohne Modellbeteiligung. Ein Modell, das seine eigenen Vorschläge bewertet, liefert eine Selbstauskunft, keine Kontrolle.
Wer über den Einsatz von KI-Agenten in eigenen Abläufen nachdenkt, sollte diese Frage vor der Auswahl des Werkzeugs klären. Sie entscheidet darüber, ob am Ende ein prüfbarer Ablauf steht oder ein sehr überzeugend formulierter blinder Fleck.
Schluss
Die Routine ist inzwischen abgeschaltet, und zwar abgeschaltet und nicht versteckt. Ein Wächter ohne Wachobjekt gehört entfernt, weil ein sichtbar leerer Platz ehrlicher ist als eine Kontrolle, die niemanden schützt. Das wöchentliche Audit prüft seither auch den Ort, an dem die Aufgabe eingetragen war, und bewertet dabei nicht nur, ob eine Routine startet, sondern ob ihr Rückgabewert innerhalb des für sie erlaubten Bereichs liegt und ob ihr Arbeitsergebnis noch frisch ist.
Für Unternehmen mit gewachsener Automatisierung lohnt eine schlichte Bestandsaufnahme. Welche automatischen Prüfungen laufen, wer liest deren Ergebnis, und wann hat zuletzt jemand nachgesehen, ob sie noch etwas bewirken. Erfahrungsgemäß findet sich in jeder über Jahre gewachsenen Umgebung mindestens ein Wächter ohne Wachobjekt. Er meldet sich nicht, das ist ja gerade sein Kennzeichen.
Wenn Sie bei dieser Bestandsaufnahme feststellen, dass niemand im Haus die Ergebnisse Ihrer Überwachungsroutinen regelmäßig liest, ist das kein Werkzeugproblem, sondern eine Frage der Zuständigkeit. Genau diese Zuständigkeit übernehmen wir im Rahmen eines Wartungsvertrags. Sprechen Sie uns an, wenn Sie wissen möchten, was in Ihrer Umgebung tatsächlich noch prüft.