AI zou bedrijven een voorsprong geven. Het kan ook een nieuwe afhankelijkheid creëren
Nog een paar jaar geleden ging het gesprek over vendor lock-in vooral over cloud, ERP-systemen, databases of kernplatforms.
Bedrijven stelden zich vragen: Kunnen we de applicatie naar een andere cloudprovider verplaatsen? Kunnen we van database veranderen? Kunnen we weg van een specifiek systeem?
Vandaag komt daar een nieuw element bij - kunstmatige intelligentie.
Organisaties bouwen steeds vaker systemen die gebruikmaken van taalmodellen, generatieve AI, RAG-oplossingen, procesautomatisering en AI-agenten. Modellen worden onderdeel van applicaties, verkoopprocessen, klantenservice, documentanalyse, beslissystemen en het dagelijkse werk van teams.
In de praktijk betekent dit dat een bedrijf afhankelijk kan raken niet alleen van specifieke software, maar ook van een specifieke leverancier van de intelligentie die door zijn systemen wordt gebruikt.
En hier ontstaat het probleem. Want iets gebruiken is iets anders dan er afhankelijk van zijn.
Dat is precies het verschil tussen bewuste technologische afhankelijkheid en vendor lock-in.
Wat is AI Vendor Lock-in precies?
Vendor lock-in betekent een situatie waarin een organisatie zo sterk met één technologieleverancier verbonden is dat overstappen naar een concurrerende oplossing moeilijk, duur, tijdrovend of riskant wordt.
In de wereld van AI kan dit veel meer vormen aannemen dan klassieke afhankelijkheid van één API.
Een bedrijf kan afhankelijk zijn van:
- een specifiek AI-model,
- een specifieke API-leverancier,
- een bepaald communicatieformaat,
- functies die uitsluitend bij één leverancier beschikbaar zijn,
- een agentensysteem,
- cloudinfrastructuur,
- de manier van dataopslag,
- een specifiek embeddings-mechanisme,
- een bepaald RAG-systeem,
- de manier waarop agenten tools aanroepen,
- prompts die geoptimaliseerd zijn voor een specifiek model,
- de competenties van het team die rond één ecosysteem zijn opgebouwd.
Dus de vraag: "Gebruiken we OpenAI?"
is beslist te simpel.
Een betere vraag is: "Hoe moeilijk zou het voor ons zijn om van AI-leverancier te wisselen als we dat over zes maanden zouden moeten doen?"
Als het antwoord is: "We weten het niet." - dan kan dat het eerste waarschuwingssignaal zijn.
OpenAI, Anthropic, Google - maakt de keuze van leverancier uit?
Op de markt bestaan meerdere sterke ecosystemen van modellen en AI-diensten, zoals die van OpenAI, Anthropic en Google.
Elke leverancier ontwikkelt eigen modellen, API's, tools en extra diensten.
Het probleem is niet dat één van hen "slecht" is. Integendeel.
Het gebruik van kant-en-klare, hoogwaardige modellen is vaak de beste zakelijke keuze. Niet elk bedrijf moet een eigen model trainen. Niet ieder bedrijf heeft eigen GPU-infrastructuur nodig. Niet iedereen zou de volledige AI-stack van nul moeten opbouwen.
Een externe leverancier gebruiken maakt het mogelijk sneller op de markt te komen, initiële kosten te beperken en te profiteren van technologie die zelfstandig bouwen buiten het bereik van de meeste organisaties zou liggen.
Het probleem ontstaat wanneer een bedrijf de leverancier niet langer als vervangbaar onderdeel ziet, maar het hele product ontwerpt alsof die leverancier de komende 10 jaar onveranderd zal blijven bestaan.
En dat kun je niet garanderen...
Modellen worden geüpdatet, oudere versies worden uitgefaseerd, prijzen veranderen, limieten veranderen, API's veranderen, nieuwe modellen verschijnen, licentievoorwaarden wijzigen, concurrentiemogelijkheden veranderen.
Dat is normale dynamiek in de technologiesector.
Daarom zou AI-architectuur niet alleen moeten vragen: "Welk model is vandaag het beste?"
maar ook: "Welke prijs betalen we als we over een jaar van model willen wisselen?"
De grootste valkuil - "we veranderen gewoon de API"
Op het eerste gezicht lijkt migratie triviaal.
We hebben een applicatie. De applicatie stuurt een verzoek naar het model. Het model antwoordt. We veranderen de leverancier. Klaar...
In werkelijkheid kan het er heel anders uitzien.
Stel je een applicatie voor die twee jaar rondom één model is ontwikkeld.
In die tijd heeft het team:
- honderden prompts gemaakt,
- de inhoud ervan geoptimaliseerd,
- het antwoordformat aangepast,
- een RAG-systeem gebouwd,
- tool calling geconfigureerd,
- agenten gebouwd,
- workflows ontworpen,
- tests voorbereid,
- gebruikers geleerd omgaan met het systeem.
Na twee jaar blijkt het model niet langer in de gebruikte versie beschikbaar te zijn.
Of de prijs stijgt, of een concurrerend model is veel beter, of het bedrijf wil een deel van de data naar een ander omgeving verplaatsen.
Theoretisch volstaat het om de API te wijzigen. In de praktijk kan het nodig zijn om de volledige systeemlogica opnieuw te testen.
Waarom?
Omdat modellen niet identiek zijn:
- Ze interpreteren instructies verschillend.
- Ze verschillen in de kwaliteit van antwoorden.
- Ze gedragen zich anders in lange contexten.
- Ze gaan verschillend om met tools.
- Ze ondersteunen structured output anders.
- Ze verschillen in multimodaliteit.
- Ze verschillen in snelheid.
- Ze verschillen in prijs.
- Ze gedragen zich ook anders in randgevallen.
Daarom kan migratie tussen modellen meer lijken op het migreren van een volledig bedrijfscomponent dan op het simpelweg vervangen van een URL.
Vijf niveaus van AI Vendor Lock-in
Het is nuttig om naar vendor lock-in breder te kijken.
1. Model lock-in
Het eenvoudigste niveau.
De applicatie is geoptimaliseerd voor een specifiek model.
Een prompt werkt uitstekend met het ene model, maar minder met een ander.
Het systeem leunt op specifieke mogelijkheden van dat model.
Verandering vereist her-tuning.
2. API lock-in
Het systeem maakt direct gebruik van functies van een specifieke leverancier.
Hoe meer unieke functies we gebruiken, hoe moeilijker migratie kan worden.
Het gaat niet alleen om tekstgeneratie.
Belangrijk zijn ook:
- structured outputs,
- function calling,
- tool calling,
- multimodaliteit,
- contextbeheer,
- veiligheidsmechanismen,
- agentensystemen.
3. Data lock-in
Data kan op een manier worden opgeslagen die sterk met een ecosysteem verbonden is.
Dit betreft ook:
- embeddings,
- vectorindexen,
- metadata,
- interactiegeschiedenis,
- RAG-configuraties.
Migratie kan vereisen dat data niet alleen wordt verplaatst, maar ook opnieuw wordt verwerkt.
4. Architectuur lock-in
Dit niveau is veel ernstiger.
De hele applicatie is rond één leverancier ontworpen.
Zijn mechanismen zitten op veel plekken in het systeem.
In dat geval vervang je niet één component.
Je herbouwt een deel van de architectuur.
5. Organisatorische lock-in
Dit is vaak het meest onderschatte probleem.
Het team kent één ecosysteem.
Alle competenties zijn rond één oplossing geconcentreerd.
Documentatie, procedures, tests en know‑how zijn verbonden aan één leverancier.
Zelfs als het technisch mogelijk is om van model te wisselen, heeft de organisatie niet de mensen die zo'n verandering kunnen uitvoeren.
Dan wordt vendor lock-in geen puur technologisch probleem.
Het wordt een bedrijfsprobleem.
Lost Multi-Model het probleem op?
Een natuurlijke reactie is: "Als één leverancier een risico is, gebruiken we er meerdere."
Dat is echter niet altijd de beste strategie.
Multi-model architectuur heeft kosten.
Je moet beheren:
- meerdere API's,
- verschillende limieten,
- verschillende prijsmodellen,
- verschillende kwaliteitsniveaus,
- verschillende antwoordformaten,
- tests,
- monitoring,
- veiligheid.
Het systeem wordt complexer.
Daarom zou het doel niet moeten zijn: "We moeten vijf leveranciers gebruiken."
Het doel moet zijn: "We moeten de mogelijkheid hebben van leverancier te wisselen als het bedrijf dat nodig heeft."
Dat is het wezenlijke verschil.
Niet elk bedrijf heeft Multi-Model nodig.
Elk bedrijf zou echter moeten weten hoe een migratie naar een ander model eruit zou zien.
AI Gateway en Model Gateway - de laag die de applicatie van de leverancier scheidt
Een manier om afhankelijkheid te verminderen is het gebruik van een tussenlaag.
Die kan fungeren als AI Gateway of Model Gateway.
In vereenvoudigde vorm kan de architectuur er zo uitzien:
Business-applicatie
↓
AI abstractielaag
↓
Modelrouting
↓
Provider-adapter
↓
OpenAI / Anthropic / Google / open-weight model / lokaal model
Dankzij deze opzet hoeft de businesslogica van de applicatie de details van elke leverancier niet direct te kennen.
We kunnen een laag hebben die verantwoordelijk is voor:
- modelkeuze,
- routing,
- fallbacks,
- kostencontrole,
- monitoring,
- logging,
- veiligheidsbeleid,
- beheer van limieten.
Bij uitval van één leverancier kan het systeem proberen een ander model te gebruiken.
Bij prijsstijgingen kunnen we de routing aanpassen.
Bij de komst van een beter model kunnen we tests uitvoeren en beslissen over migratie.
Dat betekent niet dat verandering altijd pijnloos is.
Het betekent wel dat die verandering als een realistische optie is ontworpen.
Model Router - AI hoeft niet altijd hetzelfde model te kiezen
Nog interessanter is modelrouting.
Stel je een systeem voor dat verschillende taken ontvangt.
Eenvoudige taak: "Vat deze tekst samen."
Die kan naar een snel en goedkoop model worden gestuurd.
Complexere taak: "Analyseer dit document en maak een gedetailleerde aanbeveling."
Die kan naar een krachtiger model gaan.
Een taak die beeldanalyse vereist kan naar een multimodaal model gaan.
Het systeem kan dynamisch het model kiezen dat bij de taak past.
Dat maakt optimalisatie van:
- kosten,
- kwaliteit,
- reactietijd,
- beschikbaarheid.
In die opzet wordt de AI-leverancier geen integraal onderdeel van de businesslogica.
Hij wordt één element van de infrastructuur.
En dat is een belangrijke architectonische verschuiving.
Abstractie betekent niet dat alle modellen hetzelfde zijn
Hier moet je voor één valkuil oppassen.
Je kunt een eigen functie maken: generateText() en denken dat het probleem is opgelost.
Dat is het niet.
Modellen zijn geen inwisselbare LEGO-blokken.
Als een applicatie specifieke mogelijkheden van een model gebruikt, kan een simpele abstractielaag het probleem alleen verbergen.
Goede architectuur zou dus moeten abstraheren van de leverancier, maar tegelijkertijd bewust omgaan met de verschillen tussen modellen.
In de praktijk betekent dit dat de AI-laag moet weten dat een model verschillende:
- mogelijkheden,
- limieten,
- kosten,
- kwaliteitsniveaus,
- functies,
- contexten,
- parameters kan hebben.
Provider-agnostisch ontwerpen mag niet betekenen dat je doet alsof elk model hetzelfde is.
Het betekent dat het systeem bewust kan profiteren van de verschillen tussen modellen.
Evals - zonder die is AI-migratie gokken
Een van de belangrijkste onderdelen van een architectuur die bestand is tegen verandering zijn evals, systematische tests van modelkwaliteit.
Stel dat we 1000 echte use-cases hebben. We draaien ze op het huidige model. Daarna op het nieuwe. We vergelijken de resultaten.
We controleren:
- kwaliteit,
- correctheid,
- compleetheid,
- hallucinaties,
- afstemming op vereisten,
- reactietijd,
- kosten.
Pas dan kunnen we zeggen: "Het nieuwe model is goed genoeg."
Zonder evals kan migratie op een experiment lijken. Met evals wordt het een engineeringproces.
Daarom moet een bedrijf dat AI gebruikt eigen testsets bouwen. Niet alleen de API testen, maar de eigen business-case. Dat is een enorm verschil.
Prompt kan ook een bron van vendor lock-in zijn
Prompts behandelen we vaak als tekst. In de praktijk kunnen ze deel van de businesslogica worden.
Als een team maandenlang instructies optimaliseert voor een specifiek model, kan een prompt gaan werken als een stuk code.
Daarom zouden prompts:
- geversioneerd,
- getest,
- gedocumenteerd,
- gemonitord moeten worden.
Het is ook nuttig te weten welke prompts kritisch zijn voor het systeem. Als modelwissel hun effectiviteit schaadt, moeten we weten waar we moeten zoeken.
In volwassen AI-systemen zou prompt engineering steeds meer onderdeel van software-engineering moeten worden.
Open-weight en eigen modellen - is dat ontsnappen aan vendor lock-in?
Open-weight modellen en de mogelijkheid om modellen on-premises te draaien vergroten de controle over technologie.
Maar dat betekent niet automatisch volledige onafhankelijkheid.
Als we een model naar onze eigen infrastructuur verplaatsen, hebben we nog steeds nodig:
- GPU's,
- infrastructuur,
- MLOps,
- monitoring,
- security,
- updates,
- competenties.
We kunnen dus de afhankelijkheid van de modelleverancier verminderen, maar tegelijkertijd de afhankelijkheid van de infrastructuurleverancier vergroten. Of we draaien open-weight modellen in de cloud. Dan verschuift het probleem weer naar een ander niveau. Daarom is het zinvol onafhankelijkheid technologisch breder te bekijken.
Er bestaat geen compleet afhankelijkheidsvrij systeem.
Er bestaat wel een systeem waarin afhankelijkheden:
- bekend,
- beheersbaar,
- meetbaar,
- vervangbaar zijn.
De gevaarlijkste vendor lock-in zit misschien in het hoofd van het team
Stel je een bedrijf voor dat één AI-leverancier gebruikt.
Technisch kunnen ze van model wisselen. Maar niemand weet hoe dat moet.
Het team kent geen alternatieven.
Er zijn geen benchmarks.
Geen evals.
Geen tests.
Geen ervaring met andere modellen.
Alle oplossingen zijn rond één ecosysteem gebouwd.
Dat is organisatorische lock-in.
Daarom vereist weerstand tegen vendor lock-in ook investering in competenties.
Het team moet begrijpen:
- hoe modellen werken,
- wat de verschillen tussen leveranciers zijn,
- hoe abstractielagen te bouwen,
- hoe modellen te testen,
- hoe kwaliteit te meten,
- hoe kosten te beheren,
- hoe migratie uit te voeren.
Het gaat niet om elke ontwikkelaar elk API te laten kennen.
Het gaat erom dat de organisatie niet technologisch blind is voor alternatieven.
Wanneer kan vendor lock-in acceptabel zijn?
Vendor lock-in is niet altijd slecht.
Soms is bewuste afhankelijkheid een verstandige zakelijke keuze.
Als:
- de leverancier een uitzonderlijke functie biedt,
- de oplossing de time-to-market aanzienlijk verkort,
- de migratiekosten bekend zijn,
- het risico acceptabel is,
- alternatieven zwakker zijn,
- het bedrijf snelheid nodig heeft,
kan sterke binding met één leverancier gerechtvaardigd zijn.
Het probleem is niet lock-in zelf. Het probleem is onbewuste lock-in.
Een bedrijf moet weten:
- waar het van afhankelijk is,
- waarom het daarvan afhankelijk is,
- hoeveel een verandering zou kosten,
- hoe lang een migratie zou duren,
- wat de alternatieven zijn.
Pas dan kun je spreken van een bewuste architectonische keuze.
Hoe beoordeel je AI Vendor Lock-in in jouw bedrijf?
Voer een simpele audit uit.
Stel jezelf de vragen:
Kunnen we van model wisselen zonder de hele applicatie te herbouwen?
Is de businesslogica onafhankelijk van de AI-leverancier?
Zijn prompts versioned?
Hebben we eigen evals?
Hebben we regressietests voor de belangrijkste use-cases?
Kunnen we data exporteren en verplaatsen?
Kunnen we van embedding-leverancier wisselen zonder data te verliezen?
Gebruiken agenten een orchestratielaag of zijn ze direct gebonden aan een ecosysteem?
Hebben we de mogelijkheid een alternatief model in te zetten?
Hebben we fallback?
Weten we hoeveel een migratie zou kosten?
Weten we hoe lang een migratie zou duren?
Hebben we mensen die die migratie kunnen uitvoeren?
Hoe meer "nee"-antwoorden, hoe groter de afhankelijkheid.
Je kunt ook je eigen AI Portability Score maken. Bijvoorbeeld de organisatie beoordelen op vijf gebieden:
Architectuur - is de leverancier vervangbaar?
Data - kunnen we deze verplaatsen?
Modellen - hebben we alternatieven?
Evalueerbaarheid - kunnen we modellen vergelijken?
Competenties - kan het team migratie uitvoeren?
Zo'n score hoeft geen formele standaard te zijn. Het kan wel een uitstekend managementinstrument zijn.
Want soms is het grootste probleem niet vendor lock-in zelf. Het grootste probleem is dat een bedrijf niet weet dat het eraan vastzit.
Hoe ontwerp je AI-architectuur die bestand is tegen verandering?
Er is geen universele architectuur. Wel zijn er praktische regels.
Regel 1 - scheid businesslogica van de AI-leverancier
Bouw het hele systeem niet direct rond één API.
Regel 2 - gebruik abstractielaag waar zinvol
Een AI Gateway of Model Gateway kan afhankelijkheid van een leverancier beperken.
Regel 3 - versioneer prompts
Behandel ze als onderdeel van het systeem, niet als losse teksten.
Regel 4 - bouw evals
Ga er niet vanuit dat "het nieuwe model werkt".
Controleer het.
Regel 5 - test alternatieven
Je hoeft ze niet in productie te gebruiken.
Maar het is goed te weten hoe ze omgaan met jouw use-cases.
Regel 6 - beheer data
Laat je bedrijfsdata geen gijzelaar van één platform worden.
Regel 7 - documenteer afhankelijkheden
Weten waar het systeem gebonden is aan een leverancier hoort bij architectuurdocumentatie.
Regel 8 - abstraheer niet te fanatiek
Verberg de verschillen tussen modellen niet alleen om schijnbare draagbaarheid te bereiken.
Regel 9 - meet migratiekosten
Het is niet genoeg te zeggen:
"We kunnen ooit van leverancier wisselen."
Je moet weten:
"We hebben daar drie maanden en vijf mensen voor nodig."
Of:
"We kunnen dat niet doen zonder herbouw van het systeem."
Regel 10 - neem bewuste beslissingen
Soms is sterke binding met één leverancier de beste oplossing.
Maar dat moet een bewuste risicoafweging zijn.
Geen toeval.
De vraag die elke CTO zou moeten stellen
Stel dat morgen de AI-leverancier:
- de prijzen verdubbelt,
- het door ons gebruikte model intrekt,
- limieten verandert,
- een functie beperkt waarvan ons product afhankelijk is,
- niet langer aan onze compliance-eisen voldoet.
Wat doen we?
Als het antwoord is: "We wisselen van leverancier."
Volgende vraag: "Hoe lang duurt dat?"
Een dag?
Een week?
Een maand?
Een half jaar?
Of weten we het niet?
Dat is de maatstaf voor onze technologische veerkracht.
Samenvatting - het gaat niet om geen leveranciers hebben
Een systeem volledig onafhankelijk van externe AI-leveranciers bouwen kan onbetaalbaar, onnodig of zelfs onmogelijk zijn.
Daar gaat het niet om.
Het doel is niet het ontbreken van afhankelijkheden. Het doel is bewust beheer van afhankelijkheden.
We kunnen OpenAI gebruiken. We kunnen Anthropic gebruiken. We kunnen Google gebruiken. We kunnen open-weight modellen gebruiken. We kunnen verschillende oplossingen combineren.
Het belangrijkste is weten waar de grens loopt tussen: "we gebruiken technologie" en "we zijn ervan afhankelijk".
In de wereld van AI kan die grens bijzonder moeilijk te zien zijn. Vendor lock-in ontstaat niet in één dag. Het groeit geleidelijk. Eerst integreren we een API. Dan bouwen we een functie. Vervolgens voegen we RAG toe. Dan agenten. Daarna automatiseren we processen. Uiteindelijk begint het hele team volgens dat systeem te werken. En plots blijkt dat modelwissel niet langer alleen modelwissel is - het is verandering van een deel van de organisatie.
Daarom moet AI-architectuur worden ontworpen met oog voor niet alleen wat vandaag werkt, maar ook wat er gebeurt als de technologische wereld morgen verandert.
Je hoeft geen systeem te bouwen dat zonder OpenAI, Anthropic of Google werkt. Je moet wel een systeem bouwen dat ook kan blijven functioneren als één van hen wegvalt.
Dat is precies het verschil tussen het gebruiken van AI en het bewust ontwerpen van AI-technologie.
