AVG en AI Act: de 11 chat-agent checks die de AP doet

De brief komt op een dinsdag. Twee pagina's, Helvetica, briefpapier van de Autoriteit Persoonsgegevens. Wij hebben een klacht ontvangen over een geautomatiseerd antwoord vanuit je klantenservicesysteem. De oprichter van een Nederlandse SaaS met dertig man leest hem twee keer, opent vervolgens de chat-agent die ze vier maanden geleden live hebben gezet, en start een sessie. De AP heeft in haar browser hetzelfde al gedaan.

Zo begint een AVG-onderzoek naar een klantgerichte chat-agent in de praktijk. Niet bij de privacy policy. Bij het product. De privacy policy wordt op dag drie gelezen, nadat de onderzoeker al een beeld heeft. Tegen die tijd is de volgorde waarin zij dingen gecheckt heeft de volgorde die voor jou telt.

Wat volgt is de in de praktijk geteste volgorde. Elf verplichtingen, op de volgorde waarop de AP en (vanaf augustus 2026) het AI Office over een klantgerichte agent lopen die geautomatiseerde beslissingen neemt. De beslissingen waar het om gaat zijn de alledaagse: een refund goedkeuren, een kortingscode afwijzen, een ticket routeren, een lead scoren, kiezen welk document je stuurt. Een B2B SaaS onder de twintig miljoen omzet is het uitgangspunt.

1. De 'je praat met een AI'-disclosure bij sessiestart

Artikel 50 van de EU AI Act, dat geldt vanaf 2 augustus 2026, vereist dat iedere natuurlijke persoon die met een AI-systeem werkt, daarvan op de hoogte is, tenzij het overduidelijk is. 'Overduidelijk' moet hier meer dragen dan het kan. Een chat-widget in de hoek van een SaaS-dashboard met een vriendelijke voornaam is niet overduidelijk. De AP begint hier omdat de test tien seconden kost. Of de eerste bot-tekst zegt het, of niet.

De goede versie is één zin in de eerste bot-tekst, voordat de gebruiker iets heeft getypt. De slechte versie is een tooltip op een vraagteken-icoontje naast de avatar.

2. Een werkende route naar een mens

Artikel 22(3) AVG geeft betrokkenen het recht op menselijke tussenkomst bij een beslissing die uitsluitend op geautomatiseerde verwerking berust. De EDPB-richtsnoeren bij artikel 22 zijn duidelijk: die tussenkomst moet echt zijn, niet pro forma. De AP test dit door te typen: ik wil een mens spreken. Antwoordt de agent met dat kan ik regelen en gaat door, dan is aan de plicht niet voldaan. Doorzetten naar een gesloten Slack-kanaal waar niemand leest telt ook niet.

De overdracht moet binnen één of twee beurten haalbaar zijn, moet de gebruiker uit het geautomatiseerde pad halen, en mag niet vragen dat de gebruiker de toverwoorden kent.

3. Artikel 13/14-informatie over de AI-stap

Tegen de tijd dat de onderzoeker je privacy policy leest, weet ze al wat de agent doet. Ze zoekt of de tekst klopt met wat ze heeft gezien. De policy moet de AI-verwerking benoemen, het waar van toepassing aanmerken als geautomatiseerde besluitvorming, en de doelen en gevolgen uitleggen. Een generieke tekst als 'wij gebruiken mogelijk tools van derden' redt het niet.

Een praktisch patroon: een korte, met naam genoemde sectie in de privacy policy ('Onze AI-assistent'), waarheen vanuit de eerste bot-tekst wordt gelinkt.

4. Betekenisvolle informatie over de logica

Artikel 13(2)(f), 14(2)(g) en 15(1)(h) vereisen betekenisvolle informatie over de logica van geautomatiseerde besluitvorming, plus het belang en de verwachte gevolgen. Dit is de plicht die de branche het vaakst verkeerd heeft uitgelegd. 'Betekenisvol' betekent niet 'het systeem gebruikt een large language model'. Het betekent dat de gebruiker, op het niveau van iemand die niet codeert, kan begrijpen welke factoren de beslissing dreven.

Voor een refund-agent: benoem de categorieën die het model gebruikt. Leeftijd van de bestelling, productcategorie, waarde-bracket, eerdere refund-historie. Niet de gewichten. De categorieën. Wissel je het onderliggende model en verschuiven de categorieën, dan moet de tekst meeschuiven. Verborgen modelwijzigingen zijn een reëel risico op managed API's, en de gebruiker heeft het recht om te weten wanneer datgene wat over zijn refund beslist niet langer hetzelfde is.

5. Een actuele DPIA

Artikel 35 AVG vereist een Data Protection Impact Assessment voor verwerkingen met een hoog risico, wat de AP consequent uitlegt als inclusief geautomatiseerde beslissingen die de toegang van een klant tot een dienst raken. Hun richtlijn over algoritmes en AI is het document dat je als eerste leest.

De DPIA hoeft geen scriptie van veertig pagina's te zijn. Hij moet bestaan, gedateerd, ondertekend, en ingaan op noodzaak, proportionaliteit, risico's voor betrokkenen, maatregelen en restrisico. Verandert het gedrag van de agent wezenlijk (een ander model, een nieuwe tool die hij kan aanroepen, een nieuwe databron die hij kan lezen), dan krijgt de DPIA een nieuwe revisiedatum.

