AI-chatbot incident response: degraded mode, rollback en noodplan

Een website-chatbot kan technisch bereikbaar zijn en toch een incident veroorzaken: antwoorden worden plotseling trager, bronnen ontbreken, een extern model geeft fouten, een tool schrijft onvolledige gegevens weg of de uitvoerkwaliteit daalt in slechts één taal. Wie in zo'n situatie pas gaat zoeken naar verantwoordelijken en uitschakelprocedures, verliest waardevolle tijd. Een incident-playbook legt daarom vooraf vast welke signalen tellen, wie beslist en hoe de chatbot gecontroleerd overschakelt naar een veilige degraded mode.

Het doel is niet om elke fout te verbergen achter maximale beschikbaarheid. Een beperkte, eerlijke dienstverlening is vaak beter dan een schijnbaar normale bot die onbetrouwbare uitspraken doet. Deze handleiding toont een pragmatische opzet voor website-, support- en productteams: van detectie via fallback en rollback tot de post-mortem.

Wat bij een AI-chatbot als incident telt

Een incident is meer dan een volledige uitval. Voor chatbots moeten teams rekening houden met zowel technische als functionele storingen. Technische fouten zijn bijvoorbeeld een hogere latentie, provider-timeouts, mislukte zoekopdrachten in de kennisbank of defecte integraties. Functionele fouten betreffen bijvoorbeeld sterk stijgende fallback-percentages, verkeerde bronvermelding, een onverwachte taal, ongeoorloofde tool-calls of antwoorden buiten het beoogde onderwerpsgebied.

Definieer drempelwaarden altijd in de gebruikscontext. Een korte uitval van een vrijblijvende FAQ-bot moet anders worden beoordeeld dan onjuiste informatie in een bedrijfskritisch proces. Het NIST AI Risk Management Framework beveelt aan om het beoogde gebruik, de grenzen van menselijk toezicht en de mogelijke gevolgen van fouten te documenteren. Het noemt bovendien mechanismen voor het handmatig overnemen, uitschakelen, herstellen en communiceren van AI-incidenten als onderdeel van de bedrijfsvoering.

Foutdomeinen scheiden voordat u reageert

Een algemeen signaal 'chatbot werkt niet' leidt zelden tot de juiste maatregel. Verdeel de dienst in controleerbare foutdomeinen:

• Interface en netwerk: widget laadt niet, berichten worden niet verzonden of antwoorden breken af.
• Model en provider: timeouts, rate limits, lege uitvoer of opvallende kwaliteitsveranderingen.
• Kennisbank en retrieval: bronnen zijn niet bereikbaar, verouderd of worden voor bekende testvragen niet gevonden.
• Tools en integraties: schrijfacties, afspraakverzoeken of overdrachten leveren fouten c.q. onbevestigde resultaten op.
• Safety en rechten: beveiligingsregels grijpen niet in, invoer beïnvloedt interne instructies of een tool krijgt te ruime rechten.
• Locale en routing: slechts enkele talen, onderwerpen of doelroutes zijn getroffen.

Deze scheiding voorkomt dat een team de gehele chatbot uitschakelt terwijl slechts één integratie getroffen is. Omgekeerd mag een groene HTTP-status geen functionele storing verbergen. Het artikel KI-Chatbot-Routing testen beschrijft hoe verwachte routes en daadwerkelijke resultaten systematisch worden vergeleken.

Een health-model met technische en functionele signalen

Goede observabiliteit combineert metrieken, logs, traces en kwaliteitscontroles. Technische basiswaarden zijn slagingspercentage, responstijd, foutklassen, wachtrijlengte en beschikbaarheid van belangrijke afhankelijkheden. Voor het AI-gedeelte komen daar retrieval-treffers, brongebruik, afgebroken antwoorden, fallback-ratio, handoff-ratio en resultaten van een kleine golden set bij. De handleiding voor het meten van de AI-chatbot-antwoordkwaliteit laat zien hoe dergelijke testcases onderhouden kunnen worden.

Microsoft beveelt voor noodstrategieën een holistische monitoring, gestructureerde logs, doelgroepgerichte dashboards en vooral actiegerichte alerts aan. Voor een chatbot betekent dit: een melding moet niet alleen 'foutpercentage hoog' aangeven, maar ook de getroffen locale, het foutdomein, de starttijd, de omvang en de juiste runbook-ingang vermelden. Alarmeer alleen als menselijk handelen vereist is; anders ontstaat er alert-moeheid.

