Retentiebeleid bij AI-leveranciers beoordelen
Bij het selecteren en integreren van softwareoplossingen vormt het gegevensbeheer altijd een cruciaal onderdeel van de risicoafweging. Bij het gebruik van Large Language Models (LLM's) en andere vormen van kunstmatige intelligentie krijgt data-retentie echter een fundamenteel andere lading. De invoer die een organisatie naar een externe AI-dienst stuurt, bevat vaak ongestructureerde, hooggevoelige informatie: van interne documentatie en intellectueel eigendom tot persoonsgegevens en bedrijfsgeheimen.
Iedere API-aanroep of interactie met een AI-model verstuurt deze data direct naar de infrastructuur van de leverancier. Waar traditionele SaaS-toepassingen gegevens opslaan in voorspelbare databestanden en tabellen, verwerken AI-systemen tekstuele en visuele invoer in vluchtige contextvensters, om deze vervolgens via diverse tussenlagen, logging-mechanismen en opslagmedia te verwerken. Het zorgvuldig beoordelen van het retentiebeleid van AI-leveranciers is daardoor een noodzakelijke stap om de controle over de bedrijfsinformatie te behouden.
Afbakening: Deze handleiding richt zich specifiek op de audit en de beoordeling van bewaartermijnen en verwerkingsdoelen bij externe AI-partijen. Het gaat hierbij niet om een brede leveranciersauditing of het uitvoeren van een complete gegevensbeschermingseffectbeoordeling. Zie voor bredere inzichten de gidsen over due diligence bij AI-leveranciers en het uitvoeren van een AI-risicoanalyse en DPIA.
De fundamentele vragen voor de leverancier
In de praktijk blijken de standaard productpagina's, marketing-omgevingen en algemene documentatie van AI-aanbieders onvoldoende helderheid te verschaffen over wat er exact met doorgestuurde informatie gebeurt. Termen als "veilige opslag" of "privacy-first" dekken de specifieke technische lading niet. Om een getrouw beeld te krijgen, moeten organisaties gerichte vragen stellen die de volledige levenscyclus van een gegevensstroom afdekken.
Een doeltreffende beoordeling vereist antwoord op de volgende vijf kernvragen:
- Wat wordt precies bewaard? Betreft de opslag alleen de ruwe tekst van de prompt en het antwoord, of worden ook aanvullende metagegevens, systeeminstructies, IP-adressen en verwerkingsparameters opgeslagen?
- Hoe lang blijft de data aanwezig? Blijft de informatie aanwezig gedurende de verwerkingstijd van de aanroep, een vaste termijn van bijvoorbeeld 30 dagen, of totdat de account actief wordt opgezegd?
- Waar bevindt de opslaglocatie zich? In welk geografisch gebied of datacenter staan de servers waarop deze gegevens tijdelijk of permanent rusten, en geldt dit ook voor de reservekopieën?
- Wie heeft toegang tot de gegevens? Welke geautoriseerde medewerkers of geautomatiseerde systemen van de leverancier hebben de mogelijkheid om de opgeslagen invoer in te zien?
- Wat gebeurt er bij beëindiging? Worden de gegevens na het verstrijken van de termijn of de contractsduur automatisch, definitief en onomkeerbaar gewist uit zowel actieve databases als back-ups?
Drie gescheiden doelen voor dataretentie
Een van de grootste valkuilen bij de evaluatie van een AI-dienst is de aanname dat opslag slechts één enkel doel dient. In de praktijk hanteren AI-leveranciers doorgaans drie gescheiden verwerkingsdoeleinden voor het bewaren van invoer- en uitvoergegevens. Elk doel heeft een eigen risicoprofiel en vraagt om een afzonderlijke beoordeling.
| Verwerkingsdoel | Omschrijving | Typische bewaartermijn | Risico-impact |
|---|---|---|---|
| Dienstverlening (Inference) | Het direct verwerken van de aanroep om de reactie van het model te genereren. | Sessiegebonden tot enkele seconden | Laag, mits de data na de aanroep uit de geheugenbuffer verdwijnt. |
| Misbruikdetectie (Abuse Monitoring) | Het bewaren en controleren van prompts om haatzaaiing, fraude of schadelijke inhoud te detecteren. | 30 dagen tot enkele maanden | Middel; data blijft tijdelijk aanwezig en is vaak toegankelijk voor beoordeling. |
| Modeloptimalisatie (Training) | Het gebruiken van klantdata om toekomstige AI-modellen en algoritmes verder te trainen. | Onbeperkt of langdurig | Hoog; intellectueel eigendom en gevoelig materiaal kunnen in het model lekken. |
De reikwijdte van 'Wij trainen niet op jouw data'
Veel AI-leveranciers adverteren met de stellige uitspraak dat zij klantgegevens niet gebruiken om hun modellen mee te trainen. Hoewel dit een cruciale voorwaarde is voor zakelijk gebruik, is het een misvatting te denken dat de data daarmee direct vluchtig is. De toezegging dat er niet op data wordt getraind, sluit immers niet uit dat de gegevens langdurig worden opgeslagen voor misbruikdetectie of systeemanalyse.
Wanneer een leverancier gegarandeerd niet traint op de aangeleverde invoer, is de logische vervolgvraag direct: "Aangezien de data niet wordt gebruikt voor modeltraining, welke specifieke retentietermijnen en toegangsvoorwaarden gelden er dan voor de bewaking van misbruik en beveiliging?" Vaak blijkt uit het antwoord dat de data alsnog dertig dagen ongewijzigd op externe servers blijft staan.
Variabele bewaartermijnen en abonnementsvormen
Retentiebeleid is bij veel AI-aanbieders geen vaststaand gegeven, maar gekoppeld aan de afgenomen abonnementsvorm of het gekozen accounhttype. Gratis consumentenaccounts en standaard self-service accounts hanteren doorgaans een beleid waarbij data standaard wordt bewaard en ingezet voor training en kwaliteitscontrole. Enterprise-abonnementen of specifieke B2B-overeenkomsten bieden daarentegen vaak de optie om training uit te schakelen en de bewaartermijn voor misbruikdetectie te verkorten of volledig op nul te zetten.
Omdat deze instellingen per accountlaag verschillen, is het noodzakelijk om de overeengekomen bewaartermijn expliciet vast te leggen in het zakelijke contract. Zonder deze specifieke contractuele verankering kan een aanpassing in de algemene voorwaarden of een wijziging van het abonnementstype ertoe leiden dat het retentiebeleid ongemerkt verandert. Raadpleeg voor het opstellen van de juiste clausules onze richtlijnen over AI-contracten en SLA-afspraken.
Het reële scenario van menselijke inzage
Een vaak onderbelicht aspect binnen de retentie van AI-data is de mogelijkheid van menselijke inzage (human review). AI-leveranciers zetten geautomatiseerde filters in om potentieel misbruik, schadelijke invoer of overtredingen van de gebruiks-voorwaarden te detecteren. Wanneer zo'n geautomatiseerd systeem een 'vlag' plaatst bij een specifieke prompt of interactie, wordt de betreffende gegevensstroom in veel gevallen doorgestuurd naar een beoordelingsteam.
In dat scenario krijgen medewerkers of gecontracteerde derden van de AI-leverancier direct zicht op de verstuurde tekst. Dit is geen theoretisch risico, maar een gestructureerd onderdeel van het veiligheidsbeleid van veel grote platformen. Bij het beoordelen van een leverancier dient men vooraf vast te stellen:
- Onder welke exacte voorwaarden een prompt wordt geëscaleerd naar menselijke inzage.
- Welke veiligheidsscreening en geheimhoudingsplichten gelden voor het personeel dat deze data inzichtelijk krijgt.
- Of het mogelijk is om via een enterprise-overeenkomst menselijke inzage contractueel uit te sluiten (een zogenaamde 'no human review'-clausule).
Ketenverwerking en onderaannemers
AI-toepassingen maken zelden gebruik van een geïsoleerde infrastructuur. Veel leveranciers bouwen hun dienstverlening op bovenop de API's van grotere AI-cloudproviders, of maken gebruik van gespecialiseerde externe partijen voor specifieke taken zoals vectoropslag, contentmoderatie of spraak-naar-tekstomzetting.
Wanneer er sprake is van een keten van meerdere partijen, wordt de vraag naar gegevensretentie vermenigvuldigd met het aantal schakels. Als organisatie A een AI-toepassing afneemt van leverancier B, die op zijn beurt de infrastructuur van provider C gebruikt en voor moderatie partij D inschakelt, ontstaat er een ketenverwerking. De gegevens passeren de systemen van drie afzonderlijke partijen.
Het retentiebeleid is in zo'n keten slechts zo sterk als de zwakste schakel. Als leverancier B een bewaartermijn van nul dagen belooft, maar onderaannemer C de data dertig dagen opslaat voor logboekanalyse, is het totale verwerkingsrisico alsnog aanwezig. Organisaties dienen daarom de volledige lijst van subverwerkers op te vragen en te controleren of de retentie-afspraken doorwerken in de gehele keten.
De verwerkersovereenkomst versus online documentatie
In de praktijk verwijzen AI-leveranciers voor hun retentiebeleid vaak naar documentatiepagina's, privacy policies of 'Trust Centers' op hun website. Hoewel deze bronnen waardevolle technische details bieden, hebben ze juridisch een dynamisch karakter. De inhoud van een webpagina kan door de leverancier op elk gewenst moment eenzijdig worden gewijzigd zonder voorafgaande kennisgeving.
Om rechtszekerheid te borging, moeten de afspraken omtrent gegevensretentie, opslaglocaties en bewaartermijnen rechtstreeks worden opgenomen in de Verwerkersovereenkomst (VOK) of Data Processing Addendum (DPA). Documentatie zonder contractuele grondslag biedt geen juridische waarborg wanneer de leverancier besluit zijn beleid aan te passen. Binnen de verwerkersovereenkomst dient expliciet te worden vastgelegd dat afwijkingen van het overeengekomen retentiebeleid schriftelijke instemming vereisen. Raadpleeg voor verdere privacy-aspecten ook de AVG-privacychecklist op de kennisgids.
Logboeken als verborgen opslaglocatie
Bij het beoordelen van gegevensretentie richten organisaties zich primair op de primaire database waarin de prompts worden opgeslagen. Een veelvoorkomende opslagplaats die hierbij over het hoofd wordt gezien, is de infrastructurele logging. API-aanroepen passeren webservers, API-gateways, load balancers en interne monitoringnetwerken voordat ze het AI-model bereiken.
In veel van deze tussenliggende lagen worden standaard logbestanden bijgehouden ter ondersteuning van systeembeheer, foutopsporing en netwerkbeveiliging. Vaak bevatten deze logboeken de volledige URI, inclusief headers en in sommige gevallen zelfs de inhoud van de request body. Dit geldt niet alleen voor de infrastructuur van de AI-leverancier, maar ook voor de interne netwerklaag van de eigen organisatie.
Een gedegen retentiebeoordeling vereist dat ook de bewaartermijn van deze logbestanden in kaart wordt gebracht. Zie voor een diepgaandere analyse over de inrichting van interne en externe logging het artikel over audit logging en compliance bij API's.
Risicobeperking aan de bron
In plaats van te vertrouwen op de retentieafspraken van externe leveranciers, kunnen organisaties maatregelen nemen om de hoeveelheid gevoelige data die verstuurd wordt aan de bron te beperken. Hoe minder gevoelige gegevens de organisatie verlaat, hoe kleiner de impact van het retentiebeleid van de leverancier.
Praktische technieken om het gegevensrisico te verkleinen zijn:
1. Dataminimalisatie en opschoning
Analyseer vooraf welke informatie noodzakelijk is voor de specifieke AI-taak. Verwijder overtollige details, persoonlijke identificatiemiddelen en vertrouwelijke bedrijfsinformatie uit de prompt voordat deze naar de API wordt verzonden.
2. Pseudonymisering en anonimisering
Vervang gevoelige velden, zoals namen, BSN's of specifieke klantnummers, door geautomatiseerde tokens of generieke aanduidingen. Pas nadat de uitkomst van het AI-model is ontvangen, worden de oorspronkelijke waarden in de eigen veilige omgeving teruggeplaatst.
3. Scheiding van datastromen
Richt een gedifferentieerde architectuur in waarbij standaard, niet-gevoelige vragen via externe publieke AI-API's worden afgehandeld, terwijl hooggevoelige of vertrouwelijke categorieën via een dedicated, geïsoleerde route lopen. Voor de meest kritieke data kan gekozen worden voor een specifieke technische configuratie; zie daarvoor het overzicht van zero-data-retention API-configuraties.
Beëindiging, verwijdering en de praktijk van back-ups
Wanneer een contract met een AI-leverancier eindigt, of wanneer een specifieke bewaartermijn verstrijkt, moeten de gegevens daadwerkelijk worden verwijderd. Hierbij dient een scherp onderscheid gemaakt te worden tussen het ontoegankelijk maken van data en het daadwerkelijk vernietigen ervan.
Het 'soft delete'-principe, waarbij een record in de database de status 'verwijderd' krijgt maar fysiek aanwezig blijft, voldoet niet aan de eisen van definitieve gegevensverwijdering. De leverancier moet kunnen aantonen dat de data permanent uit de actieve systemen wordt gewist.
Een bijkomend aandachtspunt zijn de roterende back-upsystemen van de leverancier. Data die uit de actieve database is gewist, blijft vaak nog enige tijd aanwezig in incidentele reservekopieën. De overeenkomst moet duidelijk bepalen binnen welk tijdsbestek (bijvoorbeeld maximaal 30 tot 90 dagen) de gegevens ook uit deze back-uparchieven automatisch overschreven en definitief vernietigd worden.
De praktijkgerichte vragenlijst voor leveranciers
Om het beoordelingsproces te standaardiseren en leveranciers objectief met elkaar te kunnen vergelijken, is het aan te raden een vaste vragenlijst te hanteren. Dit voorkomt dat elke evaluatie vanaf nul moet beginnen en zorgt voor een gestroomlijnde dossiervorming.
Een effectieve vragenlijst bevat in ieder geval de volgende vastomlijnde punten:
- Worden de via de API of interface verstuurde gegevens (prompts, uploads, gegenereerde output) gebruikt voor het trainen, finetunen of verbeteren van modellen?
- Wat is de exacte bewaartermijn van de gegevens op actieve servers voor respectievelijk de primaire dienstverlening en eventuele misbruikdetectie?
- Vindt er menselijke controle plaats op ingediende data? Zo ja, onder welke omstandigheden, door wie, en kan dit contractueel worden uitgesloten?
- Op welke geografische locaties worden de data en eventuele afgeleide gegevens opgeslagen en verwerkt?
- Welke onderaannemers of derden verwerken (delen van) de gegevensstroom en hoe is hun retentiebeleid geborgd?
- Hoe lang blijven gegevens aanwezig in back-upomgevingen nadat ze in het actieve systeem zijn gewist?
- Wordt het gespecificeerde retentiebeleid gegarandeerd in een juridisch bindende Verwerkersovereenkomst?
Door deze antwoorden systematisch te verzamelen en op te nemen in het interne dossier voor compliance en risicobeheer, behoudt de organisatie de controle over de externe gegevensstromen en kunnen verantwoorde keuzes worden gemaakt bij het inzetten van AI-technologie. Voor organisaties die een overkoepelende visie willen vastleggen, is het raadzaam dit retentieonderzoek te verankeren in het bredere traject voor het opstellen van AI-beleid.
