Kennisbank

Monitoring that is actually used

The problem is not the absence of monitoring

Most organizations already have something called monitoring. A dashboard, a reporting format, a periodic meeting where risks are discussed. The problem is not that this is missing. The problem is that AI monitoring is set up as a separate component alongside it, with its own rhythm, its own owner, and its own template. Anyone who already has three processes to track risk is not going to faithfully fill in a fourth one. It becomes an obligation that gets rushed through once a quarter, or not at all.

That is why monitoring of AI use so often delivers nothing. Not because the questions are wrong, but because the process itself remains a foreign body within an organization that already has processes for risk, compliance, and internal control.

What belongs in genuine monitoring

Monitoring that delivers something does not start with a format but with a question: what is changing, and who notices that first? For AI systems this means three layers.

The first layer is use: is a system still being used as intended, or has the application shifted without anyone reporting it? A tool that started as text checking and is now used to formulate draft decisions is a different risk than was established at the start.

The second layer is origin: is the system still the same as when it was classified? Underlying models are replaced, suppliers change their terms, a standalone tool is integrated into a larger platform. Every change can invalidate the risk assessment made at the time without anyone reassessing it.

The third layer is signal: are there complaints, error reports, or deviations indicating that something is not working as assumed? This is the layer that is most often missing, because no one has an interest in reporting a problem with a system that officially does not exist.

Why a second process gets ignored

An organization that already has a risk cycle for operational risks, financial risks, or data protection is not going to start a new cycle for AI. That is not unwillingness; it is a matter of capacity. Anyone who tries sees two things happen. Either the new monitoring runs dry, because no one finds time to feed a system that no one asks about. Or the new monitoring is taken over by the same people who already run the existing cycle, and then the distinction disappears on its own.

The question, then, is not whether a separate AI monitoring process should be created. The question is how AI signals end up in the existing cycle, so that they are discussed in the same meeting, with the same owner, and at the same rhythm as other risks. How exactly that is set up depends on how that existing cycle already works: some organizations have a quarterly report to the audit committee, others a monthly risk meeting at management level, and others still a continuous log updated per incident. More on how you embed monitoring into what is already running instead of setting up something alongside it can be found on a separate page, because that mechanism is implemented differently per organization.

The document that is there when someone asks about it

What does fit universally is a fixed format in which the status of AI systems is recorded: what is running, in what role, at what risk level, and when that was last confirmed. Not as a separate AI document, but as an appendix or fixed part of the reporting that already exists. This can connect to a one-page board report that summarizes risks without glossing over them, so that monitoring does not become a separate stream of information, but a line in a table that the director already reads.

This format only works if the underlying classification itself stays current, and that classification in turn needs to connect to the risk structure that already exists. Without that connection, monitoring remains a second language alongside the first, and that second language gets forgotten as soon as pressure increases. What that connection looks like depends on how risk structure and AI classification come together in what an organization already uses, and cannot be described in general terms without knowing the existing structure.

What monitoring finds goes beyond a document

Monitoring that works well signals not only risk but also shift: systems being used differently than intended, or tasks that have quietly been taken over without anyone recording it. Those same signals are also information about where people are actually spending their time, and where AI is factually already taking over work without that being written down anywhere. Anyone who wants to make that question more concrete than a risk classification allows can see, via the work scan from FTE TO AI, which part of the work per task is suitable for AI, regardless of whether that is already happening or still needs to be decided. That scan does not measure in risk, but in tasks and hours, and thereby connects to what monitoring signals without explaining it.