An AI model inventory is a maintained register of every AI system an organisation runs, with an owner, a purpose, a classification and a date it was last confirmed. This template is that register as a sheet: one row per AI system, with the fields an EU AI Act or SR 11-7 / SR 26-2-style register needs — purpose, type, owner, data, oversight, classification, status — plus two columns most templates leave out: who last confirmed each entry, and when. Three sample rows show what a filled-in line looks like.
Columns 1–17 are, header for header, the CSV import format of Model Inventory for Jira. Only Model Name is required; every other cell may stay empty and the row still imports. Where a column has a fixed list of values, the import rejects anything outside it — the Excel version enforces the same lists with dropdowns. The last three columns are for the spreadsheet stage and are set in the app after import. Obligation references follow the 24-field guide; this page does not add any.
| # | Column | Req. | Allowed values | Why it exists / what it serves |
|---|---|---|---|---|
| 1 | Model Name | yes | free text | The one column the import refuses to skip. A name a colleague would recognise, not a project codename. (Annex VIII identification, SR 11-7) |
| 2 | Model ID | no | free text, e.g. SYS-001 | Your own stable identifier. Survives renames; the thing you cite in incident reports and audit findings. |
| 3 | AI System Type | no | ML Model · GenAI · LLM · Agentic AI · Rule-based · Hybrid · Statistical | Failure modes and oversight differ by type. Annex VIII asks for operating logic; SR 11-7 / SR 26-2 for design and methodology. |
| 4 | Intended Purpose | no | free text | What the system does and for whom. Every classification decision starts here (Annex VIII intended purpose, Art. 9). |
| 5 | Business Unit | no | free text | Portfolio reporting: how many systems per unit, which unit owns the riskiest ones. |
| 6 | Vendor / Provider | no | free text; empty = built in-house | Sets whether you are the provider or a deployer, which decides which obligations attach (Art. 26). Annex VIII provider identification. |
| 7 | Version | no | free text | Which version the assessment was made against. Change control under SR 11-7 / SR 26-2; version history under Annex IV. |
| 8 | Deployment Environment | no | Cloud · On-prem · Edge · Hybrid · SaaS (3rd party) | Where it runs. “SaaS” means your evidence comes from the vendor’s documentation, not your own logs. |
| 9 | Data Classification | no | PII · PHI · Confidential · Internal · Public | Whether personal or health data is in play (GDPR, Art. 10 data governance). |
| 10 | Data Sensitivity | no | None · Low · Medium · High · Critical | How bad a leak or a wrong output would be. Feeds risk tiering. |
| 11 | Business Impact | no | Low · Medium · High · Critical | Materiality in SR 11-7 / SR 26-2 terms. Decides review cadence and who signs off. |
| 12 | Human Oversight Level | no | Human-in-the-loop · Human-on-the-loop · Autonomous | Art. 14: who can intervene, override or stop it. “Autonomous” rows need the most evidence. |
| 13 | Model Complexity | no | Simple · Moderate · Complex · Black-box | How explainable the system is. Black-box outputs need stronger oversight and monitoring. |
| 14 | Compliance Status | no | Compliant · In Progress · Non-compliant · Not Assessed | “Not Assessed” is an honest, useful value. Board reporting groups by this column. |
| 15 | Regulatory Scope | no | EU AI Act · SR 11-7 · GDPR · ISO 42001 · NAIC · FDA · Other — several allowed, separated by ; | Which regimes apply to this system. The only multi-value column. |
| 16 | EU AI Act Category | no | Prohibited · High-risk · Limited risk · Minimal risk | The Art. 5 / Art. 6 / Art. 50 outcome. Leave empty until assessed; do not guess. The checklist walks one system through it. |
| 17 | Model Origin | no | Internal · Vendor · Open Source · Hybrid | Who built the core model. Open-source and vendor models still need a named internal owner. |
| 18 | Business Owner | no | free text (name or role) | The person who would recognise the system if called about it. SR 11-7 / SR 26-2 ownership. Set in the app after import (it maps to a Jira user there). |
| 19 | Last Attested Date | no | YYYY-MM-DD | When the owner last confirmed the row is still true. See below. |
| 20 | Attested By | no | free text (name or role) | Who confirmed it. See below. |
Shaded rows are the spreadsheet-stage columns. The Jira import ignores them rather than failing on them; in the app, owner and attestation live on the work item and its history.
Most inventory templates stop at what and who. They skip the column that decides whether the sheet can be trusted six months later: when did the owner last confirm this row is still true, and who was it?
A register is only as good as the date its owner last confirmed it. A row created in March and never touched since says nothing about September — the system may have been retired, swapped for a different vendor, or quietly pointed at a new data source. Without an attestation date, every row looks equally current, which means none of them can be relied on. With one, staleness is visible: sort by Last Attested Date and the rows that need a call rise to the top.
For high-risk AI systems this is not a nicety. The EU AI Act expects the provider to run risk management as a continuous, iterative process (Article 9) and to keep records under a quality management system (Article 17), and the deployer to monitor operation (Article 26). A dated, named confirmation on each row is the cheapest evidence that those processes exist. For everything else, the same two columns answer the auditor’s question anyway.
It is the access-recertification pattern, applied to AI. Quarterly access reviews do not ask whether an account was approved once; they ask the owner to confirm it still should exist, and record the date and the name. Do the same for each AI system. The mechanism is identical, and auditors already know how to read it.
EU AI Act Category empty and set Compliance Status to Not Assessed rather than guessing. Classification is a separate afternoon, one system at a time, and the compliance checklist is built for exactly that.Last Attested Date and Attested By for every row you personally verified, and put a reminder in the calendar for the next round — quarterly for anything high-impact, at least annually for the rest.A spreadsheet is the right tool for the first afternoon and probably the first quarter. It stops being the right tool at a fairly predictable point: somewhere past thirty rows, or as soon as more than two people edit it. After that, nobody can say who changed the classification on row 14 or when, the attestation column is overwritten instead of appended, and the sheet forks into the version on the shared drive and the version someone emailed.
At that point the fix is not a better spreadsheet. It is moving the rows into something that keeps history per entry and assigns owners who get notified — the same reason access reviews live in a system rather than in Excel. Because the columns match, the move is an import, not a rewrite.
Model Inventory for Jira reads this exact CSV. Each row becomes a work item with an owner, a status, linked reviews and Jira’s own change history behind it — nothing to re-type.
See how it worksThe EU AI Act compliance checklist takes one row through Art. 5, Art. 6 and Art. 50 and lists the obligations that attach — the value for column 16.
Open the checklistA maintained register of every AI system an organisation runs — bought, built or embedded in a vendor product — with, for each one, its purpose, owner, technology, data, oversight, regulatory scope and status, and the date its owner last confirmed the entry. It is the artefact an auditor, a regulator or an ISO/IEC 42001 assessor asks for first, because nothing else in AI governance can be checked until the list exists. A spreadsheet is a legitimate first version; the template above is one.
At minimum: a name and stable identifier, what the system is for, the type of technology, who owns it, whether it was bought or built, what data it touches, how humans oversee it, which regulations apply, its EU AI Act category once assessed, and its compliance status. Then the two columns most templates leave out: who last confirmed the entry and when. Without those, nobody can tell a current row from an abandoned one.
Yes. A system is what the business runs and what a regulator asks about: a claims triage assistant, a credit pre-screen, a chatbot. Models are components inside it: the language model behind the assistant, the scoring model behind the pre-screen. The EU AI Act attaches obligations to systems; model risk frameworks such as SR 11-7 / SR 26-2 attach them to models. This template records systems, one row each, and lets you note the models each one uses in the type, origin and vendor columns. Model Inventory for Jira treats both as work items and links them.
Set a cadence by risk rather than one date for everything: quarterly for high-risk or high-impact systems, at least annually for the rest, and on every material change regardless of cadence — a new model version, a new data source, a new use. Record the confirmation as a date and a name on the row, and treat any entry older than its cadence as unverified until its owner confirms it again.
This template is a practical starting point, not legal advice. Confirm obligations against the official text of Regulation (EU) 2024/1689 and the frameworks that apply to you.