An oversight decision log is not a new form and not a new meeting. It is a fixed place where it is recorded which AI application has been assessed, by whom, based on which risk assessment, and with which decision. Approved, rejected, approved with conditions, or temporarily permitted pending further review. Without that list, a decision only exists in the memory of those who were present, and disappears as soon as someone changes roles or the conversation was not minuted.
The list contains, per application, a brief description of the task, the classification by role and risk level, the name of the process owner, the date of assessment, the decision taken and the reason for it. No technical specification, no supplier documentation: that belongs with the file of the application itself, not with the decision log. The list is an overview one level up — who decided what, and when that decision was last reconfirmed. An application that was approved a year ago for a task with limited risk may by now be used for something else. Without periodic reconfirmation, an old decision keeps applying to a situation that no longer exists.
The reason separate AI registers often stay empty is not unwillingness but sequence. Every organization already has a place where risks are discussed and recorded: a risk committee, an audit committee, a management meeting with a standing agenda item on operational risk. Anyone who additionally sets up a separate AI log is asking people to keep a second administration for something that substantively belongs with the first. That second process loses out, structurally, to the pressures of the day. The oversight decision log only works if it is embedded in what already exists — as a fixed part of an existing meeting, with a fixed spot on the agenda, rather than as a new obligation alongside it.
That also means the list uses the same scale and language as the rest of the risk structure. An application with a high risk level receives the same kind of attention as any other file with a high risk level: a fixed reporting frequency, a fixed owner, a fixed escalation line. What that link looks like in practice depends on the organization's existing governance and is described on the page about aligning with the existing risk structure.
A decision log is useless without a route for what happens when someone disagrees with it, or when an application changes without anyone reporting it. That route does not belong in the list itself, but it does need to connect to it: who can challenge a rejection, who needs to extend a temporary permission, and who a matter goes to when the process owner and the risk function disagree. How those lines run without every question ending up at the top of the organization is described under escalation paths that work.
The decision log is the memory; the board additionally needs a summary that does not have to be reassembled from separate minutes every quarter. What should be on that summary — and what should not, because it is already in the decision log — is described on the page about a one-page board report. Without that step, the decision log remains a document that only process owners read, while the board remains legally responsible for what is decided.
Recording a decision is not the same as knowing whether the decision is being followed. An application that has been rejected can still remain in use if no one checks whether the rejection was implemented. That is why a decision log without follow-up yields little: it documents intentions, not behavior. What is needed to see whether a decision actually holds, and which signals go with that, is described on the page about monitoring that yields something.
A decision log can only contain what has been reported. Anyone relying on notifications through the IT department sees a fraction of what is actually being used: most AI use within an organization arises outside formal procurement processes, in teams that try a tool because it works. Whether those applications ever end up on the decision log depends on whether employees dare to say what they use — and that only happens if asking about it does not feel like the anteroom to a sanction.
The first question that helps here is not 'which AI has been approved' but 'which part of this work is already being done, or could be done, by AI'. That is a different entry point than a decision log, and a more complete starting point: the work scan from FTE TO AI calculates per task which part of the work can be taken over by AI, laying a foundation that does not depend on what happens to have been reported. From that outcome, it becomes visible which applications are actually already running before the decision log ever knew about them.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.