What Is an AI System, Actually?

The EU definition — and why it's causing more debate than clarity.

---

I had dinner with a friend recently.

Smart guy. Corporate Counsel in a Big Tech company, who deals with compliance daily.

We got to talking about the EU AI Act — as you do when two lawyers meet and the wine hasn’t arrived yet — and he offered what he clearly considered a clean, practical test.

“If it’s software,” he said, “it’s not AI. And if it’s not AI, the AI Act doesn’t apply.”

He said it like someone closing a door.

Simple. Done. Next topic.

And I sat there thinking — that’s not quite right.

But it’s also not entirely wrong.

And the distance between “not quite right” and “not entirely wrong” is exactly where most companies are going to get stuck.

The EU AI Act doesn’t regulate “artificial intelligence” the way most people understand that term.

It regulates “AI systems” — a legal concept with a specific definition, seven elements, and a set of boundaries that don’t map neatly onto what your IT team thinks AI is or what your legal team thinks software is.

If you don’t know whether your system qualifies as an AI system under Article 3(1), nothing else in the regulation makes sense. Not the risk classification. Not the transparency requirements. Not the documentation obligations. Not the fines.

This is the first question. Everything else comes after.

---

The Definition — Seven Elements, One Sentence

Article 3(1) of the EU AI Act defines an “AI system” as:

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.

One sentence. Seven elements. And the European Commission needed an entire set of guidelines — published on 6 February 2025 — to explain what it means.

The definition is aligned with the OECD’s definition of an AI system, which matters for international consistency. But consistency in wording doesn’t mean clarity in application.

First, a machine-based system. Software, hardware, or both. Running on a server, a device, embedded in a product. This is the least interesting element — if it runs on a machine, it qualifies. Moving on.

Second, designed to operate with varying levels of autonomy. The system needs some degree of independence from human involvement. Not full autonomy — partial counts. But a system “designed to operate solely with full manual human involvement and intervention” is out. The word “designed” matters. It’s about intent, not just current operation. A system designed to run autonomously but currently supervised by a human? Still designed for autonomy.

Third, may exhibit adaptiveness after deployment. “May” is the word doing the heavy lifting. Self-learning, runtime adaptation — these are features some AI systems have. But their absence doesn’t disqualify a system. A model trained once, frozen, and deployed without ever updating itself can still be an AI system if it meets the other elements. Adaptiveness is a characteristic, not a requirement.

Fourth, for explicit or implicit objectives. The system pursues goals. Explicit ones are programmed in. Implicit ones are derived from the system’s behavior — a large language model doesn’t have a stated “objective” in the traditional sense, but it implicitly aims to produce coherent outputs. This element is broad by design.

Fifth, infers, from the input it receives. This is the one that matters most. The element that separates AI systems from traditional software. Inference means the system derives outputs through a process that goes beyond executing pre-programmed rules. It involves deriving models or algorithms, reasoning, pattern recognition — something more than “if X, then Y.”

Recital 12 puts it plainly: “A key characteristic of AI systems is their capability to infer.” It then excludes “simpler traditional software systems or programming approaches” and systems “based on the rules defined solely by natural persons to automatically execute operations.”

The techniques that enable inference, according to the Act and the guidelines, fall into two families:

• Machine learning approaches — systems that learn patterns from data, whether from labeled examples, from finding structure in data on their own, or from improving through trial and error. This includes deep learning and neural networks — the technology behind image recognition, language models like ChatGPT, and most of what makes AI headlines.

• And logic- and knowledge-based approaches — systems that reason using structured knowledge, like expert systems that apply a web of rules and relationships to reach conclusions (think medical diagnosis tools or legal reasoning engines).

Sixth, how to generate outputs such as predictions, content, recommendations, or decisions. Four output types, non-exhaustive. Predictions, newly generated content (text, images, audio), recommendations, and decisions.

