Deel:𝕏LinkedInRedditFacebookKopieer link

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).

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

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 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:

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. 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. Dit vereist concrete maatregelen:

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:

  1. 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.
  2. 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 van de provider.

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

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:

Lees ook