De neiging om nalevingsproblemen toe te schrijven aan regelgevende onduidelijkheid klopt grotendeels niet meer. De AVG is van kracht geworden in mei 2018. De beginselen van doelbinding, dataminimalisatie en accountability zijn uitgewerkt in richtlijnen van de Europese Gegevensbeschermingsraad, de Autoriteit Persoonsgegevens en tientallen nationale toezichthouders. NIS2 is omgezet in nationale wetgeving, de Cyberbeveiliginginswet Cbw. DORA geldt voor de financiële sector per januari 2025. En de EU AI Act classificeert risico's op een manier die voor de meeste praktijksituaties werkbaar is.

De tekst van de wet is duidelijk maar dat zegt niets over haar effectiviteit.

Wat de AVG in de praktijk heeft voortgebracht, is een compliance-industrie: DPIA-sjablonen, cookiebanner-tooling, privacyverklaringen die niemand leest, verwerkingsregisters die worden bijgehouden omdat het moet. Dat zijn instrumenten van administratieve naleving. Ze meten of het papierwerk op orde is, niet of persoonsgegevens daadwerkelijk worden beschermd, en niet of de systemen die die gegevens verwerken voldoen aan wat de wet beoogt te bereiken.

Het resultaat is een vorm van compliance die zichzelf in stand houdt zonder de onderliggende vraag te stellen: is dit systeem, dit traject, deze architectuur in lijn met de wet, laat staan de intentie erachter? Die vraag verdwijnt achter het afvinkgedrag.

Wie een IT-project van binnen heeft gezien, herkent het. Compliance staat ergens op de planning, na de functionele bouw en voor de acceptatietest. In agile omgevingen verdwijnt het in de backlog, gepland voor een sprint die wordt uitgesteld zodra functionaliteiten uitlopen. Vlak voor de livegang, wanneer de druk maximaal is en het budget grotendeels is besteed, wordt het een blokkade. Dat is geen incident; het is de standaard.

Dat beeld wordt cijfermatig bevestigd. De Barometer Digital Decade 2026, onderzoek onder 516 Nederlandse organisaties van ICTRecht en JuriBlox, stelt dat 46 tot 50 procent onvoldoende is voorbereid op de huidige golf van Europese digitale wetgeving. Internationaal twijfelt twee derde van de organisaties of hun systemen en data-gestuurde AI-toepassingen volledig compliant zijn (Usercentrics & Sapio Research, State of Digital Trust 2026). Dat zijn geen cijfers van opzet. Dat zijn cijfers van een systeem dat compliance als administratieve bestemming heeft ingericht, en daarna verbaasd is dat het niet werkt.

De wet heeft dat patroon niet veroorzaakt, maar ze heeft het ook niet gecorrigeerd. Wie een verwerkingsregister heeft bijgehouden en een DPIA heeft laten uitvoeren, heeft de administratieve checklist afgevinkt. Maar de AVG vereist meer dan dat: de verwerking zelf moet rechtmatig zijn, de architectuur moet gegevensbescherming door ontwerp borgen, en de beveiliging moet passend zijn bij het risico. Papier dekt dat niet af.

Het meest ongemakkelijke voorbeeld is de DPIA zelf. Een gegevensbeschermingseffectbeoordeling beoordeelt een systeemontwerp op papier, wordt gedaan bij aanvang van een traject, en verdwijnt daarna in een dossier. Wat er vervolgens wordt gebouwd, sluit niet altijd aan op wat beoordeeld is. Kleine technische keuzes tijdens de ontwikkeling, door een leverancier beschouwd als implementation details, kunnen de feitelijke verwerking materieel wijzigen. Niemand legt de twee daarna naast elkaar. De verificatiestap die de accountability-plicht van artikel 5 lid 2 AVG impliciet vereist, ontbreekt structureel.

De consequentie is ongemakkelijk: een DPIA die een risico correct heeft geïdentificeerd maar niet is gevolgd in de implementatie, is geen bescherming maar bewijs. De kennis was er; de verificatie niet. Als er vervolgens een inbreuk ontstaat door iets wat afwijkt van wat beoordeeld was, laat het document zien dat de organisatie wist wat vereist was en heeft nagelaten te controleren of het ook zo is gerealiseerd.

Daarmee is ook meteen de vraag gesteld wie die verificatie had moeten doen.

Hier is een vraag die terecht vaker opkomt: zou een IT-leverancier zijn opdrachtgever niet moeten waarschuwen als het systeem in ontwikkeling niet gaat voldoen aan de wet?

De vraag is legitiem. Een softwarebedrijf heeft doorgaans meer technisch inzicht in wat er wordt gebouwd dan de opdrachtgever. De informatieasymmetrie is reëel.

Maar ze onthult meteen een structureel probleem in hoe de AVG accountability heeft ingericht. De verwerkingsverantwoordelijke, de partij die doel en middelen bepaalt, draagt de juridische en financiële rekening. In theorie is dat logisch: wie de verwerking stuurt, is verantwoordelijk. In de praktijk is de verwerkingsverantwoordelijke vaak een organisatie die technisch afhankelijk is van leveranciers die precies weten hoe het systeem werkt, welke data er stroomt en wat dat juridisch betekent. Die leveranciers dragen nauwelijks directe accountability.

