Een AI-agent logt in met geldige inloggegevens en wijzigt klantdata: de AEPD-melding van 14 september 2026, uw inloggegevensclausule, artikel 32 AVG en de exoneratie in uw SaaS-contract

Op 14 september 2026 publiceerde de Spaanse toezichthouder voor gegevensbescherming, de AEPD, een bericht dat elke ondernemer met een klantportaal, een boekhoudpakket in de cloud of een CRM-abonnement zou moeten lezen. Een organisatie had een inbreuk gemeld waarbij de aanval volgens haar eigen melding was uitgevoerd door een AI-agent die een bekend taalmodel gebruikte; het is de eerste melding van dat type die de AEPD heeft ontvangen. De volgorde is het opvallende: de agent zocht eerst naar zwakke plekken in algemene bestanden, logde vervolgens correct in, en ging daarna binnen de applicatie zelfstandig verder zoeken tot hij persoonsgegevens kon wijzigen en facturen kon inzien. Voor het contractenrecht is dat een nieuwe situatie in een oud jasje: de login was geldig, de zoektocht daarna niet.

Halfopen stalen archiefkastdeur met een elektronisch kaartslot in het midden: een blanco toegangspas aan een oranje keycord steekt in het slot, het lampje staat op groen, en door de kier liggen donkergroene factuurmappen scheef in de kast

Stel dat hetzelfde gebeurt bij een Nederlands bedrijf dat zijn klantportaal of administratie bij een SaaS-leverancier afneemt. Wie de schade dan draagt, staat in drie teksten die zelden samen worden gelezen: de inloggegevensclausule in de voorwaarden van uw softwareleverancier, de beveiligingsplicht van artikel 32 AVG die op u én op uw leverancier rust, en de exoneratie die de leverancier voor "handelen van derden" heeft opgenomen. Hieronder staat wat de AEPD precies meldde, waarom die ene clausule over inloggegevens bij een aanval in twee fasen twee kanten op werkt, en welke vijf vragen u aan uw contract stelt voordat u de volgende factuur voor de dienst betaalt.


Wat de AEPD op 14 september 2026 meldde: een geldige login, daarna een autonome zoektocht in de applicatie

Het bericht van de AEPD, geschreven door Francisco Pérez Bes, is zorgvuldig in wat het wel en niet zegt. De informatie komt uit de melding van de getroffen organisatie en moet nog worden onderzocht. Het gebruik van een bepaald AI-model betekent volgens de toezichthouder niet dat dat model of de infrastructuur van de aanbieder gecompromitteerd was, en evenmin dat het instrument voor kwaadaardig gebruik is ontworpen. Wat volgens de AEPD telt, is dat een derde een AI-agent als instrument heeft gebruikt om de verschillende fasen van een aanval aan elkaar te knopen: een agent krijgt een doel, plant tussenstappen, gebruikt hulpmiddelen, voert code uit, leest resultaten en past zijn gedrag aan op wat hij vindt.

De toezichthouder verbindt daar vier gevolgen aan die rechtstreeks in een Nederlands leverancierscontract thuishoren. Ten eerste moeten risicoanalyses van verwerkingen aanvallen met of door AI uitdrukkelijk opnemen; een algemene verwijzing naar malware, phishing of ongeautoriseerde toegang volstaat niet meer, omdat automatisering de kans, de snelheid en de omvang van een incident verandert. Ten tweede moeten reactietijden opnieuw worden bekeken, want een agent test tegelijk meerdere toegangswegen. Ten derde worden digitale identiteiten en inloggegevens, API-sleutels en tokens met te ruime rechten belangrijker: een agent die er één bemachtigt, werkt op machinesnelheid door naar andere diensten. Ten vierde kan de beveiliging van verwerkingen niet alleen op handmatig ingrijpen rusten; detectie en insluiting moeten snel genoeg zijn. De AEPD verwijst daarbij naar de gids BP/36 van het Spaanse Centro Criptológico Nacional over offensieve AI.


De inloggegevensclausule: waarom "alles via uw account is voor uw rekening" bij een aanval in twee fasen twee kanten op werkt

Vrijwel elke SaaS-, hosting- of licentieovereenkomst bevat een bepaling in deze trant: de klant is verantwoordelijk voor het geheimhouden van gebruikersnamen en wachtwoorden, en alles wat via het account van de klant gebeurt, wordt aan de klant toegerekend. Op de eerste fase van zo'n incident is die clausule geschreven: een aanvaller die met bestaande inloggegevens binnenkomt. Hoe die gegevens in Spanje in handen van de agent zijn gekomen, zegt de AEPD niet, en dat is precies de vraag die in een Nederlands geschil als eerste op tafel ligt. Zijn de gegevens aan de kant van de klant gelekt of hergebruikt, dan ligt de clausule waar zij hoort; zijn zij uit de systemen van de leverancier zelf afkomstig, dan helpt de clausule de leverancier weinig.

