Direct Answer: Classification Depends on the Use Case, Not Merely the Technology
Under the EU Artificial Intelligence Act, businesses should classify an AI use case by first identifying the system’s function, purpose, and regulatory role—not simply by calling it generative AI, an AI agent, a chatbot, or a machine-learning model. The Act entered into force on 1 August 2024, but its obligations apply in stages: prohibitions and AI-literacy provisions began applying on 2 February 2025, governance rules and most obligations for general-purpose AI models applied from 2 August 2025, and the bulk of the remaining provisions apply from 2 August 2026. A separate Article 113 transitional rule postpones certain high-risk obligations embedded in regulated products to 2 August 2027. The correct classification therefore depends on both the use case and the date on which it is placed on the market or put into service.
Also worth reading: How Do Businesses Review AI Vendor Contracts Without Missing Costly Risks? · Which AI Services Contract Clauses Should Businesses Negotiate in 2026? · What Risk Clauses Should Businesses Include When Using AI in Contracts?
There are four main routes. A use may be prohibited, high-risk, subject to transparency obligations, or outside the Act’s material scope. A system can also fall into more than one regime at once: for example, a customer chatbot may have transparency duties while its internal risk-scoring component performs a high-risk use. Conversely, a sophisticated model does not automatically become high-risk merely because it uses artificial intelligence. As of the stated date of 2 October 2026, an organization should document its classification, monitor any 2026 regulatory developments, and treat unresolved product-safety questions conservatively rather than assuming that a proposed simplification has already become law.
How the High-Risk Tests Work
Article 6 supplies the central high-risk framework. An AI system is generally high-risk when it performs a covered use listed in Annex III and creates a material risk of harm to health, safety, or fundamental rights. Annex III covers areas including biometrics, critical infrastructure, education, employment, worker management, access to essential private and public services, law enforcement, migration and border control, administration of justice, and democratic processes. The listed activity is only the starting point. A business must still examine whether the system materially influences decisions about people or can materially affect access to services, opportunities, or legal rights.
A second route applies when an AI system is a safety component of a product, or the product itself is a safety component, covered by listed EU product-safety legislation and the system must undergo third-party conformity assessment. Examples can include certain medical devices, machinery, vehicles, lifts, and other regulated products. In this route, the relevant question is whether AI contributes to product safety under the applicable product legislation; Annex III is not the sole source of high-risk status. Providers must examine both the underlying product rules and the system’s role in that product before deciding which deadlines and controls apply.
The Commission and national authorities have also considered a narrower approach to Annex III in which a system performing a listed activity is presumed high-risk only if it makes a sufficiently significant contribution to a decision about a person. Draft guidance cited in the research context is non-binding and may evolve; it is not a replacement for the Act or official Commission guidelines. The 2026 Digital Omnibus discussions referenced in the research may also propose changes, but businesses should distinguish enacted amendments from proposals. For a defensible analysis, preserve the statutory test, identify the relevant use case, explain the degree of decision-making influence, and record any assumptions.
A Practical Classification Method for Business Teams
Begin with an inventory that describes what the system does rather than how its vendor labels it. Record the input, output, user, affected person, decision supported, degree of automation, and whether a human actually reviews the result. A tool that drafts a job advertisement is materially different from one that rank-applies candidates, and a chatbot that explains benefits differs from software that determines eligibility for a public benefit. The classification should be attached to the concrete deployment, because the same foundation model may receive different classifications when used for different purposes.
Next, map the deployment to Annex III, product-safety law, prohibited-practice rules, and Article 50 transparency duties. Assess whether the system materially influences a decision, merely supplies information, or operates upstream of a decision made by a qualified professional. Documentation should explain both the classification and the evidence supporting it, including product specifications, contracts, technical descriptions, user controls, and the role of human review. The Act uses role-based responsibilities, so the business must separately identify the provider, deployer, importer, distributor, product manufacturer, or other relevant actor.
Do not rely only on a questionnaire supplied by an AI vendor. Vendors may know their system’s capabilities but may not know exactly how a customer uses it. Conversely, the customer should not assume that a vendor’s general statement that a model is “not high-risk” resolves the customer’s deployment-specific duties. A classification file should identify the responsible business unit, review date, intended purpose, reasonably foreseeable misuse, and escalation process. Complex combinations—such as an agent accessing payroll data, ranking staff, and generating termination recommendations—should be split into components where necessary and then reassessed as an integrated workflow.
Comparison of the Main EU AI Act Risk Categories
| Feature | Prohibited practice | High-risk system | Transparency-controlled system | Outside material scope |
|---|---|---|---|---|
| Main trigger | Substantive use that the Act forbids, subject to its narrow exceptions | Covered Annex III use creating material risk, or qualifying safety role under product law | Interaction, synthetic content, emotion recognition, or other Article 50 trigger | Activity not covered by the Act or outside its defined scope |
| Typical examples | Certain manipulative or exploitative practices and social-scoring uses | AI used in listed decisions about employment, credit, education, essential services, or certain safety products | General-service chatbots and systems generating synthetic audio, image, video, or text in covered circumstances | Ordinary software with no relevant AI functionality or a use not covered by EU law |
| Core response | Do not deploy the prohibited use; investigate narrowly framed exceptions where facts may support one | Apply the relevant provider or deployer controls and technical documentation duties | Label, disclose, or provide information as the specific transparency rule requires | Record why the Act does not apply and continue monitoring factual changes |
| Timing | Rules generally apply from 2 February 2025 | Most relevant duties apply from 2 August 2026, with qualifying product-safety duties generally from 2 August 2027 | Most relevant duties apply from 2 August 2026 | No AI Act compliance deadline if the exclusion analysis is correct |
Common Classification Mistakes
One common error is classifying by model architecture. A large language model is not a regulatory category, and the same model can be used to summarize invoices, rank loan applicants, or generate political content. Another error is assuming human involvement removes high-risk status. If the person lacks authority, expertise, time, or meaningful information to change the result, nominal review may not substantially change the system’s practical role. The purpose and influence of the workflow matter more than the presence of a button labelled “human in the loop.”
Businesses also make the opposite mistake: assuming every tool used in a regulated department is high-risk. A spell-checking tool used by a recruiter is not automatically an employment-decision system, and a meeting summarizer is not automatically a worker-management system. However, the system may become high-risk when it systematically monitors employees, allocates performance points, or makes recommendations that materially shape a covered decision. Vendor descriptions should therefore be tested against actual user permissions, automation settings, and consequences.
Teams frequently overlook transparency duties or prohibited practices because they focus only on Annex III. A customer-facing chatbot may need disclosure that the person is interacting with AI, while certain generated or manipulated content may require marking. A prohibited-practice review is also distinct from a high-risk review and should be repeated when purpose, scale, or target population changes. Finally, treating draft Commission guidelines, vendor white papers, or the Taiwan risk framework as controlling EU law is mistaken. External frameworks can organize questions, but only EU legislation, official guidance, standards, and binding national or European decisions determine the legal result.
How AI Agents and General-Purpose Models Change the Analysis
AI agents require special care because one application can perform several functions, choose tools, access data, and take actions without a new statutory label. A recruiting agent that searches résumés, scores candidates, schedules interviews, and rejects applications cannot be evaluated as if it were only a résumé parser. Each function should be mapped, with attention to whether the agent can materially decide, execute, or trigger human action. Controls such as approval gates, restricted permissions, logging, and task limits may reduce operational risk, but they do not automatically alter the legal classification of the underlying purpose.
General-purpose AI models are assessed through a separate governance framework from downstream high-risk systems. Obligations for general-purpose AI models have applied since 2 August 2025, while a provider or deployer of a downstream system must still examine that system’s individual use. A business integrating a third-party model therefore has at least two questions: what documentation and contractual information does the model provider supply, and how is this specific deployment classified? Contract language saying that the model is “low risk” may allocate information duties, but it cannot contract out of statutory responsibilities.
The percentage claims sometimes seen in promotional scanner research should be treated cautiously. A finding that 97% of scanned agent code is non-compliant may describe a tool’s technical checks, not a legal conclusion about 97% of real-world systems. A useful automated scanner can identify missing logs, disclosures, or documentation, but it cannot reliably infer purpose, affected persons, Annex III coverage, or the effect of human review. Such results are a screening aid, not a substitute for legal analysis, and false positives are likely when the scanner has not been given deployment-specific facts.
Timing, Compliance Cost, and the 2026 Transition
As of 2 October 2026, most Article 50 transparency duties and the general high-risk regime relevant to stand-alone systems are already applying. Organizations should not treat August 2026 as a future planning date. However, high-risk systems placed on the market as safety components of regulated products may benefit from the later 2 August 2027 date under Article 113. This transition is not a blanket extension for every Annex III system, and amendments or proposals may alter the timetable. Companies should obtain a system-specific view from qualified counsel and verify the current consolidated legislation before relying on a deadline.
There is no official EU price for risk classification, and no software can guarantee legal compliance. A focused internal assessment for one simple, low-controversy deployment may cost several hundred euros in staff time, while a multi-agent platform used across employment, credit, healthcare, or customer service can require tens of thousands to hundreds of thousands of euros in legal, technical, assurance, security, and operational work. Open-source checkers and draft compliance tools may provide free initial screening, but their limitations, maintenance status, and evidentiary quality should be tested. The dominant cost is usually evidence collection and remediation, not the questionnaire itself.
A broker can help compare specialist advisers, software tools, auditors, and technical consultants, but it should not create a conflict by treating every deployment as a high-risk sales opportunity. Useful procurement criteria include relevant sector experience, fixed-scope options, transparent hourly rates, capability to distinguish binding law from draft guidance, cybersecurity and model-evaluation expertise, and independence from the AI vendor being assessed. Any engagement should define whether the deliverable is a preliminary classification memo, formal legal advice, technical testing, or implementation support.
When to Seek Advice and Act Immediately
Seek specialist review before deployment when the system materially influences a decision about employment, education, credit, insurance, healthcare, essential services, migration, justice, or democratic participation. Early review is also appropriate when a product contains AI governed by EU product-safety legislation, when one model serves several business units, or when an agent can take consequential actions using personal or confidential data. If the system is prohibited, the business should pause and examine the narrow statutory exception rather than waiting for a full compliance project. A short classification assessment may be sufficient for a simple internal writing assistant, but that conclusion should still be recorded.
The business should reassess classification after a material change in intended purpose, model version, data sources, autonomy level, user population, vendor, or downstream integration. A reasonable operating interval is at least annually for ordinary systems and before every significant release for higher-impact deployments, with event-driven reviews whenever facts change. Keep the final decision with the accountable owner, but ensure that legal compliance is not outsourced to the person operating the system. Good documentation shows what was known at the time, which law version was used, and why the selected category fits the facts.
The defensible 2026 position is therefore neither that all AI is high-risk nor that innovation can safely proceed without review. Classify each intended use, test both prohibited-practice and high-risk routes, add transparency duties where applicable, and verify the governing deadline. The law is technology-neutral but fact-sensitive: a clear inventory and a written, updateable analysis are more reliable than a vendor label, a generic scanner percentage, or an assumption that AI risk can be reduced to one universal score.