What are the EU AI Act's risk tiers?
The EU AI Act regulates AI systems by the risk their use poses, sorting them into four tiers with very different obligations:
- Unacceptable risk — prohibited outright. A narrow set of practices the Act bans, such as government social scoring and systems designed to manipulate behaviour in harmful ways.
- High risk — permitted but heavily regulated. Systems used in sensitive domains (for example biometric identification, critical infrastructure, employment and hiring, education, and access to essential services). They carry the bulk of the Act's obligations: risk management, data governance, technical documentation, human oversight, and a conformity assessment.
- Limited risk — transparency obligations. Systems that interact with people or generate content (chatbots, AI-generated media) must make clear that AI is involved.
- Minimal risk — the large majority of systems, with no mandatory obligations under the Act.
The practical point: obligations are a function of the tier, and the tier is a function of what the system is used for — not which model or framework it runs on.
How do you classify a system?
You classify by use and purpose, not by technology. The same model can be minimal-risk in one product and high-risk in another, because the Act asks what the system does in context, not what is under the hood. So classification starts from the use case: identify what the system decides or influences, who it affects, and in which domain. Then map that against the tiers — does the use fall in a high-risk domain? Does it interact with people, triggering transparency duties? Is the practice one the Act prohibits?
Because it is per-use, classification is not a one-time label on a repo. One system with two features can straddle two tiers, and a feature that changes what it does can change its tier. That is exactly why classification is easy to get wrong and easy to let go stale — which is the real operational problem.
Why classification drifts — and why a spreadsheet loses
The common pattern is a compliance spreadsheet: a tab listing each system and its assessed risk tier, maintained by hand. It breaks the same way prose policy breaks. It is a second copy of the truth, kept in sync manually, and it never stays in sync — a feature ships, the system's risk profile shifts, and the spreadsheet still says what was true last quarter. When an auditor asks “show me every high-risk system that processes personal data,” the honest answer is a week of an analyst's time and a hope that the tab is current.
The fix is to stop keeping a separate copy. When the risk classification is attached to the capability itself — alongside its declared capabilities — that question becomes a query against the system, and the classification travels with the capability when it changes instead of waiting for a manual update.
Classification as a system property, not a document
The durable approach treats regulatory classification the way a governed control plane treats every claim: as a property of the system that can be checked, not a document maintained beside it. Each declared capability carries the regimes it touches — an EU AI Act tier, a GDPR data category, a sector rule — so the build can enforce it (fail if a high-risk use ships without the controls its tier requires) and an auditor can query it (current, not reconstructed).
This is the third property of a governed control plane, alongside capability declaration and verifiable evidence — and it is why we publish disclosure formats that carry regulatory metadata as part of the Kinetic Gain Protocol Suite. Compliance stops being a spreadsheet you survive and becomes something the system can answer for. The practice is AI governance & evidence. This is an explainer, not legal advice — confirm your obligations with qualified counsel.