10 juni 2026

Self-hosting, Europese cloud en vendor lock-in, waar zit je nou echt vast?

"We zitten nergens aan vast hoor, het is maar een API-key." Die zin hoorde ik van een productmanager bij een softwarebedrijf dat al twee jaar AI-features bouwt op één Amerikaanse modelprovider. Toen ze een ander model wilden proberen, bleek het verwisselen van die API-key inderdaad een middag werk. Daarna begon het echte werk: prompts die zich ineens anders gedroegen, een zoekfunctie die kapot ging omdat de embeddings niet uitwisselbaar waren, evaluatiegeschiedenis die in het dashboard van de oude leverancier woonde, en twee features die gebouwd waren op functies die alleen die ene provider aanbiedt. De geschatte overstaptijd ging van een middag naar een kwartaal.

Dat is vendor lock-in bij AI. Niet een slot op de deur, maar honderd draadjes die je zelf hebt gesponnen zonder het door te hebben.

Ik heb eerder geschreven over waarom je data in Europa zou willen houden en over de technische kant van zelf een model hosten. Dit stuk gaat over de laag daarboven: de strategie. Waar zit afhankelijkheid echt, wat is opzegbaarheid waard, wat heeft Europa eigenlijk te bieden, en hoe verdeel je je AI-landschap verstandig over zelf draaien, Europese partijen en hyperscalers.

Lock-in zit niet in het model

De meeste mensen denken bij AI-afhankelijkheid aan het model. Dat is gek genoeg het minst vastzittende onderdeel. Vrijwel elke serieuze provider en elk open-source serveerprogramma spreekt tegenwoordig hetzelfde API-dialect, het formaat dat OpenAI populair maakte. Een model omwisselen is technisch zelden het probleem.

Het probleem zit in alles wat eromheen is gegroeid.

Je prompts, om te beginnen. Een prompt die maanden is bijgeschaafd is geen tekstje, het is een afgesteld instrument. Afgesteld op de eigenaardigheden van één specifiek model: hoe het instructies opvolgt, waar het de mist ingaat, hoe het formatteert. Zet diezelfde prompt op een ander model en je krijgt andere uitkomsten. Niet per se slechtere, maar andere. Alles moet opnieuw getest, en als je geen evaluatieset hebt opgebouwd, weet je niet eens wat "even goed" betekent.

Je embeddings zijn een hardere vorm van hetzelfde. Een embedding-model geeft elke tekst een plek op een betekeniskaart, en elke leverancier tekent zijn eigen kaart. Vectoren van het ene model zeggen niets in de ruimte van het andere. Heb je een half miljoen documentfragmenten door de embedding-API van één leverancier gehaald, dan is je hele vectordatabase aan die leverancier getrouwd. Overstappen betekent alles opnieuw verwerken: rekentijd, kosten, en hertesten of je zoekresultaten nog kloppen. En als die leverancier het model uitfaseert, neemt hij die beslissing voor jou.

Dan je logs, gespreksgeschiedenis en evaluaties. Wie het dashboard van de provider gebruikt als geheugen van zijn AI-systemen, ontdekt bij vertrek dat dat geheugen niet meeverhuist. Fine-tunes zijn nog strenger: een fine-tune van een gesloten model kun je niet downloaden. Dat is geen product dat je bezit, het is een dienst die je huurt.

Vervolgens je integraties. Elke leverancier biedt handige extraatjes: ingebouwde documentopslag, kant en klare assistenten, batchverwerking, tooltjes in de SDK. Elk extraatje scheelt vandaag bouwtijd en is morgen een draadje extra. Tien handige features later heb je een applicatie die nergens anders meer past.

En het diepste niveau: je werkprocessen en je mensen. Teams bouwen gewoontes rond een tool. Promptbibliotheken, reviewafspraken, trainingen, de manier waarop de klantenservice haar antwoorden voorbereidt. Die organisatorische laag migreert het langzaamst van allemaal, en hij staat in geen enkel architectuurdiagram.

Tel het op en je ziet waarom "het is maar een API" een gevaarlijke zin is. De API is verwisselbaar. Het systeem dat je eromheen hebt gebouwd niet vanzelf.

