You manage a risk register built around risks that can be identified, weighed, and assigned. Operational risk, credit risk, compliance risk: each has an owner, a control measure, a reporting line. AI risk does not fit naturally into that pattern, because the first problem is not the weighing. The first problem is that you do not know what you are weighing. A team that uses a language model to write draft advice, a department that has taken out an external AI subscription outside of IT procurement, a spreadsheet macro that has by now become a predictive model: these are not edge cases, this is where the risk sits, and it appears nowhere.
Your question is not "is AI risky". Your question is: what is running, who is responsible for it, and on what information can I account for that to the board and the supervisor. The answer you do not accept is reassurance without substantiation. "Nothing unusual is going on" is not an answer to a risk question, it is the absence of an answer. A risk manager who passes that on to the board is passing on that nothing has been looked at, not that there is nothing there.
The second answer you do not accept is the list from IT system management as the complete picture. That list shows what has been requested and approved. AI use largely arises precisely outside of that request process, because a standalone subscription, a browser extension, or a built-in feature in existing software is not recognized as a "new system". Anyone who wants to know the risk must therefore not only consult the system landscape, but the people doing the work, and that requires a different approach than an IT audit.
As a risk manager, you know the pattern of under-reporting on any risk topic where an employee has something to lose by answering honestly. AI use is a stark example of this: if reporting a tool that is being used results in access being revoked, no one will report it anymore. The inventory that yields something is the inventory that asks without attaching consequences to the answer. That is a different skill than risk control normally requires, and it is why a shadow-AI inventory is not set up as a control, but as a survey.
Once usage is mapped, the next step is not evaluating the vendor or the model. It is evaluating the role the system plays in a process. An AI application that rephrases text carries a different risk than an application that contributes to a decision about a customer, an employee, or an investment. The same technology, deployed in a different role, falls into a different risk class. That distinction is precisely what a risk register needs in order to place AI risk alongside the risks already in it, without creating a separate, isolated AI chapter that no one consults.
A risk manager has no interest in a new framework alongside the existing one. The interest lies in a governance set that connects to the risk structure already in place: the same ownership logic, the same escalation paths, the same reporting cycle to the board. AI risk treated as a standalone topic disappears between the regular reports. AI risk embedded in the existing risk taxonomy remains visible in the place where the board already looks.
At some point you will be asked what you know about AI use in the organization, by a supervisor, an auditor, or the board itself. The answer that holds up is not "everything has been mapped", because that is rarely something that can be substantiated for a dynamic usage pattern. The answer that holds up is a demonstrable process: how the inventory was conducted, what classification was applied, what governance arrangements follow from it, and at what frequency this is repeated. That is a different bar than completeness, and it is the bar against which risk management is normally already assessed.
This question does not present itself identically for every role in the organization. What a compliance officer needs from this inventory can be read in what does a compliance officer need to know about AI risk, the governance question of who drives the program is in what does an AI program lead need to know about AI risk, and how this topic lands at the level of the board itself is described in what does a board member need to know about AI risk. For risk management in specific sectors, with their own supply chains and forms of oversight, the picture is further refined in what AI governance looks like in construction and in what AI governance looks like in the installation sector.
The text of the applicable rules, with their precise definitions and deadlines, is not on this page and is kept up to date elsewhere. What is described here is the mechanism: how you go from an unknown usage pattern to a classifiable, reportable risk.
An inventory of AI risk inevitably brings something else into view as well: which part of the work is already factually being done by AI, and which part could be. That is a different question than risk control, but it shares the same source. FTE TO AI's work scan calculates per task which part of the work can be taken over by AI, and thereby connects to precisely the inventory that risk management already needs.
The Responsible AI Scan is currently being developed. Anyone who wants to use it once it becomes available can sign up for the waiting list.
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.