The AI Inventory: You Cannot Govern What You Have Not Listed

An AI inventory should help the company answer a practical question: where is AI affecting this business process, who owns the use and what evidence supports its operating boundary?

A list of subscriptions is not enough. Embedded features, experiments and integrations can affect the workflow without appearing as a stand-alone AI purchase. An inventory needs a discovery and maintenance process, not just a schema.

The existing AI inventory governance guide covers the broad design. This article provides a reconciliation drill for testing whether the register matches one real process.

Key takeaways

• Inventory the use in context, not only the model or vendor.

• Include embedded, experimental and connected uses within defined scope.

• Record owner, data, decision impact and evidence references.

• Reconcile the register against operating evidence with appropriate access.

• Treat missing ownership and stale records as actionable gaps.

Step 1: Choose one material process

Start with a business process where AI could affect customers, staff or important decisions. Define the boundary and ask the process owner to describe how work actually moves through tools and people.

Use authorized discovery sources such as approved procurement records, architecture records and staff input. Do not turn the exercise into covert surveillance or collect unrelated personal activity. Security, privacy and employment rules still apply to inventory work.

NIST's Govern Playbook describes inventory mechanisms, ownership and defined attributes. It also notes that partial inventories may not provide the value of a full view. A bounded drill tests the process without pretending the whole enterprise has been covered.

Step 2: Define a minimum record

This illustrative schema describes fields for a governance record. It is not an actual company inventory or a mandated regulatory form.

Field	What to record	Why it affects a decision
System and use	Tool, model or embedded feature, version where relevant, and business purpose.	Distinguishes uses that share a vendor but have different consequences.
Vendor and dependencies	Provider, material components and linked workflows.	Supports change and concentration assessments.
Accountable owner	Business owner plus operating and control contacts.	Gives questions and actions a responsible route.
Data and audience	Data classes, sources, output recipients and access boundaries.	Supports privacy, security and permitted-use review.
Decision impact	Advice, external output or action, affected people and human control.	Identifies the consequence of error or misuse.
Evidence and review	Approval, evaluations, controls, last review and change triggers.	Makes the operating boundary inspectable and maintainable.

Store controlled references where full evidence is sensitive. The inventory should make the record discoverable to the right people without making every attachment available to everyone.

Step 3: Reconcile the register with the workflow

Compare the recorded uses with what the process owner and authorized records show. Look for an unlisted embedded feature, an approved pilot that expanded, an integration that now acts automatically or a retired system still serving a dependency.

For each mismatch, record the source, uncertainty and next action. A missing record is a discovery gap, not proof that the use is forbidden or harmless. Route the use for the appropriate assessment.

Ask the owner to verify the recorded data and decision impact. A technically accurate product name can still conceal an outdated business purpose.

Step 4: Make updates event-driven

Assign updates to intake, deployment, significant configuration change, provider change and retirement. Define the owner who supplies the change and the owner who checks that the register reflects it.

The use-case approval workflow should create or update the record, not sit in a separate approval archive that nobody reconciles. Incident and change processes should do the same.

Periodic review remains useful, but it is not a reason to leave a known material change unrecorded until the annual cycle.

Step 5: Report the gaps and retest

Summarize the process covered, uses found, unresolved owners, stale evidence and decisions required. Avoid claiming enterprise completeness from one process drill.

Retest selected records after corrections. Can an authorized reviewer identify the owner, approved boundary, current evidence and response route? That is stronger evidence of a working inventory than the total number of rows.

Sources

NIST, AI RMF Playbook: Govern, GOVERN 1.6, inventory mechanisms, ownership and attributes. The schema and reconciliation drill are editorial recommendations, not a prescribed legal inventory format.

Frequently asked questions

Is a model list the same as an AI inventory?

Not for this purpose. A governance inventory needs the deployed use, owner, data, consequence and evidence as well as relevant technical identifiers.

Should experimental uses be included?

Define the inventory scope explicitly. Experiments can still involve sensitive data or consequential outputs, so do not exclude them merely because they are called pilots.

Does an inventory prove compliance?

No. It supports visibility and evidence. Actual compliance depends on applicable obligations and what the organization does with the information.

Who maintains the register?

A designated owner should coordinate it, while business and technical owners keep their records current. The process must specify responsibility rather than assume one central team knows every use.

Closing

Pick one business process and reconcile what the register says with what the workflow does. Every mismatch should lead to a named action. That is how an inventory becomes a governance control rather than a reassuring count.