AI vendor lock-in: zo voorkom je afhankelijkheid van één AI-leverancier.

AI-afhankelijkheid is anders dan je denkt

Bij traditionele software is vendor lock-in een bekend verhaal: je data zit vast, de export is beperkt, en hoe langer je wacht, hoe duurder de migratie. Bij AI is dat patroon fundamenteel anders. Niet omdat lock-in minder erg is, maar omdat het op vijf lagen tegelijk accumuleert — en elke laag vergroot de switchkosten onafhankelijk van de andere.

Dat maakt AI vendor lock-in lastiger te herkennen dan je gewend bent. Je merkt het niet op de dag dat je een tool kiest. Je merkt het op de dag dat je wilt wisselen — en ontdekt dat je prompts, workflows, data, compliance-bewijs én teamexpertise allemaal aan dezelfde leverancier vastzitten.

De vijf lagen van AI vendor lock-in

Traditionele lock-in speelt zich af op één of twee assen: data en configuratie. AI-lock-in is een vijflagenmodel waarbij de lagen elkaar versterken:

1. Modellock-in

Je prompts, fine-tuning en evaluaties zijn geschreven voor één specifiek model. Een prompt die in Claude perfect werkt, geeft in GPT-4o een ander resultaat — en andersom. Hoe meer je optimaliseert voor één model, hoe meer werk de overstap kost. Dat is geen bug: het is een eigenschap van hoe taalmodellen werken.

2. Orchestratielock-in

Dit is de snelst groeiende en meest onderschatte laag. Je agent-workflows, tool-aanroepen en beslislogica leven in de propriëtaire omgeving van je leverancier. Dat is het werk dat jíj hebt gedaan, maar dat je niet kunt meenemen. Herbouwen op een ander platform is een volledig ontwikkelproject, niet een configuratiewijziging.

3. Datalock-in

Embeddings, vectorindexen en getrainde modellen zitten in propriëtaire formaten. De directe kosten zijn egress fees en overdrachtstijd; de indirecte kosten zijn herformatteren, hervalideren en opnieuw indexeren. Bij grote datasets kan dat weken kosten.

4. Governance-lock-in

Sinds 2 augustus 2026 handhaaft de Europese Commissie de verplichtingen voor aanbieders van general-purpose AI-modellen — met boetes tot 3% van de wereldwijde omzet. De documentatie die je nodig hebt om aan die verplichtingen te voldoen — risicobeoordelingen, auditlogs, transparantierapportages — zit vaak vast in het platform van je leverancier. Wisselen betekent die documentatie opnieuw opbouwen.

5. Organisatiekennis-lock-in

Je team heeft geleerd hoe het specifieke platform werkt. De prompt-engineers kennen de eigenaardigheden van het model. De developers weten hoe de API zich gedraagt. Die kennis is niet overdraagbaar — het is opnieuw opbouwen bij een nieuwe leverancier.

Het verraderlijke is dat deze lagen vermenigvuldigend werken, niet optelbaar. Een organisatie die 60% vastzit op het model, 70% op orchestratie en 80% op data, heeft geen gecombineerde switchkost van 70% — maar een die het product is van alle drie de afhankelijkheden tegelijk.

Builder.ai: wat er gebeurt als je leverancier verdwijnt

In mei 2025 ging Builder.ai failliet — een bedrijf dat op het hoogtepunt 1,3 miljard dollar waard was. Duizenden bedrijven verloren van de ene op de andere dag de toegang tot de applicaties waarvoor ze tienduizenden euro's hadden betaald. De code, de data, de workflows: alles zat in het platform van Builder.ai.

Eén gedocumenteerd geval laat zien wat dat in de praktijk kost. NexGen Manufacturing besteedde 315.000 dollar en drie maanden aan het migreren van 40 AI-workflows naar een ander platform — kosten die met een abstractielaag grotendeels te vermijden waren geweest.

Builder.ai is geen uitzondering. In 2026 nam het aantal AI-faillissementen toe, en Gartner schat dat migratie van een verdwenen SaaS-platform gemiddeld 6 tot 12 maanden duurt en 500.000 dollar kost. Het risico is niet hypothetisch — het is aan het materialiseren.

Hoe groot is het probleem?

De cijfers zijn eenduidig. Kai Waehner's analyse van het enterprise agentic-AI-landschap (Q2 2026) vat de stand van zaken samen:

• 81% maakt zich zorgen — de overgrote meerderheid van enterprise-leiders erkent dat AI-afhankelijkheid een risico is.
• 6% kan pijnloos wisselen — slechts een fractie denkt zonder materiële verstoring van AI-provider te kunnen veranderen. Dat is een kloof van 75 procentpunt tussen bewustzijn en paraatheid.
• 45% is al gehinderd — bijna de helft zegt dat vendor lock-in hen al heeft belemmerd bij het overstappen naar betere tools.
• 37% gebruikt vijf of meer modellen — het aantal organisaties dat meerdere modellen in productie draait stijgt, maar de switchkosten stijgen mee.

"Only 6% of enterprise leaders believe they could switch their primary AI provider without material disruption." — Enterprise Agentic AI Landscape Q2 2026

Vijf strategieën om lock-in te voorkomen

Het goede nieuws: AI vendor lock-in is een ontwerpkeuze, geen onvermijdelijkheid. Organisaties die vanaf het begin flexibiliteit inbouwen, reduceren hun migratiekosten met 60 tot 80%. Dit zijn de vijf structurele beslissingen die dat mogelijk maken:

1. Bouw een abstractielaag tussen je applicatie en het model

