Risk Tiering for AI: Matching Oversight to Actual Impact

The problem with one-size-fits-all

When every AI request goes through the same heavy review, two things happen: the review queue becomes a bottleneck, and teams start working around it. The first effect is visible—weeks of delay for trivial uses. The second is worse, because it is invisible: teams that learn the front door is slow simply stop knocking, and the organization ends up with less visibility than if it had no process at all.

The opposite failure mode is just as common. In the absence of any tiering, everything is treated as low risk until something goes wrong. A drafting assistant and a system that screens job applicants receive the same absence of scrutiny, and the organization discovers the difference only after a complaint, a bad outcome or a regulator's question.

Tiering solves both problems by making the path proportional to the risk. Low-risk uses get a fast, lightweight route that encourages disclosure. High-risk uses get the depth of review they genuinely need, with the organization's scarce expert time concentrated where it can prevent real harm.

Factors that drive the tier

Good tiering questions are concrete and answerable by a business owner in minutes. Abstract questions about 'algorithmic complexity' produce abstract answers; questions about people, data and consequences produce useful ones. The assessment should feel like a short structured conversation, not a research project.

Notice what is absent from this list: the technology itself. The same model can be low risk in one context and high risk in another. A summarization model condensing internal meeting notes is a different proposition from the same model summarizing patient symptoms. Tier the use, not the tool.

• Does the system make or materially influence decisions about people—hiring, credit, safety, access to services?
• Does it process sensitive, regulated or confidential data?
• Is output used without human review?
• Is it customer-facing or public?
• How reversible is a bad outcome?

A practical four-tier model

Low risk covers internal productivity uses with no sensitive data—drafting, brainstorming, summarizing public material. Moderate covers uses with confidential data or light decision support, where a human remains clearly in the loop. High covers systems affecting individuals' rights, safety or finances, or operating with limited human review. Prohibited covers uses your organization will not pursue—for example, covert monitoring of employees or fully automated adverse decisions without appeal.

This structure aligns well with the risk-based logic of the EU AI Act and similar regulations, while remaining simple enough to operate internally. Alignment matters: when regulation asks how you classify AI risk, you want an answer that already exists rather than a mapping exercise performed under deadline.

The prohibited tier deserves more attention than it usually gets. A short, explicit, leadership-endorsed list of uses the organization will not pursue does two things: it gives teams a clear boundary they can plan around, and it demonstrates to boards and regulators that risk appetite has been considered rather than assumed.

Linking tiers to controls

A tier is only useful if it changes what happens next. Low-risk uses may need only registration and acceptable-use acknowledgement. Moderate uses might add a lightweight data review and a named owner. High-risk uses may require an impact assessment, bias and performance testing, documented human oversight, approval by a governance committee and ongoing monitoring.

Write these expectations down so teams can plan for them. Predictability is the point: a product team that knows a high-tier classification means an impact assessment and committee review can schedule around it. A team facing an unpredictable, bespoke process will instead try to avoid classification altogether.

Controls should also be testable. 'Human oversight' as a vague aspiration is not a control; 'a named reviewer approves every output above threshold X before it reaches a customer, and that approval is logged' is. When you cannot describe how a control would be verified, the tier mapping is not finished.

Revisiting the tier

Risk changes when scope, data or autonomy changes. The drafting assistant that starts suggesting customer communications, the internal tool that gains access to personal data, the decision-support system whose recommendations stop being reviewed—each has quietly moved tier without anyone filing a form.

Build tier reassessment into change management and treat a material change as a new assessment, not a footnote. Recertification cycles catch drift for systems that change slowly; change-management triggers catch it for systems that change fast. Both are needed.

Finally, track tier distribution over time as a program metric. A growing count of high-risk systems is not inherently bad—it may reflect valuable adoption—but it should be a deliberate, visible trend that leadership has chosen, not an accident nobody noticed.