Een vaste bestuurlijke lens van rol, risicoklasse en bewijs om AI-besluiten snel, consistent en aantoonbaar te beoordelen onder de AI-Act.
Veel AI-dossiers bevatten veel informatie, maar weinig houvast. Het bestuur krijgt een presentatie over de techniek, een businesscase, een risicoanalyse en een overzicht van mogelijke voordelen. Toch blijven drie eenvoudige vragen soms onbeantwoord:
Dat is een bestuurlijk probleem. Zonder duidelijke rol is niet helder wie waarvoor verantwoordelijk is. Zonder onderbouwde risicoklasse weet de organisatie niet hoe zwaar de beheersing moet zijn. En zonder bewijs blijft governance vooral een verhaal.
De oplossing is niet nóg een uitgebreid raamwerk. De oplossing is een vaste bestuurlijke lens die bij ieder AI-systeem wordt gebruikt. De drie vragen vormen samen een eenvoudige besluitlijn:
Rol bepaalt de verantwoordelijkheid. Risicoklasse bepaalt de zwaarte. Bewijs bepaalt of het systeem klaar is voor gebruik.
Deze drie ankers zijn bedoeld als vast werkmodel voor iedere AI-toepassing, van een eenvoudige chatbot tot een systeem dat kredietaanvragen, claims of sollicitanten beoordeelt.
Een chatbot en een kredietmodel hoeven niet aan precies dezelfde eisen te voldoen. De gevolgen van een fout zijn immers anders. Toch kunnen beide systemen met dezelfde drie vragen worden beoordeeld.
Dat is de kracht van deze aanpak. De vorm is steeds gelijk, terwijl de diepgang verschilt. Een toepassing met weinig impact krijgt een lichte toets. Een toepassing die rechten, inkomen, werk, zorg of veiligheid raakt, vraagt veel meer onderzoek, menselijke controle en bewijs.
Zo voorkomt de organisatie twee uitersten. Aan de ene kant staat een zware, trage aanpak waarbij zelfs een klein experiment door een groot bestuurlijk proces moet. Aan de andere kant staat een te lichte aanpak waarbij een belangrijk AI-systeem wordt behandeld alsof het alleen een nieuwe softwarefunctie is.
Volwassen AI-governance zit daartussenin: vast in structuur en passend bij het risico.
De eerste vraag gaat niet over de techniek. Zij gaat over verantwoordelijkheid.
De AI-Act onderscheidt verschillende rollen. In gewone taal gaat het vooral om vier mogelijkheden:
De rol bepaalt welke verplichtingen gelden. Een aanbieder heeft bijvoorbeeld zwaardere plichten rond technische documentatie, testen, kwaliteit en conformiteit. Een deployer moet vooral kunnen aantonen dat het systeem op de juiste manier wordt gebruikt, dat menselijk toezicht werkt en dat prestaties en incidenten worden gevolgd. Bij importeurs en distributeurs ligt extra nadruk op de keten, documentatie en controle van leveranciers.
De naam in het contract is niet genoeg. Ook een organisatie die een systeem heeft ingekocht, kan meer doen dan alleen gebruiken.
Denk aan een organisatie die:
Dan kan de juridische rol veranderen.
De AI-Act bepaalt dat een deployer, importeur, distributeur of andere partij onder bepaalde voorwaarden als aanbieder van een hoog-risico-AI-systeem kan worden gezien. Dat kan onder meer gebeuren bij een wezenlijke wijziging of wanneer het doel zo verandert dat de toepassing hoog risico wordt. Niet iedere kleine update leidt dus tot een nieuwe rol. De aard en gevolgen van de wijziging zijn bepalend.
Bron: Verordening (EU) 2024/1689 (AI-Act), EUR-Lex.
Vertaal dit naar een praktische artikel 25-gate: een vast controlemoment bij iedere belangrijke wijziging. Daarbij wordt bekeken of doel, werking, doelgroep of risicoprofiel zo sterk verandert dat de rol opnieuw moet worden bepaald. De uitkomst hoort in het AI-register en in de besluitvorming te staan.
Een goed antwoord op de rolvraag is concreet:
“Wij zijn deployer, omdat wij het systeem binnen de afgesproken instructies gebruiken. Wij trainen het model niet opnieuw. Bij iedere wijziging controleren wij via de artikel 25-gate of onze rol verandert.”
Of:
“Wij zijn zowel aanbieder als deployer. Wij ontwikkelen het model zelf en gebruiken het daarna in ons eigen proces.”
Een antwoord als “de leverancier regelt de compliance” is onvoldoende. Uitbesteden verandert de werkzaamheden, maar niet automatisch de verantwoordelijkheid van de organisatie.
Het bestuur wil minimaal zien:
De kernvraag is dus niet alleen: welke rol noemen wij onszelf? De betere vraag is: welke rol blijkt uit wat wij feitelijk doen?
Als de rol helder is, volgt de tweede vraag: hoe zwaar weegt dit AI-systeem?
De Europese aanpak is gebaseerd op verschillende risiconiveaus. Er worden vier klassen gebruikt:
De actuele Europese uitleg bevestigt deze risicogestuurde aanpak. De zwaarte van de regels hangt af van het gebruik en de mogelijke gevolgen van het systeem.
Bron: Europese Commissie, European approach to artificial intelligence.
De eerste stap is altijd de vraag of de toepassing in de buurt komt van een verboden AI-praktijk. Is dat het geval, dan is de uitkomst geen extra controle of een zwaarder dossier. Dan moet de toepassing stoppen of ingrijpend worden aangepast. De reden voor dat besluit hoort te worden vastgelegd.
Dit klinkt vanzelfsprekend. Toch bestaat een bekende valkuil: teams nemen te snel aan dat een toepassing “vast niet verboden” is. Een vaste toets voorkomt dat een gevoelig onderwerp pas laat in het project wordt ontdekt. De classificatieroute begint daarom bewust bij deze stopvraag.
Een hoog-risico-AI-systeem kan grote gevolgen hebben voor mensen, rechten, veiligheid of toegang tot belangrijke diensten. Voorbeelden zijn bepaalde toepassingen in arbeidsselectie, kredietbeoordeling, zorg en essentiële dienstverlening.
Bij hoog risico is een lichte controle niet genoeg. Dan zijn onder meer sterk risicobeheer, goede data, technische documentatie, logging, uitlegbaarheid, menselijk toezicht en monitoring nodig. Ook kunnen aanvullende beoordelingen nodig zijn, zoals een AIA, FRIA of DPIA.
Een classificatie als hoog risico is daarmee geen label in een spreadsheet. Zij bepaalt de manier waarop het systeem wordt ontworpen, getest, goedgekeurd en gevolgd.
Bij beperkt risico ligt de nadruk vaak op transparantie. Gebruikers moeten bijvoorbeeld kunnen zien dat zij met AI te maken hebben of dat AI-content is gebruikt.
Dat vraagt meer dan een algemene zin in het AI-beleid. De melding moet zichtbaar zijn in de kanalen waar de gebruiker de AI echt tegenkomt: website, app, brief, e-mail, chat of rapport.
Gebruik hiervoor een kanaal-matrix. Daarin staat per kanaal welke melding wordt gebruikt, waar deze zichtbaar is, wie eigenaar is en waar het bewijs staat.
Een toepassing kan onder de AI-Act een lichte risicoklasse hebben en toch bestuurlijk relevant zijn.
Een interne AI-assistent kan bijvoorbeeld:
De wettelijke risicoklasse is daarom het startpunt, niet het hele risicobeeld. Bestuurders moeten ook blijven kijken naar privacy, informatiebeveiliging, afhankelijkheid van leveranciers, reputatie, klantbelang en continuïteit.
De risicoklasse hoort opnieuw te worden bekeken wanneer iets wezenlijks verandert, bijvoorbeeld:
De deployer moet zelf controleren of de classificatie van de leverancier nog past bij het werkelijke gebruik. Als het gebruik verandert, moet ook de classificatie opnieuw worden bekeken.
Een goed antwoord klinkt bijvoorbeeld zo:
“Dit systeem valt in de hoge risicoklasse, omdat het zwaar meeweegt bij toegang tot financiering. De classificatie is vastgelegd, de relevante wettelijke grond is benoemd en wij beoordelen haar opnieuw bij iedere grote wijziging.”
Of:
“Dit is een toepassing met beperkt risico. Zij voert geen besluiten over mensen uit. Wel communiceren gebruikers rechtstreeks met AI. Daarom zijn transparantie, labeling en een route naar een medewerker verplicht onderdeel van de oplevering.”
De cruciale vervolgvraag is steeds: welk feit maakt deze classificatie juist, en welk soort verandering zou een nieuwe beoordeling nodig maken?
De derde vraag is de meest beslissende. Zij maakt het verschil tussen governance op papier en governance in de praktijk.
Veel organisaties hebben inmiddels AI-beleid. Maar beleid vertelt vooral wat de organisatie wil doen. Het bewijst nog niet:
Werk daarom met twee vaste bewijslijnen.
Het AI-register is de identiteitskaart van ieder AI-systeem. Het laat minimaal zien:
Het register geeft antwoord op de vraag: wat hebben wij en hoe is het ingericht? Het is daarmee geen eenvoudige inventarislijst. Het is een managementinstrument waarmee bestuur, risk, compliance en audit vanuit hetzelfde overzicht werken.
Het register vertelt wat aanwezig zou moeten zijn. De review-evidence-set laat zien of het ook echt werkt.
Deze set bevat bijvoorbeeld:
De review-evidence-set maakt zichtbaar wat na livegang gebeurt. Zij bewijst dus niet alleen dat controles zijn bedacht, maar ook dat ze worden gebruikt.
Deze vaste verzameling bewijs is de brug tussen het dagelijkse werk, wettelijke eisen en de behoefte van het bestuur aan overzicht. Met één vaste set weet het team wat het moet leveren, weet de tweede lijn wat zij moet toetsen en kunnen bestuur en audit sneller patronen herkennen.
Naast het register en de reviewset is een crosswalk nodig. Een crosswalk is een vertaaltabel met vier eenvoudige kolommen:
| Eis | Proces | Bewijs | Eigenaar |
|---|---|---|---|
| Wat moet er? | Hoe voeren wij dit uit? | Waaruit blijkt dat? | Wie is aanspreekbaar? |
Zo wordt een algemene eis over datakwaliteit vertaald naar een datasheet, een datakwaliteitscontrole, een bewijslink en een aangewezen eigenaar. Een eis over menselijk toezicht wordt vertaald naar besliskaarten, mandaten, een override-log en een proceseigenaar.
De crosswalk voorkomt dat ieder team de regels zelf uitlegt. Zij beperkt dubbel werk en maakt het mogelijk om van een eis direct door te klikken naar proces, bewijs en eigenaar.
De bewijsstructuur rust op vier kerndocumenten:
Samen zorgen deze documenten ervoor dat het systeem navolgbaar wordt voor bestuur, medewerkers, audit en toezicht.
Een sterke bestuurlijke beoordeling kijkt naar drie niveaus:
Neem menselijk toezicht als voorbeeld. In de opzet staat dat een medewerker mag afwijken van het AI-advies. Bij bestaan zijn er besliskaarten, trainingen, mandaten en een override-knop. Maar pas bij werking blijkt of medewerkers werkelijk ingrijpen, waarom zij dat doen en wat daarna gebeurt.
Een override-KPI van nul procent kan een rode vlag zijn. Misschien is het model uitzonderlijk goed, maar het kan ook betekenen dat medewerkers het advies blind volgen, geen tijd hebben of zich niet vrij voelen om af te wijken. Een zeer hoog percentage kan juist betekenen dat het model slecht aansluit op de praktijk.
Daarom zijn het percentage alleen en de procedure niet genoeg. Het bestuur wil ook enkele concrete voorbeelden uit het override-log zien. Pas op voor schijn-toezicht: menselijk toezicht bestaat pas echt wanneer iemand de uitkomst begrijpt, tijd en mandaat heeft en het ingrijpen wordt gelogd.
| Bestuurlijke vraag | Antwoord dat u wilt horen | Minimaal bewijs | Rode vlag |
|---|---|---|---|
| 1. Welke rol hebben wij? | “Wij zijn deployer en voor dit aangepaste deel ook aanbieder. Dit is opnieuw beoordeeld bij de laatste wijziging.” | Rolnotitie, contract, leveranciersinstructies, changelog, artikel 25-check en AI-register | “De leverancier is verantwoordelijk.” |
| 2. Welke risicoklasse geldt? | “De toepassing is hoog risico vanwege het doel en de gevolgen. Dit is onderbouwd en wordt opnieuw beoordeeld bij wijzigingen.” | Classificatieblad, wettelijke onderbouwing, risicoanalyse en waar nodig AIA, FRIA of DPIA | “Het is alleen een hulpmiddel.” |
| 3. Welk bewijs laat werking zien? | “De laatste review toont prestaties, fairness, drift, overrides, klachten en CAPA-effect.” | AI-register, review-evidence-set, datasheet, model card, logging, kanaal-matrix en CAPA-overzicht | Alleen beleid, een demo of een mondelinge toelichting |
De beste antwoorden hebben steeds drie kenmerken:
Een AI-review is geen informatiesessie. Zij moet eindigen met een duidelijke bestuurlijke uitkomst.
De rol en risicoklasse zijn helder. Het bewijs is compleet. Belangrijke controles werken en het resterende risico past binnen de risicobereidheid.
De kern is op orde, maar er zijn nog beperkte tekortkomingen. Deze krijgen een CAPA: een corrigerende en preventieve maatregel met een eigenaar, einddatum en verwachte effectmeting.
De rol of risicoklasse is nog onzeker. Belangrijke logging ontbreekt. Menselijk toezicht werkt niet aantoonbaar. Of de leverancier geeft onvoldoende informatie. Het systeem gaat dan niet verder totdat de gaten zijn opgelost.
De toepassing is verboden, past niet bij de waarden van de organisatie of kan niet op een aanvaardbare manier worden beheerst. Ook stoppen is dan een goed bestuurlijk besluit. Noem dit productieve frictie: governance moet niet iedere ontwikkeling blokkeren, maar moet wel “stop” kunnen zeggen wanneer de basis niet klopt.
Rol, risicoklasse en bewijs moeten niet alleen bij de eerste goedkeuring worden besproken. AI verandert. Data veroudert, modellen worden bijgewerkt, leveranciers passen hun diensten aan en het gebruik binnen de organisatie groeit.
Daarom horen de drie vragen terug te komen in vier vaste momenten.
De Definition of Ready bevat de startvoorwaarden. Doel, doelgroep, data, rol, risicoklasse, fairness, uitleg en menselijk toezicht zijn voldoende helder voordat het werk begint.
De Definition of Done bevat de oplevervoorwaarden. Testen zijn uitgevoerd, logging werkt, labeling is zichtbaar, documentatie is actueel en belangrijke verbetermaatregelen zijn verwerkt.
Tijdens de review toont het team geen mooie demo alleen. Het laat de evidence-set zien: cijfers, grafieken, logregels, voorbeelden, afwijkingen, klachten en maatregelen.
CAPA staat voor Corrective and Preventive Actions. Eerst wordt het probleem hersteld. Daarna wordt onderzocht hoe herhaling wordt voorkomen. Tot slot wordt gemeten of de maatregel werkelijk effect heeft.
Kort samengevat in vier vragen: mogen we starten, is het echt af, zien we bewijs en wat is aantoonbaar verbeterd?
Ook een ingekocht systeem kan een belangrijke rol krijgen in klant- of personeelsbesluiten. Bovendien kan eigen training, aanpassing of nieuw gebruik de rol en risicoklasse veranderen.
De classificatie van de leverancier is een belangrijk startpunt, maar de organisatie moet beoordelen of deze past bij het eigen gebruik. Dezelfde techniek kan bij een andere doelgroep of procesplaats andere gevolgen hebben.
Beleid is opzet. Het is nog geen bewijs van bestaan en werking. Het bestuur moet kunnen zien welke versie actief is, welke data wordt gebruikt en wat de laatste monitoring laat zien.
De aanwezigheid van een akkoordknop bewijst geen menselijk toezicht. De medewerker moet begrijpen, kunnen ingrijpen, voldoende tijd hebben en zich vrij voelen om af te wijken.
De praktijk verandert na livegang. Daarom moeten fairness, drift, prestaties, klachten, incidenten en overrides blijvend worden gevolgd. Het echte toezicht begint pas wanneer het systeem live is en bewijs uit de praktijk beschikbaar komt.
Organisaties hoeven niet te wachten op een perfect, organisatiebreed programma. Een gerichte aanpak kan binnen drie maanden al veel duidelijkheid geven.
Begin met de AI-systemen die de grootste invloed hebben op klanten, medewerkers, financiën of kritieke processen. Leg per systeem vast:
Het resultaat is een eerste betrouwbare versie van het AI-register.
Maak per belangrijk systeem een compacte review-evidence-set. Koppel de belangrijkste eisen via de crosswalk aan processen, bewijs en eigenaren. Beoordeel vervolgens waar gaten zitten in:
Ieder gat krijgt een eigenaar en een datum.
Bespreek niet alle technische details. Gebruik de drie vaste vragen en laat per systeem een eenvoudige rood-oranje-groenstatus zien.
Eindig ieder dossier met een besluit: doorgaan, doorgaan onder voorwaarden, pauzeren of stoppen.
Bestuurders hoeven niet te weten hoe ieder algoritme technisch is opgebouwd. Zij moeten wel kunnen beoordelen of de organisatie begrijpt wat zij doet, de juiste verantwoordelijkheid neemt en de werking kan aantonen.
Daarvoor bieden rol, risicoklasse en bewijs een krachtige lens. De rol laat zien wie verantwoordelijk is. De risicoklasse laat zien hoe zwaar de beheersing moet zijn. Het bewijs laat zien of die beheersing werkelijk werkt.
Juist door steeds dezelfde drie vragen te stellen, kan een organisatie sneller besluiten. Teams weten vooraf wat zij moeten opleveren. De tweede lijn weet wat zij moet toetsen. Audit kan het spoor volgen. Het bestuur krijgt geen verzameling losse documenten, maar één samenhangend beeld.
Zo wordt AI-governance geen extra laag rond innovatie. Het wordt de werkwijze waarmee de organisatie verantwoord kan versnellen.
Van bestuurlijke AI-vraag tot DORA, SIRA, BCM of hersteltraject: plan een vrijblijvend gesprek met een specialist.