AI-ontwikkeling, beveiliging en compliance: AVG, PCI DSS en ISO 27001 in de praktijk
Date Published
Kunstmatige intelligentie (AI) schreef de code, dus wie is verantwoordelijk als die persoonsgegevens verkeerd verwerkt? Jij. Compliance-verplichtingen hangen aan de software en aan het bedrijf dat die draait, nooit aan de tool die de code genereerde. De AVG (GDPR), PCI DSS en SOC 2 gelden precies zoals wanneer een mens elke regel had getypt.
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, valt de verplichting op 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 45% van de door AI gegenereerde codefragmenten bekende beveiligingskwetsbaarheden bevatte. 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 het, 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) beheerst elke software die de persoonsgegevens verwerkt van mensen in de Europese Unie, waar het bedrijf zelf ook gevestigd is. Slaat je app namen, e-mails, adressen of gedrag op, dan geldt de AVG, 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: beveiliging en privacy moeten van meet af aan ingebouwd zijn, niet achteraf aangeschroefd 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 (AVG, artikel 33). 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 (AVG, 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) geldt voor elke organisatie die kaarthoudergegevens opslaat, verwerkt of doorstuurt, ongeacht de omvang (PCI Security Standards Council). Een eenmanszaak die met kaart laat betalen valt net zo goed binnen het toepassingsgebied als een bank. De huidige versie is v4.0.1, en de volledige set eisen is verplicht sinds 2025, dus er valt geen overgangsregeling meer om op te leunen.
De eisen van de norm lezen als een checklist die ongelezen AI-code punt voor punt faalt: 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 je database raken, 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: 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. Daar komen 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 en rusten eronder 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 (in het Engels). Het punt voor compliance is smal en stellig: je kunt code die niemand heeft gelezen niet certificeren, melden of verdedigen.
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?
- Raken kaartgegevens ooit de database? 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 ergens gehost model. 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 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 valt het in een risicocategorie en draagt het de bijbehorende verplichtingen; was de AI alleen een ontwikkeltool, dan blijft je software gewone software in de ogen van de tekst. 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. Verplichtingen hangen aan de software en aan het bedrijf dat die exploiteert, niet aan de tool die de code schreef. De AVG en PCI DSS gelden precies zoals voor software die een mens schreef. "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 vraagt hoe een maatregel in de code is afgedwongen, en ongelezen code laat niemand over om te antwoorden, dus de attestatie faalt.
Wat is het grootste compliancerisico bij ongelezen AI-code?
Dat een beveiligingsfout, aanwezig in 45% van de fragmenten in het Veracode-onderzoek van 2025, meegaat in software die persoonsgegevens of betaalgegevens verwerkt. Een bug wordt een inbreuk, met een meldtermijn van 72 uur en een boete, in plaats van een opmerking die in review wordt opgevangen.
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.