De partij die weet hoe het gebouwd is, is niet de partij die de boete krijgt.

Juridisch bouwen leveranciers wat er gevraagd wordt. Als het bestek geen compliancevereisten stelt, bestaat er geen contractuele verplichting om die te signaleren. Dat is iets anders dan bij een architect, die geen ontwerp mag tekenen dat in strijd is met het bestemmingsplan, of een notaris die een juridisch problematische akte niet passeert. Voor IT-leveranciers bestaat geen vergelijkbare beroepscode met wettelijk afdwingbare professionele normen. Dat gesprek wordt in de sector gevoerd, maar heeft nog geen vaste grond.

Toch biedt het Burgerlijk Wetboek wel aanknopingspunten, zou je denken. Artikel 7:401 BW verplicht de opdrachtnemer tot de zorg van een goed opdrachtnemer; een open norm die rechters invullen aan de hand van wat een professionele partij in de gegeven omstandigheden had moeten doen. Als een IT-leverancier bouwt waarvan hij weet of redelijkerwijs moet weten dat het resultaat non-compliant is met acht jaar oude, breed bekende regelgeving, biedt die norm ruimte voor een waarschuwingsplicht. Artikel 6:228 BW voegt een mededelingsplicht bij dwaling toe: wie beter is geïnformeerd en weet dat de ander een onjuiste voorstelling heeft, mag die niet in stand laten. Naarmate de informatieasymmetrie groter is, valt de balans sterker naar die mededelingsplicht. Bij technische compliance-kwesties in IT is die asymmetrie structureel. Dit is geen uitgekristalliseerde jurisprudentie in deze specifieke context, maar het zijn bestaande wettelijke grondslagen die de positie van een leverancier die zich puur op de opdrachtomschrijving beroept, minder comfortabel maken dan ze op het eerste gezicht lijkt.

Wat DORA laat zien, is dat regelgevers die passiviteit niet meer als vanzelfsprekend beschouwen. DORA legt directe verplichtingen op aan ICT-dienstverleners aan financiële instellingen. Het is daarmee een erkenning dat het model van de AVG, waarbij de afnemer alle accountability draagt, tekortschiet zodra technische afhankelijkheid groot genoeg is. DORA is de correctie. Dat er een correctie nodig was, zegt iets.

Er is een structurele parallel die weinig aandacht krijgt. In de bouw is het niet mogelijk te beginnen met graven zonder een omgevingsvergunning. Niet omdat aannemers dat weigeren, maar omdat het systeem er zo op is ingericht: de vergunning is de drempelvoorwaarde voor de uitvoering. Een niet-vergund gebouw wordt stilgelegd.

In softwareontwikkeling bestaat dat systeem niet. Er is geen instantie die controleert of een nieuw systeem compliant is voordat het in productie gaat. De toetsing is retrospectief: een audit, een klacht, een datalek, een handhavende toezichthouder. Tegen die tijd is er gebouwd, betaald en in gebruik genomen. Soms jarenlang.

Dat vraagt iets anders van organisaties dan een compliance-checklist aan het einde van een project. Het vraagt om een bewuste positie aan het begin: welke wetgeving raakt dit traject, wat betekent dat voor de architectuur en de datastromen, en wie is in dit project verantwoordelijk voor die verbinding? Die functie bestaat in veel projectorganisaties eenvoudigweg niet. Ze is niet benoemd, niet bemand en niet geborgd. Ze is ook niet ingeprijsd in de offerte van de bouwer, omdat de bouwer die vraag niet stelt als hij hem niet krijgt.

Daarin schuilt misschien het meest over het hoofd geziene risico: niet dat er iets misgaat met de techniek, maar dat niemand in het project formeel verantwoordelijk is voor de verbinding tussen de technische keuzes en de wettelijke kaders.

De conclusie van dit stuk is niet dat toezichthouders te streng zijn of dat IT-leveranciers tekort schieten. Ze is ook niet dat organisaties slechte bedoelingen hebben.

De conclusie is dat er een systeem is ontstaan waarin compliance een administratieve bestemming heeft gekregen, waarbij de wet zelf dat heeft gefaciliteerd door naleving te meten in papier. En waarbij de aansprakelijkheid is belegd bij de partij die technisch het minst in staat is om te controleren wat er wordt gebouwd, terwijl de technisch capabele partijen in de keten beperkte directe accountability dragen.

Europese privacyboetes hebben de grens van 4,4 miljard euro inmiddels overschreden (GDPR Enforcement Tracker, CMS Law, actueel t/m 2025). De AI Act, NIS2 en DORA voegen nieuwe handhavingslagen toe. De druk neemt toe. Maar zolang het accountability-model niet verandert, zal die druk blijven landen bij de partij die het systeem gebruikt, niet bij de partij die het heeft gebouwd.

Acht jaar na de AVG is dat geen onvermijdelijk gegeven meer. Het is een keuze die herzien kan worden. DORA bewijst dat het kan.

Bronnen: ICTRecht & JuriBlox, Barometer Digital Decade 2026 (NL, 516 organisaties). Usercentrics & Sapio Research, State of Digital Trust 2026 (internationaal). CMS Law / GDPR Enforcement Tracker, cumulatief AVG-boete-overzicht t/m 2025 (EU/EER).