The EU AI Act: Classification Is Only the Beginning

A risk label does not tell an organization everything it must do. Compliance depends on what the technology is, how it is used, which role the organization performs and what evidence it can maintain throughout the system’s lifecycle.

The EU AI Act is often introduced through four broad categories: prohibited practices, high-risk systems, transparency-regulated uses and minimal or no-risk systems. That shorthand is useful for orientation, but it is not a complete method for determining compliance.

The Act contains separate legal tests for AI systems, general-purpose AI models and the organizations that develop, supply, import, distribute or use them. Some duties depend on high-risk classification. Others apply because of an organization’s role, the system’s capabilities, the type of interaction involved or the content it produces.

The practical question is not: What is this model’s risk score?
It is: What have we developed, supplied or deployed, how is it being used, who can be affected and what role do we perform under the Act?

Those questions must be answered for each AI system and relevant model dependency, not once for an enterprise or vendor portfolio.

Executive Summary

• The EU AI Act entered into force on August 1, 2024 and became generally applicable on August 2, 2026, although important provisions follow different dates.
• Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on July 27, 2026 and moved the main high-risk requirements to December 2, 2027 for Annex III use cases and August 2, 2028 for Annex I regulated-product systems.
• Classification is not a single risk score. Scope, intended purpose, operator role, prohibited practices, high-risk rules, Article 50 transparency duties and general-purpose AI model obligations must be assessed separately.
• The same underlying model can support an internal productivity task, a transparency-regulated chatbot and a high-risk employment or credit decision system. The deployment context changes the legal analysis.
• High-risk status activates an extensive control regime, but provider and deployer obligations differ. A fundamental-rights impact assessment is mandatory only for the deployers and use cases identified in Article 27.
• Classification and role decisions must be maintained over time. A changed intended purpose, substantial modification or new deployment context can alter the analysis and, in specified cases, change the organization’s legal role.
• The defensible operating model connects each legal conclusion to facts, rationale, controls, owners, approvals, evidence and reassessment triggers in one living governance record.

The compliance clock changed in 2026

Many summaries still reproduce the original 2024 implementation timeline. That timeline is no longer current.

Regulation (EU) 2026/1744, known as the Digital Omnibus on AI, amended the AI Act and extended the main high-risk dates. The extension provides more implementation time, but it does not eliminate the need to identify affected systems, resolve role questions and build the required governance processes.

Legal basis: consolidated AI Act, Article 113

For certain high-risk systems already placed on the market or put into service before the relevant Chapter III date, the transitional rule generally applies the high-risk regime only if the system later undergoes significant design changes. High-risk systems intended for use by public authorities have a separate compliance deadline of August 2, 2030. Providers of general-purpose AI models placed on the market before August 2, 2025 must comply by August 2, 2027.

The executive takeaway is straightforward: the high-risk deadlines moved, but the governance problem did not. An organization still needs to know what it operates, which dates apply and what evidence must exist before the relevant deadline.

The Act is not one classification ladder

The familiar four-level risk graphic can imply that every AI asset receives one mutually exclusive label. The legal analysis is more layered. An organization should answer these questions in sequence:

1.Define the asset

Is it an AI system, a general-purpose AI model, a general-purpose AI system, or part of a larger value chain?

2.Test territorial and material scope

Does the Act apply to the organization, system, model and activity, and is an exclusion relevant?

3.Determine the role

Is the organization acting as provider, deployer, importer, distributor, product manufacturer or authorised representative?

4.Screen prohibited practices

Does the intended or actual use fall within Article 5?

5.Assess high-risk status

Does Article 6(1) and Annex I or Article 6(2) and Annex III apply, and is the narrow Article 6(3) exception available?

6.Assess transparency duties

Does Article 50 regulate direct interaction, synthetic content, emotion recognition, biometric categorisation, deepfakes or specified public-interest text?

7.Assess model-provider duties

Does Chapter V apply to a provider of a general-purpose AI model, including a model with systemic risk?

8.Map other law

What privacy, employment, consumer, cybersecurity, intellectual-property, product-safety and sector-specific requirements also apply?

These questions can overlap. A chatbot may not be high-risk and may still require disclosure that a person is interacting with AI. A provider of a general-purpose AI model may have Chapter V duties even though the model is not itself classified as a high-risk AI system. A high-risk deployment may also trigger Article 50 and other EU or national law.

Minimal or no risk is therefore not a formal certificate of exemption from governance. It is shorthand for systems to which the Act does not attach high-risk requirements merely because of that use. Other AI Act provisions and other laws can still apply.

Scope comes before risk

The AI Act can apply outside the European Union. It covers providers placing AI systems or general-purpose AI models on the EU market regardless of where the provider is established. It also covers EU-based deployers and, in specified circumstances, providers and deployers outside the EU where an AI system’s output is used in the EU.

