AI-governance stopt bij productie - en dat is precies waar NIS2 begint

AI-governance zoals we die nu inrichten, stopt bij het moment dat je model in productie gaat. De EU AI Act, ISO 42001, NIST AI RMF, ze vertellen je hoe je AI betrouwbaar maakt. Hoe je bias documenteert, transparantie borgt, menselijk toezicht inregelt. Maar wat als je AI-systeem uitvalt tijdens een cyberaanval? Of langzaam degradeert door model drift? Daar zwijgen ze over.

Dat is de AI resilience gap. En voor Nederlandse ZBO’s die onder NIS2 vallen, is dat geen theoretisch probleem.

Laatst zat ik bij een zelfstandig bestuursorgaan dat trots hun AI Act-gapanalyse liet zien. Alles netjes: risicoclassificatie, documentatie, menselijk toezicht. Tot ik vroeg: “Wat gebeurt er als jullie model morgen andere output geeft door een poisoned update van jullie leverancier?” Stilte. Geen proces, geen runbook, geen test. En dat is precies het probleem.

De blinde vlek van AI-governance

Een paper die deze week op arXiv verscheen legt de vinger op de zere plek. De auteurs analyseren bestaande AI-governance frameworks en tonen aan: operationele weerbaarheid, business continuity, incident response, supply chain resilience, ontbreekt vrijwel volledig. [1]

De EU AI Act eist voor hoog-risico AI-systemen robuustheid, nauwkeurigheid en cybersecurity. Maar nergens staat dat je een BCM-plan moet hebben voor het moment dat je model uitvalt. ISO 42001 geeft je een managementsysteem voor AI, maar operationele continuïteit is geen verplicht onderdeel. NIST AI RMF noemt ‘resilience’ wel als eigenschap, maar vertaalt dat niet naar concrete maatregelen voor incident response of supply chain.

Wat hier interessant is: de frameworks gaan over trustworthiness, is het model eerlijk, uitlegbaar, veilig?, maar niet over operational resilience, blijft het draaien als de infrastructuur onder vuur ligt, als de dataverdeling verschuift, als een dependency wordt gecompromitteerd?

Wat NIS2 wél eist

NIS2 (Richtlijn EU 2022/2555, in Nederland geïmplementeerd via de Wet beveiliging netwerk- en informatiesystemen) verplicht essentiële en belangrijke entiteiten om maatregelen te nemen voor de beveiliging van hun netwerk- en informatiesystemen. Artikel 21 noemt expliciet: “de beveiliging van de toeleveringsketen”, “de beveiliging van het verwerven, ontwikkelen en onderhouden van netwerk- en informatiesystemen”, en “beleid en procedures voor de doeltreffendheid van maatregelen voor risicobeheer op het gebied van beveiliging”.

Als jouw AI-systeem onderdeel is van een kritiek proces, denk aan triage in de zorg, fraudedetectie bij een uitkeringsinstantie, of netwerkmonitoring bij een drinkwaterbedrijf, dan valt de operationele continuïteit van dat AI-systeem onder NIS2. Niet als optionele toevoeging, maar als harde eis.

De BIO2 (Baseline Informatiebeveiliging Overheid) sluit hierop aan. BIO2-hoofdstuk 17 gaat over continuïteitsmanagement. Daar staat: “De organisatie moet de continuïteit van de informatiebeveiliging borgen in de bedrijfscontinuïteitsplannen.” Als AI onderdeel is van je informatieverwerking, moet je AI dus meenemen in je BCM. De AI Act helpt je daar niet bij.

Drie operationele AI-risico’s die je nu moet testen

De paper onderscheidt drie categorieën operationele AI-risico’s die in governance frameworks onderbelicht blijven. Ik loop ze langs met concrete voorbeelden.

Model drift: sluipende degradatie

Model drift treedt op wanneer de statistische eigenschappen van de inputdata veranderen ten opzichte van de trainingsdata. Je model wordt langzaam slechter, zonder dat iemand het merkt. Geen alarm, geen foutmelding, alleen output die steeds minder klopt.

Bij een zorginstelling zag ik een voorspellingsmodel voor patiëntuitstroom dat langzaam afweek na een fusie. De dataverdeling veranderde, het model bleef de oude populatie weerspiegelen. De financiële afdeling sloeg pas alarm toen de budgetprognoses structureel 15% afweken.

Test dit actief. Met de open-source Python library evidently zet je in vijf regels een driftmonitor op: