Module 2 — The Inventory and Classification Register

Module 2 of the AI Act Compliance certification: the register that answers the first question a supervisor asks, the fields that cannot be reconstructed, and the shadow-AI problem.

A supervisor's first question is not about your policy. It is: which AI systems do you use. Everything else in a supervisory conversation branches from the answer, and the answer is a register or it is an anecdote.

Why the register, not the policy, is the foundational artefact

Three reasons.

It is the only artefact that is complete or not. A policy can be good or bad; a register either lists the systems you run or it does not. That binary is why it is asked for first.

It is the input to every other obligation. Classification, prohibitions, transparency duties, oversight assignment, log retention — all are per system. Without the list, each is done for whatever comes to mind.

Its gaps are the systems most likely to carry obligations. A system that went through procurement was probably assessed by somebody. One that arrived on a corporate card was not.

The fields, and why each is there

Three of these deserve emphasis.

The quoted intended purpose. Not a paraphrase, not your understanding of it — the vendor's words. It is the baseline against which purpose creep becomes visible, and it is the field organisations most often skip because it feels like duplication of the contract.

The role held. Compliance teams frequently write "deployer" across the whole register and then discover an internally built model, which has a provider, and it is them.

The legal baseline of the determination. The Digital Omnibus rewrote Art. 4 and moved the Chapter III dates in July 2026. A determination that does not say which text it was made against cannot be reviewed — it can only be redone, and redoing sixty determinations is a quarter.

The shadow-AI problem

Every inventory exercise surfaces systems nobody had listed, and they are disproportionately the ones carrying obligations. Practical discovery routes:

• Expense and card data. Filter for known AI vendors and for small recurring charges.
• Identity provider / SSO app inventory. Anything OAuth-connected to a corporate account.
• Network egress. Traffic to known model API endpoints from corporate networks.
• Feature flags in existing systems. The riskiest category: an AI scoring or ranking feature switched on inside an ATS, CRM or service desk you already own and already registered as non-AI.
• Ask, with an amnesty. A stated position that declaring a tool now has no consequence, and using an undeclared one later does, produces more disclosures than any technical control.

That fourth route is the one technical discovery misses entirely, because there is no new vendor and no new traffic — just a toggle in a product you already have.

Classification, and writing the negative

For each system, record the conclusion and the reasoning, including where the conclusion is that nothing applies.

A useful determination reads: "Annex III point 4 considered because the system ranks internal candidates for promotion. Concluded: high-risk, no carve-out available. Art. 6(3) not relied on — the system profiles natural persons, which voids the filter under Art. 6(3). Decided by [name], 12 September 2026, against Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744."

And the negative case is as valuable: "Annex III point 5(b) considered because the system scores transactions. Concluded: outside 5(b), which expressly carves out AI used to detect financial fraud. Decided by [name], date, against [text]."

Writing negatives down is what stops the same question being re-argued every quarter, and what lets a supervisor see that you looked rather than that you were lucky.

Keeping it alive

A register is current or it is archaeology. Three triggers should update it:

Procurement. No new system without a register entry. Module 4.

Purpose change. Any new use case for an existing system, which is the Art. 25(1)(c) gate.

Legal change. When the law moves — as it did in July 2026 — the determinations with a superseded baseline need review, and the baseline field tells you which those are in one query.

An annual review with no trigger-based updates produces a register that is accurate one day a year.

What good looks like at inspection

You can produce, for a named system, within minutes: what it is, who owns it, what role you hold, the classification and its reasoning, the intended purpose as declared, who oversees it, where the logs are and for how long, and which transparency notices apply.

If that takes a week to assemble from four teams, the finding will be about your governance rather than about the system.

Check yourself

1. Our register lists vendors. — Register systems, not vendors. One vendor may supply three systems in different tiers, and a feature toggle in an existing product is a system you already own.
2. We recorded the classification but not the reasoning. — The reasoning is what makes it reviewable. Record the Annex III point checked, the carve-out relied on, and the decision date and baseline.
3. We are a deployer, so the whole register says deployer. — Roles are per system. An internally built model has a provider, and it is you.
4. Why quote the intended purpose rather than summarise it? — Because Art. 25(1)(c) turns on whether you changed it, and a paraphrase written by you is not evidence of what the vendor declared.

Previous: Module 1 — The map, and the timetable that actually applies Next: Module 3 — The Art. 4 literacy programme →