Datalek bij een AI-koppeling: de 72-uursklok en wat je moet vastleggen

Wat telt eigenlijk als een datalek?

Een datalek is in de wet geen mysterieus begrip. De AVG noemt het een inbreuk in verband met persoonsgegevens en omschrijft dat in artikel 4, onderdeel 12, als een inbreuk op de beveiliging die per ongeluk of op onrechtmatige wijze leidt tot vernietiging, verlies, wijziging, ongeoorloofde verstrekking van of ongeoorloofde toegang tot persoonsgegevens. Drie dingen vallen daarbij op.

• Het hoeft geen hack te zijn. Per ongeluk telt net zo goed als kwaadwillend. Een verkeerd verstuurde mail is een datalek.
• Het hoeft niet om diefstal te gaan. Ook verlies en vernietiging tellen. Als je gespreksgeschiedenis onherstelbaar weg is en je had die nodig, is dat een lek.
• Het gaat om de beveiliging, niet om de schade. Of er iets misgaat voor de klant is een volgende vraag. Die vraag bepaalt of je moet melden, niet of het een datalek is.

Bij een AI-koppeling voor klantcontact zit het risico op een paar heel concrete plekken. De AI-assistent leest mee in een gedeelde mailbox. Hij hangt aan je WhatsApp-nummer. Hij schrijft gespreksverslagen weg in een CRM of in een aparte database. Er is bijna altijd een API-sleutel in het spel, en meestal ook een koppeling met een partij die de taalmodellen draait. Elk van die schakels kan lekken. Een sleutel die in een openbare repository belandt, een testomgeving met echte klantgesprekken erin, een chatvenster dat het antwoord van klant A aan klant B toont: dat zijn geen exotische scenario's, dat zijn de standaardfouten.

Belangrijk voor het vervolg: de wet legt de verantwoordelijkheid bij degene die bepaalt waarvoor en hoe de gegevens worden gebruikt. Dat ben jij, de ondernemer. Niet de leverancier van het AI-systeem. Ook niet als de fout technisch gezien bij die leverancier is gemaakt.

Wanneer begint de 72-uursklok precies te lopen?

Artikel 33, lid 1 AVG zegt dat je een inbreuk meldt zonder onredelijke vertraging en, indien mogelijk, uiterlijk 72 uur nadat je er kennis van hebt genomen. Die laatste vier woorden zijn het hele verhaal. De klok begint niet als het lek ontstaat, en ook niet als je het onderzoek hebt afgerond. De klok begint op het moment dat je er redelijkerwijs van op de hoogte bent.

Praktisch betekent dat: het moment waarop iemand binnen je organisatie het signaal krijgt. Een klant die belt dat hij een verkeerd antwoord met andermans naam erin kreeg. Een leverancier die je mailt over een storing. Een medewerker die ziet dat een exportbestand op de verkeerde plek staat. Vanaf dat signaal heb je een redelijke termijn om vast te stellen of er echt persoonsgegevens bij betrokken zijn — maar je mag dat niet oprekken om de klok later te laten starten. Een korte eerste beoordeling hoort binnen uren, niet binnen weken.

De 72 uur zijn kalenderuren. Geen werkuren, geen werkdagen. Een lek dat vrijdagmiddag om vier uur bij je binnenkomt, moet in beginsel maandagmiddag vier uur gemeld zijn. De Autoriteit Persoonsgegevens is daar uitgesproken over: ben je te laat, dan moet je dat uitleggen, en de toezichthouder accepteert een late melding alleen in uitzonderlijke gevallen. Weekend, vakantie, ziekte of drukte zijn expliciet geen geldige redenen.

Dat is een organisatorisch feit, geen juridisch detail. Als je met vijf man bent en er is één iemand die de systemen kent, dan is je meldproces net zo betrouwbaar als de agenda van die ene persoon. Spreek daarom vooraf af wie er kijkt als hij er niet is, en zorg dat die tweede persoon bij de leverancier terecht kan.

Nog iets uit hetzelfde artikel: als je de informatie niet in één keer compleet krijgt, mag je die gefaseerd aanleveren. Dat is de uitweg voor het meest voorkomende probleem — je weet binnen 72 uur wél dát er iets is gebeurd, maar nog niet precies hoeveel klanten het raakt. Meld dan wat je weet en vul later aan. Wachten tot het onderzoek klaar is, is geen optie.

Moet elk datalek naar de Autoriteit Persoonsgegevens?

