Der stille Fehler: Warum KI-Automationen im Betrieb kaputtgehen, ohne dass es auffällt

Ein Automationssystem aufzusetzen ist heute schnell gemacht. Ein paar Bausteine verbinden, ein Modell dranhängen, einmal testen, und es läuft. Der erste Moment fühlt sich gut an. Das Problem kommt zwei Monate später, wenn niemand mehr draufschaut und das System leise etwas anderes tut als am ersten Tag.

Nach dem Go-Live betreue ich die KI-Workflows, die ich baue, weiter. Die ehrlichste Lektion aus dieser Arbeit: Der Aufbau ist der kleinere Teil. Die eigentliche Arbeit beginnt, wenn das System läuft und laufen bleiben soll.

Warum Automationen mit der Zeit kaputtgehen

Ein Workflow hängt an Dingen, die sich verändern, ohne dich zu fragen. Eine Website stellt ihr Layout um, und der Baustein, der gestern den Artikeltext geholt hat, zieht heute etwas anderes. Eine Schnittstelle ändert ihr Format. Ein Anbieter dreht an einem Limit. Nichts davon meldet sich als Fehler. Das System läuft weiter, es verarbeitet ab jetzt nur Müll oder Leere.

Das ist die gefährlichste Sorte Fehler, der stille. Ein Absturz ist harmlos, den siehst du sofort. Schlimmer ist das System, das scheinbar normal weiterläuft und dabei seit drei Wochen halbe Daten verarbeitet.

Ein Beispiel aus meiner Arbeit: In einem Content-System hatte ich Quellen angebunden, die ihren Volltext sonst zuverlässig ausliefern. Irgendwann bekam der automatische Abruf bei zwei davon nur noch einen Standardblock zurück, eine Art FAQ-Gerüst, statt des eigentlichen Artikels. Im Browser sah die Seite für einen Menschen völlig normal aus. Für das System sah es aus, als hätte es den vollen Text erhalten. Es hakte den Abruf als erfolgreich ab und arbeitete mit einer leeren Hülle weiter. Ohne eine gezielte Prüfung wäre das wochenlang niemandem aufgefallen.

Was ein System braucht, um zu bleiben

Genau hier trennt sich ein Bastelprojekt von einem System, auf das man sich verlassen kann. Ein paar Dinge entscheiden darüber.

Die Überwachung muss auf das Richtige schauen. Es reicht nicht zu prüfen, ob ein Workflow durchgelaufen ist. Er läuft ja durch, auch mit Müll. Die eigentliche Frage ist, ob am Ende etwas Sinnvolles herauskommt. Dafür braucht es Plausibilitätsprüfungen, die anschlagen, wenn ein Ergebnis zu kurz, zu leer oder zu seltsam ist.

Genauso wichtig sind Alarme, die wirklich einen Menschen erreichen. Ein Fehler, der in einem Log steht, das keiner liest, ist kein bemerkter Fehler. Ich lasse meine Systeme melden, wenn etwas aus dem Rahmen fällt, direkt als Nachricht aufs Handy. So sehe ich ein Problem am selben Tag und nicht, wenn sich der Kunde beschwert.

Den Rest fängt der menschliche Freigabepunkt. Der sichert die inhaltliche Qualität und ist zugleich das letzte Netz gegen stille Fehler. Wer einen Entwurf freigibt, merkt sofort, wenn statt eines Artikels plötzlich eine leere Hülle ankommt.

Und jemand muss zuständig sein. Ein System ohne Betreuer verrottet langsam, weil sich die Welt um es herum weiterdreht und niemand nachzieht. Das ist keine Frage von vielen Stunden, aber von Regelmäßigkeit.

Der Unterschied, den das im Alltag macht

Deshalb scheitern die meisten selbstgebauten Automationen im Betrieb, nicht beim Aufbau. Das Zusammenstecken schafft heute fast jeder mit etwas Geduld. Was fehlt, ist der Plan für den Tag, an dem sich still etwas ändert. So ein System hat kein Enddatum. Es läuft weiter und braucht dauerhaft jemanden, der es im Blick behält.

Für dich als Auftraggeber heißt das zweierlei. Wenn du selbst baust, plane den Betrieb von Anfang an mit ein und nicht erst den Start. Und wenn du es bauen lässt, dann zählt neben der Frage, was das System kann, vor allem, wer sich darum kümmert, wenn es hakt.