AI-ontwikkeling, beveiliging en compliance: AVG, PCI DSS en ISO 27001 in de praktijk
Publicatiedatum
Kunstmatige intelligentie (AI) schreef de code, dus wie is verantwoordelijk als die persoonsgegevens verkeerd verwerkt? Jij. Het gebruik van een AI-tool neemt de wettelijke en contractuele verantwoordelijkheden van je organisatie niet automatisch weg. De AVG (GDPR) geldt voor de verwerking van persoonsgegevens ongeacht wie de code schreef; PCI DSS en SOC 2 zijn contractuele en sectorale kaders waarvan de precieze toepasselijkheid afhangt van je rol en verwerking.
Dat is het feit dat de meeste kopers en leveranciers verkeerd begrijpen aan AI-gestuurde ontwikkeling. De snelheid is echt, maar ze verandert geen enkele regel. Hieronder lopen we de kaders langs die een groeiend bedrijf het vaakst tegenkomt, wat elk ervan echt eist, en waarom "de AI heeft het geschreven" bij geen enkele toezichthouder of auditor als verweer telt. Lees het als leidraad voor leveranciersbeoordeling, niet als juridisch advies; bevestig de details met je eigen advocaat of functionaris gegevensbescherming (FG). Voor de plaats van compliance in de bredere praktijk begin je bij vibe coding en AI-gestuurde softwareontwikkeling.
De regel die niemand met een prompt kan omzeilen
Regelgeving reguleert uitkomsten, geen auteurschap. Wanneer je software het adres van een klant opslaat, een kaartbetaling verwerkt of personeelsdossiers beheert, ligt de verplichting bij jou als exploitant van die software, wie of wat de code ook produceerde.
Dat weegt zwaarder met AI in het spel, niet lichter, want ongelezen AI-code faalt precies op de manieren die compliancekaders geacht worden te voorkomen. Het 2025 GenAI Code Security Report van Veracode stelde vast dat door AI gegenereerde code in 45% van de tests risicovolle beveiligingsfouten introduceerde; dat cijfer beschrijft het onderzochte testresultaat en is geen universeel foutpercentage voor alle AI-code. Een ontbrekende invoervalidatie of een hardgecodeerd wachtwoord is een bug in elke codebase. In een codebase die persoonsgegevens of betaalgegevens verwerkt is diezelfde bug een compliancefout, met een meldtermijn en een boete eraan vast. De generatiesnelheid verkleint die blootstelling niet; de review overslaan vergroot die, zoals de beveiliging van door AI gegenereerde code laat zien.
AVG: het kader dat de meeste bedrijven als eerste raken
De Algemene verordening gegevensbescherming (AVG) kan van toepassing zijn op de verwerking van persoonsgegevens in het kader van activiteiten van een organisatie in de EU, en in bepaalde gevallen ook op organisaties buiten de EU die personen in de EU monitoren of goederen en diensten aanbieden. Slaat je app namen, e-mails, adressen of gedrag op van mensen in de EU, dan is de AVG doorgaans van toepassing, en een AI gebruiken om die app te bouwen verandert daar niets aan. In Nederland is de toezichthouder de Autoriteit Persoonsgegevens (AP); in België de Gegevensbeschermingsautoriteit (GBA).
Twee verplichtingen bepalen hoe de software gebouwd moet worden. Ten eerste gegevensbescherming door ontwerp en door standaardinstellingen: de AVG vereist dat privacy en beveiliging al bij het ontwerpen van de verwerking worden meegenomen, niet achteraf toegevoegd na de livegang. Ongelezen AI-code faalt structureel op die toets, want niemand besloot hoe persoonsgegevens beschermd zouden worden; het model produceerde gewoon iets wat draaide. Ten tweede de meldplicht bij inbreuken. Onder artikel 33 moet een inbreuk in verband met persoonsgegevens die een risico voor personen oplevert, zonder onredelijke vertraging en waar mogelijk binnen 72 uur aan de toezichthoudende autoriteit worden gemeld (Verordening (EU) 2016/679, artikel 33: Melding van een inbreuk in verband met persoonsgegevens aan de toezichthoudende autoriteit); de Autoriteit Persoonsgegevens bevestigt dat die 72-uursmelding aan de AP moet gebeuren en dat de verantwoordelijkheid daarvoor altijd bij de organisatie zelf ligt. Een codebase die niemand begrijpt maakt die termijn wreed: je kunt niet melden wat er gebeurde als niemand de code kan lezen om het te achterhalen.
De inzet ligt met opzet hoog. Voor de ernstigste overtredingen kunnen AVG-boetes oplopen tot 20 miljoen euro of 4% van de totale wereldwijde jaaromzet, de hoogste van de twee (Verordening (EU) 2016/679, artikel 83). De manier om daar buiten te blijven is weinig spectaculair: persoonsgegevens die je bewust verwerkt, code die een mens heeft gelezen, en gegevensstromen die duidelijk genoeg gedocumenteerd zijn om de vragen van een toezichthouder te beantwoorden.
PCI DSS: zodra je aan kaartbetalingen komt
De Payment Card Industry Data Security Standard (PCI DSS) kan van toepassing zijn op entiteiten die kaarthoudergegevens opslaan, verwerken of doorsturen; de concrete verplichtingen, validatiemethode en verantwoordelijkheid hangen af van de rol en het toepassingsgebied (PCI Security Standards Council). Een eenmanszaak die met kaart laat betalen valt vaak net zo goed binnen het toepassingsgebied als een bank. PCI DSS v4.0.1 is sinds 31 december 2024 de actieve versie, en de nieuwe, toekomstgedateerde vereisten werden vanaf 31 maart 2025 effectief.
De eisen van de norm lezen als een checklist waarvoor ongelezen AI-code punt voor punt zakt: versleutel kaarthoudergegevens, beperk wie erbij kan, test de beveiliging regelmatig, log toegang en houd die in de gaten. Niets daarvan gebeurt per ongeluk in een vibegecodeerde afrekenpagina. De veiligste architectuur is ook de eenvoudigste om conform te krijgen: sla de kaartgegevens gewoon zelf niet op. Laat betalingen lopen via een conforme betaalprovider, zodat de kaartgegevens nooit in je database belanden, wat je PCI-scope terugbrengt tot de koppeling in plaats van het hele systeem. Dat is een bewuste ontwerpkeuze die een mens maakt, en precies het soort afweging dat wegvalt wanneer niemand de build reviewt. Het is ook waarom betaalstromen een reviewzware zone zijn in ons werk aan e-commerce ontwikkeling op maat.
ISO 27001 en SOC 2: wanneer je klanten jou auditen
Het derde type eis verschilt in aard van de eerste twee. Het is geen wet, maar een kader waarmee je klanten controleren dat je hun gegevens beveiligt voordat ze die aan jou toevertrouwen. Aan Europese zijde is de referentienorm ISO/IEC 27001, de internationale norm voor managementsystemen voor informatiebeveiliging (ISMS) die eisen stelt aan een dergelijk managementsysteem: een geaccrediteerde instelling auditeert je managementsysteem en geeft een certificaat af met een nummer en een vervaldatum. Tegenover een Amerikaanse klant of SaaS-uitgever kom je eerder SOC 2 tegen, een auditkader van het American Institute of Certified Public Accountants (AICPA), gebouwd op vijf Trust Services Criteria: beveiliging, beschikbaarheid, verwerkingsintegriteit, vertrouwelijkheid en privacy (AICPA). Een onafhankelijke auditor onderzoekt je maatregelen en levert een attestatierapport. Je "slaagt" niet voor SOC 2; je krijgt een rapport dat je klanten, vaak grotere bedrijven die een leverancier beoordelen of de interne tools op maat waar een heel team van afhangt, lezen voordat ze je hun gegevens toevertrouwen.
Voor een groeiend softwarebedrijf komen ISO 27001 en SOC 2 meestal als een commerciële eis: een grote klant tekent niet totdat je het certificaat of het rapport kunt tonen. De weg daarnaartoe steunt op hetzelfde fundament als de eerste twee kaders. Je hebt maatregelen nodig die echt bestaan, bewijs dat ze draaien, en een codebase waarvan een mens het gedrag kan verantwoorden. Een attestatie die op ongelezen AI-output rust is een attestatie op drijfzand, want op het moment dat een auditor vraagt hoe een maatregel in de code is afgedwongen, moet iemand de code kunnen lezen en antwoorden.
Wat de drie verbindt: een mens die de code las
De drie families van eisen ogen op papier verschillend maar rusten in wezen op hetzelfde fundament. Elk veronderstelt dat iemand kan uitleggen hoe de software gevoelige gegevens verwerkt, kan bewijzen dat een maatregel echt in werking is, en een probleem kan verhelpen wanneer het opduikt. Elk van die veronderstellingen breekt op het moment dat de code niet gelezen is.
Daarom is review geen compliancebeleefdheidje maar de dragende praktijk. Een senior engineer die elke regel leest, is wat "de app lijkt te werken" verandert in "we weten hoe persoonsgegevens stromen, waar kaartgegevens niet heen gaan, en welke maatregel welke eis afdwingt". Wat die review opvangt, werken we uit in menselijke review van door AI gegenereerde code, en het beveiligingsgereedschap eromheen, afhankelijkheidsscans bij elke build en de rest, in hoe we elke build beveiligen. Het punt voor compliance is smal: onbeoordeelde code verhoogt het risico dat een organisatie haar beveiligingsmaatregelen niet kan uitleggen of met bewijs kan onderbouwen; een auditor beoordeelt bovendien het totale controlesysteem, niet uitsluitend of iedere coderegel door een mens is gelezen.
Wat je een AI-ontwikkelaar over compliance moet vragen
Neem deze vragen mee naar een scopinggesprek en luister naar de precieze antwoorden.
- Wie is verantwoordelijk voor compliance in het contract? Het eerlijke antwoord noemt jou verwerkingsverantwoordelijke en de leverancier verwerker, met omschreven verplichtingen, geen vage belofte dat "alles conform is".
- Hoe worden persoonsgegevens in de architectuur verwerkt? Je wilt een beschreven gegevensstroom, geen geruststelling. Waar worden gegevens opgeslagen, wie kan erbij, en wat wordt gelogd?
- Komen kaartgegevens ooit in de database terecht? Voor alles met betalingen is het juiste antwoord meestal nee, met een conforme betaalprovider bij naam.
- Wie reviewt de code, en kan die persoon de vragen van een toezichthouder of auditor erover beantwoorden? Kan geen mens de codebase lezen en een maatregel uitleggen, dan is geen enkel certificaat dat erop gebouwd is iets waard.
- Waar gaan mijn gegevens heen wanneer de AI de code genereert? De leverancier stuurt je codebase, en soms je gegevens, naar een model dat ergens gehost wordt. Vraag welk model, onder welk contract, en of je productiegegevens er ooit doorheen gaan. Een leverancier die het antwoord niet heeft, heeft zijn eigen gebruiksvoorwaarden niet gelezen, en de AVG neemt geen genoegen met dat excuus.
Nog een nuttige verduidelijking, want de verwarring is wijdverbreid en duur. De Europese AI-verordening (de AI Act, Verordening (EU) 2024/1689) geldt niet voor jouw software enkel en alleen omdat er een AI aan te pas kwam om die te schrijven. De verordening richt zich op AI-systemen die op de markt komen: bevat het opgeleverde product zelf een AI-functie, dan kan het in een risicocategorie vallen met bijbehorende verplichtingen; was de AI alleen een ontwikkeltool, dan is het enkele gebruik ervan doorgaans niet voldoende om je software tot een AI-systeem onder de verordening te maken, al hangt de precieze kwalificatie af van de functies, het doel en de rol van het uiteindelijke systeem, en verdient dat een juridische toets. De AVG geldt wél in beide gevallen, vanaf het eerste persoonsgegeven. Een leverancier die de twee door elkaar haalt, in welke richting dan ook, verkoopt je angst of zorgeloosheid, en geen van beide helpt je.
Onze volledige buildpijplijn, van geschreven scope tot gereviewde oplevering, staat beschreven in hoe we scopen, bouwen en reviewen, en die is zo opgezet dat deze vragen klare antwoorden hebben.
Veelgestelde vragen
Is door AI gegenereerde code AVG-conform?
Niet standaard, en compliance is nooit een eigenschap van code alleen. Het hangt af van hoe de software persoonsgegevens verwerkt: bescherming vanaf het begin ingebouwd, gedocumenteerde gegevensstromen, en maatregelen die een mens kan verantwoorden. AI kan conforme code genereren nadat een engineer die heeft gereviewd en geverifieerd.
Neemt AI gebruiken om software te bouwen mijn complianceverplichtingen weg?
Nee. Het gebruik van een AI-tool neemt de wettelijke en contractuele verantwoordelijkheden van je organisatie niet automatisch weg. De AVG geldt voor de verwerking van persoonsgegevens ongeacht wie de code schreef, en PCI DSS blijft van toepassing wanneer je kaarthoudergegevens opslaat, verwerkt of doorstuurt. "De AI heeft het geschreven" is bij geen enkele toezichthouder of auditor een verweer.
Moet ik PCI DSS-conform zijn als een AI mijn afrekenpagina bouwde?
Ja, als de software kaarthoudergegevens opslaat, verwerkt of doorstuurt, ongeacht wie die bouwde of hoe. De minst riskante weg laat betalingen lopen via een conforme betaalprovider, zodat kaartgegevens nooit je database raken en je PCI-scope tot de koppeling krimpt.
Kan vibegecodeerde software een ISO 27001- of SOC 2-audit doorstaan?
Alleen als de maatregelen erachter echt bestaan en iemand kan bewijzen dat ze draaien. Deze audits zijn onafhankelijke attestaties, geen vinkje. Een auditor beoordeelt het totale controlesysteem en vraagt vaak hoe een maatregel in de code is afgedwongen; bij ongelezen code is er niemand die dat kan uitleggen, wat het risico op een falende attestatie sterk vergroot.
Wat is het grootste compliancerisico bij ongelezen AI-code?
Dat een beveiligingsfout, zoals in 45% van de tests in het Veracode-onderzoek van 2025, meegaat in software die persoonsgegevens of betaalgegevens verwerkt; dat percentage beschrijft het onderzochte testresultaat, niet een universeel foutpercentage voor alle AI-code. Een bug wordt een inbreuk, met een meldtermijn van 72 uur en een boete, in plaats van een bevinding die bij review wordt onderschept.
Hoe pakt Globaprom compliance aan bij AI-gestuurde builds?
Compliancevereisten worden vooraf gescopet en geprijsd, stromen van persoons- en betaalgegevens bewust ontworpen, en een senior engineer leest elke regel zodat maatregelen bewijsbaar zijn. We zijn niet je juridisch adviseur: we werken samen met je advocaat of FG, niet in hun plaats.
Bouw het conform vanaf de eerste commit
Compliance is het goedkoopst en veiligst wanneer die vooraf is ontworpen, niet na de livegang ontdekt. Vertel ons welke regelgeving je software moet naleven en we scopen die expliciet, bouwen met elke regel gereviewd, en leveren je een codebase die je echt kunt verantwoorden tegenover een toezichthouder of auditor.