Er vindt op dit moment een gesprek plaats in directiekamers door heel Europa, en het volgt steeds hetzelfde patroon. Een CIO vertelt hoe de organisatie twaalf maanden geleden een AI-platform adopteerde. Het werkte goed. De toepassingen breidden zich uit. En toen stelde iemand van juridische zaken een vraag die aan het begin niemand had bedacht: waar verwerkt het model onze data eigenlijk?

Die vraag is in veel gevallen het begin van een langere en ongemakkelijkere: hebben wij dit model eigenlijk wel gekozen, of zat het gewoon bij het platform inbegrepen?

Deze blog is gevormd door zulke gesprekken. We horen ze in inkooptrajecten, in architectuurreviews, in strategiesessies met bestuurders die beginnen te beseffen dat de keuze voor een large language model geen technisch detail is dat ergens diep in een platform verscholen zit. Het is een beslissing met juridische, operationele en strategische consequenties, en de meeste organisaties hebben die beslissing nooit bewust genomen.

Wat volgt is geen technische verdieping. Het is een praktische gids voor beslissers die willen begrijpen wat het betekent wanneer een solution builder of platform modellen van meerdere aanbieders kan inzetten, waarom dat ertoe doet voor compliance, en welke vragen ze nu zouden moeten stellen.

De vraag die technisch was, staat nu op de bestuursagenda

Een jaar geleden zou de vraag "welk LLM gebruiken wij?" in de meeste directievergaderingen op onbegrip zijn gestuit. Het was een vraag voor het engineeringteam. De CTO wist het misschien. De rest van het bestuur had geen reden om zich ermee bezig te houden.

Dat veranderde snel. Het veranderde omdat toezichthouders begonnen te vragen. Omdat auditors begonnen te vragen. Omdat klanten, met name die in gereguleerde sectoren, AI-specifieke clausules begonnen op te nemen in hun leveranciersbeoordelingen. Een FG waar we mee spraken bij een financiele instelling zei het zonder omwegen:

"Ik ben nooit geraadpleegd over de modelkeuze. Ik kwam erachter welk LLM we draaiden toen ik begon aan de DPIA voor een nieuwe toepassing. Dat hoort niet zo te gaan."

De escalatie van engineeringvraag naar bestuurlijke zorg kwam niet doordat directeuren plotseling belangstelling kregen voor transformerarchitecturen. Het kwam doordat de regulatorische en contractuele omgeving de snelheid van AI-adoptie inhaalde. In Nederland is die versnelling goed zichtbaar. Jan Saan, medeoprichter en CTO van GLBNXT, ging hier rechtstreeks op in tijdens een recent interview met Het Financieele Dagblad, gepubliceerd in hun speciale editie over AI & Data Sovereignty. Zijn betoog was helder:

"Europese organisaties bouwen hun AI-strategieen op infrastructuur die hen van nature geen controle geeft over waar hun data naartoe gaat of welk model die verwerkt. Dat is geen technisch risico. Het is een governance-gat."

Wij hebben dit model niet gekozen, het zat bij het platform

Dit is veruit het meest voorkomende patroon in de markt op dit moment. Een organisatie nam een SaaS-platform in gebruik, een samenwerkingssuite, een product van een solution builder. De AI-functionaliteit zat erbij. Het LLM eronder was een standaardinstelling, geen keuze.

Niemand aan de inkoopkant beoordeelde het model tegen de compliance-eisen van de organisatie. Niemand vroeg onder welke jurisdictie de inferentie plaatsvindt. Niemand checkte of het model vervangen kon worden als het regulatorische beeld zou verschuiven. De AI-functie was onderdeel van het pakket, en het pakket was getekend.

Dit gebeurt om begrijpelijke redenen. Snelheid telt. Wanneer een leverancier een AI-product aanbiedt dat binnen weken live kan, is er echte bedrijfsdruk om ja te zeggen. De LLM-laag is onzichtbaar voor de meeste stakeholders, en leveranciers doen geen moeite om die zichtbaar te maken. Het zou u verbazen hoeveel enterprise-contracten de AI-component beschrijven in twee zinnen, zonder vermelding van de onderliggende modelaanbieder, de dataverwerkingslocatie, of de mogelijkheid voor de klant om een van beide te wijzigen.

Wij hebben leverancierscontracten ingezien waar de volledige AI-capaciteit was ondergebracht onder een enkele regel genaamd "intelligente features" of "AI-powered analytics." Geen model benoemd. Geen hostingjurisdictie gespecificeerd. Geen exitclausule voor de AI-component los van de bredere platformovereenkomst. Voor organisaties die dit niveau van ondoorzichtigheid nooit zouden accepteren in een cloudhostingcontract is de tolerantie ervoor in de AI-laag opmerkelijk.

