Enterprise AI Inventory
An enterprise AI inventory is the authoritative, maintained record of every AI system the organization uses — standalone tools, enterprise platforms, model APIs, agents, and AI features embedded in existing software — together with who owns each one, what it is for, who uses it, what it costs, and its governance status.
It is the least glamorous artifact in an AI program and the one everything else depends on. Governance scope, budget planning, renewal strategy, enablement targeting, risk assessment, and any credible ROI statement are all derived from it.
What belongs in the inventory
Scope is where most inventories go wrong — usually by being too narrow. Include all six categories:
- AI tools. Standalone products bought for a team or individual: writing assistants, meeting notetakers, research tools, design and code assistants.
- Enterprise AI platforms. Broad, organization-wide deployments such as productivity-suite assistants or developer assistants covering many users.
- Model APIs. Direct consumption of model providers by internal applications and services, billed by usage rather than seats.
- Agents and automations. Scheduled or event-driven processes that call a model and act, including low-code builds. These are frequently missed because nobody bought anything.
- Embedded AI features. AI capability switched on inside software the organization already owns — a real deployment that no procurement record will ever show.
- Third-party and contractor AI. AI used by agencies and contractors on your work product, where your contract terms rather than your admin console govern it.
A reusable inventory framework
The following field set is deliberately implementable in a spreadsheet on day one and portable to a platform later. Each field exists to support a specific decision; if a field supports no decision, drop it.
| Field | What it records | Decision it supports |
|---|---|---|
| System name | Product or service, and vendor | Deduplication and consolidation |
| Category | Tool, platform, API, agent, embedded feature | Proportionate oversight |
| Business purpose | The work it is used for, in one sentence | Overlap detection, retire or keep |
| Accountable owner | Named person, not a team | Everything; unowned systems cannot be governed |
| Department(s) | Which parts of the organization use it | Cost attribution, enablement targeting |
| Eligible population | Who is intended to use it | The denominator for adoption |
| Licensed seats | Seats purchased or assigned | Utilization and resizing |
| Active users | Who actually used it in the period | Adoption and renewal decisions |
| Commercial model | Per seat, metered, bundled, free tier | Correct cost treatment |
| Annual cost | Fixed plus variable, in the contracted currency | Spend consolidation and ROI denominator |
| Contract dates | Start, renewal, notice period | Renewal leverage |
| Data sensitivity | Classes of data the system may touch | Risk classification |
| Governance status | Approved, conditional, under review, retiring | Coverage reporting |
| Claimed value | Documented assumption or recorded outcome, marked as which | Honest ROI |
| Data source | Automated sync, CSV import, or manual entry | Confidence in every other field |
| Last verified | Date the entry was last confirmed | Detecting inventory decay |
The last two fields are the ones teams tend to omit and later wish they had. Without a source label, a confident estimate and a synced measurement look identical. Without a verification date, nobody can tell which half of the inventory has quietly gone stale.
Building the first version
- Agree the definition and scope. Decide explicitly whether embedded features and agents are in scope. They should be.
- Pull from existing systems. Procurement, expense and card data, identity logs, SaaS inventory, cloud and model billing, and admin consoles of platforms you already run.
- Interview department leads. Fifteen minutes each, framed as discovery rather than audit, to capture what the logs cannot.
- Reconcile into one record per system. Merge duplicates, note conflicts, keep the confidence level visible.
- Assign owners. Every entry gets a named person. Unowned entries are the ones that decay first.
- Classify and prioritize. Sort by spend and by data sensitivity; work the top of each list first.
- Publish it. An inventory nobody can see does not change behavior. Make it visible to the functions that need it.
Detection detail: how to detect Shadow AI.
Keeping it alive
Inventories fail by decay, not by construction. The organizations that keep one useful do three things: automate the fields that can be automated, set a verification cadence for the fields that cannot, and attach the inventory to a recurring decision — a quarterly renewal and consolidation review — so that keeping it current has an immediate payoff for the people maintaining it.
- Refresh seats, active users, and metered spend automatically wherever the platform exposes them.
- Re-verify owner, purpose, and population twice a year, and after any reorganization.
- Add a discovery pass to the calendar rather than waiting for the next incident to prompt one.
- Track coverage explicitly: what share of known AI spend has an owner, a purpose, and usage data.
From inventory to intelligence
A complete inventory answers "what do we have". The questions leadership asks next — is it used, is it worth it, should we consolidate — need adoption, spend, and value data attached to each entry and refreshed over time. That is the step from an inventory to Enterprise AI Intelligence, and it is why AI visibility is treated as an ongoing capability rather than a project.
Midgentic maintains this record as live infrastructure: automated connectors supply seats, active users, and activity for supported platforms; every other provider is recorded manually or by CSV with its license terms and cost; and each figure carries its source. Governance status and value assumptions sit alongside the usage data rather than in a separate document that disagrees with it.
Frequently Asked Questions
What is an enterprise AI inventory?
It is the maintained record of every AI system an organization uses — tools, platforms, model APIs, agents, embedded AI features, and contractor AI — with the owner, business purpose, user population, cost, usage, and governance status of each.
What should be included in an AI inventory?
At minimum: system name and vendor, category, business purpose, accountable owner, departments, eligible population, licensed seats, active users, commercial model, annual cost, contract dates, data sensitivity, governance status, claimed value with its basis, the data source for each figure, and the date last verified.
Should AI features inside existing software be in the inventory?
Yes. Embedded AI is a real deployment with real data handling, and because no purchase decision was made it appears in no procurement record. Inventories that exclude it systematically understate the estate.
How often should an AI inventory be updated?
Seats, active users, and metered spend should refresh automatically wherever the platform allows. Owner, purpose, and population should be re-verified at least twice a year and after any reorganization, with a discovery pass on the same calendar.
Can an AI inventory start as a spreadsheet?
Yes, and most usefully do. The field framework above is deliberately spreadsheet-implementable. The limitation appears later: manual inventories decay, and usage and spend figures age faster than anyone can maintain them by hand.