10 juni 2026

Use-case: host je eigen model in Europa

Een behandelaar bij een middelgrote zorginstelling plakt een stuk uit een cliëntdossier in ChatGPT en vraagt om een nette samenvatting. Niet uit kwade wil, maar omdat het werkt en omdat het tijd scheelt. De functionaris gegevensbescherming ziet het toevallig over een schouder gebeuren, en daarmee begint dit verhaal.

De organisatie in dit stuk is fictief, ik noem haar De Linde. Maar elke stap komt uit situaties die ik in het echt ben tegengekomen bij zorginstellingen, gemeenten en andere organisaties die hetzelfde pad liepen. Ik loop het hele traject door: van de eerste vergadering tot de eerste maand productie. Niet omdat zelf hosten altijd de juiste keuze is, maar omdat je pas goed kunt kiezen als je weet wat er werkelijk bij komt kijken.

De aanleiding: het gebeurt toch al

De Linde heeft zo'n 1.400 medewerkers, waarvan een groot deel in de directe zorg. Verslaglegging is een van de grootste tijdvreters: rapportages, overdrachten, brieven aan huisartsen. Toen het AI-vraagstuk op tafel kwam, was de eerste reflex van de directie: verbieden. Geen cliëntgegevens in publieke AI-tools, punt.

Het probleem met dat verbod kent iedereen die wel eens beleid heeft geschreven: het werkte niet. Een interne rondvraag, anoniem, leerde dat tientallen medewerkers AI-tools gebruikten voor werkteksten. Soms met gegevens die er absoluut niet in hadden gemoeten. Dat is geen incident, dat is een patroon. Mensen kiezen het gereedschap dat hun dag makkelijker maakt.

De conclusie van De Linde was daarom niet "strenger verbieden" maar "een alternatief bieden dat net zo makkelijk is, maar waarvan wij de dataflow kennen". En omdat het om gezondheidsgegevens gaat, bijzondere persoonsgegevens onder de AVG, wilde men de verwerking binnen Europa houden, bij een partij die niet onder Amerikaanse wetgeving zoals de CLOUD Act valt. Dit is geen juridisch advies, maar wel een technische realiteit: als je de hele keten zelf in handen hebt, is de discussie over waar je data heen gaat een stuk korter.

Stap 1: welk model eigenlijk?

De eerste echte keuze was het model. Hier ging het projectteam bijna meteen de fout in die ik vaker zie: beginnen bij het grootste en indrukwekkendste open model dat er is.

De nuchtere route is andersom. Eerst opschrijven wat het model moet kunnen. Voor De Linde was dat: goed Nederlands schrijven, samenvatten, herformuleren naar B1-taal voor cliëntbrieven, en overweg kunnen met lange rapportages. Geen ingewikkeld meertraps redeneerwerk, geen code genereren.

Daarna pas kijken naar modellen. Het team maakte een testset van zo'n veertig echte taken, met geanonimiseerde teksten, en liet drie open modellen in verschillende groottes daarop los. Wat bleek: een model in de middenklasse, ruwweg de categorie van 20 tot 30 miljard parameters, deed het op deze taken nauwelijks slechter dan een model dat drie keer zo groot was. Voor samenvatten en herschrijven in het Nederlands was het verschil in de blinde beoordeling door medewerkers vrijwel niet te zien.

Dat scheelt enorm in de hardware. En het is een les die ik blijf herhalen: kies je model op basis van je eigen taken, niet op basis van leaderboards. Let daarbij ook op de licentie. Sommige open modellen hebben een echte open-source licentie zoals Apache 2.0, andere hebben eigen voorwaarden van de maker. Lees die voordat je iets in productie zet.

Stap 2: waar draait het ding?

Dan de GPU-capaciteit. De Linde had drie opties op tafel.

Optie een: zelf hardware kopen en in de eigen serverruimte zetten. Maximale controle, maar ook een investering van tienduizenden euro's, plus de vraag wie het beheer doet als de ene systeembeheerder met GPU-kennis op vakantie is.