De tweede fase vraagt een eigen beoordeling. Eenmaal binnen zocht de agent volgens de melding zelfstandig naar zwakke plekken in de applicatie en vond er een die het mogelijk maakte gegevens te wijzigen en facturen in te zien. Als die wijziging buiten de rechten van het gebruikte account viel, benutte de agent een gebrek in de software en niet het account. Of de inloggegevensclausule ook die fase dekt, is een uitlegvraag. Daarvoor geldt de maatstaf van de Hoge Raad van 13 maart 1981 in het arrest Haviltex: het komt aan op de zin die partijen in de gegeven omstandigheden over en weer redelijkerwijs aan de bepaling mochten toekennen en op wat zij daarover redelijkerwijs van elkaar mochten verwachten. Daarbij wegen de tekst van de clausule, het overeengekomen beveiligingsniveau, de rol van de klant bij het beheer van accounts en rechten, en het oorzakelijk verband tussen de login en de uiteindelijke schade. Een clausule over het geheimhouden van wachtwoorden pleit er in de regel niet voor dat de klant ook kwetsbaarheden in de code van de leverancier draagt; een leverancier die dat wel wil, doet er goed aan het uitdrukkelijk op te nemen, zodat de klant weet waarvoor hij tekent.

Een applicatie waarin een ingelogde gebruiker met een gewone account de gegevens van anderen kan wijzigen, beantwoordt daarnaast in de regel niet aan wat de klant op grond van de overeenkomst mocht verwachten. Wat u bij software precies mag verwachten en hoe u dat vastlegt, staat in de eerdere JAVB-post over artikel 7:17 BW en de acceptatietest; een gebrek van dat type valt onder een gewone conformiteitsafspraak. Partijen kunnen het contractuele prestatieniveau en hun onderlinge schadeverdeling regelen; de verplichting tot passende beveiliging van artikel 32 AVG kunnen zij niet wegcontracteren, die blijft op beiden rusten.


Artikel 32 en 28 lid 3 onder c AVG: de beveiligingsplicht rust op beide partijen, en de AEPD vult nu in wat "passend" is

Artikel 32 lid 1 AVG verplicht de verwerkingsverantwoordelijke én de verwerker om, rekening houdend met de stand van de techniek, de uitvoeringskosten en de risico's van de verwerking, passende technische en organisatorische maatregelen te treffen. Artikel 28 lid 3 onder c AVG maakt die plicht bovendien tot een verplicht onderdeel van uw verwerkersovereenkomst. De vier punten van de AEPD zijn een signaal van een toezichthouder, geen Nederlandse norm; wat in Nederland "passend" is, bepalen de Autoriteit Persoonsgegevens en de rechter aan de hand van het concrete risico. Het Hof van Justitie besliste op 14 december 2023 in de zaak C-340/21 bovendien dat een geslaagde aanval door derden op zichzelf niet bewijst dat de maatregelen ontoereikend waren; de verwerkingsverantwoordelijke moet wel kunnen aantonen dat zijn maatregelen passend waren. Juist daarom is het verstandig de vier punten in de beveiligingsbijlage van uw verwerkersovereenkomst te benoemen: de rechten van API-sleutels en servicetokens, de reactietijd bij een aanval op machinesnelheid en detectie buiten kantooruren zijn dan afspraken waarop u elkaar kunt aanspreken, en documentatie die u bij een onderzoek kunt overleggen.

Voor de melding geldt het bekende schema. Een ongeoorloofde wijziging van persoonsgegevens als gevolg van een beveiligingsinbreuk is een inbreuk in verband met persoonsgegevens in de zin van artikel 4 onder 12 AVG, ook als er niets naar buiten is gelekt: de definitie noemt de wijziging van gegevens uitdrukkelijk naast verlies en ongeoorloofde toegang. Uw leverancier moet u als verwerker op grond van artikel 33 lid 2 AVG zonder onredelijke vertraging informeren; u meldt vervolgens op grond van artikel 33 lid 1 AVG zonder onredelijke vertraging en waar mogelijk binnen 72 uur na kennisneming bij de Autoriteit Persoonsgegevens, tenzij het onwaarschijnlijk is dat de inbreuk een risico voor de rechten en vrijheden van betrokkenen inhoudt. Die 72 uur beginnen dus pas te lopen als u het weet, en daar zit de rol van uw leverancier. Hoe die meldketen in uw contract hoort te staan, en wat er gebeurt als uw leverancier zelf AI-functies inschakelt, kwam eerder aan bod in de post over artikel 28 lid 2 AVG en het wijzigingsbeding.


De exoneratie voor "handelen van derden" getoetst aan artikel 6:74, 6:75 en 6:248 lid 2 BW

