van principe naar een goed functionerende proof of concept oplossing

Door Bertrand de Neve, De Neve IT Consulting B.V.

Introductie

Wie mij kent, weet dat ik met enige regelmaat onderzoek doe en de uitkomsten daarvan deel. Niet omdat ik graag publiceer, maar omdat ik in de praktijk keer op keer heb gezien hoe krachtig ‘show & tell’ is — in verandermanagement, en zeker bij het opbouwen van een vertrouwensrelatie. Een werkende demonstratie overtuigt nu eenmaal anders dan een powerpoint presentatie vol beloftes.

Op mijn eigen R&D-backlog staat een epic die met de maand belangrijker wordt: EU-soevereiniteit. Daaronder heb ik user stories beschreven voor identiteit (IAM), DNS, de werkplek — en AI.

In mijn vorige R&D-ronde, afgesloten met een geslaagde proof of concept (PoC) en het artikel Digitale soevereiniteit: van risico naar regie, beschreef ik het “waarom” en het “hoe” van soevereiniteit voor identiteit, DNS en de werkplek. Ik sloot dat artikel af met de aankondiging dat er in mijn R&D-omgeving ook aan een EU-soeverein taalmodel werd gewerkt. Dit artikel is dat vervolg: geen theorie, maar een verslag van wat er nu daadwerkelijk draait, wat het kost, waar het verrassend goed werkt, en — minstens zo belangrijk — waar het eerlijk gezegd nog niet goed genoeg is.

Waarom ik dit doe? Uit nieuwsgierigheid, en om mijn relaties zo concreet mogelijk mee te kunnen nemen in de (on)mogelijkheden. Ik werk meestal in een combinatierol als transformatie- / innovatiecoach én architect, en die rol vraagt dat ik weet waar ik het over heb — niet uit een whitepaper, maar liefst uit eigen ervaring. Mede door geopolitieke onrust, verschuift mijn focus daarbij steeds verder naar EU-soevereine oplossingen, zonder vendor lock-in en zonder dure licentiekosten. De belangrijkste conclusie van deze PoC kan ik hier alvast weggeven: we hebben vandaag de dag al prima opties en kansen. Laten we die alsjeblieft niet laten liggen.

Het model dat de tijd niet meer bijhield

Het begon met een antwoord dat er volstrekt overtuigd uitzag. Ik stelde mijn zojuist geïmplementeerde taalmodel een simpele eerste vraag over de Amerikaanse politiek, en het vertelde mij, zonder enige aarzeling, dat Joe Biden president van de Verenigde Staten is. Geen slag om de arm, geen “voor zover ik weet”. Gewoon: dit is zo.

Op zichzelf onschuldig, en makkelijk weg te lachen. Maar als je er even bij stilstaat, legt zo’n antwoord precies bloot wat er schuurt aan de manier waarop de meeste organisaties vandaag AI gebruiken. Je werkt met een groot, gesloten model, ontwikkeld in de Verenigde Staten of China. Je kent de trainingsdata niet. Je kent de afkapdatum van die training niet. Het draait op infrastructuur die je niet beheert, het is onduidelijk waar de data allemaal staat en langskomt, en de voorwaarden heb je niet onderhandeld. En toch geef je het je vragen, je documenten en, als je niet oplet, je klantgegevens en andere gevoelige informatie.

De vraag: kan dit eigenlijk wel, zonder enterprise-budget?

De vraag die ik mezelf stelde was heel concreet. Niet: is soevereine AI een goed idee? Maar: kan ik, met een beperkt R&D-budget en beperkte tijd, een AI-oplossing bouwen die van onder tot boven Europees soeverein is — en die goed genoeg is om er echt mee te werken?

Dat betekende drie harde eisen vooraf, waar ik gedurende het hele traject niet van ben afgeweken. Dat hoefde ook niet, want de mogelijkheden zijn groter dan we denken (of komt dat door mijn positieve en creatieve mind? 🙂).

