KI-Chatbot Incident Response: Degraded Mode, Rollback und Notfallplan

Ein Website-Chatbot kann technisch erreichbar sein und trotzdem einen Vorfall verursachen: Antworten werden plötzlich langsamer, Quellen fehlen, ein externes Modell liefert Fehler, ein Tool schreibt unvollständige Daten oder die Ausgabequalität fällt nur in einer Sprache ab. Wer in dieser Situation erst Zuständigkeiten und Abschaltwege sucht, verliert wertvolle Zeit. Ein Incident-Playbook legt deshalb vorab fest, welche Signale zählen, wer entscheidet und wie der Chatbot kontrolliert in einen sicheren Degraded Mode wechselt.

Das Ziel ist nicht, jeden Fehler durch maximale Verfügbarkeit zu verdecken. Ein eingeschränkter, ehrlicher Service ist oft besser als ein scheinbar normaler Bot, der unzuverlässige Aussagen macht. Dieser Leitfaden zeigt einen pragmatischen Aufbau für Website-, Support- und Produktteams: von der Erkennung über Fallback und Rollback bis zum Postmortem.

Was bei einem KI-Chatbot als Incident zählt

Ein Incident ist mehr als ein vollständiger Ausfall. Für Chatbots sollten Teams sowohl technische als auch fachliche Störungen berücksichtigen. Technische Fehler sind etwa erhöhte Latenz, Provider-Timeouts, fehlgeschlagene Abrufe aus der Wissensbasis oder defekte Integrationen. Fachliche Fehler betreffen beispielsweise stark steigende Fallback-Raten, falsche Quellenzuordnung, unerwartete Sprache, unzulässige Tool-Aufrufe oder Antworten außerhalb des vorgesehenen Themenbereichs.

Definieren Sie Schwellenwerte immer im Nutzungskontext. Ein kurzer Ausfall eines unverbindlichen FAQ-Bots ist anders zu bewerten als falsche Informationen in einem geschäftskritischen Prozess. Das NIST AI Risk Management Framework empfiehlt, den vorgesehenen Einsatz, die Grenzen menschlicher Aufsicht und die möglichen Folgen von Fehlern zu dokumentieren. Es nennt außerdem Mechanismen zum Übersteuern, Deaktivieren, Wiederherstellen und Kommunizieren von KI-Vorfällen als Teil des Betriebs.

Fehlerdomänen trennen, bevor Sie reagieren

Ein pauschales Signal „Chatbot funktioniert nicht“ führt selten zur richtigen Maßnahme. Zerlegen Sie den Dienst in überprüfbare Fehlerdomänen:

• Oberfläche und Netzwerk: Widget lädt nicht, Nachrichten werden nicht übertragen oder Antworten brechen ab.
• Modell und Provider: Timeouts, Ratenlimits, leere Ausgaben oder auffällige Qualitätsänderungen.
• Wissensbasis und Retrieval: Quellen sind nicht erreichbar, veraltet oder werden für bekannte Testfragen nicht gefunden.
• Tools und Integrationen: Schreibvorgänge, Terminabfragen oder Übergaben liefern Fehler beziehungsweise unbestätigte Ergebnisse.
• Safety und Berechtigungen: Schutzregeln greifen nicht, Eingaben beeinflussen interne Anweisungen oder ein Tool erhält zu weitreichende Rechte.
• Locale und Routing: Nur einzelne Sprachen, Themen oder Zielwege sind betroffen.

Diese Trennung verhindert, dass ein Team den gesamten Chatbot abschaltet, obwohl nur eine Integration betroffen ist. Umgekehrt darf ein grüner HTTP-Status keine fachliche Störung verdecken. Der Beitrag KI-Chatbot-Routing testen beschreibt, wie erwartete Wege und tatsächliche Ergebnisse systematisch verglichen werden.

Ein Health-Modell mit technischen und fachlichen Signalen

Gute Observability verbindet Metriken, Logs, Traces und Qualitätsprüfungen. Technische Basiswerte sind Erfolgsrate, Antwortzeit, Fehlerklassen, Queue-Länge und Verfügbarkeit wichtiger Abhängigkeiten. Für den KI-Teil kommen Retrieval-Treffer, Quellennutzung, Antwortabbrüche, Fallback-Quote, Handoff-Quote und Ergebnisse eines kleinen Golden Sets hinzu. Der Leitfaden zur Messung der KI-Chatbot-Antwortqualität zeigt, wie solche Testfälle gepflegt werden können.

Microsoft empfiehlt für Notfallstrategien eine ganzheitliche Überwachung, strukturierte Logs, zielgruppengerechte Dashboards und vor allem handlungsrelevante Alerts. Für einen Chatbot heißt das: Ein Alarm sollte nicht nur „Fehlerrate hoch“ melden, sondern betroffene Locale, Fehlerdomäne, Beginn, Ausmaß und den passenden Runbook-Einstieg nennen. Alarmieren Sie nur, wenn eine menschliche Handlung erforderlich ist; sonst entsteht Alarmmüdigkeit.

