Most teams treat the AI model inventory as a spreadsheet they fill in once, forget, and produce for an auditor two years later. That view is wrong, and it fails the moment a risk question arrives that the sheet cannot answer. The Department of Veterans Affairs told NIST that the lack of an inventory or consistent tracking complicates the work of identifying AI-related risks, because the total scope of an organization's AI deployments is unknown (NIST AI RMF RFI responses). The inventory is not paperwork. It is the precondition for every other control you plan to run.
This piece assumes you have to build one this quarter. It walks each field group and asks the same question of every column: what decision does this field let someone make, and what breaks if it is missing. If a field cannot answer that, it does not belong. The point is not a longer schema. The point is a schema where every entry pulls its weight.
Why the inventory is a control, not a record
The VA submission is blunt about the causal chain. Risks cannot be properly identified or otherwise managed without first identifying and tracking organizational AI systems (NIST AI RMF RFI responses). Read that as a dependency, not a slogan. Threat modeling depends on knowing what exists. Impact analysis after a model provider discloses a flaw depends on knowing which systems call that model. Decommissioning depends on knowing what a model connects to. Each of those downstream activities inherits the gaps in your inventory.
The NIST AI RMF Playbook makes the same point from the governance side. It suggests that organizations verify that formal AI risk management policies include currently deployed and third-party AI systems, and connect AI governance to existing organizational governance and risk controls (NIST AI RMF Playbook, Govern). Third-party systems are named on purpose. A model you did not train still reaches your data and your users, and it belongs in the inventory with the same rigor as one you built.
Software inventory practice already treats this as a maturity problem rather than a binary. The OWASP Software Component Verification Standard sorts inventory controls into three levels, where knowing all direct and transitive components at build time sits at every level, but a continuously maintained bill of materials for all systems only appears at the highest (OWASP SCVS V1). The lesson carries directly. A one-time inventory and a continuously maintained one are different controls, and only one of them survives contact with a fast-moving model estate.
Figure 1: Two of the five controls apply at L1, L2 and L3, a third joins at L2, and continuous SBOM upkeep and point of origin appear only at L3. Inventory maturity is staged, not a binary.
The fields, and what each one decides
Group the schema into four blocks. Identity, ownership, data reach, and lifecycle. Everything else is a refinement of one of these.
Identity: naming the thing so two teams mean the same model
An inventory that cannot uniquely name its entries cannot support impact analysis, because you cannot tell whether two rows are the same model or two different ones. OWASP requires that components be uniquely identified in a consistent, machine-readable format, and that an accurate inventory of all third-party components be available in a machine-readable format rather than a document a human reads and interprets (OWASP SCVS V1). For AI, the identity block carries the model name and version, the base model or provider where the system wraps a third party, and a stable identifier that does not change when someone renames the project.
Version is not optional metadata here. Model behavior changes across versions, and a risk finding against one version does not transfer to another. The machine-readable requirement matters for the same reason it matters in software supply chain work: when a provider discloses a weakness, you want to query the inventory, not read it.
Ownership: a named human who answers for the model
The NIST Playbook is direct that a lack of clear information about responsibilities and chains of command will limit the effectiveness of risk management, and that without policies that systematize AI actor roles and responsibilities, risk management can be subjective across the organization (NIST AI RMF Playbook, Govern). Translate that into a field. Every model has an accountable owner, and the owner is a person or a defined role, not a team name that dissolves under scrutiny.
Ownership earns its place because it is the field a reviewer uses to route every other question. Who approved this data source. Who decides whether the model still meets its intended use. Who signs off on decommissioning. The VA response lists decommissioning as its own discipline, arguing that organizations should create processes for securely decommissioning and disentangling AI models from other systems when no longer in use, because a compromised or untrustworthy system can harm the systems it touches (NIST AI RMF RFI responses). Decommissioning has no owner unless the inventory assigns one.
Data reach: what the model touches
This is the field group teams most often skip, and it is the one that determines legal exposure. The NIST Playbook ties AI governance to broader data governance, singling out the use of sensitive or otherwise risky data, and it points to legal requirements that can mandate documentation and disclosure around data privacy and security (NIST AI RMF Playbook, Govern). Data reach is where you record what training data fed the model, what data the model sees at inference, and whether any of it is personal or otherwise regulated.
Data reach also enables a capability the VA flagged as a trustworthiness need. Organizations should prioritize processes for securely removing personal data from a model, an operation the response calls unlearning, so that sensitive or biased data can be removed without restarting from scratch (NIST AI RMF RFI responses). You cannot scope an unlearning request against a model whose data reach you never recorded. The field pays for itself the first time a subject access request or a poisoned-data finding arrives.
Lifecycle: change history and review triggers
The inventory has to record what a model is, how it has changed, and when it must be looked at again. The NIST Playbook lists change management requirements and the frequency and detail of monitoring, auditing, and review as things AI risk policy should outline (NIST AI RMF Playbook, Govern). Change history is the field that lets an auditor reconstruct what the model was doing on the day an incident occurred, rather than what it is doing now.
Review triggers deserve their own column rather than a calendar reminder. The VA response names data drift and concept drift as risks that affect the accuracy of model outputs and should be proactively monitored (NIST AI RMF RFI responses). Drift is a condition, not a date. A review triggered by a measured drift threshold catches a degrading model that an annual review can miss for the better part of a year.
Figure 2: Four triggers land on three field blocks. Identity carries two, data reach one, lifecycle one. No ownership or change history block appears, since no trigger depends on one.
Trigger conditions: when the inventory tells you to act
A static review cadence is the weakest form of review. It fires whether or not anything changed and ignores everything that changes between firings. The stronger design records trigger conditions on each entry, so the inventory itself signals when a model needs attention. Three of the four triggers below trace to a cited source. The fourth, a model version change, is an inference from ordinary change-control practice rather than something either NIST source names.
A model version change is a trigger, because a new version is a different model for risk purposes and inherits none of the prior version's testing. A change in data reach is a trigger, because new or newly sensitive data pulls in the legal and regulatory requirements the Playbook says must be understood and documented (NIST AI RMF Playbook, Govern). Measured drift is a trigger, following the VA's argument that data and concept drift should be proactively monitored rather than discovered after outputs degrade (NIST AI RMF RFI responses). A newly disclosed attack against a model class is a trigger, given the VA's catalog of backdoor attacks, data contamination, denial of service, and oracle attacks as common techniques the field is still cataloging (NIST AI RMF RFI responses).
Each trigger works only if the field it depends on exists. That is the argument for the whole schema in one line. Version identity names the target and matches a newly disclosed attack to the models it affects, data reach scopes the review, and the lifecycle fields carry the drift trigger. Drop any one of those three and a trigger goes dark. Ownership and change history fire no triggers of their own. They route the review and reconstruct the state once a trigger fires.
The maturity you are buying
Do not aim for the highest inventory maturity in the first quarter. Aim for the level you can maintain. OWASP places a continuously maintained, always-current software bill of materials for all systems at its top level and knowing point of origin for every component there as well, while placing basic build-time component knowledge at every level (OWASP SCVS V1). Read that as a staged plan. Get identity, ownership, and data reach recorded for every known model first. Add continuous maintenance and origin tracking as the second wave.
The failure mode to avoid is the one the VA listed among the greatest challenges in managing AI-related risk. At large organizations, various stakeholders and offices may sponsor AI deployments or pilots without a centralized inventory or consistent tracking process, so the organization cannot see the total scope of its own AI (NIST AI RMF RFI responses). A shallow inventory that covers every model beats a deep one that covers half of them, because the models you never entered are the ones that hurt you. Coverage first, depth second.
What to do this quarter
Start with discovery, not schema design. Find the models before you perfect the columns. Assign an owner to each one as you find it, because an unowned entry is an entry no one will keep current. Record data reach next, since it drives the legal and privacy exposure that turns a model from a curiosity into a liability. Add change history and trigger conditions once the first three blocks are populated, and treat continuous maintenance as the milestone that moves you from a record to a control. Every field in the schema should trace to a decision someone has to make. If it does not, cut it, and cut it before it becomes a column no one fills.