Seventh, that can influence physical or virtual environments. The outputs must have potential to affect something. Physical environments (robotics, autonomous vehicles) or virtual ones (content moderation, search results, recommendations). Broadly interpreted.

Seven elements. All must be present. Miss one, and the system falls outside the definition.

---

What the Guidelines Say Is Not an AI System

A few weeks after that dinner, I was talking to an IT architect.

He mentioned a program his team was building — a prediction system for capacity planning.

Nothing fancy, he said. Takes last year’s data, runs a simple statistical formula, estimates next quarter’s numbers. No model training. No learning. Just math.

Something clicked.

Because the Commission’s February 2025 guidelines describe almost exactly that kind of system. And they say — explicitly — it’s not an AI system under the AI Act.

The guidelines identify four categories of systems that fall outside the definition.

The common thread: although some of these systems have a capacity to infer, they fall outside scope “because of their limited capacity to analyze patterns and adjust autonomously their output.”

That phrase — “limited capacity” — is doing enormous work.

The guidelines aren’t saying these systems can’t infer at all. They’re saying the inference is too limited to qualify.

With that laid out, here are the four categories:

1. Systems for mathematical optimisation

Systems used to improve or approximate traditional, well-established optimisation methods — including linear or logistic regression.

In practice, this covers a logistic regression model estimating credit default probability with fixed coefficients. A linear regression forecasting demand. The guidelines follow the OECD’s line here: simple statistical techniques like linear or logistic regression fall outside the AI system definition.

For financial services, this is significant. Logistic regression is a workhorse in underwriting, credit scoring, and risk assessment. If these fall outside the definition, a meaningful number of systems in banking and insurance are potentially out of scope — even systems that would qualify as “high-risk” under Annex III if they were AI systems.

The catch: the guidelines say "linear or logistic regression methods." They don't address what happens as you move up the complexity ladder. If your data science team uses terms like ridge regression, lasso, polynomial regression, or random forests — those aren't covered by this exclusion. And nobody knows yet where they land. The further you get from simple linear or logistic regression, the harder it becomes to rely on this carve-out.

2. Basic data processing

Systems that follow “predefined, explicit instructions or operations... developed and deployed to execute tasks based on manual inputs or rules, without any learning, reasoning or modelling at any stage of the system lifecycle.”

In practice: database management systems that sort and filter based on specific criteria. Standard spreadsheet applications without AI functionality. Inventory management systems with fixed rules. Traditional business logic engines. Workflow engines that route documents based on if/then logic.

This is the clearest exclusion. If a system simply executes human-written rules with no learning component at any stage, it’s not an AI system under the AI Act.

3. Classical heuristics

Rule-based problem-solving systems that “typically involve rule-based approaches, pattern recognition, or trial-and-error strategies rather than data-driven learning.” They do not evolve through data or experience.

The guidelines give the example of chess programs based solely on minimax algorithms. Also in this category: rule-based spam filters using keyword matching, basic pattern-matching systems, traditional search algorithms.

These are systems that might feel smart — that might even be called “AI” internally — but aren’t learning from data. A fraud detection system with 500 hand-coded rules (”flag transactions over €10,000 from new accounts”) is a classical heuristic. Even if the compliance team has been calling it their “AI fraud system” for three years.

4. Simple prediction systems

Systems that predict using basic statistical rules and do not adapt or evolve over time.

The guidelines give a specific example: “a program that estimates future stock prices by using an estimator with the ‘mean’ strategy to establish a baseline prediction.” A system that predicts next month’s temperature by averaging the last ten years of data falls here too.

This is the exclusion that will generate the most friction between legal and technical teams. To a data scientist, a prediction system — even a simple one — is doing something that looks like AI. To the guidelines, if the prediction mechanism is a fixed statistical rule that doesn’t learn or adapt, it’s out.

---

What Clearly Qualifies

