Warum eine Automatisierung kaputtgeht (aufbauen ist nicht dasselbe wie warten)
Eine KI-Automatisierung ist kein Möbelstück: Du baust sie nicht auf, steckst sie ein und vergisst sie. Sie ist ein Motor. Und ein Motor, der jeden Tag arbeitet, nutzt sich ab, braucht Öl und bleibt irgendwann stehen, wenn keiner hinschaut. Das Versprechen „wir lassen sie laufen und du fasst nie wieder etwas an" klingt gut im Verkaufsgespräch. In Produktion ist es die erste Lüge, die fällt.
Das Entscheidende ist, wie sie kaputtgeht. Fast nie mit einem Knall. Eine Automatisierung fällt selten auf einen Schlag aus —das würdest du wenigstens sehen—: Sie verschlechtert sich still. Sie läuft weiter, nur jede Woche ein bisschen schlechter, bis eines Tages jemand nachschaut und feststellt, dass sie seit einem Monat falsch klassifiziert, im falschen Ton antwortet oder Fälle überspringt. Dann ist der Schaden schon da. Warten ist das Gegenteil: hinschauen, bevor sich jemand beschwert.
Das ist kein Fehler deiner konkreten Automatisierung, so funktionieren sie alle. Die Wartung aus der Rechnung zu lassen ist sogar einer der Gründe, warum Automatisierungsprojekte scheitern: Der Start wird gefeiert, keiner übernimmt die Pflege, und sechs Monate später ist das System ein Zombie, den keiner abzuschalten oder zu reparieren wagt. Wenn du die große Karte zu all dem willst, sie steht im Leitfaden zum Automatisieren mit KI; hier ist der Zoom auf den Teil, der am Tag nach der Übergabe beginnt.
Die drei Dinge, die nachgeben: das Modell ändert sich, die Integration reißt, der seltene Fall taucht auf
Eine KI-Automatisierung steht auf drei Beinen, und alle drei bewegen sich mit der Zeit. Zu wissen, welche das sind, heißt zu wissen, was du im Blick behalten musst.
Eins: das Modell ändert sich. Der Anbieter aktualisiert die Version, justiert das Verhalten, mottet die eingesetzte Version aus. Er warnt dich nicht ins Gesicht: Eines Tages liefert derselbe Prompt eine Antwort mit anderem Ton, anderem Format oder weniger Genauigkeit. Das System bleibt nicht stehen —das ist das Problem—, es entscheidet nur etwas schlechter. Es ist der hinterhältigste Bruch, weil von allein kein Alarm losgeht — und genau deshalb wird ein Modellwechsel, der deine Automatisierungen nicht zerlegt, vorher vorbereitet und nicht an dem Tag, an dem er passiert.
Zwei: die Integration reißt. Dein CRM ändert ein Feld, eine API aktualisiert ihr Format, eine Berechtigung oder ein Token läuft ab, jemand fasst einen Export an. Das siehst du schnell: Der Ablauf stoppt schlagartig. Es ist der harte Bruch, der sein Gesicht zeigt. Und darum ist KI mit deinen Systemen zu integrieren keine einmalige Arbeit: Jedes System, an das du dich hängst, ist ein Teil, das sich auf eigene Faust bewegen kann.
Drei: der seltene Fall im 3. Monat. Am Anfang sieht die Automatisierung die normalen Fälle, für die sie gebaut wurde. Aber die reale Welt hat einen langen Schwanz: die Bestellung mit der seltsamen Bedingung, die E-Mail in einer Sprache, die du nicht erwartet hast, der Kunde, der das Formular verkehrt herum ausfüllt. Diesen Fall gab es nicht, als du gebaut hast; er taucht Wochen später auf und bricht einen Ablauf, der solide aussah. Keine Automatisierung kommt zur Welt und deckt 100 % der Realität ab; sie deckt sie ab, während die Realität sie ihr beibringt.
| Was nachgibt | Wie es sich zeigt | Wie du es fängst |
|---|---|---|
| Das Modell ändert sich | Antwortet weiter, aber schlechter: anderer Ton, anderes Format, weniger Treffer | Log- und Stichprobenprüfung; kein Alarm von allein |
| Die Integration reißt | Der Ablauf stoppt schlagartig | Fehleralarme; am selben Tag zu sehen |
| Der seltene Fall taucht auf | Ein neuer Eingabetyp blockiert oder lenkt den Ablauf ab | Ausnahme-Warteschlange und Prüfung des Eskalierten |
Was Wartung wirklich ist (du pflegst einen Motor, du hängst kein Bild auf)
Warten heißt nicht „für alle Fälle dabei sein". Es ist konkrete Arbeit mit konkreten Aufgaben. Du pflegst den Motor: Du prüfst, wie er entscheidet, justierst, was driftet, stopfst die Löcher, die der reale Betrieb aufdeckt. Du hängst kein Bild auf, um es aus der Ferne zu bewundern.
In der Praxis ist die Wartung einer KI-Automatisierung vier Dinge:
- Die Entscheidungen überwachen. In den Logs anschauen, was das System entscheidet, und es damit vergleichen, was ein Mensch entscheiden würde. Wo es richtig liegt, bleibt es; wo es scheitert, korrigierst du.
- Prompts und Regeln iterieren. Die Anweisungen anpassen, wenn sich das Modell ändert oder ein neues Muster auftaucht. Das ist kein Umprogrammieren: Es ist Feinschliff.
- Die Grenzfälle beheben. Die eskalierten Ausnahmen einsammeln, verstehen warum, und entscheiden, ob du sie abdeckst oder weiter an einen Menschen leitest. Hier lebt die Grenze Mensch in der Schleife, und sie ist nicht fix: Sie bewegt sich mit dem, was die Daten lehren.
- Die Integrationen im Blick behalten. Prüfen, dass die Verbindungen zu deinen Systemen noch leben, und handeln, wenn eine ausfällt, bevor der ganze Ablauf stoppt.
All das hat einen Preis, und ihn von Anfang an einzurechnen ist das Ehrliche. Es ist eines der drei Beine der Rentabilitätsrechnung: Setup, Modell und Wartung. Wenn du rechnest und das dritte weglässt, lügt die Zahl. Darum besteht der Leitfaden zum ROI der Automatisierung darauf, die Wartungsstunden einzurechnen, bevor du unterschreibst: Ein System, das billig zu bauen ist, kann teuer im Unterhalt sein.
Wie oft du sie prüfst und was du bei jedem Durchgang anschaust
Wartung heißt weder, ständig auf das System zu starren, noch, nie hinzuschauen. Es ist eine Taktung. Manches wird automatisch überwacht und schlägt von allein aus, anderes braucht ab und zu ein Paar Augen.
- Laufend (automatisch). Fehleralarme: Wenn eine Integration ausfällt oder ein Ablauf stoppt, schlägt es sofort aus. Das wartet nicht auf die Prüfung; es ist das Netz, das den harten Bruch meldet.
- Wöchentlich (ein schneller Durchgang). Ein Blick auf die Logs und die Ausnahme-Warteschlange: was eskaliert ist, welche neuen Fallarten auftauchten, ob das Fehlervolumen steigt. Zehn Minuten, die verhindern, dass ein kleines Problem zu einem verlorenen Monat wird.
- Monatlich (Qualitätsprüfung). Eine Stichprobe der Systementscheidungen im Vergleich mit menschlichem Urteil, um die stille Drift des Modells zu fangen. Hier merkst du, ob der Anbieter unten etwas verändert hat.
- Wenn der Anbieter das Modell aktualisiert. Außer der Reihe: Wenn eine neue Version erscheint oder deine ausgemottet wird, testest du sie, bevor du sie allein laufen lässt. Ein Modellwechsel wird wie ein Teiletausch behandelt, nicht wie ein Detail.
Die Regel darunter: Was auf einen Schlag kaputtgeht, wird automatisch überwacht; was langsam abbaut, wird von Hand geprüft. Du brauchst beides. Alarme allein fangen die Modell-Drift nicht; manuelle Prüfungen allein lassen dich eine ausgefallene Integration zu spät bemerken.
Wie du sie mit Netz übergibst: Logs, Alarme und ein Verantwortlicher
Eine Automatisierung, die sich nicht warten lässt, ist eine Automatisierung, die nicht fertig ist. Und um sie warten zu können, brauchst du drei Dinge ab dem ersten Tag, nicht als Flickwerk hinterher.
Logs, um zu sehen, was das System entschieden hat und warum —ohne Aufzeichnung gibt es keine Überwachung, nur Glauben—. Alarme, damit der harte Bruch dich findet, bevor er deinen Kunden findet. Und einen Verantwortlichen: eine Person mit Namen, die sich darum kümmert, die Logs zu lesen, die Alarme zu behandeln und zu iterieren. Ohne Verantwortlichen macht die Wartung niemand, was dasselbe ist wie keine zu haben. Wer dieser Verantwortliche ist und mit welcher Autonomie er arbeitet, gehört dazu, dass dein Team KI wirklich annimmt, statt sie nur einzuweihen.
Und eine Grenze, die man aussprechen sollte: Wartung entscheidet, was jeden Monat geprüft wird — nicht, was in der Nacht passiert, in der etwas stehen bleibt. Diese andere Hälfte —wer angerufen wird, wie dringend, und was das Geschäft in der Zwischenzeit tut— ist wer reagiert, wenn eine Automatisierung ausfällt: Schweregrade, Bereitschaft und Runbook im Maßstab eines kleinen Unternehmens.