De LLM verlaat de cloud. Tijd om je beveiliging op scherp te zetten.

De LLM verlaat de cloud. Steeds vaker draaien taalmodellen niet in een datacenter van een hyperscaler, maar op een server in een Nederlands ziekenhuis, op een edge-apparaat in een fabriek, of op een laptop van een ambtenaar. De reden is simpel: data soevereiniteit. Niemand wil dat gevoelige persoonsgegevens of staatsgeheimen via een API naar een Amerikaanse cloud verdwijnen.

Maar met die verschuiving verandert ook het dreigingsmodel. En daar hebben de meeste organisaties nog geen antwoord op.

Laatst zat ik bij een zorginstelling die een lokaal taalmodel wilde inzetten voor het samenvatten van patiëntdossiers. De IT-manager zei: "We draaien het model on-premise, dus we zijn veilig." Ik vroeg hem: "Hoe voorkom je dat een verpleegkundige via prompt injection het model zover krijgt dat het een diagnose stelt?" Stilte.

On-premise is geen magische schild. Het verplaatst alleen het probleem.

Het dreigingsmodel verschuift mee

Een paper van recente datum zet de beveiligingsuitdagingen van edge-LLM's systematisch op een rij. Securing LLMs in the Wild: Privacy and Security Challenges at the Edge analyseert wat er mis kan gaan als je een groot taalmodel buiten de cloud draait. De auteurs onderscheiden drie hoofdcategorieën: modelaanvallen, data-aanvallen en infrastructuuraanvallen.

Bij modelaanvallen denk je al snel aan prompt injection. Een kwaadwillende voert een prompt in die het model laat uitbreken uit zijn systeem-instructies. In een cloud-omgeving is dat vervelend. In een on-premise setting waar het model toegang heeft tot interne databases, wordt het ronduit gevaarlijk.

Data-aanvallen richten zich op het stelen van trainingsdata of het onderscheppen van input-outputstromen. Een lokaal draaiend model verwerkt mogelijk patiëntgegevens, financiële data of vertrouwelijke overheidsinformatie. De paper beschrijft hoe een aanvaller met modelinversie-aanvallen trainingsdata kan reconstrueren. Bij een model dat getraind is op medische dossiers, kan dat leiden tot het lekken van individuele patiëntgegevens.

Infrastructuuraanvallen zijn misschien wel het meest onderschat. Een edge-apparaat dat een LLM draait, is fysiek toegankelijk. Denk aan een server in een slecht beveiligde meterkast van een gemeentehuis. Side-channel attacks, waarbij een aanvaller via stroomverbruik of elektromagnetische straling modelparameters afleidt, zijn in een cloud-omgeving onmogelijk. In een on-premise setting zijn ze ineens reëel.

Wat betekent dit voor Nederlandse organisaties?

De paper noemt data soevereiniteit als belangrijkste drijfveer voor edge-deployment. Dat is precies wat ik zie bij overheidsklanten. De AVG, de BIO2 en de NIS2-richtlijn dwingen organisaties om grip te houden op hun data. Een lokaal taalmodel lijkt dan de oplossing.

Maar compliance stopt niet bij de keuze voor on-premise. De BIO2 schrijft voor dat je een actueel dreigingsbeeld moet hebben van je informatiesystemen. Als je een LLM toevoegt aan je infrastructuur, moet je dreigingsmodel mee veranderen. Prompt injection, data-extractie via inference, model poisoning tijdens federated learning, dit zijn geen theoretische risico's meer.

De AI Act voegt daar nog een laag aan toe. Hoog-risico AI-systemen, en veel toepassingen in de zorg en bij de overheid vallen in die categorie, moeten voldoen aan strenge eisen voor robuustheid, nauwkeurigheid en cybersecurity. Een lokaal draaiend model dat via een simpele prompt-injectie medische adviezen gaat geven, haalt die lat niet.

Federated learning: de volgende uitdaging

De paper besteedt veel aandacht aan federated learning, waarbij modellen decentraal worden getraind op lokale data. Alleen de modelupdates, geen ruwe data, gaan naar een centrale server. Klinkt als de heilige graal voor privacy, maar er zitten addertjes onder het gras.

Een aanvaller kan via de modelupdates alsnog gevoelige informatie afleiden. De paper beschrijft gradient leakage-aanvallen: door de updates te analyseren, reconstrueer je delen van de trainingsdata. Voor een zorginstelling die met federated learning patiëntgegevens verwerkt, is dat een nachtmerrie. De AVG vereist dat je passende technische en organisatorische maatregelen neemt. Als je niet kunt aantonen dat je modelupdates geen herleidbare informatie bevatten, ben je in overtreding.

