What Is an AI System Inventory?

An organisation may need records for products, internally developed systems, embedded AI features, general-purpose models, model versions, APIs, agents, and business use cases. Those objects should be linked, not forced into one category. The governed use case is often the most important unit because purpose, users, data, outputs, affected people, autonomy, controls, and consequences live there.

Authoritative does not mean that every fact originates in one database. It means the organisation has defined which source owns each field, how records are linked, who validates business context, and how conflicts are resolved. The inventory can reference a CMDB for application identity, a model registry for versions, a data catalog for datasets, and a supplier register for contracts while remaining the authoritative view of governed AI use.

The inventory also needs a clear threshold for material use. Recording every statistical feature or dormant licence can make the population impossible to govern, while narrow inclusion rules hide embedded AI and employee tools. Use candidate status for uncertain capabilities, document exclusion criteria, and require an accountable reviewer to decide whether the feature or use needs a governed record.

The detailed boundary with technical model records is covered in AI inventory versus model registry.

Some teams use terms such as AI bill of materials or AIBOM for a technical inventory of models, libraries, data dependencies, and components. That information can improve provenance and security analysis, but it does not replace the business-use record. A bill of materials explains what a system contains; the enterprise inventory explains why it operates, who is accountable, what decisions it affects, and which governance applies.

Registration should be triggered by procurement, architecture, development, model release, access, vendor-feature enablement, integration, incident, and retirement workflows. Independent reconciliation tests whether those triggers work. Owner attestations can validate purpose and use but should not be the only discovery method, because people cannot attest to systems they do not know exist.

Risk assessment, EU AI Act readiness, supplier oversight, human-oversight design, control testing, incident response, audit, and board reporting all depend on knowing which systems and uses exist. The inventory does not perform those analyses; it connects each one to the correct object, owner, version, and decision history.

Leadership reporting should distinguish discovery coverage from record completeness. Coverage asks whether independent sources suggest unknown AI use; completeness asks whether validated entries contain the facts and decisions required for their status. A portfolio can score highly on owner completion while still omitting material systems. Showing both measures keeps unknown exposure visible and gives management a concrete reason to improve discovery or validation.

An inventory should also support retirement. Closing a record requires confirmation that access and integrations were removed, dependent processes were addressed, required data or evidence was retained, monitoring ended appropriately, and supplier obligations were resolved. Preserve the closed record and rationale so future discovery does not recreate the same uncertainty or mistake a historical system for an active one.

To implement the record, continue to the AI system inventory template. To find uses outside known systems, use the shadow AI detection guide. For regulatory extensions, use the EU AI Act inventory guide.

The parent enterprise AI inventory guide should remain the principal page for organisation-wide implementation, ownership, governance, and assessment decisions.