Ein AI Agent fällt nicht auf dieselbe Weise aus wie eine klassische Anwendung. Ein herkömmlicher Ausfall ist meist sichtbar: Ein Service gibt einen Fehler zurück, eine Queue verarbeitet keine Einträge mehr, ein Dashboard wird rot. Das unmittelbare Ziel lautet dann, die Verfügbarkeit wiederherzustellen.
Ein Agent kann jedoch verfügbar bleiben und zugleich operativ unsicher werden. Er arbeitet möglicherweise mit veralteten Retrieval-Ergebnissen, ruft ein ungeeignetes Tool auf, wendet eine Freigaberegel falsch an, leitet Vorgänge an die falsche Queue weiter oder trifft nach einer Änderung am Modell, Prompt oder Workflow wesentlich andere Entscheidungen. Das Unternehmen entdeckt den Fehler unter Umständen erst, nachdem Kunden falsche Nachrichten erhalten haben, Transaktionen verändert wurden oder Mitarbeitende auf unzuverlässige Empfehlungen reagiert haben.
Dieser Unterschied ist für AI Disaster Recovery entscheidend. Backup dient der Wiederherstellung von Systemen und Daten. Operative Resilienz für AI dient der Wiederherstellung kontrollierten Verhaltens. Jedes Unternehmen, das Agents in Produktion betreibt, sollte dies vor dem ersten schwerwiegenden Incident üben – statt ein Reaktionsmodell erst zu entwickeln, während das Geschäft bereits Risiken ausgesetzt ist.
Warum ein Agent-Incident mehr ist als ein Ausfall
Ein agentischer Workflow verbindet typischerweise mehrere bewegliche Teile: ein Modell, Prompts, Tool-Berechtigungen, Workflow-Logik, Retrieval-Quellen, Identitätskontrollen, Memory oder Session State, Integrationen und menschliche Freigabeschritte. Ein Fehler kann in jeder dieser Komponenten entstehen, während seine Folgen oft an ganz anderer Stelle sichtbar werden.
Nehmen wir einen internen Service Agent, der Datensätze aktualisieren, Tickets anlegen und Antworten an Kunden formulieren darf. Die Anwendung kann technisch gesund sein, doch eine Änderung am Retrieval-Index kann dazu führen, dass der Agent überholte Richtliniendokumente verwendet. Eine Berechtigungskonfiguration kann ihm erlauben, ein Tool mit Schreibzugriff aufzurufen, das eigentlich nur für einen überwachten Workflow vorgesehen war. Ein Modell-Update muss nichts technisch beschädigen und kann dennoch verändern, wie der Agent einen Sonderfall interpretiert, der zuvor an einen Menschen eskaliert wurde.
Die gefährliche Annahme lautet, dass die Wiederherstellung eines früheren Datenbank-Snapshots das Problem löst. Sie stellt vielleicht Datensätze wieder her, beantwortet aber nicht automatisch, welche Aktionen der Agent ausgeführt hat, welche externen Systeme sie erhalten haben, ob Mitarbeitende diese Datensätze später verändert haben oder ob derselbe Fehler weiterhin im Workflow steckt, der nun erneut gestartet werden soll.
Die Einheit der Wiederherstellung ist der Geschäftsprozess, nicht allein die Infrastruktur. Wenn ein Agent in der Schadenbearbeitung, Beschaffung, Kundenbetreuung, internen IT-Operations oder Finanzadministration mitwirkt, muss die Wiederherstellung jede Geschäftstransaktion umfassen, die in dem Zeitraum berührt wurde, in dem sein Verhalten nicht vertrauenswürdig war.
Die erste Frage: Wie stoppen Sie Handlungen?
Die erste Anforderung in einem AI-Incident ist ein glaubwürdiger Weg, den Agent daran zu hindern, weiteren Schaden anzurichten. „Schalten Sie ihn ab“ klingt einfach, doch viele Teams haben nicht definiert, was das praktisch bedeutet.
Ein Agent kann auf verschiedene Arten handeln. Er kann Nachrichten versenden, Daten schreiben, Freigaben erstellen, nachgelagerte Automatisierungen auslösen, externe APIs aufrufen oder Empfehlungen abgeben, die Mitarbeitende anschließend umsetzen. Das Deaktivieren der Benutzeroberfläche kann Background Jobs weiterlaufen lassen. Das Entziehen einer Tool-Credential verhindert möglicherweise nicht, dass eine zweite Integration fortfährt. Das Pausieren eines Workflows kann neue Arbeit stoppen, während laufende Aktionen in einem unklaren Zustand verbleiben.
Eine Tabletop-Übung sollte deshalb mit einem präzisen Incident-Szenario und einer harten Frage beginnen: Wer besitzt die Autorität und die technischen Mittel, den Agent in einen sicheren Zustand zu versetzen?
Bei einem kundenorientierten Agent kann der sichere Zustand eine kontrollierte Übergabe an eine menschliche Queue sein. Bei einem internen Automatisierungs-Agent kann dies bedeuten, Schreibaktionen sofort zu deaktivieren und für die Untersuchung ausschließlich lesenden Zugriff beizubehalten. Bei einem Workflow mit hoher Wirkung kann es erforderlich sein, Tool-Berechtigungen zu entziehen, die Task-Orchestrierung anzuhalten und relevante Geschäftsprozesse einer manuellen Freigabe zu unterstellen, bis der Fehler verstanden ist.
Das ist keine Frage für das AI-Team allein. Die Verantwortung sollte zwischen IT, Security, Operations und der Fachfunktion, die den Prozess verantwortet, klar geregelt sein. Wenn drei Führungskräfte zunächst darüber diskutieren müssen, ob ein Agent weiter handeln darf, verfügt die Organisation über keinen Incident-Response-Mechanismus, sondern über eine Meeting-Abhängigkeit.
Ein hilfreiches Designprinzip ist fehlersichere Degradierung. Wenn das Vertrauen in den Workflow verloren geht, sollte der Agent die Fähigkeit verlieren, folgenschwere Aktionen auszuführen, bevor er die Fähigkeit verliert zu erklären, was er getan hat. Das setzt eine bewusste Trennung von Beobachtungs-, Empfehlungs- und Ausführungsberechtigungen voraus.
Die zweite Frage: Welche Beweise müssen gesichert werden?
Teams erschweren die Wiederherstellung oft, indem sie Systeme zu früh neu starten. Ein Agent-Incident verlangt Beweise, die sein Verhalten nachträglich erklären können. Ohne sie kann die Organisation weder die Fehlergrenze bestimmen noch die geschäftlichen Auswirkungen bewerten oder begründen, warum eine bestimmte Korrekturmaßnahme ergriffen wurde.
Die erforderlichen Beweise gehen über Application Logs hinaus. Sie sollten dokumentieren, welche Version des Workflows lief, welcher Modell-Endpunkt und welche Konfiguration verwendet wurden, welcher Prompt und welche Policy-Anweisungen galten, welcher Kontext abgerufen wurde, welche Tools verfügbar waren, welche Aufrufe erfolgten und welche Antworten zurückkamen. Wo menschliche Freigaben beteiligt sind, muss der Audit Trail außerdem zeigen, ob eine Freigabe angefordert, erteilt, umgangen oder falsch interpretiert wurde.
Das bedeutet nicht, dass jede denkbare Information unbegrenzt gespeichert werden muss. Es bedeutet, Observability anhand der Entscheidungen zu gestalten, die die Organisation möglicherweise rekonstruieren muss. Das passende Modell für Aufbewahrung und Zugriff hängt vom Use Case, der Datensensibilität und internen Richtlinien ab. Wenn ein Agent jedoch einen Kundendatensatz ändern oder eine Lieferanteninteraktion anstoßen kann, sollte eine untersuchende Person die Kette vom Auslöser über den Tool Call bis zum daraus resultierenden Geschäftsergebnis nachvollziehen können.
Beweise zu sichern heißt auch, Versionen zu sichern. Ein Modellname allein genügt nicht als operativer Nachweis. Das tatsächliche Verhalten eines Agent wird von seiner gesamten umgebenden Konfiguration geprägt: Prompt Templates, Routing-Logik, Retrieval-Einstellungen, Tool Schemas, Berechtigungen und Datenquellen. Sind diese Komponenten nicht versioniert, kann ein Team ein früheres Deployment zwar technisch wiederherstellen, aber weiterhin nicht nachweisen, was sich verändert hat.
Bitten Sie die Teilnehmenden in der Tabletop-Übung, die Beweise zu benennen, die sie benötigen würden, wenn der Incident erst mehrere Tage später durch eine Kundenbeschwerde oder einen Finanzabgleich entdeckt würde. Lautet die Antwort „Wir würden in die Logs schauen“, hat die Übung eine Lücke offengelegt. Eine brauchbare Antwort benennt konkret, welche Logs erforderlich sind, welche Systemverantwortlichen darauf zugreifen können, wie sie geschützt werden und wie das Incident-Team sie einzelnen Geschäftstransaktionen zuordnet.
Die dritte Frage: Was ist ein bekannter sicherer Workflow?
Das Rollback eines Agent wird häufig als Rückkehr zu einer früheren Modellversion missverstanden. Tatsächlich ist ein Rollback die kontrollierte Rückkehr zu einem bekannten sicheren Betriebszustand.
Ein bekannter sicherer Workflow besteht aus mehr als einem früheren Deployment-Artefakt. Er verfügt über eine dokumentierte Konfiguration, getestete Tool-Berechtigungen, validierte Datenabhängigkeiten und klare Erwartungen an sein Verhalten. Außerdem gibt es einen benannten Verantwortlichen, der seine Rückkehr in den Betrieb autorisieren kann. Kann das Team nicht sagen, welche Version zuvor sicher war und weshalb, kann ein Rollback lediglich einen früheren, weniger sichtbaren Fehler erneut einführen.
Für viele DACH-Mittelständler ist das verlässlichste Recovery-Design keine ausgefeilte Selbstheilung. Es ist ein überschaubares, diszipliniertes Release-Modell. Änderungen an Prompts, Modellen, Tools, Retrieval-Quellen und Freigabelogik sollten nachvollziehbar sein. Production Deployments sollten über einen expliziten Release-Eintrag verfügen. Wesentliche Änderungen sollten anhand repräsentativer Aufgaben bewertet werden, bevor sie auf Live-Systemen handeln dürfen.
Die Tabletop-Übung sollte prüfen, ob das Team diesen Zustand ohne Improvisation wiederherstellen kann. Kann es die freigegebene Workflow-Version identifizieren? Kann es sie über den normalen Release-Pfad deployen? Kann es verifizieren, dass gefährliche Tool-Berechtigungen weiterhin eingeschränkt sind? Kann es das Verhalten in einer kontrollierten Umgebung testen, bevor der Live-Workflow wieder geöffnet wird?
Verwechseln Sie die Wiederherstellung des Service nicht mit der Wiederherstellung von Vertrauen. Der Agent ist nicht bereit, die Arbeit wiederaufzunehmen, nur weil er wieder reagiert. Er ist erst bereit, wenn die Organisation Belege dafür hat, dass sein freigegebener Workflow, sein Kontext und seine Handlungsgrenzen wie vorgesehen funktionieren.
Die vierte Frage: Wie gleichen Sie das Fehlerfenster ab?
Der schwierigste Teil von AI Disaster Recovery ist oft der Zeitraum zwischen der ersten falschen Aktion und dem Moment, in dem die Organisation den Agent stoppt. Dies ist das Fehlerfenster.
In dieser Zeit kann der Agent Datensätze angelegt, Daten verändert, externe Workflows ausgelöst oder Empfehlungen erzeugt haben, auf die Menschen anschließend reagiert haben. Eine einfache Rückabwicklung kann ebenso schädlich sein wie der ursprüngliche Fehler. Ein Kundendatensatz wurde möglicherweise nach dem Fehler des Agent manuell korrigiert. Eine Lieferantenanfrage kann in einen separaten Prozess übergegangen sein. Eine Support-Antwort erfordert möglicherweise eine Nachfasskommunikation statt einer Löschung.
Der Abgleich sollte deshalb als fachlich geführter Prozess behandelt werden, der durch technische Beweise unterstützt wird. Das Aktivitätsprotokoll des Agent identifiziert potenziell betroffene Transaktionen, doch die Prozessverantwortlichen entscheiden, was als Behebung gilt. Manche Transaktionen lassen sich automatisch rückgängig machen. Andere müssen durch einen Fallverantwortlichen geprüft werden. Manche erfordern eine Kommunikation mit betroffenen Kunden oder Partnern. Der Recovery-Plan muss Raum für alle drei Möglichkeiten schaffen.
Ein gutes Tabletop-Szenario erzwingt diese Unterscheidung. Es sollte Aktionen enthalten, die leicht rückgängig zu machen sind, Aktionen mit nachgelagerten Abhängigkeiten und Aktionen, bei denen die Ausgabe des Agent eine menschliche Entscheidung beeinflusst hat. Genau dort werden verborgene operative Schwächen sichtbar: unklare Verantwortlichkeiten, nicht verknüpfte Datensätze, unzureichende Audit Trails und die Annahme, dass eine Integration reversibel sei, obwohl sie es nicht ist.
Machen Sie aus der Tabletop-Übung operative Disziplin
Eine Tabletop-Übung ist keine Präsentation über hypothetische Risiken. Sie ist ein zeitlich geführter Durchlauf, wie die Organisation auf einen realistischen Fehler reagieren würde – mit den tatsächlich beteiligten Menschen, Systemen und Entscheidungsrechten.
Beginnen Sie mit einem Production Agent, dessen Handlungen spürbare operative Konsequenzen haben. Definieren Sie ein Szenario, in dem der Agent verfügbar erscheint, aber nicht mehr vertrauenswürdig ist, etwa weil er veralteten Kontext nutzt oder einen nicht autorisierten Handlungspfad aufruft. Führen Sie den Incident dann entlang der vier Recovery-Fragen durch: Handlungen stoppen, Beweise sichern, einen bekannten sicheren Workflow wiederherstellen und betroffene Transaktionen abgleichen.
Die Übung sollte Reibung sichtbar machen, nicht verdecken. Wenn Teams auf undokumentiertes Wissen angewiesen sind, ist das ein Befund. Wenn niemand alle Tool-Berechtigungen des Agent identifizieren kann, ist das ein Befund. Wenn Business Owner nicht zwischen einer reversiblen Aktion und einem Fall mit manueller Behebung unterscheiden können, ist das ein Befund. Das sind keine Gründe, Production AI auf unbestimmte Zeit zu verschieben. Es ist die operative Arbeit, die nötig ist, um sie verantwortungsvoll zu betreiben.
Organisationen, die AI gut skalieren, warten nicht auf perfekte Autonomie. Sie bauen kontrollierte Wege für Fehler, Wiederherstellung und Lernen. Ein Agent, der gestoppt, untersucht, wiederhergestellt und abgeglichen werden kann, ist nicht nur sicherer. Geschäftsverantwortliche können ihm auch leichter wertvollere Arbeit anvertrauen.
Ein Fit Call hilft Ihnen, ein operatives Recovery-Modell für Production AI Agents zu definieren – bevor ein scheinbar gesunder Workflow einen Incident verursacht, den Ihre Teams weder rekonstruieren noch rückgängig machen können.
Hinweis zum Kontext: Dieser Artikel basiert auf Praxiserfahrung zur Gestaltung operativ resilienter AI-Agent-Workflows; externe Quellen wurden nicht zitiert.