High-Risk AI Classification Under the EU AI Act

High-risk AI classification under the EU AI Act depends on what a system is used for, not on the technology behind it. A system is high-risk if it is a safety component of a regulated product, or if its intended use falls within one of the areas listed in Annex III. The classification is a legal status. It decides which obligations a provider and a deployer carry. This guide explains how the two routes work, where customer-facing AI agents sit, and what to verify with a vendor.

TL;DR

• Article 6 sets two routes to high-risk status: AI in products covered by Annex I legislation, and AI used in the eight areas of Annex III.
• Classification follows intended purpose and context of use. The same model can be high-risk in one deployment and not in another.
• An Annex III system can escape the high-risk label only if it poses no significant risk of harm and meets an Article 6(3) condition. Profiling of natural persons removes that option.
• Providers of high-risk systems need conformity assessment, documentation, risk management and human oversight before market entry. Deployers need written clarity on who is responsible for what.
• US companies selling into the EU are in scope when their systems are placed on the EU market or their outputs are used there. Independent testing of real behavior supplies evidence that documentation alone cannot.

Table of Contents

• What “high-risk” means in the AI Act
• The two routes in Article 6
• The Article 6(3) exception and the profiling rule
• Is a customer service AI agent high-risk?
• Obligations once a system is high-risk
• Vendor risk for AI: provider or deployer?
• Why documentation is not enough
• Our perspective
• How Lexic supports classification and oversight
• A practical sequence for US companies entering the EU
• FAQ
• Sources

What “high-risk” means in the AI Act

The AI Act sorts systems by the risk they pose. According to the European Commission, high-risk systems are those that can adversely affect safety or fundamental rights. They are permitted, but only if they meet mandatory requirements. Prohibited practices sit above them and are banned. Below them, most minimal-risk systems carry no additional legal obligations, although some transparency duties apply regardless of risk class.

Three points follow from this structure:

• High-risk is not a ban. It is a regulated status with defined duties.
• High-risk is not the same as transparency-only. A chatbot that must disclose it is an AI may still be outside the high-risk category.
• The status attaches to a system in a use. It does not attach to a model family or a vendor.

Readers who search for “AI risk classification” often expect a score or a questionnaire. The Act has no scoring method. It has a legal test, and that test is set out in Article 6.

The two routes in Article 6

Article 6 of the AI Act creates two distinct pathways, as set out in the consolidated text on the Commission’s AI Act Service Desk.

Route one: safety components of regulated products

Article 6(1) applies two cumulative conditions. First, the AI system is a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I. Second, that product must undergo third-party conformity assessment before it is placed on the market or put into service. Both conditions must be met.

This route covers sectors such as machinery, medical devices and toys, where product safety law already requires external assessment. For these systems, the Commission’s implementation guidance gives August 2, 2027 as the date from which Article 6(1) and its corresponding obligations apply.

Route two: the use cases in Annex III

Article 6(2) points to Annex III. A system whose intended use falls in one of its areas is treated as high-risk. Annex III lists eight areas, including biometrics where law permits their use, and further areas covering employment, education, access to essential services, and the administration of justice.

For most software companies, this second route is the relevant one. It is defined by function. A resume-screening tool, a credit-scoring model and an exam-proctoring system are classified by what they do, not by how they were built.

The Article 6(3) exception and the profiling rule

An Annex III system is not automatically high-risk in every case. Under Article 6(3), a system in an Annex III area may avoid the classification when it poses no significant risk of harm to health, safety or fundamental rights. As of the consolidated text of 27 July 2026, it must also meet one of these conditions:

1. The system performs a narrow procedural task.
2. The system improves the result of a previously completed human activity.
3. The system detects decision-making patterns or deviations from them and does not replace or influence the human assessment without proper human review.
4. The system performs a preparatory task for an assessment relevant to an Annex III use case.

The same Article 6 text closes the door on one case. An Annex III system always counts as high-risk when it performs profiling of natural persons.

In practice this narrows the exception considerably. Any system that evaluates, ranks or scores an individual in an Annex III context should be treated as high-risk unless a qualified legal review concludes otherwise. Teams that rely on the exception should document the reasoning and keep it available for regulators. A conclusion reached informally, without a record, is hard to defend later.

