What should an AI system inventory contain before an EU AI Act review?
A practical register for mapping AI use cases, roles, affected people, data, controls, evidence and review ownership before an AI governance assessment.
The short answer
An AI system inventory should give a reviewer enough context to understand one real use case without chasing five teams. Each entry should name the business purpose, current status, system owner, supplier chain, users, people affected, input and output data, decisions influenced, human control, transparency measures, integrations, incidents, evidence and next review date.
Use one entry per use case, not one entry per vendor. The same model used to draft internal notes and to rank job applicants has two different purposes, impacts and review paths. The inventory is a map for governance work. It is not, by itself, a legal classification, a risk assessment or proof of compliance.
Record each use and its context
A list of supplier names tells you what the organisation pays for, but not what the tools do. Start with the process: answering patient calls, summarising worker reports, screening candidates, drafting emails or forecasting staffing demand. Then record where the AI enters the process, what output it produces and what happens next.
Include live systems, pilots and approved trials. Add a status for tools that are paused, being retired or discovered but not yet approved. Everyday software may contain an AI feature even when the contract is filed under CRM, telephony or office productivity. Ask process owners what they actually use instead of relying only on the procurement catalogue.
Name the role and the supply chain
The EU AI Act distinguishes roles such as provider and deployer. A deployer uses an AI system under its authority, while a provider develops a system, has it developed, or puts it into service under its own name or trademark. An organisation can have different roles for different systems, so do not copy one label across the whole inventory.
Record the contracting supplier, the product, relevant model or service providers, hosting and the internal team that controls the use. Link the instructions for use, contract owner and technical contact. Treat the role field as a reasoned working position that an authorised legal or compliance owner confirms. A vendor questionnaire and an AI-generated answer cannot settle the role on their own.
Show what the output can change for a person
The most useful field is often the one procurement forms omit: what can happen to a person because of this output? State whether the system provides information, drafts content, recommends an action, ranks people or triggers an action automatically. Identify workers, candidates, patients, customers or other groups who may be affected, including people who never operate the tool themselves.
Write the decision boundary in plain language. For a worker hotline, AI may collect an absence report and route it, but an authorised person decides whether the absence is accepted and what follows. For healthcare administration, AI may offer an approved appointment slot, but it does not diagnose, assess urgency or decide access to care. These boundaries make the intended purpose testable.
Map data, interfaces and retention
List the main input categories, their source, the output, recipients and destination systems. Mark personal data, special-category data and confidential business information. Record where information is stored, the approved retention approach, any international transfer path and which roles can see raw inputs, generated output, logs and corrections.
Do not turn the inventory into a second privacy register. Cross-reference the relevant processing record, DPIA, security review and data-flow diagram instead. The AI entry should still expose missing links. If nobody can identify the source of employee data, the deletion route or the destination of a generated summary, the use case is not ready for a confident review.
Attach controls and evidence, not reassuring labels
A field marked human oversight has little value unless it explains who reviews what, when they can intervene and how they are trained. Record the actual controls: user notice, approved instructions, access restrictions, test results, monitoring, fallback, incident route, correction process and safe shutdown. Link to evidence and name its owner and version.
Separate designed, tested and operating. A control described in a policy may not exist in production. A control seen in a demo may not work after an integration fails or the supplier changes a model. The inventory should make that gap visible without pretending that a green status replaces evidence.
Triage the review without outsourcing judgement to AI
Use the register to route work. A first screen can ask whether the item is an AI system, which role the organisation holds, whether it interacts directly with people, whether it influences employment, healthcare, credit or another sensitive area, and which privacy or sector rules also apply. The European Commission notes that AI Act classification depends on intended purpose and the way the system is used.
Software can collect answers, flag blanks and compare dates. It should not approve its own legal classification, decide that a use is low risk, choose a lawful basis, waive a DPIA or declare human oversight adequate. Those decisions belong to named people with access to the real workflow, contracts, technical evidence and specialist advice.
Give every entry an owner and a reason to reopen it
At minimum, keep the accountable business owner, technical owner, review owner, last review, next review and open actions. Define triggers for an earlier review: a new purpose, model, supplier, data source, integration, language, country, affected group or automated action. A material incident or repeated human correction should also return the entry to review.
Close each review with an operational decision such as keep in scope, fix by a named date, restrict, pause or retire. Then record who accepted the remaining risk and what evidence supported the decision. The inventory is useful only while it reflects the system people are using today, not the version described at procurement.
FAQ
Does every organisation need an AI system inventory under the EU AI Act?
The AI Act does not impose one universal inventory template on every organisation. Duties depend on the system, intended purpose and the organisation's role. A maintained inventory is a practical governance control that helps find relevant uses, assign owners and determine which legal or operational review each one needs.
Should everyday copilots and AI features inside existing software be included?
Include them when they are used professionally and can process organisational data, affect people or shape business work. Record the specific use rather than every possible feature. A disabled feature can be marked out of scope; an active pilot or unapproved use needs an owner and review status.
Can a supplier questionnaire replace the internal AI inventory?
No. Supplier material describes the product and its intended configuration. Your organisation must also record its actual purpose, users, affected people, data, integrations, human decisions and local controls. Cross-reference the supplier evidence instead of copying it as the whole entry.