FAQEU

EU AI Act AI System Classification Edge Cases

This FAQ helps classify borderline software, model, product, supplier, and deployment situations under the EU AI Act before assigning obligations.

Covers inference versus simple rules, general-purpose AI models versus AI systems, embedded systems, EU territorial scope, operator roles, and evidence for high-risk assessments.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Questions
4

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

EU AI Act classification starts with the thing being assessed: software or model, standalone service or embedded component, EU market or EU use, provider or deployer role, and . Borderline cases should be resolved with the Act's definitions and Article 6 classification rules, then documented with enough technical and commercial evidence to repeat the conclusion.

Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

When is borderline software an AI system under the EU AI Act?

A borderline tool is more likely to be an when it is machine-based, operates with some autonomy, and infers from inputs how to generate outputs such as predictions, content, recommendations, or decisions that can influence a physical or virtual environment.

A tool is less likely to be an when it only executes rules defined solely by people, such as fixed validation checks, deterministic routing tables, hard-coded eligibility rules, or ordinary calculations with no learning, reasoning, modelling, or inference beyond basic data processing.

The Commission's AI-system-definition guidelines are interpretive guidance, not an alternative legal definition. Classify the actual system against Article 3(1) and Recital 12, and preserve the technical facts showing whether the system infers how to generate outputs rather than relying on labels such as AI-powered or automated.

  • Record the inputs, objective, output type, autonomy level, and whether the system derives a model, algorithm, recommendation, prediction, content, or decision from data or encoded knowledge.
  • Separate deterministic automation from inference: a manually written rule that always produces the same result from the same fields is not enough by itself.
  • Treat logic- and knowledge-based systems as possible AI systems when they infer from encoded knowledge or symbolic representations, even without machine learning.
  • Keep the intended-purpose evidence from instructions, sales material, product specifications, and technical documentation because Article 6 high-risk classification depends on purpose and use context.

Does the EU AI Act cover simple rules-based software as an ?

Usually no, if the software is based only on rules defined by people to automatically execute operations. Recital 12 says the definition should not cover simpler traditional software or programming approaches based solely on human-defined rules. Escalate the case when the rules engine also learns, reasons, models, ranks, recommends, predicts, or otherwise infers from inputs or encoded knowledge.

Does inference under the EU AI Act require machine learning?

No. The Act's recital explains that inference can be enabled by machine learning and also by logic- and knowledge-based approaches that infer from encoded knowledge or symbolic representations. The classification question is therefore not only 'does it use ML?' but 'does the machine-based system infer how to generate outputs for an explicit or implicit objective?'

Citations
Question 2

How should GPAI model, AI system, and embedded product edge cases be classified?

Do not collapse a and an into the same record. The model is the reusable capability; the AI system is the deployed or supplied system that uses a model to serve an . A downstream provider can integrate a GPAI model into an AI system and then have system-level obligations for that integration.

Embedded and product-linked cases need two checks. First, decide whether the AI component itself is an . Second, decide whether Article 6 makes it high-risk because it is a safety component, is itself a covered product, or falls into an Annex III use case.

  • For GPAI, identify the model, the provider placing the model on the Union market, and any downstream provider integrating it into a specific .
  • For embedded software, document whether the is physically integrated into the product or serves product functionality without being physically integrated.
  • For product safety cases, check whether the is a safety component of a product or is itself a product covered by Annex I legislation and subject to third-party conformity assessment.
  • For Annex III cases, check whether the intended use falls into a listed sensitive area, then assess whether Article 6(3) permits a not-high-risk conclusion; profiling of natural persons remains high-risk.

Is a automatically an under the EU AI Act?

No. Article 3 separately defines a and a general-purpose . A GPAI model displays significant generality and can be integrated into downstream systems or applications. A general-purpose AI system is an AI system based on a GPAI model and capable of serving a variety of purposes. The classification record should therefore identify the model, the system built from it, and the actor responsible for each.

When can an embedded AI component become high-risk under the EU AI Act?

An embedded AI component can be high-risk when Article 6(1) applies: the is intended as a safety component of a product, or is itself a product, covered by Annex I Union harmonisation legislation and that product or system must undergo third-party conformity assessment. Separately, an embedded or non-embedded AI system can be high-risk if its intended use is listed in Annex III.

