Vendor- en compliancekaders (GDPR/DORA)

Een handige AI-tool… maar wie tekent mee?

Je organisatie (bank of verzekeraar in het groot mkb) wil sneller werken met AI: klantmails herschrijven, KYC-notities structureren, interne rapportjes samenvatten. Iemand kiest “even” een populaire AI-leverancier, zet een bedrijfsaccount aan, en binnen een week draait het mee in dagelijkse processen. Pas later komt de vraag van Risk/Compliance: waar staat de data, wie kan erbij, hoe lang blijft het bewaard, en wat als de leverancier uitvalt of een incident heeft?

Dit onderwerp is juist nu belangrijk omdat AI-gebruik vaak buiten de bestaande keten valt: niet via het DMS/CRM met bekende autorisaties, maar via chats, plug-ins, aparte admin-portals en (soms) wereldwijde subverwerkers. Dat botst snel met toezichteisen en met wat je intern al probeert te borgen via dataminimalisatie, redactie en bewustzijn van logging. Vendor- en compliancekaders geven je een manier om die dagelijkse AI-praktijk “contractueel en aantoonbaar” te maken, zodat je niet achteraf hoeft te repareren.

In deze les leer je hoe je twee grote kaders voor AI-gebruik praktisch leest en toepast: AVG/GDPR (privacy en gegevensverwerking) en DORA (digitale operationele weerbaarheid). Je gebruikt ze als checklijst voor leverancierskeuze én voor het inrichten van veilige AI-werkafspraken.

Twee kaders, één doel: controle houden over data én service

We gebruiken een paar definities die je straks direct herkent in contracten en vragenlijsten:

• Vendor (leverancier): de partij die de AI-dienst levert (SaaS, API, platform). In de keten kunnen ook subverwerkers zitten (hosting, logging, support).

• Verwerkingsverantwoordelijke / verwerker (AVG): jouw organisatie bepaalt het doel en de middelen (verantwoordelijke); de leverancier verwerkt namens jou (verwerker). Soms is de leverancier (deels) ook zelfstandig verantwoordelijke—dat wil je expliciet hebben.

• DPA (Data Processing Agreement / verwerkersovereenkomst): contractuele afspraken over verwerking, beveiliging, subverwerkers, rechten van betrokkenen, incidentmelding, audits.

• DORA: EU-regelgeving die eist dat financiële entiteiten hun ICT-risico’s, incidenten, uitbesteding en weerbaarheid aantoonbaar beheersen, inclusief kritieke derde partijen en ketenrisico’s.

• Content vs. metadata: bij AI gaat het niet alleen om “de tekst die je invoert”, maar ook om prompts, outputs, conversatiegeschiedenis, tool-instellingen en gebruikslogs. In de vorige les zag je al dat die logginglaag zomaar een extra datacontainer wordt.

Een nuttige manier om het verschil te onthouden: AVG gaat over “mag dit en hoe bescherm je mensen en gegevens?” DORA gaat over “blijft dit betrouwbaar werken, ook als het misgaat, en kun je dat bewijzen?” In de praktijk komen ze samen bij dezelfde kern: je moet weten welke data waarheen gaat, wie erbij kan, hoe lang het blijft, en wat je doet bij incidenten.

GDPR/AVG: AI-leverancier = (bijna altijd) een verwerker, dus je moet sturen

Bij AI in de financiële sector is de eerste valkuil dat mensen alleen kijken naar een marketingzin als “we trainen niet op jouw data”. Dat is relevant, maar het is niet de kern. De kern onder de AVG is: welke persoonsgegevens verwerk je, met welk doel, op welke grondslag, en met welke waarborgen? In AI-werk zie je bovendien een extra probleem uit de vorige les terug: mensen stoppen onbedoeld te veel in de prompt (micro-dossier), en die content kan daarna in logs, supporttickets of conversatiegeschiedenis terugkomen. Als dat persoonsgegevens zijn (en dat zijn ze vaak, ook na pseudonimisering), dan valt de hele keten onder AVG-regels.

Een tweede misvatting: “We pseudonimiseren, dus het is geen persoonsgegeven meer.” In veel bank- en verzekeringssituaties blijft data intern herleidbaar door dossiernummers, productcombinaties, datums, bedragen en context (het mozaïek-effect). Pseudonimisering is dus een beveiligingsmaatregel, geen vrijbrief. Dat betekent dat je in je vendor-afspraken moet borgen dat de leverancier jouw instructies volgt: alleen verwerken voor jouw doel, geen eigen hergebruikdoelen, en duidelijke grenzen rond opslag, ondersteuning en toegang.

Wat hoort er dan minimaal in een AI-geschikte DPA? Denk in vier blokken. (1) Doel en datacategorieën: benoem expliciet dat prompts, outputs en logs onder de verwerking kunnen vallen. (2) Beveiliging en toegangsmodel: wie kan content inzien (admins, support), hoe wordt het versleuteld, en welke scheiding is er tussen tenants. (3) Subverwerkers en locaties: welke partijen draaien hosting, analytics, support, en waar (datatransfers buiten de EU). (4) Rechten en incidenten: ondersteuning bij inzage/verwijdering, bewaartermijnen, en meldplichten bij datalekken. Merk op dat dit precies aansluit op je dagelijkse prompt-hygiëne: hoe minder gevoelige content je aanlevert, hoe kleiner de compliance-“blast radius” als er tóch iets gelogd of ingezien wordt.