Wat opzegbaarheid waard is

Hier hoort een nuchtere vraag bij: is dat erg? Lock-in is niet immoreel. Elke keuze voor gereedschap schept afhankelijkheid, dat was bij je boekhoudpakket ook al zo. De vraag is niet of je afhankelijk bent, maar of je het bewust bent, en wat het kost om eruit te stappen als dat moet.

Opzegbaarheid heeft drie soorten waarde.

De eerste is onderhandelingspositie. Een leverancier die weet dat jij binnen een maand weg kunt, praat anders over prijzen en voorwaarden dan een leverancier die weet dat jij een kwartaal migratie voor je boeg hebt. Die waarde verzilver je elk contract opnieuw, ook als je nooit vertrekt.

De tweede is continuïteit. Modelproviders wijzigen prijzen, faseren modellen uit en passen voorwaarden aan, dat is gewoon het tempo van deze markt. Daar komt voor Europese organisaties een geopolitieke laag bij die ik voorzichtig formuleer: de afhankelijkheid van Amerikaanse techleveranciers staat hier inmiddels op bestuurlijke agenda's, en niemand kan voorspellen hoe die verhouding zich ontwikkelt. Continuïteitsplanning gaat niet over voorspellen maar over je afhankelijkheden kennen.

De derde is de minst gehoorde: je migreert sowieso een keer. Modellen verbeteren snel, prijzen verschuiven, en wat vandaag het beste model is, is het over een jaar niet meer. Een organisatie die makkelijk kan wisselen, profiteert van elke verbetering in de markt. Een organisatie die vastzit, kijkt toe.

Het belangrijkste inzicht: opzegbaarheid is geen eigenschap van je contract, maar van je architectuur. In je contract staat dat je per maand kunt opzeggen. In je architectuur staat of dat ook echt kan. En opzegbaarheid is iets dat je bouwt op het moment dat je het niet nodig hebt, want gedwongen migreren onder tijdsdruk is altijd de duurste variant.

Het Europese cloudlandschap, zonder romantiek

Dan de vraag waar je heen kunt. Eerst de ongemakkelijke waarheid: er bestaat geen Europese hyperscaler. Het grootste deel van de Europese cloudmarkt is in handen van drie Amerikaanse partijen, en geen Europese aanbieder komt qua omvang en dienstenbreedte in de buurt. Wie doet alsof dat anders is, helpt de discussie niet.

Maar voor AI-infrastructuur heb je geen hyperscaler nodig. Je hebt rekenkracht, GPU's, opslag en netwerk nodig, en dat is precies waar Europese partijen sterk in zijn. Aanbieders als Hetzner, OVHcloud, Scaleway, Leaseweb, IONOS en StackIT leveren degelijke infrastructuur, vaak tegen scherpe prijzen, onder Europees recht en Europees eigendom. Het GPU-aanbod was lang dun, maar groeit zichtbaar; er zijn inmiddels ook gespecialiseerde Europese GPU-aanbieders bijgekomen. Wij draaien de modellen achter HostYourAI op dit soort Europese infrastructuur, en de praktijk is nuchter: kale infrastructuur is hier gewoon goed te krijgen.

Wat je bij Europese partijen wel minder krijgt, is de enorme catalogus aan managed services waar hyperscalers mee lokken. Geen honderdvijftig kant en klare diensten, vaker een kale server of een basale Kubernetes-omgeving. Dat betekent meer zelf beheren. En dat is precies de eerlijke ruil die op tafel hoort: je wisselt gemak in voor grip. Wie die ruil niet wil benoemen, verkoopt sprookjes, in beide richtingen.

Nog een nuance: de hyperscalers bieden inmiddels zelf "soevereine" varianten aan, met datacenters in Europa en extra waarborgen. Dat lost data residency op, de fysieke plek van je data. Maar het bedrijf erachter blijft Amerikaans, en daarmee blijft de discussie over Amerikaanse wetgeving zoals de CLOUD Act relevant voor je beoordeling. Of dat voor jouw situatie een probleem is, hangt af van je data en je toezichthouder. Dit is geen juridisch advies, maar wel een onderscheid dat je moet kennen: residency is waar je data staat, soevereiniteit is wie er uiteindelijk over kan beslissen.

