AI Model Inventory: Fields, Owners, and Review Workflow

An AI model inventory is not a spreadsheet of model names. It is the control record for every AI decision the organization may have to defend.

A useful inventory shows why an AI use exists and what it can see or change. It names the owner, the evidence behind the risk decision, and the event that will force another review. A product list cannot answer those questions. Neither can a technical model registry by itself.

The right unit is usually the AI use case. One model can support many uses with different data, users, authority, and consequences. One business process can also combine several models, vendor features, rules, and human decisions. Record the whole path from purpose to effect.

The AI Governance hub connects inventory work to policy, risk review, human oversight, testing, and evidence. Use the AI governance roles guide to assign decision rights, and the NIST AI RMF implementation guide to connect the record to Govern, Map, Measure, and Manage. GS Consulting brings the operating model together through AI governance and risk oversight.

AI Model Inventory: The Short Answer

Build an AI model inventory in five moves. Discover every AI use, including employee tools and vendor features. Register one stable record per bounded use case. Triage the use based on data, affected people, downstream authority, and consequence. Decide whether to approve, restrict, pause, reject, or retire it. Keep the record current through material change, incidents, recurring review, and retirement.

The minimum record needs more than a name and owner. It needs a purpose, system boundary, data boundary, users, action authority, provider and version, risk tier, test evidence, approval conditions, monitoring triggers, lifecycle state, and evidence links. If a field does not support a decision, test, or operating action, question why it exists.

Start small enough to maintain. A compact record with enforced field rules is better than a giant template full of stale prose. Put detailed assessments, test results, contracts, and incident records in their proper repositories. Link them through stable identifiers and preserve the decision trail.

Inventory the AI Use, Not Just the Model

A model name is not a risk boundary. Consider the same language model used in three places. A public research assistant reads public material and drafts notes. A proposal assistant reads controlled contract material. A service agent can update a customer record and send a message. The model may be identical. The authority, data, people, controls, and recovery burden are not.

Each inventory record should therefore describe one bounded use case with one accountable business owner. The record can reference several technical components. It can also reference a shared model registry entry, vendor assessment, data classification record, or control test. Do not collapse distinct business uses merely because they share a provider.

Include AI that arrives through software already in the environment. Embedded assistants, automated recommendations, scoring features, document extraction, security tools, and workflow agents can bypass a procurement search for products labeled as AI. Discovery needs finance, procurement, security, architecture, privacy, legal, data, and business operations evidence.

Set explicit exclusions. A team may decide that simple deterministic rules remain in a software catalog while systems that generate, classify, predict, recommend, or act enter the AI inventory. Record the definition and edge cases. Otherwise every review becomes an argument about scope.

Public Evidence Shows a Scale and Quality Problem

The official 2025 Federal Agency AI Use Case Inventory reported 3611 individually reported use cases and 445 high impact use cases as of April 13, 2026. Its validation data dictionary contains 36 fields for individual use cases. Those counts are not a private sector benchmark. They are a useful signal that inventory design becomes a data management problem at operating scale.

Quality is the harder part. In a review covering an earlier federal reporting period, GAO found that 15 of 20 reviewed agency inventories had incomplete or inaccurate use case data. Reporting rules have changed since that work. The durable lesson remains: publication or executive attention does not make weak records complete.

NIST AI RMF Govern 1.6 calls for mechanisms to inventory AI systems and allocate resources according to risk. The NIST AI RMF Playbook suggests defining scope and a responsible maintainer, then connecting records to documentation, code, incident plans, data dictionaries, and actor contacts. These are voluntary framework outcomes and suggested actions. They do not create one mandatory schema.

Original Research: The GS AI Inventory Field Priority Index

Build the fields that support a stop, approval, or escalation decision first. Add descriptive depth after the control record works.

GS Consulting built a derived planning model for 12 inventory field groups. Each group receives an ordinal rating from zero to ten across five factors. Decision criticality and risk visibility each carry 25 percent. Lifecycle utility carries 20 percent. Evidence value and change sensitivity each carry 15 percent. The weighted result is multiplied by ten and reported on a zero to 100 scale.

Data boundary and sensitivity scores 100. Action authority and downstream use scores 98.5. Business owner and risk acceptor scores 96.5. Risk tier and rationale score 95. Test evidence scores 94. Approval status and monitoring triggers each score 92.5. These fields describe exposure, authority, accountability, proof, and the decision itself.

