On-prem LLM voor gereguleerde sectoren: architectuur zonder dataverlies

In gereguleerde sectoren eindigt de meeste discussie over AI-implementatie bij dezelfde vraag: "En waar komen onze data dan terecht?" Wanneer een hoofdarts, compliance officer van een bank of partner van een advocatenkantoor die vraag stelt, is het geen retorische — achter een verkeerd antwoord schuilt een boete, intrekking van de vergunning of strafrechtelijke aansprakelijkheid.

Dit artikel gaat niet over de vraag *of* u on-prem moet gaan — daarover schreven we al in de vergelijking van lokale LLM's en de cloud. Dit gaat over *hoe* u een on-prem LLM-infrastructuur bouwt die standhoudt voor de toezichthouder, de IT-audit en het dagelijkse gebruik.

Waarom de cloud niet volstaat — ook als de provider GDPR belooft

Cloud-providers hebben uitstekende beveiligingscertificaten. Het probleem is niet hun technologie — het probleem is de juridische constructie en de architectuur van de datastromen.

Wanneer u een prompt naar een extern API stuurt, verlaten de data fysiek uw infrastructuur. Ook al persisteert de provider uw verzoeken niet (en de meeste enterprise-tiers beweren dat tegenwoordig), vanuit het perspectief van GDPR artikel 28 bent u een verwerkersrelatie aangegaan. Dat vereist een ondertekende verwerkersovereenkomst (DPA), verificatie van de derde partij en een register van verwerkingsactiviteiten.

Voor zorginstellingen geldt in de VS HIPAA, of in de EU de lokale omzetting van de EDPB-aanbevelingen. Voor banken gelden EBA ICT-risico en het DORA-framework. Voor advocatenkantoren is de vraag nog eenvoudiger: het beroepsgeheim maakt geen onderscheid tussen papier en een API-verzoek.

On-prem elimineert het risico van data-egress in principe. Geen enkel token van uw patiënten, cliënten of transacties verlaat uw netwerk. Dat is een verschil dat geen marketingframing is — het is een auditeerbaar technisch feit.

Laten we tegelijkertijd eerlijk zijn: on-prem is op zichzelf onvoldoende voor compliance. De toezichthouder wil auditlogs, toegangscontroles, versleuteling van data in rust én in transit, een gedocumenteerd incidentresponsproces en regelmatige risicoanalyses zien. "Het draait op onze eigen server" is een vertrekpunt, geen eindpunt.

Wat een on-prem LLM-architectuur moet bevatten

Voordat u een GPU en een model kiest, moet u definiëren wat u eigenlijk aan het bouwen bent. Een functionele on-prem LLM-architectuur voor gereguleerde sectoren heeft vijf lagen:

1. Serving engine en inferentielaag

Voor productie-multi-user-implementaties zijn twee hoofdframeworks relevant:

• `vLLM` — de industriestandaard voor high-throughput serving. PagedAttention vermindert KV-cache-fragmentatie drastisch, continuous batching elimineert wachten op het traagste verzoek in een batch. Breedste hardwareondersteuning (NVIDIA, AMD, Gaudi).
• `SGLang` — voordelig bij RAG-workloads en meerondige dialogen dankzij RadixAttention, dat de KV-cache van gedeelde prefixen opslaat. Op prefix-zware workloads haalt het een hogere throughput én lagere time-to-first-token (TTFT) dan vLLM.

Voor experimenten en pilots door individuele ontwikkelaars voldoet Ollama. Voor een productiesysteem met tientallen gelijktijdige gebruikers is het onderdimensioneerd — eronder draait llama.cpp, dat niet is ontworpen voor gelijktijdige verzoeken, en het verschil in throughput is bij meerdere parallelle aanvragen aanzienlijk.

2. Model — wat u kunt draaien en wat het aankan

De modelkeuze voor on-prem is primair een hardwarevraag. De hoeveelheid VRAM bepaalt wat u kunt draaien.

Indicatieve VRAM-vereisten voor inferentie (voor formaten die gangbaar zijn bij on-prem):

• 7–9B model: ~5–7 GB VRAM bij Q4_K_M-kwantisering, ~8–13 GB bij Q8_0
• 13B model: ~8 GB bij Q4_K_M, ~14 GB bij Q8_0
• 34B model: ~17–20 GB bij Q4_K_M, ~30–34 GB bij Q8_0
• 70B model: ~35–40 GB bij Q4_K_M, ~70–75 GB bij Q8_0