Citations
Regulation (EU) 2024/1689 (EU AI Act)

Supports the separate definitions for AI systems, general-purpose AI models, general-purpose AI systems, safety components, and Article 6 high-risk classification.

Question 3

Which scope and role questions change the EU AI Act answer?

Territorial scope is not limited to EU-established providers. The Act can apply to providers placing AI systems or GPAI models on the Union market, EU deployers, non-EU providers or deployers whose AI-system output is used in the Union, importers, distributors, product manufacturers, authorised representatives, and affected persons located in the Union.

Role classification is fact-specific and can change after launch. A distributor, importer, deployer, or other third party can become the provider of a if it puts its name or trademark on the system, substantially modifies it, or changes the so that the system becomes high-risk.

Scope exclusions also matter. The Regulation contains specific exclusions for personal non-professional use, certain scientific research and development activity, pre-market research, testing or development that respects applicable Union law, and some free and open-source releases. Those exclusions have conditions and do not create a general exemption for commercial deployment, prohibited practices, high-risk systems, or Article 50 uses.

  • Map the market path: who develops, brands, imports, distributes, deploys, integrates, or productizes the system or GPAI model.
  • Record the EU connection: Union market placement, Union putting into service, EU establishment or location of the deployer, Union use of outputs, or affected persons located in the Union.
  • Check whether a supplier answer covers only the model, only the , only the deployment, or the product into which the system is integrated.
  • Reclassify after material changes to , branding, integration, safety function, user population, EU market availability, or human-impacting use case.

Can a non-EU AI provider fall within the EU AI Act?

Yes. Article 2 covers providers placing AI systems or GPAI models on the Union market regardless of whether the provider is in the Union or a third country. It also covers providers and deployers in a third country where the output produced by the is used in the Union.

Can a deployer or distributor become the provider of a under the EU AI Act?

Yes. Article 25 treats a distributor, importer, deployer, or other third party as the provider of a when it puts its own name or trademark on the system, makes a , or changes the of a non-high-risk system so that it becomes high-risk.

Does a free and open-source licence exclude an from the EU AI Act?

Not always. Article 2(12) excludes AI systems released under free and open-source licences unless they are placed on the market or put into service as high-risk systems or as systems covered by Article 5 prohibited practices or Article 50 transparency duties. The licence label therefore does not remove those categories or decide whether a commercial actor has placed the system on the market.

Does the EU AI Act apply to a person's private use of an ?

The Regulation does not apply to deployer obligations where a natural person uses an in a purely personal, non-professional activity. That exclusion is limited to the person's deployer obligations; it does not remove obligations that apply to the provider or another operator placing the system on the Union market.

Citations
Question 4

What classification evidence should teams keep for EU AI Act edge cases?

A defensible classification file should show the same facts a reviewer would need to reach the answer again: the object classified, why it is or is not an , whether it is a GPAI model or a system, the , the EU nexus, the operator role, and the high-risk screening result.

For high-risk and near-high-risk cases, align the evidence with Annex IV-style system description fields even if the team is still at classification stage: interactions with other hardware or software, form of supply, product integration, development methods, third-party components, output quality, monitoring, limits, and lifecycle changes.

  • definition evidence: autonomy, inputs, objectives, output type, inference method, model or algorithm derivation, and why simple human-defined rules are or are not enough to describe the tool.
  • GPAI evidence: model identity, model provider, downstream system provider, integration method, tasks the model can perform, and system-specific .
  • High-risk evidence: Article 6(1) product-safety check, Annex III use-case check, any Article 6(3) not-high-risk rationale, and profiling status.
  • Role and scope evidence: provider, deployer, importer, distributor, product manufacturer, authorised representative, EU market or output-use facts, branding, substantial modifications, and intended-purpose changes.
  • Change evidence: version history, technical modifications, deployment context changes, supplier changes, instructions for use, and the date and approver of each reclassification.
Citations
Regulation (EU) 2024/1689 (EU AI Act)

Supports the evidence fields from Article 3 definitions, Article 6 classification documentation, Article 25 role changes, and Annex IV technical-documentation content.

Recommended next step

Turn borderline AI system facts into a reviewed classification file

Sorena can help convert model, product, supplier, and deployment facts into a source-cited EU AI Act classification record with role, scope, high-risk, and evidence checks.