DORA: AI als uitbesteding betekent sturen op beschikbaarheid, incidenten en exit

DORA wordt vaak verkeerd geïnterpreteerd als “alleen voor IT-afdeling”. In werkelijkheid raakt het iedereen die een AI-dienst inzet in kernprocessen: claims, acceptatie, KYC, klantcontact, rapportage. Zodra een AI-vendor onderdeel wordt van je dagelijkse operatie—zeker als medewerkers er klantdossiers doorheen laten lopen—dan heb je te maken met ICT third-party risk. DORA vraagt niet alleen “is het veilig?”, maar ook: kunnen we doorwerken bij storing, zien we incidenten op tijd, en kunnen we de leverancier vervangen zonder chaos?

In AI-context is vooral het verschil tussen functionaliteit en kritikaliteit belangrijk. Een tool kan functioneel “handig” zijn (mail herschrijven), maar toch kritisch worden als het breed in klantprocessen wordt gebruikt of als het de enige route wordt voor bepaalde taken. DORA dwingt je dan om na te denken over continuïteit: wat gebeurt er als de dienst 48 uur niet beschikbaar is, of als de vendor plotseling zijn voorwaarden wijzigt? Ook de keten telt mee: welke subverwerkers leveren hosting, identity, monitoring? Als één schakel faalt, valt jouw proces stil.

Concreet vertaalt DORA zich bij vendorselectie en inrichting naar drie stevige vragen. (1) Incident & monitoring: hoe krijg je signalen (alerts), hoe snel wordt een incident gemeld, en wat staat er in de post-mortem. (2) Weerbaarheid: back-up/restore, redundantie, change management, en aantoonbare testen. (3) Exit: data-export, migratiepad, verwijdering, en het voorkomen van vendor lock-in. Dit haakt direct in op wat je al weet over logging: als je contentlogs opslaat bij de leverancier, moet je die ook kunnen exporteren (voor onderzoek) én verwijderen (retentie/AVG). DORA en AVG trekken hier aan dezelfde knop, maar vanuit een ander risico.

Een simpele beslisroute: van “mag dit?” naar “kunnen we dit dragen?”

Je hoeft niet elk artikel van AVG of elke DORA-eis uit het hoofd te kennen om in de praktijk scherp te handelen. Wat je wél nodig hebt is een vaste volgorde van denken, zodat je niet blijft hangen in losse vragen (“Is dit veilig?”) maar uitkomt bij aantoonbare keuzes (“Dit is de inrichting, dit zijn de afspraken, dit is het alternatief”).

1. Classificeer de use case: gaat het om klantdata, KYC/claimdetails, of zelfs bijzondere persoonsgegevens? Dan is de lat hoger en kan “generieke AI-chat” al ongeschikt zijn.
2. Bepaal de datastroom: wat gaat er in (prompt/bijlage), wat komt eruit (output), en wat blijft achter (contentlogs, metadata, exports).
3. Kies de vendor-setup: welke tenant, welk retentiebeleid, welke admin-rollen, welke subverwerkers—en in welke regio.
4. Leg het vast: verwerkersovereenkomst (AVG) plus uitbestedings- en continuïteitsafspraken (DORA).
5. Operationaliseer: afspraken vertalen naar dagelijkse werkwijze (prompt-hygiëne, redactie, “assume it’s logged”) en naar beheer (monitoring, incidentprocedure, exit-test).

[[flowchart-placeholder]]

Deze route sluit aan op de vorige les: prompt-hygiëne en redactie verminderen niet alleen het datarisico, maar maken je ook sterker in vendor-gesprekken. Een leverancier kan veel beloven, maar als jouw organisatie structureel micro-dossiers in prompts stopt, vergroot je de impact van elk incident en wordt compliance duurder.

Voorbeeld 1: Bank — KYC-samenvattingen via AI, zonder dat de vendor je “tweede dossier” wordt

Een bank in het groot mkb wil relatiebeheerders KYC-overdrachten sneller laten schrijven. In de praktijk willen mensen complete KYC-rapporten plakken: UBO-gegevens, risicosignalen, documentstatus en soms transactiemonitoring-tekst. Vanuit AVG is dat meteen gevoelig: persoonsgegevens (UBO’s) en mogelijk interne kwalificaties. Vanuit DORA ontstaat daarnaast een operationeel risico: als de AI-tool uitvalt, ligt het overdrachtsproces stil; als de vendor logs bewaart, ontstaat een tweede bron van KYC-informatie buiten de gecontroleerde systemen.

