Operational guide
How to Build an AI System Inventory for EU AI Act Readiness
An AI system inventory for EU AI Act readiness is a controlled register of systems and use cases containing the facts needed for role, classification, requirement, and evidence analysis. It links intended purpose and actual use to organisational activity, provider, users, affected people, data, outputs, geography, modifications, ownership, analysis status, and change history.
Direct answer
The readiness inventory is a factual population, not a classification spreadsheet
The inventory should let a qualified reviewer understand what the system is, how the organisation interacts with it, why and where it is used, who is affected, and which facts remain uncertain. Role and classification conclusions should link to the record but remain separately approved analyses. Vendor labels and product categories are not substitutes for the organisation's actual circumstances.
A broader EU AI Act readiness assessment tests how this practice fits the organization's wider ownership, control, and evidence baseline.
This page focuses on the EU-readiness data layer. The enterprise AI inventory pillar covers the broader management system; the inventory-template guide covers general record design; the readiness checklist covers the programme that consumes the data. This separation keeps a regulatory view from replacing the operational inventory the organisation needs for risk and governance.
Data model
Add regulatory analysis fields to the enterprise record
Do not build a second disconnected list for legal or compliance teams. Extend or link the authoritative enterprise inventory with fields needed for EU analysis. Preserve stable system, product, component, and use-case identifiers so role, classification, supplier, risk, control, and evidence records can be joined without copying every detail.
Assign field ownership according to expertise. Business owners validate purpose, users, affected process, and continued use; technical owners validate architecture, models, integrations, and versions; procurement validates supplier and contract facts; legal or compliance authority owns approved role and classification conclusions. A central inventory steward governs definitions and quality but should not guess specialist answers simply to complete the record.
Use controlled statuses for factual validation and legal analysis. “Candidate,” “facts incomplete,” “awaiting supplier evidence,” “analysis in review,” “approved,” and “reassessment required” describe different states and should not collapse into red, amber, or green. This lets programme teams route work correctly and prevents an unanswered legal question from being mistaken for a negative classification.
Enterprise and EU-readiness fields belong in one connected model
| Field group | Enterprise inventory context | EU-readiness extension |
|---|---|---|
| Purpose and use | Business purpose, users, process, outputs, dependency | Intended purpose, actual use, affected people, deployment geography, transparency context |
| System and supplier | Product, provider, models, integrations, contract, technical owner | Relevant economic operator facts, instructions, placing-on-market or use context, modifications, supplier evidence status |
| Decision context | Autonomy, human involvement, affected decisions, business impact | Facts relevant to prohibited-practice screening, high-risk analysis, transparency, and role-dependent requirements |
| Governance status | Risk, approval, controls, exceptions, monitoring, incidents | Role conclusion, classification conclusion, legal owner, source version, requirements mapping, open questions |
| Change and evidence | Versions, changes, source records, review date, retirement | Change triggers for intended purpose, substantial modification questions, role, classification, and regulatory evidence |
The extension should capture facts and analysis status, not ask ordinary inventory users to make unsupported legal determinations.
Use the general AI system inventory template for identity, ownership, relationships, and lifecycle fields; add only the EU-specific facts and links needed by the readiness process.
Analysis inputs
Record activities and intended purpose before assigning labels
Role analysis needs facts about development, commissioning, branding, market placement, import, distribution, deployment under the organisation's authority, modifications, and changes to intended purpose. Classification analysis needs the actual purpose, affected process and people, output or decision, context of use, and relevant system characteristics. The data owner can gather facts; appropriately qualified authority should approve conclusions.
The authoritative legal starting point is Regulation (EU) 2024/1689. The inventory should record which source and interpretation version supported each approved analysis and avoid presenting this operational guide as legal advice.
Inventory control
Validate facts, supplier evidence, and material changes
Quality review for an EU-readiness inventory entry
- 01
Confirm record boundaries
Separate product, system, model or component, and materially different use cases; preserve stable links.
- 02
Validate intended and actual use
Record purpose, users, affected people, process, outputs, human involvement, geography, autonomy, and dependency.
- 03
Document organisational activities
Capture development, commissioning, branding, placing, importing, distributing, using, modifying, and purpose changes as relevant.
- 04
Link approved analyses
Reference role, prohibited-practice screening, classification, transparency, GPAI dependency, and requirement records without embedding legal conclusions in free text.
- 05
Track supplier evidence
Record instructions, technical and contractual material, change notices, incidents, missing information, owners, and restrictions.
- 06
Apply change triggers
Reopen affected analyses after changes to purpose, model, data, features, integration, autonomy, geography, supplier, or organisational activity.
The reviewer should be able to see which facts are validated, which conclusions are approved, and which decisions remain blocked.
Reconcile the readiness population against independent enterprise sources. Procurement and contracts find purchased services; identity and SaaS systems find accounts; architecture and model platforms find managed deployments; vendor management finds enabled features and change notices; business validation finds local use and purpose. Report source coverage and unresolved candidates so completeness of analysed records is not mistaken for completeness of the population.
Preserve analysis history rather than overwriting the latest answer. A reviewer should be able to see which purpose, role facts, source version, supplier material, and system configuration supported an earlier conclusion and what change caused it to reopen. That history is particularly valuable when products evolve through embedded features while retaining the same commercial name.
Programme use
Use the inventory to allocate work—not declare compliance
Portfolio reporting should show systems awaiting validation, open role and classification questions, missing supplier evidence, requirements without owners, overdue controls, and material changes awaiting review. It should also show the source coverage used to find systems. A clean status chart with an incomplete population is not readiness.
The next operational step is the EU AI Act readiness checklist, which turns inventory facts and approved analyses into requirements, controls, evidence, supplier actions, and management reporting.
For the classification decision itself, use the EU AI Act risk-classification guide. Keeping the inventory factual reduces both legal overstatement and cannibalisation with that specialist page.
FAQ
Frequently asked questions
What EU AI Act fields should an AI inventory include?
Include intended and actual purpose, users, affected people, geography, provider and supplier, organisational activities, modifications, output and decision context, human involvement, role and classification analysis status, source version, requirements mapping, evidence gaps, and change triggers.
Should one AI product have several inventory entries?
Yes when it supports materially different use cases, purposes, affected people, data, decisions, locations, or organisational activities. Link those use cases to one product or system record to preserve shared supplier and technical facts.
Can the inventory determine whether an organisation is a provider or deployer?
The inventory gathers and validates relevant activities and evidence. The role conclusion should be approved separately by appropriately qualified authority using the current law and system-specific facts.
How should general-purpose AI dependencies be recorded?
Link the general-purpose model or service to the systems and use cases that depend on it, including provider, version where known, integration, intended use, supplier evidence, change notices, contractual terms, and open requirement questions.
What should happen when supplier information is missing?
Record the missing item, affected analysis, supplier and internal owner, due date, escalation, interim restriction or compensating control, and the decision that remains blocked. Do not silently infer a favourable status.
What changes should reopen EU AI Act analysis?
Changes to intended purpose, actual use, users, affected people, model, data, features, integration, autonomy, geography, supplier, branding, modification, or organisational activity can reopen role, classification, requirement, and control analysis.
Is an EU AI Act inventory separate from the enterprise AI inventory?
It should normally be an extension or connected view, not a disconnected list. Enterprise identity, ownership, lifecycle, risk, and evidence remain authoritative; EU-readiness fields add the facts and analysis links required for regulatory work.