De wrijving komt later. Die komt wanneer een DPO een Data Protection Impact Assessment heropent omdat de AI-laag nooit op modelniveau is beoordeeld. Die komt wanneer inkoop LLM-specifieke clausules probeert toe te voegen aan een verlenging en ontdekt dat de architectuur van de leverancier geen modelsubstitutie toestaat. Die komt wanneer een juridisch team signaleert dat de LLM-aanbieder onderworpen is aan de US CLOUD Act en de gegevensbeschermingsverplichtingen van de organisatie onder AVG Artikel 48 daar rechtstreeks mee in spanning staan.

Compliance is niet iets dat je er achteraf omheen bouwt

Er leeft een hardnekkig idee in sommige delen van de markt dat compliance een schil is. Dat je eerst het best presterende model kiest en daarna het regulatorische vraagstuk oplost. Dat klopt niet.

De compliancepositie van uw AI-inzet wordt deels bepaald op het moment dat u een model en een hostingomgeving selecteert. Als inferentie verloopt via Amerikaanse infrastructuur, beheerd door een aanbieder die onderworpen is aan Amerikaans recht, pauzeren uw AVG-verplichtingen niet terwijl u een verwerkersovereenkomst regelt. Als de voorwaarden van de modelaanbieder toestaan dat inputs en outputs worden gebruikt voor modelverbetering, zijn uw dataminimalisatieprincipes al aangetast.

DPO's en juridische teams in gereguleerde sectoren duwen hier steeds vaker tegen. We horen het keer op keer: deployments die goedgekeurd werden door IT, die echte waarde leverden, die nu vastlopen omdat de compliancebeoordeling op de modellaag problemen aan het licht brengt die niemand heeft aangepakt tijdens de initiele uitrol. In de publieke sector, waar het eigen beleid van de Nederlandse overheid rond cloud en datasoevereiniteit geldt, zijn de vragen nog scherper. In de financiele sector maken toezichtsverwachtingen rond uitbesteding en data-governance het gesprek onvermijdelijk.

De EU AI Act maakt dit concreter. Organisaties die AI-systemen met hoog risico inzetten, dragen verplichtingen rond transparantie, verantwoording en documentatie die zich uitstrekken door de waardeketen. Als u niet kunt uitleggen welk model u draait, waar het gehost wordt en onder welke voorwaarden, dan heeft u een gat dat alleen maar moeilijker te dichten wordt naarmate de handhavingstermijnen naderen.

Het capability-argument klopt, maar het is onvolledig

Elke bestuurder met wie we spreken brengt hetzelfde punt naar voren, en terecht: "We hebben dit model gekozen omdat het het beste presteert voor wat wij nodig hebben." Begrijpelijk. Capability doet ertoe. Als het model het werk niet aankan, is al het andere theoretisch.

Maar prestaties zijn contextgebonden en tijdelijk. Het model dat vandaag bovenaan de benchmarks staat, doet dat over zes maanden misschien niet meer. Prijsstructuren veranderen. Nieuwe modellen verschijnen die beter presteren op bepaalde taken en slechter op andere. Het tempo van verandering in deze markt is snel genoeg dat wat u in januari evalueert, tegen de zomer niet langer de sterkste optie hoeft te zijn. We hebben organisaties een evaluatietraject van drie maanden zien doorlopen, om er vervolgens achter te komen dat de winnende kandidaat al was ingehaald tegen de tijd dat het contract werd getekend.

Belangrijker nog: het best presterende model ter wereld is irrelevant als u het niet kunt inzetten op een manier die aan uw juridische verplichtingen voldoet. Wat het model kan en wat de inzet ervan betekent voor uw compliancepositie moeten tegelijk worden beoordeeld, niet na elkaar. Geen van beide vragen mag de ander overschaduwen.

De organisaties die hier het effectiefst mee omgaan, zijn degenen die weigeren deze gesprekken te scheiden. Ze betrekken de FG bij de modelevaluatie naast de technisch architect. Ze behandelen hostingjurisdictie en dataverwerkingsvoorwaarden als selectiecriteria met hetzelfde gewicht als benchmarkscores en latencycijfers.

Wat LLM-agnostisch in de praktijk betekent

De term wordt veel gebruikt. Het is de moeite waard om precies te zijn over wat het in de praktijk inhoudt, want er is een wezenlijk verschil tussen platforms die flexibiliteit claimen en platforms die het ook daadwerkelijk leveren.

Wanneer een platform of solution builder LLM-agnostisch is, betekent het dat de klant, of de architecten van de klant, modellen van meerdere aanbieders kan selecteren, wisselen of combineren zonder de applicatie opnieuw te hoeven bouwen. De applicatielogica, de gebruikersinterface, de integraties, dat alles blijft intact. Het model eronder kan veranderen.

Denk eraan zoals u denkt over elektriciteit. U wilt niet dat de productielijn van uw fabriek vast zit aan een enkele energieleverancier zonder mogelijkheid om te wisselen. U wilt een standaardaansluiting waarmee u stroom kunt afnemen van wie de beste combinatie van prijs, betrouwbaarheid en voorwaarden biedt. Hetzelfde principe geldt hier.

