Fallback-ketens: wat doet je systeem als de provider eruit ligt?

Als je AI-systeem afhankelijk is van één externe provider, is die provider een single point of failure. Valt de API uit, loopt de latency sterk op of worden antwoorden plotseling onbetrouwbaar, dan kan een functie die technisch gezien maar één onderdeel van je applicatie is alsnog het hele proces blokkeren. Een fallback-keten voorkomt dat door vooraf vast te leggen wat het systeem doet wanneer de primaire route niet meer bruikbaar is.

Zo'n keten kan bijvoorbeeld lopen van een primaire LLM-provider naar een secundaire provider of een ander model, daarna eventueel naar een lokaal model en uiteindelijk naar een statische fallback of duidelijke foutmelding. Het doel is niet om koste wat kost altijd een AI-antwoord te produceren, maar om gecontroleerd te degraderen: de belangrijkste functionaliteit blijft beschikbaar zolang dat verantwoord kan.

Waarom één AI-provider een single point of failure is

Een LLM-API voelt vaak als een gewone infrastructuurcomponent: je stuurt een request en krijgt een response terug. Maar achter die interface zit een externe dienst waarop je geen volledige controle hebt. Storingen, capaciteitsproblemen, netwerkproblemen, rate limits, gewijzigde veiligheidsfilters en afwijkend modelgedrag kunnen allemaal invloed hebben op je applicatie.

Dat risico wordt groter wanneer AI midden in een bedrijfsproces zit. Een chatbot die tijdelijk niet antwoordt is vervelend. Een documentworkflow die geen contracten meer kan verwerken, een interne zoekfunctie die geen antwoorden meer geeft of een agent die geen volgende stap kan bepalen, kan operationeel veel ernstiger zijn.

Het probleem is bovendien niet beperkt tot volledige downtime. Een provider kan bereikbaar zijn maar trager reageren dan normaal. Een model kan geldige responses teruggeven die inhoudelijk slechter zijn. Of een API kan sommige requests wel en andere niet verwerken. Alleen controleren of een endpoint HTTP 200 teruggeeft is daarom onvoldoende.

Wat een fallback-keten concreet is

Een fallback-keten is een vooraf bepaalde reeks alternatieven die het systeem probeert wanneer de voorkeursroute niet voldoet aan bepaalde voorwaarden.

Een eenvoudige keten kan er conceptueel zo uitzien: primaire provider → secundaire provider of model → lokaal model → statische fallback of foutmelding.

Die stappen hoeven niet allemaal aanwezig te zijn. Voor een relatief eenvoudige toepassing kan één alternatieve provider voldoende zijn. Voor bedrijfskritische processen kan een lokale fallback nuttig zijn wanneer externe afhankelijkheden zoveel mogelijk moeten worden beperkt — dezelfde afweging die terugkomt bij wat AI echt kost.

Belangrijk is dat iedere stap een expliciete functie heeft. Een secundair model hoeft bijvoorbeeld niet exact dezelfde kwaliteit te leveren als het primaire model. Het kan voldoende zijn dat het een beperkt aantal kernfuncties betrouwbaar uitvoert.

Een statische fallback is nog eenvoudiger. Het systeem kan bijvoorbeeld melden dat de AI-functie tijdelijk niet beschikbaar is, maar wel bestaande informatie, zoekresultaten of handmatige vervolgstappen tonen. Dat is vaak beter dan een model inschakelen dat onvoldoende betrouwbaar is voor de taak.

Health-checks, timeouts en retries

Een fallback-keten begint met bepalen wanneer de primaire route als onbruikbaar moet worden beschouwd.

Health-checks kunnen controleren of een provider bereikbaar is en of requests binnen een acceptabele tijd worden verwerkt. Voor AI-systemen is een eenvoudige beschikbaarheidscheck echter vaak niet genoeg. Een provider kan technisch online zijn terwijl de responstijd voor de applicatie onbruikbaar is.

Daarom zijn timeouts belangrijk. Zonder timeout kan een applicatie lang blijven wachten op een request dat waarschijnlijk niet meer succesvol wordt afgerond. Een goed gekozen timeout maakt duidelijk wanneer het systeem moet stoppen met wachten en naar de volgende stap moet gaan.

Retries kunnen tijdelijke fouten opvangen, maar moeten beperkt blijven. Het direct opnieuw versturen van hetzelfde request kan een overbelaste provider juist verder belasten. Daarom wordt vaak exponential backoff gebruikt: tussen opeenvolgende retries wordt steeds langer gewacht.

Ook jitter kan worden toegevoegd, zodat veel systemen niet allemaal op exact hetzelfde moment opnieuw proberen verbinding te maken. Dat voorkomt dat een tijdelijk probleem wordt versterkt door een grote golf gelijktijdige retries.

Circuit breakers voorkomen eindeloos proberen

Een circuit breaker voorkomt dat een systeem voortdurend requests blijft sturen naar een dienst waarvan al duidelijk is dat die problemen heeft.

Wanneer voldoende failures of timeouts optreden, gaat het circuit tijdelijk open. Requests worden dan niet meer naar de primaire provider gestuurd maar direct naar de fallback-route. Na verloop van tijd kan een beperkt testrequest bepalen of de dienst weer beschikbaar is.

Dit patroon voorkomt onnodige latency en vermindert belasting op een falende dependency. Het is vooral nuttig wanneer een externe provider onderdeel is van een keten van meerdere services.

Een circuit breaker moet wel zorgvuldig worden ingesteld. Een te gevoelig mechanisme kan een provider na enkele toevallige fouten al uitschakelen. Een te tolerant mechanisme laat gebruikers juist te lang wachten voordat de fallback wordt geactiveerd.

