Klanten vertellen een chatbot veel meer dan je vraagt. Ze plakken ordernummers en afleveradressen in het venster, klagen over de bezorger, noemen hun medicijnen of de reden dat hun incasso is mislukt. Zodra een chatbot of AI-assistent live gaat, wordt die een van je drukste systemen met persoonsgegevens – en onder de AVG ben jij daarvoor verantwoordelijk, niet de modelleverancier.
Dat klinkt zwaarder dan het is. Een AVG-proof chatbot draait om een handvol beslissingen vóór de lancering: wie verwerkt wat, op welke grondslag, waar staan de gegevens, hoe lang bewaar je logs en wat doe je als het misgaat? Wie die vragen goed beantwoordt, heeft met dezelfde documentatie meteen antwoord voor de functionaris gegevensbescherming, de inkoopafdeling van grote klanten en de transparantieregels van de AI-verordening.
Waarom een chatbot een AVG-project is
Drie eigenschappen maken conversationele AI anders dan een contactformulier:
- Vrije tekst. Je bepaalt niet wat mensen typen. Bijzondere persoonsgegevens (gezondheid, religie, afkomst – art. 9 AVG) duiken op zonder dat je erom vraagt.
- Een lange keten van verwerkers. Een typische opzet bestaat uit chatwidget, orkestratielaag, LLM-API, vectordatabase, CRM of helpdesk, plus logging en analyse. Elke schakel kan gegevens opslaan.
- Ondoorzichtig hergebruik. Sommige AI-leveranciers bewaren prompts voor misbruikdetectie of gebruiken ze in consumentenabonnementen voor training. Wie dat niet controleert, vindt klantgegevens straks op plekken die in geen enkele privacyverklaring staan.
Europese bedrijven weten dit. Van de Duitse bedrijven die al AI gebruiken, noemt 66% eisen rond gegevensbescherming en 45% het risico op datalekken als belemmering (Bitkom). Een bot die kan aantonen hoe hij met gegevens omgaat, neemt die bezwaren sneller weg dan een iets slimmere bot die dat niet kan.
Stap 1: breng de gegevensstroom in kaart
Teken vóór elke juridische analyse de route van één bericht:
- Widget of kanaal – website, WhatsApp, Telegram, e-mail. Sinds 15 januari 2026 staat de WhatsApp Business API geen AI-assistenten voor algemene doeleinden meer toe; bedrijfsbots voor eigen klanten blijven toegestaan (TechCrunch).
- Orkestratie – een platform als Botpress of Intercom, een zelf gehoste n8n-instantie of eigen code.
- Model – de LLM-API, de regio en of prompts worden bewaard.
- Retrieval – de vectordatabase en de documenten die daarin geïndexeerd zijn.
- Acties – CRM, ordersysteem, agenda.
- Logs en analyse – transcripten, traces, foutregistratie, dashboards.
Noteer per blok welke persoonsgegevens binnenkomen, waar het gehost wordt en hoe lang het bewaard blijft. Deze schets vormt de kern van je verwerkingsregister (art. 30) en je DPIA.
Stap 2: kies per doel een grondslag
Er bestaat niet „dé grondslag voor de chatbot”. Elk doel heeft zijn eigen grondslag nodig.
| Doel | Gebruikelijke grondslag (art. 6 AVG) | Let op |
|---|---|---|
| Vragen beantwoorden, bestelling of retour afhandelen | Overeenkomst of precontractuele maatregelen, art. 6 lid 1 sub b | Alleen gegevens die nodig zijn voor de vraag |
| Orderstatus, afspraak maken, accountwijzigingen | Overeenkomst, art. 6 lid 1 sub b | Eerst verifiëren, dan pas informatie geven |
| Transcripten analyseren om antwoorden te verbeteren | Gerechtvaardigd belang, art. 6 lid 1 sub f | Belangenafweging vastleggen; pseudonimiseren |
| Marketingopvolging, nieuwsbriefaanmelding in de chat | Toestemming, art. 6 lid 1 sub a | Apart, niet vooraf aangevinkt, aantoonbaar |
| Gezondheidsvragen in een praktijkbot | Daarnaast een uitzondering van art. 9 lid 2, meestal uitdrukkelijke toestemming | Medische onderwerpen eventueel buiten scope houden |
| Model van de leverancier trainen op jouw chats | Vermijden | Uitzetten in instellingen én contract |
Het netst is een doelgebonden ontwerp: de bot beantwoordt, plant en escaleert – en zegt dat meteen aan het begin van het gesprek.
Stap 3: de verwerkersovereenkomst en de keten van subverwerkers
Elke leverancier die gesprekken namens jou verwerkt, is verwerker, en art. 28 vereist een schriftelijke verwerkersovereenkomst. Een goede verwerkersovereenkomst met een AI-leverancier regelt:
- verwerking alleen op jouw gedocumenteerde instructie – waarbij training op jouw gegevens is uitgesloten;
- geheimhouding van personeel en passende beveiligingsmaatregelen (art. 32);
- een lijst van subverwerkers en jouw recht om bezwaar te maken tegen nieuwe;
- hulp bij verzoeken van betrokkenen en bij DPIA’s;
- verwijdering of teruggave van gegevens aan het einde van het contract;
- melding van datalekken zonder onredelijke vertraging, zodat jij je eigen termijn van 72 uur haalt;
- auditrechten of erkende certificeringen.
Stel elke AI-leverancier dezelfde vijf vragen: Trainen jullie op onze data? Hoe lang bewaren jullie prompts en output, en waarom? In welke regio’s worden gegevens verwerkt? Wie zijn jullie subverwerkers? Hoe snel melden jullie een incident? De antwoorden horen in je leveranciersdossier – en bepalen vaak welke leverancier je kiest.
Stap 4: dataopslag en doorgifte buiten de EER
Wie persoonsgegevens buiten de Europese Economische Ruimte laat verwerken, heeft een basis uit hoofdstuk V van de AVG nodig. Bij Amerikaanse leveranciers is dat meestal een certificering onder het EU-US Data Privacy Framework of standaardcontractbepalingen met een doorgiftetoets. Amerikaanse chat- en telefonieplatformen worden in Europa doorgaans zo ingezet; dat werkt, maar het kost papierwerk en brengt een politiek risico mee waar veel inkopers rekening mee houden. In door Deloitte gerapporteerde onderzoeken let 77% van de bedrijven op het land van herkomst van hun AI-leverancier en maakt 66% zich zorgen over afhankelijkheid van buitenlandse AI (DEV Community).
| Optie | Werk rond doorgifte | Kwaliteit en kosten | Geschikt voor |
|---|---|---|---|
| Amerikaanse model-API via DPF of SCC’s | Doorgiftetoets, leverancierschecks | Topmodellen, betalen per token | Support met weinig gevoelige gegevens |
| Grote leverancier met EU-verwerkingsregio | Minder; regio contractueel vastleggen | Topmodellen, soms duurder | De meeste mkb-supportbots |
| Open-weight-model (bijv. Mistral) gehost in de EU | Geen doorgifte buiten de EER | Iets lagere kwaliteit, vaste infrastructuurkosten | Gevoelige gegevens, gereguleerde sectoren |
| Model on-premises | Geen | Meeste inspanning | Strenge sectorregels, grote volumes |
Ook de orkestratielaag telt mee. De community-editie van n8n kun je gratis zelf hosten op een server in de EU (n8n); workflowgegevens en inloggegevens blijven dan binnen je eigen infrastructuur. De afwegingen rond eigen modellen staan in private en on-premises LLM’s voor Europese bedrijven.
Stap 5: logs – bewaar wat nodig is, verwijder de rest
Je hebt logs nodig: om foute antwoorden te analyseren, om geschillen af te handelen („jullie bot beloofde me mijn geld terug”), om misbruik op te sporen en – bij hoog-risicosystemen onder de AI-verordening – om automatisch gegenereerde logs minstens zes maanden te bewaren. Maar het beginsel van opslagbeperking (art. 5 lid 1 sub e) maakt „alles voor altijd bewaren” onmogelijk.
Een bewaarschema dat we vaak als startpunt gebruiken – aan te passen aan jouw doelen en vast te leggen:
| Gegevens | Voorgestelde bewaartermijn | Toelichting |
|---|---|---|
| Ruwe transcripten met persoonsgegevens | 30–90 dagen | Genoeg voor kwaliteitscontrole en klachten |
| Geëscaleerde gesprekken | Gelijk aan het bijbehorende ticket in het CRM | Volg je bestaande regels voor klantdossiers |
| Gepseudonimiseerde traces (prompt, model, latency, kosten) | 6–12 maanden | Voor evals, kostenbeheersing en debugging |
| Geaggregeerde analyses | Onbeperkt | Geen persoonsgegevens meer |
| Beveiligings- en toegangslogs | Volgens je beveiligingsbeleid | Beschermen als productiedata |
Twee technieken maken het probleem een stuk kleiner. Maskeren vóór het model: e-mailadressen, telefoonnummers, IBAN’s en ordernummers worden vervangen voordat de prompt je systeem verlaat, en alleen teruggezet waar een actie ze nodig heeft. Eigen observability: tracingtools als Langfuse of Helicone, die bij sterke AI-teams standaard zijn (HouseofMVPs), kunnen in je eigen omgeving draaien, zodat traces niet bij nóg een leverancier belanden.
Stap 6: transparantie en rechten van betrokkenen
Je privacyverklaring moet de chatbot dekken (art. 13 en 14): doelen, grondslagen, ontvangers inclusief AI-leveranciers, doorgiften, bewaartermijnen en rechten. Aan het begin van de chat volstaat een korte regel met een link. Sinds 2 augustus 2026 eist de AI-verordening daarnaast dat gebruikers weten dat ze met een AI-systeem praten – één zin kan beide doen. De kant van de AI-verordening leggen we uit in de gids AI-verordening voor het mkb.
Houd vanaf dag één rekening met verzoeken van betrokkenen:
- Inzage (art. 15) en verwijdering (art. 17) – vind je alle gesprekken van één persoon terug in widget, logs en CRM? Koppel ze aan een klant-ID.
- Bezwaar (art. 21) – respecteer dit bij verwerkingen op basis van gerechtvaardigd belang, zoals kwaliteitsanalyse.
- Geautomatiseerde besluiten (art. 22) – neemt de bot besluiten met rechtsgevolgen of vergelijkbare aanzienlijke gevolgen, zoals het weigeren van een terugbetaling of krediet, bied dan menselijke beoordeling en leg de logica uit.
- Termijn – één maand om te reageren (art. 12 lid 3).
Stap 7: beveiliging hoort bij compliance
Art. 32 vraagt beveiliging die past bij het risico, en het AI-ecosysteem levert genoeg waarschuwende voorbeelden. Een scan van 5.600 publiek bereikbare, met „vibe coding” gebouwde apps vond meer dan 2.000 ernstige kwetsbaarheden, 400 blootgestelde geheimen en 175 lekken van persoonsgegevens (SoftwareSeni). Eén AI-chatapp stelde 406 miljoen records bloot via een Firebase-regel die alles toestond (Cloud Security Alliance).
Dan is er nog prompt injection – instructies, verstopt in berichten of documenten, die het model gegevens laten lekken of tools laten misbruiken. Zelfs OpenAI erkent dat dit probleem mogelijk nooit volledig op te lossen is (Brandon Ta). Het praktische antwoord zit in de architectuur: geef de bot de smalst mogelijke tools, dwing autorisatie buiten het model af, laat hem nooit vrij databases bevragen en test aanvallen vóór de lancering. Meer daarover in prompt injection en beveiliging van agents.
Lekken er toch persoonsgegevens, dan heb je volgens art. 33 72 uur om de Autoriteit Persoonsgegevens te informeren. Leg dat draaiboek vast vóór de lancering, niet erna.
Wanneer je een DPIA nodig hebt
Art. 35 vereist een gegevensbeschermingseffectbeoordeling (DPIA) als een verwerking waarschijnlijk een hoog risico oplevert. Typische aanleidingen bij chatbots: nieuwe technologie op grote schaal, bijzondere persoonsgegevens, stelselmatige monitoring, opgenomen gesprekken en stembiometrie. In de praktijk is een DPIA voor een supportbot een compact document en geen boekwerk: de schets van de gegevensstroom, grondslagen, risico’s (foute antwoorden, lekken, injection, doorgifte) en de maatregelen per risico. Het is meteen het document dat grote klanten in hun due diligence opvragen.
Praktijkvoorbeeld: een supportbot voor een webshop
Een meubelwebshop uit Eindhoven verkoopt in Nederland en Duitsland en wil een bot voor productvragen, track & trace en retouren. Zo vallen de beslissingen uit:
- Scope. Productvragen beantwoordt de bot uitsluitend uit de openbare catalogus – zonder persoonsgegevens. Voor orderstatus en retour verifieert de klant zich eerst met ordernummer en postcode.
- Grondslag. Overeenkomst (art. 6 lid 1 sub b) voor bestellingen en retouren; gerechtvaardigd belang voor steekproefsgewijze analyse van transcripten, vastgelegd in een korte belangenafweging.
- Leveranciers. Orkestratie op een eigen server in de EU, het LLM via een EU-verwerkingsregio, webshopsysteem en helpdesk met bestaande verwerkersovereenkomsten. Training op webshopdata contractueel uitgesloten.
- Maskeren. Namen, adressen en telefoonnummers worden vóór de prompt vervangen; het opzoeken van de order doet de code, niet het model.
- Logs. Ruwe transcripten 60 dagen, gepseudonimiseerde traces een jaar, escalaties bij het helpdeskticket.
- Transparantie. Eerste bericht, in het Nederlands of Duits afhankelijk van de webshopversie: „Ik ben de AI-assistent van de webshop. Hoe we met je gegevens omgaan, lees je in onze privacyverklaring. Typ ‚medewerker’ om een mens te spreken.” – met een link naar de privacyverklaring.
Niets hiervan is exotisch. Het is ontwerpwerk dat je één keer aan het begin doet, in plaats van het onder druk te repareren wanneer de eerste grote klant of het eerste inzageverzoek binnenkomt.
Veelgemaakte fouten
- Consumentenaccounts van AI-diensten gebruiken voor een zakelijke bot. Consumentenvoorwaarden staan vaak training op invoer toe en bieden geen verwerkersovereenkomst.
- Geen overzicht van subverwerkers. De privacyverklaring noemt één leverancier; in werkelijkheid raken er vijf de gegevens aan.
- „Alle logs bewaren, je weet maar nooit.” Onbeperkt bewaren schendt de opslagbeperking en maakt elk lek groot.
- Het model laten bepalen wie wat mag zien. Autorisatie hoort in de code, niet in de prompt.
- Gezondheidsgegevens als randgeval zien. In praktijken, verzekeringen of HR zijn ze de hoofdzaak – ontwerp ervoor of sluit ze uit.
- De route naar een mens vergeten. Zonder escalatie naar een persoon halen art. 22 en gefrustreerde klanten je in.
Conclusie
Een AVG-conforme chatbot is geen speciaal product, maar een gewoon product dat met discipline is gebouwd: gegevensstroom in kaart, grondslag per doel, verwerkersovereenkomsten met elke verwerker, een bewuste keuze voor de opslaglocatie, een bewaarschema, maskeren vóór het model en een draaiboek voor datalekken. Aan het begin genomen kosten die beslissingen dagen in plaats van maanden – en ze houden je opties open, want gegevens die je zelf beheert, kun je ook meenemen. Daar draait het om in eigenaar van je AI blijven en vendor lock-in voorkomen.
Lotus Libre bouwt AI-agents voor support en sales en de systemen eromheen – met hosting in de EU, maskering, logging en documentatie die klaar is voor de verwerkersovereenkomst. Wil je een tweede paar ogen op je bestaande of geplande bot? Plan een gratis audit van 15 minuten.
Dit artikel is algemene informatie en geen juridisch advies. Raadpleeg voor beslissingen over jouw specifieke situatie een gekwalificeerde jurist of je functionaris gegevensbescherming.