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.

How the tier is derived

The platform walks the answers in this order and stops at the first rule that matches:

Any prohibited practice → PROHIBITED, citing each Art. 5(1) point.
Out of scope asserted → OUT_OF_SCOPE.
Annex I safety component → HIGH_RISK (Art. 6(1)).
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.
Any Art. 50 trigger → LIMITED.
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).

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.

Review dates

Each classification gets a review date when the assessor signs it: the signing date plus the review interval that the 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

{
  "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.

Overview

Where things live, day one after upgrading, permissions.

Governance record

Owners, oversight, documents, readiness and Art. 50 transparency.

Lifecycle and policy

States, suspension, retirement and the tenant governance policy.

Incidents and evidence

Serious incidents, the register, exports and the evidence pack.

Get Started

AI governance (EU AI Act)

Evaluations

Risk classification

Risk classification

Risk tiers

The wizard

How the tier is derived

Overriding the tier

Second signature for high-risk tiers

Classification history

Review dates

Own tier and effective tier

MCP server impact profile

Prohibited systems

API

Next

Overview

Governance record

Lifecycle and policy

Incidents and evidence

​Risk classification

​Risk tiers

​The wizard

​How the tier is derived

​Overriding the tier

​Second signature for high-risk tiers

​Classification history

​Review dates

​Own tier and effective tier

​MCP server impact profile

​Prohibited systems

​API

​Next

Overview

Governance record

Lifecycle and policy

Incidents and evidence

Risk classification

Risk tiers

The wizard

How the tier is derived

Overriding the tier

Second signature for high-risk tiers

Classification history

Review dates

Own tier and effective tier

MCP server impact profile

Prohibited systems

API

Next