Skip to content
Confir.
EU AI Act

AI System: Definition under the EU AI Act

Definition2 June 2026· 9 min read· 1,960 words

What counts as an AI system under Regulation (EU) 2024/1689? Article 3 definition, key features, boundary cases, and why it matters for compliance.

An AI system, under Regulation (EU) 2024/1689, is "a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments." Whether your software meets this definition is the first question the EU AI Act asks — before any risk classification begins.

The EU AI Act definition

The statutory definition appears in Article 3 of Regulation (EU) 2024/1689, point 1. The text establishes four core elements: machine-based operation, varying degrees of autonomy, the capacity for adaptiveness after deployment, and the use of inference to generate outputs from inputs. Those outputs — predictions, content, recommendations, or decisions — must have the capacity to influence physical or virtual environments for the definition to be satisfied.

The EU legislator aligned this definition with the OECD's AI definition, a deliberate choice to keep the Act consistent with international governance frameworks and to avoid creating a European-only technical standard that would quickly be overtaken by practice. The OECD definition shares the same inference-from-inputs logic and the same emphasis on real-world influence.

The alignment has practical weight. Regulators and the Commission's guidance can be read alongside OECD commentary, and companies operating across jurisdictions start from a shared reference point.

Because the definition is high-level, the European Commission published guidelines on the definition of an AI system on 6 February 2025 to help organisations draw the boundary in practice. Those guidelines work through concrete examples and clarify how the four elements interact — particularly the distinction between inference-capable systems and software that merely executes pre-specified logic. For any product team unsure whether their software qualifies, the guidelines are the primary interpretive resource.

The defining features

Autonomy does not mean full independence. The definition uses the phrase "varying levels of autonomy," which captures a spectrum from narrow systems operating within tight parameters to systems that make decisions with minimal human direction. A system that outputs a credit-risk score without a human specifying the exact calculation for each case qualifies; a calculator that a human programs to output a fixed formula does not.

Adaptiveness after deployment refers to the capacity of a system to change its behaviour in response to new data or operational experience once it is live. Machine learning models that update on user interactions are the clearest example. Not every AI system needs to be adaptive — the definition uses "may exhibit," not "must exhibit" — but the prospect of post-deployment change is one of the features that distinguishes AI from static software and justifies ongoing oversight obligations.

Inference is the definitional engine. The system must infer — derive conclusions, patterns, or decisions — from the inputs it receives rather than executing only operations that a natural person has explicitly defined in advance. This is where the boundary with traditional software is drawn. A rules engine that applies a human-written decision tree, with no capacity to derive outcomes beyond what those explicit rules specify, is not inferring. A neural network that learns to classify inputs it has never encountered by generalising from training data is inferring. The Commission's February 2025 guidelines discuss this boundary in detail, including intermediate cases such as statistical models and optimisation algorithms.

Outputs that influence environments close the loop. The system must be capable of producing something — a prediction, a recommendation, a decision, content — that affects something in the world. A system that processes data internally and produces no output that any actor or environment responds to falls outside the definition in practice. In most real cases this condition is easily satisfied: if a system's output is used by a person or feeds another process, it is influencing an environment.

What is and isn't an AI system

Classic machine-learning models — supervised classifiers, regression models trained on historical data, neural networks, large language models (LLMs) and applications built on them — clearly satisfy the Article 3 definition. They infer, they operate with some autonomy, and their outputs routinely influence decisions.

Applications built on top of LLMs — a customer service chatbot, a document-analysis tool, a recruitment-screening assistant — are AI systems in their own right. The system built by the deploying company or provider is assessed under the Act, even though the underlying GPAI model is separately governed by Chapter V (Articles 51–55). The system-level concept and the GPAI model concept sit at different layers; both may attract obligations simultaneously.

On the other side of the boundary, the Act and the Commission's guidelines make clear that basic rule-based software — systems that execute only operations defined explicitly by natural persons, with no capacity to infer beyond those rules — generally falls outside the Article 3 definition. A business-process automation tool that routes forms according to a fixed decision tree, with no learning component and no capacity to produce outputs beyond what the written rules specify, is not an AI system. A spreadsheet formula is not an AI system. An expert system with a fully human-specified knowledge base and deterministic rule execution sits in a grey zone that the February 2025 guidelines work through; in most cases, if the system cannot derive anything beyond what its explicit rules define, it falls outside scope.

The boundary matters practically because there are entire software categories — workflow tools, traditional business intelligence, rules-based decisioning engines — whose developers and users need clarity on whether the Act applies at all. The honest answer for borderline cases is: consult the February 2025 guidelines and document the assessment, because regulators will want to see that the question was asked.

