Risk Tiering in Practice: Classifying AI Systems You Already Run

Every AI governance programme reaches the same point. The register is populated, there are eighty or two hundred systems in it, and the next move is obvious: they cannot all get the same treatment, so they need tiering. The scheme gets written in an afternoon, usually with three or four tiers and a scoring sheet, and then it fails quietly over the following months.

It fails because of a single design error that is easy to make and hard to see. The scheme ranks systems by what they are, and the thing that matters is what they decide.

This guide is about getting that right. Why the common schemes misfire, what the EU AI Act's own classification test reveals about the correct frame, the four dimensions that genuinely separate one system from another, and how to tier a portfolio that is already running rather than one arriving through a clean intake process. For the legal tiers themselves, our EU AI Act guide is the reference and this guide does not restate them.

Why most tiering schemes fail

Three framings dominate the schemes that get written first, and each one produces a ranking that cannot be acted on.

Tiering by model type. Large language models in one bucket, classical machine learning in another, rules engines at the bottom. This feels technical and defensible, and it ranks a chatbot that summarises meeting notes above a logistic regression that decides who gets a loan. The model is the least consequential fact about a system.

Tiering by data sensitivity. Better, because it tracks a real harm, but it measures the wrong exposure. A system trained on entirely public data that assigns risk scores to applicants is more consequential than one that processes personal data to sort a mailbox. Data sensitivity is a privacy tier. It is not a decision tier, and the two get conflated constantly.

Tiering by whether it is generative. The newest and most common. Generative is a capability, not a consequence. It changes the failure modes you test for, which is useful, and it says nothing about whether being wrong costs someone a job.

The test the law already wrote

There is a piece of evidence for the right frame sitting in the EU AI Act, and it is more useful as a design artefact than as a compliance obligation.

Article 6(3) is the filter that decides whether a system listed in Annex III escapes high risk classification. It applies where the system poses no significant risk of harm to health, safety or fundamental rights, including by not materially influencing decision making, and it gives four conditions. Read them for what they are made of.

1. A narrow procedural task
   "the AI system is intended to perform a narrow procedural task". The question is the scope of the job, not the sophistication of the method used to do it.
2. Improving a completed human activity
   "the AI system is intended to improve the result of a previously completed human activity". A human has already decided. The system polishes the output.
3. Detecting patterns without replacing the human assessment
   "the AI system is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment, without proper human review".
4. A preparatory task
   "the AI system is intended to perform a preparatory task to an assessment". The system does work that feeds a decision somebody else makes.

Not one of the four mentions the model, the architecture, the training data or the modality. All four describe the system's position relative to a decision: before it, after it, alongside it, or in place of it. That is the variable the Act uses to separate a high risk system from one that merely sits in a sensitive domain.

The exception confirms it from the other direction. The derogation does not apply where the system performs "profiling of natural persons", which is always high risk. Profiling is the case where the system forms a judgement about a person, which is the most direct possible form of influence on a decision about them. The one thing the filter refuses to let through is the one thing that most clearly occupies the decision.

The Commission published draft guidelines on this classification on 19 May 2026, structured as general principles plus one part for each of the two routes into high risk. They remain in draft and were issued for stakeholder feedback, and the page says its examples are not exhaustive and may be updated. Treat them as the clearest available indication of how classification will be approached rather than as settled.

Four dimensions that actually separate systems

Generalising from that frame gives four questions. Together they do almost all the work of separating a portfolio, and every one of them can be answered by a business owner without a data scientist in the room.

Two of these are worth dwelling on because they are the ones most often skipped.

Decision role has to be assessed as operated, not as designed. Almost every consequential system is documented as a recommendation with a human in the loop. The honest question is what the override rate actually is. A recommendation that is accepted 99.4% of the time is a decision with a confirmation step, and tiering it as advisory is the single most common way a scheme understates its own portfolio. Where the override rate is unknown, that is itself a finding and usually the first thing to measure.

Contestability is a governance property, not a product one. It depends on whether the affected person knows the system was involved, whether a route to object exists, and whether the person handling the objection has authority to reverse the outcome. All three can be absent while the product documentation describes an appeals process.

A tier definition that survives a portfolio

Tiers fail when they are adjectives. High, medium and low are arguments waiting to happen, because the business owner's medium and the risk team's medium are different numbers. Tiers work when each one has an entry test somebody can apply without negotiating.

Three design rules make this hold up in practice.

Tier on the use, not on the system. The same model serving two use cases is two entries at two tiers. Organisations resist this because it inflates the register, and it is correct: the obligations attach to the use, and a tier assigned to a model is a tier that will be wrong for one of its uses.