Het model moet Europees en écht open zijn. Ik koos voor Mistral 7B, van een Frans bedrijf, onder de Apache 2.0-licentie. Dat klinkt vanzelfsprekend, maar dat is het niet. Onderweg leerde ik dat “open source” en “open weight” bepaald niet hetzelfde zijn: een model als Teuken-7B wordt gepresenteerd als soeverein alternatief, maar blijkt bij nader inzien niet-commercieel gelicenseerd. En Apertus van de ETH Zürich is inhoudelijk misschien wel het meest transparante model dat er is — inclusief open trainingsdata — maar Zwitserland is geen EU-lidstaat, en daarmee viel het af tegen mijn eigen kader. Soevereiniteit als harde eis maakt je keuzelijst korter dan je hoopt.

De infrastructuur moet Europees zijn, en dat moet afdwingbaar zijn. Mijn PoC draait op OpenStack, en mede daarom koos ik voor de Franse provider OVHcloud. Bewust in een regio die ook GPU’s aanbiedt, zodat ik later kan opschalen zonder te verhuizen. Maar hier zit een adder onder het gras die ik graag deel: OVHcloud biedt óók een GPU-regio in Canada aan. Een Europese provider kiezen is dus niet genoeg. De regio staat bij mij daarom hard gecodeerd in de Terraform-provider — niet als instelling die je per ongeluk kunt overschrijven, maar als letterlijke waarde — én er ligt een policy-as-code-regel overheen die de pipeline laat falen zodra iemand daarvan afwijkt. Een afspraak in een document is geen controle. Een check die je bouw tegenhoudt, dat is controle.

Ik bouw en beheer daarbij uitsluitend vanuit een CI/CD-pipeline en hanteer strikt separation of duties (SoD), shift-left security, dependency-scanning en de andere best practices die daarbij horen. De kennis die ik in mijn loopbaan heb opgedaan en heb bezegeld met vakbekwaamheidscertificering als DevOps- en DevSecOps-practitioner, gebruik ik in al mijn werk — dus ook in mijn R&D. Handmatig even inloggen en iets bijstellen op de server: dat gebeurt hier niet. Alles wat er staat, staat er omdat een pipeline het heeft neergezet en de security en kwaliteitscontroles zijn geslaagd.

De data blijft van mij. Geen gedeelde SaaS-laag die met mijn prompts of documenten meekijkt. Alles draait op infrastructuur die ik zelf provisioneer, configureer en na afloop weer afbreek.

En dan is er nog een vierde drijfveer, die eigenlijk het belangrijkst is: begrijpen door zelf te bouwen. Niet een dienst afnemen en er een mooie architectuurplaat bij tekenen, maar de infrastructuur, de deploy-pijplijn, de policy-handhaving en de applicatielaag zelf in elkaar zetten. Inclusief alle plekken waar de theorie en de praktijk uit elkaar liepen. Vooral daar, eigenlijk.

Wat er nu staat

Wie het openklapt ziet vier lagen, elk bewust in een eigen repository — SoD niet als beleidsregel, maar als structuur en best practice.

De infrastructuurlaag (Terraform) provisioneert het netwerk, de server, het publieke IP-adres en de opslag. De configuratielaag (Ansible) installeert alles wat daarop moet draaien en zet de firewall dicht. De policy-laag (OPA/Conftest) bewaakt de regels waar de andere twee zich aan moeten houden. En de applicatielaag (FastAPI) is een dunne, geauthenticeerde schil vóór het model, die de buitenwereld een standaard API biedt.

Op de server draaien vijf containers die elkaar alleen intern kunnen bereiken: het taalmodel zelf, de API-laag, een eigen zoekmachine, een vectordatabase voor mijn kennisbank, en een reverse proxy die automatisch een geldig HTTPS-certificaat regelt voor ai.deneve.consulting. Van buitenaf is in de praktijk maar één ding bruikbaar bereikbaar: die versleutelde ingang, en alleen vanaf mijn eigen netwerk. De enige uitzondering in de firewall is de poort die het certificaat nodig heeft om zichzelf te kunnen vernieuwen.

Van “het werkt” naar “ik gebruik het echt”

Er zit een groot gat tussen een demo of PoC en iets dat je dagelijks openslaat. Dat gat overbruggen bleek het leukste deel van het traject, en tegelijk het deel waar de soevereiniteitskeuze steeds opnieuw werd getest.

