Privacyniveau versus leveranciersbelofte: welke data mag naar een cloud-LLM?

De privacypagina van een leverancier beschrijft de leverancier; een privacyniveau beschrijft jouw data en bepaalt welke modelhosts die mogen ontvangen. Die pagina is bewijsmateriaal voor je beoordeling. Het niveau is de grens die je routebeleid afdwingt voordat er een model wordt gekozen.

“Wij werken met een goedgekeurde leverancier” laat het eigenlijke besluit open. Mag deze host deze input verwerken, voor dit doel, onder deze overeenkomst en in deze jurisdictie? Die vraag wil je beantwoord hebben voordat de eerste prompt de deur uitgaat.

Het model-portfolio geeft dat besluit een vaste vorm. Hoofdstuk 8 legt vier privacyniveaus vast, in het boek privacy-tiers genoemd, met de regels die ze afdwingen, en zegt ronduit dat het gepubliceerde privacybeleid van een aanbieder geen goedkeuring van een route is. Hoofdstuk 3 maakt het privacyniveau een verplicht veld in het modelregister, je overzicht van alle modellen en hosts in gebruik, en laat dat veld vóór kosten of capaciteit controleren.

De niveaus zijn werkcategorieën, geen AVG-categorieën, en een niveau toekennen certificeert niets.

Welke bedrijfsdata mag ik onder de AVG veilig naar een cloud-LLM sturen?

Alleen data die onder de vastgelegde goedkeuring van die route valt: het juiste niveau, het goedgekeurde doel, de goedgekeurde jurisdictie. Deel eerst de input in en kijk daarna welke hosts nog in aanmerking komen. Kwaliteit of beschikbaarheid van een model vervangt geen toestemming die niemand heeft vastgelegd.

Het boek verdeelt data over vier niveaus:

Niveau	Wat hieronder valt	Toegestane hosts volgens het boek
T1: Publiek / open	Publiceerbaar materiaal zonder persoonsgegevens, bedrijfseigen inhoud, gereguleerde data of contractuele beperkingen.	Elke cloudhost, ook gedeelde inferentie en publieke API’s.
T2: Intern / algemeen	Gewone interne bedrijfsdata. Persoonsgegevens, gereguleerde data, stukken onder het verschoningsrecht, personeelsdata en zeer gevoelige commerciële data vallen erbuiten.	Cloudhosts met een standaard commerciële verwerkersovereenkomst, binnen de compliancegrens van je organisatie.
T3: Vertrouwelijk / beperkt	Persoonsgegevens, personeelsdata, financiële gegevens, gezondheidsgegevens, stukken onder het verschoningsrecht en beperkte commerciële inhoud.	Hosts die na vastgelegde juridische toetsing zijn vrijgegeven voor de datacategorie en jurisdictie: een cloudhost met de vereiste overeenkomsten en doorgiftemechanismen, of een geïsoleerde omgeving op eigen infrastructuur of in een afgeschermde private cloud (VPC). Geen gedeelde publieke inferentie.
T4: Air-gapped / soeverein	Data waarvoor eisen rond soevereiniteit, classificatie of klantcontracten elke externe verwerking verbieden.	Alleen op eigen infrastructuur, zonder netwerkverbinding met een externe API.

Wijzen twee criteria naar verschillende niveaus, dan kies je volgens het boek het hogere en leg je vast waarom. Twijfel naar beneden oplossen is een compliancerisico; twijfel naar boven oplossen kost geld. Geld haal je terug, een compliancefout niet.

Openbaar vindbaar is niet hetzelfde als T1. T1 sluit persoonsgegevens uit, en die vat het hoofdstuk ruim op: een e-mailadres telt mee, een naam in combinatie met een werkgever ook, en een gebruikers-ID die met redelijke middelen aan een persoon te koppelen is evengoed. De naam wegstrepen lost de vraag niet op.

Intern is niet hetzelfde als T2. Financiële prognoses, overnameonderhandelingen, concurrentie-informatie en juridische strategie zijn niet per se persoonsgegevens, maar het hoofdstuk behandelt ze als T3 omdat uitlekken de organisatie flink kan schaden. Toets dus ook commerciële gevoeligheid en contractuele beperkingen, niet alleen klantnamen.

Hoe deel je een taak in voordat je het model kiest?

