AI Inventory: A Working System of Record

Our recommended starting unit is a deployed or proposed use case: a particular organization using an AI capability for a defined purpose. A model can serve several use cases. One use case can depend on several models, tools and suppliers. Keep those relationships explicit instead of forcing every object into a single spreadsheet row with an overloaded name.

For example, an internal document assistant and a customer-facing advice assistant may call the same model. Their users, data, permitted actions and accountable owners can differ. If they share one inventory entry, a reviewer may accept evidence about the internal assistant while unintentionally treating the customer-facing use as approved. Give each use case a stable identifier, then link the shared model separately.

Record planned, trial, active, suspended and retired states according to your own operating definitions. State changes should identify who made the decision and why. Do not remove a retired record simply to make the active dashboard look tidy; retain enough context to explain past decisions and distinguish retirement from an incomplete record.

Create a small seed manifest of systems your team knows exist. Compare it with discovery outputs, procurement records, application inventories and owner submissions. Classify the differences: missing use case, duplicate identity, model mistaken for application, supplier mistaken for product, unknown owner or retired system still appearing active. This produces actionable work instead of an unexplained coverage percentage.

Ask the person resolving a duplicate to preserve the old identifiers and the reason for merging. Similar names do not prove that two records represent the same deployed use. Conversely, a product rebrand does not automatically create a new system. Keep the underlying relationship and historical naming visible so later evidence is not attached to the wrong entity.

Treat failed synchronization as a first-class state. A source that stopped updating last month can still produce a convincing-looking inventory. Show the last successful observation and the responsible operator. Decide which decisions must pause when a critical dependency is stale; do not make that behavior an accidental consequence of a dashboard filter.

Begin with a deliberately varied sample: an internally built application, a purchased AI-enabled service, an agent with tools and an application with more than one model version. Assign owners and run one complete review for each. Prefer a small inventory whose decisions can be reconstructed over a large import with no responsible people attached.

Use the downloadable template as an empty working structure. Its columns are suggestions, not a compliance form. Add your own identifiers and operating definitions, store sensitive material in an approved system and reference evidence rather than embedding secrets. Record a review trigger even when the next review date is unknown.

A useful acceptance test is to give an uninvolved reviewer one inventory record and its export. Can they explain what is used, for whom, with which data and privileges, who accepted the decision and what remains unresolved? If not, improve the relationships and evidence trail before buying another layer of reporting.