re-ai-gov Join the waiting list

Kennisbank

Monitoring that works is monitoring that connects to what is already in place

Much monitoring of AI use comes into being as a separate initiative: a new form, a new meeting, a new dashboard. It looks complete at the moment of launch. A year later it has faded away. Not because the content was bad, but because it stood next to the existing structure instead of within it.

The question, then, is not only what needs to be monitored, but where that monitoring lands. A process that no one has to remember because it is already part of a routine that is running anyway, survives. A process that asks an extra step from people who are already at capacity gets skipped over time. That is not unwillingness. It is a predictable consequence of how organizations deal with time and attention.

Why a second process loses out

Every organization already has a rhythm: quarterly reports, risk committees, audit cycles, team meetings. If monitoring of AI use introduces a new rhythm, it competes with everything that already exists — and usually loses. There is no agenda item for it, no owner who sees it as a core part of their role, no moment where it naturally comes up.

If, on the other hand, monitoring becomes a question that is already being asked — in the existing risk committee, in existing internal controls, in the existing reporting line to the board — then no one has to remember something new. The question "which AI applications have been added or changed" then becomes just as natural as "are there new suppliers" or "have there been any incidents". Exactly how that connection takes shape depends on how connecting to the existing risk structure is already set up at your organization — that structure is the point of engagement, not something alongside it.

What belongs in the document

A working monitoring document is short enough to be used repeatedly and specific enough to report something when it changes. It contains, at a minimum:

The value of the document does not lie in completeness on day one. That is rarely achievable and also not necessary. The value lies in the fact that it is kept up to date, and that keeping it up to date does not require a separate effort on top of what already happens.

Why accountability for consequences stops the information

Monitoring depends on what people are willing to report. As soon as reporting becomes equivalent to running the risk of being held accountable for something, the information stops. Someone who completes a task faster than expected using an AI tool will not report that if the consequence is a withdrawal of budget or an uncomfortable conversation. The list then remains formally complete and substantively empty — precisely the problem that sustains shadow AI.

The consequence is that monitoring only works if questions are asked without consequences attached. Not because use should remain without consequences, but because the first step — knowing what is going on — requires a different attitude than the second step — assessing whether it is appropriate. Anyone who lets those two steps coincide gets no honest answer to either.

That distinction is also where governance and accountability meet. Visibility for the board does not have to mean that every individual application is put on the table; it is about a level of reporting that allows for a judgment without getting bogged down in detail, as described in a board report that fits on one page. What lies beneath that — the recording of decisions about specific applications — belongs more in an oversight decision log than in the document that goes upward.

Whether a policy document itself is read is a similar question: a text that no one consults offers no more guidance than a monitoring process that no one fills in. See an AI policy that gets read for that. And for those wondering which part of this responsibility belongs at the boardroom table and which part belongs to IT governance, there is a distinction between what a board member needs to know about AI risk and what a CIO needs to know about AI risk — both call for different levels of detail within the same monitoring process.

From knowing what is running to knowing what it delivers

A monitoring structure that connects to what is already in place will, at some point, deliver a reliable picture of which AI applications are in use and for what. That inventory is a different question from how much of the underlying work is actually being done by AI, and with what effect. Anyone who wants to have that calculated per task — which part of a role or process can be transferred to AI, based on the tasks as they are currently carried out — will find that in the work scan from FTE TO AI.

Andrewde assistent van de Responsible AI Scan

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.