Chatbot-leveranciers beoordelen: verwerkersovereenkomst, subverwerkers en doorgifte naar derde landen

Een chatbot-leverancier kan een overtuigende demo, een EU-regio en een kant-en-klare verwerkersovereenkomst presenteren – en toch blijven er cruciale vragen openstaan. Want niet alleen de zichtbare chatbot verwerkt gegevens. Vaak spelen model-API's, hosting, vector-databases, foutanalyse, support-tools, e-maildiensten en back-ups een rol bij het leveren van de dienst. Voor website-eigenaren telt daarom de verifieerbare verwerkingsketen, niet de privacy-kreet op een verkooppagina.

Deze checklist helpt bij een gestructureerde leveranciersbeoordeling vóór de aanschaf en go-live. Het is een praktische leidraad en geen juridisch advies. Rollen, rechtsgronden, informatieplichten en doorgiftemechanismen moeten voor de specifieke toepassing worden gecontroleerd; bij een verhoogd risico, bijzondere categorieën van persoonsgegevens of openstaande contractuele vragen moet de functionaris voor gegevensbescherming (FG) of een gekwalificeerde juridisch adviseur worden ingeschakeld.

Eerst de datastroom begrijpen, dan het contract beoordelen

De centrale vraag luidt niet alleen "Waar staat de server?", maar: Welke persoonsgegevens komen wanneer bij welke rechtspersoon terecht, om welke reden en voor hoe lang? Een bezoeker kan in de chat namen, e-mailadressen, klantnummers of vrije tekst invoeren. Daarnaast ontstaan er IP-adressen, tijdstempels, apparaat-informatie, sessie-ID's, gespreksgeschiedenis, beoordelingen en technische logboeken. Ook uit een zogenaamd anoniem gesprek kan door combinatie van meerdere kenmerken een herleidbaarheid naar personen ontstaan.

Teken daarom vóór de contractcontrole een eenvoudige datastroomkaart. Deze moet ten minste de browser-widget, het chatbot-platform, de kennisbank, de model-leverancier, analyse- en foutopsporingsdiensten, supporttoegang, back-ups en verwijderpaden bevatten. Voor elk station worden de beheerder, het land, het doel, de gegevenscategorieën, de bewaartermijn en mogelijke toegang op afstand vastgelegd. Een bewering als "EU-hosting" geeft bijvoorbeeld geen antwoord op de vraag of een supportteam buiten de Europese Economische Ruimte (EER) toegang heeft tot productielogs.

Privacyrollen per doel bepalen

Of een leverancier verwerker is dan wel voor specifieke doeleinden zelf verwerkingsverantwoordelijke is, vloeit voort uit de feitelijke werkzaamheden. De Richtsnoeren 07/2020 van het Europees Comité voor gegevensbescherming (EDPB) lichten deze afbakening toe. Een leverancier kan bijvoorbeeld gespreksgegevens verwerken op basis van gedocumenteerde instructies, maar voor bepaalde eigen veiligheids-, facturatie- of productdoeleinden een andere rol claimen. Laat elk doel, de bijbehorende rol en de rechtsgrond uitdrukkelijk toewijzen. Een verwerkersovereenkomst dekt niet automatisch zelfstandige doeleinden van de leverancier af.

Verwerkersovereenkomst controleren: verplichte inhoud moet aansluiten bij de feitelijke dienst

Artikel 28 AVG vereist dat verwerkingsverantwoordelijken uitsluitend een beroep doen op verwerkers die afdoende garanties bieden met betrekking tot het toepassen van passende technische en organisatorische maatregelen. Het contract moet onder meer het onderwerp en de duur, de aard en het doel, de typen persoonsgegevens, de categorieën van betrokkenen en de rechten en verplichtingen van de verwerkingsverantwoordelijke vastleggen. Daarbij komen gedocumenteerde instructies, geheimhouding, beveiliging, bijstand bij rechten van betrokkenen en privacyverplichtingen, verwijdering of retournering, alsmede informatie en medewerking bij audits.

