Without tiers, every AI use case gets the same review — which in practice means high-risk systems get too little scrutiny and low-risk ones get so much that teams route around governance entirely. A risk-tiering rubric classifies each use case as high, medium, or low risk using a few observable dimensions, then attaches a proportionate review to each tier. This article offers a rubric you can adapt. It is recommended practice for allocating internal review effort — it is not a legal classification, and if a law or regulator defines risk categories for your industry or region, those definitions take precedence. Confirm with counsel.
Three dimensions predict most of the risk
Autonomy — does a human stand between the model and the consequence? A system that drafts text a person edits is very different from one that sends the email, updates the record, or executes the tool call on its own. Score: human reviews every output (low) → human samples or approves batches (medium) → system acts without per-action review (high). See human-in-the-loop design and automated vs. human decisions.
Audience and data sensitivity — who sees the output, and what data flows through? Internal tool for trained staff on public data (low) → internal with confidential data, or external but informational (medium) → customer-facing, or handling regulated categories of personal or sensitive data (high). Data classification feeds directly in — a use case inherits at least the sensitivity of the most restricted data it touches (data sensitivity matrix).
Consequence of error — what does a wrong output cost? Rework or mild embarrassment (low) → financial cost, customer confusion, reversible harm (medium) → safety, legal, or discrimination exposure; irreversible actions; decisions materially affecting individuals' rights or finances (high).
Combining scores into a tier
| Rule | Resulting tier |
|---|---|
| Any dimension scores high | High |
| No highs, any dimension medium | Medium |
| All three low | Low |
Take the maximum, never the average — a fully autonomous system is not made safe by a friendly audience. Add explicit overrides for automatic-high categories your organization defines up front (for example, employment decisions or anything in scope of a specific regulation), so the rubric cannot argue its way around a bright line.
What each tier buys
Low: registered in the inventory, self-attested against the use policy, fast-track review, annual re-check. Medium: full pre-launch validation with documented evals, security/privacy review, named oversight point, semi-annual or annual review. High: everything in medium, plus adversarial testing, high-stakes review with steering-committee sign-off, defined human oversight for consequential actions, monitoring with alerting, and a standing entry in the incident playbook.
Tier can also drive technical configuration, not just paperwork. Higher tiers are where you spend platform controls: a dedicated workspace with its own scoped API keys and workspace-level spend and rate limits (on the Claude API, workspace limits can be set lower than the organization's), stricter data-handling arrangements where your contract provides them, and — where data location matters — controls like the Claude API's inference_geo parameter or your cloud platform's regional endpoints. The point is proportionality in both directions: low tiers get lighter paperwork, high tiers get stronger enforcement.
Tiers change; make re-tiering a trigger
The riskiest moment is often quiet scope creep: the internal pilot gets shown to customers, the draft-only assistant gets an auto-send feature, a new data source raises sensitivity. Any change to autonomy, audience, or data classification should force a re-tier through change management — moving up a tier means the delta in review requirements applies before the change ships.
Where to go next
Wire the rubric into the intake process so every request arrives pre-scored, and see model risk basics for the discipline the tiers are rationing.