An AI system inventory is the control surface for knowing what an organization builds, buys, deploys, changes, and retires. It is not a spreadsheet of model names. A useful register connects each business use, technical system, model or service dependency, accountable owner, affected population, decision context, risk determination, control evidence, and current lifecycle state. Without those relationships, governance teams cannot answer simple operational questions: Which customer workflows rely on a model version? Which systems process personal data? Who can suspend a harmful use? Which assessment must be repeated after a vendor change?
NIST makes inventory an explicit governance outcome: AI RMF Core Govern 1.6 calls for mechanisms to inventory AI systems according to organizational risk priorities. The companion Govern Playbook describes an inventory as an organized database of system or model artifacts that can support maintenance and incident response. That framing is stronger than a compliance-only list because it makes the register useful to product, security, operations, procurement, and audit teams every week.
Define the unit of inventory before collecting fields
Inventory a deployed or deployable AI system at the level where a business outcome, owner, and operating context can be named. A recruiting assistant, fraud decision service, support summarizer, and coding assistant are separate records even if they use the same foundation model. Conversely, every prompt experiment should not become a permanent top-level record. Link lower-level components such as model endpoints, retrieval indexes, datasets, prompts, policy filters, and human review queues as dependencies of the system record.
Keep model records distinct from system records. A model may serve several systems, while one system may orchestrate several models. The OECD classification framework characterizes systems across people and planet, economic context, data and input, model, and task and output. Those dimensions show why a model identifier alone cannot explain risk: the same model can support low-consequence drafting in one context and consequential eligibility recommendations in another.
Build the AI system inventory around linked records
Use a relational design or graph-backed catalog rather than one extremely wide row. The system record should link to use cases, technical components, data assets, vendors, assessments, controls, incidents, approvals, and evidence. Each linked object gets a stable identifier, owner, version, and state. This permits a vendor model update to identify every affected system, or an incident to identify the controls and approvals that applied at the time. Store documents in their systems of record and keep immutable links, hashes, and review dates in the register.
| Record | Minimum fields | Decision it enables | Owner |
|---|---|---|---|
| AI system | Purpose, users, affected people, owner, state | Whether use is approved and supported | Business service owner |
| Use case | Decision context, autonomy, benefit, harm, jurisdiction | Which assessment and oversight apply | Product and risk owners |
| Component | Type, version, supplier, interfaces, data flow | What changes or failures propagate | Engineering owner |
| Evidence | Artifact type, version, reviewer, date, expiry | Whether a gate has current proof | Control owner |
| Relationship | Source, target, dependency type, effective dates | Which systems are exposed to a change | Catalog steward |
Make relationships temporal. The current production model, previous model, and planned model should not overwrite one another. Effective-from and effective-to dates support incident reconstruction and audit. A register that only reflects today's configuration cannot explain yesterday's decision. Edilec's data model documentation guide offers useful patterns for field definitions, ownership, and relationship clarity.
Capture fields that change decisions
Start with identity, intended purpose, prohibited uses, lifecycle state, business owner, technical owner, risk owner, users, affected groups, geography, decision role, human oversight, data classes, model and vendor dependencies, interfaces, evaluation status, monitoring, incident route, legal basis, contractual constraints, and retirement plan. Include a confidence or completeness status for discovered shadow uses. Unknown is a legitimate value that creates a remediation task; an empty field silently hides work.
The ISO/IEC 42001 overview describes a management system for organizations that provide or use AI products and services, emphasizing policies, objectives, processes, risk, and continual improvement. A register supports that system only when its fields point to operating processes. For example, a risk tier should resolve to required approvers and review frequency, while a retired state should trigger access revocation, data disposition, dependency checks, and retained evidence.
Separate factual attributes from risk conclusions
Record facts such as intended purpose, affected population, data category, automation level, reversibility, scale, and sector before recording a legal or internal classification. This separation lets reviewers reproduce the conclusion when law, guidance, or policy changes. A single generic red-amber-green value is too lossy. Maintain parallel classifications for enterprise risk, privacy, security, model risk, sector rules, and applicable AI regulation, each with rationale, reviewer, source, date, and next review.
The European Commission's AI Act overview organizes obligations by risk and system context. Organizations operating in or affecting the EU should therefore preserve intended-purpose and value-chain role evidence, not merely an EU-risk label. Legal classification belongs with qualified counsel; the register's job is to hold the facts, determination, and versioned reasoning needed to make that advice operable.
Make registration part of delivery and procurement
Create a provisional record at intake, before build or purchase. Require a stable ID before production credentials, production data access, vendor contract signature, or release approval. Enrich the record at design and evaluation gates. A deployment event changes state only after required evidence is linked and approved. Model, purpose, geography, autonomy, data, or supplier changes open a reassessment workflow. Retirement remains open until traffic, credentials, data, integrations, user access, and obligations are closed.
| Lifecycle event | Required update | Automated check | Human decision |
|---|---|---|---|
| Idea accepted | Purpose, sponsor, candidate owner | Duplicate and prohibited-use search | Proceed to discovery |
| Design selected | Components, data flows, users, affected groups | Required assessment routing | Accept architecture |
| Release requested | Evaluations, controls, monitoring, approvals | Evidence freshness and unresolved risks | Authorize production |
| Material change | New version and changed attributes | Dependency impact and expired evidence | Reassess or constrain |
| Retirement | Final state, retention, replacement, residual duties | No active traffic or credentials | Close record |
Integrate rather than duplicate. Pull deployment versions from CI/CD, vendor identity from procurement, data classification from the data catalog, incidents from service management, and access ownership from identity systems. Let stewards correct mappings, but do not ask them to retype machine-known facts. The practical AI governance operating model helps assign the councils and owners that consume this register.
Measure register quality as an operational service
Track coverage, ownership, freshness, evidence validity, relationship completeness, and reconciliation exceptions. Useful measures include the share of production AI endpoints mapped to a system, records without an active business owner, high-impact systems with expired evaluations, and vendor changes awaiting impact review. Avoid vanity totals such as number of registered models. A large register with stale records is less trustworthy than a smaller one with explicit discovery gaps and owners.
Run quarterly attestations for ordinary systems and event-driven reviews for meaningful changes, with more frequent checks where risk warrants. Reconcile cloud endpoints, API spend, browser extensions, procurement records, and data-platform workloads to find shadow AI. Give teams a safe route to declare experimental uses without immediate punishment; discovery quality collapses when registration is perceived only as enforcement. Preserve an accountable audit trail for changes to classification, ownership, and release state.
Design access and reporting for different decisions
Do not expose the entire register to every audience. Engineers need dependency and version detail; business owners need purpose, status, conditions, and incidents; auditors need evidence lineage and decision history; executives need portfolio exposure and unresolved exceptions. Apply field-level access to personal data, vulnerabilities, legal advice, and commercially sensitive terms. Publish a broad internal directory with safe summary fields so employees can discover approved systems and avoid recreating them.
Build saved questions that map to real response playbooks: all systems using a compromised model, all affected workflows in one jurisdiction, all high-impact uses without current owners, or every system receiving data from a retiring source. Test those queries during tabletop exercises. A register proves its architecture when it can answer an urgent cross-portfolio question without days of spreadsheet reconciliation.
Define stewardship service levels. New production records might require ownership and dependency validation before launch; material vendor notices might require triage within a defined business window; critical incidents require immediate linkage. Track correction history and permit owners to challenge classifications through a controlled workflow. This keeps the register authoritative without making a central team the bottleneck for every factual update.
Key takeaways
- Inventory AI systems at the business-use level and link models, data, vendors, controls, and evidence as versioned dependencies.
- Preserve factual attributes separately from legal and internal risk conclusions so determinations can be reproduced.
- Create the record during intake and make lifecycle state changes depend on current evidence.
- Integrate with deployment, procurement, data, incident, and identity systems to reduce manual decay.
- Measure coverage, freshness, ownership, and dependency quality rather than celebrating a raw record count.
Frequently asked questions
Is a model inventory the same as an AI system inventory?
No. A model inventory describes reusable model assets. An AI system inventory describes deployed uses, people, decisions, components, and controls. Link them so one model update can reveal every affected system.
How should shadow AI be recorded?
Create provisional records with discovery source, suspected owner, observed use, and confidence. Triage quickly for data or consequential-use risk, then validate facts with the team. Do not fabricate completeness to make dashboards look tidy.
Do we need a dedicated governance platform?
Not initially. A controlled database with stable IDs, workflows, access rules, APIs, and audit history can work. Move to a platform when integrations, relationships, evidence workflows, and reporting exceed what the current tool can reliably operate.
Conclusion
A credible AI system inventory turns organizational memory into governed infrastructure. It tells teams what exists, why it exists, who owns it, what it depends on, which evidence supports it, and what must happen next. Build linked, versioned records around real decisions; connect registration to delivery and procurement; and treat quality as an operational obligation. The result is useful during release, incidents, vendor changes, audits, and retirement, not merely during an annual compliance exercise.