Want soevereiniteit sneuvelt zelden op de architectuur. Die sneuvelt op het moment dat een gebruiker de soevereine variant opent, hem omslachtig vindt, en het venster van de vertrouwde Amerikaanse applicatie er weer naast zet. Herken je dat? Ik denk dat vrijwel elke organisatie er inmiddels ervaring mee heeft. Daarom heb ik de interface niet als bijzaak behandeld maar als onderdeel van de proef: een bewuste combinatie, geïnspireerd op de bekende interfaces die iedereen inmiddels gewend is, met daarin verwerkt wat ik zelf het liefst gebruik. De aan/uit-schakelaars voor internet als aanvullende bron en voor de eigen kennisbank zitten direct bij het invoerveld. Documenten en audio sleep je erin. Een antwoord laat je desgewenst voorlezen, met een snelheidskeuze. En mijn favoriete functie — een gesproken podcast laten genereren over een onderwerp naar keuze — staat gewoon in de zijbalk.

Dat maakt dit meer dan een technische proefopstelling. Het is een behoorlijk geavanceerde proof of concept geworden, en juist daarmee kan ik beproeven waar de grens ligt van wat mogelijk is op redelijk gangbare servercapaciteit — geen exotische AI-hardware, gewoon een instance zoals elke organisatie er zo een kan huren, en waarmee AI dus betaalbaar blijft. Gezien de investeringen die wereldwijd in AI worden gedaan, kan het bijna niet anders dan dat we op dit moment massaal onder de kostprijs aan een AI-verslaving raken. Ik verwacht dan ook dat de abonnementsgelden met forse stappen zullen stijgen. Wat mij betreft een extra argument om nu al serieus naar open source en EU-soevereine alternatieven te kijken.

Het begon met de bronnenkwestie waarmee dit artikel opende. Een model met een trainingsafkap dat met stelligheid verouderde feiten verkondigt, is onbruikbaar voor serieus werk. De oplossing was niet een groter model, maar een betere werkwijze: een eigen, zelf-gehoste zoekmachine ernaast, zodat het model bij feitelijke vragen actuele bronnen raadpleegt en die er netjes bij vermeldt — traceerbaarheid en transparantie, in plaats van een stellig antwoord uit het niets. Geen externe zoek-API, geen data die alsnog naar een derde partij lekt.

Daarna kwam de stap die het pas echt persoonlijk maakte: een eigen kennisbank. Niet alleen het internet als aanvulling op de afkapdatum van het model, maar ook mijn eigen documenten — notities, transcripten, aanbiedingen, facturen — permanent doorzoekbaar, met diezelfde bronvermelding. En zodra je iets permanent opslaat, dringt vanzelf de volgende vraag zich op: wat zit erin, en hoe krijg ik het er weer uit? Een overzicht en een verwijderknop. Klein werk, maar het verschil tussen een demo die je één keer laat zien en een systeem dat je durft te blijven vullen.

Vanaf daar rolde het door. Documenten uploaden (PDF, Word, tekst, Markdown) om te laten samenvatten of vertalen. Audiobestanden laten transcriberen naar diezelfde kennisbank. Antwoorden laten voorlezen met een instelbare afspeelsnelheid — omdat de standaardcomponent die knop niet bood, heb ik daar een kleine eigen speler voor gemaakt. En als voorlopig sluitstuk een debat-podcast: het model schrijft een kort script waarin een voor- en een tegenstander over een gekozen onderwerp discussiëren, en twee verschillende stemmen spreken dat uit tot één audiobestand. De logische volgende stap ligt al vast op mijn backlog: het onderwerp rechtstreeks uit de eigen kennisbank halen, zodat de twee sprekers over mijn daadwerkelijke documenten in debat gaan.

Wat je alleen leert door het echt te bouwen

Als ik één ding uit dit traject zou willen meegeven aan iedereen die soevereine infrastructuur overweegt, dan is het dit: een architectuur die er goed uitziet in een diagram bewijst helemaal niets. Pas een echte pipeline-run, tegen echte cloud-resources, met een echte HTTP-call aan het eind, telt als bewijs.

