Ask a leadership team a simple question: how many AI systems does the organization use today, and which of them influence decisions about customers or employees? The answer often says more about the state of AI governance than a policy document does.
NIST uses almost exactly this kind of question to explain what an inventory is for. Its AI RMF Playbook says a serviceable AI system inventory may allow quick answers to high-level queries “such as, ‘how many models are currently deployed within our organization?’ or ‘how many users are impacted by our models?'” Interpretation: if an organization cannot answer those questions with confidence, its other governance controls are working from an incomplete picture.
Note: statements attributed to a named source come from that source. Everything else, including passages marked “Interpretation,” is the author’s interpretation, and the inventory fields below are not a required template from any framework.
What the frameworks say
The clearest statement comes from the NIST AI Risk Management Framework (AI RMF 1.0), which NIST released on January 26, 2023. Its GOVERN function includes subcategory GOVERN 1.6: “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.” The framework is intended for voluntary use, and NIST states that it is being revised as part of the White House AI Action Plan.
The companion Playbook adds detail. It describes an AI system inventory as “an organized database of artifacts relating to an AI system or model,” which may include system documentation, incident response plans, data dictionaries and contact information for the people involved. It notes that inventories “are a common element of traditional model risk management approaches” and that “partial inventories may not provide the value of a full inventory.” Its suggested actions include naming the individual or team responsible for maintaining the inventory and defining which systems are included, “with preference to inventorying all models or systems.”
ISO makes a similar point in plainer terms. In its public explainer on ISO/IEC 42001, the international standard for AI management systems, ISO lists “identifying where AI systems are used” first among the practical steps organizations can take to build the foundations of an AI management system.
In the United States, federal policy treats the inventory as a reporting requirement. OMB Memorandum M-25-21, dated April 3, 2025, states in Section 3(b)(v) that each agency, except the Department of Defense and the Intelligence Community, “must inventory its AI use cases at least annually, submit the inventory to OMB, and post a public version on the agency’s website” (as of October 2026).
NIST and ISO offer voluntary frameworks, while M-25-21 applies only to US federal agencies. Interpretation: bodies with very different authority still arrive at the same starting step.
Why an inventory is a control, not paperwork
An inventory does not make any single AI system safer. What it does is decide which systems the rest of the governance program can reach.
Consider the controls organizations usually discuss: risk assessment, human oversight, monitoring, incident response and decommissioning. Each is applied to a specific system. A system that is not on the list is not assessed, not assigned an owner, not monitored and not reviewed when something changes. The gap is silent. Nothing fails visibly; the system simply sits outside the program.
The inventory’s value lies less in the list itself than in the coverage it gives every other control. NIST’s structure reflects the connection: GOVERN 1.6 sits directly before GOVERN 1.7, which covers decommissioning AI systems safely, and the Playbook suggests that decommissioned systems “may be stored in a model inventory along with active models, for an established length of time.”
Why AI is harder to count than it looks
Counting AI would be simple if every system arrived through a formal project. Often it does not. AI capabilities can be added to existing software through a vendor update, adopted by a team that signs up for a new tool, or carried from a pilot into routine use. None of these routes necessarily passes through the review that a new in-house model would.
Third-party AI is where this matters most. The AI RMF notes that “risk can emerge both from third-party data, software or hardware itself and how it is used,” and the Playbook suggests verifying that formal AI risk management policies “include currently deployed and third-party AI systems.” An inventory limited to models an organization builds itself will miss much of what it actually uses.
Definitions matter too. The EU AI Act defines a “deployer” in Article 3(4) as a person or body “using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity.” In other words, the Act does not place obligations only on organizations that build AI. Organizations that use it can carry responsibilities as well.
What the EU AI Act changes
The EU AI Act (Regulation (EU) 2024/1689) takes a risk-based approach. The European Commission describes four levels of risk and says that “the vast majority of AI systems currently used in the EU” fall into the minimal or no-risk category. Systems used in specified high-risk areas, such as employment, education and access to essential services, carry stricter obligations. According to the European Commission, an amending regulation known as the “AI Omnibus,” which entered into force on July 27, 2026, set the application date for the high-risk rules in these areas (listed in Annex III of the Act) at December 2, 2027. High-risk AI built into products covered by EU product legislation (Annex I) follows later, from August 2, 2028. Dates can change, so check the official text.
For deployers of high-risk systems, Article 26 includes obligations to assign human oversight (Article 26(2)) to people “who have the necessary competence, training and authority, as well as the necessary support,” and to “monitor the operation of the high-risk AI system on the basis of the instructions for use” (Article 26(5)).
The provisions discussed here (Articles 3, 4 and 26) do not set out an “inventory” as a named deployer obligation. Several duties still assume that an organization knows which AI systems it uses. For example, Article 4 asks providers and deployers of AI systems to support AI literacy, taking into account the context in which the systems are used. And public-authority deployers of high-risk systems must meet registration obligations (Article 26(8), referring to Article 49). Interpretation: even so, it is hard to see how an organization could show that it meets obligations tied to specific high-risk systems if it does not know which systems it uses and for what purpose. Classification is a judgment made system by system. Without a list, there is nothing to classify. How the Act applies to a particular organization is a question for legal advice.
What a useful inventory records
A useful entry answers a small number of questions well:
- Purpose and influence. What does the system do, and which decisions does it inform or make?
- Ownership. Who is accountable for it, and who is the operational contact if something goes wrong?
- Source. Was it built in-house, bought, or switched on inside another product?
- Data. What data does it use, and does any of it involve personal or sensitive information?
- Impact. How much harm could an error cause, and to whom?
- Status and review. Is it in pilot, in production or retired, and when was the entry last confirmed?
The last field often decides whether an inventory stays useful. An entry without a review date records only what someone believed at one point in time.
Keeping the list alive
A one-time inventory decays. Procurement checks, change management and owner reviews keep it current. The NIST Playbook also suggests naming “a specific individual or team that is responsible for maintaining the inventory.”
Conclusion
Debates about AI governance tend to focus on the hardest questions: fairness, explainability and accountability for automated decisions. Those questions matter. But each is asked about a particular system, and an organization can only ask them about the systems it knows it has.
That makes the inventory less a preliminary task than a precondition. A useful test for any governance program is not only whether its controls are well designed, but how much of the organization’s actual AI use those controls can reach.
This article reflects the author’s personal views, not those of any employer, and interpretation of publicly available materials from NIST, ISO, the European Commission, the EU AI Act Service Desk and the US Office of Management and Budget, as available on October 15, 2026. It is not affiliated with or endorsed by any of these bodies and does not reproduce their full requirements. It is general information, not legal, compliance or certification advice, and reading it does not create any advisory relationship. Laws, guidance and application dates change. Refer to the official texts, including the EU AI Act as published in EUR-Lex, and get qualified advice before acting on how they apply to your organization.
Sources: NIST, AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf; NIST, AI Risk Management Framework, https://www.nist.gov/itl/ai-risk-management-framework; NIST AIRC, AI RMF Playbook: Govern, https://airc.nist.gov/airmf-resources/playbook/govern/; ISO, ISO/IEC 42001 explained, https://www.iso.org/home/insights-news/resources/iso-42001-explained-what-it-is.html; OMB, Memorandum M-25-21, https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf; European Commission, AI Act, https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai; European Commission, AI Omnibus enters into force, https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force; AI Act Service Desk, Articles 3, 4 and 26, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-3, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4 and https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26 (accessed October 15, 2026).