Hoe toepasbaar is het Support Pool of Experts rapport over privacyrisico’s bij LLMs?

Artificial Intelligence - Blog / 8 May 2025

Sinds de opkomst van ChatGPT zijn generatieve AI-toepassingen niet meer weg te denken uit het dagelijks werk van miljoenen mensen. Of het nu gaat om chatbots, schrijfhulptools, of samenvattende functies voor meetings en e-mails: AI-systemen gebaseerd op Large Language Models (LLMs) spelen een steeds grotere rol. Maar hoe zit het met de privacyrisico's? De Support Pool of Experts van de European Data Protection Board (EDPB) heeft hier onlangs een uitgebreid rapport van ruim 100 pagina’s over geschreven. Het doel van dit rapport is om gebruikers en ontwikkelaars van LLMs praktische handvatten te geven om de bijkomende privacyrisico’s te beheersen.

In deze blog onderzoeken wij de vraag of dit rapport ook écht praktisch te gebruiken is voor organisaties met als doel om privacyrisico’s op tijd op te sporen en te mitigeren bij het implementeren van AI-systemen.

Hoe werken LLMs eigenlijk?

Om de privacyrisico’s goed te begrijpen, is enige basiskennis van LLMs cruciaal. Het rapport begint dan ook met een uitleg over de onderliggende technologie: de ‘transformer-architectuur’. De meeste LLMs die vandaag de dag op grote schaal worden gebruikt zijn gebaseerd op deze ‘transformer-architectuur’. Het rapport legt op een duidelijke manier uit hoe dit werkt, ook voor de minder technologisch onderlegde lezer.

LLMs worden in verschillende stappen ontwikkeld. Eerst wordt het model gevoed met grote hoeveelheden tekst, bijvoorbeeld van het internet en uit boeken. Deze tekst wordt vervolgens opgeschoond en opgeknipt in kleine stukjes die we 'tokens' noemen. Deze tokens kunnen bestaan uit woorden, maar bijvoorbeeld ook uit delen van woorden of leestekens. Deze tokens worden met behulp van een speciale techniek verwerkt (de hiervoor genoemde 'transformer-architectuur'). Deze techniek stelt het model in staat om te begrijpen hoe woorden met elkaar samenhangen in een zin. Het model kijkt hierbij naar de positie van woorden en kent hier een bepaalde waarde aan toe. Door gebruik te maken van de informatie over de relatie tussen de woorden onderling ('attention mechanisms'), kan het LLM de context rondom de tokens interpreteren en bijvoorbeeld gaan voorspellen wat het volgende woord zou moeten zijn.

Na het trainen van het model komt men in een fase van continue verbetering, waarbij gebruik wordt gemaakt van onder andere RAG-processen waarbij externe bronnen worden gebruikt en feedbackloops waarbij gebruikersfeedback wordt gebruikt om het model te verbeteren.

Het rapport gaat vervolgens in op de ‘lifecycle’ van een LLM en verbindt hier enkele belangrijke privacyrisico’s aan:

Dataverzameling: omdat LLMs vaak worden getraind met grote hoeveelheden aan data bestaat er een kans dat deze data persoonsgegevens bevatten en zo in het model terechtkomen.
Output (inference): als het LLM is getraind met persoonsgegevens dan bestaat de kans dat deze persoonsgegevens tijdens de output-fase worden gegenereerd en daarmee gelekt.
RAG-processen: RAG-processen zijn processen waarbij de nauwkeurigheid en betrouwbaarheid van het LLM wordt verbeterd door relevante informatie uit externe bronnen toe te voegen. Wanneer deze externe bronnen persoonsgegevens bevatten ontstaat er een privacyrisico.
Feedbackloops: tijdens de feedbackloops gebruikt het LLM feedback uit verschillende bronnen, zoals menselijke input of andere AI-systemen, om zichzelf aan te passen naar nieuwe contexten of fouten te verbeteren. Hierbij loop je het risico dat gebruikersdata kan worden opgeslagen in het AI-systeem zonder de juiste veiligheidswaarborgen.

Na deze uitleg over de werking van LLMs biedt het rapport een gestructureerde aanpak om risico’s te identificeren, beoordelen en beheersen. Deze aanpak zullen wij hieronder bespreken.

Begrijp je model en dataflow

Het rapport neemt als uitgangspunt dat het begrijpen van de AI-lifecycle van je AI-systeem en de datastroom hier doorheen essentieel is voor een goede analyse en aanpak van privacyrisico’s. Hoe de datastroom precies loopt hangt af van in welke fase van de AI-lifecycle je zit. Elke fase in de lifecycle omvat namelijk mogelijk unieke privacyrisico’s. Het is dan ook van belang om per fase de risico’s te analyseren en aan te pakken met gerichte mitigatiestrategieën. Het rapport sluit aan bij de ISO/IEC 22989 en ISO/IEC 5338 standaarden wat betreft de AI-lifecycle-fasen, maar erkent ook dat dit binnen organisaties kan verschillen.

