If your board approved the AI budget, could it also explain the risk?

21 checks across six areas of board-level AI oversight: ownership, decision rights, human accountability, incident history, regulatory exposure, and whether the board itself is actually equipped to do this job. Check off what is genuinely in place, no email required to see your result.

Listen to this briefing

Stop Confusing AI Paperwork With Governance

0:00

Why this is a board question, not a management one

Most AI governance material is written for the people building or running the system: the CIO, the data team, the risk function. That is the wrong altitude for a board. A director does not need to understand model architecture. A director needs to know whether the organisation can prove, on request, that a specific person is accountable for a specific AI system's behaviour, and whether that person has actually been asked the hard question before something goes wrong in public.

The gap this checklist is built to surface is a specific one: the difference between an AI policy existing and AI oversight actually happening. A signed policy, a governance framework on file, and a slide in the last board pack are not evidence of oversight. Evidence of oversight is a named reviewer, a tested escalation path, and a board that has already asked what the system is not allowed to do, before it did it.

This checklist does not test your organisation's AI maturity. It tests something narrower and more useful to a director: whether this board, specifically, would be able to answer for an AI incident if a regulator, a journalist, or a shareholder asked about it tomorrow.

Not started

0/ 21

Start checking off items below to see where board oversight actually stands.

This is a self-assessment against your own understanding of board practice, not an independent governance audit or legal opinion. It is not legal, regulatory, or compliance advice, and the recommended steps below are a starting point for board discussion, not a substitute for a facilitated review or your own counsel's advice. Your answers stay in your browser and are not sent to Terence Kok or reviewed by anyone.

Section 1 of 6: Who Actually Owns AI Risk

Oversight Structure

Who Actually Owns AI Risk

0 / 4

Opens a 6-page report with your checked items, recommended next steps, and calculated score. Print or save it as a PDF from there.

What boards usually get wrong about AI oversight.

A Policy Is Not Oversight

Purpose

An AI policy sets direction. It does not prove anyone is checking that the direction is being followed. Boards routinely accept the existence of a policy, a framework, or a certification as evidence that oversight is happening, when none of those things describe what is actually reviewed, by whom, or how often.

Why It Matters
  • The organisations that get caught out are rarely the ones with no AI policy. They are the ones whose policy was never tested against a real incident
  • "We have a governance framework" and "a named person reviews this system's output every week" are different claims. Only the second is oversight
  • A board that cannot name its three largest AI risks has not been shown a risk register. It has been shown a summary
How to Use
  1. Treat any unchecked item in Sections 1 or 3 as the priority. Ownership and human oversight are the load-bearing sections
  2. Ask for evidence, not descriptions, when reviewing management's next AI update
  3. Re-run this checklist after any AI incident, near-miss, or major vendor change, not just once a year

The Question That Actually Tests It

Purpose

"What can this AI system do that we would not want it to do?" is a single question that separates real oversight from paperwork. If management can answer it specifically and without hedging, oversight exists. If the answer is reassurance rather than specifics, it likely does not yet.

Why It Matters
  • A vague answer ("we have guardrails in place") is not a boundary. A specific answer ("it cannot approve a payout above $X without a named reviewer") is
  • Boards that ask this question before an incident tend to catch the gap while it is still cheap to close
  • Boards that only ask it after an incident are, by definition, asking too late for that particular case
How to Use
  1. Put this exact question on the agenda for the next AI update, before the item covering incident history
  2. Expect a specific boundary as the answer, not a description of a general principle
  3. If no one in the room can answer it precisely, that gap belongs on the risk register today, not at the next review

From Checklist to Standing Agenda Item

Purpose

This checklist tells you where the gaps are today. It does not replace a facilitated board briefing, an independent review of your specific AI systems, or ongoing oversight as your AI programme evolves. Treat a high score as a good baseline, not a finished job.

Why It Matters
  • Boards that treat AI oversight as a one-time review rather than a standing item are routinely surprised by drift: the system in production is no longer the system that was approved
  • A single strong score today says nothing about six months from now, once the vendor has shipped a model update or the use case has expanded
  • The highest-leverage change most boards can make is simply putting AI oversight on a fixed cadence, rather than raising it only when prompted
How to Use
  1. Once you cross roughly 85%, the priority shifts from closing gaps to maintaining cadence
  2. Assign the unchecked items to a named owner, not to "management" generally
  3. If your board wants this run as a facilitated session rather than a self-assessment, that is a conversation worth having directly
ISO/IEC 42001 Lead Auditor badge

About This Checklist

This checklist was built by Terence Kok, a certified ISO/IEC 42001 Lead Auditor (BSI) who has unified AI governance frameworks across multiple regulatory environments (Singapore's IMDA, Saudi Arabia's NDMO, and Oman's TRA) under a single standard for an infrastructure group operating across all three. That work sits at exactly the altitude this checklist is written for: not the technical detail of how a model works, but the evidence a board, a regulator, or an auditor actually asks to see when they test whether oversight is real. The items above are drawn from where that evidence most often turns out to be missing.

See the full certification list →

Want this run as a facilitated board briefing instead?

This checklist tells you where the gaps are. Closing them, or walking your board through the findings directly, is a conversation worth having with me.

Book a private session