Vergelijk de verwerkersovereenkomst niet alleen met een controlelijstje, maar met uw datastroomkaart en het daadwerkelijk afgenomen tarief/pakket. Een goed contract benoemt de chatfunctionaliteit, de training dan wel indexering van de kennisbank, de logging, supporttoegang en optionele functies op een begrijpelijke manier. Onduidelijke verzamelbegrippen zoals "dienstverbetering" moeten worden gespecificeerd naar concrete gegevens, doeleinden, keuzemogelijkheden en rollen.

• Instructie: Is het duidelijk dat inhoud en metadata alleen worden verwerkt voor gedocumenteerde doeleinden van de klant? Welke configuratie geldt als instructie?
• Gebruik voor modellen: Worden prompts, antwoorden of geüploade inhoud gebruikt voor algemene modeltraining of productverbetering? Zo nee, dan moet dit contractueel en technisch verifieerbaar zijn; zo ja, dan moeten de rol en rechtsgrond afzonderlijk worden beoordeeld.
• Verwijdering: Zijn er concrete termijnen voor gespreksgeschiedenis, logs, vector-indexen, back-ups en supportkopieën? Wat gebeurt er na afloop van het contract?
• Beveiliging: Zijn toegangscontroles, scheiding van gegevens (multi-tenancy), versleuteling, logging, kwetsbaarheidsbeheer en incidentenprocessen beschreven?
• Bijstand: Regelt de verwerkersovereenkomst export, rectificatie, verwijdering, inzage, beveiligingsincidenten en eventuele gegevensbeschermingseffectbeoordelingen (GEB/DPIA) op een praktische manier?
• Bewijsstukken: Zijn er auditrapporten, certificeringen of andere deugdelijke bewijzen beschikbaar en gelden deze voor precies de ingezette diensten en locaties?

Certificaten en auditrapporten kunnen belangrijke aanwijzingen bieden, maar ze vervangen noch de controle van het specifieke verwerkingsproces, noch passende contractuele clausules. Ook een gestandaardiseerde verwerkersovereenkomst is slechts zo goed als de ingevulde bijlagen en de overeenstemming met de technische werkelijkheid.

Subverwerkers: namen, taken en wijzigingen controleren

Volgens artikel 28 lid 2 AVG mag een verwerker geen andere verwerker inschakelen zonder voorafgaande specifieke of algemene schriftelijke toestemming. Bij een algemene toestemming moet de verwerker de verwerkingsverantwoordelijke informeren over beoogde veranderingen inzake de toevoeging of vervanging en de mogelijkheid bieden om hiertegen bezwaar te maken. De Veelgestelde vragen van de Europese Commissie over standaardcontractbepalingen verduidelijken bovendien dat loutere categorieën niet volstaan: de afzonderlijke subverwerkers moeten bij naam worden genoemd.

Eis een actuele, exporteerbare lijst met de statutaire naam, het land, de specifieke dienst en de betrokken gegevens. Controleer bovendien of een bedrijf enkel de contractpartner is of daadwerkelijk op meerdere locaties verwerkt. Bijzonder relevant zijn model- en embedding-leveranciers, cloudhosting, databases, CDN, monitoring, foutanalyse, support, e-mail en back-up. Voor elke vermelding moet herkenbaar zijn of gegevens worden opgeslagen, alleen worden doorgegeven of door personeel kunnen worden ingezien.

Het wijzigingsproces hoort eveneens thuis in de beoordeling: Hoe worden klanten geïnformeerd, wat is de kennisgevingstermijn en wat gebeurt er bij een gegrond bezwaar? Een e-mail op de dag van de omzetting zonder technisch of contractueel bruikbare handelingsperspectieven heeft weinig waarde. Verhelder of een alternatieve configuratie, het uitschakelen van de functie of desnoods een geordende beëindiging inclusief gegevensexport mogelijk is. Voor verdere subverwerkers moeten dezelfde privacyverplichtingen worden doorgegeven; de eerste verwerker blijft ten opzichte van de verwerkingsverantwoordelijke aansprakelijk voor de nakoming van hun verplichtingen.

