Most AI governance efforts begin with a document. A set of principles is drafted, circulated, approved and published to an intranet page. Six months later teams are still shipping AI features and nobody consults it, because it does not tell anyone what to do on a Tuesday afternoon.
Governance becomes real when it is a small number of working parts rather than a statement of values. Four of them do most of the work: how risk is classified, who is entitled to decide, where humans genuinely stay in the loop, and what gets monitored after release.
Governance becomes real when it is a small number of working parts rather than a statement of values.
Classify by consequence, not by technology
The most common design error is classifying AI systems by what they are built from. A policy that treats every large language model identically forces a drafting assistant through the same review as a system influencing credit decisions. Teams route around it, and the review board becomes a queue nobody respects.
Classify by consequence instead. What happens if the system is wrong? Who is affected, how quickly would anyone notice, and how reversible is the outcome? A tool suggesting internal document wording carries almost no consequence. A system screening applicants carries a great deal. The same model can sit inside both, which is precisely why the model is the wrong unit of classification.
High consequence
Few of your AI uses
Affects a person's access, money or rights
Governance forum, documented sign-off, active monitoring
Moderate consequence
Some of your AI uses
Informs a decision a person still makes
Named reviewer against a checklist
Low consequence
Most of your AI uses
Drafting, summarising, internal convenience
Published standard, no review
The same model can appear in all three tiers, which is why the model is the wrong unit of classification.
Decide who decides
Most AI initiatives stall not because someone says no, but because nobody is certain who is entitled to say yes. Decision rights should be explicit and matched to the risk tier. Low-consequence uses need a published standard and no meeting at all. Moderate ones need a named reviewer. High-consequence ones need a forum with real authority, including the authority to stop something.
Write those rights down and publish them beside the classification. The goal is that an engineer can work out, in under a minute and without asking anyone, which path their use case travels.
Human oversight is a design decision
Human oversight is frequently reduced to a sentence promising that a person reviews outputs. In practice that person is often working through a queue of hundreds of items, with little context and no realistic ability to disagree. That is not oversight. It is a signature.
Real oversight is designed. It specifies what the reviewer sees, what they are able to change, how much time they have, and what happens when they push back. If overriding the system is harder than accepting it, the oversight will not hold under pressure.
If overriding the system is harder than accepting it, the oversight will not hold under pressure.
Monitoring is the part everyone skips
Approval attracts the attention because it happens once and involves meetings. Monitoring is where governance is actually tested, and it is routinely deferred. Decide before launch what you will watch: output quality drift, unusual usage patterns, cost, escalations and complaints. Decide who receives those signals and which threshold triggers action.
Without monitoring, a governance framework can only tell you that something was approved once. It cannot tell you whether it still deserves to be.
None of this requires a large apparatus. A risk classification anyone can apply, decision rights people can find, oversight someone can realistically exercise, and a short list of things you genuinely watch. That is most of it. Frameworks that go much further usually do so at the expense of being used.
Key takeaways
- Classify AI uses by consequence rather than by the technology behind them.
- Match decision rights to risk tiers so the majority of uses need no meeting at all.
- Design human oversight deliberately, or it becomes a signature rather than a control.
- Decide what you will monitor before launch, not after the first incident.