Exit en fallback voor AI-diensten: wat de OpenAI-storing van juli 2026 blootlegt

U moet nu kunnen aantonen dat kritieke AI-workflows niet afhankelijk zijn van één aanbieder, en dat u een geteste uitweg hebt als die aanbieder uitvalt. Dit is geen contractdetail meer — het is een operationele verplichting.

De aanleiding is een analyse van 25 augustus 2026 over exit- en fallback-routes voor AI-diensten, die stelt dat de 17-daagse OpenAI-storing van juli 2026 blootlegde dat organisaties zonder ingebouwde alternatieven volledig stil kwamen te staan. In het geval van BigGo Finance betekende dit: geen rekening, geen compensatie, geen uitweg. In onze assessment: dit is niet een probleem van één aanbieder, maar van uw eigen architectuur en contracten. Continuïteit bij AI-diensten is uw verantwoordelijkheid, niet die van de leverancier.

Wat gebeurt er als uw primaire AI-aanbieder uitvalt?

De storing toonde aan dat directe afhankelijkheid van één model-endpoint of provider-specifieke promptstructuur een direct continuïteitsrisico is. Zodra een productie-workflow op één API en één set provider-eigen prompts leunt, kan een modelstopzetting of API-wijziging de hele zaak in één klap breken. Dit is niet theoretisch: het gebeurde in juli 2026, en de organisaties die geen alternatief hadden ingericht, konden niets doen.

Het vraagstuk is dus niet inkoopkracht of prijs. Het is architectuur. Een AI-gateway, scheiding tussen providers, credential-isolatie en getest failover-routing bepalen of uw proces blijft draaien wanneer een dienst wegvalt. Portabiliteit gaat niet alleen over de vrijheid om te kiezen, maar over de vraag of kritieke werk doorloopt als de eerste keuze wegvalt.

Welke contractuele rechten moet u hebben?

Moderne AI-contracten moeten exitrechten en dataportabiliteit expliciet verankeren — niet als optionele bijlage, maar als kernonderdeel van het hoofdcontract. Dit gaat om gedefinieerde transitieperioden, verplichte transitieassistentie, vooraf geprijsde migratie-ondersteuning en run-off-services.

Belangrijk is welke categorieën data en artefacten onder het exportrecht vallen. Dit zijn niet alleen klantdata en outputs, maar ook klant-artefacten: prompts, workflows, embeddings en retrievalindexen. Dit zijn precies de onderdelen die bij een naïeve migratie achterblijven bij de oude aanbieder. Zonder heldere rechten op export en verwijdering van deze artefacten is een exitclausule op papier waardeloos.

De EU Data Act verbiedt switching-kosten vanaf januari 2027. Dit maakt 2026 een logisch moment om exit-routes niet alleen te bedenken, maar ook echt te testen.

Welke foutmodes en risico's moet u adresseren?

• Provider lock-in door model-specifieke prompts — workflows die alleen met één model werken en niet op alternatieven kunnen worden gemigreerd.
• Verlies van klant-artefacten bij uitstap — prompts, embeddings en retrievalindexen die bij de oude aanbieder achterblijven omdat contracten ze niet dekken.
• Geen geteste failover-route — contractuele exitrechten die in de praktijk niet werken omdat de architectuur geen alternatief voorziet.
• Onzichtbare afhankelijkheden — workflows waarvan u niet kunt reconstrueren welke modellen en endpoints daadwerkelijk worden gebruikt.
• Geen aantoonbare governance — geen documentatie of audittrails die kunnen bewijzen dat u continuïteit hebt ingericht.

Welke concrete controles moet u kunnen demonstreren?

1. Inventariseer per workflow welke AI-providers en modellen u gebruikt — documenteer voor elke kritieke taak welke endpoints en modellen actief zijn.
2. Verifieer dat exitrechten en dataportabiliteit in het contract staan — zorg dat exportrechten op data en artefacten expliciet zijn gedefinieerd, met transitieperioden en kosten.
3. Test failover-routing naar minstens één alternatieve provider — voer minstens eenmaal per kwartaal een migratie-scenario uit naar een ander model of aanbieder.
4. Isoleer provider-specifieke logica achter een abstractielaag — zorg dat workflows niet direct op provider-API's leunen, maar via een gateway die failover ondersteunt.
5. Documenteer en audit welke gevoelige data door welke modellen gaat — maak zichtbaar welke klant-artefacten en data elke workflow verwerkt, zodat u weet wat u moet exporteren.

Hoe maak je continuïteit aantoonbaar?

Toezichthouders verwachten dat organisaties kunnen laten zien wie waarvoor verantwoordelijk is. Voor exit en continuïteit betekent dit dat het niet volstaat om technische mechanismen te hebben; ze moeten ook zichtbaar zijn in governance-documentatie en audittrails. Per workflow moet aantoonbaar zijn welke AI-providers en modellen worden gebruikt, welke exit- en exportrechten gelden, welke data- en artefactcategorieën migreerbaar zijn, en hoe vaak fallback-scenario's zijn getest.

Dit is het punt waar verificatie concreet wordt. Een verificatielaag kan helpen meerdere onafhankelijke modellen aan te spreken en de verificatiestappen zichtbaar te maken. Dit garandeert geen correctheid en elimineert geen hallucinaties, maar het maakt controle mogelijk en geeft meer zicht op welke modellen daadwerkelijk zijn gebruikt. Voor gevoelige inhoud kan een privacylaag gevoelige waarden vervangen door synthetische equivalenten voordat de AI-keten de inhoud verwerkt. De workflow is ontworpen om fail-closed te zijn — mislukt de privacycontrole, dan wordt het document niet doorgestuurd.

Zo'n tooling lost lock-in niet in uw plaats op en vervangt geen contractclausules of failover-architectuur. Maar het kan helpen de continuïteitsvraag toetsbaar te maken: welke modellen ben ik gebruikt, en kan ik dat later reconstrueren?

Tooling kan routering, logging en verificatie automatiseren. Het kan u helpen zichtbaarheid in te bouwen en failover-paden te testen. Maar het professionele eindoordeel — over exitplan, migratie en risico — blijft bij u. U moet bepalen welke workflows kritiek zijn, welke providers acceptabel zijn als fallback, en hoe vaak u moet testen. Tooling ondersteunt dat oordeel; het vervangt het niet.