Model, service, vendor, and version score 87.5. Purpose and success measures also score 87.5. Users, affected people, and human review score 85. Lifecycle state and review date score 84.5. Retirement and data disposition score 83. None are optional. The ranking is a build sequence for teams that cannot perfect every field on day one.

The sensitivity case increases the weight on risk visibility and evidence. No field moves by more than two points. The leading decision fields stay at the top, which supports the sequence under the documented assumptions.

The GS AI Inventory Field Priority Index is a derived planning tool. It is not an official NIST, OMB, GAO, legal, audit, compliance, certification, or regulatory determination. Replace the GS assumptions with local evidence and accountable judgment.

The Required AI Inventory Fields

Use a stable identifier and controlled values wherever possible. Free text is useful for purpose and rationale, but weak for status, risk tier, owner, dates, and review triggers. The following field groups are the practical minimum.

• Identity and purpose: stable use case ID, plain name, problem, intended benefit, success measure, business process, and current lifecycle state.
• Accountability: business owner, technical owner, data owner, control owners, operator, independent reviewer when required, and risk acceptor.
• Technical boundary: application, models, services, provider, version, hosting, interfaces, tools, agents, dependencies, and linked model registry records.
• Data boundary: sources, classes, sensitive elements, retrieval, derived data, retention, locations, sharing, provider use, and disposition rules.
• People and authority: users, affected people, human review, outputs, recommendations, system writes, external release, financial effect, access changes, and prohibited actions.
• Risk and evidence: risk tier, trigger facts, assessment, evaluation methods, results, thresholds, limitations, control proof, unresolved gaps, and incident history.
• Decision and operation: approval, approver, rationale, restrictions, expiration, monitoring measures, alerts, escalation, pause rights, recovery, review date, and change history.
• Exit: retirement date, disablement, access removal, record retention, data deletion, user notice, vendor action, and owner signoff.

Do not bury the decision in an attachment. The record should show current status, approver, conditions, expiration, and open actions without forcing a reviewer to search a folder. Link the supporting evidence, then test the links.

A vendor name is not enough. Record the model or service actually used and the version or change channel when available. Add the hosting terms, data use terms, connected tools, and changes the provider can make without local approval. The AI vendor risk guide explains the deeper review.

The AI Inventory Review Workflow

1. Discover. Search procurement, expense, identity, network, endpoint, software, cloud, browser, data, architecture, and business process evidence. Add a simple employee reporting route.
2. Register. Assign a stable ID and record the purpose, owners, model or service, data, users, authority, provider, and lifecycle state.
3. Triage. Set the risk tier, required reviewers, evidence, restrictions, and decision deadline. Missing facts become owned actions, not favorable assumptions.
4. Decide. Approve, condition, pause, reject, or retire the use. Record the approver, rationale, evidence considered, conditions, expiration, and open work.
5. Maintain. Review after material change, incidents, vendor change, control failure, owner change, approval expiration, pause, or retirement.

Automate transfers, not judgment. Procurement can create a draft record. Identity systems can verify owners. A model registry can update versions. Monitoring can open a review task. None of those events should silently approve a consequential use.

One Inventory Standard, Several Named Owners

The governance lead owns the inventory policy, schema, quality checks, reporting, and escalation process. That role does not own the truth of every use case. The business owner owns purpose, value, affected workflow, operating limits, and continued need. The technical owner owns architecture, integration, version, tools, permissions, and technical change.

Data, security, privacy, legal, compliance, procurement, records, and other control owners own their evidence and conditions. An independent reviewer may challenge testing or assumptions when consequence warrants it. The risk acceptor owns the final residual risk decision. The AI governance roles and responsibilities guide maps these decision rights in detail.

Require a backup for critical roles and a deadline for owner vacancies. A departed owner should not leave an approved use in permanent limbo. Ownership changes are review triggers because knowledge, authority, and acceptance can change with the person.

Review on Consequence and Material Change

A calendar alone is too weak. Set a recurring review based on consequence, then add event triggers. A material change is any change that could alter the use case purpose, boundary, performance, affected people, authority, risk tier, control effectiveness, or recovery design.

