AI governance foundation
AI System Inventory Template: Fields and Review Checklist
An AI inventory is the foundation for classification, accountability and evidence. It should cover embedded and third-party AI as well as models developed in-house.
Prepared by EU AI Fit editorial team · Published 24 August 2026 · Source review 31 August 2026 · Page updated 26 September 2026
Download the AI inventory workbook
One row per system and intended purpose, with owners, decisions, evidence and review dates. Includes a blank register, a field guide and a separate fictional example.
No email or account required. Adapt the template to your organisation and review it before use. It is a working aid, not an official form or proof of compliance.
Discuss a readiness sprintWhat belongs in the inventory?
Include customer-facing features, decision-support tools, workplace systems, experiments in production, APIs, plug-ins and material internal uses. Product names alone are not enough because the same technology can support several intended purposes.
- System and use-case name
- Intended purpose and output
- Provider, model and version
- Users and affected people
- Deployment countries and business process
Capture facts that affect exposure
Record whether the system influences employment, education, essential services, safety, biometrics or access to rights. Note personal or special-category data, direct interaction, synthetic content and the human decision process.
Use one record per intended purpose
The same model can support low-impact drafting, customer interaction and a decision affecting employment or access to a service. Separate materially different purposes so each record has a meaningful owner, role analysis, risk review and evidence trail.
- Do not treat a supplier name as the system
- Separate experimentation from approved operational use
- Record integrations and downstream decisions
- Link shared technical components without merging distinct use cases
In this scenario: Harbour Support Copilot
Harbour Utilities Ltd records a support copilot that drafts replies for trained agents. The inventory names the external model, retrieval source, customer group, human approval step, deployment countries and prohibited uses. A separate record covers the public chatbot because direct interaction, disclosure and escalation are different even though both services use the same model provider.
Keep it operational
Assign an owner and reviewer, record evidence links, and create triggers for reassessment. Material changes to purpose, model, data, users or autonomy should prompt review rather than waiting for an annual exercise.
- Named accountable owner
- Role and classification review state
- Evidence and supplier links
- Next review date
- Material-change triggers and history
In this scenario: the same model supports two different decisions
Elmbridge Services uses one model to draft customer replies and to summarise job applications. Create separate use-case records: the users, affected people, checks and consequences differ. For the reply assistant, record whether it can send messages or only suggest drafts; for recruitment, establish whether the summary filters, ranks or otherwise influences who is considered. A shared supplier record can connect them without collapsing their assessments.
Run discovery without hiding unknowns
Ask each department about purchased tools, enabled SaaS features, integrations and experiments used for work. Record the discovery source and the person who can verify it. ‘Version unknown’ is an action for the technical owner, not a reason to leave the field looking complete. Reconcile the inventory with procurement and approved-use records, then review material changes rather than starting a disconnected spreadsheet every year.
AI system inventory field guide
Treat each materially different intended purpose as a record. A product or model may appear more than once when it supports different decisions, users or affected groups.
Download editable worksheet (CSV)No email or account required. Includes response, evidence, owner, review and follow-up columns for your team. This is a working aid, not an official form or proof of compliance.
On smaller screens, scroll the table horizontally or download the worksheet.
| Inventory field | What to record | Why it matters |
|---|---|---|
| System and use-case name | A recognisable product name plus the specific business use | Prevents several materially different uses being hidden under one supplier name |
| Intended purpose and output | What the system is designed to do, the output it produces and the decision it informs | Role, classification and controls depend on purpose and decision influence |
| Value chain | Provider, model, integrator, reseller, contract owner and relevant versions | Shows where information and responsibilities must pass between operators |
| People and geography | Users, affected people, vulnerable groups and countries where the system or output is used | Supports scope, rights, disclosure and deployment analysis |
| Data and autonomy | Material input data, personal-data context, automated actions and human intervention points | Surfaces privacy, fairness, reliability and oversight questions |
| Ownership and status | Accountable owner, technical contact, approval state, open actions and linked evidence | Turns discovery into controlled work rather than an unmanaged list |
| Review triggers | Next review date and changes to purpose, model, data, users, autonomy, supplier or geography | Keeps the record current throughout the system lifecycle |
Questions teams usually ask
What counts as an AI system for an inventory?
Use the current legal definition and record systems the organisation builds, buys, embeds or uses professionally. Include AI introduced through SaaS features, APIs and operational experiments, not only internally developed models.
Should the inventory list products or individual use cases?
Record the use case as well as the product. The same product can support different purposes with different affected people, operator roles, risk pathways and controls.
How often should an AI inventory be reviewed?
Use a scheduled review plus event-driven triggers. Changes to purpose, model, data, users, autonomy, supplier or deployment context should prompt reassessment before the next annual review.
Recommended next step
Begin with the systems that affect customers or people, then run a discovery exercise with product, engineering, HR, procurement and security.
Run the free exposure checkRelated practical guides
Put the guidance into practice