De huidige werkelijkheid is anders. De meeste AI-platforms zijn gekoppeld aan een enkele LLM-aanbieder. De integratie zit diep, de API's zijn proprietary, en overstappen betekent een herbouw waar niemand op had gerekend en niemand budget voor heeft. Dit is vendor lock-in, maar op een laag die de meeste inkoopkaders nog niet hebben leren beoordelen.

Voor beslissers is de praktische consequentie eenvoudig. Als uw platform vastzit aan een enkele modelaanbieder en die aanbieder wijzigt zijn prijzen, zijn voorwaarden, zijn dataverwerkingspraktijken of zijn hostinglocaties, dan zijn uw opties: de wijziging accepteren of opnieuw beginnen. Geen van beide plaatst u in een sterke onderhandelingspositie.

De vragen die nu al in aanbestedingen opduiken

Er verschuift iets in hoe gereguleerde organisaties AI-leveranciers evalueren, en het gaat sneller dan de meeste leveranciers verwachtten. Inkoopteams in de financiele sector, de publieke sector, de zorg en de advocatuur voegen LLM-specifieke beoordelingscriteria toe aan hun aanbestedingen. Dit zijn geen theoretische vragen. Ze staan nu in RFP's.

De vragen die we steeds terugzien: kunnen we het onderliggende model wijzigen zonder de oplossing opnieuw te engineeren? Onder welke jurisdictie vindt modelinferentie plaats? Wat gebeurt er met onze data tijdens en na verwerking? Als onze regulatorische verplichtingen volgend jaar veranderen, hoe snel kunnen we onze AI-infrastructuur aanpassen? Ondersteunt het platform modellen van meerdere aanbieders, of zitten we vast aan een?

Deze vragen komen niet voort uit paranoia. Ze weerspiegelen een markt die volwassen wordt. Organisaties hebben geleerd, soms op de harde manier, dat technologiebeslissingen die in haast worden genomen contractuele en operationele beperkingen creeren die de oorspronkelijke business case overleven. De cloudmigratie heeft die les duur geleerd. De AI-adoptiecyclus leert hem opnieuw, en sneller.

Wat opvalt is wie deze vragen stelt. Het zijn niet alleen de bekende compliance-poortwachters. We zien CTO's ze stellen omdat ze architecturale flexibiliteit willen. We zien inkoopverantwoordelijken ze stellen omdat ze eerder door vendor lock-in zijn gebrand en het patroon herkennen. We zien bestuurders ze stellen omdat ze genoeg hebben gelezen over AI-governance om te weten dat het regulatorische beeld niet is uitgekristalliseerd en ze niet aan de verkeerde kant ervan willen belanden. Het feit dat deze gesprekken vanuit verschillende richtingen samenkomen, zegt iets over waar de markt naartoe gaat.

De organisaties met de meeste opties bewegen het snelst

De organisaties die zich het beste zullen aanpassen aan wat er ook komt, in AI-regulering en in AI-capaciteit, zijn niet degenen die het "beste" model kozen in 2024 of 2025. Het zijn degenen die ervoor zorgden dat ze van gedachten konden veranderen.

Keuzevrijheid op de modellaag is een structurele vereiste voor elke organisatie die opereert in een regulatorische omgeving die nog vorm krijgt. Het Europese regelgevingskader voor AI is niet af. Handhavingsmechanismen onder de EU AI Act materialiseren nog. AVG-interpretaties rond AI-dataverwerking blijven zich ontwikkelen via jurisprudentie en toezichtrichtlijnen. Bouwen op een architectuur die u vastlegt op een enkel model, een enkele jurisdictie en een enkele set leveranciersvoorwaarden is een weddenschap dat er niets zal veranderen. Dat is geen weddenschap waar de meeste compliance officers voor zouden tekenen.

De platforms en solution builders die dit begrijpen, ontwerpen er al voor. Ze bouwen abstractielagen die klanten in staat stellen verschillende workloads naar verschillende modellen te routeren. Ze maken hostingjurisdictie een configureerbare parameter, geen vaste beperking. Ze schrijven contracten die de AI-laag scheiden van de bredere platformovereenkomst, zodat een modelwissel geen volledige heraanbesteding vereist. Dit is waar de markt naartoe gaat. De vraag is of uw huidige architectuur daar ook naartoe gaat.

De vraag voor beslissers is niet welk LLM het beste is. De vraag is of ze de vrijheid hebben om te kiezen, en of die vrijheid er over twaalf maanden nog steeds zal zijn.

GLBNXT bouwt soevereine AI-infrastructuur voor gereguleerde Europese ondernemingen en biedt LLM-agnostische, AVG-conforme platforms die volledig binnen de EU worden gehost. Meer informatie op glbnxt.com

Referenties

European Commission, AI Act: Regulatory Framework for Artificial Intelligence

EUR-Lex, Regulation (EU) 2024/1689 (AI Act), Official Journal

EDPB, Guidelines 02/2024 on Article 48 GDPR

Kennedys Law, The EU AI Act implementation timeline (March 2026)