Door Bertrand de Neve, De Neve IT Consulting B.V.
De belofte uit deel 1
In mijn artikel Soevereine AI in eigen hand eindigde ik met een open vraag en een toezegging. De vraag: hoeveel van de grens waar ik tegenaan liep zat in het principe van soevereine AI, en hoeveel gewoon in de hardware? De toezegging: zodra mijn EU cloud service provider (EU CSP) mijn verzoek om GPU-capaciteit zou inwilligen, zou ik precies dezelfde metingen opnieuw doen en de cijfers delen.
Na wat aandringen kwam die toewijzing. Dit artikel is het vervolg: wat de GPU precies oplost, wat hij kost, waarom je hem niet zomaar krijgt, en — voor mij de mooiste uitkomst — wat er nu wél kan met een model dat volledig Europees is en op mijn eigen gehuurde infrastructuur draait.
De korte versie alvast: ik ben oprecht tevreden. Wat vandaag met open, Europese modellen mogelijk is, gaat verder dan ik een half jaar geleden had verwacht — tot en met een assistent die meewerkt aan het moderniseren van verouderde code. Verderop reflecteer ik ook kort op de commerciële (gesloten) route, maar dat is een zijstraat, geen hoofdweg.
Eén schakelaar om
Wat er technisch gebeurde, is bijna saai — en dat was precies mijn bedoeling. Ik heb één variabele omgezet van cpu-fallback naar gpu. Terraform vraagt daarop een andere machine aan, Ansible haalt een ander model op, en de policy-laag controleert of die machine nog steeds binnen de goedgekeurde lijst en de vastgelegde EU-regio valt. Geen herontwerp, geen tweede codebase, geen handmatige stap op de server. Dat de architectuur dit zonder kleerscheuren doorstond, vind ik achteraf een van de waardevolste uitkomsten van dit hele traject.
Onder die schakelaar zit een flinke sprong: van Mistral 7B op vier CPU-kernen naar Devstral Small 2 — 24 miljard parameters, Apache 2.0, ook van het Franse Mistral — op een Tesla V100S. Zelfde pipeline, zelfde policies, zelfde API en dezelfde front-end.
En de harde grens uit deel 1? Die schuift flink op. Om dat niet op gevoel te hoeven zeggen, heb ik er een eigen testsuite voor gebouwd die na elke deploy automatisch draait, op beide profielen. Hij bestaat uit drie delen: veertien controles op de werking van de omgeving zelf (draaien alle onderdelen, blokkeert de filterlaag wat hij moet blokkeren, komen de meetgegevens binnen), een vaste set vragen met een bekend goed antwoord — feiten, rekenen, redeneren, vertalen, code schrijven en gereedschap aanroepen — en een meting van responstijd en belasting van de machine. Geen losse demo dus, maar een regressietest die elke keer hetzelfde meet.
De resultaten zijn helder, en genuanceerder dan ik vooraf dacht. Met een eenvoudige opdracht en vijf gereedschappen lukt het kleine model op de CPU het soms wél — maar niet betrouwbaar. Het echte onderscheid zit in de zware test, met precies de veertien gereedschappen die mijn codeerassistent in VS Code aanbiedt. Daar schrijft Mistral 7B op de CPU een verzonnen regel code óver het gereedschap in plaats van het echt aan te roepen, en doet daar tussen de 27 en 82 seconden over. Devstral Small 2 op de GPU doet het goed, en is in ongeveer 2 seconden klaar. Het is dus niet de vraag óf er gereedschap in het spel is, maar hoeveel en hoe ingewikkeld — en dat is precies de situatie van echt ontwikkelwerk.
Ook bij gewone vragen is het verschil te zien. Een eenvoudige redeneervraag (hoe laat komt een trein aan?) kostte de CPU ruim 5 seconden, de GPU een derde seconde. Een klein stukje code schrijven: ruim 5 seconden tegen nog geen 2. En terwijl de CPU-machine tijdens de testrun op bijna 100% van zijn capaciteit draaide, bleef de processor van de GPU-machine rond de 5%. Het was dus hardware en modelomvang, niet het principe. Soevereine AI loopt niet vast op soevereiniteit.
Waarom een GPU zoveel uitmaakt
Twee dingen, en het tweede wordt vaak vergeten.
Het eerste is rekenkracht. Een taalmodel dat antwoord geeft, doet vooral heel veel eenvoudige rekensommen tegelijk. Een CPU is een handvol zeer veelzijdige vakmensen; een GPU is een fabriekshal vol eenvoudige rekenaars die allemaal tegelijk aan hetzelfde werkstuk werken. Voor dit type werk wint die hal met gemak.
Het tweede is geheugen op de kaart zelf — VRAM — en dat werkt genadeloos. Past het model er helemaal in, dan draait alles op volle snelheid. Past het er net niet in, dan schuift een deel terug naar de CPU en zakt de boel merkbaar in. Er zit weinig tussenin.
Dat heb ik gemeten in plaats van geschat, en ik ben blij dat ik dat deed. Mijn eigen inschatting van de geheugenkosten van een groter contextvenster was namelijk te optimistisch. Op de eerste kaart (16 GB) paste het model alleen bij een contextvenster van 2.048 tokens nog volledig op de GPU; bij 4.096 liep al een tiende terug naar de CPU. Op de opvolger met 32 GB paste elk getest formaat tot en met 32.768 tokens volledig op de kaart — ook met het embeddingmodel voor mijn kennisbank er gelijktijdig naast (samen 21,5 GB, met ruim 10 GB marge over).
Dat contextvenster is het werkgeheugen van een gesprek. 2.048 tokens is ongeveer drie pagina’s tekst: genoeg voor een vraag en een antwoord, te weinig om een dossier of een codebestand in samenhang te overzien. 32.768 tokens is een flink rapport. Dat is het verschil tussen een aardige demo en gereedschap waar je op kunt bouwen — en voor agentic coding is het onmisbaar, zeker als je een grote, monolithische legacy-applicatie stap voor stap wilt omzetten naar microservices.
De bredere les zit niet in de getallen maar in de werkwijze: ik heb die meting vastgelegd als een script dat ik vanuit de pipeline kan aanroepen. De volgende keer dat ik van model of GPU-kaart wissel, meet ik opnieuw in plaats van de aannames van vorige keer te laten staan. Een architectuur die op verouderde aannames rust, ziet er in het diagram nog steeds prima uit.
De rekening — en de schaarste
Nu het deel dat in de meeste enthousiaste AI-verhalen ontbreekt.
Een GPU-machine van het kaliber dat ik gebruik kost bij een EU CSP ruwweg €0,70 tot €0,80 per uur. De variant met dubbel zoveel geheugen kostte tien cent per uur meer, en dat is de beste tien cent die ik dit traject heb uitgegeven. Maar reken het eens door: €0,80 per uur is bijna €600 per maand als je zo’n machine continu laat draaien. Voor één instance, met één model, voor één tot circa vier gebruikers. Dan hebben we het nog niet over redundantie of piekbelasting.
En je kunt er niet zomaar een bestellen. Ik moest capaciteit aanvragen en wachten: verzoek ingediend op 16 augustus, goedkeuring op 15 september. Die goedkeuring gold bovendien specifiek voor één machinetype — een grotere variant vraagt opnieuw een aanvraag. Tegelijk staat het quotum voor iets veel simpelers, netwerk-securitygroepen, bij mij nog gewoon op nul. Schaarste is bij cloudproviders geen abstractie, het is een wachtrij met jouw naam erin.
Dat is geen eigenaardigheid van één provider. De markt is over de hele linie krap, bij EU CSP’s zowel als bij de non-EU CSP’s: de zwaarste kaarten zijn bij veel aanbieders simpelweg vergeven, en waar ze wel te krijgen zijn liggen de uurtarieven een veelvoud hoger dan wat ik betaal. Bovendien is GPU-capaciteit niet in elke regio beschikbaar; de regio bepaalt veel. Het knelpunt zit niet eens in het etsen van de chips, maar in de geavanceerde verpakkingstechniek en het snelle geheugen dat eromheen moet — capaciteit die je niet even bijbestelt. Dit is structureel, niet een dipje.
Voor een architect heeft dat vier concrete gevolgen.
Ontwerp voor aan en uit. Mijn omgeving breek ik na elke testronde volledig af. Dat is deels kostenbewust, maar het dwingt ook af dat opbouwen reproduceerbaar blijft. Een GPU die staat te wachten op werk is de duurste vorm van niets doen.
Zet niet alles op de zware machine. Samenvatten, vertalen, doorzoeken van je eigen documenten, transcriberen, voorlezen: dat draaide in deel 1 al prima zonder GPU. Alleen het zwaarste en tijdkritische werk heeft die kaart echt nodig. Dat onderscheid scheelt een veelvoud in kosten, en ook in energie. Een kaart als de mijne is ontworpen voor zo’n 250 watt onder volle belasting, datacenters hebben koeling nodig, en voor de chips zelf zijn grondstoffen nodig waarvan de winning niet overal even schoon verloopt. Dat is geen reden om AI links te laten liggen — de sector investeert ook flink in zuinigere chips en duurzamere datacenters. Het is wel een reden om rekenkracht te behandelen als iets kostbaars: inzetten waar het echt waarde toevoegt, uitzetten waar het niet nodig is.
Denk aan on-premise en hybride, niet alleen aan cloud. Dit is de rekensom die ik organisaties steeds vaker zie maken. Bij voorspelbaar, continu gebruik kantelt het plaatje richting eigen hardware: een paar honderd euro per maand aan huur telt in een jaar of twee op tot de orde van grootte van een eigen kaart — en die staat dan in je eigen serverruimte, onder je eigen regels, zonder wachtrij. De aantrekkelijkste variant is wat mij betreft de hybride: de basis draait on-premise of op een kleine, permanente EU CSP-instance, en zware capaciteit bij een EU CSP wordt alleen opgestart wanneer er echt werk is — een migratieslag, een grote documentverwerking, een piek. Precies daarvoor is mijn profielschakelaar gebouwd, en het is dezelfde beweging die organisaties al jaren maken met testomgevingen. Kanttekening: hardware kopen betekent ook afschrijven, koelen, beheren en over drie jaar vervangen, dus reken het echt door in plaats van het te voelen.
En wees eerlijk over wanneer zelf hosten níet loont. Gebruik je AI af en toe, verspreid over de dag, dan is per verbruikte eenheid betalen bij een dienst vrijwel zeker goedkoper dan een eigen kaart die grotendeels stilstaat. Zelf hosten wordt pas aantrekkelijk bij voorspelbare, continue belasting — of wanneer de aard van je gegevens de doorslag geeft. En dat laatste gebeurt vaker dan je denkt, zoals hierna blijkt.
Waar het nu pas echt interessant wordt: legacy
Voor mij zit de grootste winst niet in “de chat is sneller geworden”. Die zit in wat er nu wél kan.
Met een model dat betrouwbaar gereedschap kan gebruiken en een contextvenster dat een heel bestand in samenhang overziet, verandert de assistent van gesprekspartner in meewerkend collega. Hij leest de code zelf, stelt wijzigingen voor, voert ze uit, schrijft tests en legt uit wat hij heeft gedaan. In mijn ontwikkelomgeving staat hij inmiddels naast de commerciële assistenten die ik ook gebruik — en voor een groeiend deel van het werk pak ik de eigen.
Waar ik dat het meest waardevol vind: verouderde code begrijpelijk maken en stap voor stap moderniseren. Iedereen die aan legacy heeft gewerkt kent het patroon. Een component die al vijftien jaar draait, geschreven door mensen die er niet meer werken, zonder tests, met bedrijfsregels die nergens anders staan opgeschreven dan in de code zelf. Niemand durft eraan te komen, en dus wordt er omheen gebouwd — tot het niet meer kan.
Precies daar is zo’n assistent sterk. Niet om het in één keer te herschrijven — dat is nooit een goed plan — maar om de weg vrij te maken: uitleggen wat een functie feitelijk doet, de verborgen bedrijfsregels eruit vissen en opschrijven, karakteriseringstests maken zodat je het gedrag kunt vastpinnen vóór je iets verandert, en vervolgens één afgebakend stuk naar buiten tillen achter een nette interface. Dat sluit naadloos aan op het strangler-patroon uit mijn artikel Hoe je een verouderde ketenkoppeling moderniseert zonder de keten stil te leggen: niet de big bang, maar de oude applicatie geleidelijk laten verschrompelen terwijl er moderne services omheen groeien. Het gereedschap is nu goed genoeg om dat tempo echt te verhogen.
En let op wat daar doorheen loopt, of kan lopen: bedrijfskritische broncode, bedrijfsregels, soms hele integratiepatronen van een organisatie — maar ook IP-adressen, wachtwoorden, sleutels en kwetsbare code die een aanvaller precies laat zien waar hij moet zoeken. Dat is precies het materiaal waarvan je liever zelf bepaalt waar het langskomt. Soeverein draaien is in dit geval geen principekwestie — het is gewoon heel verstandig. Toch hoor ik nog te vaak: “Ach, het is maar code, laat een commercieel model het maar analyseren en herbouwen.”
Dat is voor mij de kern van dit hele traject: de Europese, open modellen zijn vandaag goed genoeg voor het werk waar het echt om gaat. Niet voor alles, niet op elke ranglijst, maar wel voor dit.
Korte reflectie: en de commerciële platforms dan?
Die vraag krijg ik altijd, dus laat ik hem kort beantwoorden — zonder er een kruistocht van te maken.
De grote AI-platforms van de non-EU CSP’s — Microsoft Azure AI Foundry, AWS Bedrock, Google Vertex AI en vergelijkbare — lossen een reëel probleem op. In veel organisaties gebruiken teams losse AI-sleutels zonder toezicht of vangrails, en plakken medewerkers bedrijfsgegevens in publieke chatvensters. Zo’n platform zet daar één bedieningspaneel omheen — bestaande identiteiten en rollen, databescherming, filters, zicht op kosten per team — met een enorme modelcatalogus en kant-en-klare koppelingen erbij, passend op wat er al staat en vaak binnen bestaand budget. Wie volgende maand moet leveren, is daar sneller klaar dan ik in mijn lab. Geen domme keuze, en ik maak er geen karikatuur van.
Twee dingen leg ik er wel naast. Dataresidentie is niet hetzelfde als zeggenschap: waar de gegevens staan is een andere vraag dan wie er onder welk recht bij kan, en een moederbedrijf buiten de EU blijft onder het recht van zijn eigen land vallen — iets wat de betrokken aanbieders zelf ook nooit hebben ontkend. En de afhankelijkheid zit allang niet meer in het model: van model wisselen kan vrij eenvoudig, het is de fabriek eromheen die bindt — het agent-raamwerk, de vectoropslag en evaluatiesets die je jarenlang vult, de monitoring die nergens anders werkt. Al is ook dat vooral een ontwerpkeuze: wie zich aan gestandaardiseerde koppelvlakken houdt en zijn eigen logica overdraagbaar bewaart, kan zo’n platform prima gebruiken zonder zich vast te ketenen.
En eerlijk is eerlijk: mijn eigen route heeft ook afhankelijkheden — quota bij mijn provider, mijn tooling, mijn eigen code — en leunt bovendien op de kennis van een paar mensen. Een platform heeft 24/7 support, mijn lab heeft mij. Mijn conclusie is dus geen of/of maar: kies per werkstroom in plaats van per organisatie, en houd in beide gevallen de uitgang open.
Wat er onderweg nog meer bij kwam
Eén toevoeging sinds deel 1 verdient aparte vermelding, omdat hij precies over dit onderwerp gaat. Er zit nu een eigen filterlaag (vangrails) vóór het model: elk bericht wordt eerst gecontroleerd op persoonsgegevens en op per ongeluk meegestuurde wachtwoorden en sleutels. Persoonsgegevens — inclusief een BSN, met controle op de elfproef — worden onherkenbaar gemaakt vóórdat het model ze ziet; een gevonden geheim blokkeert het bericht helemaal. Valt die filterlaag uit, dan gaat er niets door; dat is een bewuste keuze, want het alternatief ondermijnt het hele doel.
Ik heb dat live getest en meteen de grenzen in beeld gebracht: een naam die volledig in kleine letters staat wordt niet als naam herkend, en een IBAN met een fout aantal tekens wordt terecht genegeerd.
De testsuite liet daarna zien dat vangrails ook bijwerkingen hebben. Bij de eerste vergelijking faalden gewone vragen op beide profielen, en het leek een verschil tussen de modellen. Dat was het niet: mijn eigen filterlaag zag landnamen, kloktijden en zelfs een bestandsnaam als config.py aan voor gevoelige gegevens en haalde ze weg vóórdat het model de vraag zag. “Wat is de hoofdstad van Frankrijk?” kwam binnen als “Wat is de hoofdstad van <LOCATION>?”. Een derde fout zat in de timing: de tests startten terwijl het model nog werd geladen. Alle drie zijn opgelost in de laag waar ze thuishoorden, niet door de test soepeler te maken. Het is de les uit deel 1 in een nieuwe gedaante: wat eruitziet als een beperking van het model, zit vaak in je eigen lagen.
Eén geval staat nog open, en het is een mooie. Op de vraag wie Max Havelaar schreef, ziet de filterlaag “Havelaar” aan voor een persoonsnaam en maakt die onherkenbaar. Het kleine model geeft dan eerlijk aan dat het het niet weet. Het grote model antwoordt vol overtuiging: Herman Melville — de schrijver van Moby Dick. Daar is het begin van deel 1 weer: een model dat zonder aarzeling een fout antwoord geeft, omdat het de juiste informatie niet heeft. De filterlaag zet ik daarvoor niet zomaar ruimer, want persoonsnamen beschermen is precies zijn taak; een preciezere oplossing staat op de lijst.
Geen van deze punten had ik gevonden zonder een test die elke keer hetzelfde meet. En bij een eigen oplossing bepaal je zélf waar de grens ligt, kun je hem testen, en kun je aantonen dat het gebeurd is.
De top 3 van mijn backlog
1. Draaien op Kubernetes, om hoge beschikbaarheid en schaalbaarheid echt te onderzoeken. Nu is het één machine: valt die om, dan ligt alles stil. Bovendien zit de verkeersbegrenzing in het geheugen van één proces — dat klopt niet meer zodra er twee draaien. Een cluster dwingt af wat ik nu nog kan uitstellen: gedeelde toestand, meerdere exemplaren naast elkaar, en een GPU-node die alleen aanstaat wanneer er werk is. Dat laatste is direct de brug tussen het schaalbaarheidsvraagstuk en het kostenvraagstuk uit dit artikel. Dit is voor mij het belangrijkste punt op de lijst.
2. Identiteit, rollen en echte netwerkscheiding. Vandaag is er één ongedifferentieerde sleutel: wie hem heeft, mag alles. Ik wil onderscheid tussen een gebruiker (chatten, zoeken) en een beheerder (de kennisbank vullen en opschonen), plus een aparte sleutel per gekoppeld systeem, zodat één lek niet meteen alles raakt. Daar hoort de netwerkkant bij: mijn toegangsbeperking leunt nu volledig op de firewall op de machine zelf, omdat het quotum voor securitygroepen nog op nul staat. Eén laag is geen gelaagde beveiliging.
3. Een volledig, bewaard auditspoor. Ik zie nu in de meetgrafieken hoe vaak er iets geblokkeerd of geanonimiseerd is, maar niet wanneer precies en door wie — dat staat alleen in de logregels van de container, en die verdwijnen zodra ik de omgeving afbreek. Centrale logopslag die een herbouw overleeft, is de ontbrekende schakel tussen “we hebben het goed geregeld” en “we kunnen aantonen dat we het goed geregeld hebben”. Voor NIS2 en de Cyberbeveiligingswet is dat verschil het hele punt.
Daaronder ligt genoeg: modelkeuze per soort taak, een vorm van geheugen tussen gesprekken, en de debat-podcast die zijn onderwerp rechtstreeks uit mijn eigen kennisbank haalt. Ideeën genoeg, en zoals ik vaak zeg: never a dull moment.
Nu is het moment
Wat dit traject mij bevestigt: de Europese route is geen ideologische keuze meer en al helemaal geen offer. De GPU liet zien dat de grens die ik in deel 1 tegenkwam een hardwaregrens was, geen principiële. Het model is Europees en echt open, de infrastructuur draait bij een EU CSP in een EU-regio die technisch is afgedwongen — en het werk dat de meeste organisaties dagelijks van AI vragen kan er vandaag al op. Inclusief, en dat had ik een half jaar geleden niet durven zeggen, een assistent die serieus meehelpt om verouderde code te ontrafelen en stap voor stap te moderniseren.
Tegelijk vraagt die route iets terug: rekenkracht is duur en schaars, en eigenaarschap is werk. Dat eerlijk benoemen maakt het verhaal sterker, niet zwakker.
Wat ik organisaties meegeef: begin niet met een lijvig strategiedocument, begin met één werkstroom (use case). Kies er een waar de aard van de gegevens ertoe doet, bouw hem echt, meet zelf in plaats van te vertrouwen op wat een leverancier of een benchmark belooft, en leg de keuzes vast als code zodat ze afdwingbaar zijn in plaats van goedbedoeld. Bouw de schakelaar in vóórdat je hem nodig hebt — de mijne kostte een dag werk en heeft me een herontwerp bespaard.
Ik help organisaties in Nederland en de bredere EU om die afweging nuchter te maken: wat kan vandaag al soeverein, wat nog niet, wat kost het echt, en hoe zorg je dat je over drie jaar nog kunt kiezen. Als hands-on architect en transformatiecoach werk ik daarbij samen met de mensen die de beslissing nemen én met de engineers die het bouwen — precies de brug tussen strategie, uitvoering en eigenaarschap. Alles volgens de principes die ook in mijn eigen R&D-omgeving dagelijks de praktijktoets doorstaan: infrastructuur, configuratie en beleid als code, gescheiden verantwoordelijkheden, policy-gates vóór elke wijziging, geautomatiseerde regressietests na elke deploy, en volledige aantoonbaarheid.
Heb je vragen over wat dit voor jouw organisatie betekent, of wil je weten waar je het beste kunt beginnen? Neem gerust contact met me op.
Bertrand de Neve De Neve IT Consulting B.V. — deneveit.nl
Tags: #digitalesoevereiniteit #soevereineai #eucloud #mistral #devstral #agenticcoding #legacymodernisatie #stranglerpattern #gpu #eucsp #hybridcloud #openweights #kubernetes #policyascode #testautomatisering #nis2 #devsecops #finops #it-architecture
Bronnen en verwijzingen Prijzen en quota van GPU-instances: eigen waarneming in de console van de gebruikte EU cloud service provider, september 2026. Test- en meetresultaten: eigen geautomatiseerde testsuite en bevindingenrapport cpu-fallback versus gpu, 22 september 2026. Schaarste en marktontwikkeling van datacenter-GPU’s: openbare prijsoverzichten van gespecialiseerde aanbieders, september 2026. Kenmerken van AI-platforms van non-EU cloud service providers: openbare productdocumentatie van de betrokken leveranciers, geraadpleegd september 2026. De verklaring tegenover de Franse Senaat over de reikwijdte van buitenlandse wetgeving: openbare berichtgeving, juli 2025.
Disclaimer Dit artikel is uitsluitend bedoeld voor informatieve en educatieve doeleinden. Het beschrijft de bevindingen van een persoonlijk R&D- en leertraject in een eigen onderzoeksomgeving; het is uitdrukkelijk geen productieomgeving, geen benchmark-studie en geen leveranciers- of aankoopadvies. Genoemde meetresultaten, prestaties en beperkingen zijn momentopnamen op een specifieke hardwareconfiguratie en zijn niet zonder meer generaliseerbaar naar andere modellen, versies of omgevingen. De resultaten van de eigen testsuite betreffen één definitieve run per profiel op een beperkte, vaste set testvragen en vormen geen statistisch onderbouwde vergelijking; genoemde responstijden zijn indicatief; waar een bevinding op praktijkervaring berust in plaats van op een meting, is dat in de tekst aangegeven. Genoemde uurtarieven zijn indicatief, gelden voor één specifieke configuratie bij één aanbieder op één moment, en zeggen niets over het aanbod van andere providers. Modelversies, licentievoorwaarden, quota, prijzen, productnamen en het dienstenaanbod van cloud- en AI-leveranciers wijzigen frequent — raadpleeg altijd de meest recente officiële bronnen voordat u hierop besluiten baseert. De reflectie op AI-platforms van cloudleveranciers is gebaseerd op openbaar beschikbare documentatie en berichtgeving op het moment van schrijven, betreft uitsluitend de in dit artikel genoemde aspecten en is niet uitputtend; genoemde leveranciers dienen als voorbeeld van een bredere categorie. Verwijzingen naar producten, modellen en leveranciers zijn feitelijk bedoeld en impliceren geen aanbeveling of afkeuring. Uitspraken over kostenontwikkeling, energieverbruik, beschikbaarheid van rekencapaciteit en de afweging tussen cloud, on-premise en hybride zijn een persoonlijke inschatting, geen voorspelling, aankoop- of investeringsadvies. Wet- en regelgeving waarnaar verwezen wordt, waaronder NIS2, de Cyberbeveiligingswet, de AVG en buitenlandse wetgeving met extraterritoriale werking, is aan verandering onderhevig en de toepassing ervan is situatieafhankelijk. De auteur is architect en transformatiecoach, geen jurist; voor toepassing in uw specifieke situatie wordt professioneel en, waar relevant, juridisch advies aanbevolen. Aan de inhoud van dit artikel kunnen geen rechten worden ontleend en de auteur aanvaardt geen aansprakelijkheid voor directe of indirecte schade voortvloeiend uit het gebruik van de beschreven informatie of methodieken.
Dit artikel is tot stand gekomen met assistentie van een AI-systeem. De technische implementatie, de uitgevoerde metingen, de inhoudelijke keuzes, de conclusies en de eindredactie zijn volledig van de auteur.