Governing AI at scale, in three moves

Most AI governance does not scale. A firm starts with a handful of AI systems and a checklist, adds more systems, adds more frameworks, and the checklist grows faster than the AI does. Past a point, governance itself becomes the constraint on adoption. If AI use is going to scale, governance has to scale with it. This page sets out how, in three moves: govern to a common spine, govern with the unit that scales, and govern as a system rather than a checklist. It draws on the guidelines I wrote for Singapore's financial sector, and on the fuller treatment in my book, Some Thoughts on Scaling AI Governance.

Why AI governance stops scaling

Two things multiply. The number of frameworks a firm has to answer to, and the number of AI use cases it has to govern. Twenty frameworks, two hundred use cases, a control checklist that runs to hundreds of questions each. Multiply those out and you get millions of checks, and ticking all of them still would not tell you the AI is safe. A checklist that grows with every new framework and every new use case is not governance that scales. It is work that scales.

Govern to a common spine

Strip the packaging off different AI governance frameworks and they converge on the same three questions:

• What's at risk?
• How do we manage it?
• Who's accountable?

Find what's risky, manage it, own it. That is the spine.

The convergence is real, not rhetorical. Singapore's AI Risk Management Guidelines (November 2025) are supervisory expectations a regulator holds firms to. The Financial Stability Board's Sound Practices for the responsible adoption of AI (June 2026) are global and explicitly non-binding. Different source, scope and force, yet they share the same skeleton almost section for section: both split organisation-wide governance from lifecycle management, both organise around proportionality, both describe a similar inventory. The NIST AI Risk Management Framework converges on the same shape. So a firm does not need twenty governance programmes. It needs one backbone built on the core questions, structured from a current framework and adapted to context.

Agentic AI does not break this. The questions hold; they point somewhere new. "What's at risk?" becomes what an agent can do, and how far it can go before it has to stop. "How do we manage it?" moves from checking outputs to bounding actions. "Who's accountable?" sharpens what a firm would answer for when an agent acts on its own.

Govern with the unit that scales

"What are the use cases?" is the wrong first question for control. A use case is the least scalable thing to govern: one named use case can hide ten different risks underneath, two firms can mean completely different things by the same label, and at two hundred use cases the same patterns repeat, so the same work gets redone each time a pattern reappears under a new name. A use case is the right unit to decide whether to build. It is the wrong unit to decide how to control.

The AIRG rests on three units you can point a control at: the model, the system around it (prompts, tools, memory, retrieval, guardrails), and the use case. All three are specific, tied to one application, so the work never compounds. Above them sit three units that generalise:

• The archetype. A bounded shape such as retrieval, summarisation, classification or extraction. Write the controls for retrieval once, and every retrieval system in the firm draws from them.
• The capability. What an agent can actually do in the world, with the authority it is granted and the evidence it must produce. "Retrieve a transaction history" and "move money between accounts" are different capabilities with different bars. Govern the handful a firm relies on once, and the next system costs almost nothing to govern.
• The workflow. How far an agent can go: the branches, the approval gates, the points where it must stop and ask, designed up front and checked against what it actually did.

Governing patterns instead of instances is what lets governance keep up as the number of AI systems grows. The question worth asking is simple: of the six units, which is your AI actually governed at, and is it the one that can keep up as the count climbs?

Govern as a system, not a checklist

No control governs anything on its own. Explainability means little without selection, evaluation and a standard matched to the purpose. Human oversight leans on the monitoring that informs the overseer. Fairness depends on the features in your data. Pull on any control and you find the others it interlocks with. That is the difference between a checklist and a system: a checklist adds, box after box; a system multiplies, each control bracing the others.

Three controls hold the core together:

• Identify your AI. Miss a system and it runs ungoverned, because as far as your governance is concerned it does not exist. The hard cases are the vendor "smart feature", the old regression model, and the point at which a retrain or a swapped step turns one AI thing into a different one.
• Keep a live inventory. This is the one place everything about an AI system meets. With it, "what does this change touch, and what has to be re-checked?" is answered in an afternoon. It is also where reuse happens, because most AI only looks novel until someone notices the team next door already built it.
• Rate risk materiality honestly. Materiality is a throttle on how hard every other control works, not a label set once. A low rating quietly tells every downstream control to try less, and a system can change materiality without a line of code changing.

Before a system goes live, evaluation, fairness and explainability are one instrument pointed in three directions, built against the task. After it goes live, monitoring, human oversight, change management and logging are one loop: watch, judge, stop, record. For any control, ask what it silently depends on upstream, and what silently depends on it downstream. If you can remove a control and nothing else fails, what you had was never a system.

The book, and working with me

I developed these ideas supervising AI at the MAS and writing Singapore's AI Risk Management Guidelines. The full version is in my book, Some Thoughts on Scaling AI Governance, available at learn.simplyboring.ai. I also train and advise teams on putting it into practice. See the courses and workshops, or get in touch.