AVG en AI-klantenservice: verwerkersovereenkomst, doorgifte, bewaartermijn en verzoeken

Een AI-assistent verandert geen enkele AVG-verplichting. Hij verandert wél waar persoonsgegevens opduiken. In een chatvenster typen klanten dingen die ze nooit in een contactformulier zouden zetten: ordernummers, adressen, klachten over een afschrijving, en hele verhalen die om half twaalf 's avonds worden ingetikt omdat iemand geïrriteerd is. Die tekst wordt doorzocht, samengevat, naar een model gestuurd, als transcript opgeslagen en in je statistieken meegeteld. Niets daarvan is verboden. Alles daarvan moet je kunnen uitleggen.

1. Wie is wat, en wie ziet wat

De meeste discussies over AI en de AVG worden korter zodra de rollen hardop zijn benoemd. Jij bepaalt waarom en hoe de gegevens van je klanten worden verwerkt, dus jij bent verwerkingsverantwoordelijke. Je supportplatform verwerkt in jouw opdracht en is verwerker. De modelleverancier achter de AI-antwoorden zit daaronder als subverwerker. Aan één chatbericht werken drie partijen mee, en maar één daarvan heeft een relatie met die klant: jij.

Die laatste regel wordt vaak over het hoofd gezien. Een platform of kanaal dat jij zelf koppelt, is geen subverwerker van je leverancier maar een dienst die jij hebt aangewezen. Hij hoort in je eigen verwerkingsregister, en niemand anders zet hem daarin.

2. Wat er in de verwerkersovereenkomst hoort

Artikel 28 van de AVG — zie de tekst van Verordening (EU) 2016/679 — schrijft voor wat er in zo'n overeenkomst moet staan. De meeste gepubliceerde overeenkomsten dekken die punten wel. De vraag bij het lezen is niet of de bepalingen erin staan, maar of er iets concreets onder ligt.

• Onderwerp, duur, aard en doel, en de categorieën gegevens en betrokkenen. Wollig op dit punt betekent dat de leverancier nooit heeft uitgezocht wat hij vasthoudt.
• Verwerken uitsluitend op jouw gedocumenteerde instructies, doorgifte inbegrepen, plus de plicht om te melden als een instructie in strijd lijkt met de wet.
• Geheimhouding voor iedereen met toegang, en beveiligingsmaatregelen die concreet zijn: versleuteling onderweg en in rust, scheiding tussen klanten, toegangsbeheer, logging, back-up en herstel.
• Een lijst met subverwerkers, en een aankondigingstermijn voordat er één bij komt of wordt vervangen, met een recht van bezwaar.
• Bijstand bij verzoeken van betrokkenen en bij de artikelen 32 tot en met 36: beveiliging, datalekken, effectbeoordelingen.
• Melding van een datalek zonder onnodige vertraging, met een concreet streven en een contactpersoon met naam, niet alleen de zin uit de verordening.
• Auditrechten, en wat de leverancier aanbiedt in plaats van een audit op locatie.
• Teruggave of verwijdering aan het einde van het contract, inclusief wat er met back-ups gebeurt en hoe lang dat duurt.

Twee dingen die geen bepaling zijn, maken evenveel verschil. Hoe je hoort dat er een subverwerker bij komt: een nieuwsbrief waarop je je zelf moet abonneren is zwakker dan een contractuele termijn. En of jouw supportcontent algemene modellen traint, wat een gewone zin hoort te zijn in plaats van een conclusie die je zelf trekt. Bij ons is dat nee; de tabellen met subverwerkers, de doorgiftegrondslag en de aankondigingstermijn van 30 dagen staan in de verwerkersovereenkomst en het privacybeleid.

3. Doorgifte: waar staat het, en wat gaat eruit

"Staat het in Europa?" zijn twee vragen. Waar staat de primaire opslag, en welke losse verwerkingen verlaten de EER? Bij ons staat de primaire hosting in de EU, wordt de data van elke workspace apart van die van andere klanten opgeslagen, en is alles versleuteld onderweg en in rust. Een deel van de AI-verwerking loopt via subverwerkers buiten de EER, onder de standaardcontractbepalingen van de Europese Commissie met het Britse addendum erbij, opgeschreven zodat je het kunt controleren.