Veel leveranciersvoorwaarden sluiten aansprakelijkheid uit voor schade door onrechtmatig handelen van derden, waaronder inbraak in systemen. Bij een aanval als de Spaanse is de vraag of het handelen van de derde de tekortkoming van de leverancier wegneemt. Artikel 6:74 BW verplicht tot schadevergoeding bij iedere tekortkoming, tenzij die de schuldenaar niet kan worden toegerekend; artikel 6:75 BW zegt wanneer dat laatste het geval is: als de tekortkoming niet aan zijn schuld is te wijten en evenmin krachtens wet, rechtshandeling of in het verkeer geldende opvattingen voor zijn rekening komt. Een kwetsbaarheid in de eigen applicatie waardoor een ingelogde gebruiker de gegevens van anderen kan wijzigen, zal in de regel een tekortkoming zijn die de leverancier wordt toegerekend; hoe zwaar dat weegt, hangt af van het overeengekomen beveiligingsniveau, van het oorzakelijk verband tussen het gebrek en de schade en van een eventueel eigen aandeel van de klant, bijvoorbeeld in het beheer van de inloggegevens (artikel 6:101 BW). Dat een derde de kwetsbaarheid heeft gevonden, neemt de toerekening niet zonder meer weg: zij zat al in de applicatie voordat de agent haar vond.

Een exoneratie kan dat risico contractueel wel bij de klant leggen, maar kent twee grenzen. Tegen een klant die zich op artikel 6:233 onder a BW kan beroepen, kan de bepaling onredelijk bezwarend zijn; artikel 6:235 lid 1 BW sluit die weg voor grote ondernemingen af. Voor iedereen geldt artikel 6:248 lid 2 BW: een beroep op de exoneratie blijft achterwege als dat naar maatstaven van redelijkheid en billijkheid onaanvaardbaar is. De Hoge Raad heeft die grens onder meer in het arrest van 12 december 1997 (Gemeente Stein/Driessen) verbonden aan opzet of bewuste roekeloosheid van de schuldenaar of zijn leidinggevenden, en beoordeelt daarnaast alle omstandigheden van het geval, zoals de aard van de overeenkomst, de verhouding tussen partijen en de mate van schuld. Hoe lang een leverancier een bekende kwetsbaarheid heeft laten liggen, is een van die omstandigheden, geen zelfstandig bewijs van bewuste roekeloosheid; de JAVB-post over het vijf jaar oude lek beschrijft hoe u die achterstand in uw contract zichtbaar maakt.

Hier zit ook de verbinding met het AI-karakter van de aanval. De AEPD schrijft dat AI de snelheid, de schaal en het aanpassingsvermogen van bekende aanvalstechnieken vergroot en dat de tijd om een aanval te ontdekken en in te dammen daardoor krimpt. Voor de vraag of een tekortkoming krachtens in het verkeer geldende opvattingen voor rekening van de leverancier komt (artikel 6:75 BW), kan meewegen wat op het moment van de aanval bekend was over dit type risico. Een openbaar bericht van een Europese toezichthouder is daarbij een van de gegevens die een rechter kan betrekken; het bepaalt de Nederlandse verkeersopvatting niet op zichzelf. Wie zijn beveiligingsafspraken vastlegt met verwijzing naar dat soort bekende risico's, maakt de discussie daarover later kleiner.


Vijf vragen aan uw leverancierscontract voordat u de volgende factuur voor de dienst betaalt

  1. Waar eindigt de inloggegevensclausule? Staat er dat de klant aansprakelijk is voor alles wat via zijn account gebeurt, of alleen voor gebruik binnen de rechten die het account heeft? De tweede formulering maakt het onderscheid tussen de twee fasen van een aanval in elk geval bespreekbaar.
  2. Noemt de beveiligingsbijlage een norm en de rechten van sleutels? Een verwijzing naar ISO 27001 of NEN 7510 zegt niets over de vraag of een API-sleutel van de koppeling met uw boekhouding alleen mag lezen of ook mag schrijven. Laat de leverancier het principe van minimale rechten voor tokens en servicekoppelingen opschrijven.
  3. Staat de meldtermijn in uren? De wettelijke norm van artikel 33 lid 2 AVG blijft "zonder onredelijke vertraging"; een contractuele bovengrens van uiterlijk 24 uur na kennisneming maakt die norm hanteerbaar en geeft u de tijd die u voor uw eigen 72-uursmelding nodig heeft. Vraag daarnaast om de logbestanden die bij die melding horen.
  4. Wie bewaart de logs die de twee fasen uit elkaar houden? Zonder inlog- en toegangslogs van de leverancier kunt u niet aantonen dat de wijziging van gegevens buiten de rechten van het account viel. Onder artikel 150 Rv draagt u die bewijslast in beginsel zelf; een contractueel recht op de logbestanden binnen een vaste termijn is daarom geen detail.
  5. Maakt de exoneratie voor "handelen van derden" een uitzondering voor gebreken in de eigen applicatie? Zo niet, vraag dan die uitzondering, en een aparte afspraak over de kosten van herstel, de melding aan betrokkenen en de reconstructie van gewijzigde gegevens.

Heeft u het contract met uw softwareleverancier of de verwerkersovereenkomst bij de hand? Laat het dan even door de contractscan van JAVB lopen; die leest de aansprakelijkheids- en beveiligingsbepalingen mee en geeft u een eerste beeld van waar de tekst achterloopt op de vijf vragen hierboven, zodat u weet waarover u met uw leverancier het gesprek aangaat.