The EU AI Act is often summarised as a pyramid: prohibited at the top, high-risk below it, transparency duties below that, and a broad base of minimal-risk systems. The summary is useful, but it hides the question that actually decides your workload. That question is not "which tier?" but "which role, in which area, under which exclusions?" This article walks through the tiers as a deployer sees them, with the Annex III areas, the provider and deployer split, and the two scope exclusions that a public body most often needs to consider.
The four levels, and which two are real classifications
Regulation (EU) 2024/1689 does not contain the word "tier". It contains four kinds of rule.
Prohibited practices (Art. 5). Eight practices that may not be placed on the market or used at all. Social scoring by public or private actors is Art. 5(1)(c). Emotion inference in the workplace and in education is Art. 5(1)(f). These rules apply from 2 February 2025.
High-risk AI systems (Art. 6 and Annex III). The systems that carry the heavy duties: risk management, data governance, technical documentation, logging, human oversight, conformity assessment and registration for providers, and a shorter but real list for deployers under Art. 26.
Transparency duties (Art. 50). Duties that attach to a feature, whatever the risk classification: chatbots, emotion recognition, biometric categorisation, deep fakes and AI-generated public-interest text.
Everything else. A system that is none of the above still owes the horizontal duties, notably AI literacy for staff under Art. 4, and the GDPR still governs any personal data involved.
Only the first two are classifications in a legal sense. "Limited risk" and "minimal risk" are convenient labels for the last two, and a tool that prints them should say what they rest on.
What high-risk actually means
There are two routes into high risk. Under Art. 6(1), a system is high-risk when it is a safety component of a product covered by the Annex I product legislation, such as machinery or medical devices, and that product needs third-party conformity assessment. Public bodies rarely meet this route.
Under Art. 6(2), a system is high-risk when it is used in one of the areas listed in Annex III. The eight areas are:
- Biometrics: remote biometric identification, biometric categorisation by sensitive attributes, and emotion recognition.
- Critical infrastructure: safety components in digital infrastructure, road traffic, and the supply of water, gas, heating and electricity.
- Education and vocational training: admission, assessment, level assignment and exam monitoring.
- Employment and worker management: recruitment, selection, promotion, termination and task allocation.
- Essential services: eligibility for public assistance benefits (5(a)), creditworthiness (5(b)), life and health insurance pricing (5(c)), and emergency call triage (5(d)).
- Law enforcement.
- Migration, asylum and border control.
- Administration of justice and democratic processes.
Being in an Annex III area is the default trigger. Art. 6(3) then provides a narrow derogation: an Annex III system is not high-risk if it does not pose a significant risk to health, safety or fundamental rights, and one of four conditions holds, such as performing a narrow procedural task or a preparatory task. Two limits apply. The derogation is never available where the system performs profiling of natural persons. And under Art. 6(4) the provider must document the assessment before the system is put into service, and register it under Art. 49(2). A derogation that exists only in someone's head is not a derogation.
Provider duties and deployer duties are different lists
The Act defines a provider (Art. 3(3)) as the party that develops a system, or has it developed, and places it on the market or puts it into service under its own name or trademark. A deployer (Art. 3(4)) uses a system under its own authority, other than for personal non-professional activity.
Providers of high-risk systems owe Chapter III, Section 2: the risk management system (Art. 9), data governance (Art. 10), technical documentation (Art. 11), record-keeping (Art. 12), transparency to deployers (Art. 13), human oversight design (Art. 14) and accuracy, robustness and cybersecurity (Art. 15), plus conformity assessment and registration under Art. 49(1).
Deployers owe Art. 26. In practice that means: use the system according to the instructions, assign human oversight to competent and authorised people, ensure input data you control is relevant and representative, monitor operation, keep the automatically generated logs for at least six months, inform workers where the system is used at work, inform natural persons subject to decisions, and cooperate with authorities. Public bodies and private entities providing public services add the fundamental rights impact assessment under Art. 27. Public authorities add registration of their use under Art. 49(3). Affected persons gain a right to an explanation under Art. 86.
A deployer becomes a provider under Art. 25 if it puts its name on the system, substantially modifies it, or changes its intended purpose so that it becomes high-risk. A municipality that retrains a vendor's model on its own data should ask that question before assuming the shorter list.
The two exclusions a public body should know
Art. 2(3) says the Regulation does not apply to AI systems placed on the market, put into service or used exclusively for military, defence or national security purposes, regardless of the type of entity. Art. 2(6) says it does not apply to systems or models specifically developed and put into service for the sole purpose of scientific research and development.
Both turn on the word "exclusively" or "sole". A defence organisation that uses a system for personnel administration is not using it exclusively for defence. A university lab that hands a research prototype to a municipality has put it into service for something other than research. And neither exclusion touches the GDPR: the data-protection duties survive intact.
A worked example
The fictional municipality of Havelbrug buys a case-triage system from a supplier. Caseworkers use it to rank applications for housing benefit by likely eligibility. The municipality does not retrain it and uses it as delivered.
Role: deployer. Area: Annex III point 5(a), access to essential public services and benefits. Exclusions: none. Derogation: the supplier claims the system only "prepares" the case. But it scores individual applicants, which is profiling, so the last subparagraph of Art. 6(3) closes that door. Result: a high-risk system. Havelbrug owes Art. 26, the Art. 27 assessment, Art. 49(3) registration and Art. 86 explanations. It does not owe Art. 9 to 15; those are the supplier's.
Dates, and a caution
The Act entered into force on 1 August 2024. Art. 4 and Art. 5 apply from 2 February 2025. The general-purpose AI model rules apply from 2 August 2025. Most Annex III duties apply from 2 August 2026, and the Annex I product route from 2 August 2027. The European Commission's Digital Omnibus proposal, tabled in late 2025, proposed moving some of the high-risk dates. Check the adopted text before you plan a go-live around a date.
How Landfall helps
Landfall asks the questions above in order: whether an AI system is deployed, in which role, in which Annex III areas, whether an exclusion is claimed, and whether a derogation is documented. From those answers it computes the tier deterministically, with an article citation on every step of the rationale. An unanswered question yields "undetermined" rather than a low tier. The report separates the duties a deployer owes from the provider duties it does not, so a municipality is not handed a conformity-assessment file for a system it bought.