AI governance foundation
AI system inventory template for EU AI Act readiness
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
What 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
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.
| 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