AI Model Inventory Management: Why the Request Layer Is the Only Accurate Source

Cloud Radix reported that 78% of employees use unauthorized AI tools at work and that 86% of IT leaders are blind to those interactions. An AI model inventory built by asking teams what they use inherits both numbers. It captures the sanctioned tools people are willing to name and misses the traffic that makes up most of the risk. The inventory ships, gets marked complete, and describes a fraction of the AI actually running in the organization.

I want to walk through what a usable AI model inventory contains and why the only source that keeps it accurate is the layer where AI requests actually flow.

Why survey-based inventories decay

A survey inventory is a snapshot of what people remembered to report on the day they were asked. It decays immediately for three reasons. New tools enter through browser extensions and IDE plugins that never touch procurement. Existing tools add AI features to products already in use, so a sanctioned SaaS tool quietly becomes an AI endpoint. And agents spawn calls to models the original approval never contemplated.

None of these show up in a form. IBM found that one in five breached organizations had a breach linked to shadow AI, which is the same blindness measured from the incident side. An inventory that cannot see unsanctioned usage cannot scope the risk, and every downstream governance artifact built on it inherits the gap. The shadow AI problem is at root an inventory problem.

What a usable inventory records

A model inventory that supports governance carries more than a model name. Each entry describes a route that AI traffic actually takes, with the fields an auditor or responder will ask for:

The data_classes_seen field is the one a survey can never fill. It records what data has actually moved through the route, which is often broader than what was permitted. The gap between data_classes_permitted and data_classes_seen is a governance finding the inventory surfaces on its own. first_observed and last_observed turn the inventory into a living record rather than a dated spreadsheet.

The request layer as source of truth

An inventory stays accurate when it is generated from observation rather than declaration. The AI request layer sees every call to a model, sanctioned or not, because the call has to traverse it to reach the provider. That makes the request layer the discovery mechanism a survey cannot be. A new route appears in the inventory the first time a request takes it, not the next time someone updates a form.

This is what connects the inventory to the rest of the program. The governance implementation roadmap puts discovery in its first phase for exactly this reason, and the governance metrics that report coverage draw their denominator from this inventory. An inventory generated at the request layer also feeds the incident response plan, because responders cannot act on a route the inventory never recorded.

DeepInspect

DeepInspect generates the inventory as a byproduct of enforcement. It sits at the AI request boundary as a stateless proxy between authenticated users or agents and any LLM, and every request to a model passes through it.

Because the proxy is on the path, it observes routes as they are used, records the identities calling each one, and captures the data classes that actually cross the boundary. The inventory populates from live traffic, so data_classes_seen reflects reality and a new shadow route surfaces the moment it is first called. The same enforcement point that discovers a route can then apply policy to it, which closes the loop between finding an ungoverned model and governing it.

If your AI model inventory was built from a survey, it is describing the tools people named and missing the ones that matter. Let's talk today.