An oversight decision log records who made which decision about which AI system, based on what information, and with what caveat. That sounds simple. In practice, the first version often fails because it's set up as a new process alongside existing meetings. A second process next to the existing one gets ignored, not because people are unwilling, but because no one reserves time for something that doesn't fit into an agenda that is already full.
The log is not an activity logbook and not a risk register. It contains decisions: moments when someone with authority approved, rejected, postponed, or allowed something to proceed under conditions. Each line should include at least four elements: the system or application the decision concerns, the name and role of the decision-maker, the date, and the rationale or caveat. Without a rationale, a decision log is an attendance list. With a rationale, it becomes evidence that thought was given, not just that a box was ticked.
The log should also allow room for revision. A decision made six months ago based on information available at that time may be outdated. A good decision log shows when a decision was reconfirmed or reversed, not just when it was originally made.
Boards and executive teams already have a rhythm: quarterly meetings, risk committees, audit committees. Anyone who sets up a new oversight structure that stands apart from that rhythm is asking people to find extra time for something that has no clear place. That rarely happens structurally. It might work the first few times, with effort. After that, it drops off the agenda as soon as something more urgent comes along, and something more urgent always comes along.
The solution is not to build a new process, but to have the decision log ride along with what already happens. If there's already a risk committee that meets every quarter, the AI decision log should be a fixed part of that agenda, not a separate session. If there's already an audit trail for financial decisions, the logic of that trail — who signs off, who checks, where it's stored — should be reused for AI decisions. That's also why aligning with the existing risk structure is a separate topic: a decision log that doesn't align with how risk is already discussed elsewhere remains an isolated document that no one consults.
A decision log doesn't function on its own. It feeds the reporting that a board needs in order to say that there is visibility into AI risk, and it presumes there is a path for when a decision turns out to no longer hold up. Without a one-page board report that summarizes the decision log, the information disappears into an archive that no one browses through. Without escalation paths that work, an outdated decision simply remains in place, because no one knows whom to raise it with.
The three are connected: the decision log records what was decided, the reporting makes that visible at the level where it carries weight, and escalation ensures a decision can be reopened if the situation changes. Build one without the other two, and you create an illusion of oversight that, at the first real test — an incident, a question from a regulator, a journalist — fails to cover what is actually happening.
A decision log is only as good as the information that goes into it. If no one knows which AI systems are actually in use — including what has been acquired or set up outside of IT — then the log only records decisions about the visible, formally approved applications. The rest remains undecided, not because no decision was needed, but because no one knew there was something to decide on. That is why an inventory always precedes a decision log, not the other way around. What a board member should know about this is described in what a board member should know about AI risk; what a CIO should recognize in that inventory is described in what a CIO should know about AI risk.
What is certain: a decision log that isn't tied to an existing meeting doesn't get maintained, and a decision log without a complete picture of what's running only records part of reality. What depends on the organization: which meeting is the appropriate anchor point, how often that meeting takes place, and who has the authority to make a decision that ends up on the log. This differs by sector, by governance structure, and by risk culture, and therefore there is no fixed template that works everywhere without adaptation.
The Responsible AI Scan is under development. Anyone who currently needs a decision log that aligns with the existing structure can sign up for the waiting list; nothing is being offered yet that doesn't already exist.
A decision log states who decided, not how much work a system actually takes over or could take over. For that question — which part of a task can be transferred to AI, and which part cannot — a different lens is needed than governance alone provides. The work scan from FTE TO AI calculates, per task, which part of the work can be taken over, as a complement to the overview that a decision log and its accompanying oversight structure provide.
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.