Lokaal draaien beschermt gevoelige prompts niet vanzelf: onderzoekers vinden lekken in geheugen en tenantisolatie

Nee. Onderzoekers toonden dat lokale LLM-systemen prompts alsnog lekken via runtimegeheugen, plaintext-opslag, een cross-tenant autorisatiefout en gedeelde prefixcaching. De verdedigbare keuze is niet lokaal versus cloud, maar een aantoonbare gegevensgrens: bepaal welke data de eigen server nooit mag verlaten en controleer geheugen, opslag, interfaces en attestatie van elke verwerkingscomponent.

Een recente academische studie, "The Illusion of Local Privacy", "The Illusion of Local Privacy", ondergraaft een aanname die veel organisaties hanteren: dat een lokaal draaiend taalmodel gevoelige prompts vanzelf binnen de eigen muren houdt. De onderzoekers vonden in gangbare consumenten-LLM-systemen vier concrete manieren waarop prompts alsnog uitlekken, ook zonder cloudverbinding. Dat raakt elke bestuurder, jurist, arts of CISO die lokaal draaien als privacygarantie verkocht kreeg.

Voor de goede orde: dit betekent niet dat cloud-AI veiliger is. Het betekent dat de hostingvorm alleen niets zegt over de bescherming van uw data. De beschermingsgrens ligt niet bij "lokaal" of "cloud", maar bij de volledige verwerkingsketen die u aantoonbaar beheerst.

Welke lekken vonden onderzoekers precies in lokale LLM-systemen?

De onderzoekers achter "The Illusion of Local Privacy" beschrijven vier gescheiden lekken op dezelfde lokale machine. Prompts bleven achter in het werkgeheugen nadat een gesprek was afgelopen. Zogenoemde wrappers, de software rond het model, schreven prompts leesbaar naar schijf. Een autorisatiefout liet een gebruiker de opgeslagen gespreksstatus van een andere gebruiker herstellen, in alle tweehonderd gecontroleerde proeven. En gedeelde prompt-prefixcaching, een snelheidstruc die begin van prompts hergebruikt, veroorzaakte een meetbaar timingverschil waarmee een aanvaller kon afleiden wat een ander had ingevoerd.

• Runtimegeheugen: promptresten bleven in het geheugen staan na afloop.
• Persistente opslag: wrappers bewaarden prompts in platte, leesbare tekst.
• Tenantisolatie: een cross-tenant fout gaf toegang tot andermans gespreksstatus.
• Prefixcaching: een timingverschil verraadde de inhoud van gedeelde prompts.

De gemene deler: het model zelf draaide lokaal, maar de componenten eromheen vormden de werkelijke lekken. Daarom moet een beoordeling verder reiken dan de vraag "waar draait het model".

Biedt cloud-AI met confidential computing dan wél meer bescherming?

Cloudinference kan prompts en tussenresultaten blootstellen aan de dienstverlener, maar twee academische publicaties laten zien dat techniek die blootstelling tijdens de verwerking kan beperken. Dat is een mitigatie, geen automatische compliance of soevereiniteit.

In de studie "Your Inference Request Will Become a Black Box" "Your Inference Request Will Become a Black Box" splitsen de auteurs de inferentie tussen een door de cliënt geverifieerde confidential virtual machine, een afgeschermde rekenomgeving, en de publieke cloud. In hun specifieke evaluatie daalde de nauwkeurigheid waarmee tekst te reconstrueren viel van ruim 97,5 procent naar gemiddeld 1,34 procent, met identieke modeloutput. Een tweede studie, gepubliceerd via de Sociedade Brasileira de Computação, vergeleek reguliere en confidential virtual machines op Google Cloud met AMD SEV-SNP en Intel TDX en rapporteerde in de onderzochte benchmark geen systematische prestatieverslechtering.

Belangrijk: beide resultaten betreffen specifieke onderzoeksarchitecturen en benchmarks. Ze zijn geen universele garantie. Confidential computing beschermt data tijdens de verwerking via hardware-isolatie, geheugenversleuteling en attestatie, een cryptografisch bewijs dat u in de juiste, onveranderde omgeving draait. Maar metadata, sleutelbeheer, configuratie, subverwerkers en beschikbaarheid blijven aparte risico's die u zelf moet beheersen.