The other side of the line is less controversial. The guidelines and Recital 12 make clear that the following approaches create AI systems when used as part of a system meeting the full Article 3(1) definition.

Machine learning systems

Systems that learn from data — whether they learn from labeled examples (this is called supervised learning), find hidden patterns or groupings on their own (unsupervised learning), or improve through trial and error (reinforcement learning). Deep learning and neural networks fall here too — the technology behind image recognition, large language models, and most of what the world currently calls "AI." If your technical team says a system was "trained on data," you're almost certainly in this category.

Logic- and knowledge-based systems

Systems that reason using structured knowledge — expert systems (medical diagnosis tools, legal reasoning engines), systems that represent relationships between concepts and draw conclusions from them, and systems that use logical rules to infer new information from existing knowledge. The distinguishing feature from the excluded "basic" rule-based systems: these don't just execute rules mechanically. They reason with them.

In practice, this means:

• A machine learning model trained on historical data to predict credit defaults — in scope.

  • Contrast with a logistic regression estimator using fixed coefficients — that’s out.

• A recommendation engine that learns user preferences over time — in scope.

• A chatbot powered by a large language model — in scope.

• A computer vision system trained to detect defects on a production line — in scope.

• An expert system for medical diagnosis that uses a knowledge base and inference engine — in scope.

• A natural language processing system for document classification — in scope.

The pattern: if the system learns from data, reasons beyond its explicit rules, or derives models through training — it’s in.

---

The Paradox

I've written before about why the AI Act is generating more confusion than clarity. The same applies when it comes to the definition of an AI system.

Recital 12 excludes systems “based on the rules defined solely by natural persons to automatically execute operations.” Rules written by humans, executed mechanically. Out.

But the same guidelines include logic- and knowledge-based approaches — expert systems, symbolic reasoning, inference engines — where the rules are “encoded by human experts” through “rules, ontologies, or knowledge graphs.”

Both are rule-based. Both have rules defined by humans. One is out. One is in.

The guidelines never draw an explicit line between a “simple” rule-based system that’s excluded and a “complex” rule-based system that’s included as a logic- or knowledge-based approach. There’s no test. No threshold. No “if your rule-based system has more than N rules, it’s in.” Nothing.

My reading — and this is my interpretation, not settled law — is that the distinguishing factor is the inference capacity. An if/then business logic engine applies rules mechanically. It does what the programmer told it to do, every time, the same way. An expert system with an inference engine can chain rules together, handle uncertainty, weigh competing rules, and reach conclusions that weren’t explicitly programmed as a single path. One executes. The other reasons.

But the guidelines don’t say this explicitly. And multiple law firm analyses have flagged the same contradiction. One noted that the guidelines “appear to lack an obvious underlying logic to the examples that fall inside and outside of scope.” Another pointed out the paradox of excluding “rules defined solely by humans” while including expert systems where the rules are... defined by humans.

The logistic regression question adds another layer. Logistic regression is out. But what about a logistic regression model used as part of a larger ensemble? One whose parameters are updated periodically with new data? One used for feature selection that feeds results into a neural network? The guidelines address the technique in isolation. Real systems use combinations.

And the adaptiveness element creates its own trap. The definition says adaptiveness is not required — “may exhibit.” But one of the key reasons the four exclusion categories are excluded is precisely that they “do not adapt or evolve over time.” Adaptiveness isn’t required to be an AI. But its absence is one reason it might not be an AI. This isn’t a contradiction exactly, but it creates a zone where a non-adaptive system might or might not qualify depending on how sophisticated its inference is.

The "limited capacity" phrase — the reason all four exclusion categories are out — is never defined. Where does "limited" end and "sufficient" begin? The guidelines don't say. Which leaves a genuine grey zone for a whole class of techniques that sit between simple statistics and full-blown machine learning. If your technical team mentions gradient boosted trees, simple neural networks, nearest-neighbor methods, naive Bayes, or support vector machines — ask them to explain what those systems actually do. Because the guidelines don't address any of them.

