Wat mag je bewaren van een AI-gesprek?
Welke onderdelen van een AI-gesprek mag je bewaren, hoe lang en waarom? Praktische uitleg over gesprekslogs, persoonsgegevens, pseudonimisering, audittrails, leveranciers, verwijdering en een werkbaar bewaarbeleid onder de AVG.
Van een AI-gesprek bewaar je alleen de gegevens die je nodig hebt voor een duidelijk omschreven doel, en niet langer dan dat doel rechtvaardigt. Dat kan bijvoorbeeld nodig zijn om fouten te onderzoeken, de kwaliteit van een AI-dienst te verbeteren, beslissingen te reconstrueren of een geschil af te handelen. Bewaar niet automatisch ieder gesprek volledig omdat het technisch eenvoudig is.
Wees extra voorzichtig zodra gesprekken persoonsgegevens kunnen bevatten. Gebruikers typen regelmatig namen, e-mailadressen, dossierinformatie of andere persoonlijke gegevens in zonder dat je daar vooraf rekening mee hebt gehouden. De AVG-beginselen van doelbinding, dataminimalisatie, opslagbeperking en beveiliging zijn daarom ook relevant voor AI-gesprekslogs. Wettelijke bewaarplichten verschillen per sector en situatie. Dit artikel geeft praktische aandachtspunten en is geen juridisch advies. Zie voor de bredere context ook AI en de AVG.
Waarom zou je AI-gesprekken bewaren?
Er zijn legitieme redenen om delen van gesprekken tijdelijk of langer beschikbaar te houden. Zonder logging is het bijvoorbeeld lastig om te onderzoeken waarom een chatbot een verkeerd antwoord gaf of waarom een agent een bepaalde actie uitvoerde. Logs kunnen ook nodig zijn om incidenten te analyseren, klachten te behandelen of achteraf aan te tonen hoe een systeem tot een uitvoer kwam.
Een ander doel is kwaliteitsverbetering. Je kunt gesprekken analyseren om terugkerende fouten, ontbrekende kennis of onduidelijke instructies te vinden. Daarvoor heb je echter niet automatisch alle oorspronkelijke persoonsgegevens nodig. Vaak kun je datasets pseudonimiseren, gevoelige velden verwijderen of alleen geselecteerde gesprekken opnemen in een evaluatieset. Monitoring en inhoudelijke kwaliteitsanalyse zijn bovendien verschillende processen. Meer daarover staat in AI-monitoring: welke signalen doen er echt toe?.
Wat staat er eigenlijk in een gesprekslog?
Een AI-gesprekslog bevat vaak meer dan alleen de zichtbare vraag en het antwoord. Afhankelijk van de architectuur kunnen ook gebruikte bronnen, timestamps, modelinformatie, foutmeldingen, toolaanroepen, sessiegegevens, gebruikers-ID's en technische metadata worden vastgelegd. Bij een RAG-systeem kunnen bijvoorbeeld verwijzingen naar geraadpleegde documenten worden opgeslagen.
Het belangrijkste risico is dat je niet altijd vooraf weet welke persoonsgegevens een gebruiker invoert. Een medewerker kan een naam, klantnummer, medisch detail of volledige e-mail in een prompt plakken. Daardoor kan een technisch logbestand ongemerkt een verzameling persoonsgegevens worden. Dat maakt het verstandig om al bij het ontwerp te bepalen welke velden werkelijk nodig zijn en welke gegevens vóór opslag kunnen worden gemaskeerd of verwijderd.
Operationele logs, kwaliteitsdata en audittrails zijn niet hetzelfde
Maak onderscheid tussen verschillende soorten logging. Operationele logs helpen bij beschikbaarheid, performance en foutopsporing. Daarvoor zijn vaak technische kenmerken voldoende en hoeft de volledige inhoud van gesprekken niet altijd te worden opgeslagen.
Kwaliteitsdata gebruik je om antwoorden, retrieval, prompts of modelgedrag te evalueren. Daarvoor kan inhoud nodig zijn, maar je kunt de dataset beperken tot geselecteerde voorbeelden en waar mogelijk persoonsgegevens verwijderen of pseudonimiseren.
Audittrails zijn bedoeld om achteraf te kunnen reconstrueren wat een AI-systeem heeft gedaan, bijvoorbeeld welke actie een agent uitvoerde, welke bron werd gebruikt en of een menselijke goedkeuring aanwezig was. Bij agents kan die audittrail belangrijker zijn dan het bewaren van iedere volledige conversatie. Zie ook agent-observability.
Beperk persoonsgegevens vóórdat ze in logs terechtkomen
Pseudonimiseren betekent dat je direct identificerende gegevens vervangt door een andere identificator, terwijl koppeling onder bepaalde voorwaarden nog mogelijk blijft. Het is geen anonimisering. Maskeren gaat een stap praktischer te werk: bijvoorbeeld een e-mailadres, telefoonnummer of klantnummer vervangen door een generieke aanduiding in het log.
Je kunt dergelijke filtering waar mogelijk uitvoeren vóórdat een gesprek in een centrale logomgeving wordt opgeslagen. Denk ook aan documenten of tekst die via een RAG-pijplijn worden meegestuurd. Dezelfde principes spelen daar. Zie documenten anonimiseren voordat ze een model in gaan.
Beperk daarnaast wie logs kan bekijken. Ontwikkelaars hebben mogelijk technische foutinformatie nodig, terwijl een kwaliteitsmedewerker gespreksinhoud moet kunnen beoordelen. Dat betekent niet dat beide rollen automatisch toegang tot alle data hoeven te krijgen. Gebruik passende toegangsrechten en leg vast wie gevoelige logs mag raadplegen.
Regel verwijdering en verzoeken van betrokkenen
Een bewaarbeleid werkt alleen als gegevens ook daadwerkelijk worden verwijderd. Leg daarom vast welke systemen kopieën bevatten: applicatielogs, observability-platforms, databases, back-ups, evaluatiesets en eventueel systemen van externe leveranciers. Alleen een gesprek uit de gebruikersinterface verwijderen is niet noodzakelijk hetzelfde als alle onderliggende kopieën verwijderen.
Houd ook rekening met verzoeken van betrokkenen. Je moet technisch kunnen bepalen waar gegevens zich bevinden en welke identificatoren nodig zijn om relevante records terug te vinden. Een goed ontworpen pseudonimiseringsstrategie helpt daarbij, maar kan het zoeken juist moeilijker maken als er geen gecontroleerde koppeling meer bestaat. Neem dit mee in het ontwerp en, waar passend, in een DPIA voor AI.
Controleer wat je modelleverancier met gesprekken doet
Je eigen bewaarbeleid is maar één deel van de keten. Wanneer prompts en antwoorden naar een externe modelprovider gaan, moet je ook controleren wat die leverancier ermee doet. Bekijk de verwerkersovereenkomst, productvoorwaarden en instellingen voor gegevensverwerking, training en retentie.
Ga er niet vanuit dat instellingen voor een consumentenproduct, een zakelijke omgeving en een API hetzelfde zijn. Controleer specifiek de dienst die je gebruikt. Leg bovendien vast welke configuratie je hebt gekozen, zodat een wijziging in instellingen of leverancier later niet ongemerkt tot een ander gegevensbeleid leidt.
Een praktisch beleid voor AI-gesprekken
- Definieer per log het doel: leg vast waarom de gegevens worden opgeslagen en voorkom algemeen geformuleerde doelen zoals “voor later gebruik”.
- Sla zo weinig mogelijk op: bepaal of volledige prompts en antwoorden nodig zijn of dat technische metadata voldoende is.
- Scheid soorten logs: behandel operationele logging, kwaliteitsdata en audittrails als afzonderlijke gegevensstromen met eigen toegang en bewaarbeleid.
- Filter persoonsgegevens: maskeer of pseudonimiseer gegevens waar dat mogelijk is voordat ze langdurig worden opgeslagen.
- Beperk toegang: geef medewerkers alleen toegang tot de loggegevens die zij voor hun taak nodig hebben.
- Regel verwijdering: zorg dat gegevens na het einde van het doel ook uit relevante systemen en afgeleide datasets verdwijnen, voor zover dat technisch en juridisch van toepassing is.
- Controleer leveranciers: beoordeel afspraken en instellingen rond training, retentie en verwerking bij externe AI-aanbieders.
De kern is dat een AI-gesprek geen onschuldige technische logregel is. Zodra inhoud, gebruikersgegevens en metadata samen worden opgeslagen, kan er een omvangrijke gegevensverzameling ontstaan. Ontwerp logging daarom vanuit het doel: bewaar wat je nodig hebt, beperk toegang en bewaartijd, en verwijder wat je niet meer nodig hebt. Controleer bij sectorspecifieke verplichtingen of bijzondere persoonsgegevens altijd welke aanvullende regels voor jouw organisatie gelden.