Intended purpose decides the tier — not the model. Classification, evidence and the current 2027/2028 timetable.
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 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.
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.
Annex III covers specific use cases where AI can materially affect health, safety or fundamental rights. Common enterprise examples include:
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:
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:
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.
Next step. If you want this to ship, LMXAI scopes the integration as a system — not a workshop series.