Daarbij komt de KV-cache — bij lange contexten kan die even groot zijn als de modelgewichten zelf. Voor een productie-implementatie met meerdere gelijktijdige verzoeken en middelmatig lange contexten moet u rekenen op een aanzienlijke marge bovenop de VRAM voor de gewichten alleen.

Van de open-weight-modellen die in 2026 zinvol zijn voor gereguleerde sectoren:

• Llama 4 Maverick en Scout (Meta, eigen licentie) — MoE-architectuur, sterke prestaties, 1M+ context. De Meta custom-licentie is voldoende voor de meeste enterprise interne implementaties.
• Qwen 3-familie (Alibaba, Apache 2.0) — uitstekende prestaties op documentintensieve taken, meertalige ondersteuning inclusief Europese talen, permissieve licentie.
• Mistral Small (Apache 2.0) — Europese provider (pluspunt voor GDPR-argumentatie), permissieve licentie. Het grotere Mistral Large heeft een eigen Mistral-licentie — controleer die voor commerciële on-prem-implementaties.
• Phi-4 (Microsoft, MIT) — voor use-cases waarbij de capaciteit van 7–14B parameters volstaat; lage hardwarevereisten, goede instructieopvolging.

Voor gereguleerde sectoren raden we modellen met een permissieve licentie (Apache 2.0, MIT) aan — commercieel gebruik is ondubbelzinnig en de licentie-audit is rechtlijnig.

3. Kwantisering — een compromis dat doorgaans aanvaardbaar is

Kwantisering verlaagt de VRAM-voetafdruk en verhoogt de throughput, ten koste van een iets lagere nauwkeurigheid. Voor gereguleerde sectoren is de centrale vraag: welk compromis is aanvaardbaar voor de betreffende taak?

Praktisch overzicht van de formaten:

• Q8_0 (GGUF): behoudt ~98–99% van de kwaliteit ten opzichte van FP16, minimaal verlies. Voor kritieke taken (juridische analyse, medische documentatie) is dit de veilige keuze.
• Q4_K_M (GGUF): ~92–95% kwaliteit, aanzienlijk lagere VRAM-vereisten. Het sweet spot voor de meeste documentatie- en RAG-use-cases. Het verschil met Q8 is bij gewone conversaties nauwelijks merkbaar.
• AWQ 4-bit: geschikt voor NVIDIA GPU's, betere coherentie bij lange uitvoer dan GPTQ.
• Q2 en lager: aanzienlijke kwaliteitsdegradatie — niet aanbevolen voor gereguleerde sectoren.

Belangrijke kanttekening: de perplexiteitsverschillen tussen Q4_K_M en BF16 liggen op de meeste benchmarks onder de 6%. Dat betekent niet dat elke taak even robuust is — complexe meertrapsredenering en precieze extractie van gestructureerde informatie kunnen gevoeliger zijn. Valideer het model altijd op een steekproef van reële data uit uw domein voordat u het in productie neemt.

4. Datalaag en RAG

Voor de meeste gereguleerde use-cases volstaat het model alleen niet — u moet het koppelen aan interne documentatie, regelgeving en casehistorie. Hier komt RAG (Retrieval-Augmented Generation) om de hoek kijken.

Kerncomponenten:

• Vectordatabase lokaal geïmplementeerd: Qdrant (open-source, Rust-backend, GDPR-vriendelijk Europees bedrijf), pgvector (PostgreSQL-extensie, eenvoudig als u al PG heeft) of Milvus.
• Embeddingmodel lokaal: BGE-M3 (BAAI) dekt meerdere Europese talen en retrievaltypes in één model. Draait lokaal, geen cloud.
• Chunking en metadata: voor medische dossiers of juridische documenten is gestructureerde chunking op basis van logische eenheden (artikel, alinea, zaak) aanzienlijk beter dan naïeve verdeling per N tokens.

De contextvenstergrootte van moderne modellen (1M+ tokens) is verleidelijk, maar is geen vervanging voor RAG in een productiesysteem. De KV-cache voor een context van 1M neemt tientallen extra GB VRAM in beslag en de TTFT-latency stijgt drastisch. Voor de meeste documentatie-use-cases is een hybride aanpak (retrieval + kortere context) zowel economisch als qua prestaties beter.

5. Audit, toegangscontroles en monitoring

Dit is de laag die technische teams het vaakst uitstellen — en precies de laag waar toezichthouders op hameren.

Minimumeisen voor een gereguleerde on-prem LLM:

• Auditlogs van elk verzoek: wie vroeg wat, wanneer, wat was de prompt (of de hash van de prompt), wat was de uitvoer (of de hash), welke modelversie heeft geantwoord. Logs moeten tamper-evident zijn (write-once-opslag of ondertekening).
• Role-based access: een arts ziet de dossiers van zijn eigen patiënten, niet het hele ziekenhuis. Het LLM-endpoint moet dezelfde ACL-regels respecteren als de rest van het systeem.
• Versleuteling at-rest én in-transit: modelgewichten, vectordatabase, logs — alles versleuteld. TLS voor alle interne communicatie.
• Netwerkisolatie: de LLM-inferentieserver mag geen directe internettoegang hebben. Air-gap of minimale outbound firewall voor het serving-knooppunt.
• Model version pinning: in gereguleerde sectoren moet u kunnen aantonen welk model een beslissing heeft genomen — ook over een jaar. Versiebeheer van gewichten en deterministische reproduceerbaarheid zijn auditvereisten.

Hardware — wat u werkelijk nodig heeft

On-prem LLM is geen goedkope oplossing. Het is een investering die zinvol is waar het alternatief (cloud compliance-overhead, risikoverzekering voor dataverlies, een boete) duurder uitvalt.

Ter oriëntatie in 2026:

• Instapniveau (7–13B model, 1–5 gelijktijdige gebruikers): één NVIDIA RTX 4090 (24 GB VRAM) of A4000 (16 GB VRAM). Voor 13B in Q4_K_M is dat voldoende; voor 13B in Q8_0 heeft u dual-GPU of een 4090 nodig.
• Mid-tier (34B model of 70B in Q4_K_M, 5–20 gelijktijdige gebruikers): twee A5000 (24 GB × 2 = 48 GB), A6000 (48 GB), of de consumentenroute — twee RTX 4090's in tensor parallelisme via NVLink/PCIe.
• Productietier (70B in Q8_0 of hoger, 20+ gelijktijdige gebruikers): A100 80 GB of H100 80 GB. Op één H100 kunt u 70B Q8_0 comfortabel serveren met redelijke latency.
• Apple Silicon-alternatief: M4 Ultra / M5 Ultra met 128–192 GB unified memory is een zinvolle on-prem-keuze voor 70B FP16 waar een stille serverruimte en laag energieverbruik prioriteit hebben. De throughput ligt lager dan bij de H100, maar voor interne implementaties met lage concurrency kan dat voldoende zijn.

Vergeet het CPU-geheugen niet — bij CPU-offloading (als de GPU-VRAM onvoldoende is) draait een deel van het model in RAM. Voor een productie-implementatie met offloading heeft u minimaal 128 GB RAM nodig.

Wat on-prem LLM niet is

Waarschijnlijk de meest voorkomende misvatting in het besluitvormingsproces: on-prem LLM betekent niet automatisch compliance. We hebben organisaties gezien die Ollama op een werkstation installeerden en vol vertrouwen beweerden GDPR-compliant te zijn omdat "de AI lokaal draait".

Compliance is een proces, geen installatiestatus. Bij on-prem-infrastructuur moet u ook het volgende toevoegen:

• Een formele risicoanalyse en DPIA (gegevensbeschermingseffectbeoordeling) als u bijzondere persoonsgegevens verwerkt
• Registratie van verwerkingsactiviteiten die het LLM-systeem omvat
• Retentieregels — hoe lang bewaart u auditlogs, wie heeft toegang
• Een incidentplan — als er een beveiligingsincident optreedt, wat gebeurt er met de logs, wie meldt het aan de toezichthouder
• Regelmatige penetratietests van de inferentie-endpoints

Technische teams die dit zelfstandig oplossen zonder juridische inbreng, produceren doorgaans een systeem dat technisch werkt maar bij een compliance-audit faalt op de procesdocumentatie.

Vergelijking: on-prem vs. sovereign cloud vs. klassieke cloud

Voor gereguleerde sectoren bestaan er in werkelijkheid drie varianten, niet twee:

• Klassieke cloud-API (OpenAI, Anthropic, Google): laagste overhead, hoogste prestaties, maar data-egress is reëel. Geschikt voor use-cases waarbij u niet werkt met gevoelige PII of data die valt onder sectorale regelgeving.
• Sovereign cloud / EU-regio (Azure OpenAI EU, Anthropic Sovereign EU, OVH AI): data blijft in de EU, de provider is gebonden aan EU-contracten, de prijslijst is hoger. Voor veel organisaties is dit een beter compromis dan full on-prem — minder hardware-investering, hogere modelprestaties, met behoud van het GDPR-kader.
• Full on-prem / air-gap: geen data-egress, volledige controle, auditeerbaarheid in de strikte zin. Vereist een hardware-investering, eigen beheer en een eigen securitystack. De enige optie voor de strengste regelgeving (zoals verwerkers van gerubriceerde informatie, bepaalde soorten medische data).