Is a customer service AI agent high-risk?

There is no blanket answer. The Commission states that classification depends on a system’s intended purpose, function, specific purpose and modalities of use. A customer service agent that answers shipping questions is usually not in an Annex III area. The obligation then is transparency: people should know they are talking to an AI system.

The analysis changes when the agent’s role changes. Questions to ask for each deployment:

• Does the agent decide or influence access to something listed in Annex III? An agent that screens applicants, or that determines eligibility for a service in an essential-services category, moves toward high-risk.
• Does it profile individuals? Scoring customers on behavior, creditworthiness or likelihood to leave can bring the profiling rule into play where an Annex III area is involved.
• Does it handle biometric data? Voice-based identification or emotion inference falls into regulated territory and needs a specific legal check.
• Has its purpose drifted? A general assistant configured to triage claims or applications may have become something different from what the vendor documented.

The last point matters most for deployers. Purpose is set by the intended use declared by the provider, but real behavior is set by configuration, prompts, integrations and the conversations customers start. A classification written on paper can diverge from what the agent does in production.

Obligations once a system is high-risk

The Commission’s guidance states that before placing a high-risk system on the market or putting it into service, providers must complete conformity assessment and meet requirements covering:

• risk management
• data quality
• technical documentation
• transparency
• human oversight
• accuracy
• cybersecurity
• robustness

The assessment must be repeated after a substantial modification. Providers must also register high-risk systems in a public EU database.

Conformity assessment

Conformity assessment is the procedure by which a provider shows that the system meets the requirements. It happens before market entry and again after substantial change. For a system that was assessed once and then retrained, reconfigured or given a new purpose, the question is whether the change is substantial. That question needs a documented answer.

Records and retention

The Commission’s implementation guidance says providers must retain technical documentation, quality management system records and notified body decisions for 10 years after the system is placed on the market. Logs must be kept for at least six months, or for a period appropriate to the intended purpose.

Ongoing duties

The Act sets no fixed support period. Its lifecycle obligations, including risk management under Article 9 and performance under Article 15, require providers to keep updating and monitoring throughout operation, according to the same guidance. Conformity is therefore not a one-time certificate. It is a condition that has to hold while the system runs.

Timeline

The rollout is staggered. Per the Commission’s implementation guidance, prohibited-practice provisions applied from February 2, 2025, and certain provisions applied from August 2, 2025. Article 6(1) obligations apply from August 2, 2027. Certain high-risk systems intended for public authorities must comply by August 2, 2030. Dates in this area have been the subject of policy discussion, so confirm the current schedule on the Commission’s official pages before fixing a compliance plan.

Vendor risk for AI: provider or deployer?

Most enterprises buy AI agents rather than build them. That does not remove their exposure. Article 25 sets out when a company that buys or integrates a system becomes a provider. According to the text of Article 25, an organization takes on provider duties if it:

• puts its own name or brand on a high-risk system,
• makes a substantial modification to a high-risk system so that it remains high-risk, or
• changes the purpose of a non-high-risk system so that it becomes high-risk.

The same article requires providers and third parties that supply components or services for high-risk systems to set out, in a written agreement, the necessary information, capabilities, technical access and assistance. An exception applies to certain publicly accessible tools and components under free and open-source licences.

A vendor review checklist

Use these questions when you assess an AI vendor:

1. Intended purpose. What does the vendor’s documentation declare, and does it match your use?
2. Classification reasoning. Has the vendor assessed Annex III and Article 6(3)? Is the reasoning written down?
3. Documentation access. Will the contract give you the technical documentation, instructions for use and logs you need as a deployer?
4. Change control. How are you told about model updates, and who decides whether a change is substantial?
5. Human oversight. Can the agent hand a conversation to a person, and can you prove that it does?
6. Security testing. What evidence exists that the agent resists prompt injection and data leakage in live conditions?
7. Allocation of duties. Does the contract state who is provider and who is deployer, and what happens if that changes?

Vendor assurances answer the first four questions. Questions five to seven need observed behavior. They are where most gaps appear.

Why documentation is not enough

A high-risk file can be complete and still describe a system that behaves differently in the field. Regulators, customers and courts will look at what the agent said and did. That is the reason independent testing of the live agent matters for classification and for vendor accountability.

