How many AI systems do you have under the EU AI Act?

The Regulation never answers how many AI systems you have — and it is the question an AI inventory actually has to answer. Article 3 defines what an AI system is; no provision defines a unit of counting. What the law is sensitive to is intended purpose, and that seam is where honest counting starts.

Split out of what counts as an AI system on 12 August 2026; written against Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744.

Quick answer

• No provision counts systems. Nothing says when two functions are one system or two, or maps a system onto a codebase, a model or a deployment.
• The seam the law is sensitive to is intended purpose (Article 3, point (12)) — not your repository, your model or your service topology.
• One codebase can be two systems; four services can be one. The examples below carry the provisions.
• Our tie-break is convention, not law, and this page says which limb is which.

Does the Regulation tell you how many AI systems you have?

No — and that is the question a register actually has to answer. Article 3 defines what an AI system is, with the qualifying test read limb by limb on its own page. No provision defines a unit of counting, says when two functions are one system or two, or maps a system onto a codebase, a model or a deployment.

What the Regulation supplies instead is the property every test is applied to. Intended purpose, under Article 3, point (12), is "the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation."

Three provisions turn on it:

• Annex III lists use cases, and Article 6(2) classifies through them: "AI systems referred to in Annex III shall be considered to be high-risk." Classification asks what a system is for, not what it is built from.
• Article 25(1), point (c) makes a third party who modifies the intended purpose of an AI system a provider — where that system "has not been classified as high-risk and has already been placed on the market or put into service", and the change means it "becomes a high-risk AI system in accordance with Article 6". Both conditions travel with the point.
• Article 3, point (23) defines a substantial modification as a change after placing on the market or putting into service, not foreseen or planned in the initial conformity assessment, as a result of which either compliance with Chapter III, Section 2 is affected or the intended purpose for which the system was assessed is modified. A change of purpose is one of the two limbs, standing on its own.

Infrastructure is expressly not the test: recital 12 records that AI systems "can be used on a stand-alone basis or as a component of a product, irrespective of whether the system is physically integrated into the product (embedded) or serves the functionality of the product without being integrated therein (non-embedded)."

Where our counting rule comes from, and where it stops being law

We sell by the system, so we have a commercial interest in this number — read the rule knowing that. Each limb carries the provision behind it; the last carries none.

One system is one thing your AI does — because intended purpose is the property Annex III, Article 6(2) and Article 25(1), point (c) all turn on.

One codebase and one model can be two systems. A product that ranks job applicants and answers support questions has two intended purposes; analysing and filtering job applications is named in point 4, point (a), of Annex III, and answering support questions is named nowhere in it. One record cannot carry both answers.

One job spread across four services is still one system. Nothing in the Regulation counts services, and recital 12 makes topology irrelevant.

The tie-break is ours, not the law's: if two things would get different answers to the assessment questions, they are different systems. It exists because splitting costs you a row in a register while merging can hide a use case that classifies differently — the two errors are not symmetrical, and only one is a compliance problem.

A different seam is defensible if you can name the intended purpose each record covers: what a reviewer tests is whether the record answers which systems, what classification and on what basis. Complipath's guided risk classification records the intended purpose you state, the provisions that fired and the reasoning, per system; what it can and cannot decide is published, because a tool that will not say where it stops should not be trusted with a classification. The five-step method is the order to run them in.

What this means for you

If you're a provider: pick the seam, write it down, and let every record name the intended purpose it covers — the counting decision is itself evidence, and the decision tree runs per record from there.

If you're a deployer: your vendor's product count is not your system count. A suite you subscribe to can hold several intended purposes, and the ones that touch Annex III use cases need their own answers.

How many entries will your register hold?

Classify your system now — 7 questions on the main line, plus follow-ups where they apply, no account, and the classification runs in your browser: answers stay there unless you choose to keep the result.

FAQ

Does the EU AI Act say how many AI systems you have? No. Article 3 defines what an AI system is; no provision defines a unit of counting, says when two functions are one system or two, or maps a system onto a codebase, a model or a deployment. The property the law is sensitive to is intended purpose under Article 3, point (12).

Can one codebase be two AI systems? Yes. A product that ranks job applicants and answers support questions has two intended purposes: analysing and filtering job applications is named in point 4, point (a), of Annex III, and answering support questions is named nowhere in it. One record cannot carry both answers.

One model doing three things — how many systems? The Regulation does not count, so nothing in it answers directly. What it is sensitive to is intended purpose: Annex III lists use cases, and Article 25(1), point (c) treats a change of intended purpose as capable of turning a non-high-risk system into a high-risk one. Three intended purposes, three records.

Is the tie-break law? No — it is our convention, and the page says so: if two things would get different answers to the assessment questions, they are different systems. Splitting costs a row in a register; merging can hide a use case that classifies differently. The two errors are not symmetrical, and only one is a compliance problem.

Sources: Regulation (EU) 2024/1689 (EUR-Lex), Article 3, points (12) and (23), Article 6(2), Article 25(1), point (c), recital 12, and point 4 of Annex III, point (a). Split out of the qualifying-test guide on 12 August 2026; the verbatim rows behind every quotation are in that guide's claims file, tables C and D, referenced from this page's own claims file.