• New model, major version, provider, hosting design, agent, tool, or connected system.
• New data source, sensitive data class, retention pattern, sharing path, or provider use term.
• New user group, affected population, decision purpose, external release, or production action.
• Changed evaluation result, operating threshold, approval condition, monitoring measure, or human review duty.
• Incident, near miss, complaint, control failure, audit finding, drift signal, or unexpected behavior.
• Owner change, contract change, approval expiration, pause, resumed operation, or retirement.

Define who can declare a change material, who must be notified, which approval is suspended, and what evidence is needed to resume. If those rules are vague, teams will classify every change as minor to avoid delay.

Treat Inventory Quality as an Operating Metric

Do not measure success by row count. Track whether the records can support decisions. Use three groups of measures:

• Coverage: discovery coverage, required field completeness, and valid owner rate.
• Control health: overdue reviews, expired approvals, broken evidence links, and unresolved high consequence gaps.
• Flow: time from discovery to decision and time from retirement decision to disablement.

Run automated checks for controlled values, dates, duplicate IDs, missing owners, inactive identities, broken links, impossible status combinations, and stale versions. Then sample records manually. A field can be complete and still be wrong.

Reconcile against other systems. Compare the inventory to procurement, payment, identity, cloud, software, model registry, security, privacy, and architecture records. Investigate both directions: AI found outside the inventory and inventory entries with no operating evidence.

The Minimum AI Inventory Evidence Packet

The packet contains an inventory policy, field dictionary, use case record, boundary record, decision record, test record, monitoring record, and change record. These artifacts can live in connected systems. The inventory should expose their identifiers, current status, owners, and links.

Preserve historical decisions. Do not overwrite a prior approval when conditions change. Record the new decision, its effective date, the evidence considered, and what happened to the old conditions. Auditability depends on sequence.

Common AI Inventory Mistakes

• Counting models instead of uses. This hides different data, authority, users, and consequences behind one technical name.
• Making one administrator responsible for truth. Central teams can enforce quality, but business and control owners must attest to their fields.
• Collecting everything before deciding anything. A large questionnaire delays action while critical authority and data facts remain unclear.
• Approving the vendor once. Vendor review does not approve every use case, integration, data path, or downstream action.
• Using a one time discovery exercise. New software features, employee tools, and model changes will make the record stale.
• Deleting retired records. Retirement needs evidence of disablement, access removal, retention, disposition, and accountable closure.

What to Do in the First 30 Days

In the first week, agree on the AI use case definition, scope, stable ID, required decision fields, controlled status values, and accountable roles. Select one inventory owner and one executive escalation path.

In the second week, discover use through procurement, finance, identity, security, architecture, data, and business interviews. Register incomplete records rather than hiding them. Mark unknown facts, owners, and due dates.

In the third week, triage the most consequential uses. Prioritize sensitive data, external decisions, production actions, broad access, affected people, weak recovery, and unclear ownership. Decide restrictions and evidence requests.

In the fourth week, run the quality check, close duplicate records, test evidence links, review overdue decisions, and present the unresolved risk to accountable leaders. Then set the recurring discovery and review cadence.

Sources and Method

The research package records these primary public sources:

• NIST AI RMF Core
• NIST AI RMF Playbook
• OMB Memorandum M-25-21
• 2025 Federal Agency AI Use Case Inventory
• GAO 24 105980
• GAO AI Accountability Framework

OMB M-25-21 applies to covered federal agencies under its terms. It is an operating signal for other organizations, not a blanket contractor staffing or inventory rule. NIST AI RMF is voluntary. Legal, regulatory, contractual, and sector obligations require context specific review.

The GS model uses documented ordinal ratings and weights. Source observations, inputs, formulas, scores, sensitivity results, and figure data are preserved in the research package. The score supports planning and challenge. It does not replace accountable review.

AI Model Inventory FAQ

What is an AI model inventory?

An AI model inventory is a governed record of AI use cases, systems, models, data, people, decisions, controls, changes, and exit actions. It should let a reviewer reconstruct why the use was allowed and what would stop it.

Should the inventory include employee AI tools?

Yes, when those tools fall within the organization definition and can access business data or affect business work. Use discovery and a simple reporting route. Do not rely on voluntary memory alone.

How detailed should the inventory be?

Detailed enough to route and defend decisions, but small enough to maintain. Keep current control facts in the record and link deeper assessments, tests, contracts, and incidents through stable identifiers.

What is the operating standard?

No owner, no boundary, no decision evidence, no approved AI use. Register the use, name the accountable roles, prove the control facts, and reopen the decision when material change makes old evidence stale.