In het kader van het bepalen van de AI-lifecycle en datastroom onderscheidt het rapport vier belangrijke LLM-service-modellen:

LLM-as-a-Service: een extern AI-systeem dat gebruikt wordt via een API, zoals ChatGPT.
Off-the-shelf LLM: klant-en-klare modellen die worden afgenomen en kunnen worden aangepast door de afnemer
Zelfontwikkelde LLM: intern ontwikkelde modellen die op een eigen infrastructuur worden gehost
Agentic AI: een AI-systeem dat autonoom doelen kan stellen en acties kan ondernemen om die doelen te bereiken, vergelijkbaar met een digitale agent met eigen initiatief.

Bij het toepassen van het rapport op je eigen use case moet je je hier dus eerst afvragen welk LLM-service-model je wil gaan gebruiken. Veelal zal dit gaan om een LLM-as-a-Service. Vervolgens kan je aan de hand van het rapport nagaan hoe de dataflow door dat systeem verloopt en per fase van de AI-lifecycle analyseren welke privacyrisico’s hierbij kunnen opduiken.

Voor elk model wordt de bijbehorende dataflow en risicoanalyse beschreven. Bij LLM-as-a-Service ligt het risico vooral bij de gebruikersinput. Denk hierbij aan een medewerker die ChatGPT gebruikt en persoonsgegevens en andere gevoelige informatie in zijn of haar prompts verwerkt. Zelf ontwikkelde modellen lopen juist risico wanneer er niet zorgvuldig wordt om gegaan met de data waarmee het model wordt getraind. De boodschap: begrijp je model, weet waar je data naartoe gaat en implementeer passende beveiligingsmaatregelen.

Het fijne aan dit rapport is dat het per LLM-service-model een duidelijk overzicht geeft van de risico’s per fase en hoe deze gemitigeerd kunnen worden. In het voorbeeld van een LLM-as-a-Service wordt bijvoorbeeld als privacyrisico genoemd dat gebruikers (onbewust) gevoelige data of persoonsgegevens kunnen invoeren. De mitigerende maatregel die hierbij wordt genoemd is het implementeren van duidelijke gebruikersrichtlijnen en restricties op wat kan worden ingevoerd in het model, door bijvoorbeeld het toepassen van filters of waarschuwingen.

Risico’s identificeren: waar let je op?

In hoofdstuk 4 introduceert het rapport een framework om risico’s te identificeren aan de hand van zogenaamde risicofactoren, zoals:

Gebruik van gevoelige data
Verwerking op grote schaal
Lage datakwaliteit
Onvoldoende beveiliging

Deze risicofactoren zijn gebaseerd op analyses van onder andere de AVG en het Europese Verdrag voor de Rechten van de Mens. Naast de risicofactoren worden er andere criteria genoemd die men in overweging moet nemen bij het identificeren van risico’s. Zo worden er termen uit de AI Act meegenomen zoals hazard, hazard exposure, threats en vulnerabilities om het risicoprofiel van je systeem beter te begrijpen. Vervolgens wordt het belang van intended purpose benadrukt omdat risico’s vaak ontstaan wanneer een AI-systeem wordt gebruikt in een andere context dan waarvoor het bedoeld was. Tot slot wordt er ook in gegaan op het belang van ‘threat modeling’, waarbij je aan de hand van specifieke AI-dreigingen kwetsbaarheden proactief opspoort en het belang van het verzamelen en monitoren van data en bewijs.

Hoewel dit hoofdstuk minder praktisch leest dan voorgaande hoofdstukken, wordt het hoofdstuk afgesloten met overzichtelijke tabel, wat als startpunt kan worden genomen bij het toepassen van bovenstaande punten. Op deze manier is het praktisch toepasbaar op je eigen use case en kan je op een overzichtelijke manier de privacyrisico’s van jouw AI-systeem identificeren en analyseren. Zo wordt er bijvoorbeeld besproken wat de potentiële impact van het risico onder de AVG is en op welke LLM-service-modellen het van toepassing is. Als we weer als voorbeeld een LLM-as-a-Service nemen, is heel makkelijk in het overzicht te zien dat er voor dit service-model een risico kan bestaan dat de aanbieder van het AI-systeem onterecht trainingsdata heeft geclassificeerd als anoniem. Dit kan onder andere leiden tot een schending van het principe van doelbinding uit de AVG.

Van risico-identificatie naar evaluatie

Na identificatie volgt de evaluatie: hoe waarschijnlijk is het risico, hoe groot is de mogelijke schade en moeten de risico’s worden aangepakt om ervoor te zorgen dat persoonsgegevens worden beschermd? Hierbij wordt uitgegaan van de formule:

Risico = Kans x Ernst

