Consequence-Based Tiering

Governance applied uniformly is applied to nothing. The strictest requirements make low-risk uses unaffordable, so teams deploy outside the process — and a shadow estate of ungoverned systems is the outcome, which is worse than a proportionate process with visible gaps.

Tiering by consequence resolves it, and the dimension is what happens when the system is wrong and who bears it — not the model's size, its novelty, or the technology used.

Why it matters

It is what makes governance operable. A process that accommodates the low-risk case keeps those cases visible, and visibility is the precondition for everything else.

Even the lowest tier's requirement — a record of what it is, who owns it and what it is used for — is not nothing, since an inventory is what every subsequent governance activity depends on and most organisations cannot produce one.

Implementation patterns

Tier on:

• Whether a decision affects a person's access to something material — credit, employment, insurance, benefits — which in most emerging regimes triggers the strictest treatment.
• Whether a human meaningfully reviews the output. A human who approves ninety-nine percent of recommendations without independent evidence is not a control, and claiming otherwise is the most common way an assessment is wrong.
• Whether the output is reversible.
• The scale of exposure, since aggregate consequence differs by orders of magnitude between a rarely-used internal tool and a system on every customer interaction.

And require, at the highest tier: documented evaluation with subgroup breakdown, bias assessment, honest documented limitations, evidenced human review, an appeal path reaching someone with authority to change the outcome, drift monitoring, and a named accountable owner.

Industry example

Enterprise AI providers such as Cohere and data-operations platforms such as Scale AI face a specific complication: customers use the system for purposes the provider does not know, so the same deployment is low-risk for one customer and high-risk for another.

That makes part of the tiering obligation the customer's, and the provider's job is to supply the evaluation evidence, documented limitations and controls that make the customer's assessment possible — which is a product feature and increasingly what enterprise procurement asks for.

Failure scenarios

• Untiered governance, applied to nothing.
• Tiering by technology rather than by consequence.
• Human review counted as a control without evidence of independence.
• No inventory, so the lowest tier is invisible entirely.
• Provider assuming the customer's use case, and tiering on the wrong assumption.

Trade-offs

Tiering requires a judgement per system, and the boundary cases consume disproportionate effort. It also creates an incentive to argue a system into a lower tier.

The mitigation is a small number of tiers with concrete triggers rather than a scoring model, plus periodic re-assessment when a system's use changes — since a low-risk system whose usage expanded is the case the initial assessment cannot catch.

Interview question

"You have forty machine-learning systems in production. Sort them into tiers for me, tell me what each tier requires, and tell me what you would do about the ones nobody has told you exist."