Build the inventory from evidence, not from a survey. Combine what the endpoints, the cloud accounts, the identity system and the network can actually see, give every item a named owner, record what each one can reach, and refresh it continuously. A survey tells you what people remember using; evidence tells you what is running.
Boards and regulators now ask a question that sounds simple: which AI does this company use? The honest answer for most organisations is an estimate. This guide sets out how to replace the estimate with an inventory you can defend, in about thirty days.
What belongs in the inventory
Treat anything that can make a decision, call a tool, hold a credential or move data as an AI asset. In practice that means:
- Applications and services: AI assistants, chat tools and AI features inside other software, sanctioned or not.
- Agents and tool servers: autonomous agents, coding agents and the MCP servers or plug-ins they use.
- Models and libraries: hosted models you call, local models you run, and the AI libraries in your code.
- Credentials and identities: provider API keys and the service accounts agents act as.
- Data connections: the stores, repositories and cloud resources an AI can read or write.
The fields that make it useful
A list of names is not an inventory. For each asset record:
- What it is and which version, and where it runs.
- Who owns it, as a named person or team.
- Whether it is approved, approved with conditions, or not allowed, and who decided and when.
- What it can reach: files, credentials, cloud accounts, network destinations.
- How exposed it is, and why, with the evidence behind the rating.
- How it was seen: found in a configuration, seen running, or both. A configuration proves an item is configured, not that it is running, and a running item with no configuration is a different finding.
- When it was last seen, so stale entries fall away.
Where the evidence comes from
No single source sees everything, so combine several and note which source saw what:
- Endpoints and servers reveal tools, plug-ins, local keys, installed apps and local agents.
- Cloud accounts reveal hosted AI services, the roles agents hold and the data they can reach.
- Identity systems reveal sign-ins to AI services and the accounts behind them.
- Network and proxy records reveal traffic to AI endpoints from places no agent is installed.
- Code and build systems reveal AI libraries, keys committed to repositories and AI-generated code.
An AI Bill of Materials, a machine-readable list of the AI components in an application or environment, is a good output format because it can be handed to an auditor or a customer.
Ownership is the hard part
Discovery is the easier half. An asset with no owner cannot be approved, fixed or retired. Pull ownership from the systems that already know it: the directory, the device-management tool, the service catalogue. Where you cannot, route the finding to the likely team and make accepting or reassigning it a recorded step.
Measures that tell the board something
- Coverage: the share of endpoints, accounts and sources feeding the inventory, with the blind spots named.
- Ownership: the share of assets with a named owner.
- Decisions: the share with a recorded approve or deny, and how many are overdue for review.
- Time to detect: how long a new AI tool takes to appear in the inventory.
- Reach: the number of assets that can touch sensitive data or a production account.
Common mistakes
- A one-off spreadsheet. It is out of date the week it is finished. The inventory must refresh on its own.
- Claiming completeness. Say what you cannot see. An inventory with named blind spots is more credible than one claiming everything.
- No decision attached. Finding an unapproved tool achieves nothing until someone approves, restricts or removes it.
- Collecting content. Discovery needs metadata, such as what exists and what it can reach. It does not need prompts or file contents.
A thirty-day plan
- Week 1: agree the definition of an AI asset and the fields above. Pick a pilot population.
- Week 2: run read-only discovery on the pilot and connect one cloud account.
- Week 3: assign owners, record decisions on the top findings, and review what reaches sensitive data.
- Week 4: report coverage, ownership and decisions to leadership, and plan the wider rollout.
Sargha produces this inventory from read-only discovery and connectors, with ownership routing and an AI Bill of Materials. The free assessment covers up to 25 endpoints. See data inventory and the assessment.