Gedegradeerde kwaliteit is ook een storing

Bij AI-systemen is beschikbaarheid niet hetzelfde als bruikbaarheid. Een model kan technisch functioneren terwijl de kwaliteit van de antwoorden sterk achteruitgaat.

Dat kan bijvoorbeeld zichtbaar worden doordat structured output vaker ongeldig is, tool calls mislukken, antwoorden essentiële informatie missen of het model instructies minder consistent volgt. Voor sommige toepassingen kunnen zulke problemen net zo schadelijk zijn als volledige downtime.

Daarom kan een fallback-mechanisme ook kwaliteitscriteria bevatten. Een systeem dat JSON verwacht kan bijvoorbeeld controleren of het antwoord geldig is en aan het vereiste schema voldoet. Bij RAG kan worden gecontroleerd of verplichte bronverwijzingen aanwezig zijn. Bij agents kan worden vastgesteld of een verwachte tool call daadwerkelijk is uitgevoerd.

Voor complexere toepassingen kan monitoring daarnaast veranderingen in foutpatronen, latency en validatiefouten signaleren. Het doel is niet om automatisch te bepalen of elk antwoord inhoudelijk perfect is, maar om meetbare signalen van degradatie te herkennen.

Een tweede provider is niet automatisch plug-and-play

Een veelgemaakte aanname is dat je een tweede LLM-provider eenvoudig achter dezelfde interface kunt zetten. Technisch kan dat vaak, maar functioneel zijn modellen niet volledig uitwisselbaar.

Providers kunnen verschillen in system prompts, tool calling, structured output, contextverwerking en veiligheidsbeleid. Dezelfde prompt kan bij twee modellen verschillend gedrag opleveren.

Een fallback die alleen technisch getest is, kan daardoor tijdens een storing onverwachte resultaten produceren. Prompt-compatibiliteit moet daarom onderdeel zijn van de architectuur.

Een praktische aanpak is om prompts en tooldefinities zo provider-onafhankelijk mogelijk te ontwerpen en provider-specifieke aanpassingen in een aparte integratielaag te plaatsen. Vervolgens moeten dezelfde kritieke taken tegen meerdere modellen worden getest. Dat betekent niet dat de output identiek moet zijn. Wel moet duidelijk zijn welke gedragsverschillen acceptabel zijn en welke niet.

Redundantie kost geld en complexiteit

Fallback-architectuur is geen gratis verzekering. Een tweede provider betekent extra integratiecode, aparte credentials, monitoring en tests. Een lokaal model vraagt daarnaast infrastructuur, modelbeheer en mogelijk hardwarecapaciteit.

Ook operationeel ontstaat meer complexiteit. Incidenten moeten kunnen aantonen welke provider een request heeft verwerkt, waarom een fallback is geactiveerd en of gebruikers daardoor andere resultaten hebben gekregen.

Die kosten moeten passen bij de impact van uitval. Voor een experimentele interne tool kan een duidelijke foutmelding voldoende zijn. Voor een systeem dat onderdeel is van een belangrijk bedrijfsproces kan redundantie veel logischer zijn. De juiste architectuur is daarom niet automatisch de langste fallback-keten. Het gaat om proportionele robuustheid.

Wanneer geen antwoord beter is dan een zwakkere fallback

Een fallback hoeft niet altijd een ander AI-model te zijn.

Stel dat een toepassing financiële gegevens classificeert, technische beslissingen ondersteunt of informatie geeft waarvoor hoge nauwkeurigheid vereist is. Als de fallback aantoonbaar minder betrouwbaar is, kan doorgaan met een zwakker model een groter risico vormen dan tijdelijk stoppen.

In zulke gevallen is fail closed vaak verstandiger: de functie meldt dat automatische verwerking tijdelijk niet beschikbaar is en verwijst naar een handmatig proces.

Bij minder kritieke taken kan fail open acceptabel zijn. Een interne schrijfassistent kan bijvoorbeeld tijdelijk overschakelen op een eenvoudiger model, zolang gebruikers weten dat de kwaliteit anders kan zijn. Die beslissing moet per functie worden genomen. Een systeem hoeft niet één globale fallback-strategie te hebben.

Test de fallback voordat je hem nodig hebt

Een fallback die nooit wordt getest, is vooral theoretische redundantie.

Je moet kunnen simuleren dat de primaire provider niet bereikbaar is, extreem traag reageert of ongeldige responses teruggeeft. Vervolgens moet zichtbaar worden of timeouts, retries, circuit breakers en alternatieve routes daadwerkelijk functioneren.

Ook de terugkeer naar de primaire provider verdient aandacht. Wanneer een storing voorbij is, moet het systeem gecontroleerd kunnen herstellen zonder voortdurend tussen providers heen en weer te schakelen.

Logging is daarbij essentieel. Zonder inzicht in welke route is gebruikt, hoe lang iedere stap duurde en waarom een fallback is geactiveerd, wordt troubleshooting moeilijk.

Conclusie

Een robuust AI-systeem gaat er niet vanuit dat zijn primaire provider altijd beschikbaar en bruikbaar blijft. Een fallback-keten combineert alternatieve providers of modellen met mechanismen zoals health-checks, timeouts, retries, backoff en circuit breakers. Daarbij moet niet alleen downtime worden gedetecteerd, maar ook meetbare kwaliteitsdegradatie. Redundantie heeft echter kosten en verschillende modellen gedragen zich niet identiek. Soms is een secundair model de juiste oplossing; soms is een duidelijke foutmelding veiliger. De beste fallback-strategie is daarom niet degene die altijd een antwoord produceert, maar degene die gecontroleerd blijft functioneren wanneer onderdelen van het systeem falen — dezelfde denkwijze achter model-routing.