AI Inventories: The Governance Control Everything Else Depends On
You can’t govern AI you can’t see. Here’s what an AI inventory is, why it matters, and how to build one that stays accurate.
Ask most leadership teams how many AI tools their organization uses and you may get a confident number. Ask how many of those tools touch customer data, who owns each one, and which ones were added by a vendor update last quarter, and the confidence fades.
That gap is no longer theoretical. Microsoft’s 2026 Data Security Index, based on a survey of more than 1,700 data security leaders, found that roughly a third of organizations’ data security incidents now involve generative AI tools. Yet fewer than half of surveyed organizations are implementing security controls built specifically for generative AI.
The instinct is to respond to increased AI usage with policy: an acceptable-use statement, a list of approved tools, a training module. Those matter, but every one of them assumes you already know what AI is running in your business. Most organizations don’t. That is the problem an AI inventory solves, and it is why the inventory is the first governance control to put in place, not the last.
What is an AI inventory?
An AI inventory is a maintained, organization-wide record of every AI tool, feature, and agent in use. For each one, it captures who owns it, what it’s used for, what data it touches, and how risky it is.
The idea is not new. The NIST AI Risk Management Framework calls for it directly, asking organizations to have mechanisms in place to inventory their AI systems according to their risk priorities.1
What it isn’t. An AI inventory is not your IT asset register with an “AI” tag added, and it is not a data team’s model registry. The asset register misses free tools and features vendors switch on within third-party apps; the model registry misses everything the business buys rather than builds.
What belongs in it. A useful inventory covers five categories:
| Category | What it covers | Why it’s easy to miss |
|---|---|---|
| Sanctioned AI | Enterprise AI tools you procured and approved | Usually listed, but often without data or use-case details |
| Embedded AI | Copilots and “smart” features vendors add to SaaS you already own | No new purchase, so no procurement trigger |
| Built AI | In-house models, apps, and agents, plus integrations calling third-party model APIs | Lives in code and cloud accounts |
| Shadow AI | Personal or free accounts, browser extensions, and plug-ins used for work without approval | Downloaded and paid by employee, or not paid at all |
| Grey-zone AI | An approved tool used for an unapproved purpose or with unapproved data | The tool is already “on the list” but is misused |
What problems does an AI inventory solve?
The short answer is that it makes every other AI control possible. The longer answer is that it solves four distinct problems.
The cost of not having one
Without an inventory, risk doesn’t disappear. It just goes unmeasured until an incident, an audit, or a regulator measures it for you.
How to put an AI inventory in place
The organizations that get this right treat the inventory as an operating process, not a one-time audit. Here is the approach we recommend.
Step 1: Set the scope and name an owner
Agree what counts as AI, using all five categories above; a narrow definition such as “tools IT bought” guarantees blind spots. Then name a single accountable owner to the entire inventory, typically a governance lead, with IT/security, legal, procurement, and business owners each playing a defined role for individual tools.
Step 2: Discover what’s already out there
No single method finds everything, so run three discovery tracks in parallel and reconcile the results:
Platform tooling can carry much of the technical track. For Microsoft 365 organizations, Microsoft’s security guidance for AI covers Defender for Cloud Apps to discover and sanction generative AI apps, Purview DSPM for AI to see how sensitive data flows into AI tools, and Microsoft Entra Agent ID to see agents built in Copilot Studio and Foundry.
Step 3: Capture a minimum viable record
Resist the urge to design a 40-field template; coverage matters more than depth at the start. A practical first draft captures the tool and vendor, a named owner, the use case, the data it processes, deployment type, connected systems, approval status, risk tier, human oversight, and review dates.
Step 4: Triage what you find
Every discovered tool gets one of four decisions: approve, approve with conditions (such as data restrictions or a move to an enterprise license), replace with a sanctioned alternative, or retire. Prioritize by the sensitivity of the data involved and the stakes of the decisions the tool influences. And treat shadow AI as demand: retiring a popular tool without a credible replacement can push usage further underground.
Step 5: Keep it alive
An inventory is only as good as its last update, so build it into processes that already run. Add an AI review step to procurement, architecture review, and project intake so new AI is registered before it goes live. Conduct a review of records when a vendor ships new AI features, a new data source is connected, or the use case changes. Additionally set review frequency by risk tier, the higher risk a tool carries, the more frequent a review should occur.
The bottom line
AI governance doesn’t start with a policy, a committee, or a risk framework. It starts with an honest answer to a simple question: what AI is running in our business right now, and who is accountable for it?
The good news is that you don’t need a perfect system to begin. A named owner, a broad definition of AI, three discovery tracks, and a dozen fields will get most organizations to meaningful visibility within a few months.
Notes
- NIST AI RMF 1.0 (NIST AI 100-1), subcategory GOVERN 1.6: mechanisms are in place to inventory AI systems, resourced according to organizational risk priorities.
- NIST AI RMF 1.0, subcategory GOVERN 1.7: processes are in place for decommissioning and phasing out AI systems safely.
- NIST AI RMF Playbook, suggested actions for GOVERN 1.6: name a specific individual or team responsible for maintaining the inventory.
- EU AI Act, Annex III lists the use cases that make a stand-alone AI system high-risk, such as recruitment, credit scoring, and education; AI in products regulated under Annex I, such as medical devices, can also be high-risk.
- Regulation (EU) 2026/1744 (Digital Omnibus on AI): Annex III high-risk obligations apply from 2 December 2027 (previously 2 August 2026); Annex I obligations apply from 2 August 2028.
Sources
- Microsoft, New Microsoft Data Security Index report explores secure AI adoption to protect sensitive data (2026 Data Security Index), January 29, 2026
- Microsoft, 80% of Fortune 500 use active AI agents: Observability, governance, and security shape the new frontier (Cyber Pulse report), February 10, 2026
- Microsoft and LinkedIn, 2024 Work Trend Index: AI at Work Is Here. Now Comes the Hard Part
- Microsoft Learn, Discover AI apps and data
- Gartner, Gartner Identifies Critical GenAI Blind Spots That CIOs Must Urgently Address, November 19, 2025
- Infosecurity Magazine, coverage of 1Password’s 2025 Annual Report
- Cybernews survey, August 2025, as reported by Yahoo/TechRadar
- NIST, AI Risk Management Framework
- Orrick, EU AI Act Update: Digital Omnibus Finalizes 8 Compliance Changes
- Cloud Security Alliance, EU AI Act high-risk deadline research note