Platform
Know what AI exists across your organization
A real inventory of every AI system running in the organization, showing who owns each one and whether anybody has yet taken responsibility for it.
What a row has to carry
- A named person, not a team alias
- An attested identity of its own
- A declared reach, system by system
- A rule evaluated at the action
A row missing any of the four is a finding rather than an entry. What counts as an AI system.
The estate, counted
Eleven systems, six people, four autonomy levels.
An inventory is only useful at the resolution of a single row, so the numbers here are a way in rather than the answer. The interesting figure is the last one: the systems that are not simply running normally.
AI systems
11
declared, owned and governed
Accountable people
6
named, not aliased
Teams
6
no central AI committee
Needing attention
2
watched or dropped to read-only
IllustrativeFigures from the OpsAI sample estate — a fictional company, used to show the shape of an inventory rather than the size of one.
A list without owners is not an inventory.
The column that makes this document worth keeping is the second one. Everything else can be rebuilt from logs; a named person who has accepted responsibility for a system cannot be inferred from anything.
The inventory itself
Every AI system, and the person who answers for it.
One row per system. Reach is shown as the enterprise systems each one can actually touch, because that is the column people are surprised by — an agent's name says nothing about how far it gets.
AI system inventory
11 systems · 6 accountable people| AI system | Answers for it | Runs for | Autonomy | Reach | State |
|---|---|---|---|---|---|
| refund-resolver | Priya NairSupport Ops | Support Ops | L3Act with approval | RazorpayZendesk2 actions | Acting |
| order-lookup | Priya NairSupport Ops | Support Ops | L1Observe | Zendesk1 action | Acting |
| ap-invoice-agent | Rahul MenonFinance | Finance | L2Advise | Zoho BooksRazorpayX2 actions | Acting |
| payout-runner | Rahul MenonFinance | Finance | L4Act autonomously | RazorpayX1 action | Watched |
| vendor-onboard | Anita RaoProcurement | Procurement | L3Act with approval | NetSuite1 action | Acting |
| inventory-sync | Anita RaoProcurement | Procurement | L2Advise | Postgres1 action | Acting |
| tier1-support | Priya NairSupport Ops | Support Ops | L2Advise | GmailZendesk2 actions | Acting |
| crm-hygiene | Sneha IyerRevOps | RevOps | L1Observe | Salesforce1 action | Acting |
| claims-triage | Devang ShahClaims | Claims | L2Advise | SalesforceGmail2 actions | Acting |
| contract-reader | Kabir SenLegal | Legal | L1Observe | Box1 action | Acting |
| dunning-agent | Sneha IyerRevOps | Finance | L2Advise | Gmail1 action | Read only |
One row, expanded
Agents
Everything behind a single row: the framework it was built with, the model it calls, and what it has actually been doing.
The reach column
Tools
What each system may call, declared up front. Anything outside the declaration is refused, not reviewed later.
The other inventory
Models
Every model the organization calls, the version in production, and the owner who approved its use.
Read it by person
The same inventory, from the other end.
Sorted by system it is a catalogue. Sorted by person it is an accountability register, and it answers a different question: if this went wrong tonight, who is being called?
- Priya NairSupport Ops
- refund-resolverL3
- order-lookupL1
- tier1-supportL2
Highest autonomy held: L3 · Act with approval
- Rahul MenonFinance
- ap-invoice-agentL2
- payout-runnerL4
Highest autonomy held: L4 · Act autonomously
- Anita RaoProcurement
- vendor-onboardL3
- inventory-syncL2
Highest autonomy held: L3 · Act with approval
- Sneha IyerRevOps
- crm-hygieneL1
- dunning-agentL2
Highest autonomy held: L2 · Advise
- Devang ShahClaims
- claims-triageL2
Highest autonomy held: L2 · Advise
- Kabir SenLegal
- contract-readerL1
Highest autonomy held: L1 · Observe
Not all rows are equal
Governance in proportion, never uniform.
Treating every system as either locked down or fully trusted is what produces incidents. Over-restrict the simple ones and teams route around you; under-restrict the autonomous ones and the incident arrives on its own schedule.
- L1ObserveReads. Never writes.Light, targeted checks3
- L2AdviseProposes. A person commits.Output quality checks5
- L3Act with approvalActs inside a bound. Above the bound, a person co-signs.Meaningful review · audit trail2
- L4Act autonomouslyActs inside a bound, watched continuously, circuit breaker armed.Circuit breaker armed1
A level is a standing decision, not a rating.
Autonomy is a separate axis from risk. Risk describes how consequential one action is; autonomy describes what a system is allowed to do at all. A level-1 system can still request a critical action — it simply cannot commit one. So the ladder is deliberately not coloured like a severity scale.
Breaking a bound does not earn a warning. It drops the system a level, and coming back up is a decision a person makes — once a rule exists that would have stopped the thing that happened.
Currently not simply acting
2 systems- payout-runnerWatchedFinance · answers to Rahul Menon · L4 Act autonomously
- dunning-agentRead onlyFinance · answers to Sneha Iyer · L2 Advise
The honest part
An inventory covers what was declared.
This is the limit of the document, and stating it is what makes the rest of it trustworthy. Eleven tidy rows are not the same as knowing what is running.
- It covers what was declared
- Every row here was registered by somebody. That is a real achievement and it is not the same as coverage — the systems that cause incidents are usually the ones that were never registered at all.
- A missing owner is a finding
- A system with no named person is not assumed to belong to the team that deployed it. It is flagged, and it stays flagged until somebody accepts it. A team alias is not a name.
- Nominal ownership is still a gap
- A named owner who does not know they own it is a row that will pass an audit and fail an incident. Cross-team ownership is the usual signal, and it is worth reading the list for.
- Counting is not controlling
- An inventory tells you what exists. It does not stop any of it doing anything. The rows become controls when each one has a rule at the action.
The systems that matter most are the ones nobody registered.
A copilot that arrived with a seat licence, a scheduled job that quietly gained a model call, a SaaS feature that turned up in a release note. None of them passed through a build review, so none of them are on this page — and every one of them can change something in a system of record.
Also not on this page
The sample estate reaches 12 enterprise systems and one of them is deliberately unconnected. An inventory of AI systems and an inventory of what they can reach are two documents, and the second one is where a surprise usually lives.
After the count
Counting is the easy half.
An inventory is worth having on its own, and it changes nothing by itself. The rows become controls when each one has an owner who accepted it and a rule that is evaluated at the action.