AI chatbot incident response: Degraded mode, rollback a havarijní plán

Webový chatbot může být technicky dostupný, a přesto způsobit incident: odpovědi se náhle zpomalí, chybějí zdroje, externí model vrací chyby, nástroj zapisuje neúplná data nebo kvalita výstupu klesne jen v jednom jazyce. Kdo v takové situaci teprve hledá odpovědné osoby a způsoby vypnutí, ztrácí drahocenný čas. Incident playbook proto předem určuje, které signály jsou klíčové, kdo rozhoduje a jak chatbot řízeně přejde do bezpečného degraded mode.

Cílem není zakrývat každou chybu maximální dostupností. Omezená, ale poctivá služba je často lepší než zdánlivě normální bot, který poskytuje nespolehlivé informace. Tento průvodce ukazuje pragmatickou strukturu pro webové, podpůrné a produktové týmy: od detekce přes fallback a rollback až po postmortem.

Co se u AI chatbota počítá jako incident

Incident je více než jen úplný výpadek. U chatbotů by týmy měly brát v úvahu jak technické, tak věcné poruchy. Technickými chybami jsou například zvýšená latence, vypršení časových limitů poskytovatele (timeouts), neúspěšné načítání ze znalostní báze nebo nefunkční integrace. Věcné chyby se týkají například prudce rostoucí míry fallbacku, chybného přiřazení zdrojů, neočekávaného jazyka, neoprávněného volání nástrojů nebo odpovědí mimo vyhrazenou oblast témat.

Prahové hodnoty definujte vždy v kontextu použití. Krátký výpadek nezávazného FAQ bota je třeba posuzovat jinak než chybné informace v procesech kritických pro podnikání. Rámec NIST AI Risk Management Framework doporučuje dokumentovat zamýšlené použití, limity lidského dohledu a možné následky chyb. Jako součást provozu uvádí také mechanismy pro manuální zásah (override), deaktivaci, obnovu a komunikaci incidentů AI.

Oddělte chybové domény dříve, než začnete reagovat

Paušální signál „chatbot nefunguje“ málokdy vede ke správnému opatření. Rozložte službu na ověřitelné chybové domény:

• Rozhraní a síť: Widget se nenačítá, zprávy se nepřenášejí nebo odpovědi se přerušují.
• Model a poskytovatel: Timeouty, rychlostní limity (rate limits), prázdné výstupy nebo nápadné změny kvality.
• Znalostní báze a retrieval: Zdroje jsou nedostupné, zastaralé nebo se nenacházejí pro známé testovací dotazy.
• Nástroje a integrace: Zápisy, dotazy na termíny nebo předání vykazují chyby, případně nepotvrzené výsledky.
• Bezpečnost a oprávnění: Ochranná pravidla nefungují, vstupy ovlivňují interní instrukce nebo nástroj získá příliš rozsáhlá práva.
• Lokalizace a směrování: Zasaženy jsou pouze jednotlivé jazyky, témata nebo cílové cesty.

Toto oddělení zabraňuje tomu, aby tým vypnul celého chatbota, když je zasažena pouze jedna integrace. Naopak zelený stav HTTP nesmí zakrývat věcnou poruchu. Článek Testování směrování AI chatbota popisuje, jak systematicky porovnávat očekávané cesty a skutečné výsledky.

Model zdraví služby s technickými a věcnými signály

Dobrá pozorovatelnost (observability) kombinuje metriky, logy, trasy (traces) a kontroly kvality. Technickými základními hodnotami jsou míra úspěšnosti, doba odezvy, třídy chyb, délka fronty a dostupnost klíčových závislostí. Pro část AI se přidávají zásahy retrievalu, využití zdrojů, přerušení odpovědí, míra fallbacku, míra předání (handoff) a výsledky malé sady Golden Set. Průvodce Měření kvality odpovědí AI chatbota ukazuje, jak tyto testovací případy spravovat.

Společnost Microsoft doporučuje pro havarijní strategie celostní monitorování, strukturované logy, řídicí panely uzpůsobené cílovým skupinám a především alerty s praktickou hodnotou. Pro chatbota to znamená: Alarm by neměl hlásit pouze „vysoká chybovost“, ale navíc uvést dotčenou lokalizaci, chybovou doménu, začátek, rozsah a odpovídající vstupní bod v runbooku. Spouštějte alarm pouze tehdy, když je vyžadován lidský zásah; jinak vzniká únava z alarmů.

