Lokaal draaien beschermt gevoelige prompts niet vanzelf

U moet voor elke verwerkingscomponent — geheugen, opslag, authenticatie, tenantisolatie — aantonen dat gevoelige prompts daar niet onversleuteld of ongeautoriseerd toegankelijk zijn, ongeacht of het model lokaal of in de cloud draait.

Een analyse van 6 november 2026 van lokale LLM-systemen die prompts via geheugen en opslag lekken stelt dat de hostinglocatie alleen geen garantie biedt dat gevoelige data binnen de eigen muren blijft. Onderzoekers vonden vier concrete lekroutes in gangbare lokale systemen: prompts bleven in werkgeheugen achter, wrappers schreven ze leesbaar naar schijf, een autorisatiefout gaf gebruikers toegang tot andermans gespreksstatus, en gedeelde prefixcaching veroorzaakte timingverschillen waarmee aanvallers konden afleiden wat anderen invoerden. In onze beoordeling betekent dit dat de beschermingsgrens niet bij "lokaal" of "cloud" ligt, maar bij de volledige verwerkingsketen die u aantoonbaar beheerst — en dat elke CISO, jurist en bestuurder die lokaal draaien als privacygarantie verkocht kreeg, die aanname moet herzien.

Waar lekken prompts in lokale systemen eigenlijk uit?

De vier lekroutes die onderzoekers vonden, zaten niet in het model zelf, maar in de componenten eromheen. Werkgeheugen bewaarde prompts na afloop van gesprekken. De software rond het model schreef invoer leesbaar naar schijf. Een authenticatiefout in alle tweehonderd geteste configuraties liet gebruikers de opgeslagen status van andermans gesprekken herstellen. En prefixcaching — een snelheidstruc die het begin van prompts hergebruikt — liet meetbare timingverschillen achter waarmee een aanvaller kon afleiden wat iemand anders had ingevoerd.

De gemene deler is dat geen van deze lekken het gevolg is van cloudverbinding of externe overdracht. Ze ontstaan in de verwerkingsketen die u lokaal controleert. Dat verschuift de verantwoordingslast: u kunt niet volstaan met "het model draait lokaal", maar moet per component aantonen dat gevoelige data daar niet onbeschermd toegankelijk is.

Welke risicocategorieën moet u per component controleren?

• Runtimegeheugen — prompts en tussenresultaten die na verwerking niet gewist worden en door lokale processen kunnen worden gelezen.
• Persistente opslag — plaintext-bestanden waar wrappers en logging prompts schrijven zonder versleuteling of toegangscontrole.
• Tenantisolatie — autorisatiefouten die gebruikers toegang geven tot andermans opgeslagen gesprekken of status.
• Prefixcaching en timing — hergebruik van promptfragmenten dat meetbare timingverschillen veroorzaakt waaruit inhoud kan worden afgeleid.
• Attestatie en vertrouwensgrenzen — gebrek aan cryptografisch bewijs dat verwerking in de juiste, onveranderde omgeving plaatsvindt.

Kan confidential computing deze lekken voorkomen?

Cloudinfrastructuur kan prompts en tussenresultaten blootstellen aan de dienstverlener, maar twee academische onderzoeken tonen aan dat hardware-isolatie die blootstelling tijdens verwerking kan beperken. In één studie daalde de nauwkeurigheid waarmee tekst uit model-output kon worden gereconstrueerd van ruim 97,5 procent naar gemiddeld 1,34 procent, terwijl de modeloutput identiek bleef. Een tweede evaluatie rapporteerde geen systematische prestatieverslechtering bij gebruik van confidential virtual machines met AMD SEV-SNP en Intel TDX op publieke cloud.

Belangrijk: beide resultaten betreffen specifieke onderzoeksarchitecturen. Confidential computing beschermt data tijdens verwerking via hardware-versleuteling en attestatie — cryptografisch bewijs dat u in de juiste omgeving draait. Maar metadata, sleutelbeheer, configuratie, subverwerkers en beschikbaarheid blijven aparte risico's die u zelf moet beheersen. "We draaien op een confidential VM" is zonder geverifieerde attestatie onvoldoende.

Welke concrete controles moet u per workflow kunnen aantonen?

1. Documenteer welke data de grens niet mag passeren — bepaal per gegevenssoort en per workflow welke prompts, tussenresultaten en metadata onder geen beding de gecontroleerde omgeving mogen verlaten.
2. Versleutel runtimegeheugen en persistente opslag — zorg dat prompts en tussenresultaten in geheugen en op schijf versleuteld zijn en niet door ongeautoriseerde processen kunnen worden gelezen.
3. Controleer tenantisolatie en authenticatie — verifieer dat gebruikers alleen hun eigen opgeslagen gesprekken kunnen herstellen en dat geen autorisatiefouten cross-tenant toegang toestaan.
4. Eis attestatie voordat gevoelige data verwerkt wordt — leg vast dat attestatiestatus per verwerking wordt geverifieerd voordat gevoelige data de grens passeert.
5. Inspecteer prefixcaching en timing-zijkanalen — controleer of hergebruik van promptfragmenten meetbare timingverschillen veroorzaakt waaruit inhoud kan worden afgeleid.

Hoe vertaalt u dit naar beleid en contracten?

Een survey onder Amerikaanse AI-leiders vond dat 61 procent gevoelige data naar publieke cloud-AI stuurt, terwijl 93 procent zich zorgen maakt over blootstelling aan infrastructuurproviders. Dit wijst op een zichtbare kloof tussen praktijk en beleid. Juristen kunnen in leverancierscontracten een afdwingbare eis opnemen dat de leverancier aantoont dat gespreksstatus per gebruiker is afgeschermd, met concreet inspectiebewijs in plaats van een algemene verklaring. Compliance officers kunnen die tweespalt vertalen naar een vastgelegde datagrens, zodat gebruik en beleid niet langer uiteenlopen.

Begin niet met de keuze lokaal of cloud, maar met de vraag welke data onder geen beding de gecontroleerde grens mag passeren. Werk vervolgens per gegevenssoort uit waar en hoe die verwerkt mag worden. Hostinglocatie bepaalt niet wat beschermd is; de aantoonbare gegevensgrens doet dat wel.

Tooling kan geheugen monitoren, opslag versleutelen en attestatie vastleggen. Maar de keuze welke data de grens niet mag passeren, en de beoordeling of een specifieke configuratie die grens werkelijk handhaaft, blijft uw eigen professionele verantwoordelijkheid.