The AI Estate: How to Inventory Your Models, Agents and Data Flows
How to inventory your AI estate: models, agents, tools and data flows, with a sample schema for risk tiering.
An AI estate inventory is a living register of every model, agent, tool, dataset and data flow your organisation uses or depends on, with an owner and a risk level against each. You build it by combining discovery from systems (network, identity, billing, code), declaration from teams, and verification against what actually runs. It is the first practical step toward Sovereign Intelligence, because sovereignty is the ability to retain meaningful control over your AI estate, and you cannot control what you have not listed. This post gives a method, a sample schema and the link from inventory to Trust Profiles and risk tiering.
What is the AI estate, exactly?
The estate is wider than "the AI projects we approved". It includes everything that makes AI happen in your organisation:
- Models: hosted APIs, open-weight models you run, fine-tuned or tailored variants, and models embedded inside SaaS products you buy.
- Agents and assistants: custom agents, copilots inside productivity tools, coding agents on engineers' machines, and bots in chat tools.
- Tools and connectors: the systems agents can call, such as ticketing, CRM, email, code repositories and databases.
- Data and context: knowledge bases, vector indexes, memory stores, prompt libraries and evaluation sets.
- Infrastructure: inference hosts, GPU capacity, gateways and the networks between them.
- Suppliers: every company in the chain, including the ones one step removed, such as the hosting provider behind a model vendor.
The last item matters more than it looks. The supply-chain sovereignty view treats vendors, models, infrastructure and critical dependencies as one chain, and an inventory that stops at the first vendor stops too early.
Why does the inventory come first?
Three reasons, in order of how often they bite.
You cannot assign accountability to what you cannot name. Every governance control, from access rules to approval thresholds, attaches to a specific system with an owner. Without the list there is nothing to attach it to.
Risk is a property of the use, not the model. The same model can power a harmless summariser and a decision aid in a regulated process. Risk tiering needs the use case, the data and the action rights, which only an inventory with context captures.
Regulation increasingly assumes you know. The EU AI Act's obligations depend on classifying what you provide or deploy. Article 4 on AI literacy has applied since 2 February 2025, and the Digital Omnibus on AI, in force since 27 July 2026, moved stand-alone high-risk obligations from 2 August 2026 to 2 December 2027 and embedded-product obligations to 2 August 2028, per Gibson Dunn's summary. General-purpose AI obligations applied from 2 August 2025 and were not deferred. Whatever applies to you, the first question a reviewer asks is "what AI do you have, and what does it do?". Whether a given system falls into a high-risk category is a legal judgement for your counsel, informed by the inventory.
Where do you discover what is running?
No single source is complete. Use several, and treat disagreement between them as the finding.
| Discovery source | What it reveals | Blind spot |
|---|---|---|
| Identity provider and SSO logs | Which AI services people sign in to | Personal accounts, API keys |
| Network and DNS egress | Calls to model providers and AI SaaS | Traffic from unmanaged devices |
| Cloud and billing records | Paid model APIs, GPU instances, vector databases | Free tiers, credits |
| Code and configuration search | SDK imports, API keys in config, agent frameworks | Closed-source SaaS features |
| Procurement and contracts | Approved vendors with AI clauses | Tools bought on a card |
| Browser and endpoint tooling | Extensions, local models, desktop assistants | Tools used off-network |
| Team declarations | Intent, owner, purpose | Anything people forget or avoid declaring |
Shadow AI is the usual gap: tools adopted by individuals or teams without review. The shadow AI analysis explains why a ban rarely works and why a sanctioned alternative does better. The practical stance for the inventory is amnesty-first. Make declaring a tool safe and useful, for example by promising a fast review, and the list improves quickly.
What should each inventory entry record?
Keep the schema small enough that people fill it in and rich enough that controls can attach. The fields below are a starting point, and several map directly onto the Trust Profile, the record kept for every AI system.
| Field | Why it matters | Maps to Trust Profile field |
|---|---|---|
| System name and unique ID | Everything else hangs off it | Identity |
| Business owner and technical owner | Accountability and escalation | Owner |
| Purpose and users | Risk depends on use | Risk level |
| Model or models used, and versions | Approval, evaluation, retirement | Approved models |
| Data classes read and written | Residency and access rules | Data classification |
| Where data is processed and stored | Residency and transfer analysis | Data residency |
| Systems and tools it can reach | Blast radius | Permitted systems |
| Actions it can take | Authority | Allowed actions |
| Actions it must not take | Limits | Restricted actions |
| Approval rule | Human oversight | Human approval rule |
| Retention of prompts, outputs and traces | Privacy and evidence | Retention |
| Logging and audit coverage | Traceability | Audit |
| Policies that apply | What it is governed by | Policy set |
| Suppliers and sub-processors | Supply chain | Not in the profile, tracked separately |
| Date reviewed and next review | Keeps the register alive | Not in the profile, tracked separately |
Notice what is absent: fields nobody can maintain. A register with fifty columns is dead within a quarter. Start with the ten that drive decisions.
How do you map data flows?
A data-flow map answers "what leaves, where does it go, and under whose control?" For each system, sketch four things.
- Inputs: which sources feed prompts and context, and under what permissions.
- Processing: which model and which host handle the data, and in which jurisdiction. The data sovereignty deep dive lists the five controls to check: location, access, processing, transfer and retention.
- Outputs and actions: where results are written and which systems the agent can change.
- Side channels: logs, analytics, caches, evaluation datasets and support tooling, which often carry copies of prompts. These are the flows people forget.
Draw the organisation boundary on the map and mark every arrow that crosses it. For each crossing, record the legal basis and the contract term that governs it. Where a provider is subject to non-EU law, remember that the location of the data and the control over it are different questions. The US CLOUD Act, for example, lets US authorities compel US-based providers to disclose data in their possession, custody or control regardless of where it is stored, as analysed by CSIS. That is a reason to record the provider's corporate jurisdiction as a field, not just the data-centre country.
How do you handle agents and their tools?
Agents deserve their own pass because their risk is in what they can do, not only what they can read. For each agent, list every tool and connector and the credential it uses. Ask:
- Does the agent act with its own identity or a shared key?
- Are credentials scoped to the minimum and short-lived, or standing and broad?
- Which tool calls are read-only, which write, which are irreversible?
- Is there a path to the same systems that bypasses any enforcement point?
Tool protocols make this both easier and harder. The Model Context Protocol, donated to the Linux Foundation's Agentic AI Foundation in December 2025 (announcement), gives you a standard way to connect tools, which means a standard place to count them. It also makes it quick for anyone to attach a new tool server. Include MCP servers in the inventory as first-class entries. The MCP interoperability post covers the protocol and multi-agent systems covers orchestration.
How does the inventory feed risk tiering?
Once entries exist, assign each a risk tier using a few questions that anyone can answer.
| Question | Raises the tier when |
|---|---|
| What data class does it touch? | Confidential or restricted data, personal data of sensitive kinds |
| What can it do? | It writes, sends, pays or changes records |
| Is the action reversible? | Hard or impossible to undo |
| Who is affected? | Customers, employees or the public rather than internal drafts |
| How much human review sits between output and effect? | None, or review is nominal |
| Is it a regulated use? | It falls into a category your counsel flags |
Combine the answers into a small number of tiers, low, medium and high is enough, and attach default controls to each tier. A low-tier read-only summariser needs identity, logging and an approved model. A high-tier agent that touches customer accounts needs approval rules, tighter monitoring and a documented review. The tier then sets the starting autonomy level: high-tier systems begin at L1 Assist or L2 Approve and move up only on evidence, as laid out in the controlled autonomy rollout plan.
How do you keep the inventory alive?
A register decays unless it is wired into how work happens. Four habits help.
- Make the inventory the gateway to access. If a model, key or tool is only issued to registered systems, registration becomes the easy path.
- Automate the boring fields. Pull model versions, data sources and tool lists from the platform where possible, so people confirm rather than type. A platform with a model gateway, such as Connect, already sees which models are called.
- Review on events, not only on calendar. A new data source, a new tool or a model change should trigger an update.
- Retire explicitly. Decommissioned systems stay on the list with a retired date, so ghosts, such as old keys that still work, can be found.
The enterprise AI workspace rollout checklist shows how an inventory fits into a phased rollout, and step 1 of the build guide shows where it sits in the larger sequence.
What are the common mistakes?
- Scoping to approved projects only. The unapproved ones are where the surprises are.
- Recording models but not uses. Risk follows use.
- Forgetting embedded AI. SaaS products add AI features through updates. Ask vendors for a list of AI features and sub-processors, and compare with the sub-processor list you publish or receive.
- One-off spreadsheet. A snapshot is out of date the day it is circulated.
- No owner for the register itself. Someone must be accountable for its quality, usually in the CIO's or Chief AI Officer's office. See the Chief AI Officer page.
Where to go next
Start with a one-week sprint: pull identity, network and billing data, ask each team to declare what they use, and reconcile the two. Then attach owners and risk tiers. When you want to see where that leaves your readiness, take the self-assessment, which runs entirely in your browser. If you would like help scoping an estate review, talk to our team. The wider framework is in the Sovereign Intelligence pillar, and the glossary defines the terms used here.
Further reading: AI Usage and Cost Analytics: FinOps for Models and Agents.