Primary sources

References and citations

digital-strategy.ec.europa.eu
Referenced sections
  • Commission FAQ source explaining that the framework applies to public and private actors inside and outside the EU in relevant market or use scenarios.
"inside and outside the EU"
eur-lex.europa.eu
Referenced sections
  • Supports the evidence fields from Article 3 definitions, Article 6 classification documentation, Article 25 role changes, and Annex IV technical-documentation content.
"technical documentation"
Related guides

Explore more topics

Are industry AI use cases high-risk under EU AI Act Annex III?
FAQ answer on when an industry AI use case falls under EU AI Act Annex III, how Article 6 classification works, when Article 6(3) can support a non-high-risk conclusion, and what evidence providers should keep.
EU AI Act Applicability and Roles: Scope, Actor Map, and Evidence
Determine whether the EU AI Act applies to an AI system or GPAI model, map provider, deployer, importer, distributor, and product manufacturer roles, and record evidence for classification.
EU AI Act applicability test: scope, role, and risk classification
Stepwise EU AI Act applicability test for AI-system status, exclusions, territorial scope, operator role, prohibited uses, high-risk systems, GPAI models, transparency duties, and evidence records.
EU AI Act Article 5 Prohibited AI Practices Screening Guide
Screen AI systems against EU AI Act Article 5, including manipulation, social scoring, biometrics, law enforcement, and the new prohibited-content category.
EU AI Act Article 50 transparency disclosures FAQ
Article 50 FAQ for EU AI Act transparency duties covering chatbot notices, synthetic content marking, biometric and emotion notices, deepfakes, public-interest text, timing, accessibility, and exceptions.
EU AI Act Article 50 transparency, labeling, and user disclosures
Source-backed guide to EU AI Act Article 50 duties for user interaction notices, synthetic content marking, deepfake labels, emotion recognition notices, biometric categorisation notices, and related high-risk AI instructions for use.
EU AI Act Article 73 serious incident FAQ
FAQ on EU AI Act serious incident handling for high-risk AI systems, including Article 73 reporting, deployer escalation, corrective action, and GPAI systemic-risk distinctions.
EU AI Act Compliance Checklist by Risk Class
A practical EU AI Act checklist for classifying AI systems, assigning operator roles, screening prohibited practices, and collecting evidence for high-risk, GPAI, transparency, monitoring, and incident duties.
EU AI Act Compliance Program: roles, high-risk evidence, GPAI and incidents
Build an EU AI Act compliance program around provider, deployer, importer, distributor, high-risk, GPAI, transparency, monitoring, and incident evidence duties.
EU AI Act conformity assessment and notified bodies for high-risk AI
Source-backed guide to EU AI Act high-risk AI conformity assessment routes, provider evidence, EU declaration of conformity, CE marking, and notified body involvement.
EU AI Act deadlines and compliance calendar | Article 113 dates
EU AI Act compliance calendar for Regulation (EU) 2026/1744, Article 113 dates, Article 111 transitions, GPAI enforcement, Article 50, and high-risk systems.
EU AI Act FAQ: scope, roles, high-risk AI, GPAI, FRIA, and dates
Source-backed EU AI Act FAQ covering scope, roles, risk classification, GPAI, transparency, AI literacy, rights and complaints, sandboxes, authorities, SME provisions, and current legal status.
EU AI Act FRIA FAQ: Article 27 Scope, Contents, and Notification
Source-backed FAQ on when Article 27 requires a fundamental rights impact assessment, which deployers are covered, what the FRIA must contain, and how it relates to DPIAs and registration.
EU AI Act FRIA for high-risk AI systems: Article 27 scope and evidence
Source-backed guide to EU AI Act Article 27 fundamental rights impact assessments: who must run a FRIA, Article 6(2) triggers, Annex III carveouts, DPIA overlap, notification, and registration evidence.
EU AI Act GPAI and Systemic-Risk Duties: Article 53 and 55 FAQ
FAQ on EU AI Act duties for general-purpose AI model providers, including Article 53 documentation, copyright and training-summary duties, Article 55 systemic-risk duties, serious incidents, cybersecurity, and staged enforcement.
EU AI Act GPAI evidence pack checklist for Article 53 and 55
Build a source-backed evidence pack for EU AI Act GPAI model obligations: technical documentation, downstream information, copyright policy, training-content summary, and systemic-risk records where applicable.
EU AI Act GPAI Provider Obligations: Articles 53 and 55
Source-backed guide to EU AI Act duties for general-purpose AI model providers: Article 53 documentation, copyright policy, training-content summary, downstream information, and Article 55 systemic-risk controls.
EU AI Act High-Risk AI Requirements: Articles 8-16 and 26
Map the EU AI Act requirements for high-risk AI systems: risk management, data governance, technical documentation, logs, transparency, human oversight, accuracy, robustness, cybersecurity, and deployer duties.
EU AI Act high-risk AI use cases by industry | Article 6 and Annex III guide
Industry-by-industry guide to EU AI Act high-risk classification under Article 6, Annex III, Annex I product safety routes, exclusions, and provider/deployer boundaries.
EU AI Act high-risk conformity assessment route selector
Select the EU AI Act Article 43 conformity assessment route for a high-risk AI system, including Annex I product legislation, Annex III categories, notified body triggers, standards, declaration, CE marking, registration, and evidence.
EU AI Act high-risk requirements checklist: Articles 8-15
Checklist for EU AI Act high-risk AI system requirements in Articles 8-15: risk management, data governance, documentation, logs, transparency, human oversight, accuracy, robustness, and cybersecurity.
EU AI Act penalties and fines: Article 99 tiers and GPAI exposure
EU AI Act penalties explained: Article 99 fine tiers, prohibited-practice exposure, incorrect information, SME caps, Member State rules, and GPAI model fines.
EU AI Act post-market monitoring and serious incident reporting
Source-backed guide to EU AI Act Articles 72 and 73 for high-risk AI: monitoring plans, serious incident reporting, deployer escalation, corrective action, and GPAI distinctions.
EU AI Act post-market monitoring FAQ for high-risk AI systems
Answer to how providers and deployers should handle EU AI Act post-market monitoring for high-risk AI systems under Article 72, with serious-incident, log, corrective-action, and lifecycle-change triggers.
EU AI Act provider vs deployer role boundaries: Article 3 and Article 25 FAQ
FAQ on EU AI Act provider, deployer, operator, importer, distributor, authorised representative, product manufacturer, downstream provider, and GPAI model provider boundaries.
EU AI Act risk classification intake workflow
A source-based intake structure for classifying EU AI Act scope, prohibited practices, high-risk routes, Annex III use cases, GPAI model status, roles, and reassessment triggers.
EU AI Act serious incident reporting triage workflow: Article 73 and Article 55
Triage EU AI Act serious incidents by definition, actor, reporting route, deadline, deployer escalation, corrective action, and separate GPAI systemic-risk reporting.
EU AI Act Technical Documentation and Provider Evidence Templates
Build AI Act evidence templates for high-risk AI providers: Article 11 technical documentation, Annex IV fields, quality management, conformity, CE marking, registration, logs, and post-market monitoring.
EU AI Act technical documentation FAQ | Article 11 and Annex IV
What Article 11 and Annex IV require in high-risk AI technical documentation: system identity, intended purpose, architecture, data, testing, oversight, cybersecurity, conformity, and post-market monitoring.
EU AI Act Timeline Roadmap: Dates, Legal Status, Owners, and Evidence
Turn EU AI Act milestones into an implementation roadmap by separating enacted dates, political agreements, draft guidance, consultations, and voluntary codes, then assigning actions and evidence.
EU AI Act vs ISO/IEC 42001: legal duties, controls, and evidence limits
Compare the EU AI Act and ISO/IEC 42001:2023, including legal status, Article 17 quality management, high-risk duties, GPAI, evidence reuse, and assurance limits.
EU AI Act vs NIST AI RMF: legal duties, risk controls, and evidence boundaries
Compare the EU AI Act with NIST AI RMF 1.0 across legal status, GOVERN-MAP-MEASURE-MANAGE, high-risk duties, GPAI, evidence reuse, and revision limits.
FAQ: EU AI Act conformity assessment procedures and notified body selection
cited FAQ on EU AI Act Article 43 conformity assessment routes, Annex VI internal control, Annex VII notified-body review, CE marking, declarations, and registration.