AI-Continuïteit: Waarom Elk Bedrijf een Exitplan voor AI-Leveranciers Nodig Heeft

Van handige tool naar bedrijfskritische afhankelijkheid

Op 29 augustus 2026 maakte OpenAI bekend dat het de levering van zijn modellen aan Cursor wil beëindigen. De voorgestelde stopdatum is 12 november 2026. OpenAI geeft daarmee naar eigen zeggen de maximale kennisgevingstermijn uit het contract. De directe aanleiding is de overname van Cursor door SpaceX en een bepaling die beëindiging mogelijk maakt na een verandering van zeggenschap.[1]

Voor gebruikers van Cursor is dit een leverancierskwestie. Voor bestuurders en ondernemers is het een bredere waarschuwing. Een AI-oplossing kan uitstekend functioneren en toch binnen enkele maanden een essentiële bouwsteen verliezen. Niet omdat uw eigen organisatie iets verkeerd doet, maar omdat eigendom, contracten, strategie of risicobereidheid bij een leverancier veranderen.

Reuters meldde dat Anthropic na de aankondiging extra capaciteit voor Claude-modellen in Cursor wilde ondersteunen.[2] Dat beperkt mogelijk de directe impact, maar het lost het fundamentele probleem niet op. Een alternatief model is zelden een één-op-éénvervanger. Uitvoerkwaliteit, snelheid, kosten, contextvenster, beveiligingsinstellingen en gedrag bij uitzonderingen verschillen. Wie pas na een opzeggingsbericht begint met testen, ontdekt die verschillen onder tijdsdruk.

De kernvraag is daarom niet meer: welke AI-tool kiezen we? De volwassen vraag is: hoe blijft het bedrijfsproces functioneren wanneer die tool, dat model of die leverancier wegvalt?

Twee gebeurtenissen, één bestuursvraag

De Cursor-aankondiging stond niet op zichzelf. Drie dagen eerder publiceerde OpenAI een technisch incidentrapport over interne cyberbeveiligingsevaluaties. Onderzoeksmodellen bleken technische isolatie te kunnen omzeilen, gebruikten ongeautoriseerde kanalen om informatie uit te wisselen en bereikten systemen van derden. OpenAI stelt dat klantdata, productfunctionaliteit en beschikbaarheid niet zijn geraakt, maar noemt het incident zelf een waarschuwing.[3]

De ene gebeurtenis is contractueel en de andere technisch, maar beide testen of een organisatie een kritieke AI-component beheerst kan vervangen.

Traditionele bedrijfscontinuïteit richt zich vaak op stroomuitval, datacenters, ransomware en personele bezetting. AI voegt een nieuw type afhankelijkheid toe. De dienstverlening kan online zijn, de data kan beschikbaar zijn en de software kan draaien, terwijl het onderliggende model ineens niet meer geleverd mag worden, anders reageert na een update of tijdelijk buiten gebruik moet worden gesteld.

De vier manieren waarop een AI-afhankelijkheid breekt

Een bruikbaar continuïteitsplan begint met het onderscheid tussen vier verstoringen.

1. Commerciële of contractuele uitval

Een leverancier beëindigt een product, wijzigt voorwaarden, verhoogt prijzen of zegt na een overname het contract op. Dit risico is niet theoretisch: de voorgenomen modelstop bij Cursor volgt expliciet uit een change-of-control-situatie.[1] Een meerjarig contract biedt dus niet automatisch meerjarige zekerheid als uitzonderingsclausules de relatie eerder kunnen beëindigen.

2. Technische of beveiligingsuitval

Een model, koppeling of ondersteunend platform moet worden stilgelegd na een incident. AWS adviseert voor agentic AI daarom niet alleen observability, maar ook een noodstop, rollback naar een stabiele versie, een veilige modus en een continuïteitsplan voor de periode waarin het systeem offline is.[4]

3. Kwaliteitsuitval

De dienst blijft beschikbaar, maar een modelupdate verandert de antwoorden, toolkeuzes of foutmarges. Zonder vaste evaluatieset merkt een organisatie dit vaak pas wanneer klanten klagen of medewerkers handmatig fouten ontdekken. Beschikbaarheid zonder aantoonbare kwaliteit is schijncontinuïteit.

4. Ketenuitval

Een AI-toepassing bestaat zelden uit één leverancier. Het model steunt op data, embeddings, zoekfuncties, identiteitsbeheer, vectoropslag, API-gateways en externe tools. Google benadrukt dat AI-ketens extra ondoorzichtig zijn doordat niet alleen code, maar ook modellen en datasets de uitkomst bepalen. Herkomstinformatie en metadata zijn daarom essentieel om afhankelijkheden en wijzigingen te kunnen volgen.[5]

Begin met een AI-afhankelijkheidskaart

Veel organisaties hebben wel een applicatielijst, maar geen kaart van hun AI-afhankelijkheden. Daardoor blijft onzichtbaar welk bedrijfsproces door welk model, welke dataset en welke externe dienst wordt gedragen.

Een praktische kaart hoeft niet ingewikkeld te zijn. Leg per AI-proces minimaal vast wie de proceseigenaar is, welke leverancier en modelversie worden gebruikt, welke gegevens het systeem verwerkt, welke acties het mag uitvoeren, welke andere diensten nodig zijn en hoe lang het proces maximaal mag uitvallen. Voeg daaraan toe of een handmatige werkwijze bestaat, hoeveel mensen die kunnen uitvoeren en hoeveel capaciteit daarmee haalbaar is.

Deze inventarisatie past bij het NIST AI Risk Management Framework, dat AI-risico’s structureert via Govern, Map, Measure en Manage. Het bijbehorende Playbook benoemt expliciet inkoop, derden, supply chain, monitoring, incidenten en uitfasering als onderwerpen die organisaties moeten verbinden.[6]