All more sophisticated than logistic regression. All arguably capable of inference. All potentially falling into the “limited capacity” gap that the guidelines created but didn’t fill.

---

Two Conversations, One Problem

I keep coming back to those two conversations.

The lawyer who drew a clean line — software on one side, AI on the other — and moved on with his meal. The IT architect who described a prediction system that would be unambiguously “AI” in his professional world but falls outside the AI Act’s definition entirely.

Neither was wrong, exactly. But neither had the full picture. And the space between their perspectives is where compliance actually lives.

The lawyer’s instinct — “if it’s software, it’s not AI” — gets at something real. The AI Act doesn’t regulate all software. It regulates a specific subset of software with specific characteristics. But “it’s software, not AI” is imprecise to the point of being dangerous. An expert system is software. A deep learning model deployed as a web service is software. A chatbot running on an API is software. All of them are AI systems under the AI Act.

What the lawyer probably meant was: if it’s traditional software using fixed rules, it’s not an AI system under the AI Act. That’s closer to correct. But only if the system truly has no inference capability beyond mechanical rule execution. And the only way to know that is to look inside the system — at what it actually does, not what it’s called.

The IT architect’s perspective carries a different risk. In his world — and in the world of every data science team I’ve encountered — “AI” includes any system that makes predictions. Any system that uses data to generate outputs. Logistic regression, linear regression, decision trees — all “ML/AI.” All part of the toolkit.

Under the EU AI Act, many of those are not AI systems. A logistic regression model with fixed coefficients? Not AI under the AI Act. A simple averaging prediction system? Not AI. A rule-based system with hand-coded rules? Not AI.

This matters in both directions. Technical teams may flag systems for compliance that don't need it — burning resources, delaying projects, creating unnecessary work. Or they may hear "your logistic regression isn't AI under the AI Act" and conclude that nothing in their pipeline needs attention — missing the more sophisticated model sitting right next to it that probably does qualify.

The translation both teams need is this: “AI” under the EU AI Act is a legal definition. It doesn’t match the colloquial understanding and it doesn’t match the technical one. Something can be artificial intelligence in every data science textbook and not be an “AI system” under Article 3(1). And something your legal team dismisses as “just software” can still qualify if it has the right kind of inference capability.

Neither team can do this analysis alone. Legal can’t assess scope without understanding what the system technically does. Tech team can’t assess it without understanding what the legal definition actually requires. The exercise has to be joint.

---

Borderline Cases — Where the Line Gets Blurred

Theory is useful. Specific examples are better.

So, let’s take a look where the definition meets actual systems.

The credit scoring model. A bank uses logistic regression to score credit applications. Trained on historical data, fixed coefficients, no post-deployment learning. The data science team calls it an ML model. The guidelines say logistic regression falls outside the AI system definition. Likely not in scope. But — if the bank periodically retrains with new data and redeploys, the picture gets murkier. And if the logistic regression is one component in a larger pipeline that includes ML elements, the pipeline as a whole might still qualify.

The rule-based fraud detection system. An insurer runs a system with hundreds of hand-coded rules — “if claim amount exceeds €50,000 and policyholder tenure is under one year and no police report was filed, flag for review.” Rules written by domain experts. No learning component. The guidelines would classify this as basic data processing or classical heuristics. Not AI. The moment the insurer adds a machine learning layer — a model that scores flagged claims by likelihood of actual fraud based on historical outcomes — that component moves toward the definition. One layer changes everything.

The recommendation engine. An e-commerce company runs two versions. Version A uses machine learning to learn patterns from user behavior — what people browse, buy, and ignore — and generates personalized recommendations based on those patterns. Likely an AI system. Version B uses a simple lookup — "customers who bought X also bought Y" — based on counting how often products are purchased together. No learning, no adaptation, just a fixed rule. Closer to basic data processing. Probably not an AI system. Two systems, same job, different classifications — because the definition cares about how the system works, not what it does.

