A board that puts AI on the agenda is usually offered two kinds of documents: a thick dossier that no one reads before the meeting, or a summary that says so little that no decision follows from it. A one-page board report is not a summary of the dossier. It is a different question: what does a board member need to know to be able to take responsibility, and what is noise.
That distinction is not trivial. Most AI reports we see count systems. A page that only counts how many AI applications there are tells a board nothing about where the risk lies. Counting is an IT question. Governance is a different question: which applications affect decisions about people, which have been put into use without oversight, and which fall under a risk class that requires a signature.
A page that works contains a limited number of elements, each with a reason for being included:
The rest — who trained which model, which supplier applies which terms, which technical mitigation has been applied — belongs in the layer below. That layer exists, is maintained, and can be requested. But it does not belong on the page the board reads, because then the board will not read it.
The reason so much AI governance stalls is not that there is no process. It is that there is a second process, alongside the existing one. A board already has a risk committee, already has an audit calendar, already has a format for reporting on operational risk, on compliance, on information security. Anyone who puts a separate AI process next to that — with its own frequency, its own template, its own owner — is asking for something that gets skipped first when the agenda is too full. That does not happen out of unwillingness. It happens because a second process by definition gets less attention than the first.
The report that does get read is the report that runs along in the existing rhythm: the same meeting, the same format, the same way of escalating that already exists for other risks. How that alignment takes shape in practice is described on the page about aligning with the existing risk structure, and the way decisions are subsequently recorded is covered on the page about an oversight decision log that runs along in the existing rhythm.
A one-page report is only usable if the inventory behind it is correct. That is the part that gets skipped most often: board members receive a page with a risk classification, without anyone having checked whether the underlying list of AI applications is complete. Shadow AI — the use that has arisen outside the IT list — then silently disappears from view, not because it is unimportant, but because no one asked about it. An employee who uses an AI tool without it having been approved will not report that on their own if a reckoning looms. They only report it once questions are asked without consequences.
The page, then, is the tip of a process that begins with the inventory and escalates via paths that already exist. How that escalation works without creating a new hierarchy is described on the page about escalation paths that are actually used. And what needs to be structurally maintained to be able to fill in the page again each time without it becoming a reconstruction is described on the page about monitoring that actually yields something for reporting.
The Responsible AI Scan delivers the inventory, the classification, and the governance structure that aligns with what already exists — including the format for a report that the board actually reads. The scan itself is under construction; anyone who wants something usable now can join the waiting list.
A report that states which part of the work falls under AI risk naturally raises another question: which part of the work itself can be taken over by AI. That is a different calculation, made per task rather than per system, and that calculation is made by the work scan of FTE TO AI.
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.