Nee. Artikel 33 maakt één uitzondering: melden hoeft niet als het onwaarschijnlijk is dat de inbreuk een risico oplevert voor de rechten en vrijheden van betrokkenen. Dat klinkt als een ruime ontsnapping, maar zo werkt hij niet. De toezichthouder zegt het zo: je moet een risico-inschatting maken om te beslissen of je wel of niet meldt en of je de slachtoffers wel of niet informeert.

De beslissing ligt dus bij jou, en het is een beredeneerde beslissing die je later moet kunnen laten zien. Wat weeg je mee?

• Wat voor gegevens. Een naam en een e-mailadres is iets anders dan een gesprek waarin iemand zijn medische klacht beschrijft aan de chat van een kliniek.
• Hoeveel mensen. Eén klant is niet automatisch geen risico, maar de omvang telt mee.
• Wie kon erbij. Een bestand dat één seconde open stond op een intern netwerk is iets anders dan een index die door een zoekmachine is opgepikt.
• Wat kan er misgaan. Kan iemand hiermee inloggen, iemand oplichten, of iets over een klant onthullen wat hij niet gedeeld wilde hebben?
• Wat had je al geregeld. Waren de gegevens versleuteld en is de sleutel niet meegelekt, dan is het risico feitelijk lager.

De vuistregel voor een ondernemer met weinig tijd: bij twijfel meld je. Een melding die achteraf niet nodig blijkt kost je een halfuur invulwerk. Een gemiste melding is een overtreding van artikel 33 én levert het beeld op dat je de risico's niet in beeld had.

Welke incidenten moet je wel melden en welke niet?

De tabel hieronder zet een aantal situaties op een rij die bij AI-klantcontact daadwerkelijk voorkomen. Let op de laatste kolom: vastleggen doe je altijd, ook als je niet meldt. Daar komt artikel 33, lid 5 om de hoek kijken, en daarover verderop meer.

Veelvoorkomende incidenten rond een AI-koppeling voor klantcontact, naast de vraag of melding bij de Autoriteit Persoonsgegevens en aan de klant nodig is. De uitkomst hangt altijd af van je eigen risico-inschatting.

Incident	Melden bij de toezichthouder	Klant zelf informeren	Vastleggen in eigen overzicht
AI-antwoord bevat gegevens van een andere klant en gaat naar één ontvanger	Meestal wel; afhankelijk van de gevoeligheid van wat er in stond	Alleen bij hoog risico, bijvoorbeeld bij gezondheids- of financiële gegevens	Ja
Export met gespreksgeschiedenis staat onbeveiligd online	Ja	Ja, zodra het hoog risico oplevert voor de betrokkenen	Ja
API-sleutel van de AI-koppeling gedeeld in een openbare omgeving	Ja als er via die sleutel bij klantgegevens gekund kon worden	Afhankelijk van wat er benaderd is en door wie	Ja
Interne mail met klantgegevens naar de verkeerde collega binnen hetzelfde bedrijf	Vaak niet, als de gegevens de organisatie niet verlaten hebben en zijn verwijderd	Meestal niet	Ja
Gespreksdatabase versleuteld, sleutel niet gelekt, back-up intact	Vaak niet; risico is dan doorgaans onwaarschijnlijk	Meestal niet	Ja
Verlies van gegevens: gespreksgeschiedenis onherstelbaar weg, geen back-up	Ja, verlies is ook een inbreuk	Afhankelijk van de gevolgen voor de klant	Ja
Leverancier meldt je een inbreuk in zijn eigen systeem	Jij meldt, niet de leverancier; beoordeling is aan jou	Bij hoog risico, en dan door jou	Ja

De tabel is een hulpmiddel, geen uitspraak. Twee incidenten die er hetzelfde uitzien kunnen anders uitpakken omdat de gegevens anders zijn. Schrijf daarom altijd op waarom je tot je conclusie kwam.

Wat moet er in de melding staan?

Artikel 33, lid 3 AVG somt op wat een melding minimaal bevat. Vier onderdelen, en ze zijn allemaal te beantwoorden zonder jurist:

1. De aard van de inbreuk. Wat is er gebeurd, om welke soorten gegevens gaat het, om welke categorieën mensen, en bij benadering om hoeveel personen en hoeveel records. Bij benadering — je hoeft geen exact getal.
2. Een contactpunt. De naam en contactgegevens van de functionaris voor gegevensbescherming, of van een ander punt waar meer informatie te krijgen is. Heb je geen functionaris, dan noem je degene die het dossier bij je beheert.
3. De waarschijnlijke gevolgen. Wat kan dit betekenen voor de mensen om wie het gaat.
4. De maatregelen. Wat je hebt gedaan of gaat doen om het lek te dichten en de gevolgen te beperken.

