The AI Inventory Every Organization Needs

An organization can claim to have an artificial intelligence inventory and still be unable to say which business teams use embedded copilots, which external models process sensitive information, or which experiments have quietly moved into production. The problem is rarely the absence of a spreadsheet. It is that the inventory was designed as an administrative list rather than a governance control.

A useful AI inventory should answer operational questions: What AI system or use case exists? What is it for? Who is accountable? How risky is it? Which data, vendors, and models does it depend on? Where is it in the lifecycle? What evidence shows that it remains authorized and controlled? Its value is not the number of rows. Its value is a governable view of the organization’s AI portfolio.

Inventory the use in context, not just the model

Many inventories start with model names: an internally developed algorithm, a machine-learning model, or a purchased foundation model. That is not enough. The same underlying model might summarize internal documents, prioritize sales leads, or power an agent that can execute transactions. The risk changes with the context of use.

A practical unit of record is therefore the AI system or governed use case in a defined context, linked to shared components where needed. A foundation model can appear as a dependency across several entries, while each use case retains its own purpose, users, data, controls, and risk exposure.

The voluntary NIST AI RMF Playbook makes inventory a specific governance outcome in GOVERN 1.6: mechanisms should be in place to inventory AI systems and resource them according to organizational risk priorities. NIST describes an AI inventory as an organized database of system- or model-related artifacts that can support both single-system questions and portfolio-level questions. Its Generative AI Profile goes further by addressing generative AI embedded in application software and suggesting that any inventory exemptions be defined in policy.

As of September 2026, NIST still identifies AI RMF 1.0 as the current published framework while a revision is underway. That is another reason to design the inventory around durable governance information rather than around one regulatory taxonomy or one generation of technology.

Minimum fields should connect purpose, accountability, and risk

There is no universal number of fields. But a register that captures too little information cannot drive approvals, reviews, monitoring, or audit coverage. A minimum viable design can be organized into four groups.

Group	Core fields	Why they matter	Examples
Identity and purpose	unique ID, use-case name, business process, objective, AI capability	Prevents duplication and links technology to a business need	recommendation, prediction, GenAI, RAG, agent
Accountability	business owner, technical owner, users, oversight function	Shows who decides, operates, fixes, and accepts risk	Sales, IT, Risk, AI committee
Risk and dependencies	criticality, data used, vendor/model, third parties, impact on people or decisions	Determines the intensity of controls and review	personal data, external model, automated decision
Lifecycle and evidence	status, version, approval date, last assessment, next review, incidents/changes, documentation links	Keeps the record current and traceable	pilot, production, suspended, retired

The IIA’s Artificial Intelligence Auditing Framework, 2nd Edition advises organizations and internal auditors to capture current and planned AI uses and to understand elements such as the AI objective, who uses and manages it, the tools involved, risk considerations, and oversight. For internal audit, these fields also turn the inventory into a practical input to risk assessment and assurance planning.

ISO/IEC 42001:2023 does not reduce AI governance to a centralized register either. The standard addresses assigned responsibilities, risk management, documented information, and relevant resources across the AI lifecycle. A well-designed inventory can operationalize those requirements and controls, but it does not replace the AI management system or evidence that controls are operating. The official ISO page for ISO/IEC 42001 confirms that the standard covers establishing, implementing, maintaining, and continually improving an AI management system.

Classification should change the control path

A risk label is useful only if it changes what happens next. If “high,” “medium,” and “low” risk systems all follow the same approval and monitoring process, the classification is decorative.

A simple starting point is to classify each use case across four dimensions: impact of the use, sensitivity of the data, degree of autonomy or influence over decisions, and third-party dependency. The resulting criticality tier can then determine who approves the use, which risk assessment is required, what evidence must be retained, how often the system is reviewed, and which changes trigger revalidation.

COSO’s 2026 publication Achieving Effective Internal Control Over Generative AI uses this same operating logic. Its implementation roadmap starts by establishing governance and then inventories GenAI use cases. It calls for owners and attributes such as objectives, data sources, models, deployment approach, criticality, dependencies, versions, and change history before moving into risk assessment, control design, and monitoring.

A mature inventory does not merely describe what AI exists. It determines which governance path applies to each use.

Lifecycle status should be controlled, not free text

“Active” and “inactive” are too crude for AI governance. Important decisions occur between an idea and a retired system, and the inventory should make those transitions visible.

A workable lifecycle taxonomy might include proposed, under assessment, pilot, approved for production, in production, restricted or suspended, and retired. Each transition should correspond to evidence: an approval, completed testing, a model or configuration change, expansion into a new context, a significant incident, or a decommissioning decision.

This is especially important for third-party AI. A provider may update an underlying model while the product name remains unchanged. A copilot may gain agentic features. A trial may become standard operating practice without a formal go-live decision. The inventory therefore needs to capture version, access mode, dependencies, and material changes, not simply the commercial tool name.

Retirement deserves the same discipline. A system marked as retired may still have credentials, data stores, integrations, or active users. Closing an inventory entry should be tied to evidence that relevant access and dependencies have actually been removed or transferred.

Completeness cannot be proven by asking once

The most common weakness in AI inventories is overreliance on management surveys. Surveys are useful, but they assume people recognize what qualifies as AI, know which capabilities are embedded in their software, and choose to disclose experimental use.

Completeness should be tested through reconciliation across independent sources. A fundamental approach can cross-check at least five signals:

Procurement and vendor management: contracts, renewals, and services that include models, copilots, APIs, or AI-enabled functionality.
SaaS, SSO, and application catalogs: tools available to users even when no formal AI project exists.
Expense and corporate-card data: subscriptions or API credits purchased outside centralized procurement.
Cloud and technical repositories: model endpoints, machine-learning services, AI libraries, agents, and data-science projects.
Process owners and surveys: business context that technical sources cannot reveal, including manual and experimental uses.

COSO explicitly recommends periodic scans or surveys to detect shadow AI. The IIA likewise warns that discovery should not stop with IT or the data-science team because departments and individual users may be applying AI independently.

For internal audit, the objective is not to prove that absolutely nothing is missing in a fast-changing environment. It is to assess whether management has designed a reasonable, repeatable process to discover new uses, investigate differences among sources, and update the register promptly. The Global Internal Audit Standards provide the broader professional basis for evaluating governance, risk management, and control; an AI inventory can become one of the key information sources for determining where exposure exists and where assurance coverage is needed.

Make the inventory a workflow, not an annual file

The strongest operating model is one in which the inventory updates by design. A purchase request creates or changes an entry. A new AI project must be registered before pilot. Production approval changes lifecycle status and activates control requirements. A material change triggers risk reassessment. An incident updates the record and may suspend the system. Retirement closes the lifecycle.

In that model, the inventory becomes the connecting layer across governance, risk, compliance, security, privacy, third-party management, and audit. It also enables portfolio questions that a spreadsheet assembled once a year cannot answer well: Where is risk concentrated? Which vendors are critical? Which uses have not been reviewed recently? Which systems depend on the same foundation model?

Internal audit can help management establish an initial baseline and can test the design and completeness of the process, particularly in less mature organizations. But the inventory should ultimately operate as a management control. If it lives only in audit workpapers, it will not govern day-to-day AI use.

A simple test reveals whether the inventory is working: when a new vulnerability, vendor issue, or regulatory requirement emerges, can the organization quickly identify which AI uses are affected, who owns them, and which evidence needs to be reviewed? If the answer requires another round of emails and spreadsheets, the organization does not yet have an operational AI inventory.