Early pricing is live. Access is by request — ask with an email address.Early pricing is live. Access is by request.

AI system inventory

A living inventory of every AI system and agent

An AI system inventory is one continuously updated record of every AI system, model, and agent your company runs: what each one is, who owns it, what it costs, and what stands behind its claimed return. It shares a word with warehouse stock software and nothing else — the assets on this list are software, not shelves.

This page is for the Head of AI, the governance lead, or the operator who has been asked for the list — every system, who owns each one, and what the estate costs and returns. The decision it serves is the renewal decision: which systems keep their funding, which are retired, and what you show a board or an auditor when they ask.

Published August 21, 2026 · Last reviewed August 21, 2026

What an AI asset inventory holds

One record per system or agent. Each record names an owner, states the system’s purpose, and carries three running figures beside it: what the system costs, what value has been claimed for it, and how much of that claim is evidenced. Open risks and evaluation results sit on the same record, so “is this worth running” and “is this safe to run” are answered from one place instead of two tools that have never met.

Names for the artifact vary. Some organizations call it an AI asset inventory or an AI system register; large companies often say enterprise AI inventory. Others keep an AI use case inventory — a list of approved uses rather than of running systems. Keep the use case on the system’s record rather than in a separate list: a use case is a claim about what a system is for, and it is only worth reviewing next to what the system actually did. The longer argument is in why value streams, not use case lists, are the thing to review.

An AI agent inventory is the harder half

A chatbot answers a question. An agent takes actions — it files the ticket, drafts the refund, commits the change. An inventory of agents therefore has to hold more than a license list: what each agent is allowed to touch, who signed for that, and what it did with the authority. The difference is worth ten minutes: why an agent commits the enterprise in a way a chatbot never did.

An agent inventory also has to keep itself current, because agents multiply faster than any registrar. In Oabo, an agent enrols itself by sending one telemetry event — the record begins because the agent ran, not because someone remembered to type it in. The list stays what runs, rather than what was declared.

How a living inventory works

Five steps, and the loop runs continuously rather than once a year.

Inputs. Usage and spend arrive through four doors, chosen per machine or per account: an API gateway that attributes each call, the vendor accounts your teams already pay for, developer machines, and a managed-fleet file staff cannot switch off. Nothing is ever written back to a source system.
Records. Every system and agent lands as one record with a named owner, and costs attach to the record that incurred them — so one monthly bill stops hiding three side projects.
Evidence states. Every value claim carries a stage — Potential, Claimed, Verified, Hardened — and the stage is set by the server, never by the claim’s author. A move up always means a second person looked.
Outputs. A readout of cash, hours, and how much is verified, and a signed audit pack an auditor can check without us in the room.
Decision. Renew, retire, or fund the next system — made on figures that carry their evidence with them.

You can walk one worked claim through this loop on sample data without an account, or read the same walk narrated station by station.

Shadow AI discovery

The inventory you are asked for is never the inventory you have. Subscriptions land on card statements nobody reviews, and teams build assistants on a shared account without telling anyone — not from bad faith, but because nobody asked. Discovery is why the inventory must be fed by what runs rather than by what is declared: the fleet file counts every seat from its first day, the gateway attributes each call, and the vendor-account door surfaces seats that never sign in. The declared list and the discovered list will not match. The gap is the finding.

For the shape this usually takes, see the software company whose one API bill hid three quiet assistants.

Cost, value, and evidence — not just exposure

Most software sold as an AI inventory today is security software. It maps your systems to find exposure — what data each one can reach, which endpoints are open — and that is a real job someone in your company should own. But an inventory that stops at risk cannot answer the renewal question, and that question is getting louder: paying for AI is now normal, while saying what it earned is still rare. An inventory built for the value question ties each system to what it costs, what it returned, and the evidence behind the return — the three things the exposure-mapping tools leave out.

Doing that honestly means keeping four kinds of value apart, because they are not the same kind of fact: realized cash, capacity hours, structural-value attestations, and modeled estimates. Cash means a ledger event. Hours stay hours and are never priced into cash. Structural changes are separately signed attestations on their own expiry clocks. An estimate stays labelled an estimate for as long as it is one. A tool that adds these together is manufacturing a number nobody will defend in front of a board.

Regulatory drivers: ISO/IEC 42001 and the EU AI Act