Deel een soort werk in op wat het kan ontvangen, niet op wat het meestal ontvangt. Een documentassistent die vooral interne beleidsstukken verwerkt maar ook HR-bijlagen accepteert, is een T3-taak.

Zet alle input op een rij, niet alleen de getypte zin: het document of bericht, bijlagen, opgehaalde passages, de gespreksgeschiedenis, gebruikers-ID’s en de instellingen die de applicatie toevoegt.

Het niveau dat je voor het taaktype registreert, is een ondergrens, zodat geen enkel verzoek zich omlaag kan praten naar een goedkopere host. Wat er werkelijk binnenkomt, kan het niveau wel verhogen. De regel uit hoofdstuk 8:

Effectief niveau = het hoogste van het geregistreerde niveau van het taaktype, elk niveau dat de sessie of eerdere context al meedraagt, en elk niveau dat een controle op de inhoud van het verzoek aanwijst.

Controles mogen het niveau verhogen; niets brengt het onder de ondergrens, en onbekend valt nooit lager uit. Krijgt een T2-taak een geplakt HR-bestand binnen, dan wordt dat verzoek op T3 verwerkt. Een T3-taak blijft T3, ook als het document van vandaag onschuldig oogt. Valt de controle zelf uit, dan wordt het verzoek tegengehouden in plaats van doorgelaten.

Een geregistreerd niveau verlaag je niet met een schonere prompt: perk het databereik van het taaktype in, toon aan dat data van een hoger niveau de taak niet meer kan bereiken en leg de wijziging met datum vast.

Wat is modelroutering? laat zien welke velden een route verder meedraagt, van mandaat tot fallback. Frontier, workhorse of lokaal helpt je een modelklasse te kiezen binnen de hosts die de niveaucontrole doorstaan.

Welke vragen moet de AVG-toets beantwoorden?

Hoofdstuk 8 behandelt de AVG als toetsvragen die je juridisch adviseur of compliance-verantwoordelijke beantwoordt voordat het routebeleid wordt goedgekeurd. Dit is geen juridisch advies of volledige checklist; het doel is een vastgelegd besluit dat je routering kan afdwingen.

1. Kan de AVG op deze route van toepassing zijn? Je juridisch adviseur bevestigt de reikwijdte; jij legt het antwoord vast, met de kaders die voor het taaktype gelden en de jurisdictie.
2. Treedt de aanbieder op als verwerker, en onder welk instrument? Zo ja: welke verwerkersovereenkomst of gelijkwaardige contractuele regeling is nodig? Leg de status ervan vast, de datacategorieën en jurisdictie die ze dekt, en wanneer die status is gecontroleerd.
3. Gaat de verwerking over de grens? Dan kan een doorgiftemechanisme of een andere vastgelegde grondslag nodig zijn. Leid de toelaatbaarheid niet af uit de marketingpagina van een aanbieder.
4. Wat is er precies goedgekeurd? Leg de entiteit vast, het verwerkingsdoel, de datacategorie, de jurisdictie en de doorgiftebeoordeling. Toets opnieuw zodra aanbieder, regio, contract of regelgeving verandert.

In het register van het boek krijgt elke host zes governancevelden: status van de verwerkersovereenkomst, juridisch beoordelingsdossier, maximaal toegestaan niveau (het plafond van de host), jurisdictiebereik, air-gap-status en reviewdatum. Een getekende overeenkomst is het papierwerk dat de toetsing mogelijk maakt; zonder vastgelegde goedkeuring blijft het plafond waar het was.

Lees het plafond altijd samen met de goedkeuring erachter, want die noemt een doel, een datacategorie en een jurisdictie. Een host die is goedgekeurd voor het samenvatten van supporttickets, is daarmee nog niet goedgekeurd voor het analyseren van de prestaties van medewerkers. Koppel het goedkeuringsdossier aan de route.

Een uitgewerkt voorbeeld: één taak voor de klantenservice, twee cloudhosts

Dit voorbeeld is hypothetisch. Een softwarebedrijf wil elke week een overzicht van terugkerende thema’s in de klantenservice. De taak kan klantberichten, e-mailadressen, account-ID’s en gespreksgeschiedenis ontvangen en staat daarom op T3 in het register. Berichten van klanten met een contract dat externe verwerking verbiedt, blijven buiten de taak.

