NIST AI RMF is niet genoeg: SCITUS en de 57 controls voor multi-jurisdictioneel AI-toezicht

AI-risicomanagement draait niet langer om één framework. Het draait om de vraag: hoe voldoe je tegelijk aan de AI Act, de AVG, de BIO2, sectorale normen én de eisen van je toezichthouder? Precies die vraag beantwoordt SCITUS — een systematische aanpassing van NIST AI RMF 1.0 aan een federale, multi-jurisdictionele realiteit.

Ik zag het probleem laatst nog bij een zorginstelling. Ze gebruiken een AI-model voor het prioriteren van radiologiebeelden. De CISO had drie spreadsheets: één voor de AI Act, één voor de NEN 7510, één voor de AVG. Geen enkele sprak dezelfde taal. Controls overlapten, andere bleven juist liggen. Toen ik SCITUS onder ogen kreeg, dacht ik: dit is precies wat we in Nederland missen.

Wat SCITUS doet

SCITUS is een framework dat het NIST AI Risk Management Framework 1.0 vertaalt naar een multi-jurisdictionele context. De onderzoekers hebben het toegepast op Canada — federaal én provinciaal — maar het model is generiek. Het resultaat: 57 concrete controls, versiebeheerd in een catalogus, met een duidelijke mapping naar de onderliggende wet- en regelgeving.

De kern is een matrix die elke NIST AI RMF-subcategorie koppelt aan één of meer juridische vereisten uit verschillende jurisdicties. Vervolgens definieert SCITUS per subcategorie een control die alle relevante eisen dekt. Een voorbeeld: subcategorie GOVERN-1.1 (wettelijke en regelgevende vereisten rond AI) wordt in de Canadese context gemapt naar de federale Privacy Act, de Personal Information Protection and Electronic Documents Act (PIPEDA), en provinciale wetten zoals Quebec’s Law 25. De bijbehorende SCITUS-control luidt dan:

SCITUS-CTL-001: De organisatie onderhoudt een actueel register van toepasselijke AI-gerelateerde wettelijke verplichtingen, uitgesplitst naar jurisdictie, en toetst elk AI-systeem hieraan voor ingebruikname en bij significante wijzigingen.

Geen vage aanbeveling, maar een toetsbare maatregel. En dat 57 keer, voor elke relevante subcategorie van het NIST AI RMF.

Versiebeheer als fundament

Wat SCITUS onderscheidt van eerdere mappings, is het versiebeheer. De control catalog is opgezet als een gestructureerd document met een versienummer, changelog en verwijzingen naar de specifieke wetsartikelen die ten grondslag liggen aan elke control. Wijzig je een control omdat de wet verandert, dan is die wijziging traceerbaar. In een federale context met meerdere wetgevers is dat geen luxe, maar een vereiste.

In Nederland kennen we dat probleem ook. De AI Act wordt gefaseerd van kracht, de AVG kent bindende interpretaties van de EDPB, de BIO2 wordt herzien, en NIS2 krijgt nationale invulling via de Wet beveiliging netwerk- en informatiesystemen. Zonder versiebeheer op je control set weet je over een jaar niet meer waarom een bepaalde maatregel in je ISMS staat.

Van Canada naar Nederland: een directe vertaling

De Canadese casus is relevant omdat Nederland een vergelijkbare gelaagdheid kent. Wij hebben weliswaar geen provinciale AI-wetten, maar wel een stapeling van Europese verordeningen, nationale wetten en sectorspecifieke normen. Een AI-systeem bij de Belastingdienst moet voldoen aan de AI Act, de AVG, de Baseline Informatiebeveiliging Overheid (BIO2), de Nederlandse Overheid Referentie Architectuur (NORA) én de eisen van de Autoriteit Persoonsgegevens. Dat zijn vijf verschillende bronnen van verplichtingen, elk met een eigen vocabulaire.

SCITUS biedt een blauwdruk om die chaos te temmen. Je neemt het NIST AI RMF als basis, identificeert per subcategorie welke Nederlandse en Europese eisen relevant zijn, en formuleert een control die alle eisen dekt. Het resultaat is een set van 57 controls die je direct kunt opnemen in je AI-governance.

Een voorbeeld voor de Nederlandse context: subcategorie MAP-2.1 (AI-systeemregistratie). De AI Act verplicht registratie van hoog-risico AI-systemen in de EU-databank (art. 51). De BIO2 eist een actueel overzicht van alle informatiesystemen (BIO2.1.1). De AVG vraagt om een register van verwerkingsactiviteiten als er persoonsgegevens in het spel zijn (art. 30). Een Nederlandse SCITUS-control zou kunnen luiden:

NL-CTL-012: De organisatie houdt een centraal AI-systeemregister bij dat per systeem de AI Act-risicoclassificatie, de BIO2-systeem-ID, het AVG-verwerkingsregister-ID en de toepasselijke wettelijke grondslagen bevat. Het register wordt minimaal per kwartaal gevalideerd tegen de actieve systemen in productie.

Compliance as code: van catalogus naar geautomatiseerde check

Een control catalog is pas waardevol als je hem kunt operationaliseren. SCITUS leent zich voor een ‘compliance as code’-aanpak. Je definieert elke control als een machine-leesbare regel, koppelt die aan je CI/CD-pipeline of cloudomgeving, en laat een policy engine continu toetsen of je AI-systemen compliant zijn.

Een minimale implementatie met Open Policy Agent (OPA) ziet er zo uit:

package ai.compliance

import rego.v1

default allow = false

# NL-CTL-012: AI-systeemregister moet bestaan en actueel zijn
allow if {
    input.ai_systems[_].register_id != ""
    input.ai_systems[_].risk_classification in {"limited", "high", "unacceptable"}
    input.ai_systems[_].last_validated > time.add_date(time.now_ns(), -90, 0, 0)
}

Je versiebeheert deze regels in Git, samen met de control catalog. Een wijziging in de AI Act leidt tot een pull request op je Rego-code, met een changelog die verwijst naar het gewijzigde wetsartikel. Zo maak je multi-jurisdictionele compliance auditeerbaar en reproduceerbaar.

Waarom dit nu urgent is

De AI Act wordt vanaf 2 augustus 2026 van kracht voor hoog-risico AI-systemen. De NIS2-richtlijn is sinds oktober 2024 van toepassing en breidt de reikwijdte van cybersecurityverplichtingen uit naar de zorg, digitale infrastructuur en overheidsdiensten. De BIO2 wordt in 2026 herzien en zal AI-gerelateerde beheersmaatregelen bevatten. Organisaties die nu nog vertrouwen op losse compliance-spreadsheets, lopen vast.

SCITUS toont dat een systematische, versiebeheerde control catalog haalbaar is. De 57 controls zijn geen theoretische exercitie; ze zijn getoetst aan de Canadese praktijk en direct toepasbaar op andere federale systemen. Nederland kan dit model één-op-één overnemen, met een eigen mapping naar de AI Act, AVG, BIO2, NIS2 en NORA.

De valkuil van enkelvoudige frameworks

Te vaak zie ik organisaties die denken dat het NIST AI RMF voldoende is. Ze implementeren de vier functies — Govern, Map, Measure, Manage — en verklaren zichzelf compliant. Maar het RMF is een raamwerk, geen checklist. Het vertelt je niet welke specifieke maatregelen je moet nemen om aan de AI Act te voldoen. SCITUS vult die leemte op, zonder het RMF los te laten. Het bouwt erbovenop.

In een eerdere post schreef ik al over de beperkingen van enkelvoudige AI-governance frameworks: CEDAR-42001: Waarom ISO 42001-conformiteit alleen niet genoeg is. Die analyse blijft relevant, maar SCITUS voegt daar een essentiële laag aan toe: de erkenning dat je nooit met één wetgever te maken hebt. Multi-jurisdictioneel is de norm, niet de uitzondering.

Concrete stappen voor jouw organisatie

Begin met het inventariseren van alle juridische bronnen die op jouw AI-systemen van toepassing zijn. AI Act, AVG, BIO2, NIS2, NORA, sectorspecifieke normen — zet ze op een rij. Pak vervolgens het NIST AI RMF erbij en loop de subcategorieën langs. Bepaal per subcategorie welke eisen uit welke bronnen relevant zijn. Formuleer een control die alle eisen dekt. Versiebeheer het resultaat in een Git-repository.

Wil je een vliegende start maken? Begin met het in kaart brengen van je eigen juridische bronnen. Pak het NIST AI RMF erbij, loop de subcategorieën langs, en bepaal per subcategorie welke eisen uit welke bronnen relevant zijn. Formuleer een control die alle eisen dekt. Versiebeheer het resultaat in een Git-repository — dat is de kern van SCITUS’ methodologie, en die kun je vandaag al toepassen.

Bron: SCITUS: Multi-Jurisdictional NIST AI RMF Adaptation, arXiv:2607.15051. Abstract | PDF