Pro rekonstrukci ukládejte pouze nezbytná data. Úplný obsah konverzací není automaticky nutný. Často mohou stačit události, krátké pseudonymní reference a kontrolované vzorky kvality. Tipům na toto téma se věnuje článek Datově úsporná analytika AI chatbotů.

Definujte úrovně závažnosti a jasné spouštěče

Jednoduchá tříúrovňová klasifikace mnoha týmům postačuje:

1. Sledovat: nepatrná odchylka bez zjevného dopadu na uživatele; odpovědná osoba kontroluje trend a vzorek.
2. Omezeno: zasažena je relevantní část odpovědí, lokalizací nebo integrací; aktivuje se degraded mode a interní koordinace.
3. Kritické: rozsáhlá nedostupnost, chybné výpovědi kritické pro podnikání, nekontrolované akce nástrojů, bezpečnostní podezření nebo riziko úniku dat; dotčené funkce se okamžitě deaktivují a incident je oficiálně řízen.

U každé úrovně zaznamenejte měřitelné spouštěče, povolená opatření a roli s rozhodovací pravomocí. Kombinujte naměřené hodnoty s možností manuální eskalace: podpora nebo redakce mohou incident odhalit dříve než technický alarm. Dokument NIST SP 800-61 Revision 3 zařazuje incident response do průběžného řízení rizik a zdůrazňuje detekci, reakci a obnovu jako propojené úkoly.

Degraded mode jako žebřík namísto vypínače Zap/Vyp

Robustní chatbot zná několik kontrolovaných provozních stavů. Konkrétní žebřík závisí na případu použití, ale může vypadat takto:

1. Běžný provoz: schválená znalostní báze, model a povolené integrace jsou aktivní.
2. Omezené odpovědi: bot odpovídá pouze na jasně vymezené dotazy z ověřených zdrojů; u nejistých témat neimprovizuje.
3. Deaktivované nástroje: bot vysvětlí, že akci nelze v současnosti provést, a nepotvrdí úspěch bez spolehlivého výsledku.
4. Asistenční režim: bot pomáhá pouze s orientací a odkazuje na prověřený lidský kontakt nebo samoobslužnou cestu.
5. Offline režim: konverzace se ukončí nebo nahradí statickým, přístupným upozorněním.

Každý přechod vyžaduje podmínku, odpovědnou osobu a otestovanou zpětnou cestu. Vyhněte se formulacím jako „vyřízeno“ nebo „rezervováno“, pokud závislá akce nebyla potvrzena. Při předání musí být vyjasněn rozsah kontextu, ochrana osobních údajů a dostupnost. K tomu se hodí průvodce Human Handoff u AI chatbota.

Stanovte kritéria pro rollback před dalším vydáním

Rollback má smysl tehdy, existuje-li časová souvislost se změnou a předchozí verze prokazatelně nabízí bezpečnější stav. Schopnost rollbacku by se neměla týkat jen verzí aplikace, ale také konfigurací promptů, stavů znalostní báze, pravidel směrování, oprávnění nástrojů a přiřazení modelů. Zaznamenejte, které komponenty je nutné vrátit zpět společně, aby nevznikla nekompatibilní směs.

Definujte také kritéria pro přerušení. Pokud rollback nezlepší hodnoty, nesmí tým opakovaně provádět totéž opatření. Následuje další degraded mode nebo izolace závislosti. Google ve své praxi SRE popisuje rychlé rollbacky jako legitimní opatření při incidentu, ale zároveň vyžaduje strukturovanou koordinaci a průběžný záznam rozhodnutí.

Před přepnutím zpět do běžného provozu je nutná kontrola obnovy (recovery check): stabilní technické zdravotní ukazatele, úspěšný test vzorku Golden Set, zkontrolovaná dotčená lokalizace, ověřené nástroje pomocí bezpečných testovacích případů a dostupná cesta k předání lidem. Teprve poté se provoz kontrolovaně zvyšuje.

Incident playbook pro prvních 30 minut

Stručný runbook je v případě nouze užitečnější než dlouhá obecná směrnice. Může určovat následující pořadí:

1. Potvrďte alarm nebo hlášení podpory a zaznamenejte začátek, dotčené funkce a dopad na uživatele.
2. Určete závažnost incidentu a jmenujte odpovědného vedoucího zásahu (incident command).
3. Zastavte další nekoordinované změny; zaznamenejte poslední vydání, změny promptů, znalostí a směrování.
4. Aktivujte bezpečný degraded mode a omezte rizikové nástroje nebo odpovědi.
5. Porovnejte technické a věcné signály; izolujte dotčené lokalizace a závislosti.
6. Proveďte rollback nebo workaround na základě předem definovaných kritérií.
7. Informujte podporu, produktové manažery a další dotčené strany potvrzenými fakty.
8. Po každém opatření zkontrolujte účinek a zdokumentujte časové razítko, výsledek a další rozhodnutí.

Google SRE shrnuje řízení incidentů jako koordinaci, komunikaci a kontrolu. Jasně vymezené role brání tomu, aby několik lidí provádělo současně protichůdné změny. Malé týmy mohou role sloučit; rozhodující je, aby jedna osoba řídila situaci, druhá odpovídala za technickou nápravu a někdo udržoval spolehlivé stavové informace.

Komunikace bez spekulací

Stavové zprávy by měly obsahovat pozorované dopady, dotčené funkce, aktivní náhradní cesty a čas příští aktualizace. Neověřená příčina nebo předčasný odhad doby obnovy do nich nepatří. Pokud je zasažen pouze jeden jazyk nebo integrace, uveďte to přesně. Je-li rozsah dosud nejasný, pojmenujte tuto nejistotu.

Pro citlivé incidenty platí navíc interní bezpečnostní procesy, procesy ochrany osobních údajů a případně ohlašovací povinnosti. Běžný support playbook je nenahrazuje. Při podezření na prompt injection, únik dat nebo neoprávněné akce nástrojů by měl být včas zapojen příslušný bezpečnostní tým. Článek Prompt injection u webových chatbotů se zabývá odpovídajícími technickými vrstvami ochrany.

Postmortem a cvičení uzavírají kruh

Po obnově zdokumentuje bezvinné (blameless) postmortem dopad, časovou osu, detekci, mitigaci, přispívající faktory a konkrétní následná opatření. Google SRE doporučuje stanovit kritéria pro postmortem ještě před incidentem, například degradaci viditelnou pro uživatele, ztrátu dat, manuální rollback nebo selhání monitorování. Zaměření spočívá na systémech a rozhodnutích, nikoli na hledání viníka.

Každé opatření vyžaduje odpovědnou osobu, termín a ověřitelný výsledek. Typickými vylepšeními jsou nový alarm, přísnější oprávnění pro nástroje, dodatečný případ pro Golden Set, lepší šablona stavových zpráv nebo otestované upozornění pro offline režim. Nejméně stejně důležitá jsou krátká cvičení: simulujte timeout poskytovatele, nedostupnou znalostní bázi a chybnou lokalizaci. Zkontrolujte, zda odpovědnosti, degraded mode, komunikace a recovery check skutečně fungují.

Kontrolní seznam pro incident readiness

• Technické a věcné signály incidentů jsou definovány odděleně.
• Úrovně závažnosti mají měřitelné spouštěče a jednoznačná rozhodovací práva.
• Pro model, znalostní bázi, nástroje, směrování a lokalizace existují izolovatelná záložní řešení.
• Chatbot nikdy nepotvrzuje akci bez spolehlivého výsledku.
• Degraded mode a offline upozornění byly otestovány na desktopu, mobilních zařízeních i s klávesnicí.
• Rollback zahrnuje související konfigurace a má kritéria pro přerušení.
• Cesty pro handoff a komunikaci jsou prověřené a obsahují pouze ověřené kontaktní údaje.
• Obnova vyžaduje stabilní metriky, vzorek kvality a kontrolovaný náběh.
• Opatření z postmortemu mají určenou odpovědnou osobu, lhůtu a kontrolu účinnosti.
• Tým si nacvičuje nejméně několik realistických chybových domén.

Zdroje

• NIST: SP 800-61 Revision 3 k 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 nečiní chatbota bezchybným. Zajišťuje však, aby tým včas odhalil odchylky, omezil rizikové funkce a navedl uživatele na spolehlivou cestu. ChatReact lze přitom nasadit jako součást jasně zdokumentovaného procesu pro web, znalosti a handoff; odpovědnosti, prahové hodnoty a nouzové cesty však musí odpovídat konkrétní společnosti.