Our audits have revealed that 85% of the agents assessed fail to escalate issues to a human representative appropriately. Human oversight is a named requirement for high-risk systems. An agent that does not hand over when it should leaves a gap between the documented control and the real one. For deployers, that gap is a compliance exposure and a customer experience failure at the same time.

Our perspective

Classification is where most organizations start, and where many stop. We see three recurring problems.

First, classification is treated as a one-time legal opinion. Agents change through prompt edits, new tools and model upgrades. Each change can alter what the agent does, and so can alter its risk position. Classification needs an owner and a review cycle.

Second, the vendor’s declaration is treated as proof. A declaration states intent. It does not show what the agent does when a customer is frustrated, vulnerable or trying to push it out of scope. The only way to know is to interact with the agent as a real user would, across customer experience, security, technical reliability and regulatory compliance.

Third, evidence is not preserved in a form that others can trust. When a regulator, a board or a vendor disputes a finding, the record has to stand up. That is why Lexic Compass uses third-party cryptographic hashing to verify the integrity of evidence and support traceability.

Our view is that organizations govern AI agents better when assessment is independent of the vendor and based on observed conversations. Classification tells you which rules apply. Testing tells you whether the agent meets them.

— Sergio Llorens

How Lexic supports classification and oversight

Lexic Compass is an AI agent audit platform that assesses conversational agents from any vendor by interacting with them as real users would. It covers customer experience, security, technical reliability and regulatory compliance, including escalation handling and customer disclosure. The output is evidence that teams can use to govern agents in production and to hold vendors accountable.

Engagements run in several formats: Flash Preview, Audit Sprint and Enterprise Continuous Trust. Details are on the Compass audit page. For organizations that also want to understand what customers say across calls, chats, emails and tickets, Lexic Pulse analyzes those conversations for sentiment, churn and opportunity signals.

A practical sequence for US companies entering the EU

US-based companies often meet the AI Act when they plan EU market entry. A workable order of work looks like this:

1. Inventory every AI agent and system. Record its purpose, the data it touches, who supplies it and where it is deployed.
2. Map each use to Annex I and Annex III. Write down the result and the reasoning, including any Article 6(3) argument and the profiling check.
3. Assign roles. Decide whether you are provider or deployer for each system, and test that against the Article 25 triggers.
4. Fix the contracts. Make sure agreements cover information, technical access, logs and assistance.
5. Test live behavior. Verify disclosure, escalation, security and compliance in real conversations, and keep the evidence.
6. Monitor and re-review. Repeat classification and testing after substantial changes, and confirm current deadlines on the Commission’s official pages.

A qualified EU legal adviser should confirm classification for any system near an Annex III area. This article is general information and does not replace that advice.

FAQ

What is a high-risk AI system under the EU AI Act?

It is a system that either serves as a safety component of a product covered by Annex I legislation, or is intended for use in an area listed in Annex III. High-risk systems are allowed on the EU market but must meet mandatory requirements first. The status depends on intended purpose and use, not on the underlying technology.

Can an Annex III system avoid the high-risk label?

Yes, in limited cases. It must pose no significant risk of harm and meet one of the Article 6(3) conditions, such as a narrow procedural task or a preparatory task. The exception never applies when the system profiles natural persons.

What is a conformity assessment for AI?

It is the procedure through which a provider shows that a high-risk system meets the Act’s requirements before it is placed on the market or put into service. It must be repeated after a substantial modification. The requirements include risk management, documentation, human oversight, accuracy and cybersecurity.

Is a customer service chatbot high-risk?

Usually not by default, but it depends on its role. If it influences decisions in an Annex III area, or profiles individuals in that context, it may be high-risk. Even when it is not, transparency duties can still apply, so customers should know they are interacting with an AI system.

How should we assess vendor risk for AI agents?

Start with intended purpose, the vendor’s classification reasoning and the written agreement on information and technical access. Then verify behavior directly, especially human escalation, disclosure and security. Check whether any change you make could make you the provider under Article 25.

Sources

• Navigating the AI Act, European Commission
• Article 6: Classification rules for high-risk AI systems, AI Act Service Desk
• Annex III, AI Act Service Desk
• Implementation Guidance for the EU AI Act, European Commission
• Article 25: Responsibilities along the AI value chain