TL;DR
- Do not classify by model capability. It is unverifiable, it changes under you at every model update, and it does not describe your exposure.
- Classify by reach, reversibility and autonomy: all three verifiable from your own configuration.
- A four-tier scheme is enough. More tiers produce debate about boundaries and no additional control.
- The classification drives credential lifetime, oversight pattern, review interval and logging depth. If it drives nothing, it is paperwork.
- Regulatory classification is a separate exercise. EU AI Act high-risk status is determined by use case under Annex III, not by your internal tiering.
Why capability is the wrong axis
Schemes that grade agents by reasoning ability, autonomy level or model class share three defects.
They are unverifiable. You cannot inspect the capability of a hosted model, and vendor claims are marketing artefacts. A grade you cannot check is a grade you cannot defend to an assessor.
They are unstable. The underlying model is updated by the provider without your involvement, so a classification tied to capability silently expires. Re-grading an estate every time a provider ships is not operable.
They do not describe your exposure. A highly capable agent with read-only access to a public dataset can do nothing to you. A simple agent with write access to your billing system can do a great deal. Capability describes the model; reach describes the risk.
Three axes that work
- Reach: what systems and data classes it can touch, split into read and write. Verifiable from your own IAM configuration, and the single strongest predictor of consequence.
- Reversibility: can the effects be undone, by whom, and how quickly. A bulk update with a tested rollback is a different animal from an outbound customer email.
- Autonomy: does it act only on explicit request, on a schedule, or continuously in response to events. This determines how much can happen before anyone notices, which is why it matters independently of the other two.
Two secondary axes worth recording without letting them drive the tier: blast width (one record or the whole tenant) and audience (internal only, or does output reach customers or the public).
A four-tier scheme
| Tier | Definition | Required controls |
|---|---|---|
| T1. Observational | Read-only, internal data only, acts on explicit request | Registered with owner; standard credential lifetime; annual review; standard logging |
| T2. Reversible actor | Writes, but all effects are internally reversible with a tested path | Bounded credential lifetime; over-the-loop review with a real exception queue; semi-annual review; delegation chain logged |
| T3. Irreversible or external | Effects cannot be undone, or reach outside the organisation | Short-lived per-invocation credentials; in-the-loop approval on the irreversible subset; quarterly review; full chain logging; measured revocation path |
| T4. Consequential and autonomous | T3 reach, acting continuously without a request trigger | All T3 controls plus out-of-band approval, tested kill path with a recorded time, named accountable executive, and a documented risk acceptance |
Four tiers is deliberate. Schemes with seven produce meetings about whether something is a five or a six, and the distinction never changes a control.
Applying it so it does something
A classification that does not change any control is paperwork. Each tier should mechanically determine:
- Credential lifetime: shorter as the tier rises.
- Oversight pattern: per the human-in-the-loop table.
- Review interval: annual through quarterly.
- Logging depth: caller identity at T1, full delegation chain from T2 upward.
- Approval to deploy: team-level at T1 and T2, security review at T3, named executive at T4.
Two operational rules that prevent the scheme decaying. Classify at provisioning, from the requested reach, so the tier is set before the agent exists rather than argued about afterwards. And re-classify on scope change, automatically: an agent granted write access to a new system has changed tier whether or not anyone filed a form. If your issuance layer cannot trigger that, the scheme will drift within two quarters.
Regulatory classification is a separate exercise
Do not conflate the two
Your internal tier is an operational control input. EU AI Act high-risk status is determined by use case under the Act's annexes, not by your reach analysis. An agent you rate T1 may be high-risk under Annex III because of the domain it operates in, and a T4 agent may fall outside the Act entirely. Run both classifications and record them separately. Note also that the Digital Omnibus deferred Annex III high-risk obligations to 2 December 2027 and Annex I to 2 August 2028.
The same separation applies to sectoral regimes. A tier is what you use to decide how tightly to hold an agent. A regulatory classification is what determines which obligations attach. Neither substitutes for the other, and an assessor will ask for both.
Frequently asked questions
How should AI agents be classified for risk?
By reach, reversibility and autonomy rather than by model capability. Reach is what systems and data classes the agent can touch, split into read and write. Reversibility is whether effects can be undone, by whom and how quickly. Autonomy is whether it acts only on request, on a schedule, or continuously. All three are verifiable from your own configuration and stay stable when the underlying model changes.
Why not classify agents by model capability?
Three reasons. Capability of a hosted model is unverifiable and vendor claims are marketing artefacts, so the grade cannot be defended to an assessor. It is unstable, because providers update models without your involvement and the classification silently expires. And it does not describe your exposure: a highly capable agent with read-only access to public data can do nothing to you, while a simple agent with write access to billing can do a great deal.
How many risk tiers should an agent classification scheme have?
Four is sufficient: observational read-only, reversible actor, irreversible or externally reaching, and consequential plus autonomous. Schemes with more tiers generate debate about boundaries without changing any control. The test of whether a tier count is right is whether moving between adjacent tiers mechanically changes credential lifetime, oversight pattern, review interval, logging depth or deployment approval.
Does an internal agent risk tier determine EU AI Act high-risk status?
No, and conflating them is a common error. EU AI Act high-risk status is determined by use case under the Act's annexes, not by your internal reach analysis. An agent you rate as low tier internally may be high-risk under Annex III because of the domain it operates in, and a high-tier agent may fall outside the Act entirely. Run both classifications and record them separately.
How do you stop a risk classification scheme from drifting?
Classify at provisioning from the requested reach, so the tier is set before the agent exists, and re-classify automatically on scope change. An agent granted write access to a new system has changed tier whether or not anyone filed a form. If your issuance layer cannot trigger re-classification on a permission change, the scheme will be inaccurate within about two quarters.
Need agent oversight that would survive an assessor?
Human oversight that exists in design and not in evidence is the most common finding we see. HumanAudit tests oversight and risk classification against your real deployments, not your policy documents.