Lees elke andere leverancier op dezelfde manier. Wie "EU-hosting" antwoordt en daarna stopt, heeft iets over zijn database verteld en niets over de modelaanroep. Vraag schriftelijk welke verwerking de EER verlaat, onder welke grondslag, en of er een instelling bestaat waarin dat helemaal niet gebeurt.

4. Bewaartermijn: de data waar niemand eigenaar van is

Transcripten stapelen zich op omdat niemand ooit heeft besloten dat dat niet moet. Ze zijn ook nuttig: voor kwaliteitscontrole, voor gaten in je content, en voor het vervelende moment waarop een klant zegt dat hem iets is toegezegd. Tegelijk is elke maand aan transcripten een maand persoonsgegevens die je bij een verzoek moet doorzoeken, exporteren en verwijderen. Opslagbeperking is geen advies.

• Stel een termijn per soort gegeven in. Gesprekken, AI-logboeken en gekoppelde ordergegevens hebben echt verschillende houdbaarheid.
• Laat de termijn automatisch aflopen. Een bewaarbeleid dat afhangt van iemand die maandelijks opruimt, is geen beleid.
• Weet wat het aflopen kost. Met de transcripten van vorig jaar verdwijnt ook je mogelijkheid om een oude zaak terug te lezen, dus bepaal eerst wat je geaggregeerd bewaart.
• Maskeer in plaats van te bewaren. E-mailadressen en telefoonnummers onleesbaar maken bij het sluiten houdt de draad bruikbaar en haalt er het gevoeligste uit.
• Zet de termijnen in je privacyverklaring in dezelfde woorden als waarin je ze hebt ingesteld.

In ons product zijn dit instellingen die een eigenaar of beheerder van de werkruimte zelf zet: een bewaartermijn voor gesprekken, een aparte voor gedetailleerde AI-logboeken, en een schakelaar die contactgegevens maskeert zodra een gesprek is opgelost. Welke tool je ook kiest, beantwoord op dag één wie die getallen bezit — want de standaard in de meeste systemen is "alles bewaren, voor altijd, per ongeluk".

5. Dataminimalisatie, op de plek waar het gebeurt

Minimaliseren is in een chatproduct vier besluiten over wat je assistent überhaupt nodig mag hebben.

1. Vraag niet wat je niet gebruikt. Elk veld in je pre-chatformulier is data die je vanaf dat moment vasthoudt. Een naam en een e-mailadres beantwoorden de meeste tickets; een geboortedatum bijna nooit.
2. Controleer door te matchen, niet door te tonen. Koppel een orderopzoeking aan het e-mailadres waarmee de klant chat en geef een neutraal "niet gevonden" bij een mismatch, zodat een geraden ordernummer nooit bevestigt dat de bestelling van iemand anders bestaat.
3. Houd de assistent read-only op klantgegevens. Een AI die een order leest, is een ander risico dan een AI die hem mag wijzigen; terugbetalingen en orderwijzigingen zet je klaar voor goedkeuring door een mens.
4. Weet wat de widget in de browser achterlaat. De onze bewaart een sessiekenmerk in de lokale opslag, zodat een terugkerende klant zijn eigen gesprek terugziet — een feit voor je cookieverklaring, en een goede vraag aan elke leverancier.

Dat tweede punt wordt een incident als je het mist, en het is meteen de plek waar de AI-verordening en de AVG elkaar in dezelfde widget tegenkomen. De transparantiekant staat in AI-chatbot, AVG en de AI-verordening.

6. Inzage- en verwijderverzoeken, van begin tot eind

Een inzageverzoek beantwoord je zonder onnodige vertraging en uiterlijk binnen één maand na ontvangst, met een verlenging van maximaal twee maanden bij een complex verzoek of veel verzoeken tegelijk — mits je de betrokkene binnen die eerste maand vertelt dat je verlengt. Ruim, tot je het probeert over vier kanalen en dezelfde klant er drie keer in blijkt te staan.

