AI-resilience: de blinde vlek in je NIS2-risicoanalyse

Je AI-model is compliant. Het voldoet aan de AI Act, is getest op bias, transparantie en fairness. Maar wat gebeurt er als het model morgen offline gaat? Of als de leverancier stopt? Daar zegt de AI Act niets over. En dat is precies het probleem.

Laatst bij een ZBO dat AI inzet voor fraudedetectie hadden ze een fallback-scenario voor als het primaire datacenter uitvalt, maar niet voor als het AI-model zelf onbruikbaar wordt. "Dan schakelen we terug naar handmatige controle", zei de CISO. Maar dat proces was al jaren niet meer beoefend, en de mensen die het konden waren vertrokken. Operationele veerkracht? Papieren tijger.

NIS2 verplicht essentiële en belangrijke entiteiten om maatregelen te nemen voor operationele veerkracht. Artikel 21 noemt expliciet het waarborgen van de continuïteit van diensten. BIO2, de baseline informatiebeveiliging overheid, eist in hoofdstuk 10 continuïteitsmanagement. Beide kaders vragen om een risicoanalyse van kritieke processen, impacttoleranties en geteste fallback-procedures.

AI-systemen die onderdeel zijn van kritieke dienstverlening vallen hier dus onder. Toch zie ik in de praktijk dat AI-componenten zelden in het BCM-plan staan. De aanname is dat "de cloud" of "de leverancier" de beschikbaarheid wel regelt. Die aanname klopt niet.

De AI Act richt zich op risico's voor gezondheid, veiligheid en grondrechten. Transparantie, bias, menselijk toezicht. ISO 42001 is een managementsysteem voor verantwoord AI-gebruik. Beide frameworks dekken betrouwbaarheid, maar niet operationele veerkracht. Wat als het model niet meer beschikbaar is? Wat als de leverancier failliet gaat? Wat als de data-input stopt? De paper "The AI Resilience Gap" (arXiv:2607.05159) legt deze blinde vlek bloot. [1]

Dit is geen theoretisch risico. Frontier-modelleveranciers opereren met hoge concentratierisico's. Een API-storing bij één partij legt tientallen diensten plat. En de substitueerbaarheid van modellen is laag: je kunt niet zomaar overstappen van GPT-5 naar een ander model zonder herbouw van prompts, integraties en validatie.

Drie blinde vlekken in je AI-risicoanalyse

1. Substitueerbaarheid
   Kun je het AI-model vervangen door een ander model, een andere leverancier, of een handmatig proces? Lock-in is groot. Een gemeente gebruikt een AI-chatbot van een startup. Startup stopt. Chatbot offline. Burgers kunnen geen vragen meer stellen. Geen fallback. De AI Act verplicht je niet om een exit-strategie te hebben. NIS2 wel.

2. Concentratierisico
   Veel organisaties gebruiken dezelfde frontier-modellen. Als die API uitvalt, liggen tientallen overheidsdiensten plat. NIS2 eist dat je afhankelijkheden in kaart brengt en impacttoleranties definieert. AI-afhankelijkheden staan zelden in het leveranciersregister. Dat moet veranderen.

3. Fallback doctrine
   Wat is de procedure als het model faalt? Terugval op een eenvoudiger model, handmatig proces, of statische regels? "We schakelen terug naar handmatig" is geen doctrine als niemand het meer kan. Fallback moet getest worden, net als een disaster recovery plan.

Technisch voorbeeld: health checks die niet genoeg zijn

Stel je draait een AI-model in een Kubernetes-cluster. Je hebt liveness probes op de container. Die checken of de container draait, niet of het model correcte output geeft. Een model kan "stil" falen door data drift, terwijl de container gewoon healthy is.

Wat je nodig hebt is een custom readiness probe die periodiek een inferentie doet en de output valideert tegen een baseline. Bijvoorbeeld een eenvoudige rule-based check die alarmeert als de voorspelde waarde buiten een bepaalde bandbreedte valt. Pas dan kun je een failover triggeren naar een fallback-model of handmatig proces.

readinessProbe:
  exec:
    command:
    - python
    - /app/validate_model.py
    - --baseline
    - /data/baseline.json
  initialDelaySeconds: 30