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

The EU AI Act never answers how many AI systems you have — and that is the question an AI inventory 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.

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 and the rest of its definitions collected as the terms, as the law defines them. 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. Whether a lawyer has to sign the seam you chose is answered on its own page: do we still need a lawyer?

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. What an export of that register carries is among the questions, answered.

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.

Where this question meets the product: the AI inventory. Answering it in a customer's questionnaire: how to answer AI questions in a supplier questionnaire.