Voor de meeste Nederlandse en Europese bedrijven in gereguleerde sectoren is sovereign cloud gecombineerd met selectieve on-prem voor de gevoeligste workloads de pragmatische weg. Niet alle LLM-taken hoeven on-prem te draaien — alleen die waarvoor de data het vereisen.

Guardrails en modelbeveiliging

On-prem implementatie lost externe data-egress op, maar niet interne risico's. Het model kan hallucineren, misleidende medische of juridische inhoud produceren of worden misbruikt via prompt injection.

Voor gereguleerde sectoren zijn de volgende maatregelen onmisbaar:

• Outputvalidatie: LLM-uitvoer moet een validatielaag doorlopen voordat die wordt weergegeven of verder verwerkt. Gebruik voor gestructureerde uitvoer (extractie van gegevens uit documenten, classificatie) constrained decoding (XGrammar-backend in vLLM of SGLang).
• Human-in-the-loop voor kritieke beslissingen: geen enkel on-prem-model mag automatisch medische adviezen ondertekenen, kredieten goedkeuren of juridisch bindende documenten genereren zonder menselijke controle. Meer hierover in human-in-the-loop voor agents.
• Outputmonitoring: bewaking van weigeringen, ongebruikelijke patronen in prompts en pogingen om de systeemprompt of de context te extraheren.

Veelgestelde vragen

Is on-prem LLM altijd duurder dan de cloud?

Bij een laag verzoekvolume (tot enkele duizenden verzoeken per dag) is een cloud-API goedkoper — u hoeft niet te investeren in een GPU. Bij een hoog volume kruisen de lijnen elkaar: een eigen GPU-server schrijft zich bij een gemiddelde belasting doorgaans af in 1–2 jaar. Voor gereguleerde sectoren gaat het echter primair niet om de prijs — het gaat erom wat uw organisatie zich kan veroorloven vanuit compliance-oogpunt.

Hoeveel VRAM heb ik nodig voor gewoon bedrijfsmatig gebruik?

Voor de meeste bedrijfsmatige use-cases (documentanalyse, interne copilot, classificatie) volstaat een 7–13B-model in Q4_K_M-kwantisering. Daarvoor is een NVIDIA RTX 4090 (24 GB) of A5000 (24 GB) voldoende. Als u een groter model (34B of 70B) wilt voor zwaardere juridische of medische analyses, reken dan op dual-GPU of een professionele kaart met 48–80 GB VRAM.

Heb ik ISO 27001 of een ander certificaat nodig om on-prem LLM legaal te gebruiken?

Niet rechtstreeks — noch de AVG noch sectorale regelgeving vereist specifieke certificaten, maar ze vereisen wel "passende technische en organisatorische maatregelen". ISO 27001 is de praktijk die aantoont dat u risico's systematisch heeft beheerst — het vereenvoudigt de compliance-audit aanzienlijk en wordt steeds vaker door zakenpartners geëist.

Kan ik een open-weight-model commercieel gebruiken zonder juridische risico's?

Dat hangt af van de licentie. Apache 2.0 en MIT zijn volledig commercieel bruikbaar zonder beperkingen. De Meta Llama-licentie staat commercieel gebruik toe, maar vereist bij meer dan 700 miljoen actieve gebruikers een speciale toestemming — voor interne enterprise-implementaties is dat niet relevant. Controleer altijd de actuele licentietekst bij het kiezen van een model.

Hoe zorg ik ervoor dat het model bedrijfsdata niet bewaart of doorgeeft?

Bij lokale implementatie persisteert het model zelf geen data — een LLM is een statische set gewichten, geen database. Het risico zit in de perifere lagen: logs van het serving-framework, KV-cache op schijf (als dat ingeschakeld is), contextvensters die bij een verkeerde configuratie tussen sessies worden gedeeld. Zorg ervoor dat de serving engine is geconfigureerd zonder cross-sessie context-deling, dat logs uitgeschakeld of versleuteld zijn, en dat KV-cache-offload naar schijf uitgeschakeld is of op een versleuteld volume draait.

*Overweegt u on-prem LLM voor de zorg, financiën of rechtspraktijk en weet u niet waar te beginnen — dan kijken we graag concreet naar uw situatie. We helpen met de hardwarekeuze, de architectuur van de serving-stack en wat u aan het compliance-team moet kunnen laten zien. Neem contact met ons op en we beginnen met een beoordeling van uw werkelijke vereisten.*