Daarnaast is er het risico van model poisoning. Een kwaadwillende partij die deelneemt aan het federated learning-proces, kan bewust vervuilde updates sturen. Het centrale model wordt dan stelselmatig vergiftigd. In een zorgcontext: stel dat een aanvaller het model zo manipuleert dat het bepaalde diagnoses systematisch mist. De gevolgen laten zich raden.

Wat je wél kunt doen

De paper geeft geen pasklare oplossing, maar wel een helder dreigingslandschap. Van daaruit kun je als organisatie zelf maatregelen treffen. Een paar concrete stappen:

1. Breng je aanvalsoppervlak in kaart.
Waar draait het model? Wie heeft fysieke toegang? Welke data verwerkt het? Welke API's of databases zijn gekoppeld? Zonder antwoord op deze vragen is elk beveiligingsplan nattevingerwerk.

2. Implementeer input- en outputfiltering.
Prompt injection is niet volledig te voorkomen, maar je kunt de impact beperken. Valideer alle input voordat die het model bereikt. Filter output op gevoelige patronen, denk aan BSN-nummers, medische termen of financiële data, voordat een gebruiker die te zien krijgt.

3. Monitor modelgedrag.
Een lokaal draaiend model is geen statisch systeem. Log queries, track afwijkingen in output-distributies, en stel alerts in op ongebruikelijke patronen. Een model dat plotseling medische diagnoses gaat geven terwijl het alleen voor samenvattingen bedoeld is, moet direct worden uitgeschakeld.

4. Versleutel modelparameters.
Als een aanvaller fysieke toegang heeft tot de edge-server, moet die niet zomaar het model kunnen kopiëren. Encryptie van modelbestanden is een minimale eis. De paper noemt Trusted Execution Environments (TEEs) als een veelbelovende richting, maar die zijn nog niet breed beschikbaar voor LLM-inferentie.

5. Denk na over federated learning-architectuur.
Gebruik differential privacy om modelupdates te anonimiseren. Voeg ruis toe aan de gradients voordat ze naar de centrale server gaan. Dat maakt gradient leakage-aanvallen significant moeilijker. En implementeer robuuste aggregatiemechanismen die afwijkende updates kunnen detecteren en negeren.

De BIO2-toets

Voor overheidsorganisaties is de BIO2 leidend. Die schrijft een risicogebaseerde aanpak voor. Een lokaal LLM dat persoonsgegevens verwerkt, valt onder de hoogste risicoklasse. Dat betekent: periodieke penetratietests, onafhankelijke audits, en een continu bijgewerkt dreigingsbeeld.

De paper uit 2026 geeft je dat dreigingsbeeld op een presenteerblaadje. Gebruik het. Leg de dreigingscategorieën naast je eigen infrastructuur. Waar zitten de gaten? Welke aanvallen zijn voor jouw context het meest waarschijnlijk? Documenteer die analyse, want zonder documentatie heb je in de ogen van een auditor niets gedaan.

Hetzelfde geldt voor zorginstellingen die onder de NEN 7510 vallen. De eisen voor informatiebeveiliging in de zorg overlappen sterk met de BIO2. Een lokaal taalmodel dat patiëntgegevens verwerkt, moet voldoen aan dezelfde eisen als elk ander medisch informatiesysteem. De paper helpt je om de specifieke LLM-risico's te identificeren die in standaard risicoanalyses vaak over het hoofd worden gezien.

Geen reden om te wachten

De verschuiving naar edge-LLM's is onomkeerbaar. De voordelen op het gebied van latentie, kosten en data soevereiniteit zijn te groot om te negeren. Maar de beveiligingsuitdagingen zijn reëel en worden nog te vaak onderschat.

Wat me opviel in de paper: de auteurs benadrukken dat veel aanvallen niet nieuw zijn. Modelinversie, side-channel attacks, gradient leakage, het zijn bekende technieken uit de machine learning-literatuur. Wat wél nieuw is, is de context. Een aanval die in een academisch lab theoretisch was, wordt in een productieomgeving met echte patiëntgegevens ineens een incident met AVG-melding.

Dus nee, on-premise is niet per definitie veilig. Maar met een goed dreigingsmodel, de juiste technische maatregelen en een gedocumenteerde risicoanalyse kom je een heel eind. Begin vandaag nog met het in kaart brengen van je aanvalsoppervlak. De paper geeft je de checklist.

---

Bron: Securing LLMs in the Wild: Privacy and Security Challenges at the Edge, PDF

Verder lezen: AI Act zelftest: valt jouw AI-systeem onder de wet?