AI Act: classifying your AI systems (Annex III) in practice
The EU AI regulation does not apply in the same way to a writing assistant and to a tool that screens job applications. It all starts with a simple question that few organisations have taken seriously: which systems do you use, and which category do they fall into?
This article is a working method, not legal advice. The reference text is Regulation (EU) 2024/1689. For any binding decision, have the classification validated by a lawyer, and check the official timeline as of the date you are reading.
The principle: a risk-based approach
The AI Act does not regulate “AI” as a whole. It sorts uses into several levels:
- Prohibited practices (Article 5): social scoring, manipulation that exploits vulnerabilities, emotion recognition in the workplace and in education except for medical or safety reasons, building facial recognition databases through untargeted scraping, among others.
- High-risk systems (Article 6): those that are safety components of regulated products (Annex I), and those used in the areas listed in Annex III.
- Transparency obligations (Article 50): for example, telling people they are interacting with an AI system, or flagging certain generated content.
- Everything else, which is not subject to specific obligations, apart from the obligation to take measures to ensure AI literacy (Article 4).
General-purpose AI models (the large models most assistants are built on) have their own regime, which falls mainly on their providers.
The eight areas of Annex III
A system is presumed high-risk if it is intended to be used in one of these areas, for the uses the annex specifies:
- Biometrics: remote biometric identification, biometric categorisation, emotion recognition, insofar as these uses are permitted.
- Critical infrastructure: safety components in the management of critical digital infrastructure, road traffic, or the supply of water, gas, heating and electricity.
- Education and vocational training: admission, assessment of learning outcomes, guidance, exam proctoring.
- Employment and workforce management: recruitment, screening applications, evaluating candidates, promotion or termination decisions, task allocation, performance monitoring.
- Access to essential services: eligibility for public benefits, creditworthiness assessment and credit scoring (excluding fraud detection), pricing in life and health insurance, triage of emergency calls.
- Law enforcement: uses by or on behalf of law enforcement authorities.
- Migration, asylum and border control.
- Administration of justice and democratic processes: support for judicial decision-making, systems intended to influence an election.
For a private company, the areas that come up most are HR (4), credit and insurance (5), and occasionally biometrics (1) or infrastructure (2).
The Article 6(3) exception
A system listed in Annex III is not considered high-risk if it does not pose a significant risk to health, safety or fundamental rights, in particular when it performs a narrow procedural task, improves the result of a previously completed human activity, detects deviations without replacing human assessment, or performs a preparatory task.
Two important limits: a system that performs profiling of natural persons is always high-risk, and a provider relying on the exception must document its assessment before placing the system on the market, and register the system. The exception has to be justified in writing; it is never presumed.
Provider or deployer: who carries what
The second question, just as decisive as the first, is your role.
| Role | Who | Main obligations (high-risk) |
|---|---|---|
| Provider | Whoever develops the system, or has it developed, and places it on the market or puts it into service under their own name. | Risk management system, data governance, technical documentation, logging, instructions for use, human oversight, accuracy and robustness, quality management system, conformity assessment, CE marking, registration, post-market monitoring, reporting of serious incidents. |
| Deployer | Whoever uses the system under their authority in a professional context. | Use in line with the instructions, human oversight assigned to competent people, relevance of the input data they control, monitoring of operation, retention of logs, informing workers' representatives before use in the workplace, informing the people affected. A fundamental rights impact assessment for certain deployers, including public bodies and credit and insurance uses. |
Watch out for role drift: a deployer who puts their name or trademark on a system that is already high-risk, or substantially modifies it while it remains high-risk, becomes a provider. The same applies if they change the intended purpose of a system that was not high-risk in such a way that it becomes high-risk. They then carry all of the provider’s obligations. The risk is real whenever a team modifies a tool, or uses it for an Annex III purpose the provider never intended.
A staggered timeline
The regulation entered into force on 1 August 2024, with phased application:
- 2 February 2025: the Article 5 prohibitions and the obligation to take AI literacy measures.
- 2 August 2025: obligations for providers of general-purpose models, governance and penalties.
- 2 August 2026: general application of the regulation, including the Article 50 transparency obligations, which have applied since that date.
- 2 December 2027: obligations for Annex III high-risk systems.
- 2 August 2028: high-risk systems embedded in regulated products (Annex I).
These dates are those of the regulation as amended by the amending regulation known as the “Digital Omnibus on AI” (OJ L 2026/1744), adopted and applicable since 27 July 2026. It pushed back the high-risk obligations, which were originally due to apply in August 2026 and August 2027. Still, check the consolidated text for your own case. Either way, the inventory and the classification do not depend on these dates: they are the prerequisite for everything else.
The method, in five steps
- Inventory. Every system, including AI features built into purchased software and informal use of assistants. Shadow AI is the number one source of surprises.
- Describe the intended purpose. For each system: what it is for, who it affects, which decision it influences. It is the intended purpose, not the technology, that determines the category.
- Classify. Prohibited, high-risk (Annex I or III), transparency, or no specific obligation. For Annex III cases, examine and document the Article 6(3) exception.
- Qualify your role. Provider, deployer, or both depending on the system, watching for the modifications that tip you over.
- Plan. A compliance plan per high-risk system, with an owner, deadlines and the evidence expected.
The useful deliverable is not a hundred-page report. It is a living register, kept by someone and tied to product decisions. A RASCI-style responsibility matrix helps settle who keeps the register, who approves it and who must be consulted.
Where does AI in production fit in?
Compliance is not a brake on going to production; it is part of it. The requirements for logging, human oversight and monitoring overlap with what any serious system should do anyway: trace its decisions, allow a human to take over, measure its quality over time.
The projects that stall are the ones where legal discovers the system at launch. The ones that move forward build classification into scoping, as I explain in from AI proof of concept (POC) to production. On the team side, the AI literacy obligation already applies: training on real cases is the most direct way to meet it.