Ein Immobilienbüro merkt um 10:17 Uhr, dass der neue Agent Besichtigungstermine mit der falschen Uhrzeit bestätigt. Sechs Nachrichten sind bereits draussen, weitere zwanzig liegen in der Warteschlange. Der erste Reflex lautet: „Alles ausschalten.“
Nur: Was genau ist „alles“? Den AI-Workflow? Das CRM? Den Mailversand? Die komplette Terminannahme? Und was passiert mit den sechs bereits versendeten Bestätigungen?
Ein Not-Aus ist dann gut, wenn er schnell den falschen Effekt stoppt, ohne unnötig den ganzen Betrieb stillzulegen. Rollback ist die zweite Frage: Welche Zustände lassen sich technisch zurückdrehen, welche müssen menschlich korrigiert werden?
NIST behandelt Incident Response als vorbereitete Fähigkeit zur Reaktion und Wiederherstellung, nicht als spontane Aktion nach einem Vorfall. Für AI-Automationen ist genau dieser Gedanke hilfreich: Der Not-Aus gehört vor dem ersten produktiven Fehler ins Design.
Ein KI-Not-Aus ist kein grosser roter Button
In einer Demo reicht häufig ein Toggle „Workflow off“. In Produktion bestehen Automationen aus mehreren Teilen: Eingangskanal, Modell, Warteschlange, CRM, Mail- oder SMS-Tool, Kalender, Webhooks und Hintergrundjobs.
Wenn der Agent falsche Texte erzeugt, kann es genügen, externe Sends zu stoppen und Anfragen weiter anzunehmen. Wenn Credentials kompromittiert wirken, müssen Sie eventuell Zugänge widerrufen. Wenn die Logik doppelte Buchungen erzeugt, stoppen Sie Schreibzugriffe, aber lassen Lesezugriffe und Monitoring laufen.
Darum sollte ein Not-Aus mindestens auf Ebenen denken: Aufnahme, Entscheidung, Schreiben und Ausführen und Credentials. Je kleiner Sie stoppen können, desto weniger Geschäft verlieren Sie während der Untersuchung.
etablierte Incident-Response- und Ausfallsicherheit-Ansätze trennen Eindämmung, Wiederherstellung und kontrollierten Betrieb.
Empfehlung: Bauen Sie für kritische Agenten mehrere gezielte Schalter statt nur einen globalen Off-Button.
Stoppen ist nicht dasselbe wie rückgängig machen
Ein CRM-Feld lässt sich oft auf einen alten Wert zurücksetzen. Ein falsch versendetes E-Mail lässt sich nicht aus dem Postfach des Kunden zurückholen. Ein Kalendereintrag kann gelöscht werden, aber der Kunde kann die alte Bestätigung bereits gelesen haben. Eine Zahlung oder Bestellung kann weitere Prozesse ausgelöst haben.
Deshalb ist „Rollback“ bei Business-Automation häufig eine Mischung aus technischen und kompensierenden Aktionen.
Technisch reversibel sind zum Beispiel ein interner Status, ein Entwurf oder eine noch nicht veröffentlichte Datensatzänderung. Bei externen Effekten brauchen Sie dagegen oft eine Korrekturaktion: Nachricht senden, Termin telefonisch bestätigen, Gutschrift prüfen oder einen falschen Datensatz mit menschlichem Kontext bereinigen.
Microsofts Architekturpatterns beschreiben unter anderem Compensating Transactions für verteilte Prozesse, bei denen nicht jede bereits ausgeführte Aktion einfach zurückgerollt werden kann. Das passt gut zur Realität von KMU-Automationen.
Ein ehrlicher Eintrag in der Betriebsanleitung sagt also nicht „Rollback E-Mail“, sondern: „Outbound stoppen; betroffene Empfänger identifizieren; Korrekturtext durch Mitarbeiter freigeben; Versand dokumentieren.“
Der Ablauf in den ersten 15 Minuten
Ein guter Incident-Flow muss so kurz sein, dass jemand ihn unter Stress tatsächlich benutzt.
- Ausführung eindämmen. Neue riskante Schreibvorgänge oder externe Nachrichten stoppen; Aufnahme wenn möglich weiterlaufen lassen.
- Warteschlange einfrieren. Noch nicht ausgeführte Jobs nicht löschen, sondern markieren und vor erneuter Verarbeitung schützen.
- Zugriff begrenzen. Bei Verdacht auf Credential- oder Berechtigungsproblem die Agentenidentität oder betroffene Tokens widerrufen.
- Beweise sichern. Lauf-ID, Prompt-Kontext, Tool-Aufrufe, betroffene Datensätze, Zeit und Version dokumentieren.
- Auswirkungen klassifizieren. Reversibel, kompensierbar oder irreversibel; danach Verantwortlicher und Korrekturweg bestimmen.
- Kontrolliert wiederanlaufen. Erst mit einem Testfall, kleiner Warteschlange und Monitoring; kein „alles wieder an“ nach einem einzelnen Fix.
Wichtig ist die Warteschlange. Ein häufiger Fehler entsteht nach dem vermeintlichen Fix: Der Workflow wird eingeschaltet und spielt automatisch zwanzig alte, inzwischen manuell bearbeitete Jobs erneut ab. Der Not-Aus hat dann den ersten Schaden gestoppt und der Wiederanlauf erzeugt den zweiten.
Wer entscheidet, wann wieder gestartet wird?
Der Entwickler allein sollte den Geschäftsprozess nicht wieder freigeben, wenn er die Kundenfolgen nicht kennt. Gleichzeitig kann die Geschäftsführung keinen technischen Zustand beurteilen.
Für kleine Teams reicht eine klare Zweierlogik: Die technisch verantwortliche Person bestätigt, dass Ursache und technische Barriere verstanden sind. Die fachlich verantwortliche Person bestätigt, dass offene Kundenfälle, Warteschlange und Korrekturen geklärt sind. Bei kleinen Automationen können beide Rollen bei derselben Person liegen; die zwei Fragen bleiben trotzdem getrennt.
Übergabe an Menschen ist besonders wichtig bei irreversiblen Effekten. Ein Agent sollte nicht autonom entscheiden, wie eine falsche Preiszusage korrigiert oder ein verärgerter Kunde angesprochen wird. Das ist keine Rechenaufgabe, sondern eine Geschäftsentscheidung.
Ausnahmen gibt es: Bei völlig internen, reversiblen Aktionen kann ein automatischer Rollback sinnvoll sein. Wenn ein System ein fehlerhaftes Tag setzt und die alte Version eindeutig gespeichert ist, muss nicht jedes Mal jemand klicken. Das sollte aber bewusst festgelegt und getestet sein.
Minimaler sicherer Pilot: Not-Aus vor Autonomie testen
Bevor ein Agent selbstständig Kundenaktionen ausführt, testen Sie einen künstlichen Fehler. Lassen Sie ihn absichtlich einen ungültigen Status erzeugen oder eine Testnachricht in eine isolierte Umgebung schicken. Stoppen Sie den Prozess über denselben Mechanismus, den Sie im Ernstfall verwenden würden.
Danach beantworten Sie fünf Fragen: Welche Komponente wurde tatsächlich gestoppt? Sind neue Anfragen verloren gegangen? Bleibt die Warteschlange sichtbar? Können irreversible und reversible Effekte getrennt werden? Wer darf den Wiederanlauf auslösen?
Messen Sie Zeit vom Alarm bis zum Stop, Anzahl Aktionen nach Auslösung des Not-Aus, Anteil betroffener Vorgänge mit vollständigem Audit-Trail, Zeit bis zur fachlichen Korrektur, Quote erfolgreicher kontrollierter Wiederanläufe und Zahl der Fälle, die nach dem Wiederanlauf doppelt ausgeführt wurden.
Die letzte Kennzahl sollte idealerweise null bleiben — nicht als Marketingversprechen, sondern als konkrete Prüfgrösse.
Der wichtigste Schluss: Ein AI-Agent ist erst dann produktionsreif, wenn Sie nicht nur wissen, wie Sie ihn starten, sondern auch wie Sie ihn sauber stoppen. Not-Aus, Rollback und Reconciliation sind keine Extras für Grossunternehmen. Sie sind die Mechanik, die verhindert, dass ein kleiner Fehler zum betrieblichen Chaos wird.
Auch Prompts, Berechtigungen, Routing-Regeln und Wissensquellen sind Versionen. Nach einer fehlerhaften Änderung muss nachvollziehbar sein, welcher Stand aktiv war. Die Incident-Response-Vorlage regelt die Kommunikation; das Agent-Inventar zeigt, welche Systeme betroffen sind.
Quellen
- NIST SP 800-61 Rev. 3 — Incident Response
- NIST — AI Risk Management Framework 1.0
- Microsoft Azure Architecture Center — Cloud Design Patterns
FAQ
Reicht es, den Workflow in Make oder Zapier zu deaktivieren?
Das kann ein Teil des Not-Aus sein. Prüfen Sie zusätzlich Warteschlangen, laufende Jobs, Credentials und bereits ausgelöste externe Aktionen.
Kann man jede AI-Aktion zurückrollen?
Nein. Externe Nachrichten, bestätigte Termine oder andere irreversible Effekte brauchen oft eine kompensierende menschliche Aktion.
Sollte der Not-Aus automatisch auslösen?
Für klar definierte technische Grenzwerte kann das sinnvoll sein. Geschäftlich wichtige Stopps sollten jedoch transparent eskalieren und einen Verantwortlichen haben.
Muss während einer Störung die Aufnahme ausfallen?
Nicht zwingend. Oft ist ein reduzierter Betrieb besser: Anfragen weiter erfassen, aber riskante Schreibvorgänge und Zusagen pausieren.
Wer darf die Automation wieder starten?
Eine vorher definierte Rolle. Idealerweise sind technische Ursache und fachliche Auswirkungen beide geprüft.