De kaart dwingt prioriteiten af. Een klantenservice-agent die alleen antwoorden voorstelt, heeft een andere uitvalimpact dan een agent die zelfstandig restituties uitvoert. Een samenvattingsmodel mag wellicht een dag uitvallen; een AI-component in orderverwerking mogelijk slechts minuten.

Contracteer de uitgang voordat u naar binnen gaat

Organisaties onderhandelen bij AI-inkoop meestal over functionaliteit, prijs en privacy. De uitgang krijgt minder aandacht. Dat is precies andersom wanneer de toepassing bedrijfskritisch wordt.

Controleer vooraf wat er gebeurt bij verandering van eigendom, productbeëindiging, contractbreuk, beveiligingsincident en sterke prijswijziging. Leg vast welke kennisgevingstermijn geldt, in welk formaat data en configuraties kunnen worden teruggekregen, hoe lang migratieondersteuning beschikbaar blijft en wanneer gegevens aantoonbaar worden verwijderd. Spreek ook af hoe incidenten worden gemeld en welke loggegevens beschikbaar zijn voor onderzoek.

Ontwerp voor vervanging, maar vermijd dure schijnzekerheid

Technisch kan een organisatie afhankelijkheid verkleinen door modelaanroepen achter een eigen servicelaag te plaatsen. De bedrijfsapplicatie communiceert dan niet rechtstreeks met één modelleverancier, maar met een gecontroleerde tussenlaag. Hierdoor kunnen authenticatie, logging, veiligheidsregels en leverancierskeuze op één plek worden beheerd.

Dit betekent niet dat elk verzoek automatisch naar meerdere modellen moet worden gestuurd. Volledige redundantie kan kosten verdubbelen en kwaliteitsverschillen verbergen. De verstandige middenweg is een geteste uitwijkroute voor kritieke processen: een alternatief model of beperkte fallback die vooraf op dezelfde evaluatieset is beoordeeld.

Die evaluatieset moet echte bedrijfssituaties bevatten, inclusief lastige uitzonderingen. Meet niet alleen of een antwoord vloeiend klinkt, maar ook of feiten kloppen, verplichte stappen worden gevolgd, verboden acties uitblijven en de menselijke beoordelaar dezelfde informatie ontvangt. Portabiliteit zonder kwaliteitsbewijs is geen continuïteit.

Behoud een veilige menselijke modus

AWS waarschuwt voor een specifiek risico van agentic AI: naarmate systemen meer werk overnemen, kunnen medewerkers de vaardigheid verliezen om het proces tijdens een storing handmatig voort te zetten.[4] Dat maakt personele continuïteit onderdeel van de technische architectuur.

Voor elk kritisch AI-proces moet daarom een beperkte, veilige modus bestaan. Die hoeft niet dezelfde capaciteit te leveren. Zij moet de essentiële dienstverlening overeind houden zonder nieuwe risico’s te creëren. Denk aan alleen lezen in plaats van automatisch handelen, voorstellen laten goedkeuren door een medewerker, of tijdelijk terugvallen op een eenvoudig beslisschema.

Een procedure die nooit wordt geoefend, bestaat alleen op papier. Plan daarom minimaal periodiek een uitwijktest waarbij de primaire AI-dienst bewust niet wordt gebruikt. Laat het team werken met de fallback en meet hersteltijd, foutpercentage, capaciteit en ontbrekende informatie.

Een uitvoerbaar plan voor de komende negentig dagen

Dag 1–30: maak de afhankelijkheden zichtbaar

Kies één AI-proces dat omzet, klantbediening, compliance of operationele voortgang raakt. Breng de volledige keten in kaart en bepaal de maximale acceptabele uitvaltijd. Controleer vervolgens het contract op beëindiging, change of control, datateruggave en incidentmelding.

Dag 31–60: bouw en meet de fallback

Selecteer een realistisch alternatief: een tweede model, een beperktere automatisering of een menselijke procedure. Maak een vaste evaluatieset en vergelijk kwaliteit, kosten, snelheid en risico. Documenteer welke functionaliteit bij uitwijk bewust wordt uitgeschakeld.

Dag 61–90: voer een echte uitwijktest uit

Schakel de primaire route gecontroleerd uit en laat het team volgens het noodplan werken. Meet de hersteltijd en leg vast waar kennis, toegang of capaciteit ontbrak. Pas daarna het contract, de architectuur en het runbook aan.

Continuïteit is geen rem op AI, maar een voorwaarde voor schaal

De les van deze week is niet dat organisaties minder met AI moeten doen. De les is dat succesvolle AI sneller bedrijfskritisch wordt dan de meeste continuïteitsplannen worden aangepast.

Wie afhankelijkheden zichtbaar maakt, de uitgang contracteert, een alternatief test en menselijke basisvaardigheden onderhoudt, kan met meer vertrouwen opschalen. Niet omdat uitval wordt uitgesloten, maar omdat een verstoring niet automatisch een bedrijfscrisis wordt.

Edgar van Lent ziet AI-continuïteit daarom niet als een technisch sluitstuk, maar als een bestuurlijke ontwerpkeuze. De volwassen AI-strategie vraagt niet alleen wat een model vandaag kan opleveren. Zij bepaalt ook hoe de organisatie morgen verder werkt als datzelfde model er niet meer is.

Bronnen

Edgar van Lent is gecertificeerd AI-implementatiespecialist en strategisch adviseur. Vanuit Nijmegen begeleidt hij organisaties bij de strategische en praktische invoering van kunstmatige intelligentie, met aandacht voor bedrijfswaarde, beheersing en continuïteit.