Ik heb dat opgezocht door consequent iets te doen wat in een gewone demo nooit gebeurt: na elke verificatieronde breek ik de hele omgeving weer af. Deels om kosten te vermijden — dit is R&D, geen productie — maar vooral omdat elke nieuwe sessie daardoor opnieuw begint met opbouwen. Elke keer bleek zo of een fix van de vorige keer écht standhield, of alleen toevallig had gewerkt.

Dat leverde een reeks storingen op die in een eenmalige demo nooit zichtbaar waren geworden. Het patroon was elke keer hetzelfde: iets wat op het eerste gezicht extern of toevallig leek, gaf pas na grondig doorlezen van logs, broncode of protocolgedrag zijn werkelijke, veel specifiekere oorzaak prijs. Mijn belangrijkste les daaruit is bijna een gedragsregel geworden: sluit eerst je eigen lagen grondig uit voordat je een externe oorzaak aanneemt, en let daarbij vooral op regels die pas ná de eerste succesvolle run van kracht worden. Hoe ga jij daarmee om — accepteer je “het werkt nu weer” als afgeronde diagnose, of ga je door tot je de oorzaak hebt?

Een harde grens: agentic coding wordt nog niet goed ondersteund

Ik wilde het zelf-gehoste model als derde optie naast Copilot en Claude Code in mijn ontwikkelomgeving kunnen gebruiken. De integratie zelf is geslaagd, en zelfs behoorlijk elegant: het model verschijnt gewoon in mijn VS Code, chat en code-bewerking werken betrouwbaar, en ook een MCP-koppeling — het protocol waarmee je externe gereedschappen aan een AI-assistent hangt — is functioneel correct geïntegreerd. Alle gereedschappen worden netjes en volgens de standaard aangeboden. De aansluitingen liggen er, en ze werken technisch goed.

Maar zelfstandig laten werken — het model zelf bestanden laten lezen en aanpassen, wat tegenwoordig “agentic coding” heet — dat lukt met dit model nog niet betrouwbaar. En ik weet nu vrij precies waarom.

Bied ik het model één enkel, eenvoudig gereedschap aan met een duidelijk voorbeeld, dan gaat het foutloos: drie van de drie pogingen goed. Bied ik het de veertien gereedschappen aan die een echte codeerassistent nodig heeft, met het bijbehorende systeemprompt van ruim 6.500 tekens, dan stort het in: nul van de drie. Het model kopieerde in één poging letterlijk de voorbeeldwaarde uit de instructie in plaats van het gevraagde bestand, voegde in een andere poging ongevraagd een tweede aanroep toe, en liep in een derde vast in een generatie die na twee minuten nog niet klaar was.

Ik ben onderweg drie keer van verklaring veranderd. Eerst: “de API ondersteunt geen tool-calling” — die had ik gebouwd en getest, dus dat was het niet. Toen: “de client gebruikt een eigen tekstconventie in plaats van de standaard” — deels waar, maar achterhaald zodra ik het daadwerkelijke netwerkverzoek met een eigen testservertje onderschepte en zag dat er wél keurig volgens de standaard werd gevraagd. En uiteindelijk de conclusie die overbleef: dit is geen protocolprobleem en geen configuratieprobleem. Dit is modelcapaciteit. Een model van dit formaat (7B parameters), zonder de rekenkracht van een GPU en met beperkte parameteromvang, schiet simpelweg tekort voor een taak van deze complexiteit.

Ik vind dat geen tegenvaller. Dit is precies het soort grens dat je alleen vindt door iets echt te bouwen en het vervolgens te breken — en dat je eerlijk moet benoemen, want de ruil die aan dit hele traject ten grondslag ligt (soevereiniteit boven ruwe capability-score) is alleen een eerlijke ruil als je hem ook zo opschrijft. Wat wél betrouwbaar werkt: chatten, samenvatten, vertalen, documenten doorzoeken, code lezen en bespreken, transcriberen, voorlezen. Voor een groot deel van het dagelijkse werk in een organisatie is dat ruimschoots genoeg. Voor autonome code-agents nog niet.

Wordt vervolgd: de GPU

Blijft de vraag: hoeveel van die grens zit in het principe, en hoeveel gewoon in de hardware?

