AI-consultant lock-in is het risico dat een bedrijf zijn AI-systeem niet meer kan verlaten, aanpassen of zelfs maar begrijpen zonder de persoon die het gebouwd heeft. In juni 2026 werd duidelijk hoe reëel afhankelijkheid van een AI-leverancier kan zijn, toen een Amerikaans exportcontrolebevel een topmodel van de ene op de andere dag offline haalde voor elk bedrijf dat er stilzwijgend op had gebouwd. Dat is de zichtbare helft van het probleem. De stille helft — en degene die ik het vaakst mkb-projecten zie ontsporen — is afhankelijkheid van de bouwer, niet van het platform.
Wat de uitschakeling van Claude Fable 5 werkelijk laat zien
Op 9 juni 2026 lanceerde Anthropic Claude Fable 5 en Claude Mythos 5, de krachtigste modellen van het bedrijf tot dan toe. Drie dagen later beval het Amerikaanse ministerie van Handel het bedrijf de wereldwijde toegang stil te leggen onder exportcontroleregels, na berichten over een jailbreak met vermeende gevolgen voor de nationale veiligheid. Omdat Anthropic geen manier had om de nationaliteit van gebruikers in real time te verifiëren, was uitschakelen voor iedereen, overal, binnen enkele uren de enige optie die aan de regels voldeed. De modellen bleven 18 dagen uit de lucht. Toen het bevel eind juni werd ingetrokken, kwam Fable 5 terug — tegen ongeveer het dubbele van de prijs van Anthropics eigen Opus 4.8, in één klap het duurste model dat het bedrijf aanbood.
Niets aan die reeks gebeurtenissen was uniek voor Anthropic; hetzelfde kan elk toonaangevend AI-lab overkomen onder dezelfde regeldruk, en het punt hier is niet één bedrijf aan te wijzen. Het punt is dat elk bedrijf wiens klantenservicebot, code-review-pijplijn of klantgerichte agent vastgeklonken zat aan één specifiek model, twee weken lang geen alternatief had en geen stem in wat er daarna gebeurde. Onderzoek bevestigt hoe wijdverspreid die blootstelling al was vóór het incident: 81% van de Amerikaanse bestuurders maakt zich op zijn minst enigszins zorgen over afhankelijkheid van één AI-leverancier, 47% zegt dat het verliezen van hun belangrijkste leverancier een kernfunctie zou verstoren, en slechts 6% denkt daadwerkelijk zonder schade te kunnen overstappen. Lock-in op modelniveau is inmiddels iets waar bestuurders openlijk over piekeren. Mooi zo — dat is de helft van het probleem die eindelijk een naam heeft.
De lock-in die niemand benoemt: afhankelijk van de bouwer, niet het platform
Dit is de helft die ik veel vaker klanten zie overkomen, en die heeft niets te maken met welk model er achter de API draait. Een bedrijf kan alles goed doen op het modelvraagstuk — een open standaard kiezen, het gesloten agent-framework van één leverancier vermijden — en toch volledig onmachtig zijn om aan zijn eigen AI-systeem te komen, omdat de prompts, de uitzonderingslogica, de orkestratie en de kennis van "waarom doet het dit" in het hoofd van precies één persoon zitten: de consultant die het bouwde.
Ik stel elke ondernemer die ik spreek een variant van dezelfde vraag die tijdens het onderzoek voor dit stuk steeds terugkwam: wat gebeurt er na de oplevering — wie beheert dit systeem eigenlijk in maand veertien? Bijna niemand heeft een antwoord, want bijna niemand stelt de vraag vóór de handtekening. Ze staat niet op het lijstje naast prijs en doorlooptijd, en precies dat maakt haar de gevaarlijkere lock-in. Modelafhankelijkheid meldt zich met een brief van een ministerie of een herprijsde factuur — luid en onmiskenbaar. Consultant-afhankelijkheid meldt zich stil, als een supportticket dat drie weken kost in plaats van drie uur, omdat de enige die het systeem begreep met vakantie is, voor iemand anders werkt, of gewoon het tarief heeft verhoogd — wetend dat u moeilijk nee kunt zeggen.
Waarom dit een verdienmodelkeuze is die ik moet bevechten, geen ongeluk
Ik denk niet dat de meeste consultants bewust een val bouwen. De val bouwt zichzelf. De snelste, meest indrukwekkende manier om een AI-systeem op te leveren is het rechtstreeks vast te klinken aan het framework van één leverancier, de uitzonderingsregels van de klant in prompts te bakken die alleen u ooit ziet, en het architectuurdocument over te slaan omdat de klant al enthousiast is over de demo en er toch niemand om vroeg. Het staat in weken live. Het oogt briljant in de vergadering. En het levert een systeem op dat alleen de maker veilig kan aanraken — wat toevallig precies de versie van "succes" is die mijn eigen toekomstige omzet maximaliseert.
Die verleiding voel ik bij elk project, en ik zou liegen als ik het ontkende. Een systeem dat niemand behalve ik begrijp, is elke maand opnieuw meer waard voor mijn bedrijf dan een systeem dat uw eigen team zonder mij kan draaien. Eerlijk zijn over die prikkel is de enige manier die ik ken om er bewust tegenin te bouwen, in plaats van er per ongeluk in te schuiven — wat ik denk dat de meeste bureaus doen. Het verklaart ook waarom de branche hier zelden openlijk over praat: de prikkel benoemen is slecht voor de prikkel.
Wat ik daadwerkelijk anders bouw
Een paar concrete gewoontes, geen van alle exotisch, en stuk voor stuk controleerbaar.
- Elk project eindigt met een architectuurdocument in gewoon Nederlands, geen diagram dat alleen ik kan lezen, plus een werksessie waarin iemand van uw eigen team — niet per se technisch — het systeem bedient en aanpast terwijl ik toekijk, niet andersom.
- Code en data staan vanaf dag één in uw eigen repository en cloudomgeving, nooit in de mijne, zodat er niets "over te dragen" valt omdat niets ooit van mij is geweest.
- Waar de keuze bestaat, bouw ik op open standaarden in plaats van het gesloten agent-framework van één leverancier. Dat werd in 2026 merkbaar goedkoper om goed te doen: uit het brancheonderzoek van Stacklok blijkt dat 41% van de softwareorganisaties inmiddels beperkt of breed in productie draait met MCP-servers, en er bestaan meer dan 10.000 publieke MCP-servers om een systeem te koppelen aan de tools die het nodig heeft zonder het formaat van één leverancier in de leidingen te bakken. Modelonafhankelijk bouwen kostte vroeger extra engineeringuren; een flink deel van die belasting is dit jaar stilletjes verdwenen, en precies daarom is er minder excuus om het over te slaan dan twee jaar geleden.
- Ik kies standaard voor projecten met een vaste scope in plaats van open-einde-retainers, met opzet — een retainer is namelijk de enige commerciële vorm die mij financieel beloont zodra het systeem afhankelijk van mij blijft. Een vaste scope dwingt de prikkel terug naar het meteen goed doen van de overdracht.
- En elk contract legt vóór de eerste factuur vast wat er gebeurt als de klant wil vertrekken: wat ze ontvangen, in welk formaat, en hoe lang een overdracht duurt. Dat onderhandelen tijdens een breuk is het slechtst denkbare moment, en ik heb genoeg slecht onderhandelde breuken gezien om te weten dat vooraf altijd wint van achteraf.
Dit gaat trouwens niet echt over enterprise-budgetten, ook al is het meeste onderzoek naar vendor lock-in geschreven voor CIO's met een governanceteam achter zich. Een bedrijf van honderd man dat volgens het CIO-onderzoek van dit jaar 37% van zijn AI-werklast op vijf of meer modellen draait, heeft nog altijd iemand wiens taak het is die blootstelling periodiek te beoordelen. Een Nederlands of Vlaams mkb-bedrijf van twintig man heeft dat vrijwel nooit. Geen kwartaalreview van leveranciersafhankelijkheid, geen eigen AI-team dat merkt dat een supportticket drie weken kost in plaats van drie uur, geen governancelaag tussen de ondernemer en de factuur van de consultant. Precies daarom wegen de vragen in dit stuk zwaarder voor een klein bedrijf dan voor een groot bedrijf, niet lichter — u heeft minder mensen die het probleem achteraf kunnen opvangen, waardoor het vooraf opmerken uw enige betrouwbare optie is.
Elke gewoonte hierboven is eigenlijk een verkorte versie van dezelfde onderliggende check, die het waard is om een keer voluit te zeggen: kost vertrekken u een onderhandeling, of kost het u een herbouw? Een onderhandeling is vervelend maar te overleven — u bakkeleit over prijs, doorlooptijd, misschien een afkoopsom, en het leven gaat door. Een herbouw betekent het project met iemand anders overnieuw beginnen, tegen volle kosten, omdat niets uit het eerste traject bruikbaar is zonder de oorspronkelijke maker. Een groot bedrijf met een governanceteam kan die kosten meestal één keer opvangen en verder gaan. Een installatiebedrijf of accountantskantoor van twintig man kan dat niet — er staat geen tweede budget klaar voor hetzelfde project. Precies daarom weegt de onderliggende vraag, onderhandeling of herbouw, zwaarder op die schaal dan op enterprise-niveau, en kost het niets extra om haar vóór ondertekening te stellen.
Zelfs Europa's eigen soevereiniteitsproject ontsnapte hier niet volledig aan
Het is de moeite waard om toe te geven hoe moeilijk dit werkelijk is om goed te doen, zelfs met de beste bedoelingen en een serieus budget — want het duidelijkste recente voorbeeld is geen klein AI-bureau, het is de Europese Commissie zelf. In april 2026 gunde de Commissie haar allereerste soevereine-cloudraamwerk — tot 180 miljoen euro over zes jaar — aan vier aanbieders, expliciet om Europa's afhankelijkheid van niet-Europese infrastructuur te verkleinen. Drie van de winnaars — Post Telecom met OVHcloud en CleverCloud, StackIT, en Scaleway — bouwen op hun eigen technologie en haalden het hoogste onafhankelijkheidsniveau van het raamwerk, SEAL-3. De vierde, Proximus — het Belgische telecombedrijf — won zijn plek via S3NS, een joint venture waarvan de cloudlaag op technologie van Google draait onder een Europees juridisch jasje, en landde één niveau lager, op SEAL-2.
CISPE, de koepel van 38 Europese cloudbedrijven, noemde de beslissing "sovereignty washing" en waarschuwde dat het aankleden van de technologie van een buitenlandse hyperscaler in lokaal bestuur de onderliggende afhankelijkheid niet wegneemt — het maakt haar alleen moeilijker te zien. Het verweer van de Commissie zelf — dat een niet-Europese technologiestack onder voldoende streng bestuur nog steeds de soevereiniteitslat kan halen — is een redelijk institutioneel argument. Het is ook, bijna woord voor woord, hetzelfde argument dat elke AI-leverancier gebruikt over zijn eigen gesloten lock-in: vertrouw op het jasje, maak u geen zorgen over wat eronder zit. Als de Europese Commissie 180 miljoen euro en jaren van weloverwogen planning kan besteden en toch één niveau onder volledige onafhankelijkheid landt, dan heeft een Nederlands of Vlaams mkb-bedrijf dat op een dinsdagmiddag een chatbotcontract tekent, vrijwel geen kans om het equivalente probleem zelf op te merken. Dat is geen reden om de vraag maar te laten rusten. Het is precies de reden om haar vóór de handtekening te stellen, niet erna.
Een korte checklist vóór u tekent bij een AI-consultant
Vijf vragen, één keer gesteld, vóór de eerste factuur, aan elke AI-consultant die u overweegt.
- Wie is eigenaar van de code en de data zodra dit project klaar is — op papier, niet in de geest?
- Kan een andere ontwikkelaar dit systeem lezen en een kleine aanpassing doen zonder u eerst te bellen?
- Wat kost het, in tijd en euro's, om over te stappen als de prijs of toegang tot het onderliggende model verandert?
- Zit er ergens een onderdeel vastgeklonken aan het gesloten formaat van één leverancier dat een standaardtool niet zou kunnen vervangen?
- Wat zegt het contract, stap voor stap, over wat er gebeurt als u wilt vertrekken?
Als een van deze vijf geen helder antwoord heeft vóórdat u tekent, bent u niet achterdochtig door twee keer te vragen. U doet het enige stuk due diligence dat noch de demo, noch de offerte ooit voor u zal doen — en voor een bedrijf zonder eigen AI-team om het probleem later op te vangen, is dit misschien de enige kans die u krijgt om het überhaupt op te merken.
Ik ben nog één keer eerlijk over die spanning: mezelf vervangbaar maken is niet wat de meeste verdienmodellen in deze branche belonen, en er zijn maanden waarin ik die verleiding net zo scherp voel als elke andere ondernemer. Maar ik schrijf het liever hier op, in het openbaar, dan dat een klant er de harde manier achter komt — via een brief van een ministerie, een herprijsde factuur, of een supportticket dat stilletjes drie weken duurt — dat de afhankelijkheid vanaf het begin was ingebouwd, en niemand het ooit vroeg.
