Why classification matters before the deadline
The future dates affect substantial provider and deployer requirements, including risk management, data governance, documentation, logging and human oversight. These capabilities depend on system design, supplier information and operating workflows. Classification is therefore an input to technical planning, rather than a label to add after implementation.
That does not make the requirements universally active today. Nor does it excuse currently applicable literacy, prohibitions or Article 50 duties. Review those branches separately.
The two principal routes
| Route | Classification question | What is insufficient alone |
|---|---|---|
| Article 6(1), Annex I | Is the AI system a specified product or safety component, and does the relevant product require third-party conformity assessment under the listed legislation? | Membership in a regulated sector or the presence of any AI feature. |
| Article 6(2), Annex III | Does the intended use match a listed use, subject to Article 6(3)'s conditions? | A broad industry label or an internal "low risk" designation. |
Start with the AI system and intended purpose. Keep underlying model identity separate. A GPAI model can support different systems whose uses lead to different system classifications. Classification of a GPAI model with systemic risk is a different legal test and does not replace the Article 6 analysis for an AI system.
Annex I and product integration
Annex I classification requires both conditions in Article 6(1). The system must have the specified product or safety-component connection, and the product must require the relevant third-party conformity assessment. Sole assistance, optimization, efficiency, convenience or quality control without a safety function does not establish a safety component. Third-party assessment required only for non-health/safety matters, such as spectrum use or electromagnetic interference, does not establish this route either.
This means a medical devices or infrastructure label is a starting point for questions, not an automatic answer. Identify the product legislation, safety function, assessment requirement and actual AI component. Keep evidence for each condition.
The July amendment deletes the machinery Directive entry at Annex I Section A point 1 and creates a separate amended machinery integration mechanism. Article 2(13)'s equivalent-protection path also depends on delegated acts and conditions. It is not an existing blanket exemption for Section A products.
Annex I Section B has restricted direct AI Act application under Article 2(2). Product systems and systems that may qualify under both routes therefore need analysis of the relevant sector rules. The repository has not independently verified every adjacent instrument or future delegated act needed for a complete product opinion.
Annex III and intended use
Annex III identifies specified uses in biometrics, infrastructure, education, employment, essential services, law enforcement, migration/borders, justice and democratic processes. The exact purpose and conditions matter. This is a screening overview, not the complete 25-row legal matrix.
| Example use | Why it deserves classification review | Qualification |
|---|---|---|
| Recruitment and candidate filtering | Annex III point 4(a) covers specified recruitment/selection activities. | Not every HR administrative tool has that purpose. |
| Worker promotion, termination or specified task allocation | Point 4(b) concerns specified employment and management decisions. | Examine the decision and allocation basis; not every scheduler is included. |
| Natural-person creditworthiness or scoring | Point 5(b) covers that assessment. | Fraud detection is excluded from this point; not all business lending is included. |
| Natural-person life/health insurance risk or pricing | Point 5(c) covers these uses. | Other insurance classes are not automatically included. |
| Emergency healthcare triage | Point 5(d) includes this use. | Not every healthcare workflow is emergency triage. |
| Safety components in specified infrastructure operation | Point 2 concerns the safety function. | General sector analytics alone does not establish it. |
A change in intended purpose can require reassessment. Under Article 25, an actor can become the provider when it changes the intended purpose so that a previously non-high-risk system becomes high-risk. Classification and legal responsibility should be reviewed together.
The Article 6(3) derogation
An Annex III system is not exempt merely because a provider considers it low impact. Article 6(3) requires no significant risk of harm to health, safety or fundamental rights, including no material influence on decision outcomes, and at least one of four task conditions. These concern narrow procedural work, improvement of a completed human activity, specified pattern/deviation detection, or preparatory work. Pattern/deviation detection has its own limits concerning prior human assessment and proper human review. Read the conditions together rather than treating the task list as four standalone exemptions.
An Annex III system that performs profiling of natural persons is always high-risk. A provider relying on the derogation needs to document the assessment and meet the retained Article 49(2) registration requirement. A spreadsheet entry saying "human reviewed" is not a substitute for those conditions.
Our operational recommendation is to preserve the intended purpose, workflow position, influence on the decision, profiling analysis and reasons for any derogation. Treat uncertainty as a review item rather than force a binary result. The final legal classification needs the facts and qualified review.
Core high-risk requirements
| Requirement | Legal anchor | Practical consequence |
|---|---|---|
| Risk management | Article 9 | Iterative lifecycle risk identification, mitigation and testing for intended use and foreseeable misuse. |
| Data governance | Article 10 | Relevant training, validation and testing governance, including representativeness and bias/gap examination; a testing rule for non-training systems. |
| Technical documentation | Article 11 and Annex IV | Documentation before market placement or putting into service, kept current. Article 18 has separate record retention. |
| Automatic logging | Article 12 | Design for automatic event recording; controlled-log duties sit separately in Articles 19 and 26(6). |
| Information for deployers | Article 13 | Clear, correct, complete and accessible instructions on purpose, limits, metrics, oversight, maintenance and logs. |
| Human oversight | Articles 14 and 26(2) | Provider design and deployer assignment must support effective oversight and intervention. |
| Accuracy | Article 15 | Appropriate lifecycle accuracy and metrics in instructions; no universal statutory accuracy percentage. |
| Robustness | Article 15 | Resilience to faults and inconsistencies, with appropriate fallback and feedback-loop measures. |
| Cybersecurity | Article 15 | Protection against unauthorized alteration and AI-specific attacks, with only conditional shortcuts. |
Providers also have quality-management, conformity, declaration/marking and authority-cooperation duties within the applicable route and timetable. Deployers have different obligations under Article 26, including following instructions, assigning oversight and undertaking applicable operating checks.
Registration and fundamental-rights impact assessment need a separate route check. These requirements concern Annex III, not the Annex I route alone.
| Duty | Actor and route | Qualification |
|---|---|---|
| Registration | Providers of relevant Annex III systems; specified deployers have separate registration duties | Apply the Article 49 conditions, including the retained registration for a provider relying on Article 6(3). |
| Fundamental-rights impact assessment before first use | Specified Annex III deployers, including public-law bodies, private entities providing public services and deployers of the specified credit and life/health-insurance systems | The infrastructure exception and Article 27 conditions matter; a data-protection impact assessment does not erase the FRIA elements. Update and notification duties also apply under their conditions. |
Dates and existing systems
| Principal date | Scope | Qualification |
|---|---|---|
| 2 December 2027 | Chapter III Sections 1 through 3 for the Annex III route | Article 6(5) excluded; existing-system and dual-route analysis remain necessary. |
| 2 August 2028 | Chapter III Sections 1 through 3 for the Annex I route, excluding Article 6(5) | Product conditions and restricted Section B application matter. |
| 2 August 2030 | Specified high-risk systems intended for use by public authorities | A specific provider/deployer backstop, not a general private-sector extension. |
Article 111(2) supplies an existing-system transition based on placement or first use before the relevant date and significant design changes afterward, preserving Article 5 and the public-authority backstop. Do not silently equate its design-change wording with "substantial modification" used elsewhere. Keep system history and each legal test separate.
The express Chapter III postponement does not settle all Chapter IX questions. Articles 72/73 have the general statutory date of 2 August 2026, but their high-risk coverage interacts with postponed classification and existing-system transitions. v0.2 leaves that interaction open. This page neither declares universal 2026 monitoring/reporting duties nor postpones them without legal basis.
Conformity assessment and standards
Not every high-risk system requires a notified-body assessment. Article 43(2) uses internal-control assessment for Annex III points 2 through 8. Biometric point 1 has conditional internal/notified-body routes, while Section A products use relevant sector procedures. Classification and conformity route are connected but distinct decisions.
A harmonised standard supports Article 40 presumption only where its reference is published in the OJ and only for covered requirements. Published-standard status alone is insufficient. The baseline supports EN 18286:2026 publication and a bounded finding that no AI Act OJ reference was located in the inspected sources. It does not guarantee absence of every citation.
Operationally, continue requirement-specific preparation while standards develop. Track standard version, covered requirements, citation and restrictions before relying on a presumption. An ISO certificate should not replace classification, technical evidence or applicable conformity procedures.
What organizations should do
Separate the system, model and intended use. Identify the relevant legal entity and role, test both classification routes, and record exceptions or derogation reasoning. Map the route-specific date and system history. Then examine design and operational gaps against the relevant requirements, including supplier dependencies.
Prioritize capabilities that need early technical decisions, such as logging, oversight interfaces, data lineage and documentation. Keep the legal requirement distinct from the implementation method and evidence used to examine it. This planning sequence is our interpretation.
Moving issues and FAQ
Are the classification guidelines final?
The inspected materials remained draft at the cutoff; official final adoption was expected by end 2026. Article 6(5)'s earlier statutory deadline remains distinct from that expectation. Draft examples should not be presented as final interpretation.
Is every financial services or healthcare AI system high-risk?
No industry label alone establishes classification. Examine Annex I product conditions and the exact Annex III purpose, including the credit, insurance and triage distinctions.
Does a human reviewer automatically remove high-risk status?
No. The Article 6(3) conditions need to be established, and Annex III profiling remains always high-risk.
Can a provider use one compliance date for every system?
The principal dates differ by route, and individual systems can have different transitions or sector restrictions. Record the actor, system, purpose, route and date behind each conclusion.
Next step
Review the timeline, confirm provider/deployer roles, and use the operational readiness sequence for preparation.
Primary sources
Use the consolidated text to navigate provisions and the authentic original and amending Official Journal acts for the legislation. Guidance and Q&A retain their separate legal status.
- Consolidated text: Regulation (EU) 2024/1689, 27 July 2026 · legislation.
- Regulation (EU) 2024/1689 of 13 June 2024 · legislation.
- Regulation (EU) 2026/1744 of 8 July 2026 · legislation.
- Targeted consultation on draft high-risk classification guidelines · official information, nonbinding.
- CEN/CLC JTC 21 AI Standards Catalogue : public data · standards body information.
- Publication de la EN 18286:2026 : une première norme européenne pour soutenir la mise en œuvre de l’AI Act · official information, nonbinding.
- Harmonised Standards : references published in the OJEU · official information, nonbinding.