Most of the EU AI Act's cost and effort sits in one category, high-risk AI systems, and many organisations still cannot say which of their systems fall into it. Classification decides whether a system needs a risk management system, technical documentation, logging, human oversight, conformity assessment, CE marking and registration, or none of these. The Digital Omnibus on AI, Regulation (EU) 2026/1744, changed the dates and several rules in July 2026, so plans written in 2025 need revisiting. This guide explains the two classification routes, the Annex III use cases, the provider and deployer obligations, the current timeline, penalties, and what the rules mean for AI agents and the machine identities they run on. It is written for security, risk and compliance practitioners and for executives who own AI programmes. For the Act as a whole, see the EU AI Act Compliance Guide.
Key takeaways
- There are two routes into high-risk. A system is high-risk if it is a safety component of, or is itself, a product under Annex I legislation that needs third-party conformity assessment, or if its use case is listed in Annex III.
- The Annex III exception is narrow and must be documented. Article 6(3) lets a provider treat an Annex III system as not high-risk only for narrow, preparatory or pattern-detection tasks, never where the system profiles people, and the assessment must be written down and the system registered.
- The dates moved. After the Digital Omnibus, the Annex III obligations apply from 2 December 2027 and the Annex I product obligations from 2 August 2028, according to the consolidated Article 113.
- Deployers have real duties too. Using a high-risk system means following instructions for use, assigning competent human oversight, keeping logs for at least six months, informing workers and affected people, and in some cases a fundamental rights impact assessment.
- Article 15 is a security requirement. High-risk systems must resist data poisoning, model poisoning, adversarial examples, confidentiality attacks and exploitation of model flaws, which puts the security team inside the conformity file.
Scope: who and what is covered
The AI Act (Regulation (EU) 2024/1689) applies to providers placing AI systems on the EU market or putting them into service in the EU, wherever they are established, to deployers established or located in the EU, and to providers and deployers in third countries where the system's output is used in the EU (Article 2). Importers, distributors and authorised representatives are also in scope. Military, defence and national security uses, pure scientific research and personal non-professional use are excluded; free and open-source systems are not exempt if they are high-risk.
The two classification routes
| Route | Test (Article 6) | Typical examples | Conformity assessment |
|---|---|---|---|
| Annex I (product safety) | The AI system is a safety component of a product, or is itself a product, covered by Annex I Union harmonisation legislation, and that product needs third-party conformity assessment (Article 6(1)) | AI in medical devices, machinery, toys, lifts, radio equipment | Follows the sectoral procedure, with the AI Act requirements assessed as part of it (Article 43(3)) |
| Annex III (use case) | The system's intended purpose falls in one of the eight Annex III areas (Article 6(2)), unless the Article 6(3) derogation applies | CV screening, credit scoring, exam proctoring, benefit eligibility | Internal control under Annex VI for points 2 to 8; biometrics may need a notified body under Annex VII |
The Digital Omnibus added Article 6(1a) to (1c). AI used solely for non-safety purposes such as user assistance, performance optimisation, automation, convenience or quality control does not qualify as a safety component, unless its failure or malfunction would endanger health and safety. A product that needs third-party assessment only for risks other than health and safety, for example radio spectrum interference, does not meet the Annex I condition.
The Annex III use cases
| Annex III area | Listed use cases | Notable exclusions |
|---|---|---|
| 1. Biometrics | Remote biometric identification; biometric categorisation by sensitive attributes; emotion recognition | Verification whose sole purpose is confirming a claimed identity |
| 2. Critical infrastructure | Safety components in critical digital infrastructure, road traffic, and supply of water, gas, heating or electricity | None listed |
| 3. Education and vocational training | Admission and assignment; evaluating learning outcomes; assessing the level of education; monitoring prohibited behaviour during tests | None listed |
| 4. Employment and workers' management | Recruitment and selection, including targeted job adverts and filtering applications; promotion, termination, task allocation and performance monitoring | None listed |
| 5. Essential private and public services | Public benefit eligibility; creditworthiness and credit scores; life and health insurance pricing; emergency call triage and dispatch | Systems used to detect financial fraud |
| 6. Law enforcement | Victim risk; polygraph-type tools; evidence reliability; offending risk; profiling in investigations | Only where permitted by Union or national law |
| 7. Migration, asylum and border control | Polygraph-type tools; risk assessment of entrants; examining applications; detecting and identifying persons | Verification of travel documents |
| 8. Justice and democratic processes | Assisting judicial authorities; influencing elections or voting behaviour | Campaign tools whose output people are not directly exposed to |
The Article 6(3) derogation
An Annex III system is not high-risk if it poses no significant risk of harm to health, safety or fundamental rights and does not materially influence decision-making. That is the case where it (a) performs a narrow procedural task, (b) improves the result of a previously completed human activity, (c) detects decision patterns or deviations without replacing or influencing the human assessment without proper review, or (d) performs a preparatory task. A system that profiles natural persons is always high-risk. A provider relying on the derogation must document the assessment before placing the system on the market and register the system under Article 49(2). Draft Commission classification guidelines with examples were published for consultation on 19 May 2026.
When you become the provider
Article 25 turns a distributor, importer, deployer or other third party into a provider, with all Article 16 obligations, if it puts its own name or trademark on a high-risk system, makes a substantial modification that keeps it high-risk, or changes the intended purpose of a non-high-risk system, including a general-purpose AI system, so that it becomes high-risk.
Key obligations
Provider requirements (Articles 8 to 17)
- Risk management (Article 9): a documented, iterative process across the lifecycle that identifies, evaluates and treats foreseeable risks, including reasonably foreseeable misuse. See the AI Risk Assessment Guide.
- Data and data governance (Article 10): training, validation and test data that are relevant, sufficiently representative and examined for bias.
- Technical documentation (Article 11, Annex IV): the evidence file a market surveillance authority or notified body will read.
- Record-keeping (Article 12): automatic event logging over the system's lifetime, sufficient for risk identification, post-market monitoring and deployer monitoring. Remote biometric identification systems must log at least each use's start and end time, the reference database, the input data that produced a match and the identity of the people who verified the result.
- Transparency to deployers (Article 13): instructions for use, including declared accuracy levels and metrics (Article 15(3)).
- Human oversight (Article 14): overseers must be able to understand the system's limits, stay aware of automation bias, interpret output, decline or override it, and stop the system through a "stop" button or similar procedure that brings it to a safe state. For remote biometric identification, no action is taken on a match unless two competent people have separately verified it.
- Accuracy, robustness and cybersecurity (Article 15): resilience to errors and faults, mitigation of feedback loops in systems that keep learning, and measures to prevent, detect, respond to, resolve and control data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks and model flaws.
- Quality management system (Article 17) and the other Article 16 duties: provider name and contact on the system, documentation and log retention, conformity assessment (Article 43), EU declaration of conformity (Article 47), CE marking (Article 48), registration (Article 49(1)), corrective action (Article 20) and accessibility.
Deployer obligations (Article 26 and 27)
| Obligation | Article | Practical evidence |
|---|---|---|
| Assign human oversight to people with competence, training, authority and support | 26(2) | Named overseers, training records, escalation rights |
| Input data relevant and sufficiently representative, where the deployer controls it | 26(4) | Data quality checks on prompts, features and retrieval sources |
| Monitor operation; report risks and serious incidents; suspend use where needed | 26(5) | Monitoring runbook, supplier contact path |
| Keep logs under the deployer's control for at least six months | 26(6) | Retention policy aligned with data protection law |
| Inform workers' representatives and affected workers before workplace use | 26(7) | Works council notice |
| Inform people subject to Annex III decisions | 26(11) | Notices in the decision journey |
| Use Article 13 information for the GDPR Article 35 DPIA | 26(9) | DPIA referencing the provider's documentation |
| Fundamental rights impact assessment before first use (public bodies, private entities providing public services, credit scoring and life or health insurance pricing) | 27 | FRIA with processes, affected groups, risks, oversight and complaint routes, notified to the market surveillance authority |
Incident reporting
Under Article 73, providers report serious incidents to the market surveillance authority of the Member State where the incident occurred, no later than 15 days after becoming aware, no later than 2 days for widespread infringements or incidents under Article 3(49)(b), and no later than 10 days where a person has died. The provider must investigate without altering the system before informing authorities. Deployers who identify a serious incident inform the provider first. See the AI Incident Reporting Guide.
Timeline and current status
The dates below are taken from the consolidated Article 113 on the Commission's AI Act Service Desk, which reflects the Digital Omnibus (Regulation (EU) 2026/1744, in force 27 July 2026). Further amendment is possible, so confirm against the official text before relying on a date.
| Date | What applies |
|---|---|
| 2 February 2025 | Chapters I and II: definitions, AI literacy and the Article 5 prohibitions |
| 2 August 2025 | Notified bodies (Chapter III Section 4), general-purpose AI models, governance and the penalties chapter |
| 2 August 2026 | General date of application, including Article 50 transparency (with a delay to 2 December 2026 for marking of content from systems already on the market before 2 August 2026) |
| 2 December 2027 | High-risk requirements for Annex III systems (Article 6(2)) |
| 2 August 2028 | High-risk requirements for Annex I product systems (Article 6(1)) |
The Omnibus also reinstated a simplified registration requirement for Annex III systems that providers consider not high-risk, extended some simplifications to small mid-cap companies, and amended conformity assessment and FRIA provisions (Articles 27(4) and (5), 43).
Enforcement and penalties
National market surveillance authorities supervise high-risk systems; the penalties chapter has applied since 2 August 2025. Article 99 sets three tiers.
| Infringement | Maximum fine |
|---|---|
| Prohibited practices (Article 5) | EUR 35 million or 7% of worldwide annual turnover, whichever is higher |
| Provider, authorised representative, importer, distributor, deployer and notified body obligations (Articles 16, 22 to 24, 25(2) and (4), 26, 31, 33 and 34) and Article 50 transparency | EUR 15 million or 3%, whichever is higher |
| Incorrect, incomplete or misleading information to notified bodies or authorities | EUR 7.5 million or 1%, whichever is higher |
For SMEs and start-ups the cap is whichever is lower. The Omnibus added the same lower cap for small mid-cap companies for the second and third tiers. Authorities weigh gravity, cooperation, the operator's measures, self-notification and intent (Article 99(7)).
What it means for AI agents and non-human identities
An AI agent is high-risk when its intended purpose falls under Annex III or Annex I, for example an agent that shortlists candidates or sets credit limits. Reconfiguring a general-purpose agent for such a purpose is the Article 25 case.
- Oversight needs an off switch that works: the Article 14(4)(e) stop capability maps directly to revoking the agent's credentials and tokens. If a human cannot cut the agent's access to downstream systems quickly, the oversight design is incomplete. See the AI Agent Kill Switch and Containment Guide and the Human-in-the-Loop for AI Agents Guide.
- Logs must be attributable: Article 12 traceability and the six-month deployer retention only help if each action is logged against a distinct agent identity, not a shared service account or API key.
- Least privilege is a robustness control: an agent with broad tokens turns a model error into an incident. The PocketOS database deletion, where an AI coding agent used an over-privileged token to wipe production, shows the failure mode Article 15(4) asks providers to design against.
- Prompt injection and excessive agency are Article 15(5) matters: OWASP LLM01:2025 Prompt Injection and LLM06:2025 Excessive Agency describe how inputs can redirect an agent's actions; MITRE ATLAS AML.T0051 LLM Prompt Injection, AML.T0020 Poison Training Data and AML.T0043 Craft Adversarial Data give testable threat cases. See the MITRE ATLAS Guide.
- Supplier agreements cover identities: Article 25(4) requires written agreements with suppliers of components, tools, models and services; include how credentials, keys and service accounts used by the supplier's components are issued, rotated and revoked.
Compliance steps
- Build the inventory: list every AI system and agent, its intended purpose, owner, supplier and the identities it uses. See the AI Register and AI Inventory Template.
- Classify and record the reasoning: test each entry against Annex I and Annex III, document any Article 6(3) derogation with the specific condition relied on, and confirm no profiling is involved. Have legal counsel review borderline cases.
- Decide your role per system: provider, deployer, importer or distributor, and check every Article 25 trigger (own branding, substantial modification, change of intended purpose).
- Gap-assess against Articles 9 to 15 and 26: start with logging, oversight and cybersecurity, which take the longest to engineer.
- Pilot one system end to end: assemble the technical documentation, QMS procedures and declaration of conformity for a single system before scaling, and test the oversight stop path in a non-production environment.
- Run adversarial testing: red-team for poisoning, evasion, prompt injection and data leakage, and record results in the technical file. See the AI Red Teaming Guide.
- Prepare deployer artefacts: worker notices, affected-person notices, DPIA updates and, where required, the FRIA.
- Stand up post-market monitoring and incident reporting: define what counts as a serious incident, who decides, and how the 2, 10 and 15 day clocks are met.
- Plan rollback: keep the previous model version and a manual process ready, so that suspending use under Article 26(5) does not stop the business.
Choosing your approach
- Buy versus build: buying a high-risk system from a provider leaves you with deployer duties and supplier due diligence; building or substantially modifying one makes you the provider with the full conformity burden.
- Small organisations: avoid accidental provider status and keep deployer evidence.
- Large organisations: integrate AI Act controls into an existing management system such as ISO/IEC 42001 rather than running a parallel programme. See the ISO/IEC 42001 Guide.
Detection and measurement
- Percentage of inventoried AI systems with a recorded classification decision and owner.
- Number of Article 6(3) derogations, each with documented reasoning and registration.
- Percentage of high-risk systems whose actions are logged against a distinct identity, with retention of at least six months.
- Time to stop a high-risk system and revoke its credentials in a test (target: minutes).
- Override and reversal rate by human overseers, a signal for automation bias or model drift.
Framework mapping
| AI Act requirement | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Legal classification and obligations (Art. 6, 16, 26) | PM-9 Risk Management Strategy | GV.OC-03 |
| Inventory of AI systems | CM-8 System Component Inventory | ID.AM-02 |
| Risk management (Art. 9) | RA-3 Risk Assessment | ID.RA-04 |
| Record-keeping and log retention (Art. 12, 26(6)) | AU-12 Audit Record Generation, AU-11 Audit Record Retention | DE.CM-09 |
| Post-market and deployer monitoring (Art. 26(5), 72) | CA-7 Continuous Monitoring | DE.CM-09 |
| Serious incident reporting (Art. 73) | IR-6 Incident Reporting | GV.OC-03 |
| Value chain agreements (Art. 25(4)) | SR-3 Supply Chain Controls and Processes | GV.SC-05 |
| Limiting agent access (Art. 15(4), 15(5)) | AC-6 Least Privilege | PR.AA-05 |
Common failure patterns
- Classifying by technology, not purpose: teams label a model "low risk" because it is a small classifier, while its use in candidate filtering puts it squarely in Annex III point 4(a).
- Undocumented derogations: relying on Article 6(3) without a written assessment or registration, or applying it to a system that profiles people.
- Accidental provider status: fine-tuning or re-purposing a general-purpose model for a high-risk use without realising Article 25 now applies.
- Oversight on paper only: a named reviewer who approves thousands of outputs a day with no way to stop the system is not Article 14 oversight.
- Shared credentials: agents running under one service account make Article 12 traceability and incident investigation impossible.
Practitioner checklist
- Maintain an AI inventory with intended purpose, role (provider or deployer) and owner for every system and agent.
- Record a classification decision against Annex I and Annex III for each entry, with any Article 6(3) reasoning and registration.
- Check every Article 25 trigger before re-branding, fine-tuning or re-purposing a model.
- Give every AI agent its own identity and scoped, short-lived credentials so logs are attributable.
- Test the Article 14 stop path, including credential revocation, at least quarterly.
- Retain deployer logs for at least six months, reconciled with GDPR retention limits.
- Include poisoning, evasion and prompt injection tests in the technical documentation.
- Prepare worker and affected-person notices and, where required, the FRIA.
- Document serious incident criteria and the 2, 10 and 15 day reporting path.
Standards and references
- European Commission AI Act Service Desk: Article 6 Classification rules for high-risk AI systems
- European Commission AI Act Service Desk: Annex III High-risk AI systems
- European Commission AI Act Service Desk: Article 113 Entry into force and application
- European Commission AI Act Service Desk: Article 26 Obligations of deployers of high-risk AI systems
- European Commission AI Act Service Desk: Article 15 Accuracy, robustness and cybersecurity
- European Commission AI Act Service Desk: Article 99 Penalties
- European Commission: Draft guidelines on the classification of high-risk AI systems
- OWASP: Top 10 for LLM Applications 2025
Related NHI Mgmt Group resources: EU AI Act Compliance Guide · EU AI Act Prohibited Practices Guide · Agentic AI Compliance Guide · AI Governance Guide. This guide summarises the EU AI Act's high-risk AI system rules as amended by Regulation (EU) 2026/1744 and is not legal advice.