Wat betekent dit voor bestuurders, juristen en CISO's die AI-gebruik moeten verantwoorden?

Onze analyse: omdat de lekken in lokale systemen in het geheugen, de opslag en de servinglaag zaten en niet in het model, verschuift de verantwoordingslast naar de volledige keten. Daarom zouden CISO's hun AI-risicobeoordeling kunnen uitbreiden met runtimegeheugen, persistente opslag, authenticatie, tenantisolatie en prefixcaching, en die punten expliciet in een volgende beoordelingsronde opnemen. Onze analyse: omdat de cross-tenant fout in alle tweehonderd proeven reproduceerbaar was, laat dit in de onderzochte configuratie zien dat gedeelde infrastructuur zonder aantoonbaar harde isolatie een risico vormt. Daarom zouden juristen in leverancierscontracten een afdwingbare eis kunnen opnemen dat de leverancier aantoont dat gespreksstatus per gebruiker is afgeschermd, met concreet inspectiebewijs in plaats van een algemene verklaring. Onze analyse: confidential computing biedt alleen bescherming binnen een correct ingerichte trust boundary; "we draaien op een confidential VM" is zonder geverifieerde attestatie onvoldoende. Daarom zouden bestuurders kunnen eisen dat de attestatiestatus per verwerking wordt vastgelegd voordat gevoelige data de grens passeert. Een door Fortanix gepubliceerde survey onder driehonderd Amerikaanse AI-leiders vond dat 61 procent gevoelige data naar publieke cloud-AI stuurt, terwijl 93 procent zich zorgen maakt over blootstelling aan infrastructuurproviders. Onze analyse: dit wijst op een zichtbaar gat tussen praktijk en zorg. Compliance officers zouden die tweespalt kunnen vertalen naar een vastgelegde datagrens, zodat gebruik en beleid niet langer uiteenlopen.

Naar onze inschatting is het belangrijkste gevolg dat auditors runtimegeheugen, prefixcaching, tenantisolatie en attestatie als vaste beoordelingspunten zouden moeten overwegen voor zowel lokale als cloudsystemen. Wie dat niet doet, controleert de verkeerde grens en mist juist de plek waar prompts in de studie weglekten.

Hoe bepaal ik welke data de eigen server nooit mag verlaten?

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.

1. Maak onderscheid tussen modelbestanden, prompts, bijlagen, retrievalcontext, embeddings, outputs, logs, telemetrie, foutmeldingen, back-ups en supportdata; elk kan apart lekken.
2. Leg vast dat "lokaal" pas betekenis heeft als ook geheugen, opslag, wrappers, interfaces, updates, beheeraccounts en uitgaande telemetrie binnen uw grens vallen.
3. Verbied ruwe gevoelige prompts in niet-gecontroleerde cloudendpoints; laat alleen geminimaliseerde, gesegmenteerde of gecontroleerd gemaskeerde gegevens de grens passeren.
4. Sta externe verwerking pas toe wanneer doel, noodzaak, contract, locatie, bewaartermijn, verwijdering én attestatie zijn vastgelegd.
5. Controleer bij cloudinference niet alleen het model, maar ook sleutelbeheer, subverwerkers en metadata; onze vorige analyse legt uit hoe u aantoont welke subverwerkers en modelroutes uw AI-systeem feitelijk gebruikt.

Deze aanpak sluit aan op wat elders al bleek. Onze lezing: een AI-verbod houdt uploads van gevoelige data niet tegen, zodat alleen een technisch afgedwongen datagrens beschermt wat beleid op papier niet vasthoudt. Gecontroleerd maskeren vraagt daarnaast kennis van de regels en methoden voor pseudonimisering onder de AVG. Meer achtergrond bij dit onderwerp vindt u in ons themahub over AI-privacy en AVG. De rode draad blijft: hostinglocatie bepaalt niet wat beschermd is; de aantoonbare gegevensgrens doet dat wel.

Bronnen: Het artikel steunt op de arXiv-studie "The Illusion of Local Privacy", de ACL-publicatie over confidential inference, een SBSeg-evaluatie van confidential computing en een door Fortanix gepubliceerde survey.