Let the tier be raised but never silently lowered. Anyone should be able to escalate a system upward. Moving one down requires the same evidence and the same approver as the original classification, because downward movement is where a scheme quietly erodes.

Attach consequences to each tier before you classify anything. If Tier 1 and Tier 3 produce the same amount of work, people will pick whichever reads better and the scheme means nothing. The tier has to cost something, and the business has to know what before it answers the questions.

Tiering what you already run

Most guidance assumes systems arrive through an intake process where classification happens at the door. The real problem is usually a portfolio of systems that are already in production, built by people who have moved on, documented inconsistently or not at all.

1. Start from the use, and get it in one sentence
   For each entry, write what the system decides or influences, for whom, in one sentence with no technology in it. Where nobody can write that sentence, you have found something more interesting than a classification problem, which is a system with no identifiable owner or purpose.
2. Run the four questions, not a scoring matrix
   Weighted scoring across fifteen factors produces a number that feels objective and hides the one factor that mattered. Four questions with written answers produce a classification a reviewer can argue with, which is the property you want.
3. Measure the override rate on anything claiming a human in the loop
   This is the highest value measurement in the whole exercise and it usually already exists in an application log. It converts a claimed control into a number, and it frequently moves systems up a tier on evidence rather than on argument.
4. Classify the top of the portfolio properly and the tail cheaply
   A handful of systems will be obviously consequential and a long tail obviously not. Spend the effort on the band in the middle where the answer is genuinely contested. Blanket classifying the tail as lowest tier with a one line basis is defensible; leaving it unclassified is not.
5. Set a re-classification trigger, not a calendar
   Annual review catches changes up to a year late. Trigger on the events that actually change consequence: a new use case, a change in who is affected, removal of a human review step, or a material change in volume. Our guide to AI spend as a governance signal covers how a step change in consumption surfaces the last of those automatically.

The tier is a decision, so it needs a record

Classification is where governance programmes most often produce a conclusion with no supporting artefact. The system is listed as medium risk and nothing records who decided, on what basis, or against which version of the scheme.

The Act treats the negative case as a documented decision, which is a useful signal about what is expected. A provider concluding that an Annex III system is not high risk must, under Article 6(4), "document its assessment before that system is placed on the market or put into service", supply it to national competent authorities on request, and register under Article 49(2). The obligation attaches specifically to deciding that something is not in the heavier category, which is exactly the decision an internal scheme is most likely to make casually.

A defensible classification record is short and contains five things: the use in one sentence, the answers to the four questions, the resulting tier, the version of the scheme applied, and the person who approved it with a date. Our guide to audit ready evidence covers where records like this should live so they can be reproduced later.

The version matters more than it looks. Schemes get revised, and a system classified under the 2025 scheme and never revisited is carrying a tier that no longer means what the current scheme says it means. Without the version on the record there is no way to know which systems need re-running when the scheme changes.

The trade-offs nobody puts on the slide

Tiering by use multiplies the register. It is the right answer and it is genuinely more work, and anyone selling it as free is not being straight. The cost is real and the alternative is a register whose entries are wrong for most of what they cover.

A good scheme will raise your high risk count. Measuring override rates and assessing decision role as operated rather than as designed tends to move systems up. That is the scheme working, and it is worth warning the people who will see the number before they see it, because a jump in Tier 1 count reads as a failure if nobody explained why it was expected.

Regulatory classification and internal tiering are not the same exercise. They overlap and they answer different questions. The EU AI Act asks whether obligations attach. Your scheme asks how much assurance work a system deserves, including for systems the Act says nothing about. Running one scheme and labelling it both will either over-govern everything outside scope or under-govern everything inside it. Our risk classifier covers the regulatory question specifically.

Nobody is neutral about their own system. Self classification by the building team is fast and biased downward, and central classification is slow and uninformed. The workable arrangement is self classification against a scheme with hard entry tests, sampled and challenged centrally, with the sampling weighted toward anything self assessed as low.

Frequently asked questions

Where this leaves you

The reason tiering schemes get rewritten so often is that the first version usually sorts by the properties that are easiest to observe, and those are properties of the technology. Model type, data class and modality are all sitting right there in the documentation. Decision role, reversibility, reach and contestability have to be asked about, and the answers come from the business rather than from the system.

That extra step is the whole value. A scheme built on what systems decide produces a ranking that a business owner recognises, that an auditor can follow, and that still makes sense when the underlying technology changes, which it will. The Act's own filter was written that way, and the four conditions it uses contain no technology at all. That is not a coincidence, and it is the most useful hint in the whole classification problem.