Optie twee: GPU's huren bij een van de grote Amerikaanse hyperscalers, in een Europees datacenter. Technisch prima, maar daarmee haal je precies de afhankelijkheid binnen die je probeerde te vermijden. Een Europees datacenter van een Amerikaans bedrijf is data residency, geen data-soevereiniteit. De locatie van de server is niet hetzelfde als de jurisdictie van het bedrijf erachter.

Optie drie: GPU-capaciteit huren bij een Europese partij. Er zijn inmiddels meerdere Europese aanbieders van GPU-servers en modelhosting, van grote spelers tot gespecialiseerde partijen. De Linde koos deze route: een gehuurde server met een professionele GPU met 48 GB VRAM, in een Nederlands datacenter, bij een Europees bedrijf. Geen koopinvestering, wel een vast maandbedrag, en de mogelijkheid om op te schalen of te stoppen.

De doorslag gaf iets onverwachts: de verwerkersovereenkomst. Bij de Europese partij was binnen twee weken helder wie waar verantwoordelijk voor was. Dat gesprek is bij een hyperscaler met standaardvoorwaarden van honderden pagina's een stuk taaier.

Stap 3: de inference server en het endpoint

Een model en een GPU zijn nog geen dienst. Daar zit een inference server tussen: de software die het model laadt, verzoeken aanneemt en antwoorden teruggeeft. De Linde koos vLLM, een veelgebruikte open-source inference server die gebouwd is voor meerdere gelijktijdige gebruikers en die slim omgaat met GPU-geheugen.

Het belangrijkste praktische detail: vLLM biedt een OpenAI-compatible API. Dat betekent dat het endpoint zich gedraagt zoals de API van OpenAI. Applicaties die met OpenAI kunnen praten, kunnen met een kleine aanpassing ook met jouw eigen model praten. Meestal komt het neer op twee dingen veranderen: het basisadres van de API en de API-sleutel.

Voor De Linde was dat goud waard. De organisatie had al een intern hulpmiddel waarin medewerkers teksten konden laten samenvatten, gebouwd op de OpenAI-API in een pilotfase. De leverancier hoefde geen nieuwe integratie te bouwen. Eén configuratiewijziging, en hetzelfde scherm praatte ineens met het eigen model in het Nederlandse datacenter in plaats van met een Amerikaanse cloud. De gebruiker ziet alleen het antwoord. De organisatie moet de hele dataflow begrijpen, en die liep nu aantoonbaar binnen Europa.

Wel met twee toevoegingen die ik iedereen aanraad. Ten eerste een eigen tussenlaag, een simpele gateway, die per applicatie een eigen sleutel uitgeeft en al het verkeer logt: wie vroeg wat, wanneer, hoeveel tokens. Geen inhoud van prompts in de standaardlogs, wel metadata, dat was de bewuste afweging. Ten tweede netwerkafscherming: het endpoint hangt niet open aan het internet, maar is alleen bereikbaar vanaf de eigen systemen.

En toen kwam productie

De demo is makkelijk. Productie is waar AI serieus wordt. In de eerste zes weken liep De Linde tegen drie dingen aan die ik bijna elk zelf-host-project zie tegenkomen.

Eerste probleem: latency op piekmomenten. Om half negen 's ochtends en rond de overdracht om drie uur wilden tientallen medewerkers tegelijk rapportages samenvatten. Lange documenten erin, lange antwoorden eruit. Het model bleef antwoorden, maar de wachttijd liep op van een paar seconden naar ruim een halve minuut. Technisch gebeurde er niets geks: de GPU heeft een maximum aan wat hij tegelijk kan verwerken, en lange contexten vreten geheugen. De oplossingen waren prozaïsch: een limiet op de maximale invoerlengte, streaming aanzetten zodat het antwoord woord voor woord verschijnt en de wachttijd korter voelt, en uiteindelijk de afweging of er een tweede GPU bij moest. Die kwam er, voorlopig, niet. De limieten bleken genoeg.