Doorgifte naar derde landen: mechanisme en daadwerkelijke werking controleren

Hoofdstuk V van de AVG geldt voor doorgiften van persoonsgegevens naar derde landen en voor verdere doorgiften. Een doorgifte ontstaat niet alleen door permanente opslag; ook administratieve toegang, supporttoegang of het ophalen van gegevens door een dienst buiten de EER kan relevant zijn. Wijs daarom aan elke pijl in de datastroomkaart een bestemmingsland, een ontvanger en een doorgiftemechanisme toe.

1. Adequaatheidsbesluit: Controleer op de doorlopend geactualiseerde lijst van de Europese Commissie of het besluit, het gebied, de sector en de specifieke ontvanger worden gedekt. Bij beperkte kaderregelingen volstaat een enkele vestiging in een land niet.
2. Passende waarborgen: Ontbreekt een passend adequaatheidsbesluit, dan komen afhankelijk van de situatie instrumenten volgens artikel 46 AVG in aanmerking. Veelal worden de standaardcontractbepalingen van de Europese Commissie gebruikt. De module, partijen, bijlagen, doorgiftebeschrijving en technische maatregelen moeten aansluiten op de daadwerkelijke keten.
3. Toetsing van de doeltreffendheid: Een ondertekend SCC-document beëindigt de controle niet automatisch. De definitieve EDPB-aanbevelingen 01/2020 beschrijven een risicogebaseerd proces: doorgiften in kaart brengen, instrument bepalen, wetgeving en praktijk van het derde land beoordelen, eventueel aanvullende maatregelen vastleggen, formele stappen afronden en regelmatig herbeoordelen.

Aanvullende technische maatregelen moeten passen bij het specifieke risico. Versleuteling is bijvoorbeeld alleen betekenisvol als er rekening wordt gehouden met sleutelbeheer, toegangsrechten en het verwerkingsdoel. Een model-leverancier die platte tekst moet verwerken en zelf toegang heeft tot de sleutels, is een andere situatie dan een louter versleutelde back-upopslag. Algemene uitspraken zoals "AES-256" of "AVG-compliant" vervangen deze analyse niet. Uitzonderingen op grond van artikel 49 AVG vormen evenmin een gemakkelijke standaardroute voor geplande, terugkerende SaaS-verwerkingen.

Praktijkvoorbeeld: EU-regio met een wereldwijde dienstenketen

Stel dat een chatbot zijn hoofddatabase in Frankfurt opslaat. De antwoorden worden echter gegenereerd door een model-API van een Amerikaans bedrijf, foutrapporten gaan naar een andere dienst en een wereldwijd supportteam kan bij escalaties gespreksverslagen openen. "Gegevensopslag in de EU" beschrijft dan slechts een deel van het systeem.

Due diligence scheidt vier vragen: Welke inhoud verlaat de EER om modelantwoorden te genereren? Worden daar prompts opgeslagen of voor andere doeleinden gebruikt? Bevatten foutrapporten platte tekst, identificatoren of alleen geminimaliseerde technische gegevens? Onder welke voorwaarden kan support buiten de EER toegang krijgen? Pas daarna kunnen doorgifte-instrumenten, aanvullende maatregelen en restrisico's worden beoordeeld.

Technisch gezien kan de website-eigenaar het risico vaak beperken: onnodige logvelden uitschakelen, gevoelige gegevens vóór externe aanroepen uit de invoer verwijderen, korte bewaartermijnen instellen, gevoelige gedeelten scheiden van de openbare bot, kennisbronnen isoleren per client/tenant en supporttoegang alleen na goedkeuring toestaan en loggen. Hoe een openbare bot en een klantenportaal strikt worden gescheiden, leest u in het artikel Openbare AI-chatbot vs. klantenportaal. Voor geüploade bestanden vult de checklist over bestandscontrole, privacy en handoff de leveranciersbeoordeling aan.

