
Ask a board member what AI governance means and you will usually get one of two answers: a moratorium or a policy document. Neither answer describes a working control system. A moratorium stops the organisation from learning anything useful while competitors and, more worryingly, staff using unsanctioned tools carry on regardless. A policy document sits in a folder and is read once, at launch, and never again.
Proportionate governance is different. It treats generative AI the way a mature organisation treats any other source of operational risk: by classifying use cases, matching the level of scrutiny to the level of exposure, and building in the checks that catch problems before customers or regulators do. That is a design exercise, not a legal exercise, and it should sit with the people who understand both the technology and the business process it touches.
Not every use case carries the same risk
A model that drafts internal meeting summaries and a model that produces customer-facing credit decisions are not the same risk category, yet many governance frameworks treat them identically because it is administratively simpler. That simplicity is expensive. It either slows the low-risk use case to the pace of the high-risk one, or it drags the high-risk one through a process built for internal convenience.
The fix is a short, honest classification exercise at the point a use case is proposed: who is affected by the output, how reversible is a wrong answer, and what happens if the model is confidently wrong rather than obviously wrong. Confidently wrong is the dangerous case, because it does not announce itself and it erodes trust in a way that is hard to repair.
Governance that only says no eventually gets ignored. Governance that says yes, and here is how, gets followed.
Model risk is not the same as project risk
Traditional project governance asks whether a delivery is on time and on budget. Model risk asks a different question: does the system's behaviour drift as inputs change, and would anyone notice if it did. That requires monitoring that most delivery teams have never built before, because nothing in a conventional software release changes its own behaviour after it ships.
In practice this means treating a generative AI deployment less like a one-off release and more like an ongoing operational service with its own metrics: rate of human override, rate of escalation, and periodic sampling of outputs against a known-good baseline. Without that instrumentation, a governance committee is approving a snapshot of behaviour that may no longer be true within weeks.
- 路Classify use cases by exposure before build, not after
- 路Instrument override and escalation rates from day one
- 路Sample outputs against a baseline on a fixed cadence
- 路Put a named owner against every deployed model, not a committee
Human oversight has to be designed, not assumed
"A human is in the loop" is one of the most overused and least examined phrases in AI governance. In practice it often means a person clicks approve on an interface that gives them no meaningful basis to disagree, under time pressure that discourages disagreement anyway. That is oversight in name only.
Real oversight means the reviewer has the information, the time and the incentive to challenge the model, and that challenging it is not treated as a failure of the automation. Programmes that get this right build friction deliberately into the highest-risk decisions and remove it deliberately from the lowest-risk ones, rather than applying a uniform amount of human review everywhere.
Evaluation beats policy
The organisations that govern generative AI well spend less time writing policy and more time running evaluation: structured, repeated tests of what the model actually does against representative inputs, including adversarial and edge cases. A policy document tells you what should happen. An evaluation suite tells you what does happen.
This is also where governance earns its keep with delivery teams rather than fighting them. Engineers respect a test suite. They tend to resent a policy binder, particularly one written by people who have never used the tool it describes. Building governance as a set of evaluations that ship alongside the model, rather than a gate that sits in front of it, changes the relationship from adversarial to collaborative.
The organisations still debating whether to allow generative AI at all are asking the wrong question. It is already in use, sanctioned or not, because it is useful. The question worth answering is where the genuine exposure sits, and whether the controls around it are proportionate to that exposure rather than to institutional anxiety.
Get that classification right and governance stops being a brake. It becomes the reason the organisation can move faster than a competitor who is still arguing about whether to start.