De prompt luidt: “Groepeer deze tickets per productprobleem. Laat klantnamen weg uit de samenvatting.”

Die instructie bepaalt wat er terugkomt. Ze haalt geen enkele naam of e-mailadres uit de input die de host ontvangt.

Er staan twee hosts in het register, met verzonnen goedkeuringen:

Host	Vastgelegde goedkeuring	Mag deze host de batch ontvangen?
A	Plafond T2, interne documentatie	Nee. De ondergrens van de taak (T3) ligt boven het plafond van A.
B	Plafond T3, analyse van supporttickets voor deze datacategorieën en deze jurisdictie	Ja, binnen die goedkeuring.

Ga ervan uit dat de contract- en doorgiftetoets voor B is afgerond. Geen van beide hosts is een bestaande aanbieder.

De regel geeft drie antwoorden. Een ticket met het e-mailadres van een klant gaat naar B. Een algemeen storingsbericht via dezelfde taak ook, want de ondergrens blijft T3. En ligt B eruit, dan mag geen van beide hosts de batch verwerken; dat A nog capaciteit over heeft, verandert daar niets aan.

Nu wil het bedrijf ook berichten meenemen van een klant met een contract dat elke externe verwerking verbiedt. Het kan die buiten deze taak houden, of de taak naar T4 tillen met een route op eigen infrastructuur of een vastgelegde geblokkeerde uitkomst. Op T3 blijven omdat de meeste klanten soepelere contracten hebben, kan niet.

Het resultaat is een routeoverzicht dat iemand anders kan controleren:

Taak: wekelijkse samenvatting van klantenservicethema's
Toegestane input: klantberichten en de bijbehorende ticketcontext
Uitgesloten input: materiaal dat niet extern verwerkt mag worden
Geregistreerd niveau: T3
Primaire host: B, binnen de vastgelegde goedkeuring voor supportanalyse
Tweede vrijgegeven host: geen (alles hangt aan B; bewust vastgelegd)
Als B uitvalt: vasthouden in een duurzame wachtrij; opnieuw proberen; maximale wachttijd bewaken
Na de wachttijd: gestructureerde foutmelding; benoemde eigenaar waarschuwen
Log: niveau, taaktype, beoogde host, reden van blokkade, afhandeling

Het overzicht is een illustratie: interval, maximale wachttijd, goedkeuringsdossier en eigenaar moeten nog worden ingevuld.

Wat gebeurt er als geen vrijgegeven host beschikbaar is?

Onder druk ligt het antwoord voor de hand: de host die wél draait. Hoofdstuk 8 sluit dat uit: geen beschikbaarheidsargument gaat boven een niveaugrens. Er blijven drie ontworpen reacties over:

• Wachtrij en opnieuw proberen. Houd het verzoek vast in een duurzame wachtrij, geen buffer in het werkgeheugen, met een instelbaar interval voor nieuwe pogingen en een maximale wachttijd. Daarna verloopt het verzoek met een foutmelding. Dit past bij batchwerk en bij werk dat bijna realtime moet zijn.
• Degraderen naar een beperkte functie. Geef een beperkt antwoord waarvoor de gevoelige input niet nodig is, zoals een gestructureerde bevestiging dat het document is ontvangen en wordt verwerkt zodra er weer capaciteit is. Die gedegradeerde modus op productniveau vraagt productontwerp, niet alleen routering.
• Afbreken met een gestructureerde foutmelding. Geef een foutmelding terug die zegt dat het conforme pad niet beschikbaar is, met genoeg detail voor het aanroepende systeem om een zinvolle melding te tonen of handmatig te escaleren. Het routeringslog legt een geblokkeerde route vast, nooit een succes.

De latentieklasse van de taak beslist: een realtime taak met een gebruiker aan de andere kant kan niet minutenlang wachten, een batchtaak wel uren. Bepaal vóór de ingebruikname wie een waarschuwing krijgt als een beperkte route blokkeert. Een geblokkeerd verzoek zonder logregel is een gat in je compliance.

De grens geldt voor elk pad waarlangs de data van het verzoek gaat: de primaire route, de fallback-keten en elke gespiegelde kopie, schaduwkopie of evaluatiekopie van hetzelfde verzoek. Wie een vervangend model test op kopieën van echte verzoeken, krijgt daarvoor geen vrijstelling.

