Vendor lock-in en digitale soevereiniteit: het complete draaiboek

Je hebt nooit besloten om afhankelijk te worden van je leveranciers. Het is geslopen. Een boekhoudpakket hier, Microsoft 365 voor de hele tent, een webshop op een platform, een AI-functie in je helpdesktool, en een portaal dat een bureau ooit voor je bouwde. Elk los besluit was verstandig. Bij elkaar vormen ze een web van afhankelijkheden waarvan je de omvang niet kent, tot je iets wilt veranderen en merkt dat het niet kan: de export levert een puinhoop op, het contract rekent een afkoopsom, of niemand behalve die ene partij begrijpt nog hoe het werkt.

Dit is het draaiboek om dat web in kaart te brengen en beheersbaar te maken. Niet één systeem, maar je hele stack, in drie fasen: je herkent waar je vastzit, je weegt per systeem hoe erg dat is, en je bouwt met een realistisch plan je afhankelijkheid af. Het is voor de ondernemer, IT-verantwoordelijke of teamleider, van een MKB-bedrijf tot een afdeling van een grotere organisatie, die grip wil zonder in paniek de halve boel te verhuizen. De losse deelonderwerpen (je werkplek, je AI, je klantdata, je maatwerk) werk ik in aparte gidsen tot op de stap uit; dit stuk is de kaart eroverheen die ze verbindt.

Waarom afhankelijkheid een portfoliovraag is

Vendor lock-in, in gewoon Nederlands leveranciersafhankelijkheid, is geen ja of nee maar een schaal, en hij kent vijf vormen die vaak tegelijk spelen: je data zit opgesloten, het formaat is propriëtair, het contract bindt je, de kennis zit bij een ander, of je hangt aan één ecosysteem. Hoe je die per systeem meet en doorbreekt, staat in mijn gids over wat vendor lock-in precies is en hoe je er per systeem uit komt. Wat dit draaiboek daaraan toevoegt is de laag eroverheen: je beoordeelt niet één tool, je beoordeelt je hele portefeuille.

Waarom dat verschil telt, zie je zodra je uitzoomt. De Europese cloud draait op een handjevol Amerikaanse bedrijven: volgens Synergy Research hebben Amazon, Microsoft en Google samen ongeveer zeventig procent van de Europese cloudmarkt in handen, tegenover vijftien procent voor Europese aanbieders. Als je werkplek, je klantdata en je AI alledrie bij dezelfde één of twee partijen liggen, is je risico niet de som van drie losse afhankelijkheden maar één geconcentreerde: één prijsverhoging, één beleidswijziging, één storing raakt alles tegelijk. Waar je data staat en van wie je software is, is daarmee geen politiek standpunt maar een bedrijfsrisico, eentje dat op dezelfde plank hoort als een te grote klant of een onmisbare medewerker.

Wat je nodig hebt

De scan hierna kost vooral aandacht, geen budget. Zorg dat je dit klaar hebt liggen voordat je begint:

• Een lijst van je kernsystemen: boekhouding en ERP, CRM, webshop, werkplek en cloud, de AI-tools die je echt gebruikt, en je maatwerk.
• Toegang tot je contracten, algemene voorwaarden, verwerkersovereenkomsten en de subverwerkerslijsten van je leveranciers.
• Vijf minuten per systeem om de export-knop echt te testen, in plaats van aan te nemen dat hij werkt.
• Waar mogelijk iemand die technisch kan beoordelen of een export ook bruikbaar is, en niet alleen bestaat.
• Een eenvoudige scoretabel waarin je per systeem vijf assen kunt vastleggen. Een spreadsheet volstaat.

Het draaiboek: herkennen, wegen, afbouwen

Grip op leveranciersafhankelijkheid krijg je in drie fasen: je herkent waar je vastzit door elk kernsysteem op vijf assen te scoren, je weegt elk systeem op kriticaliteit maal lock-in zodat je weet wat eerst moet, en je bouwt gefaseerd af met per systeem een van vier routes. Geen big bang, maar golven met een vangnet.

Werk de zes stappen in deze volgorde af:

Stap 1: Inventariseer je hele stack

