KI-Automationen haben eine Eigenschaft, die klassische Skripte selten haben: Einzelne Schritte dauern lange und unterschiedlich lange. Ein Generierungslauf kann Minuten oder Stunden brauchen, je nach Auslastung. In dieser Zeit laufen andere Prozesse weiter — und arbeiten häufig auf denselben Daten. Daraus entsteht eine Fehlerklasse, die keine Fehlermeldung erzeugt und trotzdem Ergebnisse vernichtet.
Das Muster in seiner einfachsten Form
Ein langlaufender Prozess liest zu Beginn den gesamten Arbeitsstand in den Speicher. Er arbeitet ihn ab und schreibt ihn am Ende vollständig zurück. Dazwischen hat ein zweiter, schneller Prozess einzelne Einträge verändert. Der langsame Prozess weiß davon nichts und überschreibt sie mit dem Stand von vor Stunden.
Sichtbar wird das nicht als Absturz, sondern als seltsames Verhalten: Erledigte Aufgaben tauchen erneut auf, bereits verschickte Nachrichten gehen ein zweites Mal raus, Statusangaben springen zurück. Weil kein Fehler protokolliert wird, sucht man die Ursache typischerweise zuerst in der Fachlogik — dort ist sie nicht.
Vier Regeln, die das Problem lösen
Die Gegenmaßnahmen sind einfach, müssen aber vollständig angewendet werden. Eine halbe Lösung erzeugt seltenere Fehler, keine besseren.
- Nie einen alten Gesamtstand zurückschreiben. Vor jeder Änderung frisch einlesen und ausschließlich das eigene Feld ändern.
- Schreibzugriffe serialisieren. Eine Sperre, die genau den Moment des Lesens, Änderns und Schreibens umfasst.
- Vor der langsamen Aktion reservieren. Den Eintrag als in Bearbeitung markieren, bevor der eigentliche Vorgang startet.
- Jede Reservierung verfällt. Ohne Verfallszeit blockiert ein abgestürzter Prozess den Eintrag dauerhaft.
Die dritte Regel ist die entscheidende. Sie schützt nicht die Datei, sondern die Handlung: Solange ein Eintrag reserviert ist, kann kein zweiter Prozess dieselbe Aktion auslösen — auch dann nicht, wenn er zwischenzeitlich startet.
Eine Sperre muss zwei Eigenschaften haben, sonst schadet sie mehr als sie nützt: Sie muss atomar erzeugt werden, damit zwei Prozesse sie nicht gleichzeitig erhalten können, und sie muss nach einer festen Zeit ungültig werden. Eine Sperre ohne Verfall führt beim ersten Absturz dazu, dass gar nichts mehr läuft.
Warum das gerade bei KI-Läufen zuschlägt
Bei klassischen Prozessen sind Laufzeiten meist stabil und kurz. Bei KI-Läufen sind sie es nicht: Dieselbe Aufgabe kann heute Sekunden und morgen Minuten dauern, abhängig von Modellauslastung, Modellwechseln im Speicher oder konkurrierenden Aufgaben auf derselben Hardware. Das Zeitfenster für Konflikte ist damit nicht konstant, sondern schwankt genau dann, wenn das System stark ausgelastet ist.
Hinzu kommt, dass viele KI-Automationen ihre Warteschlange in einer einzelnen Datei führen, weil das zu Beginn ausreicht. Solange nur ein Prozess darauf zugreift, funktioniert das tadellos. Der Bruch entsteht in dem Moment, in dem ein zweiter, unabhängig getakteter Prozess dazukommt — und niemand die Annahme aus der Anfangszeit noch einmal prüft. Dass rechenintensive Läufe deshalb bewusst getaktet gehören, ist in Nachtlauf statt Echtzeit beschrieben.
Nachweisbar machen, dass es hält
Eine Absicherung, die nur im Normalfall geprüft wurde, ist nicht geprüft. Der aussagekräftige Test ist die Gegenprobe: Man baut die Sperre bewusst aus und lässt mehrere Prozesse gleichzeitig laufen. Tritt der Fehler dann reproduzierbar auf, war der Test scharf genug. Tritt er nicht auf, prüft der Test etwas anderes als angenommen.
Im laufenden Betrieb hilft eine zusätzliche Kennzahl: die Zahl der Fälle, in denen ein Prozess auf eine Sperre gestoßen ist. Steigt sie, überlappen Läufe häufiger als geplant. Das ist eine Warnung, bevor die Auswirkungen sichtbar werden — und deutlich hilfreicher als die nachträgliche Suche nach doppelten Ergebnissen.
Der Grundsatz dahinter
Wer Automationen um KI herum baut, sollte jeden geteilten Zustand als potenzielle Konfliktstelle behandeln: Warteschlangen, Zählerstände, Statusfelder, Ergebnislisten. Die Frage lautet immer gleich — kann zwischen meinem Lesen und meinem Schreiben etwas passiert sein? Lautet die Antwort ja, braucht es eine Sperre, eine Reservierung oder beides.
Diese Fehlerklasse verursacht selten einen Ausfall und häufig falsche Daten. Und falsche Daten sind teurer, weil man auf ihrer Grundlage weiterarbeitet.