For a North American organization, the absence of an EU office does not end the analysis. Relevant questions include:

• Is an AI system or general-purpose AI model being placed on the EU market or put into service there?
• Is output produced by a system operated outside the EU used in the EU?
• Is the organization supplying, importing, distributing, integrating or using the system?
• Are affected people, such as employees, applicants, customers or citizens, located in the EU?
• Does an exclusion or limitation apply, including for specified military, defence, national-security, research or personal non-professional activity?

Scope should be recorded for each system, with the supporting facts and any exclusion. The same company can have one system within scope and another outside it.

Legal basis: consolidated AI Act, Article 2

Role determines responsibility

The Act allocates obligations across the AI value chain. One organization can perform different roles for different systems, and a role can change when the organization modifies or repurposes a high-risk system.

Under Article 25, a distributor, importer, deployer or other third party can become the provider of a high-risk AI system if it places its own name or trademark on the system, substantially modifies it while it remains high-risk, or changes the intended purpose of a non-high-risk system so that it becomes high-risk.

Buying a third-party product does not automatically make every buyer a provider. Configuration, rebranding, integration and changed use still require analysis. Contracts can allocate information, access and practical responsibilities, but they do not replace the statutory role test.

Legal basis: consolidated AI Act, Articles 3 and 25

How high-risk classification works

Article 6 creates two principal routes to high-risk status.

Route 1: AI connected to regulated products

An AI system can be high-risk under Article 6(1) when it is a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I and the product must undergo a third-party conformity assessment before it is placed on the market or put into service.

The 2026 amendment sharpened this route. A component used only for non-safety functions such as convenience, service efficiency, performance optimization or non-safety quality control is not a safety component merely because it sits inside a regulated product. The intended safety function and consequences of failure matter. A third-party assessment required solely for risks unrelated to health and safety, such as specified spectrum or electromagnetic-interference risks, does not by itself satisfy Article 6(1)(b).

Route 2: Listed sensitive use cases

Article 6(2) and Annex III identify high-risk use cases across biometrics, critical infrastructure, education and vocational training, employment and worker management, essential services and benefits, law enforcement, migration and border control, and the administration of justice and democratic processes.

The area heading is not enough. The system must match a listed use case. A general productivity tool used by an HR team is not automatically high-risk because HR uses it. A system intended to filter job applications or evaluate candidates is specifically listed and requires a different conclusion.

The Article 6(3) exception is narrow and documented

An Annex III system may be treated as not high-risk where it does not pose a significant risk of harm to health, safety or fundamental rights, including because it does not materially influence a decision outcome, and one of the specified conditions applies. Those conditions concern a narrow procedural task, improvement of a previously completed human activity, detection of patterns or deviations without replacing or improperly influencing the prior human assessment, or a preparatory task.

The exception is not a casual risk acceptance. The provider must document the assessment before placing the system on the market or putting it into service and register the system under Article 49(2). An Annex III system that profiles natural persons remains high-risk.

Status note: As of August 24, 2026, the Commission’s high-risk classification guidance is still labelled draft and is not legally binding. The conclusions in this article rely on the consolidated Regulation.

Current guidance status: European Commission high-risk systems guidance page

High-risk status starts a control program

Once the relevant high-risk provisions apply, classification becomes the entry point to an extensive control regime. Provider duties include, as applicable:

• a documented risk-management system maintained as a continuous, iterative lifecycle process
• data and data-governance requirements for training, validation and testing data sets where applicable
• technical documentation kept current and automatic logging designed for traceability
• clear information and instructions for deployers
• effective human-oversight measures
• accuracy, robustness and cybersecurity
• a documented quality-management system
• the applicable conformity assessment, EU declaration of conformity, CE marking and registration
• post-market monitoring, corrective action and serious-incident reporting

Deployer duties are different. They include using the system in accordance with instructions, assigning human oversight to people with the necessary competence, training and authority, controlling input data where the deployer has control, monitoring operation, keeping logs under the deployer’s control, suspending use and escalating specified risks, informing affected persons in specified Annex III decision contexts, supporting an applicable data-protection impact assessment and completing a fundamental-rights impact assessment where Article 27 applies.

The distinction matters. Provider conformity does not remove the deployer’s responsibility for the system’s actual use, oversight and context-specific impacts. Deployer monitoring does not replace the provider’s post-market duties.

Penalty exposure: Article 99 sets maximum administrative fines of up to EUR 35 million or 7 percent of worldwide annual turnover for prohibited-practice violations, and up to EUR 15 million or 3 percent for specified operator and Article 50 violations, using the higher maximum for undertakings. For SMEs, the lower applicable maximum is used. The actual decision and amount depend on the circumstances and applicable enforcement process.

Legal basis: consolidated AI Act, Article 99

Transparency and general-purpose AI require separate analysis

High-risk classification is not the only source of obligations.

