Every organisation of some size already has a risk structure. A risk committee, an audit function, a reporting line to the board, a format in which risks are classified and tracked. Anyone who puts a new process next to that, specifically for AI, with its own committee, its own calendar and its own language, will within a year have a process that nobody fills in anymore. Not because AI is considered unimportant, but because a second structure competes with the first for time, attention and mandate. The existing structure almost always wins, because it is embedded in appraisals, performance cycles and board agendas. The new structure sits outside of that.
The question, then, is not how you build an AI governance structure. The question is how AI gets a place in the structure that already exists.
Most risk structures already have a number of fixed components: a risk inventory that is updated periodically, a classification by severity and likelihood, an owner per risk, an escalation line to a higher level when a threshold is exceeded, and reporting to the board at fixed moments. That is the structure into which AI must fit, not alongside it.
That means an AI application should not be listed in a separate AI register, but as a risk item in the existing register, with the same fields as any other risk: owner, severity, likelihood, mitigation, status date. The classification by risk level that belongs to an inventory of AI use must align with the scale already used for operational risk, not with a new scale invented solely for AI. Anyone reading what a cio should know about ai risk will see that this alignment is precisely where things often go wrong: a technically correct AI risk score that nobody can compare with the rest of the risk register.
Two things make embedding difficult. The first is language. Risk managers work with concepts such as impact, likelihood and mitigating measure. AI vendors and technical teams work with model versions, training data and performance metrics. A governance set written only in technical language will not be read by the risk committee. A governance set written only in risk language will not be filled in by the technical owner. The set must be readable in both directions: technical enough to be correct, governance-oriented enough to land. That principle recurs in an ai policy that gets read: a document that aligns with how people already read and decide, rather than demanding a new way of reading.
The second is pace. A risk committee meets on a fixed cycle, often quarterly or monthly. AI use changes faster: a team starts with a new tool this week, without a meeting preceding it. The governance set must therefore not depend on the meeting cycle to function. There must be a lighter mechanism that catches deviations between the fixed moments, and that is only formally confirmed at the next cycle. How that mechanism works in practice is described at escalation paths that work: a route short enough to be used before the next quarterly committee convenes.
A governance set that aligns with an existing risk structure contains, in broad terms: an inventory item per AI application with an owner and risk class, a link to the existing escalation path so that a deviation does not disappear into a separate channel, and a fixed place in the periodic reporting to the board. Not as a separate chapter on AI, but as a line in the table the board already knows. What that reporting can look like without introducing a new format is described at how do you get a one-page board report embedded in what already circulates.
The content of the rules themselves, exactly what falls under which risk level and which timelines apply, is recorded elsewhere and changes over time; this page is about the mechanism that gives that content a place in the existing structure, not about the text of those rules.
Embedding only succeeds if the inventory is accurate to begin with. And it is only accurate if people dare to say what they use. Anyone who, when filling in the risk item, senses that an honest answer will lead to a note in an appraisal, will not fill it in honestly. The governance set must therefore make clear from the very first version that the goal is oversight, not sanction. Without that commitment, part of the usage remains out of view, and the alignment with the risk structure is built on an incomplete list. What a board member needs to know about this before the first inventory starts is described at what should a board member know about ai risk.
This embedding is about risk, ownership and reporting: it ensures that what AI does is visible and manageable within the structure that already exists. A different question, which logically follows once that overview is in place, is what AI can actually take over within that work. The work scan from FTE TO AI calculates per task which part of the work can be taken over by AI, as a follow-up step once the governance side is in order.
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.