ISO/IEC 42001, the management-system standard for AI, expects an organization to know and document the AI systems inside its scope. An inventory is where that work starts, not where it ends. EU AI Act readiness starts in the same place: obligations attach system by system, according to the role you hold and the risk class each system falls into, and you cannot classify a system you have not listed.

The boundary is worth stating plainly. Oabo provides the inventory and the evidence record behind it — who owns each system, what it does, what it costs and returns, and who signed. It does not certify compliance with ISO/IEC 42001, the EU AI Act, or any other framework, and no software alone can. A regulated-industries pack — an off-by-default module with a compliance-framework library and per-agent attestations — is a separate item on the roadmap, not part of the inventory today.

How it compares to what you may already have

Each of these is good at its own job. None of them is a living inventory, and the fair comparison is to say where each one stops.

A spreadsheet
Where most inventories start, and it answers the first audit. It has no way to notice a system it was never told about, and it says nothing about whether its rows are still true. It records what someone remembered to type in, on the day they typed it.
A one-time assessment
Tells you what ran the quarter it was written. It ages the day it is delivered, and the estate it describes changes faster than the next engagement can be scoped.
A cost dashboard
Tells you what you spent, accurately. It does not say who owns each system, what the spend returned, or what evidence stands behind the return — and it has nothing to show when the number is challenged.
A model registry
An engineering tool: versions, weights, deployment lineage. The right record for the team that ships the model, and the wrong altitude for the buyer question — it prices nothing and holds no sign-off.
A broad GRC suite
Holds policies and attestations across the whole company. AI systems appear in it as rows to attest, not as running software with a cost and a return. Pair one with a live inventory rather than asking it to be one.

What Oabo does and does not do

It does:

Keep one record per AI system and agent — named owner, purpose, costs, value claims, open risks, and evaluation results.
Set the evidence stage on every figure server-side, and add a linked event to the organization’s hash chain for every application write, preserving reviewable history.
Read from your systems through the four doors above, and never write back.
Produce signed audit packs an auditor can verify independently.

It does not:

Verify your value claims against your books. A person still names the general-ledger event behind a claim and signs for it.
Certify compliance with ISO/IEC 42001, the EU AI Act, or any other framework.
Hold a SOC 2 report today. If your review needs one, say so before you start rather than after.
Accept protected health information or payment card data — both limits are written into the terms.
Offer self-serve signup. Access is requested with an email address and approved by a person.

Questions buyers ask

What should an AI system inventory include?

At minimum: the system’s name and purpose, a named owner, where it runs, what it costs, what value is claimed for it and at what evidence stage, and which risks are open. Before adding a field, decide how it will stay current — cost is the usual casualty — or the inventory decays into last quarter’s spreadsheet.

How is this different from a model registry?

A model registry tracks versions, weights, and deployment lineage for the team that ships the model. An AI system inventory is the management record — owner, cost, return, risk — for the people deciding whether to keep funding it. Most companies that need one need both, and neither substitutes for the other.

How do you find the AI nobody registered?

By watching the places AI has to pass through rather than asking people to declare it: the fleet your machines report through, the gateway your calls route through, and the vendor accounts your company pays for. Self-declaration finds the systems people are proud of. The doors find the rest.

Who should own the AI inventory?

One named person — usually the Head of AI or a governance operator — and one named owner per record, which matters more. An inventory whose rows have owners answers questions by itself. An inventory owned only in aggregate turns every question into a hunt.

How often should it be updated?

Continuously, by the systems themselves. A review cadence — quarterly is common — is for judging records, not for creating them. If discovering a new system depends on the review meeting, then the meeting is your inventory, and it runs four times a year.

Does an inventory make us compliant with ISO/IEC 42001 or the EU AI Act?

No. Both frameworks expect you to know your systems, so an inventory is a starting condition, and neither framework stops there. What an inventory changes is the shape of the work: you argue about what each system must satisfy, instead of arguing about what exists.

How do we start?

With one record. Ask for access with an email address; an approved request comes back as one link that opens your workspace, and in the first hour you can register an agent, record what it costs, and enter your first value claim. To see the loop before asking, walk the worked example above.

The list stays current because the systems report

Oabo Scorecard keeps the inventory of every AI system and agent — owner, cost, value, evidence — as a living record rather than an annual project. Plans are priced by the number of AI systems you track, which is the count this page is about.

Request access See how Oabo works