Stel dat een Europese organisatie een agent wil bouwen die aanvragen beoordeelt, gegevens uit kernsystemen raadpleegt, een besluit voorbereidt en uiteindelijk zelf stappen in een proces uitvoert.
Moet die agent een Europees taalmodel gebruiken? Op een Europese cloud draaien? Amerikaanse technologie volledig vermijden?
Er is geen eenduidig antwoord.
Een organisatie kan een Europees model op Amerikaanse infrastructuur draaien. Ze kan Amerikaanse cloudtechnologie gebruiken die door een Europese entiteit wordt beheerd. Ze kan een open model in de eigen omgeving draaien en toch afhankelijk zijn van niet-Europese chips. Of ze gebruikt een Amerikaans frontiermodel en houdt haar eigen data, agentlogica en processen volledig in eigen hand.
Elk van die opties kun je met recht meer of minder soeverein noemen.
Daarom moeten we AI-soevereiniteit niet langer zien als een keuze tussen leveranciers.
Soevereiniteit is het bewust managen van afhankelijkheden over de hele AI-stack.
De managementvraag wordt dan: welke afhankelijkheden accepteren we, welke risico’s brengen ze mee en waar zou verlies van controle de organisatie wezenlijk beperken?
Soevereiniteit kent lagen
De Europese Commissie kijkt inmiddels op een vergelijkbare, gelaagde manier naar cloudsoevereiniteit. Het Cloud Sovereignty Framework 2026 beoordeelt leveranciers op 48 criteria in acht gebieden, waaronder juridische soevereiniteit en jurisdictie, data en AI, operatie, toeleveringsketen en technologische soevereiniteit.
Het framework onderscheidt datasoevereiniteit, technologische autonomie en ten slotte volledige soevereiniteit.
Dat onderscheid is belangrijk voor AI, omdat een architectuur met agents bestaat uit lagen met zeer verschillende afhankelijkheden.
Ik onderscheid op dit moment zes lagen:
Rekenkracht → cloud & infrastructuur → basismodellen → data & kennis → agentorkestratie → applicatie & proces
Governance en controle lopen door alle zes lagen heen.
Hoe dichter we bij de eigen kennis en de daadwerkelijke uitvoering van het werk komen, hoe voorzichtiger ik zou zijn met het uit handen geven van controle.
Europa bouwt alternatieven voor de hele stack
Onderin de stack investeert Europa fors in rekenkracht.
EuroHPC zet 19 AI Factories op in Europa, ondersteund door 13 AI Factory Antennas. In juli 2026 startte ook de aanbesteding voor veel grotere AI Gigafactories, die grootschalige Europese capaciteit moeten bieden voor het trainen en draaien van modellen.
Dat is betekenisvolle infrastructuur. Tegelijk laat het zien waarom soevereiniteit geen kwestie van ja of nee is. Europese rekencentra kunnen nog steeds afhankelijk zijn van niet-Europese chips, netwerktechnologie en software.
Volledige soevereiniteit tot op de hardware zou daarom een uitzonderlijk hoge lat zijn.
Een laag hoger worden de keuzes concreter.
Europese cloudaanbieders zoals OVHcloud en Scaleway bieden infrastructuur in Europees eigendom en beheer. Maar tussen de Europese cloud en de traditionele hyperscaler is een nieuwe categorie ontstaan.
S3NS combineert bijvoorbeeld Google Cloud-technologie met een Franse juridische entiteit, Franse operatie en Franse infrastructuur. AWS heeft inmiddels een afzonderlijke European Sovereign Cloud en Microsoft heeft zijn soevereine cloudopties uitgebreid.
Zulke architecturen vergroten de Europese controle over operatie en data aanzienlijk, zonder de onderliggende technologische of zakelijke afhankelijkheid weg te nemen.
Dat onderscheid is belangrijk.
Europese dataresidentie is niet hetzelfde als Europese operationele controle. En Europese operationele controle is niet hetzelfde als technologische onafhankelijkheid.
De modellaag wordt een echte Europese keuze
In de modellaag is de verandering misschien het duidelijkst zichtbaar.
Mistral heeft zich ontwikkeld van een Frans modelbedrijf tot een bredere Europese AI-infrastructuurspeler, met betaalde en open modellen, regionale verwerking en steeds vaker een eigen Europese strategie voor rekenkracht.
Zwitserland kiest een andere aanpak.
Apertus 1.5, ontwikkeld door ETH Zürich, EPFL en het Swiss National Supercomputing Centre, is ontworpen als volledig open model. Het model, de code en het ontwikkelproces zijn in te zien en aan te passen. De makers positioneren het nadrukkelijk als infrastructuur voor soevereine AI, en niet als zoveelste chatbot.
Er komen ook andere Europese initiatieven op. EuroLLM richt zich sterk op Europese talen. OpenEuroLLM wil een familie van transparante Europese basismodellen ontwikkelen, met grotere releases in de komende jaren.
Deze initiatieven zijn niet allemaal te vergelijken met de huidige toonaangevende frontiermodellen. Ze verschillen sterk in volwassenheid, mogelijkheden en beoogd gebruik.
Maar ze veranderen wel de strategische keuze.
Europese organisaties kunnen steeds vaker bepalen waar topprestaties belangrijk genoeg zijn om externe afhankelijkheid te accepteren, en waar transparantie, controle over de inzet of eigendom van het model zwaarder wegen.
Ik zou niet optimaliseren voor een volledig Europese stack
Er is een risico dat we soevereiniteit te ver doorvoeren.
Voor veel organisaties zou de eis dat iedere processor, clouddienst, elk model en ieder softwareonderdeel Europees moet zijn, duur uitpakken en de toegang tot betere technologie beperken.
Een Amerikaans frontiermodel kan voor een specifieke taak simpelweg duidelijk beter presteren.
Dan kan het een volkomen rationele keuze zijn om het te gebruiken.
Maar die afhankelijkheid is niet gratis.
Een niet-Europese aanbieder kan extra vragen oproepen over internationale doorgifte van gegevens, jurisdictie, toegang door de aanbieder, bewaartermijnen, controleerbaarheid, continuïteit en de mogelijkheid om over te stappen.
Voor de doorgifte van persoonsgegevens naar de Verenigde Staten biedt het EU-US Data Privacy Framework bijvoorbeeld een adequaatheidsbesluit voor deelnemende Amerikaanse organisaties. In andere situaties kunnen andere doorgiftemechanismen gelden.
De Amerikaanse CLOUD Act voegt een andere overweging toe. Bedrijven die onder Amerikaanse jurisdictie vallen, kunnen via een geldige juridische procedure worden verplicht gegevens te verstrekken die zij beheren, ongeacht waar die gegevens zijn opgeslagen.
Dat betekent niet dat Amerikaanse clouddiensten automatisch in strijd zijn met de AVG.
Het betekent wel dat de locatie van de server alleen de soevereiniteitsvraag niet beantwoordt.
Daarom moet je compliance en soevereiniteit niet door elkaar halen.
Een Europese AI-dienst kan slecht bestuurd zijn en niet aan de regels voldoen. Een Amerikaanse dienst kan in Europa volledig volgens de regels worden ingezet. Ook de AI Act stelt eisen op basis van de rol en het gebruik van AI, niet op basis van de nationaliteit van de leverancier. De verplichtingen voor aanbieders van AI voor algemene doeleinden gelden sinds augustus 2025; de handhavingsbevoegdheden van de Commissie sinds augustus 2026.
Soevereiniteit kan sommige risico’s makkelijker beheersbaar maken. Ze vervangt compliance niet.
De waardevolste lagen zijn misschien niet de modellen
Er is nog een reden om het taalmodel niet tot het middelpunt van een soevereiniteitsstrategie te maken.
Kijk wat er gebeurt wanneer een organisatie serieus agents gaat bouwen.
Het model levert het redeneervermogen. Maar daaromheen bouwt de organisatie stap voor stap iets op dat veel specifieker is:
context over klanten, diensten en producten;
zoekfuncties en eigen kennisbronnen;
het geheugen van agents;
systeeminstructies;
definities van tools;
bevoegdheden;
workflowlogica;
momenten waarop een mens goedkeurt;
testsets voor evaluatie;
escalatieregels;
en koppelingen met operationele systemen.
Samen beschrijft dat steeds nauwkeuriger hoe de organisatie werkt.
Ook hier ontwikkelt Europese technologie zich. Deepset/Haystack uit Duitsland biedt modelonafhankelijke infrastructuur voor agents en het ophalen van kennis. n8n biedt orkestratie van workflows en agents die je zelf kunt hosten. Europese vector- en zoektechnologie, zoals Qdrant en Weaviate, helpt organisaties belangrijke delen van hun contextarchitectuur overdraagbaar te houden.
Europese governancebedrijven zoals Saidot, LatticeFlow AI en Giskard ontwikkelen controles voor AI-systemen en agents, en Langfuse biedt tracing en evaluatie die je zelf kunt hosten.
De afzonderlijke producten zullen veranderen. Het architectuurprincipe gaat langer mee:
Houd je eigen kennis en logica beter overdraagbaar dan het model dat ermee redeneert.
Een organisatie kan dan Mistral gebruiken voor de ene toepassing, een Amerikaans frontiermodel waar dat genoeg extra waarde oplevert, en misschien Apertus of een ander open model voor een toepassing die strikte controle vraagt.
Een ander model kiezen zou niet moeten betekenen dat je de kennis en de werkwijze van de organisatie opnieuw moet opbouwen.
Afhankelijkheid kost werk
Dit verandert ook de afweging bij het kiezen van technologie.
Bij de keuze voor externe technologie vergelijken we meestal functionaliteit, prestaties, implementatie-inspanning en prijs.
Maar afhankelijkheid levert doorlopend werk op.
Een niet-Europees model of een niet-Europese cloudaanbieder kan extra privacybeoordelingen, contractuele waarborgen, beveiligingsmaatregelen, dataclassificatie, monitoring, modelevaluatie, architectuurwerk en een exitplan vragen.
Een gesloten agentplatform kan de implementatie versnellen, maar maakt het later moeilijker om workflows, geheugen en bedrijfslogica te verhuizen.
Omgekeerd brengt het zelf hosten van een open Europees model ook kosten mee. Iemand moet het beheren, beveiligen, evalueren en goed laten presteren.
Aan beide kanten zijn er dus kosten.
Daarom zou ik bij belangrijke keuzes in de AI-architectuur vier minder zichtbare kostenposten meewegen:
Compliancelast. Beheerlast. Exitlast. Kennislast.
Ze maken een externe afhankelijkheid niet automatisch onaantrekkelijk. Een wereldwijde technologieleverancier kan zoveel extra waarde leveren dat die kosten ruimschoots te rechtvaardigen zijn.
Maar ze horen wel in de afweging thuis.
Bepaal soevereiniteit per laag
Dat brengt me bij een vrij eenvoudige aanpak.
Stel voor iedere belangrijke laag van de AI-architectuur deze vragen:
- Wat plaatsen we hier eigenlijk?
Standaard rekenkracht is iets anders dan het geheugen over klanten of de eigen beslislogica. - Welke afhankelijkheid accepteren we?
Technologie, jurisdictie, operatie, kennis — of alle vier? - Wat gebeurt er als die afhankelijkheid onaanvaardbaar wordt?
Kunnen we realistisch van leverancier wisselen, of alleen contractueel? - Welk doorlopend werk is nodig om haar te beheersen?
Beveiliging, privacy, evaluatie, governance en operationele weerbaarheid vragen allemaal capaciteit. - Welk vermogen moet in huis blijven?
Technologie uitbesteden mag niet ongemerkt betekenen dat je ook het vermogen uitbesteedt om je eigen werkwijze te begrijpen en te veranderen.
Het antwoord verschilt per laag.
Over het algemeen zou ik veel meer wereldwijde afhankelijkheid accepteren bij rekenkracht en basismodellen dan bij eigen data, bevoegdheden van agents, bedrijfslogica en de uitvoering van processen.
Dat is geen universele architectuurregel. Een bank, een defensieorganisatie en een middelgrote producent zullen de grenzen om goede redenen anders trekken.
Maar dat is precies het punt.
Soevereiniteit moet worden ontworpen, niet uitgeroepen.
Het doel is niet om ieder onderdeel Europees te maken. Het doel is betekenisvolle controle houden over de delen van de architectuur die de organisatie niet kan missen.
Gebruik wereldwijde technologie waar het voordeel de afhankelijkheid rechtvaardigt. Kies voor Europese of zelf beheerde alternatieven waar jurisdictie, eigen kennis, operationele vrijheid of continuïteit controle waardevoller maken.
En begrijp bij iedere afhankelijkheid die je accepteert wat het blijvend kost om haar te beheersen.