Breng eerst alles in kaart. Maak een lijst van elk systeem dat een kernproces draait of klantdata verwerkt, en noteer per systeem de leverancier, waar het draait, wat erin zit en of het je bedrijf platlegt als het wegvalt. Vergeet de onzichtbare afhankelijkheden niet: je e-mailprovider, je back-updienst, je analytics en de AI-motor onder een tool die je vooral als iets anders kent. Je kunt niets wegen wat je niet ziet, en juist de vergeten hoeken zijn waar lock-in het langst onopgemerkt groeit.

Stap 2: Scoor elk systeem op vijf assen

Geef elk systeem een lock-in-score. Loop per systeem vijf assen langs en geef elke as 0 punten (vast), 1 (deels) of 2 (vrij): data-export (kun je er zonder de leverancier uit?), dataformaat (open en gangbaar, of propriëtair?), contract (redelijke opzegtermijn, geen exit-boete?), kennis (is vastgelegd hoe het werkt?) en koppelingen (open standaarden of unieke functies?). De optelsom van 0 tot 10 laat per systeem zien hoe vast je zit; de uitgewerkte zelftest met voorbeelden staat in de gids hierboven. Twee assen zijn vaak minder erg dan ze lijken. Voor je boekhouding kun je met de open Auditfile Financieel je grootboek en mutaties uit vrijwel elk pakket exporteren, en voor persoonsgegevens dwingt de wet al een deel af. Sinds 12 september 2025 verplicht de EU Data Act clouddiensten je data machineleesbaar terug te geven, en zijn overstap- en egresskosten vanaf 12 januari 2027 volledig verboden. Een recht op papier is alleen geen vrijheid in de praktijk: je moet het opeisen en je systeem mag niet vastzitten in leverancierseigen diensten.

Stap 3: Weeg met een prioriteitsmatrix

Zet elk systeem in een matrix van kriticaliteit tegen lock-in. Niet elk systeem met een lage score hoef je aan te pakken, en niet elk systeem waar je vastzit is een probleem. Wat telt is de combinatie: een bedrijfskritisch systeem waar je diep in vastzit is je eerste zorg, een vervangbare tool met slechte export negeer je gerust tot je hem toch vervangt.

Stap 4: Kies per systeem een route

Verbind aan elk systeem een van vier routes, op basis van waar het in de matrix valt. Deze vier keren precies terug in het beslis-kader verderop: blijven en afdekken, exporteren en documenteren, gefaseerd overstappen, of eigenaarschap inbouwen. Leg de gekozen route per systeem vast, zodat je een plan hebt in plaats van een gevoel.

Stap 5: Bouw gefaseerd af, laag voor laag

Werk je afbouwpad van goedkoop naar ingrijpend af, nooit alles tegelijk. De volgorde die het minste risico geeft:

1. Contracten eerst. Onderhandel bij de eerstvolgende verlenging een exit-clausule en een gegarandeerde data-export, precies op het moment dat je positie het sterkst is. Krijg je een afrekening per resultaat voorgelegd, check dan wie het woord resultaat definieert voordat je tekent, want die partij bepaalt je factuur.
2. Data-export en residency. Zet periodieke exports op en breng je klantdata onder het juiste rechtsregime. Hoe je per dataset een EU-residency-optie kiest en je verwerkersovereenkomsten bijwerkt, werk ik apart uit. Voor je gevoeligste data bestaan er inmiddels Europees bestuurde clouds: AWS heeft zijn Europese soevereine cloud sinds 15 januari 2026 algemeen beschikbaar in Brandenburg, bestuurd door een EU-rechtspersoon met Europese directie.
3. Werkplek en cloud. Zit je vast in één kantoor-ecosysteem, dan maak je dat functie voor functie los. Mijn stappenplan om van Microsoft 365 naar een soevereine werkplek met Nextcloud, e-mail en Linux te migreren doet dat in golven, met Microsoft als vangnet tot het alternatief bewezen is.
4. Je AI-laag. Hangt je automatisering aan één model-API, schuif er dan een dunne routerlaag onder die je een leverancier-onafhankelijke AI-stack met open-weight achtervang geeft. Welk model daar past, kies je niet op een leaderboard maar op je eigen taak en data, in een keuzegids voor open-weight modellen. Koop je AI als functie in een SaaS, stel dan de vijf inkoopvragen die blootleggen welk model eronder draait en of je kunt wisselen.
5. Eigenaarschap van je maatwerk. Liet je software bouwen, dan is code in handen krijgen niet hetzelfde als eigenaar zijn. Leg eigendom, escrow en documentatie-overdracht vast met een checklist voor AI-geschreven maatwerksoftware, want eigenaarschap over je code, data en documentatie is je sterkste bescherming tegen lock-in.

