Kennisbank

A board report that connects to what the board already reads

A board receives periodic reports: financial, operational, on risks that already have a place in the existing structure. A report on AI that stands apart from that, with its own rhythm and its own format, gets skipped over in practice. Not because the subject is unimportant, but because a second process alongside an existing process demands a separate effort that competes with everything already on the agenda. What does get read is what fits within the existing reporting line: the same rhythm, the same length, the same place in the meeting.

What belongs on that one page

A board report on AI has no need for a complete technical inventory. The board needs an answer to a limited number of questions: which AI applications exist, which risk category do they fall into, what has changed since the previous report, and have there been any escalations. That last point is where most reports come up empty — not because nothing happens, but because no route exists along which a signal can reach the board. Without working escalation paths that work, a report is a snapshot without history: it shows what exists now, not what went wrong along the way or nearly went wrong.

The report relies on what is already established. An oversight decision log of who approved what is the source from which the page is summarized, not a separate document that exists alongside it. What appears on the page is a condensation of decisions already made; it is not a new assessment the board itself has to make based on raw data.

Why a second process gets ignored

Organizations already have a risk structure: an audit committee, a risk committee, a fixed place on the board agenda for operational risks. An AI report that introduces its own committee, its own calendar, or its own template asks everyone already involved to do something extra on top of what they already do. That extra work gets postponed as soon as the agenda fills up, and the agenda always fills up. The result is that the report falls away after a few times, not because someone decided AI risk isn't important, but because no one decided it was more important than what was already there.

The solution does not lie in placing more emphasis on the subject, but in reducing the friction of incorporating it. A page that appears in the same quarterly rhythm as the other risk reports, that uses the same layout and sits in the same place in the package, gets read because reading it doesn't require a separate action. What does not work is a separate AI governance cycle that runs apart from the existing cycle — that gets ignored as soon as the first busy month arrives.

What the page assumes already exists

A one-page report can only be short if the underlying structure is complete. It assumes a what should a board member know about AI risk-type overview of roles and responsibilities, so the page doesn't have to explain every time who is responsible for what. It assumes an inventory that includes not only what IT has approved, but also what departments have started using on their own without reporting it — shadow AI that only becomes visible once people are allowed to say what they actually use without consequences. A report that shows only the approved list is reporting a fiction.

The page also assumes that something happens between the reports: monitoring that produces something instead of a log that nobody consults. Without that intermediate layer, the quarterly page is a surprise every edition, instead of a summary of something that has already been tracked throughout the quarter. And it assumes that the underlying policy is not documentation for form's sake, but an AI policy that gets read by the people who use the systems daily — because a report on compliance with a policy nobody knows about mainly reports on itself.

What a CIO adds to the report

The board page is a condensation; the substantiation sits one layer deeper, with whoever knows the systems. What a CIO contributes to that is described at what should a CIO know about AI risk, and those two layers — board-level overview and operational knowledge — need to connect before the page that takes fifteen minutes to read actually says something about what is happening in the organization.

This structure is being built up, not offered as a finished product. Anyone who wants the scan that delivers this inventory, classification, and reporting structure goes on a waiting list; it is under construction and is not sold as a ready-made instrument before it actually is one.

The question that follows the report

Once it is clear which AI is running and which risk category it falls into, a different question follows, one that is not about risk but about how the work itself is organized: what portion of the tasks currently being performed lends itself to being taken over by AI. That is a separate calculation, built not on risk but on tasks. The work scan from FTE TO AI calculates, per task, what portion of the work is eligible for takeover, as a follow-up step once it is clear what AI already exists within the organization.