Sla voor de reconstructie alleen de noodzakelijke gegevens op. Volledige gespreksinhoud is niet automatisch vereist. Gebeurtenissen, korte pseudonieme referenties en gecontroleerde kwaliteitssteekproeven zijn vaak voldoende. Tips hiervoor vindt u in het artikel datazuinige AI-chatbot-analytics opzetten.

Ernstniveaus en duidelijke triggers definiëren

Een eenvoudige driedelige classificatie is voor veel teams voldoende:

1. Monitoren: lichte afwijking zonder aantoonbare gebruikersschade; verantwoordelijke persoon controleert trend en steekproef.
2. Beperkt: een relevant deel van de antwoorden, locales of integraties is getroffen; degraded mode en interne coördinatie worden geactiveerd.
3. Kritiek: brede onbereikbaarheid, onjuiste bedrijfskritische uitspraken, ongecontroleerde tool-acties, vermoeden van beveiligingslek of datarisico; getroffen functies worden direct uitgeschakeld en het incident wordt formeel afgehandeld.

Leg per niveau meetbare triggers, toegestane maatregelen en de beslissingsbevoegde rol vast. Combineer meetwaarden met een handmatige escalatiemogelijkheid: support of redactie kunnen een incident sneller opmerken dan een technisch alarm. NIST SP 800-61 Revision 3 plaatst incident response binnen het doorlopende risicobeheer en benadrukt detectie, respons en herstel als samenhangende taken.

Degraded mode als een ladder in plaats van een aan-uitschakelaar

Een robuuste chatbot kent meerdere gecontroleerde bedrijfstoestanden. De concrete ladder hangt af van de toepassing, maar kan er zo uitzien:

1. Normale werking: goedgekeurde kennisbank, model en toegestane integraties zijn actief.
2. Beperkte antwoorden: de bot beantwoordt alleen duidelijk afgebakende vragen uit geverifieerde bronnen; over onzekere onderwerpen wordt niet geïmproviseerd.
3. Tools uitgeschakeld: de bot legt uit dat een actie momenteel niet kan worden uitgevoerd en bevestigt geen succes zonder betrouwbaar resultaat.
4. Assistieve modus: de bot helpt alleen bij oriëntatie en verwijst naar een gecontroleerd menselijk contact- of self-servicekanaal.
5. Offline-modus: het gesprek wordt gesloten of vervangen door een statische, toegankelijke melding.

Elke overgang vereist een voorwaarde, een verantwoordelijke en een geteste weg terug. Vermijd formuleringen als 'afgerond' of 'geboekt' wanneer een afhankelijke actie niet is bevestigd. Bij een overdracht moeten contextomvang, privacy en bereikbaarheid geregeld zijn. Hierop sluit de handleiding human handoff in de AI-chatbot aan.

Rollback-criteria vastleggen vóór de volgende release

Een rollback is zinvol als er een temporeel verband is met een wijziging en de vorige versie aantoonbaar een veiligere status biedt. Niet alleen applicatieversies moeten rollback-fähig zijn, maar ook prompt-configuraties, kennisbankversies, routingregels, tool-michtigingen en model-toewijzingen. Leg vast welke componenten samen moeten worden teruggezet om te voorkomen dat er een incompatibele mix ontstaat.

Definieer bovendien afbreekcriteria. Als een rollback de waarden niet verbetert, mag het team niet herhaaldelijk dezelfde maatregel uitvoeren. Dan volgt de volgende degraded mode of de isolatie van een afhankelijkheid. Google beschrijft in zijn SRE-praktijk snelle rollbacks als een legitieme incidentmaatregel, maar vereist tegelijkertijd een gestructureerde coördinatie en een continue vastlegging van beslissingen.

Vóór het terugschakelen naar de normale werking is een recovery-check nodig: technische health-waarden stabiel, golden set-steekproef geslaagd, getroffen locale gecontroleerd, tools met ongevaarlijke testcases gevalideerd en handoff-pad bereikbaar. Pas danach wordt het verkeer gecontroleerd opgevoerd.

Het incident-playbook voor de eerste 30 minuten

Een kort runbook is in geval van nood nuttiger dan een lange algemene richtlijn. Het kan de volgende volgorde voorschrijven:

1. Alarm of supportmelding bevestigen en starttijd, getroffen functies en impact op gebruikers noteren.
2. Ernstniveau van het incident bepalen en een verantwoordelijke incident manager aanwijzen.
3. Verdere ongecoördineerde wijzigingen stoppen; laatste releases, prompt-, kennis- en routingwijzigingen in kaart brengen.
4. Veilige degraded mode activeren en risicovolle tools of antwoorden beperken.
5. Technische en functionele signalen vergelijken; getroffen locales en afhankelijkheden isoleren.
6. Rollback of workaround uitvoeren aan de hand van vooraf gedefinieerde criteria.
7. Support, productverantwoordelijken en overige betrokkenen informeren met geverifieerde feiten.
8. Na elke maatregel het effect controleren en tijdstempel, resultaat en volgende beslissing documenteren.

Google SRE vat incident management samen als coördinatie, communicatie en controle. Duidelijke rollen voorkomen dat meerdere personen tegelijkertijd tegenstrijdige wijzigingen doorvoeren. Kleine teams kunnen rollen samenvoegen; doorslaggevend is dat één persoon de leiding heeft, één verantwoordelijk is voor de technische mitigatie en iemand betrouwbare statusinformatie bijhoudt.

Communicatie zonder speculatie

Statusmeldingen moeten waargenomen effecten, getroffen functies, actieve alternatieve routes en het tijdstip van de volgende update bevatten. Een niet-gecontroleerde oorzaak of voortijdige hersteltijd hoort er niet in thuis. Als slechts één taal of integratie is getroffen, meldt u dat precies. Als de omvang nog onduidelijk is, benoemt u die onzekerheid.

Voor gevoelige incidenten gelden bovendien de interne veiligheids-, privacy- en eventuele meldingsprocessen. Het normale support-playbook vervangt deze niet. Bij het vermoeden van prompt injection, datalekken of ongeoorloofde tool-acties moet het verantwoordelijke securityteam vroegtijdig worden ingeschakeld. Het artikel prompt injection bij website-chatbots behandelt passende technische beveiligingslagen.

Post-mortem en oefeningen sluiten de cirkel

Na het herstel documenteert een blameless post-mortem de impact, tijdlijn, detectie, mitigatie, bijdragende factoren en concrete vervolgmaatregelen. Google SRE beveelt aan om criteria voor een post-mortem al vóór het incident vast te leggen, zoals voor gebruikers zichtbare kwaliteitsvermindering, dataverlies, een handmatige rollback of het falen van de monitoring. De focus ligt op systemen en beslissingen, niet op schuldzuivering.

Elke maatregel heeft een verantwoordelijke, een deadline en een controleerbaar resultaat nodig. Typische verbeteringen zijn een nieuw alarm, een striktere tool-machtiging, een extra golden set-case, een betere statustemplate of een geteste offline-melding. Minstens even belangrijk zijn korte oefeningen: simuleer een provider-timeout, een onbereikbare kennisbank en een foutieve locale. Controleer of verantwoordelijkheden, degraded mode, communicatie en de recovery-check daadwerkelijk werken.

Checklist voor incident readiness

• Technische en functionele incidentsignalen zijn gescheiden gedefinieerd.
• Ernstniveaus hebben meetbare triggers en duidelijke beslissingsrechten.
• Voor model, kennisbank, tools, routing en locales bestaan isoleerbare fallbacks.
• De chatbot bevestigt nooit een actie zonder betrouwbaar resultaat.
• Degraded mode en offline-melding zijn getest op desktop, mobiele apparaten en met het toetsenbord.
• Rollback omvat bijbehorende configuraties en beschikt over afbreekcriteria.
• Handoff- en communicatiewegen zijn gecontroleerd en bevatten alleen geverifieerde contactgegevens.
• Herstel vereist stabiele metrieken, een kwaliteitssteekproef en een gecontroleerde opschaling.
• Post-mortem-maatregelen krijgen een verantwoordelijke, een termijn en een doeltreffendheidscontrole.
• Het team oefent minstens meerdere realistische foutdomeinen.

Bronnen

• NIST: SP 800-61 Revision 3 over 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 maakt een chatbot niet foutloos. Het zorgt ervoor dat een team afwijkingen vroegtijdig herkent, risicovolle functies beperkt en gebruikers naar een betrouwbare route leidt. ChatReact kan hierbij worden ingezet als onderdeel van een duidelijk gedocumenteerd website-, kennis- en handoff-proces; verantwoordelijkheden, grenswaarden en noodroutes moeten passen bij de desbetreffende organisatie.