Ik stel bij elk AI-project tegenwoordig dezelfde vraag: als jullie leverancier morgen de prijs verdubbelt of het model uitfaseert, hoe lang duurt het dan voordat je ergens anders draait? Het eerlijke antwoord is meestal dat niemand het weet.
Dat is AI vendor lock-in. Niet omdat een leverancier je bewust opsluit, maar omdat niemand heeft opgeschreven wat er allemaal mee moet als je vertrekt.
- Modellen worden regelmatig uitgefaseerd, prijzen en limieten veranderen. Wisselen is geen uitzondering, het is onderhoud.
- De lock-in zit zelden in het model zelf. Hij zit in prompts, koppelingen, logs en kennis die alleen in het platform van de leverancier staan.
- Een exitplan past op één A4: wat je bezit, waar het staat, hoe je het meeneemt en hoe je test dat het daarna nog werkt.
- Wie een vaste testset heeft, kan in dagen wisselen in plaats van maanden.
Wat er meestal gebeurt
Het patroon dat ik het vaakst zie gaat zo. Een team bouwt een interne assistent op het platform van één aanbieder. Prompts staan in de webinterface van dat platform, documenten zijn geüpload in de ingebouwde kennisbank, gesprekken en feedback zijn alleen zichtbaar in hun dashboard. Het werkt goed en niemand denkt verder.
Dan komt de mail dat het gebruikte model over een paar maanden verdwijnt. Het opvolgende model is duurder en antwoordt net anders. Een prima moment om ook eens naar een andere aanbieder te kijken, vindt het team.
Dat blijkt lastig. De prompts moeten met de hand worden overgezet. De kennisbank is te exporteren als losse bestanden, maar zonder de opbouw en metadata die de antwoorden goed maakten. Maanden aan feedback van gebruikers blijft achter. En er is geen manier om te laten zien dat een nieuwe opzet net zo goed antwoordt als de oude.
Dus blijft het team zitten waar het zit. Niet omdat die aanbieder de beste keus is, maar omdat weggaan te veel onbekend werk is.
Je zit pas echt vast als je niet meer kunt uitrekenen wat vertrekken kost.
Waarom AI vendor lock-in nu relevant is
Bij klassieke software kon je een pakket tien jaar laten draaien. Bij AI is de levensduur van een modelversie veel korter. Alle grote aanbieders houden een openbare lijst bij van modellen die verdwijnen, zoals de OpenAI deprecations-pagina, het overzicht van Anthropic model deprecations en de Gemini API deprecations. Wisselen van model gebeurt dus toch. De vraag is alleen of je het zelf plant.
Daar komt bij dat een nieuw model van dezelfde leverancier ook gewoon een wissel is. Ander gedrag, andere kosten, soms andere limieten. Daarover schreef ik eerder in hoe AI model drift je workflow stil breekt. En toen in september meerdere grote diensten tegelijk uitvielen, zag je wie een tweede route had en wie niet (zie de gelijktijdige storing bij ChatGPT, Claude, Grok en Gemini).
Ook de regelgeving kijkt mee. De Europese Data Act geldt sinds 12 september 2025 en bevat regels om makkelijker over te stappen tussen clouddiensten, met een verbod op overstapkosten vanaf 12 januari 2027 (Verordening (EU) 2023/2854). Of jouw AI-dienst daaronder valt, hangt af van wat je precies afneemt. Voor de financiële sector is het al concreet: DORA verplicht een exitstrategie voor ICT-diensten die kritieke functies ondersteunen.
Je hoeft niet onder DORA te vallen om het idee over te nemen. Een exitplan maken kost een middag. Er geen hebben kost je onderhandelingspositie bij elke prijsverhoging.
Wat je nu kunt doen: een exitplan in vijf stappen
Het doel is niet om nooit meer afhankelijk te zijn. Dat lukt niemand. Het doel is dat je weet wat vertrekken kost, zodat je het kunt kiezen. Zo werkt ook AI-automatisering in je eigen omgeving: stopt de samenwerking, dan kun je zelf verder.
- Maak een lijst van wat van jou is. Prompts en systeeminstructies, de documenten in je kennisbank, koppelingen met andere systemen, gesprekslogs en feedback, en je testset. Zet bij elk onderdeel waar het nu staat.
- Haal de prompts uit het platform. Bewaar ze in versiebeheer of op zijn minst in een gedeelde map met datum en eigenaar, niet alleen in de webinterface van de leverancier. Hoe dat eruitziet, beschreef ik in prompt versiebeheer zonder Slack.
- Test een export voordat je hem nodig hebt. Exporteer de kennisbank en de logs één keer echt. Kijk of de structuur en metadata meekomen, of alleen losse bestanden. Wat niet te exporteren is, is je echte lock-in.
- Zet een dun laagje tussen je proces en het model. Laat je koppelingen niet rechtstreeks overal dezelfde leverancier aanroepen, maar via één plek waar je het model kunt vervangen. Dat kan een eenvoudige eigen service zijn of een bestaande gateway. Het hoeft niet groot.
- Houd een testset klaar. Zonder vaste set echte vragen kun je niet aantonen dat een andere aanbieder net zo goed werkt. Dat is precies het verhaal uit jullie AI-assistent heeft geen regressietest. Met zo’n set wordt wisselen een meetbare beslissing in plaats van een gok.
Wat je in het contract wilt zien
Bij een nieuwe aanbieder of een verlenging kijk ik naar een paar vaste punten. Hoe lang van tevoren word je gewaarschuwd als een model verdwijnt? Mag je je data en logs in een bruikbaar formaat meenemen, en hoe lang na het einde van het contract nog? Wordt jouw data gebruikt om modellen te trainen? En wat kost vertrekken, als het iets kost?
Dat zijn geen exotische eisen. Een inkoper die cloudcontracten kent, herkent ze meteen. Bij AI-diensten worden ze alleen vaak overgeslagen omdat het begon als een proefabonnement met een creditcard.
Wil je weten of een ander model jullie taak goedkoper of beter doet, dan begint AI-modeloptimalisatie bij precies deze vraag. Liever dat iemand anders de modellen, de wissels en de testset beheert? Kijk dan naar managed AI-agents, of plan een kort gesprek via contact.
Weet je wat het jullie kost om van AI-leverancier te wisselen?
We lopen samen jullie AI-toepassingen langs, brengen in kaart wat vastzit en maken een exitplan dat op één A4 past. Inclusief een testset, zodat een wissel meetbaar wordt.