Black Sheep AI
Risk tiering is the sorting step that decides how much governance an AI use case has to earn. Get it right and your review effort lands where the harm is. Get it wrong and you audit the spam filter while the credit model ships unexamined.
Ask a governance team what they do and many will hand you a checklist. One checklist, for every AI system. That's the failure mode risk tiering exists to fix. A spam filter and a loan-approval model are both "AI," and treating them the same means one of two things: the checklist is light enough for the spam filter, so it misses what matters on the loan model, or it's heavy enough for the loan model, so nobody finishes it for the spam filter and the whole process gets ignored. Uniform governance doesn't scale, and worse, it aims attention at the wrong systems.
Risk tiering is the alternative. It's a classification step, run at project intake, that sorts each use case into a tier, and the tier determines how much oversight the system gets before and after it ships. Rigorous controls for the systems that can hurt people. Light-touch controls for the ones that can't. The tier is the routing decision that everything else follows from.
The four tiers
Our risk tiering system uses four tiers, matched to the EU AI Act's categories so a single classification satisfies both internal governance and regulatory expectation.
| Tier | What it means | What governance it gets | Examples |
|---|---|---|---|
| Prohibited | Clear threat to fundamental rights, safety, or democratic values | Cannot be deployed | Social scoring, subliminal manipulation, untargeted facial-recognition scraping |
| High | Significant impact on health, safety, or fundamental rights | Full framework compliance, third-party assessment, continuous monitoring | Hiring and resume screening, credit scoring, medical diagnosis, biometric ID |
| Limited | Moderate impact, mainly a transparency concern | Disclosure, documentation, periodic review | Chatbots, content recommendation, sentiment analysis |
| Minimal | Low potential for harm | Standard development practice, lightweight documentation | Spam filters, game AI, inventory optimization |
The tiers aren't just labels; each one carries a different bill of work. A minimal-risk system needs a lightweight model card and an entry in the AI inventory, and it proceeds. A limited-risk chatbot has to tell users they're talking to AI and label synthetic content. A high-risk system triggers the full sequence: an algorithmic impact assessment, RAI Council review, independent validation of fairness and accuracy, executive sign-off, then quarterly monitoring for the life of the system. Prohibited systems don't ship at all, and if one is discovered mid-project it gets halted and reviewed to understand how it got that far.
That escalation is the entire value of tiering. The classification isn't paperwork; it's the thing that decides whether you owe five artifacts or one.
How a use case gets classified
We keep the first pass deliberately simple, a short decision tree anyone at intake can run:
- Does it fall under a prohibited use case? If yes, stop.
- Does it affect fundamental rights, health, safety, or access to essential services? If yes, it's high-risk.
- Does it interact directly with users or generate content presented as human-made? If yes, limited-risk.
- Could its failure cause significant business or reputational harm? If yes, consider limited-risk; otherwise minimal.
Four questions, and most systems resolve in the first two. The tree is intentionally blunt because the goal at intake is speed and consistency, not precision. Precision comes next.
Tiering is coarse; the impact assessment is fine
A tier tells you the category. It doesn't tell you how bad the specific risks are, or whether your controls have brought them down to something acceptable. That's the job of the impact assessment, which every high-risk system has to complete before deployment. The impact assessment is where a system's actual fairness, privacy, and human-rights exposure gets documented, tested, and either mitigated or formally accepted. Tiering says "this one needs a hard look." The assessment is the hard look.
For teams that want a number rather than a category, our risk scoring matrix gives one. It scores a risk as likelihood times impact, then adjusts for detectability, how quickly you'd catch the problem before it caused harm. A resume-screening tool scores likelihood 4 (bias in screening is common without mitigation) times impact 4 (employment discrimination carries legal and individual harm), for a base of 16. Bias is difficult to detect, so the detectability factor of 1.25 pushes it to 20: critical. The same arithmetic on a customer-service chatbot, possible-but-minor with easy detection, lands at 4.5: low. The detectability factor is the part people miss. Strong monitoring genuinely lowers a system's effective risk, because a problem you catch in real time does less damage than one you find in a lawsuit.
The scoring matrix and the tier agree by design: a critical or high score maps to the high-risk tier and its EU AI Act obligations, a medium score to limited, a low score to minimal. The tier is the fast answer; the score is the auditable one.
Why tiers beat a flat checklist
Three things go wrong when you skip tiering:
- You spend your scarce reviewers on low-risk systems because the process treats everything as equally important, and the reviewers who should be scrutinizing the credit model are signing off on dashboards.
- High-risk systems get under-examined because a checklist sized for the average case is too shallow for the dangerous one.
- Nobody notices when a system changes tier. A support chatbot is limited-risk until the day it starts quoting loan terms, at which point it's making credit-adjacent decisions and should be high-risk. Tiering only works if you reclassify on significant change, which is why change management is part of the process, not an afterthought.
Risk tiering isn't the whole of governance. It's the valve. It decides where the pressure of your review effort gets applied, and a governance program without it is either exhausting or negligent, usually both. If you're setting one up, start here:
- Adopt the four-tier taxonomy and write down the criteria for your industry and jurisdiction.
- Classify every system already in your inventory, and record the rationale for each.
- Put the classification step into project intake so new work is tiered before it's built.
- Reassess on any significant change in scope, data, or decision authority.
Then let the tier do what it's for: send the effort to the systems that can actually hurt someone.