Tweede probleem: de kostendiscussie. Een gehuurde GPU-server kost een vast bedrag per maand, ook 's nachts en in het weekend als er bijna niemand iets vraagt. Iemand van financiën rekende uit dat dezelfde hoeveelheid verkeer via een API-aanbieder per token afgerekend goedkoper zou zijn geweest. Dat klopte, in die eerste maanden. Het is het eerlijke verhaal van zelf hosten: je betaalt voor capaciteit, niet voor gebruik. Dat wordt pas gunstig bij voldoende volume, en het rekenmodel verandert zodra meer toepassingen op hetzelfde model gaan draaien. Bij De Linde kwamen er binnen een half jaar twee toepassingen bij, waaronder een zoekfunctie op interne protocollen, en toen begon de som de andere kant op te kantelen. Maar wie alleen een chatvenster voor twintig mensen wil, moet zich afvragen of een eigen GPU het juiste startpunt is.

Derde probleem: updates. Open modellen ontwikkelen zich snel. Na vier maanden verscheen een nieuwere versie van het gekozen model, merkbaar beter in Nederlands. Bij een API-aanbieder krijg je zo'n verbetering soms stilzwijgend, of je zet een modelnaam om. Bij zelf hosten ben je het zelf: nieuwe gewichten binnenhalen, de testset van veertig taken er opnieuw doorheen draaien, vergelijken, en pas daarna omzetten. De Linde heeft daar een vast ritme van gemaakt, elk kwartaal een evaluatieronde. Dat klinkt als overhead, en dat is het ook. Het is tegelijk de reden dat niemand daar wakker ligt van een modelwissel: er ligt altijd een recente meting onder.

Wat het opleverde

Na een jaar is de balans bij De Linde als volgt. Het schaduwgebruik van publieke AI-tools is niet helemaal verdwenen, maar wel sterk gedaald, simpelweg omdat het interne alternatief er is en goed genoeg werkt. De verwerking van cliëntgegevens voor deze toepassingen loopt aantoonbaar binnen Europa, op infrastructuur waarvan de organisatie elke schakel kan benoemen. Bij vragen van de functionaris gegevensbescherming of een auditor is er een antwoord dat verder gaat dan "dat staat in de voorwaarden van de leverancier": er zijn logs, er is een verwerkersovereenkomst met één duidelijke partij, er is een gedocumenteerde keten.

En misschien wel het belangrijkste: de organisatie heeft geleerd hoe dit werkt. De keuze voor een model, de rekensom achter GPU-geheugen, het verschil tussen een vlotte demo en een dienst die om half negen overeind blijft. Die kennis maakt elke volgende AI-beslissing beter, ook als die volgende beslissing is om iets juist niet zelf te hosten.

Het denkmodel, als je dit overweegt

De volgorde die bij De Linde werkte, en die ik zelf ook hanteer:

1. Begin bij de taken, niet bij het model. Maak een eigen testset van echte voorbeelden. 2. Kies het kleinste model dat die taken goed doet. Groter is duurder, niet automatisch beter. 3. Beslis bewust over jurisdictie: een Europese serverlocatie is iets anders dan een Europese partij. 4. Gebruik een inference server met een OpenAI-compatible endpoint, zodat bestaande applicaties met minimale aanpassing kunnen aansluiten. 5. Zet er vanaf dag één een gateway met logging en eigen sleutels tussen. 6. Reken eerlijk: vaste GPU-kosten tegenover gebruik per token, en bedenk welke toepassingen er nog bij komen. 7. Plan modelupdates als terugkerend proces, met je testset als meetlat.

Zelf hosten in Europa is geen principekwestie en geen hype. Het is een infrastructuurkeuze, met echte kosten en echt beheer, die voor sommige organisaties precies de goede is en voor andere onnodig zwaar. Het verschil zit niet in de techniek, die is inmiddels volwassen. Het verschil zit in of je vooraf weet waarom je het doet, en of je bereid bent het ook na de livegang serieus te blijven nemen.

↘︎ ALLE ARTIKELEN