Speichern Sie für die Rekonstruktion nur die notwendigen Daten. Vollständige Gesprächsinhalte sind nicht automatisch erforderlich. Ereignisse, kurze pseudonyme Referenzen und kontrollierte Qualitätsstichproben können häufig ausreichen. Hinweise dazu bietet der Beitrag KI-Chatbot-Analytics datensparsam gestalten.

Schweregrade und klare Auslöser definieren

Eine einfache dreistufige Klassifizierung reicht für viele Teams:

1. Beobachten: leichte Abweichung ohne erkennbaren Nutzerschaden; zuständige Person prüft Trend und Stichprobe.
2. Eingeschränkt: ein relevanter Teil der Antworten, Locales oder Integrationen ist betroffen; Degraded Mode und interne Koordination werden aktiviert.
3. Kritisch: breite Nichterreichbarkeit, falsche geschäftskritische Aussagen, unkontrollierte Tool-Aktionen, Sicherheitsverdacht oder Datenrisiko; betroffene Funktionen werden sofort deaktiviert und der Incident formal geführt.

Notieren Sie pro Stufe messbare Auslöser, erlaubte Maßnahmen und die entscheidungsberechtigte Rolle. Kombinieren Sie Messwerte mit einer manuellen Eskalationsmöglichkeit: Support oder Redaktion können einen Vorfall früher erkennen als ein technischer Alarm. NIST SP 800-61 Revision 3 ordnet Incident Response in die laufende Risikosteuerung ein und betont Erkennung, Reaktion und Wiederherstellung als zusammenhängende Aufgaben.

Degraded Mode als Leiter statt als Ein-Aus-Schalter

Ein robuster Chatbot kennt mehrere kontrollierte Betriebszustände. Die konkrete Leiter hängt vom Anwendungsfall ab, kann aber so aussehen:

1. Normalbetrieb: freigegebene Wissensbasis, Modell und erlaubte Integrationen sind aktiv.
2. Eingeschränkte Antworten: der Bot beantwortet nur klar abgegrenzte Fragen aus verifizierten Quellen; unsichere Themen werden nicht improvisiert.
3. Tools deaktiviert: der Bot erklärt, dass eine Aktion derzeit nicht ausgeführt werden kann, und bestätigt keinen Erfolg ohne verlässliches Ergebnis.
4. Assistiver Modus: der Bot hilft nur bei Orientierung und verweist auf einen geprüften menschlichen Kontakt- oder Self-Service-Weg.
5. Offline-Modus: die Konversation wird geschlossen oder durch einen statischen, zugänglichen Hinweis ersetzt.

Jeder Übergang benötigt eine Bedingung, einen Verantwortlichen und einen getesteten Rückweg. Vermeiden Sie Formulierungen wie „erledigt“ oder „gebucht“, wenn eine abhängige Aktion nicht bestätigt wurde. Bei einer Übergabe müssen Kontextumfang, Datenschutz und Erreichbarkeit geklärt sein. Dazu passt der Leitfaden Human Handoff im KI-Chatbot.

Rollback-Kriterien vor dem nächsten Release festlegen

Ein Rollback ist sinnvoll, wenn ein zeitlicher Zusammenhang mit einer Änderung besteht und die vorherige Version nachweislich einen sichereren Zustand bietet. Rollback-fähig sollten nicht nur Anwendungsversionen sein, sondern auch Prompt-Konfigurationen, Wissensbasis-Stände, Routingregeln, Tool-Berechtigungen und Modellzuordnungen. Halten Sie fest, welche Komponenten gemeinsam zurückgesetzt werden müssen, damit keine inkompatible Mischung entsteht.

Definieren Sie außerdem Abbruchkriterien. Wenn ein Rollback die Werte nicht verbessert, darf das Team nicht wiederholt dieselbe Maßnahme ausführen. Dann folgt der nächste Degraded Mode oder die Isolation einer Abhängigkeit. Google beschreibt in seiner SRE-Praxis schnelle Rollbacks als legitime Incident-Maßnahme, verlangt aber zugleich strukturierte Koordination und eine fortlaufende Aufzeichnung der Entscheidungen.

Vor dem Zurückschalten in den Normalbetrieb braucht es einen Recovery-Check: technische Gesundheitswerte stabil, Golden-Set-Stichprobe bestanden, betroffene Locale geprüft, Tools mit ungefährlichen Testfällen validiert und Handoff-Pfad erreichbar. Erst danach wird der Traffic kontrolliert erhöht.

Das Incident-Playbook für die ersten 30 Minuten

Ein kurzes Runbook ist im Ernstfall nützlicher als eine lange allgemeine Richtlinie. Es kann folgende Reihenfolge vorgeben:

