Een oversight-besluitenlijst registreert wie welk besluit nam over welk AI-systeem, op basis van welke informatie, en met welk voorbehoud. Dat klinkt eenvoudig. In de praktijk mislukt de eerste versie vaak omdat ze als nieuw proces wordt neergezet naast bestaande overleggen. Een tweede proces naast het bestaande wordt genegeerd, niet omdat mensen onwillig zijn, maar omdat niemand tijd reserveert voor iets dat niet aansluit op een agenda die al vol staat.
De lijst is geen logboek van activiteiten en geen risicoregister. Ze bevat besluiten: momenten waarop iemand met bevoegdheid iets goedkeurde, afwees, uitstelde of onder voorwaarden liet doorgaan. Per regel horen minimaal vier elementen: het systeem of de toepassing waarover het besluit gaat, de naam en rol van de besluitvormer, de datum, en de motivering of het voorbehoud. Zonder motivering is een besluitenlijst een presentielijst. Met motivering wordt ze het bewijs dat er is nagedacht, niet alleen dat er is afgevinkt.
De lijst hoort ook ruimte te bieden voor herziening. Een besluit dat een half jaar geleden is genomen op basis van toen beschikbare informatie, kan achterhaald zijn. Een goede besluitenlijst laat zien wanneer een besluit is herbevestigd of teruggedraaid, niet alleen wanneer het oorspronkelijk is genomen.
Besturen en directies hebben al een ritme: kwartaalvergaderingen, risicocomités, auditcommissies. Wie een nieuwe oversight-structuur optuigt die los staat van dat ritme, vraagt mensen om extra tijd te vinden voor iets dat geen duidelijke plek heeft. Dat gebeurt zelden structureel. De eerste paar keer lukt het misschien, met inspanning. Daarna verdwijnt het van de agenda zodra er iets urgenters langskomt, en er komt altijd iets urgenters langs.
De oplossing is niet een nieuw proces te bouwen, maar de besluitenlijst te laten meeliften op wat er al gebeurt. Als er al een risicocomité is dat elk kwartaal samenkomt, hoort de AI-besluitenlijst een vast onderdeel van die agenda te zijn, niet een aparte sessie. Als er al een auditspoor bestaat voor financiële besluiten, hoort de logica van dat spoor — wie tekent, wie controleert, waar het wordt opgeslagen — te worden hergebruikt voor AI-besluiten. Dat is ook de reden dat aansluiten op de bestaande risicostructuur een apart onderwerp is: een besluitenlijst die niet aansluit op hoe risico elders al wordt besproken, blijft een geïsoleerd document dat niemand raadpleegt.
Een besluitenlijst functioneert niet op zichzelf. Ze voedt de rapportage die een bestuur nodig heeft om te kunnen zeggen dat er zicht is op AI-risico, en ze veronderstelt dat er een pad is voor wanneer een besluit niet langer houdbaar blijkt. Zonder een board-rapportage van een pagina die de besluitenlijst samenvat, verdwijnt de informatie in een archief dat niemand doorbladert. Zonder escalatiepaden die werken blijft een besluit dat achterhaald is gewoon staan, omdat niemand weet bij wie hij het moet aankaarten.
De drie hangen samen: de besluitenlijst legt vast wat er is beslist, de rapportage maakt dat zichtbaar op het niveau waar het gewicht heeft, en escalatie zorgt dat een besluit kan worden heropend als de situatie verandert. Bouw je er één zonder de andere twee, dan ontstaat een schijn van overzicht die bij de eerste toets — een incident, een vraag van een toezichthouder, een journalist — niet blijkt te dekken wat er werkelijk gebeurt.
Een besluitenlijst is zo goed als de informatie die erin komt. Als niemand weet welke AI-systemen er daadwerkelijk in gebruik zijn — inclusief wat buiten IT om is aangeschaft of opgezet — dan registreert de lijst alleen besluiten over de zichtbare, formeel goedgekeurde toepassingen. De rest blijft onbesloten, niet omdat er geen besluit nodig was, maar omdat niemand wist dat er iets was om over te besluiten. Dat is waarom een inventaris altijd voorafgaat aan een besluitenlijst, niet erna komt. Wat een bestuurder daarover hoort te weten, staat beschreven in wat een bestuurder moet weten over AI-risico; wat een CIO in die inventarisatie hoort te herkennen, staat in wat een CIO moet weten over AI-risico.
Wat vaststaat: een besluitenlijst zonder aansluiting op een bestaand overleg wordt niet onderhouden, en een besluitenlijst zonder volledig beeld van wat er draait, registreert slechts een deel van de werkelijkheid. Wat afhangt van de organisatie: welk overleg het aangewezen ankerpunt is, hoe vaak dat overleg samenkomt, en wie de bevoegdheid heeft om een besluit te nemen dat op de lijst terechtkomt. Dat verschilt per sector, per bestuursstructuur en per risicocultuur, en daarom is er geen vast sjabloon dat overal zonder aanpassing werkt.
De Responsible AI Scan is in aanbouw. Wie op dit moment behoefte heeft aan een besluitenlijst die aansluit op de bestaande structuur, kan zich aanmelden voor de wachtlijst; er wordt nog niets aangeboden dat er nog niet is.
Een besluitenlijst zegt wie besliste, niet hoeveel werk een systeem daadwerkelijk overneemt of zou kunnen overnemen. Voor die vraag — welk deel van een taak zich laat overdragen aan AI, en welk deel niet — is een andere blik nodig dan governance alleen biedt. De werkscan van FTE TO AI rekent per taak uit welk deel van het werk over te nemen is, als aanvulling op het overzicht dat een besluitenlijst en de bijbehorende oversight-structuur bieden.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Antwoorden komen uit de kennisbank van deze site. Geen advies op maat, en geen scan van uw bedrijf.