Article 50 applies from August 2, 2026. It addresses direct interaction with AI, machine-readable marking of synthetic audio, image, video or text, notice for emotion-recognition and biometric-categorisation systems, disclosure of deepfakes and disclosure of specified AI-generated or manipulated public-interest text. The article contains exceptions and context-specific conditions, so organizations should evaluate each use rather than apply a generic AI-generated label to every output.

Final implementation guidance: European Commission Article 50 transparency guidelines

Chapter V applies to providers of general-purpose AI models. Article 53 includes obligations concerning technical documentation, information for downstream AI-system providers, a policy for compliance with EU copyright law and a public summary of training content. Providers of general-purpose AI models with systemic risk have additional Article 55 duties for model evaluation and adversarial testing, systemic-risk assessment and mitigation, serious-incident tracking and reporting, and cybersecurity.

The voluntary General-Purpose AI Code of Practice offers one route for demonstrating compliance with covered obligations. Providers that do not use an approved code or applicable harmonised standard must demonstrate alternative adequate means of compliance.

Implementation guidance: European Commission guidelines for GPAI model providers

This is another reason not to force all AI assets into one risk matrix. A general-purpose model, the AI system integrating it and the organization deploying the system may each require a separate but linked governance record.

Classification must be dynamic

The AI Act itself reflects lifecycle governance. Article 9 defines high-risk risk management as a continuous, iterative process requiring regular review and updating. Article 11 requires technical documentation to remain current. Article 27 requires covered deployers to update a fundamental-rights impact assessment when relevant elements change or become outdated. Article 72 requires providers to collect, document and analyse post-market performance data so they can evaluate continuous compliance.

In practice, organizations should define reassessment triggers for changes to:

• intended purpose or business use
• affected population, geography or decision impact
• model, version, data or measured performance
• vendor, integration or downstream dependency
• level of autonomy or human oversight
• incident history or newly identified risk
• applicable law, final guidance or standard

Not every change automatically changes legal classification. The point is to identify changes that could affect the underlying facts, role, intended purpose, risk or control obligations, then route them for reasoned review.

A practical governance model for the EU AI Act

Intake

Create a structured record for the AI system, underlying models, vendors, intended purpose, users, affected persons, data, integrations and jurisdictions. Identify missing information before classification begins.

Assess

Determine scope, operator role, prohibited-practice status, high-risk status, transparency duties, general-purpose AI considerations and other applicable requirements. Preserve the facts, rationale, reviewer and date behind each conclusion.

Approve

Map applicable requirements to controls, accountable owners, approval conditions and evidence. Resolve gaps before release or expansion of use.

Monitor

Track system, model, data, vendor, control and incident changes. Trigger reassessment when a change could affect intended purpose, role, classification, risk or compliance.

Report

Generate management views, assessment records, audit evidence and regulator-ready information from the same governance record rather than reconstructing the history after a request arrives.

Governance information should move with the AI system. Inventory, classification, controls, decisions, evidence and monitoring history should remain connected throughout its lifecycle.

What executives should ask now

1.Is the inventory complete?

Does it include internal, third-party and agentic AI, plus the models, vendors and integrations on which each system depends?

2.Can every conclusion be defended?

Can the organization show why a system is in or out of scope, what role it performs and how prohibited-practice, high-risk, transparency and GPAI conclusions were reached?

3.Are requirements operationalized?

Are applicable requirements connected to controls, accountable owners, approvals, evidence and deadlines?

4.Is change governed?

Which changes or incidents trigger reassessment, who receives the alert and who can suspend use?

5.Is evidence retrievable?

Can the organization produce a coherent record for management, auditors, customers or regulators without starting a manual evidence exercise?

If these questions cannot be answered from a consistent source of truth, the largest gap may not be policy. It may be the absence of an operating system for AI governance.

The FairFuture AI Perspective

FairFuture AI is building an enterprise AI governance and compliance platform designed to centralize AI governance, simplify compliance and maintain continuous oversight.

The platform is being designed around five connected capabilities:

Intelligent Intake

Turn project documents or a plain-language description into a structured AI system record, creating a centralized inventory of internal, third-party and agentic AI.

Risk Classification

Classify each AI system based on its purpose, context, impact, affected stakeholders, jurisdiction and applicable requirements, with a clear rationale for every result.

Compliance Automation

Translate regulatory requirements and internal policies into reusable controls, owners, approvals, evidence requests and automated workflows.

Continuous Monitoring

Track changes in systems, models, data, vendors, controls and incidents, with alerts when review or action is required.

Evidence & Reporting

Capture evidence as governance work happens and generate dashboards, audit reports and regulator-ready packages through standard views or natural-language requests.

Now onboarding early-access partners across financial services, government and healthcare.

Talk to Us

Talk to us about your organization’s EU AI Act readiness, AI inventory, classification process or continuous-governance priorities.

Official Sources