1. Alarm oder Supportmeldung bestätigen und Beginn, betroffene Funktionen sowie Nutzerauswirkung notieren.
2. Incident-Schweregrad bestimmen und eine verantwortliche Einsatzleitung benennen.
3. Weitere unkoordinierte Änderungen stoppen; letzte Releases, Prompt-, Wissens- und Routingänderungen erfassen.
4. Sicheren Degraded Mode aktivieren und riskante Tools oder Antworten begrenzen.
5. Technische und fachliche Signale vergleichen; betroffene Locales und Abhängigkeiten isolieren.
6. Rollback oder Workaround anhand der vorab definierten Kriterien ausführen.
7. Support, Produktverantwortliche und weitere Betroffene mit bestätigten Fakten informieren.
8. Nach jeder Maßnahme Wirkung prüfen und Zeitstempel, Ergebnis sowie nächste Entscheidung dokumentieren.

Google SRE fasst Incident Management als Koordination, Kommunikation und Kontrolle zusammen. Klare Rollen verhindern, dass mehrere Personen gleichzeitig widersprüchliche Änderungen vornehmen. Kleine Teams können Rollen zusammenlegen; entscheidend ist, dass eine Person die Lage führt, eine die technische Mitigation verantwortet und jemand verlässliche Statusinformationen pflegt.

Kommunikation ohne Spekulation

Statusmeldungen sollten beobachtete Auswirkungen, betroffene Funktionen, aktive Ersatzwege und den Zeitpunkt des nächsten Updates enthalten. Eine ungeprüfte Ursache oder voreilige Wiederherstellungszeit gehört nicht hinein. Wenn nur eine Sprache oder Integration betroffen ist, sagen Sie das präzise. Wenn der Umfang noch unklar ist, benennen Sie diese Unsicherheit.

Für sensible Vorfälle gelten zusätzlich die internen Sicherheits-, Datenschutz- und gegebenenfalls Meldeprozesse. Das normale Support-Playbook ersetzt diese nicht. Bei Verdacht auf Prompt Injection, Datenabfluss oder unzulässige Tool-Aktionen sollte das zuständige Sicherheitsteam früh einbezogen werden. Der Beitrag Prompt Injection bei Website-Chatbots behandelt passende technische Schutzschichten.

Postmortem und Übungen schließen den Kreislauf

Nach der Wiederherstellung dokumentiert ein blameless Postmortem Auswirkung, Zeitleiste, Erkennung, Mitigation, beitragende Faktoren und konkrete Folgemaßnahmen. Google SRE empfiehlt, Kriterien für ein Postmortem schon vor dem Incident festzulegen, etwa nutzersichtbare Degradation, Datenverlust, manuelles Rollback oder ein Versagen des Monitorings. Der Fokus liegt auf Systemen und Entscheidungen, nicht auf Schuldzuweisung.

Jede Maßnahme braucht Verantwortliche, Termin und überprüfbares Ergebnis. Typische Verbesserungen sind ein neuer Alarm, eine engere Tool-Berechtigung, ein zusätzlicher Golden-Set-Fall, eine bessere Statusvorlage oder ein getesteter Offline-Hinweis. Mindestens ebenso wichtig sind kurze Übungen: Simulieren Sie einen Provider-Timeout, eine nicht erreichbare Wissensbasis und eine fehlerhafte Locale. Prüfen Sie, ob Zuständigkeiten, Degraded Mode, Kommunikation und Recovery-Check tatsächlich funktionieren.

Checkliste für die Incident Readiness

• Technische und fachliche Incident-Signale sind getrennt definiert.
• Schweregrade besitzen messbare Auslöser und eindeutige Entscheidungsrechte.
• Für Modell, Wissensbasis, Tools, Routing und Locales existieren isolierbare Fallbacks.
• Der Chatbot bestätigt niemals eine Aktion ohne verlässliches Ergebnis.
• Degraded Mode und Offline-Hinweis wurden auf Desktop, Mobilgeräten und mit Tastatur getestet.
• Rollback umfasst zusammengehörige Konfigurationen und hat Abbruchkriterien.
• Handoff- und Kommunikationswege sind geprüft und enthalten nur verifizierte Kontaktdaten.
• Recovery verlangt stabile Metriken, Qualitätsstichprobe und kontrolliertes Hochfahren.
• Postmortem-Maßnahmen erhalten Verantwortliche, Frist und Wirksamkeitsprüfung.
• Das Team übt mindestens mehrere realistische Fehlerdomänen.

Quellen

• NIST: SP 800-61 Revision 3 zu Incident Response
• NIST AI Risk Management Framework: Core
• Microsoft Well-Architected: Emergency Response Strategy
• Google SRE Workbook: Incident Response
• Google SRE: Postmortem Culture

Incident Readiness macht einen Chatbot nicht fehlerfrei. Sie sorgt dafür, dass ein Team Abweichungen früh erkennt, riskante Funktionen begrenzt und Nutzer auf einen verlässlichen Weg führt. ChatReact kann dabei als Teil eines klar dokumentierten Website-, Wissens- und Handoff-Prozesses eingesetzt werden; Zuständigkeiten, Grenzwerte und Notfallwege müssen zum jeweiligen Unternehmen passen.