Stap 6: Veranker en herbeoordeel

Maak van dit draaiboek een gewoonte, geen eenmalige actie. Zet de uitkomst in je register van verwerkingsactiviteiten en systemen, zodat je bij de volgende schok niet vanaf nul begint. Plan een vaste herbeoordeling, jaarlijks of bij elke leverancierswissel. En het belangrijkste: maak exit-by-design je inkoopregel. Bij elk nieuw systeem dat je binnenhaalt eis je vooraf drie dingen, terwijl je onderhandelingsmacht op zijn grootst is: een werkende export die je zelf kunt draaien, een open en gangbaar formaat, en een redelijke opzeg- en exit-clausule. Zo groeit het web niet opnieuw dicht.

Valkuilen

• Alles tegelijk willen verhuizen. Een complete migratie van je stack is duur, riskant en zelden nodig. De winst zit in het gericht aanpakken van de systemen die hoog scoren op kriticaliteit maal lock-in, en de rest met rust laten.
• De export-knop die je nooit test. Dat er een export in zit, is geen garantie dat het bestand ook in een ander systeem valt te laden. Test hem, en laat iemand controleren of het resultaat bruikbaar is voordat je erop rekent.
• EU-regio verwarren met soevereiniteit. Een Amerikaanse leverancier die je data in een Europees datacenter zet, valt via zijn moederbedrijf nog steeds onder Amerikaans recht. De juridische bodem onder data richting de VS schuift bovendien al jaren: het EU-VS Data Privacy Framework bleef in september 2025 nog wel overeind toen het Europese Gerecht een vernietigingsverzoek afwees, maar na Safe Harbor en Privacy Shield reken je er niet op dat de derde versie eeuwig standhoudt. Voor de kroonjuwelen weegt Europese zeggenschap zwaarder dan een kale regiokeuze.
• Eén afhankelijkheid inruilen voor een andere. Ga je naar één managed partij of één router zonder afspraken over export en formaten, dan heb je je afhankelijkheid alleen verplaatst. Eis open standaarden en een exit, ook bij een open-source oplossing.
• Alleen op de maandprijs kiezen. De goedkoopste tool van nu is de duurste als je er over drie jaar niet uit komt. Dat je vastzit merk je pas als de prijs stijgt terwijl je niet weg kunt: Microsoft verhoogt de prijs van Microsoft 365 Business Standard per 1 juli 2026 met twaalf procent. Reken de overstapkosten mee in de keuze, niet pas als je al gegijzeld bent.
• Kennis die bij één partij blijft hangen. Bij AI-geschreven maatwerk zit de werking niet meer in een mensenhoofd maar verspreid over prompts en specificaties. Zonder een echte documentatie-overdracht koop je een black box die niemand anders kan onderhouden.

Beslis-kader: welke route per systeem

Het kader draait om vier routes. Welke past, lees je af aan drie vragen die je al beantwoordde in de scan: is het systeem bedrijfskritisch, krijg je je data er bruikbaar uit, en is het standaardsoftware of maatwerk?

• Blijven en afdekken. Standaardsoftware waar je tevreden over bent maar contractueel of technisch vastzit. Blijf zitten, maar onderhandel bij de volgende verlenging een exit-clausule en een gegarandeerde export. De goedkoopste route, en vaak de verstandigste.
• Exporteren en documenteren. Een systeem dat je kunt missen of later vervangt, met matige lock-in. Zet een periodieke export op en leg de werking vast; een dure overstap loont hier zelden.
• Gefaseerd overstappen. Een kritisch systeem met hoge lock-in en een slechte exit. Plan een migratie in golven, test eerst of de export echt werkt, en houd het oude systeem als vangnet tot het alternatief draait.
• Eigenaarschap inbouwen. Maatwerk dat een bureau voor je maakte. Leg code, data en documentatie contractueel vast met een akte, regel escrow waar de bouwer de code beheert, en dwing een overdracht af die iemand anders kan oppakken.