Het rapport stelt dan ook dat het essentieel is om zowel de kans als de ernst van de geïdentificeerde risico’s in kaart te brengen in dit stadium. De richtlijn laat ruimte voor een eigen methodologie, maar sluit aan bij bekende standaarden zoals ISO 31000 en 31010. Ook maakt het rapport gebruik van twee verschillende modellen voor kans- en impactberekening:

FRASP: Framework for Assessing the Severity & Probability of Fundamental Rights Interferences in AI Systems. Dit framework geeft criteria om de kans en ernst van inbreuken op fundamentele rechten door AI-systemen te beoordelen. Sommige van deze criteria focussen op systeemniveau, terwijl anderen context-specifiek zijn.
AEPD: Risk Management and Impact Assessment in Processing of Personal Data. Dit framework wordt gebruikt om de ernst van de risico’s in kaart te brengen.

Voor beide frameworks wordt er geadviseerd om de scores uit de frameworks te aggregeren en vervolgens te mappen. Bij de berekening van de ernst moet wel in het oog worden gehouden dat criteria 1-5, 7 en 8 als ‘stoppers’ gelden, wat betekent dat de eindscore altijd overeenkomt met de hoogste score van (één van) deze criteria. Dit is zo om kritieke risico’s te prioriteren.

Ook wordt voor zowel de kans op risico’s als de ernst van risico’s een duidelijk overzicht gegeven in een tabel waarbij per criteria uit de frameworks (FRASP voor kans en AEPD voor ernst) worden gecombineerd met de bijgaande kans- dan wel ernstniveau’s. Uiteindelijk worden de risico’s geclassificeerd waarbij de combinatie van het kansniveau en ernstniveau in een matrix tot een risico-classificatie komt variërend van very high tot low.

Na het classificeren van de risico’s wordt aangegeven dat risicobeheersing op vier manieren kan plaatsvinden:

Mitigeren
Overdragen
Ontwijken
Accepteren

Het rapport geeft een duidelijk overzicht met voorbeelden van mitigerende maatregelen, waardoor het weer praktisch in te zetten is en je een goede houvast geeft bij de toepassing van de voorgaande theorie. Als we kijken naar ons voorbeeld van de LLM-as-a-Service waarbij het risico werd geïdentificeerd dat de aanbieder trainingsdata onterecht kan classificeren als anoniem, kan je in het rapport meteen vijf voorgestelde mitigerende maatregelen zien. Het rapport kan zo praktisch worden toegepast en dienen als inspiratie bij het mitigeren van jouw vastgestelde risico’s.

Review & monitor

Nadat de risico’s in kaart zijn gebracht, beoordeeld en gemitigeerd ben je nog niet klaar. Het rapport adviseert continue evaluatie en een review van het risico-managementproces. Deze review kan je helpen na te gaan of:

De geplande risicocontroles op effectieve wijze zijn geïmplementeerd
Opkomende risico’s zijn geïdentificeerd en gemitigeerd
Het risicomanagementplan in lijn is met de projectdoelen en reguleringen

Ook wordt aangegeven dat het belangrijk is dat organisaties een dynamisch risicoregister bijhouden, waarin eigenaarschap, periodieke updates en documentatie samenkomen. Op deze manier hou je een overzicht van de verantwoordelijkheden en de status van de risico’s.

Wat betreft de continue controle en evaluatie van risico’s benoemt het rapport verschillende technieken die je kunt gebruiken, zodat je wederom een praktisch uitgangspunt hebt voor de toepassing van de theorie op je eigen use case.

Is deze richtlijn praktisch toepasbaar?

Volgens de auteur van het rapport zelf is het geen allesomvattend document, maar juist bedoeld als een praktische gids. Dit blijkt uit de concrete handvatten die het rapport bij alle verschillende hoofdstukken geeft. Door heldere uitleg, visuele schema’s en tabellen is het een nuttig startpunt voor organisaties die met LLMs aan de slag willen. Het rapport sluit af met de toepassing van de theorie op drie verschillende use cases, waardoor je als lezer een goed beeld krijgt hoe de theorie in de praktijk kan worden toegepast. Enige noot is dat je als lezer wel enig technisch begrip en kennis van LLMs en hoe zij werken nodig hebt, maar dit wordt grotendeels uitgelegd in het begin van het rapport.

Conclusie: privacy by design is geen luxe, maar noodzaak

Het rapport maakt één ding duidelijk: privacyrisico's en de oplossingen daarvoor moeten vanaf het allereerste moment centraal staan in elk AI-project. Door de AI-lifecycle te koppelen aan de manier waarop data door jouw beoogde AI-systeem gaat, kun je gericht maatregelen treffen om risico’s te beperken. Het rapport is omvangrijk, maar met de juiste kennis van het AI-systeem wat je wil gaan inzetten geeft het rapport een duidelijk overzicht en uitgangspunten om de privacyrisico’s in kaart te brengen.