Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The EU AI Act does not classify every AI system used in a sensitive industry as high-risk. It uses two legal routes: certain AI systems connected to regulated products under Article 6(1) and Annex I, and specified uses listed in Article 6(2) and Annex III. If a system qualifies, the Act sets out lifecycle duties—including risk management, documentation, human oversight and monitoring—with responsibilities depending on the operator’s role. Following a 2026 amendment, the specified Chapter III requirements apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.
What “high-risk” means under the EU AI Act
“High-risk” is a legal classification, not a general description of an AI system that seems important, powerful or potentially harmful. The Act identifies systems through two routes, each with its own conditions. One concerns AI used in or as certain regulated products; the other concerns particular uses listed in the Act. A system’s intended purpose and the applicable statutory description matter: simply operating in a listed industry does not automatically make every AI tool in that industry high-risk.
The starting point is Regulation (EU) 2024/1689, the Artificial Intelligence Act, read together with its amendment, Regulation (EU) 2026/1744. The original Act sets out the classification framework and obligations; the 2026 amendment changes the timing for specified high-risk requirements. The consolidated legal text and applicable sector rules should be checked for any real classification or compliance decision.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →How to determine whether an AI system is high-risk
Route 1: AI connected to a regulated product
Under Article 6(1), an AI system is high-risk if it is intended to be used as a safety component of a product, or is itself a product, covered by Union harmonisation legislation listed in Annex I, and that product must undergo third-party conformity assessment under the relevant legislation. In other words, the product route depends on both the product’s coverage by the listed legislation and the requirement for third-party assessment. A connection to a regulated product alone is not enough to establish that this route applies.
#1 Best Overall
This route links AI Act obligations to an existing product-regulation framework. For an assessment, identify the product, the relevant Annex I legislation, the AI system’s intended role in or as the product, and whether that legislation requires third-party conformity assessment. The analysis concerns the actual product and intended use, not merely the fact that its maker uses AI somewhere in its business.
Route 2: an AI use listed in Annex III
Article 6(2) and Annex III cover specified use areas. These include:
- Biometrics.
- Critical infrastructure.
- Education and vocational training.
- Employment, workers management and access to self-employment.
- Access to and enjoyment of essential private services and essential public services and benefits.
- Law enforcement.
- Migration, asylum and border control.
- Administration of justice and democratic processes.
These are broad subject areas, not a rule that every AI system used by an organisation in one of them is automatically high-risk. Check the specific Annex III description and the conditions in Article 6 against the system’s intended purpose and function. For example, an AI tool used by an education provider should not be classified from the organisation’s sector alone; the relevant question is whether its intended use matches an Annex III entry.
When an Annex III system may be outside the classification
The Act provides an exception for an Annex III system that does not pose a significant risk of harm to health, safety or fundamental rights, including where it does not materially influence the outcome of decision-making. A provider relying on this exception must document its assessment before placing the system on the market or putting it into service. That record is part of the classification work, not a substitute for applying the legal conditions.
There is an important qualification: systems that perform profiling of natural persons are treated as high-risk under the applicable Annex III provision. Do not assume that the exception is available without checking the statutory text and the system’s actual function. Classification may turn on details that are easy to miss if the assessment relies only on a product label or a high-level description of the business use.
A practical classification sequence
- Describe the intended purpose. Record what the system is designed to do, who will use it and in what context. Compare that purpose with the product and use-case descriptions in Annex I and Annex III.
- Check the product route. If the system is used as a safety component of, or is itself, a product covered by Annex I legislation, establish whether the product must undergo third-party conformity assessment under that legislation.
- Check the use-case route. If the system is intended for a use area in Annex III, compare its specific purpose and function with the corresponding statutory entry and Article 6 conditions.
- Assess any relevant exception. For an Annex III system, determine whether the statutory exception applies, including whether the system poses significant risk or materially influences a decision. Account for the profiling provision.
- Keep the classification record. Where the provider relies on the Annex III exception, document that assessment before market placement or putting the system into service. Retain the analysis supporting the route selected and revisit it if the intended purpose changes.
- Identify the operator’s role and the dates. Establish whether the organisation is acting as provider, deployer, importer, distributor or product manufacturer, and determine which requirements and application dates are relevant to that role and route.
What the high-risk framework requires
Chapter III establishes connected requirements intended to address risks over a system’s lifecycle. The following is an orientation, not a complete compliance checklist: the exact duties depend on the provisions that apply, the system’s route and the organisation’s role. The Act also operates alongside relevant product-sector rules, so an AI Act review should not be treated as a replacement for product-specific conformity work.
Risk management
Providers must establish a continuous risk-management system to identify and address risks associated with the high-risk AI system over its lifecycle. This makes risk assessment an ongoing process rather than a one-time exercise completed only before launch. The system’s intended purpose and risks are central to the wider framework: they inform how other requirements, such as data practices and oversight, are addressed.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteData governance
The Act requires data and data-governance practices appropriate to the system’s purpose and risks. The practical question is not just whether a dataset exists, but whether the organisation’s data practices are suitable for the system being developed or used and for the risks it presents. The applicable statutory provisions should be consulted for the detailed requirements; a general data policy alone does not establish compliance.
Rank #3
Technical documentation and records
Technical documentation and record-keeping must support assessment and traceability. These requirements help make it possible to understand and evaluate a system rather than treating it as an unexplained component. Records also matter when the provider documents an Annex III exception. What documentation is required, and by whom, depends on the applicable provisions and role.
Information for deployers and human oversight
Providers must give deployers clear information and instructions, including information about system capabilities and limitations. The framework also requires human-oversight measures suited to the system and its use. These are related but distinct: information helps a deployer understand what the system can and cannot do, while oversight concerns the measures for human supervision in context. The Act’s requirements should be checked for the particular system rather than reduced to a generic instruction to “keep a human in the loop.”
Accuracy, robustness and cybersecurity
High-risk systems must have appropriate accuracy, robustness and cybersecurity. These are system qualities to address in light of the system’s intended purpose and risks. The framework does not turn those terms into a single universal performance target in the overview here; organisations should consult the applicable legal provisions and any relevant sector requirements instead of assuming one metric works for every system.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quality management and post-market monitoring
Provider quality-management arrangements and post-market monitoring are part of the framework. Together, they extend compliance beyond preparation for market entry: providers need arrangements for managing quality and monitoring systems after they are placed on the market or put into service. The specific procedures and records required must be determined from the provisions that apply to the system.
Conformity assessment and registration
Conformity assessment and registration obligations apply as relevant. The product route expressly depends on third-party conformity assessment under the applicable product legislation; that product-law condition should not be confused with the full set of AI Act obligations. For either route, identify the applicable assessment and registration requirements from the legal text rather than assuming that one process or registration rule covers every high-risk system.
Which organisation is responsible?
The Act’s duties are role-specific. A provider’s responsibilities are not interchangeable with those of a deployer, importer, distributor or product manufacturer. An organisation may need to establish which role or roles it holds in relation to a particular system and examine the requirements attached to each. The fact that an organisation buys or uses an AI system does not by itself answer which obligations apply to it.
| Role or relationship | Why it matters |
|---|---|
| Provider | The framework assigns provider duties that include quality management and post-market monitoring, alongside system-level requirements. Providers relying on the Annex III exception must document the assessment before market placement or putting the system into service. |
| Deployer | Deployers receive information and instructions from providers, and the framework includes human-oversight measures suited to the system and use. Check the applicable provisions to establish the deployer’s own duties. |
| Importer or distributor | These are distinct operator roles. Their applicable obligations need to be checked in the Act rather than inferred from the provider’s responsibilities. |
| Product manufacturer | A manufacturer dealing with an AI system connected to a regulated product needs to assess the product route and the relevant product-sector conformity framework. The precise obligations depend on the applicable legislation and role. |
This is a role map, not a full allocation of legal duties. Contracts and internal labels do not replace the statutory analysis of who is acting in each capacity. Where one organisation performs several functions, consider each function against the corresponding legal provisions.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →When the high-risk requirements apply
The original Act’s broad application schedule has been amended. As of 13 October 2026, the specified obligations in Chapter III, Sections 1, 2 and 3 apply on different dates depending on the high-risk route:
| High-risk route | Specified Chapter III Sections 1–3 obligations apply from | Basis |
|---|---|---|
| Article 6(2), Annex III use cases | 2 December 2027 | Regulation (EU) 2026/1744 |
| Article 6(1), Annex I product-related systems | 2 August 2028 | Regulation (EU) 2026/1744 |
These are not dates for every obligation in the AI Act. EUR-Lex’s official summary identifies 2 August 2026 as the Act’s general application date and notes that exceptions and staged dates exist. The summary and amendment should therefore be read together: the later dates above concern the specified Chapter III Sections 1–3 obligations for the respective high-risk categories, not a blanket postponement of the regulation. See the EUR-Lex summary of the AI Act and the amendment’s legal text for the schedule and its scope.
The amending regulation gives the legislature’s stated rationale in its recitals: “The timely availability of support instruments, including guidance, relevant standards, common specifications and codes of practice is important in order to facilitate compliance and reduce the risk of divergent interpretation and uneven application of the rules across Member States.” This is an institutional statement in the regulation’s recital, not a quotation attributed to an individual.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to turn the rules into a compliance plan
A useful first pass is to make classification, role and timing explicit before building detailed controls. That reduces the risk of preparing for the wrong requirements or treating a future application date as though all current obligations were suspended.
- Inventory the systems. For each system, describe its intended purpose, context of use, connection to any regulated product and the decisions or functions it supports.
- Map each system to the legal route. Check Article 6(1) and Annex I for the product route, and Article 6(2) and Annex III for listed use cases. Record why a route applies or does not apply.
- Document any exception analysis. If a provider concludes that an Annex III system qualifies for the exception, retain the assessment of significant risk and material influence on decision-making, and account for the profiling provision.
- Assign organisational roles. Identify the provider, deployer, importer, distributor and product manufacturer where relevant. Do not assign all work to one team simply because one company is involved.
- Build a requirement-to-evidence map. For the applicable duties, identify the responsible role, the process or technical measure used, and the documentation or records that support it. Include risk management, data governance, deployer information, oversight, performance, monitoring and conformity assessment where relevant.
- Plan against the right date. Distinguish the Annex III and Annex I dates for the specified Chapter III Sections 1–3 requirements from the general application date and any other staged provisions.
- Review changes. Reassess classification and controls when an intended purpose or use changes, or when new legal materials affect the applicable analysis. Verify the consolidated regulation and relevant Commission materials before relying on a date or interpretation operationally.
Common classification and timing mistakes
- Assuming a sector label decides the issue. An AI tool used by a hospital, school or public authority is not automatically high-risk merely because of the organisation’s sector. Match the system’s intended use to the statutory entry and conditions.
- Ignoring the product-law condition. Under the product route, verify both the Annex I coverage and the requirement for third-party conformity assessment under the relevant product legislation.
- Applying an Annex III exception without a record. A provider relying on the exception must document the assessment before market placement or putting the system into service. Profiling of natural persons also requires attention to the applicable Annex III provision.
- Confusing provider and deployer duties. Responsibilities are role-specific. A deployer’s receipt of instructions does not make the provider’s system-level responsibilities disappear, and a provider’s duties should not simply be assigned to every other operator.
- Treating 2027 or 2028 as a universal start date. The amendment sets distinct dates for specified high-risk obligations. It does not, on the information stated here, move every AI Act requirement to those dates.
Keeping the assessment current
The dates and supporting materials are update-sensitive. Regulation (EU) 2026/1744 changed the application schedule for specified high-risk obligations, while the legislature’s stated rationale points to the importance of available guidance, standards, common specifications and codes of practice. Before making a market-entry or compliance decision, consult the current consolidated text, the relevant provisions of the original Act and amendment, and applicable product-sector legislation. This explainer is an overview of the framework, not a legal opinion on a particular system.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
