> ## Documentation Index
> Fetch the complete documentation index at: https://docs.swarmd.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Risk classification
> How a system's EU AI Act risk tier is derived from a signed questionnaire, when a second signature is needed, and how MCP servers and LLM gateways inherit the tier of the agents that use them.
# Risk classification
The Act classifies; it does not score. A classification on the platform is a
questionnaire that walks the Act's own decision tree in the Act's order. The
platform derives the tier from the answers, shows the articles it rests on,
and records the person who signed it. The answers are stored with the tier,
so the reasoning survives even if the tier is later changed.
You classify from the system's **Governance › Classification** page with
**Classify** (or **Reclassify** once a classification exists). The same
wizard is used for agents, MCP servers and LLM gateways.
***
## Risk tiers
| Tier (API value) | Shown as | Legal basis | Meaning |
| - | - | - | - |
| `UNCLASSIFIED` | Unclassified | — | No classification recorded yet. Every existing system starts here after the upgrade. |
| `OUT_OF_SCOPE` | Out of scope | Art. 2, Art. 3(1) | Not an AI system, or excluded from the Act. A rationale is required. |
| `MINIMAL` | Minimal risk | — | In scope, with no Annex I or Annex III use and no Art. 50 trigger. |
| `LIMITED` | Limited risk | Art. 50 | One or more Art. 50 transparency duties apply, and nothing higher does. |
| `HIGH_RISK_EXEMPT` | High-risk (exempt) | Art. 6(3), Art. 6(4), Art. 49(2) | An Annex III use case with a documented Art. 6(3) derogation, and no profiling of natural persons. Still needs registration and a written assessment. |
| `HIGH_RISK` | High-risk | Art. 6(1), Art. 6(2) | An Annex III use case without a derogation, or a safety component of an Annex I product. |
| `PROHIBITED` | Prohibited | Art. 5 | Matches a prohibited practice. |
The tiers are ordered as listed, from least to most strict. Wherever the
platform compares tiers (inheritance, gates, oversight) it uses this order.
***
## The wizard
The wizard has seven steps. The progress bar uses the short label; each step
opens with the full title.
| Step | Title | What you answer |
| - | - | - |
| Role | Role and intended purpose | Your role for this system — **Provider** (you developed it, Art. 3(3)), **Deployer** (you use it under your authority, Art. 3(4)) or **Provider and deployer** — and the intended purpose (Art. 3(12)), at least ten characters. Optionally the date it was placed on the market or put into service. |
| Scope | Scope | Whether the system is outside the Act's scope (Art. 2 exclusions, or not an AI system under Art. 3(1)). |
| Art. 5 | Prohibited practices | Every Art. 5(1) practice the system performs or enables, including the two points added by the Digital Omnibus (non-consensual intimate imagery and child sexual abuse material). |
| High-risk | High-risk classification | Whether it is a safety component of an Annex I product that needs third-party conformity assessment, and every Annex III use case it falls under (25 points across eight areas). |
| Derogation | Art. 6(3) derogation | Only when an Annex III use case was ticked: which of the four Art. 6(3) conditions apply, and whether the system profiles natural persons. |
| Art. 50 | Transparency obligations | Whether it interacts directly with people, generates synthetic content, performs emotion recognition or biometric categorisation, or produces deepfakes or public-interest text. |
| Sign | Review and sign | The derived tier and its legal basis, an optional upward override, and a rationale. **Sign classification** records you as the assessor. |
The derived tier updates as you answer, so you can see the effect of each
answer before you sign.
The intended purpose matters beyond this form. For a **deployer-role** agent,
a new version that changes the agent's name or description brings the review
forward (Art. 25(1): you may have become the provider). See
[Review dates](#review-dates).
***
## How the tier is derived
The platform walks the answers in this order and stops at the first rule that
matches:
1. **Any prohibited practice** → `PROHIBITED`, citing each Art. 5(1) point.
2. **Out of scope asserted** → `OUT_OF_SCOPE`.
3. **Annex I safety component** → `HIGH_RISK` (Art. 6(1)).
4. **Any Annex III use case** → `HIGH_RISK` (Art. 6(2) plus each Annex III
point), **unless** at least one Art. 6(3) condition is claimed **and** the
system does not profile natural persons, in which case
`HIGH_RISK_EXEMPT`. If a derogation is claimed but the system profiles
people, the tier stays `HIGH_RISK` and the legal basis cites the profiling
bar.
5. **Any Art. 50 trigger** → `LIMITED`.
6. Otherwise → `MINIMAL`.
Art. 50 duties apply on top of the high-risk regime, so the Art. 50
references are added to the legal basis of any in-scope tier, not only
`LIMITED`. A high-risk agent that talks to people still has the disclosure
obligation.
The same answers always give the same tier and the same legal basis.
***
## Overriding the tier
On the **Review and sign** step you can **raise** the tier above the derived
one. You cannot lower it: to reach a lower tier, change the answers, which is
a new classification with its own reasoning. You cannot override to
Unclassified.
A rationale is required when you override, and also when you assert the
system is **out of scope**. The wizard will not let you sign without one.
***
## Second signature for high-risk tiers
A classification whose final tier is **High-risk** or **High-risk (exempt)**
needs a second signature (Art. 17(1)(m)) from someone other than the
assessor.
Until it is approved:
* the system's governance state stays where it was — a system in **Draft**
does not move to **Assessed**, so it cannot be put into service;
* the register shows the row with `approvalPending: true` and counts it in
the *Pending approval* tile;
* the Classification page shows *Approved by: Pending*.
To approve, a second person with Write on the system opens the
**Classification** page and presses **Approve classification**. The button is
disabled for the assessor, and the server refuses the assessor's signature
too. Only the latest classification can be approved; once someone
reclassifies, the earlier pending one can no longer be approved.
A pending high-risk classification **already counts as high-risk** for
everything that reads the tier: the readiness obligations, the gate, the
human-oversight check in the relay, and the tier MCP servers and gateways
inherit. The register never hides a pending high-risk finding. What the
second signature changes is the governance state: only an approved
classification moves a system from Draft to Assessed.
`PROHIBITED` does not wait for a second signature; it takes effect as soon as
it is signed (see [Prohibited systems](#prohibited-systems)).
***
## Classification history
Every submission appends a new, numbered classification. The previous one is
superseded, never edited, and stays visible under **Previous
classifications** and in the evidence pack. The current one shows the
derived tier, the final tier, the legal basis, the answers as signed, the
rationale, the assessor and the approver.
Reclassifying a system that is already **In service** does not take it out of
service (unless the new tier is Prohibited). If the change is substantial, use
**Require reassessment** on the lifecycle page — see
[Lifecycle and policy](/governance/lifecycle-and-policy#transitions).
***
## Review dates
Each classification gets a review date when the assessor signs it: the
signing date plus the review interval that the
[governance policy](/governance/lifecycle-and-policy#tenant-governance-policy)
sets for the final tier. With the platform defaults that is **12 months** for
High-risk and High-risk (exempt) and **24 months** for every other tier.
* Changing the policy interval affects classifications signed after the
change; existing review dates are not recalculated.
* The second signature does not move the review date.
* A review is due when the date passes. The register's *Review overdue* tile
counts those systems, and the Classification page asks you to reclassify.
* **Brought-forward reviews (Art. 25).** When a new version of a classified,
**deployer-role** agent changes the agent's name or description, the review
becomes due immediately. The register shows it under the *Reassessment
pending* filter and the Classification page explains why. Signing a new
classification clears it.
***
## Own tier and effective tier
Agents have one tier: their own classification. MCP servers and LLM gateways
have two:
| | Own tier | Effective tier |
| - | - | - |
| Agent | Its latest classification | Same as its own tier |
| MCP server | Its latest classification | The strictest of its own tier and the latest classification of every agent with an **active** subscription to it |
| LLM gateway | Its latest classification | The strictest of its own tier and the latest classification of every agent with an **active** subscription to it |
A tool server used by one high-risk agent is therefore treated as high-risk
itself. The Classification page lists the contributing agents under
**Inherited from agents**. The effective tier is recomputed on every read:
when a subscription is removed or an agent is reclassified, the inherited
tier follows immediately.
Everything that depends on the tier — obligations, readiness, the gate, the
human-oversight check, second signatures for retirements and suspension
lifts — uses the **effective** tier. The register's *Unclassified* tile and
filter use the **own** tier, so an MCP server you have not classified yet
still shows as unclassified even if it inherits a tier.
Classify agents before the MCP servers and gateways they use. An
unclassified agent contributes nothing to an inherited tier, so the tool
servers behind it look lower-risk than they are until it is classified.
***
## MCP server impact profile
An MCP server's owner can declare what its tools reach and do, on the
server's Classification page (**Impact profile**). The profile **does not
change the tier**; it decides which obligations apply.
| Field | Values |
| - | - |
| Data categories | No personal data · Personal data · Special-category data (GDPR Art. 9) · Biometric data · Financial data · Health data · Data about children |
| Action capability (the most consequential thing its tools can do) | Read only · Writes or changes state · Irreversible actions · Moves money or makes payments |
| Safety component | Fulfils a safety function whose failure endangers health, safety or property (Art. 3(14)) |
| Affects natural persons | Its outputs feed decisions about, or interactions with, people |
What it drives:
* For an MCP server at Minimal tier or above (own or inherited), *Impact
profile declared* is a mandatory obligation.
* When the action capability is **Irreversible actions** or **Moves money**,
the server needs at least one oversight person with a current AI literacy
attestation, whatever its tier.
***
## Prohibited systems
A Prohibited classification takes effect immediately, without a second
signature. What happens next depends on the system's state:
| State when classified | What happens |
| - | - |
| Draft | Moves to **Assessed**, with a note that it cannot enter service. **It is not frozen** and keeps serving traffic. |
| Assessed | No state change. Not frozen. |
| In service | **Suspended** with reason *Non-conformity*, and the kill switch is engaged. Callers get `Sink agent is frozen`. |
In every state, the gate then refuses to put it into service, register a new
version of it, reactivate it or publish it to the marketplace.
Classifying a Draft or Assessed agent as Prohibited does **not** stop its
traffic. If it is serving requests, freeze it with the **Freeze** button on
the agent's page, then decide whether to retire it. An LLM gateway has no
kill switch: classifying a gateway that is **In service** as Prohibited is
refused. Suspend the agents that use the gateway instead.
***
## API
Through the gateway, under `/registry`. Replace `agents/{agentId}` with
`mcp-servers/{mcpServerId}` or `llm-gateways/{llmGatewayId}` for the other
subject types.
| Method and path | Purpose |
| - | - |
| `GET /registry/v1/agents/{agentId}/governance` | The whole governance record, including the latest classification and readiness |
| `POST /registry/v1/agents/{agentId}/governance/classifications` | Submit a classification (`answers`, optional `overrideTier`, `rationale`, `placedOnMarketAt`) |
| `POST /registry/v1/agents/{agentId}/governance/classifications/{seq}/approve` | The second signature |
| `GET /registry/v1/agents/{agentId}/governance/classifications` | Classification history, newest first |
| `PUT /registry/v1/mcp-servers/{mcpServerId}/governance/impact-profile` | Declare an MCP server's impact profile |
```json theme={null}
{
"answers": {
"operatorRole": "DEPLOYER",
"intendedPurpose": "Answers customer questions about orders and returns on the web shop.",
"transparencyObligations": ["INTERACTS_WITH_NATURAL_PERSONS"]
},
"rationale": "Customer-facing chat; no Annex III use."
}
```
Yes/no answers you leave out count as "no", and lists you leave out count as
empty. The response includes `derivedTier`, `riskTier` (the final tier),
`legalBasis`, `approvalPending` and `reviewDueAt`.
***
## Next
Where things live, day one after upgrading, permissions.
Owners, oversight, documents, readiness and Art. 50 transparency.
States, suspension, retirement and the tenant governance policy.
Serious incidents, the register, exports and the evidence pack.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.