The chatbot spectrum. A basic FAQ chatbot that matches keywords in your question to pre-written answers from a fixed database? Not AI under the AI Act. A chatbot powered by a large language model that generates its own responses? Unambiguously AI. The interesting case: a chatbot that uses a small machine learning model to figure out what you're asking about (intent classification, in technical terms), then serves a pre-written response based on that classification. The classification component has inference capability — it learned from data how to categorize questions. Likely an AI system — even though the answers themselves are canned.

---

Even If It’s an AI System — It Might Still Be Out of Scope

The definition question and the scope question are different analyses. A system can be an AI system under Article 3(1) and still fall outside the AI Act’s obligations through exemptions in Article 2.

Research and development. AI systems in research, testing, or development before being placed on the market or put into service are excluded. But testing in real-world conditions is covered. The moment you go from lab to live users, the exemption ends.

Open source. Free and open-source AI models are generally exempt — unless they’re classified as high-risk, involve prohibited practices, or trigger transparency obligations. Not a blanket pass.

Military, defence, national security. AI systems used exclusively for these purposes are excluded. “Exclusively” is load-bearing — any dual-use or civilian spillover brings the system back in scope.

Personal non-professional use. Natural persons using AI for purely personal purposes are exempt from deployer obligations.

The distinction matters: a logistic regression model isn't an AI system at all — the definition question. A deep learning model used in defence is an AI system, but it's exempt — the scope question. Different analyses, different conclusions. Both necessary. And if you're outside the EU wondering whether any of this applies to you — it probably does.

---

The Bigger Picture

I’ve been thinking about what that dinner conversation really exposed.

It wasn’t about one lawyer being wrong. It was about how instinctively everyone reaches for a simple answer to this question. Software or AI. In or out. Regulated or free. And the regulation — whether by design or by accident — doesn’t give you a simple answer.

Every obligation in the AI Act flows from the AI system definition. Risk classification under Article 6? Only applies to AI systems. Transparency requirements under Articles 50 and 52? Only AI systems. GPAI obligations under Articles 51 through 56? Only AI models and systems. Documentation, conformity assessment, registration — all triggered by having an AI system.

The definition is the on/off switch for the entire regulation.

The Commission’s guidelines got the extremes right. A spreadsheet macro is not an AI system. A deep learning model is. The four exclusion categories give specific examples that many companies can use to sort their obvious cases.

What the guidelines left unresolved is the middle. The “limited capacity” standard is too vague to resolve borderline cases without system-by-system analysis. The rule-based paradox — excluded as “traditional software” but included as “expert systems” — has no clear test. The interaction between techniques in real-world pipelines, where a system might use both excluded and included approaches, isn’t addressed at all.

Which means most companies will need to do what regulations always end up requiring when the text is ambiguous: the actual work.

Map your systems. Not by their names, not by their marketing labels — by what they technically do. Have the technical team describe the actual mechanism. Have the legal team apply the seven elements of Article 3(1). For every system where inference is the question — and it usually will be — assess whether the system’s inference capacity is “limited” in the way the guidelines describe, or whether it goes beyond the four exclusion categories.

Document the reasoning. Especially for borderline cases. “We assessed this system against Article 3(1) and concluded it does not qualify because...” is a sentence that will matter when enforcement starts.

Don’t take this lightly. The guidelines leave gaps — real ones — and the temptation is to read those gaps in your favor. To call something “just software”. To assume a system is exempt because it uses a technique that sounds like one of the four exclusion categories.

The gaps will be filled. Through enforcement, through case law, through updated guidance. And the companies that did the rigorous assessment — system by system, element by element, with legal and tech teams in the same room — will be the ones who aren’t scrambling when that clarity arrives.

The definition is where compliance starts.

It’s also where most companies stop thinking too soon.

Don’t be most companies.