Here is the version of AI governance I have seen fail more times than I can count.
An organisation decides it needs to get serious. It stands up a committee, writes a policy, and defines an approval process. The policy says every use of AI must go through the committee. The approval process is long. The committee meets monthly. Within three months, the following things are true. Business units are frustrated because pilots take a quarter to approve. Employees are quietly using consumer AI tools on their personal devices, because the sanctioned path is too slow. The committee is drowning in low-risk requests, which crowds out its attention to the high-risk ones. And the CEO, who kicked this whole thing off because she read something worrying in the paper, is now hearing complaints from every direction.
That is not governance. That is the theatre of governance. And it is the specific failure mode that a risk-tiered philosophy is designed to prevent.
This article is about the operating principle behind almost every credible AI regulatory regime in the world today: proportionate response to actual risk. The EU AI Act uses it. The NIST AI Risk Management Framework uses it. The MAS Guidelines use it. The APRA expectations use it. So did the ISO/IEC 42001 standard. Once you understand the philosophy, most of the specific rules make sense as expressions of it. Without the philosophy, the rules read like a random pile of obligations.
The core idea
The core idea of risk-tiered governance is that different AI uses should attract different levels of oversight, based on the actual harm they could cause and the actual likelihood of that harm. This is obvious when you say it out loud. It becomes counterintuitive only when you try to design a governance framework, because there is a very strong pull toward uniform process.
Uniform process feels defensible. Every use case gets the same review. Every model gets the same documentation. Every deployment goes through the same gates. When something goes wrong, you can say you applied the same rules to everything. That feels safe.
It is not safe. It is exactly what regulators are pushing back on.
The EU AI Act’s four-tier structure (unacceptable, high, limited, minimal risk) exists precisely because a uniform approach would either strangle low-risk AI or under-govern high-risk AI. You cannot use the same review process for a spam filter and a hiring algorithm, because if the process is right for the hiring algorithm it is comically overweight for the spam filter, and if the process is right for the spam filter it is dangerously underweight for the hiring algorithm.
The MAS Guidelines make the same point, differently. They apply the principle of proportionality explicitly. A high-impact, highly complex, business-critical AI system, think a loan approval model, gets the most stringent governance. A low-risk application like AI-assisted code completion gets much less. Same principle. Same regulator conclusion.
The APRA letter did not use the word “proportionate” but described the same idea. Governance and controls should reflect the size, scale, and complexity of the entity, and the materiality of the AI use case within it.
The materiality question
Before you can tier your AI use cases, you have to be able to say what makes one use case more material than another. This turns out to be harder than it sounds, so let me give you a workable definition.
A use case is material to the extent that its failure could cause meaningful harm to a person, to the organisation, or to a third party, either directly or through the decisions it influences.
Break that down.
Failure includes accuracy failures (the model gets it wrong), fairness failures (the model is systematically biased), integrity failures (the model has been manipulated or its inputs have), and availability failures (the model is unavailable when needed). All four are failures. Not all four apply equally to every use case.
Harm includes financial harm, physical harm, harm to reputation, harm to fundamental rights, discrimination, loss of privacy, exposure to fraud, and exposure to inappropriate content. In some jurisdictions, particularly the EU under both the AI Act and GDPR, harm to fundamental rights carries specific weight. In others, financial and consumer protection harms tend to dominate.
Meaningful is the word that does the most work. It filters out failures whose consequences are trivial. A model that occasionally suggests the wrong emoji is not meaningful. A model that occasionally misclassifies a fraud alert is meaningful. A model that occasionally denies a mortgage application when it should have approved it is very meaningful.
If you can classify your use cases along those axes, tiering becomes tractable.
A practical tiering approach
Here is a tiering structure I have used successfully with several organisations, adapted for the current regulatory environment. It has four tiers, and it deliberately mirrors the shape of the EU AI Act because that alignment is now the pragmatic default even for organisations that do not do business in Europe.
Tier 1: Prohibited use cases. These are uses the organisation will not do, regardless of business benefit. Every organisation should have some, and they should be specific. Not “we will not use AI unethically,” which means nothing. But “we will not use AI to make final decisions on employment offers or terminations,” or “we will not use AI to profile customers in ways that would be illegal under anti-discrimination law.” Prohibited use cases are the fastest, cheapest governance control you have. Nothing else in your framework needs to review or approve them, because they are off the table.
Tier 2: High-risk use cases. These are uses that could cause material harm if they fail. They get the full weight of your governance framework: named accountable executive, formal risk assessment, human oversight, ongoing monitoring, incident response plan, board reporting. Under the EU AI Act, Annex III enumerates specific high-risk use cases (recruitment, credit scoring, essential services, law enforcement, education, biometric categorisation, and others). That list is a useful starting point even outside the EU.
Tier 3: Limited-risk use cases. These are uses where the failure mode is bounded, either because human review always intervenes before consequences occur, or because the consequences of failure are limited. They still get governance, but the governance is lighter. A defined intake, a documented use case, an owner, basic monitoring. Not board reporting. Not formal risk assessment. Not continuous audit.
Tier 4: Minimal-risk use cases. These are uses where the failure mode is not material by any credible measure. AI-assisted grammar checking. Meeting transcription. Search ranking within an internal knowledge base. They get standing approval as a category, and individual instances do not need review at all. This is where you save the time you spend on tiers 2 and 3.
The proportion of use cases that ends up in each tier varies enormously by organisation. In a financial services firm, tier 2 is large, tier 3 substantial, tier 4 nontrivial. In a professional services firm, tier 4 tends to dominate. In a healthcare setting, tier 2 can be almost everything.
Figure 1: The tiering framework
Figure 1 shows the four-tier structure with representative use cases at each level. Note that the same underlying technology can appear in different tiers depending on how it is used. A large language model behind a customer support chatbot handling billing enquiries may be tier 3. The same model used to draft communications about a claim denial is tier 2. The technology is not the risk. The use is.
What each tier actually gets
Let me be more specific about what “governance intensity” looks like in practice, because the abstract answer is unhelpful.
For a tier 2 high-risk use case, I would expect all of the following to exist and be current. A documented use case description, including the business justification. A risk assessment that names failure modes and their potential impact. A named accountable executive with the authority to stop or change the system. A human oversight design that specifies where and how human review intervenes. A monitoring plan that watches for drift, bias, and performance degradation over time. An incident response playbook for the specific system. Regular reporting to the risk committee, at least quarterly, and to the board at least annually. Third-party components documented, and vendor exit strategies tested.
For a tier 3 limited-risk use case, I would expect substantially less. A use case description. A named owner. Basic performance monitoring. Documented human review points where they exist. A place in the AI inventory. No board reporting unless something goes wrong.
For a tier 4 minimal-risk use case, I would expect only presence in the inventory and adherence to organisational acceptable use policies. That is all.
For tier 1 prohibited use cases, the entire framework consists of the prohibition. Its enforcement is the same as any other policy prohibition: managers uphold it, employees are trained on it, violations are treated as policy breaches.
The two failure modes to avoid
There are two ways to get tiering wrong, and both are common.
The first is tier inflation. Everything ends up in tier 2 because the risk assessment is too cautious, or because nobody wants to be the person who classified something as low risk when it later caused a problem. The result is that tier 2 becomes meaningless. Everything gets the same treatment, and the treatment is expensive and slow. You have effectively reinvented uniform process with extra steps.
The counter to tier inflation is a documented, defensible tiering methodology, applied consistently, with sign-off at the right level. It is much easier to defend a tier 3 classification if you can point to the methodology that produced it, the specific risk assessment that supported it, and the executive who approved it.
The second failure mode is tier gaming. Business units learn the tiers and describe their use cases in ways that keep them in tier 3 or tier 4. “It is just augmentation.” “It is not making decisions, it is just suggesting.” “It has human oversight, so it is not really high risk.” Each of these can be genuinely true and can also be genuinely false, depending on the specifics of how the system is deployed and used.
The counter to tier gaming is independent review of the tiering itself, not just of the use case. Tiering decisions on tier 2 candidates should not sit with the business unit that will benefit from a lower tier. Second-line risk should have visibility, and internal audit should periodically sample the tiering decisions to check for drift.
Why the philosophy matters more than the taxonomy
I want to close on a point that I think gets lost in discussions of tiering.
The specific taxonomy you use matters less than the philosophy behind it. There are organisations using three tiers, four tiers, five tiers, or the full EU risk pyramid. There are organisations that use “critical/high/medium/low” and others that use “restricted/enhanced/standard/basic.” The labels are all fine.
What matters is that the framework distinguishes what should be distinguished, and does not require the same intensity of review for things that carry radically different risk. A framework that treats a spam filter and a credit decision engine the same is broken, no matter what taxonomy it uses. A framework that distinguishes them intelligently is working, no matter what taxonomy it uses.
The philosophy behind this whole track, and behind most of the AI governance work happening around the world, is that AI is enormously valuable and enormously varied, and the job of governance is to enable the valuable use while managing the specific risks that specific uses actually pose. Governance that produces “no” as its default answer will be routed around by employees who want to get their jobs done, and will fail. Governance that produces “yes with these conditions” as its default answer, calibrated to the actual risk of the specific use, will work.
Figure 2: The failure modes at the extremes
Figure 2 shows what happens when you get this wrong at either end. Under-governance at the top-right of the risk-benefit space produces harm to customers, to the organisation, and to trust. Over-governance at the bottom-left produces shadow AI, employee frustration, competitive disadvantage, and eventually a governance framework that gets ignored. The sweet spot in the middle, calibrated intensity, is where credible AI governance actually lives.
The next article moves from philosophy to specifics. What can actually go wrong with AI in production? We will walk through the four categories of risk that dominate everything else: bias, hallucination, privacy, and security. Each has its own dynamics, its own controls, and its own regulatory implications. Once you have that map, the rest of the governance framework has something specific to defend against.