AI system inventory template: the 18 fields
Identifying AI risks starts with a list of the AI systems in use. Most organisations do not have one, and the systems they forget are the ones nobody has assessed. This template gives the 18 fields to record for each system and why each is there.
| # | Field | What to record | Why it is there |
|---|---|---|---|
| 1 | System | Name, business function and components; a unique, persistent system ID | Lists each system once; the ID links to the register, the impact assessments and the logs |
| 2 | Vendor or built | Built, bought, or bought and configured; supplier and contract; any model provider behind the product | Who holds the documentation (AI Act Articles 13, 25(4)) |
| 3 | Model and version | Model name, version identifier, date of the last change notice, whether the version can be pinned | A vendor can change the model without telling you |
| 4 | Purpose | The intended purpose as the provider states it, and the purpose in use | Use outside the intended purpose changes the risk and can change your role |
| 5 | Users | Who operates the system or acts on its output, by role and number | AI literacy and human oversight (Articles 4, 26(2)) |
| 6 | Persons affected | People whose money, access, rights or health the output affects, including those unaware of the system; children and vulnerable groups flagged | The fundamental rights impact assessment (Article 27(1)(c)) |
| 7 | Data | Training sources if built; production inputs; personal and special-category data; where data is sent and kept | Data governance and the DPIA (Articles 10, 26(4)) |
| 8 | Role under the Act | Provider, deployer or both; the ISO/IEC 42001 role; the Article 25 check | Your duties depend on your role (Articles 3, 25) |
| 9 | Classification | The Article 6 outcome and a reference to the record, with the Article 5 screen and any Article 50 duty | Prohibited, high-risk, transparency only or minimal (Articles 5, 6, 49, 50) |
| 10 | Owner | One named person accountable, with the model owner and data owner | Every risk needs an owner |
| 11 | Stage | One of the seven lifecycle stages | Pilots that quietly become production |
| 12 | Jurisdictions | Where it is used and where the affected persons are | Which rules apply |
| 13 | Period and frequency of use | How long and how often it is used | The fundamental rights impact assessment (Article 27(1)(b)) |
| 14 | Impact assessments | DPIA, fundamental rights impact assessment and ISO/IEC 42005-style assessment: reference, date, next due | Articles 26(9) and 27; ISO/IEC 42001 Annex A |
| 15 | Last risk assessment | The date, and the version assessed | The quarterly version check |
| 16 | Discovery source | Declared, procurement, scan, audit or incident | Measures how much shadow AI you are finding |
| 17 | Pilot end date | The date by which the pilot closes or goes through the deployment gate | Stops pilots running unassessed |
| 18 | Logs | Where they are kept and for how long | Record-keeping and log retention (Articles 12, 26(6)) |
Fields 1 to 11 are the inventory of Chapter 5 of the book; fields 12 to 18 are what later chapters rely on. The workbook has the same fields as a sheet ready to fill in.
What the inventory feeds
Each line of the inventory decides what comes next. The role and the classification decide which duties of the AI Act apply (see EU AI Act obligations by role and date). The persons affected and the period of use feed the fundamental rights impact assessment. The system's purpose and data decide which lines of the AI risk register apply to it. For a bank or an insurer, a bought AI service is also an ICT service, and the same supplier details serve DORA's register of information.
Questions about AI inventories
What is an AI inventory?
A list of the AI systems an organisation builds, buys and uses, one line per system, with what each does, who uses it, whom it affects, its role and class under the AI Act, and an owner. It is the starting point for identifying AI risks, because a system nobody has listed is a system nobody has assessed.
Does the EU AI Act require an AI inventory?
Not in those words. But you cannot work out your role (Article 25), classify your systems (Article 6), meet the deployer duties of Article 26 or decide which systems need a fundamental rights impact assessment (Article 27) without knowing which systems you run. Financial entities must also keep a register of information on their ICT third-party arrangements under DORA (Article 28(3)), and AI services bought as ICT services belong in it.
How do you find AI that nobody declared?
Look beyond what teams declare: procurement and expense records, software contracts with AI features added, sign-ons to AI services, and incidents. Record where each system was found, so you can see how much was undeclared. Register line OPS-07 covers shadow AI.
The template in Excel
The free workbook holds the inventory sheet, the use-case template, the register with its scoring formulas and the FRIA mapping, all linked by the same fields.
Get the inventory template and the book
Your files are ready. The links are personal to your email address and work for 7 days. A copy is on its way to your inbox.
Start with Chapter 1, then Appendix A for the register. Questions about the method are welcome at rory@eonriskservices.com.