Most of the work the AI Act requires is answered one system at a time. Classification is answered per system. So are the role the organisation holds, the conformity route, the oversight assignment, the registration duty and the technical file.
A system nobody has listed cannot be classified, assessed or evidenced. That makes the register, a per-system record of the facts those duties turn on, the first substantive step of an AI Act programme rather than an administrative preliminary to it. A programme that starts classifying before the register is complete is classifying a sample of unknown size and unknown representativeness.
First, some duties are organisational. Article 4, as amended by the Digital Omnibus, requires providers and deployers to take measures to support AI literacy, and Article 17 requires a provider of high-risk systems to put a quality management system in place. Second, Chapter V places obligations on providers of general-purpose AI models, which are models rather than systems, so a register should provide for models as well as systems.
Neither moves the starting point. The organisational duties cannot be discharged without knowing what the estate contains, and what sets a programme's cost, timing and exposure still resolves per system.
Procurement records and IT asset lists are usually accurate. The difficulty is that they answer questions about purchase and installation, and the register asks about operation. Three categories of AI fall outside both, because none passes through the channels compliance already watches.
Embedded AI. A case management system with a triage module, a human resources system with a screening or ranking feature, a customer relationship platform with propensity scoring. None was bought as AI, and the capability may have arrived in a release note, switched on by default. Where the module analyses and filters job applications, the platform contains a use Annex III lists as high-risk, although the contract still describes the same platform.
Departmental adoption. Tooling adopted below the price that triggers review, or a tool the organisation already licenses pointed at a new problem. That last case is the least visible, because nothing was acquired, and changing a system's intended purpose so that it becomes high-risk is one of the routes by which an organisation becomes its provider under Article 25(1)(c), once Article 25 applies.
Pilots that became production. Nobody marks the transition, because there is no single moment to mark. The signal is dependency rather than status: a pilot whose failure would interrupt a service is production with an inaccurate label.
Wherever any of those routes has been used, the estate is larger than the record. That follows from how the three categories arise, not from published surveys, which are vendor and analyst work rather than peer-reviewed research. The reliable version of the claim is directional: expect the estate to exceed the record, expect the excess to sit in categories nobody has counted, and do not size a programme from any published multiple.
Each category is found by a different means, so start all four discovery channels together: spend analysis at service level, repository and pipeline scanning, suppliers and the procurement pipeline, and a structured survey.
The supplier letter is one written question to each major platform supplier asking which licensed modules score, rank, classify, predict or generate, and which were enabled by default. It is the quickest route to the embedded category.
The survey should ask about function and consequence rather than technology. People classify tools by what they do, so a department asked whether it uses AI systems answers honestly and inaccurately. Ask whether any process has software deciding, drafting, ranking, scoring or recommending something a person used to do, and what would be affected if it gave a wrong answer.
Do not run it as an audit. The assurance that disclosure is not a finding covers the disclosure, not the system: a disclosed system that engages an Article 5 prohibition must still be withdrawn from use.
Count one entry per distinct purpose and obligation set, not one per product or supplier. Splitting is the cheaper error to correct.
Each entry carries the purpose, where the system operates, where the people affected by it are, the role the organisation holds and a named owner who has accepted ownership in writing. The geography of affected persons is, in our experience, often omitted, and it can change the answer, because the Act reaches providers and deployers outside the Union where the output is used in the Union. An IT asset list carries few of these fields, so extending one saves less work than it appears to.
Discovery ends on a defined test: two consecutive cycles find no new systems above a defined materiality threshold, and every entry has an owner who has accepted ownership in writing. A procurement gate, a change process and an annual re-run keep the register current after that.
No provision requires a register in this form, and the high-risk obligations apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems, subject to Article 111(2) for systems already on the market. But as at 11 August 2026 the Article 4 literacy duty, the Article 5 prohibitions and the Article 50 transparency duties already apply, including to systems the organisation has not listed. The larger cost of deferral falls on planning: a programme budgeted before discovery is budgeted against a guess that is likely to be low.
The first step costs a letter, and it can go this week.
If your organisation has a policy but not a register, start with section 3 of the full paper, The Register Nobody Has, on the three categories and section 5 on the discovery channels. Section 6 sets out the survey wording, sections 7 to 9 the boundary rule, the fields and ownership, and the closing section, "Where to start, and what it costs", the staged path.
