--- title: "The AI systems register: why it matters and how to build it" url: https://zerofive.ai/en/blog/compliance/ai-systems-register-how-to-build canonical: https://zerofive.ai/en/blog/compliance/ai-systems-register-how-to-build language: en published: 2026-03-19 updated: 2026-09-18 author: "ZeroFive.AI" tags: AI systems register, AI inventory, AI Act register, AI systems census, AI governance abstract: "The AI systems register is the first governance tool and the base of any AI Act programme: what it contains, how to build it and how to keep it alive." --- # The AI systems register: why it matters and how to build it Among all the deliverables of an AI governance programme, the systems register is the one with the most unbalanced ratio between how humble it is and how decisive. Humble because in its first version it is, literally, a table. Decisive because every other governing activity depends on it: you cannot risk-classify what was never censused, you cannot assess the privacy impact of an unknown processing operation, you cannot present to the board the state of a perimeter nobody ever delimited. In our assessments its absence is one of the critical gates that cap the merit class regardless of the other scores, and the choice is deliberate: an organisation that does not know what it uses cannot, by definition, govern it. ## What it is for, beyond the obvious The regulatory function is what pushes most companies to start. The AI Act reasons by systems, and every obligation, from classification to high-risk requirements to transparency, presupposes knowing which systems exist and in which role the company touches them; for deployers of high-risk systems, assessments and documentation require exactly the information a good register already contains. Anyone who knows the GDPR will recognise the logic of the Article 30 record of processing activities, and the kinship is not merely conceptual: many rows of the two registers overlap, and building them in dialogue avoids censusing the same world twice. The managerial function, less quoted, is worth more in daily life. The register is the place where the CFO discovers how much the company truly spends on AI by adding up licences scattered across functional budgets, where the CISO sees the attack surface individual purchases have composed, where whoever evaluates a new use case checks whether a suitable tool already exists, avoiding the third subscription to the same service. It is also the structural antidote to the shadow AI we wrote about: the phenomenon thrives in the absence of an official place where tools can be declared. ## What to write in each row A useful register holds together a few well-chosen pieces of information, and experience suggests about a dozen fields. The system's identity: name, supplier or internal development, description of purpose in business language. The responsibility: the internal owner with first and last name, the function using it. The regulatory profile: the company's role (provider or deployer), the AI Act risk category with its written rationale, the presence of personal data with the related legal basis and the reference to the DPIA where one exists. The operations: the data the system consumes and produces, the systems it integrates with, the status (experimentation, production, retired) and the date of the row's last review. Two warnings save months. The first concerns granularity: the right entry is the system in its context of use, not the product, because the same tool used by marketing for drafts and by HR for screening is one row for procurement and two very different rows for risk. The second concerns initial ambition: the perfect first version is the enemy of the existing first version, and a shared sheet with twenty honest rows beats the platform project starting in six months. Dedicated tools arrive once the register has proven it can live. ## Keeping it alive, which is the hard part Every organisation that built a register then discovered the second half of the job: registers die of obsolescence in silence, and a year-old register is almost worse than none, because it produces false confidence. Survival is designed by hooking updates to the flows where systems are born and change. Procurement is the main hook: no purchase with AI components completes without its register row filled, and the question "does it contain AI?" enters the supplier checklist. The second hook is release: no use case reaches production without registration. The third is the periodic amnesty window for whatever escapes the first two, direct heir of the initial census. Finally a custodian is needed, typically inside the function chairing AI governance, with the explicit mandate to chase incomplete rows: registers do not update themselves out of kindness. Built this way, the register stops being a formality and becomes the map on which decisions are taken, from intervention priorities to the fast answer when an authority, a client or the board asks "which AI systems do you use and how do you govern them?". If that question would catch you improvising today, the first step costs little and can be taken with method inside a full measurement: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The minimal version of the exercise, meanwhile, fits in one empty row and one question: which system would you write down first, and whose name would you put in the owner column?