AI Governance in Practice: Telling Real Board Oversight From Governance That Only Looks Reassuring

Two organisations bought the same AI tool in the same quarter. Same vendor, same contract, same glossy demo. Eighteen months later, one board can tell you exactly which decisions that tool touches, who owns the risk, and what happens when it gets something wrong. The other board can tell you it approved a policy and that the reports look fine. Then a customer is wrongly declined, a journalist asks a question, and the second board discovers that “the reports look fine” was never the same thing as being in control. Same tool, opposite governance. The difference was never the technology.

Governance is what you can demonstrate, not what you feel

Good AI governance is not a feeling, and it is not a policy sitting in a drawer. It is a set of things a board can demonstrate on demand. When a regulator, an auditor or a wronged customer asks how the board oversees its AI, the well-governed board reaches for evidence and the poorly governed board reaches for reassurance. This matters because King V judges the discharge of the governing body’s duty against outcomes, not intentions. Survey work by the Financial Sector Conduct Authority and the Prudential Authority found adoption rising while board-level oversight lagged, with explainability and model risk repeatedly flagged as gaps. The lesson is blunt. A board that cannot show its work has not done the work. Hold every marker that follows to that standard: can the board evidence it? If not, it is aspiration, not oversight.

Six markers of a board in control

The first marker is a named accountable owner. Not a committee, not a function, not “IT” in the abstract, but a person at a senior level who owns the organisation’s use of AI and whom the board can call to account by name. Diffuse accountability is the same as no accountability, because when something goes wrong everyone can truthfully point elsewhere. The second is a living inventory of AI systems in use, revisited on a known cadence. Shadow adoption is now the norm: a team runs customer queries through a generative tool, a recruiter trials a screening product, a finance analyst automates a classification, and none of it appears on a register drawn up two years ago. Surprise, in governance terms, is failure. The third is a risk classification the organisation owns. Every system on the inventory should carry an assessment of what could go wrong and how much it matters, because a chatbot answering opening-hours questions is not the credit model deciding who gets a loan. The trap is accepting the vendor’s risk rating as your own; the vendor rates its product in the abstract, not your use, your customers or your regulatory context.

The fourth marker is a human-oversight specification for each system, set commensurate with its risk. This connects to King V’s Recommended Practice 109(c)(ii), which calls for clear accountability for decisions, actions, outputs and outcomes. Oversight is not one organisational setting you switch on: a low-risk system might need periodic sampling, while a high-consequence system needs a human who understands its limits and has both the authority and the practical ability to stop it. A named human who rubber-stamps is not oversight; it is automation bias wearing a badge. The fifth marker is bringing vendor-supplied AI inside your governance rather than leaving it outside. Most AI a board oversees is not built in-house; it arrives embedded in a procured platform or a software update, and the instinct is to treat the contract as the control. That instinct is wrong: a tool bought from a third party still produces outputs in your name, affecting your customers and creating your exposure, so it belongs in your classification, your oversight specification and your incident processes. The sixth marker is incident capture and escalation, because a model will drift, an output will be discriminatory, and a system will produce something confidently false. The question is never whether, only what happens next. A useful illustration, persuasive only and binding on no one, is the Canadian small-claims matter of Moffatt against Air Canada, in which an airline’s chatbot gave a customer wrong information and the airline was held to own what its automated tool had told that customer.

Activity is not exposure

Here is the distinction that separates a board that governs from a board that merely receives paper. Weak AI reporting shows activity. Strong AI reporting shows exposure. An activity report tells the board how busy everyone has been: the tool processed so many queries, the policy was updated, training was completed, a quarterly review took place. It reads as reassurance and answers no question that matters. An exposure report tells the board what it is on the hook for: which decisions AI now touches, where the concentration of risk sits, what incidents occurred and how they were handled, and what is trending in the wrong direction. The most common failure at board level is the belief that approving a policy and receiving a quarterly report discharges the oversight duty. It does not. A policy is an intention and a quarterly activity report is a comfort blanket, and under King V the board is judged on the adequacy of its oversight. A board that mistakes activity for exposure is not overseeing; it is being managed.

Accountability cannot be outsourced

This is the point the whole discipline turns on: accountability for AI outputs cannot be transferred to a vendor. You can outsource the building of a system, its hosting, its maintenance, even its monitoring. What you cannot outsource is your accountability for what it does in your name. King V’s Recommended Practice 109(c)(ii) puts clear accountability for decisions, actions, outputs and outcomes at the centre of the governing body’s duty, and there is no clause that lets a board hand that accountability out with a purchase order. Enforcement itself is a moving target: the Italian regulator’s fifteen-million-euro fine against OpenAI made headlines as a landmark, and the Court of Rome then annulled it in March 2026 on reasoning that turned on jurisdiction rather than the merits, so it is no longer a standing outcome. What that history shows is simpler than any single ruling. Enforcement is contested, reversed and rewritten, but the board’s accountability for its own organisation’s AI does not move with the headlines. It stays exactly where it started, with the board.

Read two board packs

Put it to work. Imagine two board packs on the same table. The first opens with a named AI owner, a dated inventory of live systems, a risk classification the organisation made and recently revisited, oversight specified per system with real intervention rights, vendor tools folded inside the same discipline, a log of incidents with the serious ones escalated, and a page that tells the board precisely where its exposure sits. The second opens with a policy approved last year and a slide showing how many queries the tool handled this quarter. You do not need to be a technologist to tell these two boards apart: one can demonstrate its oversight, the other can only describe its hopes. So the question to carry back to your own boardroom is not “do we have an AI policy?” Almost everyone does, and it proves almost nothing. The sharper question is this: if a regulator, an auditor, or a customer you have wronged asked your board to demonstrate how it oversees the organisation’s use of AI, what could you actually show them?