Build an AI use-case inventory that can trigger a decision

“We use Copilot” is an application statement, not an AI use-case record. It does not tell an AI governance lead whether staff are drafting internal notes, summarising supplier bids or recommending which supplier should win. Those uses can share software while requiring different data, oversight and authority.

A useful inventory makes those differences visible without turning every employee’s prompt into a registration exercise. Its unit is a repeatable business activity with a recognisable purpose, owner and operating boundary. The aim is to direct review effort and resolve uncertainty, while allowing understood uses to proceed.

Separate the use from the technology underneath it

Create a use-case record for “summarise supplier bids for procurement reviewers”, then link it to the application, relevant AI feature and provider records. Another department using the same application for a different consequential task gets a separate use case. Several teams doing the same task under the same controls may share one record, with their scope stated.

This structure prevents two opposite errors. One giant record labelled with a vendor name hides meaningful differences. A new record for every minor prompt variation creates a maintenance burden with little decision value. Split a use when its purpose, affected people, data or authority changes enough to require a different approval.

NIST’s AI Risk Management Framework Playbook, GOVERN 1.6, describes an inventory that can connect documentation, technical artefacts, contact information and incident-response material, and calls for responsibility for its maintenance. That is a useful foundation. For enterprise adoption, the additional discipline is to make the business use explicit, so a technical inventory can answer who is authorised to do what.

Keep detailed model documentation and contracts in their existing systems, linked from the use case. The inventory needs enough information to locate evidence and make a decision; duplicating every document creates conflicting versions.

Capture the boundary an approver actually needs

A compact entry should answer six questions:

• What work is being done? Name the task, intended benefit and business process. “Improve productivity” is too broad to test.
• Who owns the outcome? Name the business decision owner and technical service owner. Give each an actual responsibility, such as approving changed use or disabling a feature.
• Who and what are affected? Identify users, affected customers or staff, input data categories and connected information sources.
• What can the system do? Distinguish advice, draft content and actions that change another system. State the human review required before an output is used.
• What technology and evidence support it? Link the application feature, provider and relevant configuration, evaluation and data-handling evidence. Mark uncertain details as unresolved.
• What is the decision? Record the approval state, permitted boundary, outstanding condition, decision owner and trigger for another review.

These fields allow a governance lead to route a case. A tool name and a risk colour alone do not explain whether work may continue, who must act or what evidence would resolve a hold.

Microsoft’s Copilot data and privacy documentation shows why a product name is insufficient. It describes web search generating queries for Bing, advises checking an agent’s own privacy statement and terms, and notes that additional terms may apply to third-party models. The inventory should therefore identify the features and extensions in use. A provider-level assessment cannot silently stand in for every configuration.

A record that changes when the work changes

Consider this hypothetical entry for a procurement team using an AI feature inside an existing SaaS application.

Use: produce first-draft summaries of supplier proposals for an analyst. Business owner: the procurement operations manager. Technical owner: the SaaS service owner. Users and inputs: the named sourcing team, approved proposal documents and the evaluation questions. Output and authority: a summary for human comparison; no autonomous scoring, supplier rejection or outbound message. State: limited pilot, conditional on confirming the feature’s model provider and permitted data handling. Next decision: the procurement owner decides whether to proceed after the service owner supplies that evidence.

The record makes the missing provider information actionable without pretending it is already known. The service owner has a concrete task, and the business owner knows the decision the evidence supports.

Now suppose the team wants to connect the feature to contract records and allow it to email suppliers. This is a changed information boundary and action capability. Reopen the review against those changes; do not simply edit “pilot” to “production”. Preserve the earlier decision so incident responders can establish what was authorised at the time.

Make discovery a continuing part of ordinary work

Seed the inventory from procurement records, application owners, architecture reviews and team declarations. Ask about enabled AI features in existing services as well as newly purchased tools. A product already present in the software estate can still contain a use nobody has assessed.

Separate confirmed use from suspected use. A contract mentioning AI is a lead to investigate, not proof that a particular business process uses it. Give uncertain records an owner and a resolution date. This keeps discovery honest and avoids inflating adoption figures with capabilities nobody has enabled.

Connect maintenance to events that already happen: a feature is enabled, a contract renews, a connected data source changes, an evaluation fails or a service owner leaves. Review frequency should reflect the consequence and rate of change of the use. A calendar reminder alone is unlikely to catch a new action permission introduced between reviews.

For oversight, ask how many consequential uses lack owners, how many approvals have unresolved conditions and which records no longer match deployed configurations. Those questions reveal work the organisation needs to do. A growing total of registered tools reveals much less.

The next step is to translate approved boundaries into an AI acceptable-use policy teams can follow. Staff need to know which tasks, data and actions are permitted; the inventory gives that policy an accountable operational basis.