An enterprise AI provider must apply governance proportionate to risk across many model deployments. How should tiering work?

What the tier should be derived from

The consequence of the model being wrong, and who bears it — not the model's size, its novelty or the technology used.

The dimensions that matter:

• Whether a decision affects a person's access to something material — credit, employment, insurance, benefits — which in most emerging regimes is the trigger for the strictest treatment.
• Whether a human meaningfully reviews the output, and whether that review is genuine or a formality. A human who approves ninety-nine percent of recommendations without independent evidence is not a control, and claiming otherwise is the most common way a tiering assessment is wrong.
• Whether the output is reversible. A recommendation is; an automated rejection with no appeal is not.
• The scale of exposure, since a rarely-used internal tool and a model on every customer interaction differ by orders of magnitude in aggregate consequence.

What each tier should require

Highest tier: documented evaluation against a held-out set with subgroup breakdown, bias assessment, documented limitations, human review that is evidenced rather than asserted, an appeal path, monitoring for drift, and a named accountable owner.

Middle: evaluation, documentation, monitoring, and a defined escalation.

Lowest: a record of what it is, who owns it, and what it is used for — which is not nothing, since an inventory is the precondition for every subsequent governance activity and most organisations cannot produce one.

The failure of untiered governance

Applying the strictest requirements to everything makes them unaffordable, so they are applied to nothing — and teams deploy models outside the process because the process cannot accommodate the low-risk case.

A shadow estate of ungoverned models is the outcome, which is worse than a proportionate process with visible gaps.

The multi-tenant complication

A provider's customers use the model for purposes the provider does not know. The same deployment may be low-risk for one customer and high-risk for another, which means the tiering obligation is partly the customer's — and the provider's job is to supply the evaluation evidence, the documented limitations and the controls that make the customer's assessment possible.

Supplying that evidence is a product feature, and it is what enterprise procurement increasingly asks for.