# Zero-data-retention configureren bij LLM-API's

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 6 augustus 2026

Bij het integreren van grote taalmodellen (LLM's) in bedrijfsapplicaties is de omgang met gevoelige gegevens een kritieke factor. Wanneer organisaties gebruikmaken van externe API-aanbieders, worden prompts en de gegenereerde antwoorden over het publieke internet verzonden naar infrastructuur die beheerd wordt door derden. Om te voorkomen dat deze gegevens persistent worden opgeslagen, bieden veel API-providers de optie van Zero Data Retention (ZDR) aan. In dit artikel wordt geanalyseerd wat ZDR technisch inhoudt, hoe de verschillende opslaglagen zich tot elkaar verhouden, en hoe je deze configuraties implementeert en verifieert binnen je eigen software-architectuur.

## Wat zero data retention belooft (en wat niet)

De term Zero Data Retention suggereert dat er op geen enkel moment gegevens worden bewaard. In de praktijk is deze definitie genuanceerder en heeft deze specifiek betrekking op de persistering van de payload (de prompt en de completion) op fysieke opslagmedia na afronding van de API-transactie. Het is belangrijk om de technische grenzen van deze belofte te begrijpen om risico's te identificeren via een [AI-risicoanalyse (DPIA)](https://consultancy.llmnet.nl/ai-risicoanalyse-dpia).

Wanneer een verzoek naar een LLM-API wordt verzonden onder een ZDR-overeenkomst, gebeurt het volgende met de payload:

 
- In-memory verwerking: De prompt wordt ingelezen in het werkgeheugen (RAM of VRAM) van de verwerkende servers om de transformer-berekeningen uit te voeren. Gedurende de verwerkingstijd bevindt de tekst zich in actieve staat in het geheugen.
 
- Geen schijfopslag: Zodra de API-respons volledig is gegenereerd en teruggestuurd naar de client, wordt de payload uit het vluchtige geheugen gewist. Er vindt geen wegschrijving plaats naar database-systemen, transactionele logs of back-upmedia van de provider.
 
- Metadata-uitzondering: ZDR heeft vrijwel nooit betrekking op de metagegevens van het verzoek. Gegevens zoals het tijdstip van de aanroep, de gebruikte API-sleutel, het aantal verwerkte tokens, het IP-adres van de client en het specifieke modeltype worden nog steeds gelogd voor operationele doeleinden.

 Belangrijk: ZDR voorkomt dat data in rust (data at rest) wordt opgeslagen bij de provider na het verzoek, maar het beschermt de data niet tegen onderschepping tijdens transport (data in transit). Hiervoor blijven transportversleuteling (TLS) en netwerkbeveiliging de primaire mechanismen.

## Het onderscheid tussen de drie retentielagen

Bij het analyseren van het privacybeleid en de API-documentatie van LLM-providers lopen drie verschillende vormen van dataretentie vaak door elkaar. Voor een correcte configuratie moeten deze lagen strikt gescheiden worden beoordeeld:

 
 
 Retentielaag | 
 Doel van de opslag | 
 Typische bewaartermijn | 
 ZDR-status | 
 

 
 
 
 Modeltraining | 
 Verbeteren en trainen van toekomstige modelversies. | 
 Permanent (tenzij verwijderd) | 
 Standaard uitgeschakeld bij commerciële API's. | 
 

 
 Abuse-monitoring | 
 Detecteren van misbruik, illegale content of beleidsschendingen. | 
 Vaak 14 tot 30 dagen | 
 Moet expliciet worden uitgezet (ZDR opt-in). | 
 

 
 Debugging & Support | 
 Foutopsporing en ondersteuning bij incidenten door engineers. | 
 Enkele uren tot dagen | 
 Wordt bij ZDR volledig uitgeschakeld voor payload. | 
 

 

### 1. Gebruik van invoer voor modeltraining

Voor de meeste commerciële API-abonnementen (in tegenstelling tot gratis consumenteninterfaces) geldt dat invoerdata standaard niet wordt gebruikt om modellen te trainen. Dit is de minimale basislijn. Dit betekent echter niet dat de data niet wordt opgeslagen; het betekent enkel dat de data niet in de trainingspijplijn belandt.

### 2. Retentie voor abuse-monitoring

Dit is de meest voorkomende reden waarom data alsnog tijdelijk wordt opgeslagen. Providers bewaren prompts en completions om achteraf te kunnen controleren of er sprake was van misbruik (zoals het genereren van schadelijke code of desinformatie). ZDR is pas echt actief wanneer deze abuse-monitoring voor jouw API-sleutels of account is uitgeschakeld. Dit vereist vaak een specifieke goedkeuring of contractuele addendum.

### 3. Retentie voor debugging en support

Wanneer een API-aanroep faalt met een HTTP 5xx-fout, slaan systemen vaak de exacte payload op om ontwikkelaars in staat te stellen de fout te reproduceren. Onder een ZDR-configuratie moet deze vorm van logging voor de payload worden geblokkeerd. Foutlogs mogen in dat geval alleen niet-gevoelige metagegevens bevatten.

## Standaardinstellingen versus expliciete configuratie

De aanname dat een API-verbinding standaard veilig is, kan leiden tot datalekken. Standaardinstellingen verschillen sterk per aanbieder. Bovendien is er een belangrijk technisch onderscheid tussen instellingen op accountniveau en configuraties per specifiek API-verzoek.

Op account- of organisatieniveau kan een provider ZDR afdwingen voor alle API-sleutels die onder dat account vallen. Dit gebeurt vaak op basis van een goedgekeurd aanvraagformulier of een enterprise-contract. Het voordeel hiervan is dat individuele ontwikkelaars binnen de organisatie geen specifieke parameters hoeven mee te sturen om ZDR te activeren. De policy wordt centraal afgedwongen op de API-gateway van de provider.

Op verzoekniveau (per API-call) bieden sommige systemen parameters of HTTP-headers aan om data-opslag te onderdrukken. Dit geeft flexibiliteit wanneer slechts een deel van de applicatie met gevoelige gegevens werkt. Het risico is echter dat een programmeerfout of het weglaten van de parameter in een nieuwe microservice ertoe leidt dat data alsnog persistent wordt opgeslagen. Dit kan getoetst worden aan de hand van de [AVG-privacy-checklist](https://gids.llmnet.nl/avg-privacy-checklist) voor AI-systemen.

## Wat er typisch wel wordt bewaard: de impact op de DPIA

Bij het uitvoeren van een data protection impact assessment is het niet voldoende om te vermelden dat ZDR is geactiveerd. De metagegevens die buiten de ZDR-scope vallen, moeten nauwkeurig in kaart worden gebracht. Deze gegevens kunnen namelijk nog steeds persoonsgegevens bevatten of herleidbaar zijn tot individuen.

De volgende metagegevens worden doorgaans wel bewaard door API-providers:

 
- IP-adressen en routing-informatie: De netwerkoorsprong van het verzoek. Dit is relevant als de API rechtstreeks vanuit de client-applicatie (bijvoorbeeld een mobiele app) wordt aangeroepen in plaats van via een eigen backend.
 
- Tokenaantallen (input en output): Nodig voor de facturatie en volumeberekeningen. Hoewel de tokens zelf (de tekst) worden verwijderd, blijft het getal (bijvoorbeeld prompt_tokens: 142, completion_tokens: 85) bewaard.
 
- Rate-limit-tellers en timestamps: Om misbruik en overbelasting (DDoS) tegen te gaan, houdt de provider bij hoeveel verzoeken een specifieke API-sleutel per minuut of dag doet.
 
- Facturatieregels: Gegevens over het verbruik gekoppeld aan de accountidentificatie voor administratieve doeleinden.

Indien metagegevens worden bewaard, moet in de DPIA worden vastgelegd hoe lang deze bewaard blijven en hoe de provider deze gegevens beschermt tegen ongeautoriseerde toegang.

## Gevolgen voor stateful functies en geavanceerde API-features

ZDR is technisch relatief eenvoudig bij stateless, eenmalige tekstgeneraties. Zodra je echter gebruikmaakt van complexere API-functies die afhankelijk zijn van status (state), ontstaan er conflicten met de zero-data-retentiebelofte. De onderstaande functies vereisen extra aandacht:

### Server-side conversatiestatus (Assistant-API's)

Sommige providers bieden Assistant-API's aan waarbij de conversatiegeschiedenis (de 'threads') op de servers van de provider wordt opgeslagen. Dit stelt ontwikkelaars in staat om de context niet bij elke call opnieuw mee te sturen. Bij een actieve ZDR-policy zijn deze stateless endpoints vaak onbruikbaar, of moet de status volledig aan de clientzijde (in je eigen database) worden beheerd.

### Bestandsuploads (RAG en fine-tuning)

Functies waarbij bestanden (zoals PDF's of JSONL-trainingsbestanden) naar de provider worden geüpload voor indexering of fine-tuning, zijn inherent in strijd met ZDR. Deze bestanden moeten persistent opgeslagen worden om door het model gelezen te kunnen worden tijdens runtime. ZDR is in deze scenario's vaak enkel van toepassing op de uiteindelijke query, niet op de geüploade referentiebestanden.

### Prompt-caching

Om kosten en latentie te verminderen, bieden veel API's prompt-caching aan. Hierbij wordt de systeemprompt of een groot document tijdelijk gecached op de servers van de provider, zodat opeenvolgende verzoeken sneller verwerkt worden. Hoewel deze cache vaak vluchtig is (en na enkele uren verloopt), betekent het wel dat de prompt gedurende die tijd opgeslagen blijft. Dit moet expliciet worden afgewogen tegen de ZDR-vereisten.

### Asynchrone batch-verwerking

Bij batch-API's stuur je een groot aantal verzoeken in één keer op, waarna de provider deze binnen 24 uur verwerkt. De invoer en de gegenereerde resultaten moeten gedurende dit venster op de servers van de provider worden opgeslagen totdat de client de resultaten ophaalt. ZDR is hierbij vaak pas actief nadat de resultaten succesvol zijn gedownload of na het verstrijken van een vaste bewaartermijn (bijvoorbeeld 7 dagen).

## ZDR afdwingen in je eigen gateway

In plaats van blind te vertrouwen op de configuratie van de externe provider, is het architectonisch veiliger om een filter- en controlelaag in te richten binnen je eigen infrastructuur. Dit is met name relevant wanneer je besluit om een [LLM-gateway zelf te hosten](https://api.llmnet.nl/llm-gateway-zelf-hosten). De gateway fungeert als een proxy tussen de interne applicaties en de externe API's.

Binnen deze gateway kunnen de volgende mechanismen worden geïmplementeerd om gegevensbescherming af te dwingen:

// Conceptuele weergave van payload-sanitatie in een eigen gateway
function preprocessRequest(request) {
 // 1. Normaliseer het verzoek en verwijder niet-toegestane velden
 const sanitizedBody = filterFields(request.body, ALLOW_LIST);
 
 // 2. Strip potentiële persoonsgegevens met regex of PII-detectie
 sanitizedBody.prompt = stripPII(sanitizedBody.prompt);
 
 // 3. Dwing ZDR headers of parameters af
 sanitizedBody.extra_headers = {
 ...sanitizedBody.extra_headers,
 "X-Disable-Abuse-Monitoring": "true"
 };
 
 return sanitizedBody;
}

De gateway moet werken op basis van een allow-list van API-parameters in plaats van een deny-list. Dit voorkomt dat nieuwe parameters die de provider introduceert (en die mogelijk dataopslag activeren) per ongeluk worden doorgelaten naar de externe API. Tevens kan de gateway uitgaande verzoeken analyseren op gevoelige patronen (zoals burgerservicenummers of creditcardgegevens) en deze pseudonimiseren voordat ze de infrastructuur verlaten.

## Het risico van eigen logging

Een veelvoorkomende valkuil is dat een organisatie veel moeite doet om ZDR bij de LLM-provider te configureren, om vervolgens de prompts en completions onversleuteld op te slaan in de eigen applicatielogs, tracing-systemen of APM-tools (Application Performance Monitoring). Dit verplaatst het datalek-risico enkel van de provider naar de eigen infrastructuur.

Om dit te voorkomen, moeten logging- en observability-systemen zo worden ingesteld dat payloads systematisch worden uitgesloten van opslag, zoals beschreven in de gids over [observability en logging](https://api.llmnet.nl/observability-en-logging). Dit vereist concrete maatregelen:

 
- Scheiding van metadata en payload: Log wel de statuscode, de responstijd en het aantal tokens, maar nooit de inhoud van de messages-array of de completion-tekst.
 
- Maskeren in foutrapportages: Bij uitzonderingen (exceptions) in de applicatie kan het framework geneigd zijn de volledige HTTP-request-body op te nemen in de stacktrace. Zorg ervoor dat de HTTP-client zo is geconfigureerd dat deze gevoelige headers en body-inhoud maskeert in foutlogs.
 
- Toegangsbeheer op debug-logs: Als debug-logging tijdelijk moet worden ingeschakeld in productie, zorg dan voor automatische retentielimieten (bijvoorbeeld maximaal 24 uur) en strikte rolgebaseerde toegang (RBAC) tot deze logs.

## Regio- en verwerkingslocatie versus zero data retention

Het is een veelvoorkomend misverstand dat ZDR en dataresidentie (data residency) synoniemen zijn. ZDR garandeert enkel dat gegevens niet persistent worden opgeslagen. Het zegt niets over waar de gegevens in-memory worden verwerkt.

Indien een organisatie gebonden is aan Europese wetgeving, is het vaak vereist dat de verwerking van persoonsgegevens binnen de Europese Economische Ruimte (EER) plaatsvindt. Een API-aanroep naar een provider met ZDR geactiveerd kan nog steeds gerouteerd worden naar servers in de Verenigde Staten voor de in-memory berekeningen. Om compliantly te opereren, moeten beide eigenschappen onafhankelijk van elkaar worden geconfigureerd:

 
- Dataresidentie: Configureer de API-client om verbinding te maken met specifieke regionale endpoints (bijvoorbeeld eu-west-1.api.provider.com) om te garanderen dat de data de geografische grens niet overschrijdt tijdens transport en tijdelijke verwerking.
 
- ZDR: Zorg ervoor dat op die specifieke regionale endpoints de ZDR-instellingen actief zijn om persistente opslag na verwerking te voorkomen.

## Verificatie en contractuele vastlegging

Een technische configuratie is juridisch en operationeel waardeloos zonder de juiste contractuele basis. De technische ZDR-instelling moet direct gekoppeld zijn aan de juridische afspraken in de [AI-contracten en SLA](https://consultancy.llmnet.nl/ai-contracten-en-sla) van de provider.

Let bij het beoordelen van contracten en verwerkersovereenkomsten (DPA's) op de volgende aspecten:

 
- Recht op audits: Biedt de provider de mogelijkheid voor externe audits (zoals SOC 2 Type II rapportages) die specifiek de werking van de ZDR-pijplijnen valideren?
 
- Wijzigingsbeheer: Hoe informeert de provider je over wijzigingen in de API-voorwaarden of standaardinstellingen? API-versiewisselingen (bijvoorbeeld van v1 naar v2) kunnen er soms toe leiden dat eerdere opt-out-instellingen voor abuse-monitoring komen te vervallen of opnieuw moeten worden aangevraagd.
 
- Subverwerkers: Controleer of de provider gebruikmaakt van subverwerkers voor de verwerking van de API-verzoeken, en of de ZDR-verplichtingen ook aan deze partijen worden opgelegd.

## Praktische controlelijst voor ingebruikname

Voordat er daadwerkelijk productiedata door een LLM-API-integratie stroomt, dient de technische implementatie te worden geverifieerd aan de hand van deze controlelijst:

 
- [ ] Contractuele bevestiging: Is de verwerkersovereenkomst getekend en is de ZDR-clausule (inclusief uitsluiting van modeltraining en abuse-monitoring) formeel bevestigd voor de betreffende account-ID's?
 
- [ ] Endpoint-verificatie: Wijzen alle API-aanroepen in de productiecode naar de juiste regionale en ZDR-specifieke endpoints?
 
- [ ] Header- en parametercontrole: Indien ZDR op verzoekniveau wordt geconfigureerd: is er een unit-test of integratietest die controleert of de vereiste parameters (zoals specifieke headers of flags) daadwerkelijk in elke uitgaande HTTP-request aanwezig zijn?
 
- [ ] Functiebeperkingen: Zijn stateful functies (zoals assistants of server-side threads) uitgeschakeld of gemigreerd naar client-side alternatieven?
 
- [ ] Gateway-beveiliging: Filtert de eigen API-gateway onbekende of onveilige parameters en dwingt deze een allow-list af?
 
- [ ] Lokale log-sanitatie: Is handmatig geverifieerd dat er geen prompt- of completiondata terechtkomt in de eigen applicatielogs, foutmeldingssystemen en APM-dashboards? Dit is essentieel voor de naleving van je interne beleid omtrent [audit-logging en compliance](https://api.llmnet.nl/audit-logging-en-compliance).
 
- [ ] Periodieke controlecyclus: Is er een proces ingericht om bij elke grote update van de API-client of de provider-API de retentie-instellingen opnieuw te valideren?

## Lees ook

 
- [Audit-logging en compliance bij API-integraties](https://api.llmnet.nl/audit-logging-en-compliance)
 
- [Observability en logging in complexe LLM-omgevingen](https://api.llmnet.nl/observability-en-logging)
 
- [Stappenplan: Een LLM-gateway zelf hosten](https://api.llmnet.nl/llm-gateway-zelf-hosten)
 
- [AI-risicoanalyse en het uitvoeren van een DPIA](https://consultancy.llmnet.nl/ai-risicoanalyse-dpia)
 
- [AI-contracten en SLA: Waar je op moet letten](https://consultancy.llmnet.nl/ai-contracten-en-sla)
 
- [De AVG-privacy-checklist voor AI-toepassingen](https://gids.llmnet.nl/avg-privacy-checklist)

llmnet.nl - LLM-aggregatie en API-integratie