EU AI Act Definition of an AI System: What Software Is Covered

What Is the EU AI Act Definition of an AI System

Everything in Regulation (EU) 2024/1689 hangs on one threshold question: is this software an AI system at all? Article 3(1) supplies the answer. An AI system 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. The wording deliberately tracks the definition developed by the OECD, so that the EU rulebook stays interoperable with international frameworks. If software meets this definition, the Act's classification machinery applies; if it does not, the Act is simply not engaged, whatever else the software does.

The Seven Elements Broken Down

Why Inference Is the Decisive Test

The European Commission's guidelines on the definition, published in February 2025, put the weight on the capability to infer. Inference means the system derives outputs from inputs using models or algorithms whose behaviour was not exhaustively hand-written, typically because it was learned from data. A machine-learning model that predicts customer churn infers: no human wrote a rule for each customer. By contrast, software whose every response follows rules fully and explicitly specified by humans, with no learning and no derivation beyond executing those rules, lacks the inference capability the definition requires. The guidelines describe such simpler traditional software, including basic data processing and systems based solely on rules written entirely by people, as falling outside the definition. The boundary is functional, not cosmetic: renaming a rules engine as AI in marketing does not bring it into scope, and calling a learned model a simple script does not take it out.

What Clearly Falls Inside the Definition

Machine-learning systems of every family are the core case: supervised, unsupervised, self-supervised, reinforcement, and deep learning. That includes recommendation engines, demand forecasting models, fraud and anomaly detection, credit and risk scoring models, speech and image recognition, large language models and the chatbots built on them, image and video generators, autonomous navigation stacks, and predictive maintenance systems. Logic-based and knowledge-based approaches that perform reasoning over knowledge representations can also qualify, because the definition is not limited to statistical learning. Adaptiveness after deployment is explicitly optional: a model frozen at training time, never updated in production, remains an AI system as long as it infers.

What Generally Falls Outside

Conventional software keeps its ordinary legal life outside the Act. Spreadsheets and their formulas, fixed business-rule engines that apply human-written thresholds, classical statistical reporting that summarises rather than predicts, database queries, search by exact matching, deterministic schedulers, and standard automation scripts all execute instructions rather than inferring how to respond. Two cautions temper the comfort. First, embedded AI: a conventional application that ships with a learned model inside, a CRM with predictive lead scoring, a helpdesk with an answer-suggestion model, contains an AI system even though the wrapper is ordinary software. Second, simple optimisation and estimation methods sit near the line, and the Commission guidelines walk through such cases rather than offering a single bright rule; borderline tools deserve a documented assessment rather than an assumption.

How the Definition Relates to GPAI Models

The Act distinguishes AI systems from general-purpose AI models. A model, such as a large language model exposed through an API, is the engine; an AI system is the usable arrangement built around an engine, with an interface, a purpose, and a deployment context. Models carry their own obligations for their providers under the GPAI chapter, while systems carry the risk-tier obligations. When a general-purpose model is combined with even a thin application layer and offered for use, the combination is a general-purpose AI system. For businesses this means one product can implicate two regimes: the upstream model provider answers for the model, and whoever offers the finished system answers for the system.

Why Classification as an AI System Is Only Step One

Meeting the definition does not itself create heavy duties. It opens the door to the risk assessment: prohibited, high-risk, limited-risk transparency, or minimal risk. The large majority of systems that pass the definition land in minimal risk and face no new obligations beyond the organisation-wide AI literacy duty. This is worth stating plainly because teams sometimes panic at discovering that dozens of tools technically qualify as AI systems. The count does not matter; the classification of each does. An inventory of forty AI systems of which thirty-eight are minimal risk is a calm document, provided the two that touch hiring or credit are identified and handled.

How to Run the Assessment in Your Organisation

Use a short, repeatable test per tool. One: is it machine-based software? Two: does it produce predictions, content, recommendations, or decisions? Three: does it infer, meaning its behaviour was learned from data or derived by the system, rather than every rule being hand-written? Four: does it operate with any autonomy from continuous human control? If all four are yes, record it as an AI system and proceed to risk classification. Ask vendors directly whether their products contain machine-learning components and where; their answers feed your inventory and their hesitation tells you something too. Document negative conclusions as well, especially for borderline rule-based tools, citing the Commission guidelines you relied on. Definitions sit upstream of every other AI Act duty, so an hour spent here, recorded properly, anchors the whole compliance file and is the first thing a reviewer will want to see.

Worked Examples: Applying the Test to Real Tools

A few concrete walk-throughs show the test in action. A mortgage calculator that applies a published interest formula: machine-based and produces outputs, but every rule is human-specified, no inference, not an AI system. A churn-prediction model trained on historical customer data: learned behaviour, predictions influencing retention decisions, clearly an AI system. An email routing rule set built by the IT team, if subject contains invoice then forward to accounts: pure human-written rules, outside the definition. The same routing function powered by a classifier trained on past emails: inside the definition. A thermostat following a fixed schedule: outside. A thermostat that learns occupancy patterns and adjusts heating: inside. An FAQ page with keyword search: outside. A support bot generating answers from a language model: inside, and also subject to chatbot transparency. The pattern across all pairs is identical: the question is never what the tool is called or how impressive it seems, but whether its behaviour was learned or derived rather than exhaustively written by people.

What to Do With Genuinely Borderline Software

Some tools resist the quick test: hybrid systems mixing hand-written rules with small learned components, classical statistical models on the boundary of machine learning, and optimisation engines whose parameters were tuned on data. For these, three habits keep you safe. First, consult the Commission guidelines on the definition, which address several of these families directly and explain the reasoning to apply. Second, ask the vendor a precise question: does this product contain components whose behaviour was derived from data rather than explicitly programmed, and which ones? Third, when in genuine doubt, classify the tool provisionally as an AI system and run the risk-tier analysis anyway; if it lands in minimal risk, as borderline tools usually do, the practical cost of the cautious answer is one inventory line and nothing more. The expensive error is the opposite one: declaring a learned system to be ordinary software and discovering the mistake when the system is making employment or credit decisions that put it in the high-risk tier. Whatever conclusion you reach for a borderline tool, give it the same treatment as any other classification: a dated record, the reasoning in two or three sentences, the guideline passages relied on, and a named owner who will revisit the call when the product changes, because vendors routinely swap rule-based internals for learned models between versions without flagging the legal significance.

This article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.