Je AI werkt. Tot de verbinding wegvalt.

Een storing maakt afhankelijkheden zichtbaar

Op 29 september 2026 meldde OpenAI verhoogde foutpercentages bij ChatGPT, Codex en de API. De incidentpagina bevat ook een herstelupdate van 6 oktober. Dat is een actuele aanleiding om naar onze eigen afhankelijkheden te kijken; het bewijst niet dat alle klanten een week lang uitval ervoeren. [1]

Een AI-demonstratie laat meestal zien wat er gebeurt als alles meewerkt. Voor een bruikbaar bedrijfsproces telt ook wat er gebeurt wanneer een antwoord te laat komt, halverwege stopt of helemaal uitblijft. Welke werkzaamheden kunnen door? Wat blijft bewaard? En wie neemt het over? Die vragen horen bij het ontwerp, voordat de eerste gebruiker vastloopt.

Begin bij de taak die moet doorgaan

Neem een fictief voorbeeld: een medewerker laat AI een klantvraag samenvatten en een conceptantwoord voorbereiden. De medewerker controleert het voorstel en verstuurt het antwoord. Dit is een ontwerpsituatie, geen beschreven SBIT-klantproject.

Als de AI niet beschikbaar is, hoeft de klantvraag niet te verdwijnen. Bewaar de oorspronkelijke invoer, laat zien dat het concept ontbreekt en bied handmatige afhandeling aan. Spreek met de Product Owner en gebruikers af welke onderbreking acceptabel is. Een tekstsuggestie mag misschien wachten; een tijdgebonden aanvraag heeft een andere route nodig.

Leg die afspraak vast als observeerbaar gedrag. Bijvoorbeeld: bij het overschrijden van de afgesproken wachttijd blijft de invoer staan, verschijnt een begrijpelijke melding en kan een medewerker verder. Kies de wachttijd op basis van het werkproces en metingen, niet op basis van een willekeurig rond getal.

Opnieuw proberen vraagt een grens

Een tijdelijke fout kan een nieuwe poging rechtvaardigen. Microsoft beschrijft begrensde retries met passende wachttijden en waarschuwt dat agressief herhalen een overbelaste dienst verder kan belasten. Niet iedere fout is tijdelijk: een ongeldige aanvraag vraagt een correctie. [2]

Bepaal daarom één totaalbudget voor wachten en proberen. Controleer ook wat de gebruikte clientbibliotheek al opnieuw probeert. Anders kan een ogenschijnlijk bescheiden instelling op meerdere plekken samen veel meer aanvragen veroorzaken.

Bij aanhoudende fouten kan een circuit breaker nieuwe aanvragen tijdelijk tegenhouden en later beperkt herstel beproeven. Dat beschermt de rest van de applicatie tegen een falende afhankelijkheid. Het is een mogelijke ontwerpkeuze, geen verplicht onderdeel van iedere AI-integratie. [3]

Geen antwoord betekent niet: niets uitgevoerd

Zodra een AI-workflow ook acties uitvoert, wordt herstel gevoeliger. Stel dat een vervolgstap een ticket aanmaakt, maar de bevestiging verloren gaat. Blind herhalen kan dan twee tickets opleveren. AWS beschrijft hoe een afgesproken unieke aanvraagidentificatie helpt om herhaalde opdrachten zonder extra neveneffecten af te handelen. [4]

Een sleutel meesturen is op zichzelf niet genoeg: de ontvangende dienst moet het gedrag ondersteunen. Onderzoek bij een onbekende uitkomst eerst de verwerkingsstatus. Scheid bovendien het maken van een AI-voorstel van het uitvoeren van een zakelijke actie. Laat een afgebroken tekststroom nooit stilzwijgend doorgaan als compleet, goedgekeurd resultaat.

Test de onderbreking én de terugkeer

Wacht voor deze controles niet op een echte leveranciersstoring. Simuleer fouten aan de integratiegrens in een testomgeving. Combineer snelle, herhaalbare controles met beperkte integratietests tegen de echte dienst. Onderstaande scenario’s zijn een voorgestelde startset; kies en verdiep ze op basis van jullie risico’s.

1. Geen antwoord: laat de maximale wachttijd verstrijken. Controleer invoerbehoud, melding, begrensde pogingen en de aangeboden vervolgstap.
2. Afgebroken antwoord: onderbreek de stroom na enkele tekstfragmenten. Controleer dat het resultaat als onvolledig wordt behandeld en geen vervolgactie start.
3. Onbekende actie-uitkomst: voer de actie uit maar laat de bevestiging weg. Controleer dat herstel geen tweede zakelijke verwerking veroorzaakt.
4. Herstel na uitval: laat de dienst terugkomen terwijl een medewerker handmatig verder is gegaan. Controleer dat een laat AI-resultaat diens werk niet overschrijft.
5. Overname onder druk: bied meerdere uitgevallen taken aan. Controleer eigenaarschap, zichtbaarheid van de wachtrij en welke informatie de medewerker ontvangt.

Maak menselijke overname uitvoerbaar

“Een mens kijkt ernaar” is pas een werkbare afspraak als duidelijk is wie, wanneer en met welke informatie. Toon de oorspronkelijke vraag, de uitgevoerde stappen, de onzekere uitkomst en de reden voor overdracht. Geef medewerkers een manier om de taak af te ronden zonder dat de automatisering tegelijkertijd verdergaat.

Een ander model inzetten kan een optie zijn, maar vraagt eigen beoordeling van antwoordkwaliteit, gegevensverwerking en gedrag. Behandel die wissel niet als vanzelfsprekend gelijkwaardig. Soms is expliciet wachten of handmatig afhandelen de beter beheersbare keuze.

Bespreek dit vóór de volgende release

Kies één belangrijk AI-proces en doorloop de uitvalscenario’s samen met development, beheer, Quality Engineering en een gebruiker. Leg vast wie openstaande taken bewaakt en welk bewijs nodig is om herstel geslaagd te noemen. Kijk naast technische foutmeldingen ook naar achtergebleven werk en dubbele verwerking.

Voor SBIT begint kwaliteit bij zulke afspraken: welk risico willen we beheersen en welke feedback helpt ons beslissen? Een betrouwbare AI-toepassing heeft niet alleen een bruikbaar antwoord, maar ook een begrijpelijke en geteste route wanneer dat antwoord ontbreekt.