En als een onderdeel niet beschikbaar is?

Concentratie verandert het risico-ontwerp

De Bank of England benadrukt dat afhankelijkheid van een klein aantal AI-aanbieders gevolgen kan hebben voor financiële dienstverlening wanneer deze aanbieders uitvallen, vooral als overstappen naar alternatieven moeilijk is. De analyse gaat over het financiële stelsel; ze toont niet aan dat elke gedeelde afhankelijkheid tot een systemisch falen zal leiden.

Voor het productteam kan de vraag heel concreet zijn: welke klantreizen zijn afhankelijk van deze opvraging, deze provider of dit model? Een overzicht van leveranciers volstaat niet als daaruit niet blijkt welke diensten stoppen met werken wanneer één onderdeel uitvalt.

Referentie: Bank of England · AI en financiële stabiliteit ↗

Een storing heeft niet altijd dezelfde gevolgen

Het opvragen van informatie kan worden uitgesteld. Een betaling kan nog op bevestiging wachten en mag niet worden herhaald zonder de status te controleren. Een mislukte ondertekening kan de afronding van de formalisering verhinderen, ook al blijven andere delen van het dossier beschikbaar.

Deze situaties vragen om verschillende reacties. Het contract moet zichtbaar maken of er sprake was van een weigering, onbeschikbaarheid, verloop of een onbekend resultaat. De interface volgt dat onderscheid, zodat de gebruiker niet wordt aangespoord een actie te herhalen die mogelijk al heeft plaatsgevonden.

Een alternatief is niet hetzelfde als een equivalent

Een adapter kan de eigenaardigheden van een provider bundelen, maar garandeert geen directe overstap. Een alternatief moet de benodigde velden leveren, de betekenis behouden en aan operationele eisen voldoen. Ook authenticatie, limieten, termijnen en effecten kunnen veranderen.

Een alternatief testen betekent de volledige klantreis controleren. Een technisch geldig antwoord kan een andere semantiek hebben. Bij de keuze van een leverancier moet je rekening houden met deze overstapkosten en met de werkelijke voorwaarden om een secundaire route te activeren.

Meet herstel als productwerk

Een nuttige oefening is één afhankelijkheid kiezen en kijken hoe de journey zich zonder die afhankelijkheid gedraagt. Wie wordt gewaarschuwd? Kan de case wachten? Welke actie wordt geblokkeerd? Hoe stroomt het werk terug in de flow zodra de service hersteld is?

Dit gesprek brengt architectuur, operatie en klantenservice dichter bij elkaar. Het doel is niet om te beloven dat er nooit iets misgaat, maar om onduidelijke statussen en geïmproviseerd herstel te voorkomen. Continuïteit vraagt om verantwoordelijken en criteria voor herstel, net zoals een functionaliteit acceptatiecriteria heeft.