Ik ben ervan overtuigd dat het grotendeels het laatste is. Alles wat hierboven staat draait vandaag op een fallback-profiel: een ‘goedkope’ CPU-instance, bewust gekozen om de kosten te drukken en omdat de GPU-capaciteit er nog niet is. Hopelijk wordt mijn verzoek bij OVHcloud vlot ingewilligd — GPU-capaciteit is schaars en erg prijzig. De architectuur heb ik er al wel op voorbereid: één schakelaar zet de hele omgeving om naar een GPU-profiel met een aanzienlijk zwaarder model, zonder dat er iets herontworpen hoeft te worden.

Nu is het wachten op de toewijzing. Zodra die er is, gaat het GPU-profiel aan en draait er een fors zwaarder Europees model op dezelfde, ongewijzigde infrastructuur echter met veel meer rekenkracht en RAM geheugen. Dan doe ik exact dezelfde metingen opnieuw — dezelfde veertien gereedschappen, hetzelfde systeemprompt, dezelfde drie pogingen — en dan weten we of die grens werkelijk verschuift. Daarover een volgend artikel, met de cijfers erbij. Ik ben zelf minstens zo benieuwd als jij dat hopelijk ook bent.

Andere onderwerpen op mijn backlog: het model combineren met Nextcloud als kennisbank, en met ServiceNow. Mijn ServiceNow-omgeving is al gekoppeld aan mijn CI/CD-omgeving, waardoor ik test- en meetresultaten vanuit de pipeline aan het model kan doorgeven om te helpen bij het inschatten van het risico van een change — en waardoor ik incidenten en CMDB-gegevens als kennisbron kan ontsluiten. Enfin, ideeën genoeg. Of zoals ik vaker zeg: ‘Never a dull moment’.

Zelf de regie pakken

Wat dit traject voor mij bevestigt: soevereine AI is geen alles-of-niets-vraagstuk, en al helemaal geen ideologisch statement. Het is een reeks concrete, uitlegbare keuzes — over de herkomst van het model, over de jurisdictie van de infrastructuur, over waar je documenten landen — die je stuk voor stuk kunt maken, technisch kunt afdwingen en aantoonbaar kunt vastleggen. Voor een groot deel van wat organisaties vandaag met AI willen doen, is een Europese route al werkbaar. Voor het zwaarste werk momenteel nog niet helemaal, maar er wordt hard doorgewerkt om Europa op eigen benen te laten staan. Ook wat ICT betreft.

Ik help organisaties in Nederland en de bredere EU om die afweging nuchter te maken: welke (AI-)toepassingen kunnen vandaag al soeverein, welke nog niet, wat kost het, en hoe bouw je het zo dat je er later niet opnieuw in vast komt te zitten. Als hands-on en multi-skilled architect en transformatiecoach werk ik daarbij samen met de sleutelpersonen binnen de organisatie zelf en met de engineers die het uiteindelijk realiseren — de brugfunctie tussen strategie, planning en uitvoering. Alles gebouwd 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, en volledige aantoonbaarheid richting NIS2 en de Cyberbeveiligingswet.

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.

 

Tags: #digitalesoevereiniteit #soevereineai #eucloud #mistral #openweights #ovhcloud #openstack #terraform #ansible #policyascode #rag #selfhosted #llm #nis2 #devsecops #it-architecture

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 leveranciersadvies. Genoemde meetresultaten, prestaties en beperkingen zijn momentopnamen op een specifieke, bewust beperkte hardwareconfiguratie en zijn niet zonder meer generaliseerbaar naar andere modellen, versies of omgevingen. Modelversies, licentievoorwaarden, quota, prijzen en het aanbod van cloudproviders wijzigen frequent — raadpleeg altijd de meest recente officiële bronnen voordat u hierop besluiten baseert. Verwijzingen naar producten, modellen en leveranciers zijn feitelijk bedoeld en impliceren geen aanbeveling of afkeuring. Uitspraken over toekomstige prijsontwikkelingen zijn een persoonlijke verwachting, geen voorspelling of advies. Wet- en regelgeving waarnaar verwezen wordt, waaronder NIS2 en de Cyberbeveiligingswet, is aan verandering onderhevig. 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.

Schermafbeeldingen: eigen chat-interface van ai.deneve.consulting, door Bertrand de Neve.