EU AI Act high-risk systems: how to classify them and what changes in 2027

Under the EU AI Act the intended purpose of a system, not the model inside it, decides whether it is high-risk. This article gives the current timetable, a three-step classification procedure (category, exceptions, evidence) and the engineering work that follows. It relates the procedure to scholarship noting that the Act defines risk categories without a concrete assessment method, and to work on conformity assessment and auditing.

Keywords EU AI Act · high-risk AI · Annex III · classification · conformity assessment · compliance evidence

The EU AI Act does not make every enterprise AI system high-risk. The classification depends on the system's intended purpose, the context in which it is used, and whether it falls into the high-risk categories defined by the Regulation.

For engineering teams, this distinction matters because high-risk status changes the entire delivery model: risk management, data governance, technical documentation, logging, human oversight, accuracy, robustness, cybersecurity, conformity assessment and post-market monitoring become part of the system lifecycle.

The Regulation ties obligations to risk class and, for high-risk systems, requires a risk-management system, data governance, technical documentation, automatic logging, transparency, human oversight, and accuracy, robustness and cybersecurity (Articles 9–15)^[1]. Classification is the hard part: the Act defines four categories but lacks a clear methodology for assessing risk in concrete situations, and a scenario-based, proportional method has been proposed to fill that gap^[2].

The enforcement side was analysed early. Conformity assessment and post-market monitoring were described as the two primary mechanisms in the proposal and read as the basis of a Europe-wide AI auditing ecosystem^[3]. A critical strand argues that the Act treats trustworthiness as acceptability of risk, and that actual trust and the trustworthiness of deployed systems may stay misaligned^[4]. For teams, the practical tools are internal: an end-to-end framework for internal algorithmic auditing^[5] and documentation built into the architecture.

The implementation schedule changed during 2026. As of September 2026, the European Commission's current guidance states that the high-risk rules for Annex III use cases — including biometrics, critical infrastructure, education, employment, migration, asylum and border control — apply from 2 December 2027. High-risk systems embedded in regulated products have a later application date of 2 August 2028.

This is different from Article 50 transparency obligations, which already apply from 2 August 2026.

For organisations maintaining older compliance roadmaps, this distinction is important: the AI Act is already enforceable in several areas, but the full high-risk regime has a later application date for these categories.

High-risk systems can arise through two main routes.

1. AI used as a safety component of a regulated product

Examples include AI integrated into machinery, medical devices or other products already covered by EU product-safety legislation. These systems follow the product-related high-risk route and the extended 2028 timeline.

2. AI used in sensitive Annex III contexts

Annex III covers specific use cases where AI can materially affect health, safety or fundamental rights. Common enterprise examples include:

• recruitment, candidate screening and employee evaluation;
• education admissions, assessment or exam monitoring;
• access to essential private or public services;
• biometric identification or categorisation;
• migration, asylum and border-control decisions;
• certain justice and democratic-process applications.

A system should not be classified only by the model it uses. The same foundation model can support a low-risk internal summarisation tool and a high-risk recruitment workflow. Intended purpose and actual use are decisive.

Article 6 includes cases where an Annex III system may not be high-risk when it performs a narrow procedural or preparatory task and does not materially influence the decision outcome. Examples can include document indexing, translation, search, classification or anomaly detection for human review.

This exception should be documented rather than assumed. If the system profiles natural persons, the exception is substantially narrower and the risk analysis must be treated with particular care.

For high-risk systems, compliance is not just a policy document. The system must produce evidence.

A production architecture should support:

• risk management: a repeatable lifecycle process for identifying and mitigating foreseeable risks;
• data governance: provenance, quality controls and bias analysis for relevant datasets;
• technical documentation: a maintained technical file describing intended purpose, architecture, limitations and testing;
• automatic logging: traceable system events sufficient for post-hoc investigation;
• human oversight: meaningful intervention, escalation and override paths;
• accuracy, robustness and cybersecurity: measurable performance targets, resilience tests and security controls;
• post-market monitoring: mechanisms to detect incidents, degradation and material changes after deployment.

The practical lesson is simple: if these controls are added after the system is already in production, compliance work becomes expensive and fragmented. Designing them into the platform is usually cheaper and easier to audit.

Even where the high-risk application date is still ahead, organisations should already maintain an AI inventory and classify systems by intended purpose. New systems should be designed so that logging, evaluation, human oversight and documentation are native platform capabilities rather than separate compliance projects.

A useful minimum package is:

1. system inventory and owner;
2. intended-purpose statement;
3. preliminary risk classification;
4. architecture and data-flow diagram;
5. evaluation and red-team evidence;
6. logging and trace-retention policy;
7. human-oversight design;
8. change-management and reclassification triggers.

LMXAI treats this evidence layer as part of production engineering: architecture, observability and compliance should describe the same system, not three disconnected versions of it.

• European Commission — AI Act enforcement framework
• European Commission — high-risk systems guidance
• Regulation (EU) 2024/1689

• Practical EU AI Act guide
• Article 50 transparency obligations
• GPAI provider vs downstream integrator
• EU AI Act FAQ for enterprise teams
• What an EU AI Act compliance deliverable contains
• EU AI Act risk classification service