6. De LLM-provider als met naam genoemde sub-verwerker

Draait je agent op Anthropic, OpenAI, Google, Mistral of iemand anders, dan is die provider een sub-verwerker onder artikel 28. De AP controleert of je een getekende DPA met ze hebt en of de provider met naam op je sub-verwerkerspagina staat. 'Diverse AI-diensten' redt het niet.

Bedrock, Vertex en Azure OpenAI voegen een laag toe. De cloudprovider is de directe sub-verwerker en de modelaanbieder zit erachter, en dat moet correct in je documentatie staan. Na elke beleidswijziging aan de platformkant opnieuw nakijken, want wat upstream met wie wordt gedeeld is niet altijd stabiel.

7. Een rechtmatig mechanisme voor doorgifte buiten de EER

Vindt de inference buiten de EER plaats, dan wil de AP je artikel 46-mechanisme zien. Voor de meeste teams betekent dat Standard Contractual Clauses met de provider, plus een Transfer Impact Assessment die ingaat op toegang door de Amerikaanse overheid. Het EU-US Data Privacy Framework helpt, maar is niet onvoorwaardelijk en de schaduw van Schrems II is niet helemaal weg. Hosten in de EU-regio van de provider is de schoonste oplossing als die er is, en de meeste grote providers bieden 'm inmiddels.

8. Vermeldingen in het verwerkingsregister voor de AI-verwerking

Artikel 30-verwerkingsregisters die van vóór de AI-launch dateren en nooit zijn bijgewerkt: dat is de meest voorkomende bevinding in elk AP-dossier dat ik heb gezien. Het register moet de AI-verwerking als aparte regel bevatten, met eigen doel, rechtsgrond, ontvangers, bewaartermijn en doorgiftes. De AP vraagt het register vroeg op, omdat een vergelijking met het echte product elk gat op deze lijst zichtbaar maakt.

9. Een echte opt-out voor gebruik als trainingsdata

De meeste grote LLM-API's trainen niet standaard op enterprise-input, maar gebruikers hebben onder artikel 21 het recht om bezwaar te maken tegen verwerking, en de AI Act versterkt de verwachting dat consumenten weten waar hun gesprek wel en niet voor wordt gebruikt. De AP zoekt naar een duidelijke uitspraak over de trainingsdata-status bij de chat zelf, niet weggestopt op een sub-pagina die niemand opent.

10. Cookie- en trackingtoestemming voor de widget

De chat-widget laadt vaak vanaf een domein van een derde, plaatst cookies en start een session-id voordat de gebruiker iets heeft getypt. Onder de Telecommunicatiewet, de Nederlandse implementatie van ePrivacy, vereist dat voorafgaande toestemming voor alles wat niet strikt noodzakelijk is. Zowel de AP als de ACM kijken hiernaar, en de ACM was hier in 2025-2026 actiever in dan de AP zelf.

11. Incidentlogging voor AI-specifieke fouten

De meeste SaaS-chat-agents zijn geen AI-systemen met hoog risico onder bijlage III van de AI Act, dus de formele meldplicht uit de AI Act bijt niet. Artikel 32 AVG blijft van kracht. Een gehallucineerde refund-afwijzing die een niet-bestaande policy-clausule citeert is een data-juistheidsincident onder artikel 5(1)(d). De AP vraagt steeds vaker: heb je een log, kun je het overleggen, heeft de gebruiker een correctie gehad?

De civielrechtelijke aansprakelijkheidslijn beweegt mee met de regulatoire. Europese rechters beginnen te bepalen wie verantwoordelijk is voor een uitspraak die een AI-systeem over een klant doet. Verzint je agent een feit over iemands account, dan wordt de aansprakelijkheidsvraag in lopende rechtszaken beslist, niet in een toekomstige white paper. De goedkoopste verdediging is een log waaruit blijkt dat je het hebt opgemerkt en hebt gecorrigeerd.

Een audit van vijf minuten die je vandaag kunt doen

Open je eigen chat-agent in een incognito-venster. Typ: ik wil een mens spreken. Typ daarna: wat ben jij. Vraag hem dan om een beslissing te nemen die een gebruiker mogelijk wil terugdraaien: zeg mijn abonnement op, geef een refund op mijn laatste factuur. Lees ondertussen de privacy policy in een ander tabblad. Het gat tussen wat de agent doet en wat de policy zegt, is het gat dat een onderzoeker gaat documenteren.

Toen we de support-agent bouwden voor een van onze SaaS-klanten, was de plicht die het hardst beet nummer vier: die over betekenisvolle informatie. De eerlijke versie van 'welke factoren dreven deze beslissing' was lastig op te schrijven zonder de system prompt te lekken, en de juridische versie was lastig op te schrijven zonder nutteloos te zijn. We zijn geëindigd met een korte beslissingskaart richting de gebruiker, die de categorieën benoemt en linkt naar een langere uitleg voor wie het detail wil. Ontwerp je vergelijkbare oppervlakken, dan begint ons werk aan AI-agents precies bij deze vraag.