An AI system inventory is a working record of what an organisation develops, supplies or uses. For an EU AI Act review, its most useful field is the intended purpose: what the system is designed to do, for whom and in which context. A list of vendor names or subscriptions cannot answer that question. The inventory should also identify the responsible people, the model or service dependencies, the affected groups and the evidence supporting the description.
The inventory is a starting point for classification and governance. It does not by itself show that a system complies with the Act.
Define the unit of inventory
Record the AI system or use case, not merely every model API or every software licence. One model may power several applications with different intended purposes. Conversely, a single application may use several model components. A recruitment screening workflow and a customer-support assistant therefore deserve separate entries even if both use the same general-purpose model.
Give each entry a stable identifier and version. Describe what the system receives, what it produces and how its output influences a human or automated decision. If the purpose changes materially, retain the old record and open a new review rather than overwriting the reasoning.
Capture the minimum useful fields
| Field | What to record | Why it matters |
|---|---|---|
| System and version | Product, workflow, release and owner | Links decisions to the deployed configuration |
| Intended purpose | Specific task, users and expected outcome | Supports the risk-category assessment |
| Use context | Geography, affected groups and consequence of output | Distinguishes a general feature from its actual deployment |
| Actors | Provider, deployer, supplier, importer or distributor where relevant | Points to the appropriate role guidance |
| Model dependencies | Underlying model, supplier and integration | Separates general-purpose model questions from system duties |
| Human involvement | Who reviews, overrides or acts on output | Makes oversight assumptions testable |
| Evidence | Instructions, design documents, contracts and test records | Supports the classification rationale |
| Review owner and date | Named reviewer, decision and next trigger | Keeps the assessment current |
Do not collect unnecessary personal data in the inventory. Link to controlled evidence rather than copying sensitive datasets into a broad-access spreadsheet.
Ask the legal questions in a consistent order
First, check whether the use raises a question under Article 5 prohibited practices. Then assess whether Article 6 and Annex I or III may classify the system as high-risk. Review the specific Article 50 transparency situations separately. If your organisation provides a general-purpose AI model, open a separate Chapter V review. Record both the conclusion and the precise provision examined. “Low risk” without a stated reason is not an assessment.
This order is a practical workflow, not a legal hierarchy that displaces other applicable rules. Data protection, employment, product safety, consumer and sector requirements may also apply. A system can have more than one relevant AI Act workstream.
Example: one supplier, two distinct uses
Suppose a company uses a model provider’s service for an internal writing assistant and also integrates it into a tool that ranks job applicants. The provider of the underlying model has its own model-related obligations. The organisation’s applicant-ranking product has a distinct intended purpose and requires an assessment against the employment use cases in Annex III. The employer using the tool may have deployer duties. The writing assistant should not inherit the recruitment classification simply because it uses the same model.
The inventory should therefore contain separate system entries, a linked model dependency, and a clear description of the provider and deployer for each deployment. The final classification still depends on the actual functions and the legal conditions in Article 6.
Assign ownership and a change trigger
Name a person who can obtain accurate information about the system and a reviewer who can challenge the classification. Define triggers for reassessment: a changed intended purpose, new affected population, new model or feature, different geography, substantial modification, incident or updated official guidance. Keep previous decisions so the reasoning can be reconstructed.
A review register can include four states: information needed, under assessment, decision recorded and scheduled for reassessment. Treat unresolved legal questions as open items rather than marking an entry compliant. The governance planning checklist can turn the inventory into assigned work; the timeline helps attach an application date to each relevant provision.
Keep the source trail current
Use the consolidated AI Act text and the Commission’s AI Act overview to verify current rules. A saved link, date checked and short reasoning note are more useful than a bare category label. Seek qualified advice where a classification or release decision depends on a contested interpretation.