GPAI models are worth distinguishing explicitly. A general-purpose AI model — a foundation model such as a large language model — is governed separately under Chapter V of the Act, not as an "AI system" in the system-level sense. The system that a provider builds and deploys using a GPAI model is the "AI system." The GPAI model is the underlying component. Both layers are regulated, but under different provisions.

Why the definition matters for compliance

The Article 3 definition is the gateway. Until you establish that your software is an AI system, none of the Act's obligations — classification, risk management, technical documentation, human oversight, conformity assessment — are triggered. This makes the threshold question the first item in any compliance assessment, not an afterthought.

Once you confirm that something is an AI system, the next question is whether it is prohibited under Article 5 (unacceptable risk), high-risk under Article 6 read with Annex III (or via Annex I for safety components of regulated products), limited-risk under Article 50, or minimal-risk. None of that classification work is relevant unless the software first qualifies as an AI system.

In practice, most enterprise software built in the last five years — especially anything involving machine learning, personalisation, recommendation engines, or predictive analytics — will satisfy the definition without much debate. The contested cases are at the margins: optimisation tools, traditional statistical models, complex rules engines. For those, the investment in a documented threshold analysis is worthwhile. If authorities later question your compliance posture, showing that you actively assessed the definition and reached a reasoned conclusion is significantly better than having no record of the question being asked.

Confir's classification workflow begins with this threshold step. Its rule-based engine asks intake questions structured around the Article 3 elements — autonomy, inference, environmental influence — and derives a documented determination before proceeding to risk classification under Article 6 and Annex III. The same deterministic logic that makes Confir's outputs audit-defensible makes the threshold step reproducible: the same inputs always produce the same finding.

Frequently Asked Questions

Is every software tool an AI system under the EU AI Act?

No. The Act applies only to systems that infer — deriving outputs from inputs in ways that go beyond executing explicitly defined operations. Traditional software, fixed rule engines, and spreadsheet formulas are generally outside the definition. The European Commission's guidelines of 6 February 2025 provide detailed worked examples for drawing the line. When in doubt, document the assessment: regulators will look for evidence that the question was considered.

Does a system need to use machine learning to qualify as an AI system?

Not necessarily, but in practice most systems that satisfy the Article 3 definition do involve some form of machine learning or statistical inference. The definition focuses on the capacity to infer, not on the technical architecture. An optimisation algorithm or a Bayesian system that can derive outputs beyond what its explicit rules define may qualify even without a neural network. The Commission's February 2025 guidelines work through these intermediate cases.

If my product is built on an LLM (a GPAI model), is it an AI system?

Yes. The application you build and deploy using a GPAI model is an AI system in its own right and is assessed under Articles 5, 6, and Annex III according to its use. The underlying GPAI model is separately regulated under Chapter V (Articles 51–55). Both layers can attract obligations simultaneously — the model provider's duties under Article 53 (and Article 55 for systemic-risk models) do not substitute for your obligations as the system provider under Article 16.

Does the definition cover AI systems used internally within a company, not sold to customers?

Yes. The EU AI Act covers AI systems put into service — used operationally — as well as those placed on the market. Internal use in a professional context falls within scope. A company that deploys a third-party AI system for internal HR screening or credit analysis is a deployer under Article 26 and owes the corresponding obligations. Whether you built the system yourself (provider, Article 16) or use someone else's (deployer, Article 26) determines which obligations apply, not whether the use is internal or external.

Does the Article 3 definition cover AI systems used outside the EU?

Territorial scope is governed by Article 2, not Article 3. The AI Act follows an effects-based approach: it applies to providers placing AI systems on the EU market and to deployers operating within the EU, even where the provider is established outside the EU. If the outputs of an AI system affect persons in the EU, the Act is likely to apply. Article 2 details the exceptions and carve-outs, including an exclusion for AI developed exclusively for national security purposes by member states.

When did the AI system definition take effect?

Regulation (EU) 2024/1689 entered into force on 1 August 2024. Article 3 (definitions) has applied since then. The prohibited practices in Article 5 have applied since 2 February 2025. High-risk obligations under Article 6 and Annex III apply from 2 December 2027 for stand-alone Annex III systems (deferred under the Digital Omnibus agreed in May 2026), and from 2 August 2028 for high-risk AI embedded in Annex I regulated products.

Related terms

Manage your EU AI Act compliance in one place

Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.

Start free trial →