De meest effectieve investering is een AI-gateway: een tussenlaag die alle LLM-verzoeken routeert via een uniforme, leveranciersonafhankelijke API. Je applicatiecode praat met de gateway; de gateway routeert naar OpenAI, Anthropic, een zelf-gehost model of een combinatie — zonder codewijzigingen bij een overstap.

In Laravel kun je dat realiseren met de AI SDK, die sinds Laravel 13 standaard leveranciersabstractie biedt. Je applicatie stuurt een verzoek, en de provider wordt een configuratiekeuze in plaats van een architectuurbeslissing.

2. Houd orchestratielogica in je eigen codebase

Dit is waar de meeste organisaties het verkeerd doen. Ze bouwen hun agent-workflows, beslisbomen en tool-integraties in het platform van de AI-leverancier — omdat dat het snelst werkt. Maar het is ook de snelste route naar lock-in, want dat is het werk dat je niet kunt exporteren.

De oplossing: bouw je orchestratielogica in je eigen applicatie. De AI-provider levert het taalmodel; jij beheert de flow, de tools en de beslisregels. Dat kost meer initieel, maar het maakt je onafhankelijk van welk platform dan ook.

3. Gebruik open standaarden voor tool-integratie

Het Model Context Protocol (MCP) is het meest concrete voorbeeld van hoe open standaarden lock-in voorkomen. MCP is ontworpen als een universele koppellaag tussen AI-modellen en externe systemen — vergelijkbaar met wat USB-C deed voor hardware. Het protocol is model-agnostisch en wordt inmiddels ondersteund door Anthropic, OpenAI, Google DeepMind en Microsoft.

In juli 2026 publiceerde de MCP-werkgroep de 2026-07-28-specificatie: een stateless protocol met OAuth 2.1-authenticatie, Server Cards voor capability discovery en Tasks voor langlopende taken. Wie zijn integraties op MCP bouwt, kan van model wisselen zonder de toollaag te herbouwen.

4. Bewaar prompts, evaluaties en data in open formaten

Sla prompts op als versioned code — niet als configuratie in een dashboard. Bewaar fine-tuning-datasets in JSONL of Parquet. Exporteer evaluatieresultaten regelmatig. Hoe meer van je AI-infrastructuur in open, draagbare formaten bestaat, hoe minder je vastzit aan de opslaglaag van je leverancier.

Een praktische vuistregel: als je morgen je AI-provider zou opzeggen, hoeveel van je werk kun je meenemen in bestanden die je zelf kunt lezen? Alles wat je niet kunt exporteren, is lock-in.

5. Verdeel het risico over meerdere providers

Je hoeft niet alles bij dezelfde leverancier af te nemen. Gebruik Claude voor redeneerwerk, GPT-4o voor brede tekstvragen en een open-source model voor privacygevoelige taken die je lokaal wilt draaien. 37% van de organisaties draait inmiddels vijf of meer modellen in productie — niet uit luxe, maar als bewuste risicospreiding.

Met een abstractielaag op zijn plek is die spreiding geen extra complexiteit maar een configuratiebeslissing.

Waarom het MKB extra kwetsbaar is

Grote organisaties hebben enterprise-architecten, inkoopteams en proof-of-concept-trajecten. Het MKB heeft die luxe zelden. Een ondernemer die een AI-tool kiest, doet dat op basis van een demo, een aanbeveling en een maandbedrag dat betaalbaar lijkt. De vijf lagen van lock-in zijn op dat moment onzichtbaar.

Het patroon is herkenbaar uit de low-code-wereld: lage instapkosten, snelle resultaten, en dan op een ochtend de ontdekking dat je niet weg kunt zonder alles opnieuw te bouwen. Bij AI komt daar een extra dimensie bij: de kennis die je team opbouwt rond een specifiek model en platform is niet overdraagbaar. Hoe langer je wacht, hoe meer je team gespecialiseerd raakt in één ecosysteem.

Een paar vragen die helpen bij de keuze:

• Kan ik mijn prompts en configuratie exporteren? — Niet als PDF maar als bruikbare bestanden die ik in een ander systeem kan laden.
• Draait de logica in mijn omgeving of in het platform? — Orchestratie die alleen binnen het platform bestaat, is het duurste type lock-in.
• Wat gebeurt er als deze leverancier morgen stopt? — Het Builder.ai-scenario is niet hypothetisch. Software escrow is voor maatwerk; voor AI heb je draagbaarheid nodig.
• Kan ik van model wisselen zonder code te herschrijven? — Als het antwoord nee is, heb je modellock-in.

De rol van maatwerk

Hier zit de crux: AI vendor lock-in is fundamenteel een architectuurprobleem, geen licentieprobleem. Het gaat niet om welke tool je kiest, maar om hoe je die tool integreert. Een SaaS-tool die je orchestratielogica vasthoudt in een propriëtair platform, creëert afhankelijkheid — ongeacht hoe goed het product is.

Maatwerksoftware die je eigen AI-gateway bouwt, je orchestratielogica in je eigen codebase houdt en integreert via open standaarden als MCP, geeft je de flexibiliteit om van model te wisselen wanneer je wilt. De AI-provider is dan een inwisselbare laag in je stack, geen fundament waar alles op rust.

Dat is geen theoretisch voordeel. Met de snelheid waarmee het AI-landschap verandert — nieuwe modellen elke paar maanden, prijsdalingen van 90% in een jaar, providers die geopolitiek onbereikbaar worden — is de mogelijkheid om te wisselen geen luxe maar een bedrijfskritische eigenschap.