Besluitvorming met een stoplicht in plaats van een onderbuikgevoel

Controlepunt	Groen	Geel	Rood
Datastroom	Volledig, actueel en afgestemd op het afgenomen pakket	Enkele toegangen of opslaglocaties onduidelijk	Alleen marketingbeweringen over de EU-regio
Verwerkersovereenkomst	Doeleinden, gegevens, termijnen en ondersteuning concreet	Aanvullingen nodig vóór go-live	Geen duidelijke gebondenheid aan instructies of verwijdering
Subverwerkers	Namenlijst met land en taak aanwezig	Wijzigingsproces onpraktisch	Alleen categorieën of onbekende keten
Doorgifte naar derde landen	Mechanisme, omvang en beoordeling aangetoond	Maatregelen moeten nog worden geverifieerd	"EU-server" moet alle doorgiften verklaren
Beheer	Owner, reviewdatum en exit getest	Bewijsstukken zonder vaste review	Geen monitoring na het sluiten van de overeenkomst

Een geel punt hoeft niet automatisch nadelig te zijn voor de leverancier. Het vereist echter wel een verantwoordelijke, een deadline en een verifieerbaar acceptatiecriterium. Een rood punt in een centrale verwerkingsketen zou de livegang moeten blokkeren totdat het contract, de configuratie of de leverancierskeuze is aangepast. Documenteer ook geaccepteerde restrisico's en de persoon die deze beslissing heeft genomen.

Compacte go-live checklist voor website-eigenaren

• Datastroomkaart en rollen per doel zijn goedgekeurd.
• Verwerkersovereenkomst en bijlagen komen overeen met het gekozen pakket, de functionaliteiten, het type gegevens en de bewaartermijnen.
• Alle subverwerkers zijn met naam, land, taak en wijzigingsprocedure gedocumenteerd.
• Elke doorgifte naar een derde land heeft een passend, actueel gecontroleerd mechanisme en eventuele aanvullende maatregelen.
• Modeltraining of ander eigen gebruik van chatgegevens is opgehelderd en geconfigureerd zoals overeengekomen.
• Logging, supporttoegang, gegevensexport, verwijdering en einde van het contract zijn in de praktijk getest.
• Privacyverklaring en chat-interface leggen de verwerking begrijpelijk uit; gebruikers worden niet verleid tot het invoeren van onnodige gevoelige gegevens.
• Er is gecontroleerd of er voor de specifieke toepassing een gegevensbeschermingseffectbeoordeling (GEB/DPIA) vereist is.
• Een owner monitort wijzigingen bij subverwerkers, doorgiftemechanismen, functionaliteiten en beveiligingsbewijzen.

Aanvullend is een vergelijking waardevol met het fundamentele overzicht AI-chatbot en AVG, evenals met de handleiding voor databesparende chatbot-analytics. Daarmee worden inkoop, technische configuratie en doorlopend beheer niet als gescheiden projecten behandeld.

Blijven controleren na het sluiten van de overeenkomst

Due diligence is geen eenmalige PDF-map. Stel ten minste een vast review-ritme en gebeurtenisgestuurde controles vast. Aanleidingen hiervoor zijn nieuwe subverwerkers, een andere model-leverancier, nieuwe productfuncties, gewijzigde opslaglocaties, een beveiligingsincident, verlopen certificaten of wijzigingen in een adequaatheidsbesluit. De actuele lijst met subverwerkers en de belangrijkste contractversies moeten met datum worden gearchiveerd, zodat latere wijzigingen navolgbaar blijven.

De praktische maatstaf is eenvoudig: kan uw team voor elke relevante datastroom uitleggen wie wat waarom verwerkt, waar dit gebeurt, hoe lang gegevens blijven staan, welke beveiligingsmaatregel geldt en hoe een exit werkt? Als deze antwoorden zijn onderbouwd, verandert een algemene privacyclaim in een solide inkoopbeslissing. Blijven centrale stations onbekend, dan mag de chatbot nog niet werken met echte bezoekersgegevens.