AI inventory for the EU AI Act: the register that knows which law it answered

An AI inventory is one list with a line for every AI system you run. Each line says what the system is for, which group the law puts it in and which article says so, the answers that decision was based on, who confirmed it and when. The word "inventory" appears nowhere in the Regulation. We use it because you do — and what the law has instead is duties that attach per system, none of which can be answered without one. And because the law has already changed once, one property separates a register from a spreadsheet: every entry has to know which version of the law it answered.

Written 12 August 2026 against Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, in our pinned source corpus.

What must an AI inventory record for each system?

• The system, not the model or the vendor. Duties attach to AI systems by intended purpose, and one codebase can be two systems.
• The classification and its article — high-risk under Article 6, transparency-obligated under Article 50, prohibited under Article 5, or the residual. The article is what makes the entry checkable.
• Negative decisions too. Article 49(2) requires the provider — or, where applicable, the authorised representative — who concluded a system is not high-risk under Article 6(3) to register themselves and the system in the EU database before placing it on the market or putting it into service: the Regulation itself treats "not high-risk" as a decision worth recording.
• Who confirmed it, and when. A named person's confirmation is what turns a tool's output into your evidence.
• The version of the law it answered — the property this page is about.

Which AI systems belong in the inventory?

All of them — the inventory is how you find out which tier each one lands in, and the residual tier is a conclusion, not an exemption from the list. The unit is the system with its intended purpose: the same model shipped for two purposes is two entries, and a system built on a general-purpose model is classified by what it is for while the model carries its own Chapter V duties. Providers and deployers both need one — the same high-risk system generates different duties for each role, and Article 26(1) obliges deployers of high-risk systems to take measures ensuring they are used in accordance with the instructions for use — a duty you cannot discharge for a system you have not listed.

For high-risk systems in Annex III the inventory has a public counterpart: Article 49(1) requires the provider — or, where applicable, the authorised representative — to register themselves and the system in the EU database of Article 71 before placing it on the market or putting it into service, with the exception of high-risk systems referred to in point 2 of Annex III. Your internal register is where that filing, and every other per-system duty, starts.

Why must the inventory be versioned against the law?

Because a source text is a state, not a constant. Regulation (EU) 2026/1744 amended Regulation (EU) 2024/1689 in force — among much else it replaced the application dates in Article 113, third paragraph, so the high-risk requirements now apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems (point (c), as amended). A classification recorded in July 2026 answered a different text than one recorded today. A register that does not record which text each entry answered cannot tell you which entries the amendment touched — and "re-check everything" is what nobody does.

This is the property Complipath is built around, and it is checkable rather than asserted:

• Every record keeps the engine version that produced it — the rules as they stood, a fact of the record, not a banner that silently updates.
• Every verdict carries a corpus statement: which regulations the classification rules were derived from, which amending text is known and not yet derived, and which provisions the assessment does not detect — the same statement every export carries.
• Exports and shared views freeze the legal position in the document itself — produced-on date and corpus statement travel with the PDF, because a document that has left the building must not depend on a live view that keeps moving.
• When an amending act lands, the register can say which of your systems cite provisions the act touched. It names the provisions and the affected entries; it never concludes anything about your compliance — nothing is re-classified automatically, and the named person who confirmed the entry decides what to do. That boundary is deliberate: what this check can and cannot decide is published, not discovered.

We hold our own published text to the same discipline: every quotation on this site is checked on every build against sha256-pinned source files, a superseded source file is kept forever as the evidence of what the law said when a page was written, and the amendment's reach was derived from the amending act's own enumeration of what it replaced and deleted — which is how this page can say what changed without asking you to trust it.

What does a defensible inventory look like in practice?

Start with the systems that decide something about people — employment, credit, access to services — because those are where Annex III and the nearest deadlines live. Record every conclusion with its article, including the negative ones. Date every entry and confirmation. Then keep the register alive: the Regulation's dates arrive in sequence, and classification is what tells you which ones reach you.

If you're a provider: your inventory feeds the public one — Article 49(1) registration in the Article 71 EU database for Annex III high-risk systems (except point 2 of Annex III), and Article 49(2) registration of documented not-high-risk conclusions under Article 6(3). The Article 16 obligations that follow a high-risk entry are per system too.

If you're a deployer: you owe the Article 26 duties for every high-risk system you use, and you cannot owe them for systems you have not listed. Watch the role boundary: modify a system's intended purpose and you can become the provider.

Run the classification — real engine output

The block below is not a mock-up. It is rendered from a real run of the Complipath engine, fetched from the live API at every build — the same payload, character for character, that the published example assessment shows in full, with the engine version and the parts the run left undetermined printed rather than trimmed.

The engine is deterministic: fixed rules over your confirmed answers, every verdict traceable to the article it rests on — and where it stops is published, not discovered: what this check can and cannot decide lists both sides, written once by a person, never generated per visitor.

What would your first entry say?

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 require an AI inventory? Not by that name — the Regulation never uses the word; "AI inventory" is the buyer's term, and ours. But its duties attach per system: classification under Article 6, registration of Annex III high-risk systems (point 2 of Annex III excepted) in the EU database under Article 49(1) and Article 71, deployer duties under Article 26. None of them can be answered without a per-system register.

What should each AI inventory entry contain? The system's intended purpose, the risk classification with the article it rests on, the answers behind it, the named person who confirmed it, the date, and the version of the law and rules it was made against. Negative conclusions are entries too — Article 49(2) even requires registering not-high-risk conclusions reached under Article 6(3).

Do deployers need an AI inventory too? Yes. Article 26 attaches duties to deployers per high-risk system — measures ensuring use follows the instructions for use (26(1)), assigning human oversight (26(2)), monitoring operation (26(5)) — and you cannot owe a per-system duty for a system you have not listed. Provider and deployer registers can contain the same system with different duties attached.

What happens to the inventory when the law changes? It has already happened: Regulation (EU) 2026/1744 amended the 2024 text in force. An entry that records which version of the law it answered can be found and re-confirmed; one that does not leaves you re-checking everything or nothing. In Complipath, records keep their engine version and corpus statement, and a person decides what gets re-confirmed.

Sources: Regulation (EU) 2024/1689 (EUR-Lex), Articles 6, 26, 49, 71 and 113, and Annexes I and III, as amended by Regulation (EU) 2026/1744 (EUR-Lex) — the corpus this page's every quotation is verified against on every build. Product claims are measured against the application's code; the engine output on this page is fetched from the live API at build time, its provenance and holds printed by the build, never assumed.