Bij een AI-koppeling verdient punt vier extra aandacht. Het dichten van een lek betekent daar vaak: de sleutel intrekken en vervangen, de koppeling tijdelijk uitzetten, de gelekte kopie laten verwijderen bij de partij die hem heeft, en nagaan of gegevens die je aan een taalmodel hebt gestuurd daar ergens bewaard zijn gebleven. Dat laatste kun je alleen beantwoorden als je vooraf weet hoe je leverancier met gegevens omgaat. Wie dat pas op dag één van een lek gaat uitzoeken, haalt de 72 uur niet.

Krijg je het niet compleet? Meld dan wat je hebt, meld dat het onderzoek loopt, en lever de rest gefaseerd na. Dat mag volgens hetzelfde artikel uitdrukkelijk.

Wanneer moet je de klant zelf ook informeren?

Melden bij de toezichthouder is niet hetzelfde als het aan je klanten vertellen. Artikel 34 AVG zegt dat je de betrokkene zelf informeert wanneer de inbreuk waarschijnlijk een hoog risico inhoudt voor zijn rechten en vrijheden. De drempel ligt hoger dan bij de melding aan de toezichthouder: daar gaat het om "een risico", hier om "een hoog risico".

Wat betekent dat in de praktijk van klantcontact? Denk aan gesprekken waarin klanten dingen vertellen die ze niet openbaar zouden zetten. Een AI-chat bij een kliniek waarin klachten worden beschreven. Een WhatsApp-lijn van een schuldhulpverlener. Een mailbox waar mensen kopieën van documenten naartoe sturen. Als die inhoud bij een onbekende derde terechtkomt, is de kans op een hoog risico groot. Gaat het om een lijstje met alleen voornamen en de vraag "hoe laat ben je open", dan is die kans klein.

De mededeling aan de klant moet in duidelijke en eenvoudige taal, en bevat in elk geval dezelfde kern als de melding: wat er is gebeurd, wat de waarschijnlijke gevolgen zijn, welke maatregelen je neemt, en waar hij terecht kan met vragen. Artikel 34, lid 3 kent uitzonderingen — onder meer wanneer de gegevens versleuteld en daardoor onbegrijpelijk waren, wanneer je achteraf maatregelen hebt genomen waardoor het hoge risico zich niet meer kan voordoen, of wanneer individueel informeren onevenredig veel moeite kost en je in plaats daarvan een openbare mededeling doet.

Een waarschuwing over die uitzonderingen: ze zijn bedoeld voor gevallen waarin het risico echt is weggenomen, niet voor gevallen waarin je liever geen mail wilt sturen. Als je je op een uitzondering beroept, schrijf dan op waarom die opgaat.

Waarom moet je ook lekken vastleggen die je niet meldt?

Dit is het onderdeel dat in het MKB het vaakst vergeten wordt. Artikel 33, lid 5 AVG bepaalt dat je alle inbreuken documenteert: de feiten rond de inbreuk, de gevolgen ervan en de genomen corrigerende maatregelen. Niet alleen de gemelde. Ook het incident waarvan je na een half uur concludeerde dat er geen risico was.

De reden is eenvoudig. Je beslissing om niet te melden is zelf een beslissing waarvoor je verantwoording aflegt. Zonder vastlegging is die beslissing niet te controleren en dus ook niet te verdedigen. Het overzicht dient een tweede doel dat je zelf merkt: patronen. Drie keer per kwartaal hetzelfde soort fout in dezelfde koppeling is geen ongeluk meer, dat is een ontwerpprobleem.

Zo'n overzicht hoeft geen systeem te zijn. Een tabel volstaat, mits per incident in elk geval het volgende erin staat:

• datum en tijdstip waarop je het signaal kreeg, en van wie;
• wat er is gebeurd en welke systemen en koppelingen erbij betrokken waren;
• welke soorten gegevens en welke categorieën mensen, en bij benadering hoeveel;
• je risico-inschatting, met de redenering erbij;
• de beslissing: wel of niet melden bij de toezichthouder, wel of niet de klant informeren, en waarom;
• wat je direct hebt gedaan en wat je structureel hebt aangepast;
• wie het heeft afgehandeld.

Die vijfde regel is de belangrijkste. Zonder de redenering is het geen dossier maar een logboek.

Wat als het lek bij je AI-leverancier zit?