Een gelaagd denkmodel: zelf, Europees, hyperscaler

Hoe verdeel je dit nu praktisch? Niet met één principe voor alles, maar in lagen. Ik gebruik er drie.

Laag één: wat je zelf draait. Dit is kleiner dan mensen denken, en strategischer. Het gaat om de onderdelen die samen het geheugen en de stuurknuppel van je AI-landschap vormen: je prompts en configuratie in je eigen versiebeheer, je vectordatabase met de embeddings van je interne kennis, je model gateway waar al het AI-verkeer doorheen loopt, en je logs en evaluaties. Geen van deze onderdelen vraagt zware hardware; een gateway en een vectordatabase draaien op een bescheiden server. Maar wie deze laag bij een leverancier legt, legt daar de regie neer. Dit is je exit-vermogen, en dat besteed je niet uit.

Laag twee: wat bij een Europese partij mag. Het zware werk met gevoelige data: GPU-inference van open modellen op documenten met persoonsgegevens, je databases, je backups, de applicaties eromheen. Je huurt de hardware, het beheer blijft deels bij jou, het juridische regime blijft Europees. Voor een zorginstelling die behandelverslagen samenvat of een gemeente die brieven verwerkt, is dit de logische plek.

Laag drie: wat prima bij een hyperscaler of Amerikaanse API kan. Werk met publieke of ongevoelige data, experimenten, marketingteksten, en taken waar de allerbeste modellen echt verschil maken en de data dat toelaat. De beste modellen komen op dit moment nu eenmaal vaak uit de VS. Dogmatisch weigeren kost kwaliteit zonder dat er een risico tegenover staat.

De lagen werken alleen met drie verbindingsregels. Eén: al het modelverkeer loopt door je eigen gateway, in het OpenAI-compatible formaat, zodat providers verwisselbaar blijven. Twee: gebruik voor je interne kennis een open embedding-model dat je zelf kunt blijven draaien, zodat je betekeniskaart van jou is. Drie: logs en evaluaties stromen naar je eigen opslag, niet alleen naar het dashboard van een leverancier.

En één gewoonte erbij: test je opzegbaarheid. Verhuis één keer per half jaar een onbelangrijke workload naar een andere provider, als brandoefening. Een exit-plan dat alleen op papier bestaat, is geen plan maar een wens.

Waar het misgaat

Drie valkuilen zie ik steeds terug. De eerste: alles zelf willen draaien uit principe, en vervolgens verzuipen in beheer, updates en beveiliging. Self-hosting is geen deugd, het is een verantwoordelijkheid, en je moet hem alleen nemen waar hij iets oplevert. De tweede is de spiegelbeeldige: een "multi-cloud strategie" op een slide, terwijl in werkelijkheid elke workload met leverancierspecifieke features is vastgeklonken. De derde is subtieler: je gateway of AI-platform afnemen als SaaS bij wéér een leverancier, waarmee je je anti-lock-in-laag zelf tot lock-in maakt. De stuurknuppel uitbesteden aan een derde partij verplaatst het probleem, het lost het niet op.

Tot slot

Lock-in is geen schande, het is een prijs. Soms is die prijs het waard: een leverancier die je veel werk uit handen neemt, mag best wat afhankelijkheid kosten. De fout zit in het onbewust betalen. De productmanager uit het begin dacht dat hij een API-key huurde, en bleek een kwartaal migratie te hebben opgebouwd, draadje voor draadje.

Begin dus niet bij de vraag "moeten we naar Europese cloud" of "moeten we self-hosten". Begin bij de inventarisatie: waar zitten onze draadjes? Welke prompts, embeddings, logs en features zijn met welke leverancier vergroeid, en wat kost het om ze los te maken? Daarna verdelen de lagen zich bijna vanzelf: regie zelf draaien, gevoelig werk Europees, de rest waar het gereedschap het beste is. Niet uit principe, maar omdat je dan elk draadje zelf hebt gekozen.

↘︎ ALLE ARTIKELEN