Stap voor stap pak je dit vendor- en complianceproof aan. Eerst beschrijf je de verwerking in gewone taal: “AI helpt bij tekststructuur en formulering; brondata blijft in KYC-systeem; prompts bevatten alleen minimale, geredigeerde feiten.” Daarna borg je dit contractueel en technisch: in de DPA leg je vast dat prompts/outputs niet voor eigen doelen worden gebruikt en dat contentretentie uit kan of strak begrensd is. DORA-achtig kijk je naar continuïteit: wat is de fallback als de tool down is (template in Word/CRM), en hoe exporteer je eventueel benodigde auditinformatie zonder dat je contentlogs een privacybom maakt.

In de dagelijkse uitvoering betekent dit: de medewerker gebruikt placeholders ([UBO_1], [Klant_A]), generaliseert tijd (“laatste 90 dagen”) en zet guardrails (“geen aannames, markeer onbekend”). Het effect is dat je nog steeds tijdwinst haalt, maar je voorkomt dat de leverancier een schaduwadministratie van KYC-teksten opbouwt. De beperking blijft dat AI-output conceptmatig is: je controleert altijd tegen het KYC-systeem, en je gebruikt AI niet als bron voor risicobesluiten.

Voorbeeld 2: Verzekeraar — claimcommunicatie met medische context: AVG strikt, DORA praktisch

Een verzekeraar wil claimbehandelaars helpen met klantvriendelijke, consistente e-mails. In arbeidsongeschiktheidsclaims zit al snel medische informatie; dat zijn bijzondere persoonsgegevens met hoge impact bij fout gebruik. De verleiding is groot om “even de hele mailwisseling” te plakken en te vragen om een herschrijving. Vanuit AVG is dat vaak onacceptabel, zeker als de AI-tool conversatiegeschiedenis bewaart of als support inzage kan krijgen. Vanuit DORA speelt iets anders mee: als deze AI-schrijfhulp een standaard onderdeel van het proces wordt, moet je ook regie hebben op incidenten, wijzigingen in de tool (bijv. retentie-defaults) en een exit als de leverancier niet meer past.

Een werkbare inrichting start met een scherpe afbakening van de use case. Je gebruikt AI alleen op toon, structuur en standaardzinnen, niet op medische inhoud. In vendor-voorwaarden laat je expliciet vastleggen dat content niet wordt hergebruikt en dat je retentie en logging kunt sturen. Operationeel regel je dat medewerkers geen medische passages in prompts zetten en dat ze alleen neutrale statusinformatie gebruiken (“beoordeling loopt”, “ontvangst stukken bevestigd”, “doorlooptijd volgens norm”), waarna ze in het claimsysteem handmatig de noodzakelijke referenties invoegen.

De impact is groot: je reduceert het risico dat medische details in contentlogs terechtkomen, terwijl je toch consistentere communicatie krijgt en minder escalaties door onduidelijke mails. De beperking is dat je soms minder “persoonlijk” schrijft, maar dat is in claims vaak een voordeel: minder detail betekent minder kans op onbedoelde verspreiding, verkeerde interpretatie of juridisch ongelukkige formuleringen. Zo werken AVG en DORA samen: privacybescherming door minimalisatie, en procesweerbaarheid door duidelijke vendor-regie en fallback.

Een checklist die je echt gebruikt in vendor-gesprekken

Als je met Procurement, IT of Compliance aan tafel zit, helpen deze vragen om snel de kern boven tafel te krijgen. Ze sluiten direct aan op prompt-hygiëne, redactie en logging uit de vorige les.

• Data in/uit/achterblijvend: Worden prompts/outputs opgeslagen? Kunnen we contentlogging beperken? Wat is de standaard retentie?

• Menselijke inzage: Kan vendor-support content zien? Hoe werkt “break glass”-toegang en wordt dat gelogd?

• Subverwerkers en locatie: Wie host, wie monitort, wie doet support, en waar staat de data?

• Incident & melding: Hoe snel horen we het? Welke informatie krijgen we? Wat is het proces voor forensisch onderzoek zonder onnodige datadeling?

• Exit: Kunnen we alles exporteren, migreren en aantoonbaar verwijderen? Is er een plan dat ook echt getest wordt?

A checklist you can trust

• Prompt-hygiëne en redactie verlagen niet alleen datarisico, maar maken vendor-afspraken haalbaar: minder gevoelige content betekent minder complexe (en minder risicovolle) logging- en retentie-eisen.

• AVG/GDPR dwingt helderheid af over rolverdeling, doelbinding, subverwerkers, bewaartermijnen en rechten van betrokkenen—ook voor prompts, outputs en metadata.

• DORA maakt AI-vendors een weerbaarheidsvraagstuk: incidenten, monitoring, ketenrisico en een realistische exit zijn net zo belangrijk als functionaliteit.

• De praktische winst zit in aantoonbaarheid: je kunt uitleggen waarom een AI-use-case mag, hoe data stroomt, en wat je doet als het misgaat.

Als je deze kaders consequent toepast, verandert AI van “snelle tool” naar een beheerst onderdeel van je dienstverlening: efficiënt waar het kan, strikt waar het moet, en verdedigbaar bij audit, klanten en toezichthouders.