Dit is het meest waarschijnlijke scenario bij een AI-koppeling, want je draait de techniek meestal niet zelf. De rolverdeling is dan als volgt: je bent verwerkingsverantwoordelijke, de leverancier is verwerker. Artikel 33, lid 2 AVG legt de verwerker één plicht op: hij informeert je zonder onredelijke vertraging zodra hij kennis heeft genomen van een inbreuk. Hij meldt niet bij de toezichthouder. Dat doe jij.

Daar zit een praktisch gevaar in. Jouw 72 uur beginnen te lopen op het moment dat je het weet. Als je leverancier er drie dagen over doet om je te bereiken, ben je niet automatisch te laat — maar je bent wel afhankelijk van iemand anders voor het startsein. Daarom moet dit in het contract staan.

Artikel 28 AVG eist dat de verwerking door een verwerker wordt geregeld in een overeenkomst die de verwerker aan jou bindt en waarin onder meer het onderwerp, de duur, de aard, het doel en de soorten gegevens zijn vastgelegd. Diezelfde bepaling verplicht de verwerker om je bij te staan bij het nakomen van je verplichtingen rond datalekken en beveiliging. Vertaal dat naar afspraken die je kunt gebruiken op de dag dat het misgaat:

• een concrete meldtermijn richting jou, uitgedrukt in uren, niet "zo spoedig mogelijk";
• een vast contactpunt en een kanaal dat ook in het weekend werkt;
• de plicht om je de informatie te leveren die artikel 33, lid 3 van je vraagt: aard, aantallen, gevolgen, maatregelen;
• een verbod om zonder jouw opdracht namens jou met klanten of de toezichthouder te communiceren;
• duidelijkheid over onderaannemers, want de partij die het taalmodel draait is vaak weer een andere partij;
• de afspraak dat je logbestanden krijgt die laten zien wie wanneer bij welke gegevens kon.

Let op: de Autoriteit Persoonsgegevens wijst erop dat de AVG een verwerkersovereenkomst eist van beide partijen, en dat beide aansprakelijk zijn als die overeenkomst ontbreekt. Je kunt dus niet zeggen dat de leverancier het had moeten regelen.

Hoe maak je de 72 uur haalbaar voordat er iets gebeurt?

De 72-uursklok is niet moeilijk omdat de regel ingewikkeld is. Hij is moeilijk omdat er onder tijdsdruk vier dingen tegelijk moeten gebeuren: uitzoeken wat er is, dichten, beoordelen en melden. Alles wat je vooraf regelt, hoef je dan niet te bedenken.

1. Weet waar de gegevens staan. Welke koppelingen heeft de AI-assistent, welke systemen schrijft hij naar, en wie is daar de leverancier van. Zonder dat overzicht kun je de aard en de omvang niet beschrijven.
2. Beperk vooraf wat er kan lekken. Een assistent die alleen ziet wat hij voor het antwoord nodig heeft, lekt bij een fout minder. Dat is een beveiligingsmaatregel, en die weegt mee in je risico-inschatting.
3. Leg één meldadres binnen je bedrijf vast. Eén e-mailadres of nummer waar medewerkers en leveranciers een vermoeden melden. Zo is er geen discussie over wanneer je kennis had.
4. Wijs een tweede persoon aan. De klok stopt niet voor vakantie of ziekte, dus je proces mag niet op één agenda leunen.
5. Maak het formulier vooraf een keer leeg door. Wie de vragen kent, verzamelt tijdens een incident meteen de juiste dingen.
6. Houd het overzicht bij vanaf dag één. Ook voor de kleine dingen. Achteraf reconstrueren lukt niet.

En bewaar de eerste signalen. Screenshots, e-mails, tijdstempels. Bij de vraag "wanneer had je er kennis van" is je eigen administratie het enige bewijs dat je hebt.

De drie fouten die het duurst uitpakken

De eerste is de klok te laat laten beginnen. Ondernemers wachten met melden tot ze het complete beeld hebben, terwijl de wet gefaseerd melden juist toestaat. De tweede is denken dat de leverancier het meldt. Dat doet hij niet: hij meldt aan jou, jij meldt aan de toezichthouder. De derde is niet vastleggen wat je niet meldt. Dat maakt van een verdedigbare beslissing een onverklaarbaar gat.

Wat je hier leest is algemene uitleg over de wet en geen juridisch advies. Of je in je situatie moet melden, hangt af van feiten die alleen jij kent. Bij twijfel over een concreet incident: laat het beoordelen door iemand die je situatie kent, en laat de klok ondertussen doorlopen in je eigen tijdlijn.