Een oversight-besluitenlijst is geen nieuw formulier en geen nieuwe vergadering. Het is een vaste plek waar wordt vastgelegd welke AI-toepassing is beoordeeld, door wie, op basis van welke risico-inschatting, en met welk besluit. Goedgekeurd, afgekeurd, met voorwaarden, of tijdelijk toegestaan in afwachting van verder onderzoek. Zonder die lijst bestaat een besluit alleen in het geheugen van wie erbij was, en verdwijnt het zodra iemand van functie wisselt of het gesprek niet is genotuleerd.
De lijst bevat per toepassing een korte omschrijving van de taak, de classificatie naar rol en risiconiveau, de naam van de proceseigenaar, de datum van beoordeling, het genomen besluit en de reden daarvoor. Geen technische specificatie, geen leveranciersdocumentatie: dat hoort bij het dossier van de toepassing zelf, niet bij de besluitenlijst. De lijst is een overzicht op één niveau hoger — wie besliste wat, en wanneer dat besluit voor het laatst is herbevestigd. Een toepassing die een jaar geleden is goedgekeurd voor een taak met beperkt risico, kan inmiddels voor iets anders worden gebruikt. Zonder periodieke herbevestiging blijft een oud besluit gelden voor een situatie die niet meer bestaat.
De reden dat losse AI-registers vaak leeg blijven, is niet onwil maar volgorde. Iedere organisatie heeft al een plek waar risico's worden besproken en vastgelegd: een risicocomité, een auditcommissie, een directievergadering met een vast agendapunt over operationeel risico. Wie daarnaast een apart AI-logboek optuigt, vraagt mensen een tweede administratie te voeren voor iets dat inhoudelijk bij de eerste hoort. Dat tweede proces verliest het, structureel, van de waan van de dag. De oversight-besluitenlijst werkt alleen als hij is ingebed in wat er al is — als vast onderdeel van een bestaand overleg, met een vaste plek op de agenda, in plaats van als nieuwe verplichting ernaast.
Dat betekent ook dat de lijst dezelfde schaal en taal gebruikt als de rest van de risicostructuur. Een toepassing met een hoog risiconiveau krijgt hetzelfde soort aandacht als een ander dossier met een hoog risiconiveau: vaste rapportagefrequentie, vaste eigenaar, vaste escalatielijn. Hoe die koppeling er in de praktijk uitziet, hangt af van de bestaande governance van de organisatie en staat beschreven op de pagina over aansluiten op de bestaande risicostructuur.
Een besluitenlijst is nutteloos zonder een route voor wat er gebeurt wanneer iemand het er niet mee eens is, of wanneer een toepassing verandert zonder dat iemand het meldt. Die route hoort niet in de lijst zelf, maar moet er wel op aansluiten: wie een afkeuring wil aanvechten, wie een tijdelijke toestemming moet verlengen, en bij wie een zaak terechtkomt als de proceseigenaar en de risicofunctie het niet eens zijn. Hoe die lijnen lopen zonder dat iedere vraag bovenaan de organisatie belandt, staat beschreven bij escalatiepaden die werken.
De besluitenlijst is het geheugen; het bestuur heeft daarnaast een samenvatting nodig die niet ieder kwartaal opnieuw hoeft te worden samengesteld uit losse notulen. Wat er op die samenvatting moet staan — en wat juist niet, omdat het al in de besluitenlijst zit — staat op de pagina over een board-rapportage van een pagina. Zonder die stap blijft de besluitenlijst een document dat alleen de proceseigenaren lezen, terwijl het bestuur juridisch verantwoordelijk blijft voor wat er wordt beslist.
Een besluit vastleggen is niet hetzelfde als weten of het besluit wordt nageleefd. Een toepassing die is afgekeurd, kan alsnog in gebruik blijven als niemand controleert of de afkeuring is doorgevoerd. Dat is de reden dat een besluitenlijst zonder vervolg weinig oplevert: hij documenteert intenties, niet gedrag. Wat er nodig is om te zien of een besluit ook standhoudt, en welke signalen daarbij horen, staat op de pagina over monitoring die iets oplevert.
Een besluitenlijst kan alleen bevatten wat er is aangemeld. Wie afhankelijk is van meldingen via de IT-afdeling, ziet een fractie van wat er werkelijk wordt gebruikt: het grootste deel van AI-gebruik in een organisatie ontstaat buiten formele aanschaftrajecten, in teams die een tool proberen omdat het werkt. Of die toepassingen ooit op de besluitenlijst belanden, hangt af van of medewerkers durven te vertellen wat ze gebruiken — en dat gebeurt alleen als vragen ernaar niet als voorportaal voor een sanctie aanvoelen.
De eerste vraag die daarbij helpt, is niet 'welke AI is goedgekeurd' maar 'welk deel van dit werk wordt eigenlijk al, of zou kunnen worden, door AI gedaan'. Dat is een andere ingang dan een besluitenlijst, en een vollediger vertrekpunt: de werkscan van FTE TO AI rekent per taak uit welk deel van het werk over te nemen is door AI, en legt daarmee een basis die niet afhangt van wat toevallig is aangemeld. Vanuit die uitkomst wordt zichtbaar welke toepassingen er eigenlijk al draaien voordat de besluitenlijst er ooit van wist.
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.