Onder al deze routes ligt dezelfde afweging tussen kant-en-klaar en maatwerk. Lock-in vermijden betekent niet dat je alles zelf moet bouwen of hosten: een kant-en-klare SaaS met een nette export en een redelijk contract is vaak gewoon de slimste keuze. Zelf bouwen of zelf hosten reserveer je voor je gevoeligste of meest kritische systemen, waar grip op data en integraties zwaarder weegt dan gemak. Of je een onderdeel beter kunt kopen of laten bouwen is een nuchtere afweging per bedrijfsonderdeel, geen geloofskwestie, en lock-in hoort daarin een expliciete factor te zijn.

Een casus: een accountantskantoor van twintig man

Neem een accountantskantoor met twintig medewerkers. Het draait op Microsoft 365 voor de hele werkplek, een boekhoudpakket, een CRM voor de klantrelaties, een AI-helpdesktool voor vragen van cliënten, en een cliëntenportaal dat een extern bureau twee jaar geleden bouwde. Gevoelige data genoeg, en nog nooit iemand die de afhankelijkheid als geheel bekeek.

De scan levert dit op. Microsoft 365 is bedrijfskritisch met hoge lock-in: alles hangt samen, de data staat bij een Amerikaanse partij, en de prijs ging net omhoog. Het boekhoudpakket is kritisch maar de lock-in valt mee, want de auditfile-export werkt en het formaat is open. Het CRM is belangrijk met middenlock-in: contacten komen er als CSV uit, workflows niet. De AI-helpdesktool blijkt onder de motorkap een model te draaien dat de leverancier stil kan wisselen, met cliëntvragen die naar een onbekende subverwerker gaan. Het cliëntenportaal is kritisch en de kennis zit volledig bij het bureau: geen documentatie, geen akte, alleen een gebruiksrecht.

De matrix wijst de volgorde aan. Het portaal en Microsoft 365 staan rechtsboven (kritisch, hoge lock-in) en gaan eerst. Het afbouwpad over twaalf maanden: eerst de contracten, waarbij het kantoor bij de bureau-verlenging een broncode-escrow, een eigendomsakte en een documentatie-overdracht afdwingt, en bij de AI-tool laat vastleggen dat het onderliggende model niet zonder bericht wisselt. Dan de klantdata, met EU-residency aan en de verwerkersovereenkomsten bijgewerkt. Daarna de werkplek: een pilotgroep van vijf gaat naar een soevereine opzet, terwijl de rest op Microsoft blijft tot het werkt. De abonnementsprijs van dat alternatief blijkt vergelijkbaar met de nieuwe, twaalf procent hogere Microsoft-prijs; het echte verschil zit niet in de euro's per maand maar in de grip op waar de cliëntdata staat. Het CRM krijgt een maandelijkse export en verder rust. Twaalf maanden later is geen enkel systeem nog een gijzelaar, en is er niets omgevallen onderweg.

De machtsvraag onder alles

Leveranciersafhankelijkheid is geen technisch detail maar een machtsvraag: wie kan er weg, en wie zit vast? Je hoeft niet alles zelf te bouwen of te hosten om die vraag in je voordeel te beantwoorden. Je moet alleen, bij elk systeem waar je bedrijf op leunt, één ding zeker weten: als de relatie met deze leverancier morgen eindigt, kan ik dan gewoon door? Kan ik mijn data eruit halen, in een formaat dat een ander leest, zonder afkoopsom, met de kennis om verder te bouwen?

Wie dat portefeuille-breed regelt terwijl het rustig is, hoeft niet in paniek te schieten als de prijs stijgt, een grondslag omvalt of een leverancier van richting verandert. Hij weet allang waar hij staat, en belangrijker: dat hij een keuze heeft. Dat is het hele punt van dit draaiboek. Niet onafhankelijkheid als ideaal, maar als de nuchtere zekerheid dat je software je vooruithelpt in plaats van vasthoudt.