Een handmatige afwijking kan een verzoek naar een ander model verplaatsen dat het effectieve niveau al toestaat, maar nooit over de niveaugrens heen. Een verboden verstrekking loggen legt haar vast; toegestaan wordt ze daar niet door. Heeft het bedrijf de data echt nodig op een plek die het niveau verbiedt, dan vraagt dat om herindeling via je complianceproces.

Wat moet het routeringslog laten zien?

De audittabel in hoofdstuk 8 noemt de velden: tijdstip van het verzoek, taaktype, toegekend privacyniveau, gekozen modelhost, toegepaste routeringsregel, de markering voor een handmatige afwijking, wie die afwijking goedkeurde, de uitkomst (gelukt, fallback of geblokkeerd) en de latentie. Een vingerafdruk van de input is optioneel in het operationele log en altijd alleen een hash, nooit de ruwe inhoud. Voor een geblokkeerde route voegt het ontwerpsjabloon uit het hoofdstuk de beoogde host, de reden van de blokkade en de afhandeling toe.

Het hoofdstuk scheidt een gedetailleerd operationeel log van een compliancelog op hoofdlijnen en noemt geen universele bewaartermijn: je juridisch adviseur of compliance-verantwoordelijke bepaalt elke termijn op basis van doel, toepasselijk recht en contract.

Het artikel over de agent-audittrail beschrijft de bredere reconstructieoefening. Voor privacyniveaus is de toets smaller: kan een collega alleen op basis van de vastleggingen laten zien welke host de data kreeg en waarom die host daarvoor was vrijgegeven?

Eén grens blijft: de routeringsvoorwaarde bestuurt de systemen die je zelf beheert, niet het browsertabblad dat een medewerker op een privéaccount opent. Daarvoor gebruikt het boek een lijst met goedgekeurde modellen in termen van niveaus: welke tools, voor welke categorieën data, via welke accounts.

Probeer dit vandaag

Pak de laatste vijf prompts die je team naar een extern model heeft gestuurd. Beoordeel ze in de omgeving waar die data al goedgekeurd is opgeslagen, niet door ze in een ander extern model te plakken.

1. Reconstrueer de volledige input. Neem bijlagen, opgehaalde context en gespreksgeschiedenis mee. Noteer een verwijzing, geen kopie van gevoelige tekst.
2. Ken het niveau uit het boek toe. Toets op persoonsgegevens, commerciële gevoeligheid en contractuele beperkingen. Vergelijk de uitkomst met het geregistreerde niveau van de taak en met wat de sessie toevoegde, en neem het hoogste. Ontbreekt een indeling, dan is dat al een bevinding.
3. Benoem de werkelijke bestemming. Host, dienst en account, plus elke fallback- of evaluatiekopie. Kunnen je vastleggingen niet zeggen waar de data heen ging, schrijf dat dan op.
4. Zoek de goedkeuring die gold. Vergelijk het effectieve niveau met het plafond van de host en toets daarna doel, datacategorie en jurisdictie. Ontbrekend bewijs telt als gat, niet als akkoord. Een latere goedkeuring laat niet zien wat er mocht op het moment van verzenden.
5. Kies de eerste herstelactie. Elke prompt waarvan het niveau hoger ligt dan waarvoor de route is vrijgegeven, is je eerste herstelpunt. Voorkom herhaling, wijs een eigenaar aan, leg de toegestane route of de geblokkeerde uitkomst vast en leg de regel voor aan je juridisch adviseur of compliance-verantwoordelijke.

Houd per prompt één regel bij: verwijzing, effectief niveau, bestemming, goedkeuring, klopt of gat, volgende actie, eigenaar.

Vijf kloppende regels zeggen iets over vijf prompts, niet over het systeem. Kloppen ze alle vijf, doe dan de niveau-oefening uit het hoofdstuk voor je gevoeligste taaktype: noem alleen op basis van het register het niveau, de hosts die voor dat niveau zijn vrijgegeven en wat er gebeurt als geen van die hosts beschikbaar is. Een gat in een van die antwoorden is een bevinding die je kunt herstellen voordat een auditor haar aanwijst.

Citeer deze pagina:Privacyniveau versus leveranciersbelofte: welke data mag naar een cloud-LLM?Len P. van der Hof. https://lenvanderhof.com/nl/blog/privacyniveau-versus-beloofde-privacy/ · Gepubliceerd 6 november 2026.