AI system inventory: the foundation of all governance

Why do you need an AI system inventory?

An AI system inventory is the first — and non-optional — step for any organisation that wants to comply with the EU AI Act. Without it, it is impossible to know which systems need to be classified, which are high-risk, who is responsible for each, or which regulatory obligations apply.

Article 60 of the EU AI Act establishes a European database where providers and deployers must register their high-risk AI systems before putting them into service. To register in that database, you first need a complete internal inventory.

Beyond regulatory compliance, the inventory has immediate organisational value: it provides visibility over shadow AI — the AI systems that employees or departments use without the knowledge or authorisation of the AI Committee — enables clear ownership assignment for each system, and facilitates decisions about which systems to maintain, update or retire.

ISO 42001 also requires an inventory as the starting point of the management system (controls A.8 and A.6): without knowing what systems exist and what they do, it is impossible to assess their impact or establish appropriate controls.

What to register for each AI system

The minimum information each inventory entry should capture includes:

• Unique identifier: an internal code or ID that allows the system to be referenced across all compliance documentation.
• Name and description: functional name and description of what it does, what problem it solves and in what context it operates.
• Purpose and use cases: exactly what it is used for, what decisions it automates or supports, what business processes it is involved in.
• Internal owner: the person or role within the organisation accountable for managing the system. Essential for deployer obligations under the EU AI Act.
• Provider or developer: whether it is a third-party system (SaaS, API) or internally developed. For third-party systems, include the provider's name and contract details.
• Personal data processed: whether the system processes personal data, which categories, and on what legal basis (direct connection to GDPR).
• EU AI Act risk level: prohibited, high, limited or minimal. Include the justification and whether Annex III has been formally checked.
• Deployment status: in production, in testing/pilot, in development, retired.
• Registration and last review dates: to manage mandatory periodic review cycles.
• Business area: department or area that owns the system.

For systems classified as high-risk, the inventory must be supplemented with the complete technical documentation of Annex IV of the EU AI Act: general description, capabilities and limitations, training data, development methodology, performance metrics and human oversight measures.

How to build the inventory: step by step

1. Discovery phase

The biggest challenge is not documenting known systems, but discovering those that nobody has catalogued. The discovery phase should include:

• Review of software vendor contracts: are there AI or machine learning clauses?
• Department survey: what tools do they use that include AI features?
• Review of active SaaS subscriptions: many productivity tools (Copilot, Notion AI, Salesforce Einstein) include AI without teams identifying it as such.
• Interviews with technical leads: are there internally developed ML models or scripts?

2. Stakeholder interviews

For each identified system, the interview with the area owner aims to capture the real purpose of use, the data it handles, who makes final decisions and whether there is effective human oversight of the system's outputs.

3. Technical audit

For internally developed or infrastructure-integrated systems, the technical audit verifies which models are used, what training data was employed, which versions are in production and whether activity logs exist.

4. Continuous monitoring

The inventory is not a one-off project: it is a continuous process. AI systems are constantly added, updated and retired. The onboarding process for new systems must be integrated into the software acquisition cycle and the internal development process.

Common mistakes when building the inventory

• Incomplete scope: limiting the inventory to internally developed systems and ignoring SaaS tools with embedded AI. Most AI in enterprise use today is third-party AI contracted as a service.
• No owner assigned: registering systems without a clear owner makes the inventory inoperative for compliance. Each system needs an accountable person.
• Static snapshot: treating the inventory as a project that closes rather than a living process. Without an update process, the inventory becomes outdated within weeks.
• Under-documenting data: not recording what personal data each system processes makes it impossible to connect the inventory with GDPR obligations and the records of processing activities.
• Optimistic classification: assuming a system is minimal risk without formally checking Annex III. The formal verification of all 8 Annex III domains must be documented for each system.

How Kaitalog automates the inventory

Kaitalog provides three mechanisms to build and maintain the inventory on a continuous basis:

• Conversational registration agent: any employee can declare an AI system by answering questions in natural language. The agent extracts structured metadata and generates a draft ready for Committee validation. No long forms, no friction.
• CSV/API import: for organisations with partial inventories in spreadsheets or CMDB systems, Kaitalog enables bulk import and completing missing information.
• Automated review cycles: Kaitalog notifies owners when a system is due for review, automatically updating the inventory status and generating an auditable change history.