1. Vind alle identiteiten. Eén persoon kan bestaan als chatbezoeker, e-mailadres, WhatsApp-nummer en klantnummer in je webshop. Bepaal vooraf op welk kenmerk je koppelt: het e-mailadres is meestal het enige dat ze delen.
2. Neem de afgeleide gegevens mee. Labels, sentimentscores, AI-logboeken, analyserijen en gespiegelde ordergegevens zijn allemaal persoonsgegevens over die persoon.
3. Stel de identiteit van de verzoeker vast vóór je iets verstrekt. Een inzageverzoek dat bij de verkeerde persoon belandt, is een datalek in de vermomming van naleving.
4. Bepaal wat "wissen" in jouw systeem betekent. Rijen echt verwijderen breekt vaak de financiële en analytische samenhang, dus veel systemen anonimiseren onomkeerbaar: elk veld dat naar de persoon leidt wordt gewist, het lege omhulsel blijft. Dat is een verdedigbare uitvoering van artikel 17, zolang het resultaat niet meer te herleiden is en je het kunt uitleggen.
5. Volg de gegevens tot in indexen en back-ups. Zoek- en vectorindexen, caches, een export in iemands downloadmap en versleutelde back-ups leven langer dan de databaserij. Back-ups laat je normaal overschrijven in de gewone rotatie; zeg dat, en noem de termijn.
6. Leg vast wat je deed en wanneer. Het verzoek, de identiteitscontrole, de omvang en de afronddatum zijn over een jaar je enige bewijs.

Daaruit volgen twee vragen aan je leverancier. Kun je per klant zelf exporteren en wissen, of wordt elk verzoek een ticket bij de leverancier? En staat klantinhoud in een index die het wissen niet bereikt? Onze route voor particulieren staat op de pagina over gegevensverwijdering, en beheerders kunnen één klant exporteren en wissen vanuit de compliance-instellingen, zonder ons erbij te halen.

7. Heb je een DPIA nodig voor een supportchatbot?

Meestal niet op zichzelf. Een gegevensbeschermingseffectbeoordeling is verplicht als een verwerking waarschijnlijk een hoog risico oplevert voor de rechten en vrijheden van mensen: stelselmatige observatie op grote schaal, bijzondere persoonsgegevens op grote schaal, of geautomatiseerde besluiten met rechtsgevolgen of vergelijkbare gevolgen. Een assistent die vastgelegde vragen beantwoordt en doorzet naar een mens haalt die drempel normaal niet, en een korte vastgelegde toets is dan het juiste resultaat. Dat verandert zodra je er dingen bij zet: scores die mensen anders routeren, medische of financiële details die structureel binnenkomen, een assistent die aanspraken beslist in plaats van beschrijft, opgenomen gesprekken. Kijk ook op de lijst van verwerkingen waarvoor je eigen toezichthouder een DPIA verplicht stelt — die lijsten zijn nationaal en niet overal gelijk.

De mail die je een leverancier stuurt

Alles hierboven past in acht vragen. Stel ze schriftelijk vóór een proefperiode in plaats van erna, als je inkoop vastloopt. De antwoorden komen meestal snel, en traagheid is ook informatie.

• Waar staat de primaire opslag, en welke verwerking verlaat de EER onder welke grondslag?
• Welke subverwerkers verwerken vandaag de persoonsgegevens van onze klanten, en hoeveel aankondiging krijgen wij als die lijst verandert?
• Wordt onze supportcontent gebruikt om algemene modellen te trainen, en is dat contractueel of een instelling?
• Welke bewaartermijnen kunnen wij per soort gegeven instellen, en loopt het aflopen automatisch?
• Hoe stelt de assistent vast met wie hij praat voordat hij order- of accountgegevens noemt?
• Kunnen wij zelf alles over één persoon exporteren en wissen, over alle kanalen, en wat blijft er staan?
• Binnen welke termijn melden jullie een datalek, en wie is de contactpersoon met naam?
• Welke certificeringen en audits hebben jullie vandaag, en wat staat er nog op de roadmap?