Most organisations now run dozens or hundreds of AI use cases, and without a tiering scheme every one of them gets either the same heavy review or no review at all. Risk tiering sorts AI use cases by the harm they could cause, so that a meeting summariser and a credit decision engine are not governed the same way. This guide sets out how to build a tiering scheme that works: the regulatory floor set by the EU AI Act, the factors that drive inherent and contextual risk, how to score agentic "action risk", how to tier third-party and SaaS AI, and what each tier should require. It is written for AI governance leads, security architects, risk and compliance teams and anyone who runs an AI intake process.
Key takeaways
- Tier the use case, not the model. The same foundation model can sit behind a low-risk drafting tool and a high-risk hiring screen; impact comes from purpose, data, autonomy and who is affected.
- Regulation sets the floor, not the scheme. EU AI Act Article 5 prohibitions and Article 6 high-risk classification are knock-out questions at intake, but most internal use cases fall below them and still need differentiated control.
- Score what the system can do, as well as what it says. Agentic systems with tool access, write permissions and credentials need an action-risk dimension that content-only scoring misses.
- Vendor AI is your risk too. SaaS features switched on by a supplier, and third-party models you cannot inspect, are tiered on your use and your data, with residual uncertainty pushing the tier up.
- A tier is only real if it changes controls. Each tier must map to concrete requirements: approver, testing depth, human oversight, monitoring and re-review interval.
Why tier AI use cases
Tiering is proportionality made operational. NIST AI RMF 1.0 GOVERN 1.3 expects processes "in place to determine the needed level of risk management activities" based on organisational risk tolerance, and MANAGE 1.2 asks that treatment of documented AI risks is prioritised based on impact, likelihood and available resources. The NIST Generative AI Profile (NIST AI 600-1) has a specific action, GV-1.3-001, on factors to consider when defining or updating risk tiers for generative AI. Banking supervisors take the same line for models: the US interagency model risk guidance issued in April 2026 (SR 26-2) weighs inherent risk against materiality and allows immaterial models to receive only identification and monitoring, and Canada's OSFI Guideline E-23 requires a model risk rating that drives review depth, approval authority and monitoring intensity.
- Without tiers: governance teams become a bottleneck, low-risk requests wait weeks, and staff route around the process into shadow AI.
- With tiers: low-risk use cases self-certify against guardrails in days, and review effort concentrates on the small number that can deny someone a loan, move money or change production systems.
- Inventory first: tiering needs a list to tier. GOVERN 1.6 expects mechanisms to inventory AI systems resourced according to risk priorities. See the AI Register and AI Inventory Template.
The regulatory floor: EU AI Act classification
Whether or not you are in the EU, the AI Act categories are the most widely used reference point for impact tiering, and they make good knock-out questions at the start of intake. The detail of obligations sits in the EU AI Act Compliance Guide; what matters for tiering is the classification logic, as amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026.
| AI Act category | Legal basis | Tiering consequence | Applies from (Article 113 as amended) |
|---|---|---|---|
| Prohibited practice | Article 5(1)(a) to (h): manipulative techniques, exploiting vulnerabilities, social scoring, crime prediction based solely on profiling, untargeted facial image scraping, emotion inference at work or school, biometric categorisation of sensitive traits, real-time remote biometric identification for law enforcement (narrow exceptions) | Stop. Not tiered, rejected at intake unless legal confirms an exception | 2 February 2025 |
| Prohibited practice (added 2026) | Article 5(1)(ba) non-consensual intimate imagery and (bb) child sexual abuse material | Stop. Also a content safety requirement for any image or video generation feature | 2 December 2026 |
| High-risk, Annex III | Article 6(2): biometrics, critical infrastructure, education, employment, essential services (benefits, credit scoring, life and health insurance pricing, emergency triage), law enforcement, migration and border, justice and democratic processes | Top internal tier by default | 2 December 2027 |
| High-risk, product safety | Article 6(1): safety component of, or itself, a product under Annex I law needing third-party conformity assessment | Top tier; product safety team owns | 2 August 2028 |
| Transparency obligations | Article 50: systems interacting with people, synthetic content generation, emotion recognition and biometric categorisation, deepfakes and public-interest text | Minimum disclosure and labelling controls, whatever the internal tier | 2 August 2026 (general date) |
| Everything else | No specific obligation beyond AI literacy and general law | Internal tiering decides | n/a |
The Article 6(3) derogation and why it needs care
An Annex III system is not high-risk if it does not pose a significant risk of harm and meets one of four conditions: (a) it performs a narrow procedural task, (b) it improves the result of a previously completed human activity, (c) it detects decision patterns or deviations without replacing or influencing the human assessment without proper review, or (d) it performs a preparatory task for an Annex III assessment. The derogation never applies where the system performs profiling of natural persons. A provider relying on it must document the assessment before placing the system on the market and still register it (Article 6(4) and Article 49(2)); the Omnibus simplified the registration content but kept the duty. Treat a derogation claim as a tier decision that needs legal sign-off and evidence, not as a way out of review.
- Deployer duties at the top tier: public bodies, private entities providing public services, and deployers of credit scoring (Annex III point 5(b)) or life and health insurance pricing (point 5(c)) must carry out a fundamental rights impact assessment under Article 27 before first use, covering the process, duration and frequency of use, affected groups, specific risks, human oversight and remediation. Build that into the tier 1 workflow, alongside a GDPR Article 35 DPIA where personal data is processed. See the AI Impact Assessment Template.
Inherent risk factors
Inherent risk is the risk of the use case before your controls. Score it at intake from facts the requester can supply. The factors below combine the AI Act areas, the AI RMF MAP function (MAP 1.5 documented risk tolerances, MAP 5.1 likelihood and magnitude of each impact) and the qualitative factors OSFI E-23 lists for model risk rating (business use, complexity or autonomy, data reliability, customer impact, regulatory risk).
| Factor | Low (1) | Medium (2) | High (3) |
|---|---|---|---|
| Decision impact on people | No decision about individuals | Informs a decision a human makes and checks | Determines or materially shapes access to jobs, credit, services, benefits, legal outcomes |
| Affected population | Internal staff, opt-in | Customers, with alternative channel | Public, vulnerable groups, children, no realistic opt-out |
| Data sensitivity | Public or synthetic | Internal or confidential | Special category personal data, regulated data, secrets, source code |
| Autonomy | Suggestion only | Human approves each action | Acts without per-action approval |
| Reversibility | Output discarded easily | Reversible with effort | Irreversible: payments sent, records deleted, messages published |
| Exposure | Internal only | Partners or authenticated customers | Open internet, untrusted input (web, email, documents) |
| Model opacity and maturity | Deterministic or well-understood model | Established ML with validation evidence | Generative or agentic, proprietary third-party model, limited evaluation evidence |
| Scale | A handful of users or decisions | Business unit | Enterprise-wide or high-volume customer decisions |
Contextual risk: the same tool in different places
Contextual risk is what changes when an approved capability is reused. A transcription feature in a team meeting is low risk; the same feature in a disciplinary hearing or a clinical consultation is not. Tie tiers to the use case record (purpose, users, data, outputs, downstream decisions), never to the product name, and require a new tier decision when any of those change.
- Purpose drift: a summariser later used to rank candidates has moved into Annex III point 4(a) territory. Re-tier on change of purpose.
- Data drift: connecting a copilot to HR, finance or legal repositories raises data sensitivity without any change to the model. See the Data Classification Guide.
- Audience drift: an internal pilot exposed to customers picks up Article 50(1) disclosure and consumer law liability. The Air Canada chatbot ruling shows a customer-facing bot's wrong answer becoming the operator's liability.
- Jurisdiction: the same use case may be high-risk in one market and unregulated in another. Tier to the strictest market where it is used. See the Global AI Regulation Map.
Action-risk tiering for agents
Content-based tiering asks what the system might say. Agents also act: they call tools, hold credentials and change systems. Score action risk separately and take the higher of the two tiers.
| Action class | Examples | Minimum tier | Typical control |
|---|---|---|---|
| A0 Read public | Web search, public documentation | Low | Output filtering, logging |
| A1 Read internal | Search tickets, read wiki, query a data warehouse | Medium | User-delegated, least-privilege scopes; no standing service account |
| A2 Write reversible | Draft emails, create tickets, open pull requests | Medium | Human review before send or merge |
| A3 Write external or irreversible | Send email externally, post publicly, delete data, deploy to production | High | Per-action approval, rate limits, kill switch (MANAGE 2.4) |
| A4 Financial or privileged | Payments, refunds, IAM changes, secrets access | High, often prohibited for autonomous use | Dual control, transaction limits, just-in-time credentials |
The Replit AI agent database deletion is the standard illustration: a coding assistant with write access to production was treated as a developer convenience, not as an A3 action-risk system needing approval gates and environment separation.
Where identity fits
Action risk is mostly an identity question. What an agent can do is defined by the tokens, API keys and service accounts it holds, so the tier decision should record which identity the use case runs as, what scopes it has and who owns it. A use case that can only reach data through the requesting user's delegated, scoped token is lower risk than one running on a shared, long-lived key with broad permissions. Tier 1 and tier 2 agentic use cases should have a registered non-human identity with an owner, scoped permissions and rotation. See the AI Agent Authorisation Guide and the Identity Governance for AI Agents Guide.
Tiering vendor, SaaS and internal AI
The tier belongs to your use of the system, wherever the model runs. What changes for third-party AI is how much evidence you can get and how much control you keep.
| Source | What you can see | Tiering adjustment | Key evidence to request |
|---|---|---|---|
| Internal build on your infrastructure | Data, prompts, code, evaluation results | Score as assessed | Your own test and evaluation records |
| Internal build on a hosted foundation model API | Your prompts and data; not model training | Raise one level on opacity if no provider evaluation evidence | Provider model card, data retention and training-use terms |
| Dedicated AI SaaS product | Vendor documentation and contract only | Raise one level where data leaves your boundary or outputs drive decisions | Security assessment, sub-processors, logging, incident notification |
| AI feature embedded in existing SaaS | Often only a release note | Re-tier the host application when the feature is enabled; default off until assessed | Admin controls to disable, data flows, model provider |
| Open-weight model run internally | Weights, but limited training data provenance | Score supply chain risk explicitly | Model provenance, licence, scanning results |
Vendor tiering should feed your third-party risk process, not run beside it. NIST CSF 2.0 GV.SC-07 expects supplier risks to be understood, recorded, prioritised, assessed, responded to and monitored over the relationship. See the Third-Party AI Risk Guide, the SaaS and OAuth App Governance Guide and the Vendor Security Assessment Template.
From score to tier: what each tier requires
A simple, defensible scheme: apply knock-outs first (Article 5 means reject; Annex III or Annex I high-risk, or action class A3 or A4, means tier 1). Otherwise sum the eight inherent factors (8 to 24), and add one point for each contextual flag (public exposure, vulnerable users, cross-border use, vendor opacity). This is NHI Mgmt Group's suggested starting point, not a standard; calibrate the thresholds against twenty or so real use cases before launch.
| Tier | Trigger | Approver | Required before go-live | Monitoring and re-review |
|---|---|---|---|---|
| Prohibited | Article 5 practice or internal red line | n/a | Rejected; record decision | n/a |
| Tier 1 High | Knock-out to high, or score 19 or above | AI review committee and accountable executive | Full risk and impact assessment, FRIA or DPIA where required, independent testing and red teaming, human oversight design, documented fallback | Continuous monitoring, incident runbook, re-review at least every 6 months and on any change |
| Tier 2 Medium | Score 14 to 18 | AI governance lead plus security and privacy | Standard assessment, evaluation against defined acceptance criteria, data flow review | Quarterly metrics review, annual re-tier |
| Tier 3 Low | Score 13 or below, no flags | Business owner self-certifies | Approved tool list, acceptable use policy attestation | Spot checks, annual attestation |
The review committee mechanics are covered in the AI Ethics Board and AI Review Committee Guide, and the assessment method for tier 1 and tier 2 in the AI Risk Assessment Guide. Tier 1 use cases that affect individuals also need the testing in the Explainable and Fair AI Guide.
Implementing a tiering process
- Agree the risk appetite statement for AI with the executive owner (NIST CSF 2.0 GV.RM-02, AI RMF MAP 1.5). Decide your red lines beyond Article 5.
- Build the intake questionnaire from the factor table: 15 to 25 questions, each mapped to a factor, answerable by a business requester in under 20 minutes.
- Back-test on existing use cases. Tier 20 to 30 known systems with the draft scheme and compare with expert judgement. Adjust thresholds until disagreements are rare and explainable.
- Pilot with one or two business units for a quarter, with the governance team reviewing every self-certified tier 3 decision to check the questionnaire is not being gamed.
- Connect discovery. Feed SaaS discovery, cloud AI service logs, browser telemetry and expense data into the register so unregistered use cases surface. See the Shadow AI Discovery Guide.
- Roll out enterprise-wide with an amnesty period for existing use cases to register and be tiered.
- Define the rollback: if a tier 1 system fails monitoring thresholds, the documented fallback (manual process or previous version) must be executable within an agreed time, and the owner must know how to invoke it.
Detection and measurement
- What to log: intake decisions with score breakdown and approver; changes to purpose, data sources, tools or user population; AI feature enablement events in SaaS admin logs; agent tool calls and the identity used.
- Coverage: percentage of discovered AI use cases that have a tier (target above 95 per cent).
- Timeliness: median days from intake to decision per tier (tier 3 measured in days, tier 1 in weeks).
- Drift: number of use cases re-tiered upward after a change, and the share caught by change triggers rather than by audit.
- Overdue reviews: tier 1 and tier 2 use cases past their re-review date (target zero for tier 1).
- Shadow ratio: AI use cases found by discovery that never went through intake, trended monthly.
Framework mapping
| Framework | Reference | How tiering supports it |
|---|---|---|
| NIST AI RMF 1.0 | GOVERN 1.3, GOVERN 1.6, MAP 1.5, MAP 5.1, MANAGE 1.2 | Proportionate risk management, inventory, tolerances, impact sizing, prioritised treatment |
| NIST AI 600-1 | GV-1.3-001, GV-1.6-001 | Risk tier factors and inventory for generative AI |
| NIST CSF 2.0 | GV.RM-02, GV.RM-06, ID.RA-05, GV.SC-07, ID.AM-02 | Appetite, standard risk categorisation method, inherent risk, supplier risk, inventory |
| NIST SP 800-53 Rev. 5 | RA-2, RA-3, RA-9, PM-9, SA-9 | Categorisation, risk assessment, criticality analysis, risk strategy, external services |
| EU AI Act | Articles 5, 6, 27, 50, Annex III | Knock-out questions and top-tier obligations |
| ISO/IEC 42001:2023 | AI management system risk assessment and treatment | Tiering is the proportionality mechanism inside the AIMS |
For the wider governance structure that tiering plugs into, see the AI Governance Guide and the NIST AI RMF Guide.
Common failure patterns
- Tiering the vendor, not the use: approving "ChatGPT" or "Copilot" as a single tier, then discovering it is used for code, HR letters and customer complaints with very different risk.
- No re-tier trigger: tiers set at pilot and never revisited after new data connectors or tools are added.
- Ignoring action risk: scoring an agent on content harms only while it holds write access to production or a payments API.
- Derogation as default: claiming Article 6(3) for systems that profile individuals, which the derogation never covers.
- Self-certification without spot checks: requesters learn which answers produce tier 3. Sample decisions and compare with discovery data.
- Shadow use outside the scheme: the Samsung ChatGPT source code leak came from staff pasting confidential code into a public tool that no tiering process had considered.
Practitioner checklist
- Publish an AI risk appetite statement and a list of internal red lines beyond EU AI Act Article 5.
- Put Article 5, Annex III, Annex I and action-class A3/A4 knock-out questions at the start of intake.
- Score inherent risk on documented factors and add contextual flags for exposure, vulnerable users, jurisdiction and vendor opacity.
- Record the identity, scopes and owner of every agentic use case as part of the tier decision.
- Tie each tier to named approvers, required evidence, monitoring and a re-review interval.
- Require legal sign-off and documentation for any Article 6(3) derogation claim, and never apply it to profiling.
- Re-tier automatically on change of purpose, data source, tool access, user population or market.
- Default embedded SaaS AI features off until the host application is re-tiered.
- Back-test thresholds on real use cases and review the scheme annually.
- Report tier coverage, overdue reviews and shadow ratio to the AI governance committee monthly.
Standards and references
- EUR-Lex: Regulation (EU) 2024/1689 (Artificial Intelligence Act)
- EUR-Lex: Regulation (EU) 2026/1744 (Digital Omnibus on AI)
- European Commission AI Act Service Desk: Article 6, Classification rules for high-risk AI systems
- European Commission AI Act Service Desk: Annex III, High-risk AI systems
- NIST: AI Risk Management Framework 1.0 (NIST AI 100-1)
- NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
- OSFI: Guideline E-23, Model Risk Management
- ISO: ISO/IEC 42001:2023 Artificial intelligence management system
Related NHI Mgmt Group resources: AI Governance Guide · AI Risk Assessment Guide · AI Register and AI Inventory Template · AI Model Risk Management Guide (SR 11-7)