You cannot govern what you have not enumerated. That much is uncontroversial. What surprises most organisations is that an AI inventory fails for reasons an asset inventory never does — the population is not on your network, it is created by people who do not think of themselves as builders, and the single most important field cannot be discovered by any tool.
The sentence that names the requirement. NIST AI RMF subcategory GOVERN 1.6 reads: “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.” ISO/IEC 42001 contains no control titled “AI inventory” — it contains several requirements you cannot evidence without one.
Plain-English explainer · ISO/IEC 42001:2023 · NIST AI RMF 1.0 · OWASP Top 10 for LLM Applications 2026 · Last reviewed August 2026
An AI inventory answers one question — what is running, on whose authority, with access to what — and it is harder than an asset inventory for three structural reasons. Most of the population lives inside vendor tenancies you do not scan. Most of it was created without a ticket, a purchase order or a change record, by people who would not describe themselves as building anything. And the field that decides everything downstream, intended use, exists only in somebody’s head until a human writes it down. A discovery tool will find agents. It will not find owners. That gap is the whole engineering problem of this exercise, and the reason a register built from tooling alone decays within a quarter. What follows is the inclusion test that keeps the register credible, the fields that make an entry worth maintaining, the enumeration path for each surface — custom GPTs, workspace agents, MCP-connected assistants and Copilot Studio agents — what to do about agents created by other agents and agents whose builder has left, and how the register earns its cost by driving risk classification rather than recording history.
Key Takeaways
- NIST AI RMF names the requirement directly at GOVERN 1.6 — mechanisms are in place to inventory AI systems, resourced according to organizational risk priorities. ISO/IEC 42001 has no control called “AI inventory”, but its Annex A requirements on resource documentation, technical documentation and intended use cannot be evidenced without one.
- Inclusion should turn on four observable properties rather than on whether something is called AI: is it shared with other people, does it persist between sessions, does it touch a data class you protect, and can it take an action rather than only produce text? Any one of the four means an entry.
- Over-inclusion is a real failure mode. A register of nine hundred entries where forty matter has no signal, nobody reviews it, and it is stale inside a quarter — so the exclusions have to be written down as deliberately as the inclusions.
- Discovery tooling is necessary and insufficient: it enumerates OAuth grants, published agents and gateway traffic, but it cannot supply the owner, the intended use, the sensitivity of what actually flows at runtime, or what an acceptable failure looks like.
- The three fields that decide blast radius are identity used, granted scopes and action capability — which is exactly how OWASP’s LLM03:2026 Excessive Agency decomposes: excessive functionality, excessive permissions and excessive autonomy.
- Agents created by other agents and agents whose builder has left are the two population problems no configuration database was designed for. Every entry needs a named owner and a deputy, and offboarding has to query the register by owner before the account is disabled.
- A register that does not change a decision is a spreadsheet. It earns its cost when a change of field value — a new connector, a model version, a widened audience — forces a re-review without anyone remembering to ask.
Not an asset inventory with a new column
Organisations that already run a mature configuration database usually approach this as an extension exercise, and the first two weeks go well. The difficulty arrives later, and it is structural rather than a matter of effort. Five differences account for almost all of it.
The population is not on your network. A server announces itself. A custom GPT does not: it exists inside a supplier’s tenancy, it has no address you can scan, and the only route to it is an administrative export from the product itself. The same is true of workspace agents, published low-code agents and every AI feature that arrives switched on inside a product you bought three years ago for something else.
Creation is not a project. There is no requisition, no architecture review and no change ticket. Someone in finance spends twenty minutes on a Tuesday configuring an assistant that reads a folder of contracts, and by Friday four colleagues use it. Nothing in that sequence touches a process designed to notice new systems, which is why waiting for people to declare things produces a register that is confidently wrong.
The unit of inventory is contested. For infrastructure the unit is obvious — a host, an account, a service. Here you have to choose between the model, the deployment, the agent configuration and the business use, and different teams will choose differently in the same week. The resolution that holds up is the deployed use, for reasons set out in the edge cases below, but the choice has to be made explicitly and written into the policy or the register fragments.
The properties that matter are behavioural. An asset record is about what a thing is. An AI entry is about what a thing may do, on whose authority, with which oversight — and those change without the thing changing. Adding one connector to an existing agent can move it from a curiosity to the most consequential item on the register without altering a single line of anything a scanner inspects.
It goes stale on its own. A provider updates a model, a vendor ships a feature into a product you already own, an MCP server adds a tool. Your entry is now wrong and nobody in your organisation did anything. Asset records do not generally behave that way, which is why the review-trigger field described below is not administrative decoration — it is the part that keeps the register true between reviews.
The practical consequence is a gap between the estate leadership believes it has and the estate an enumeration pass finds. That gap is the most common surprise in a first AI governance engagement, and it is rarely a story about rule-breaking. It is a story about capability arriving through channels that existing governance was never pointed at.
Inclusion is a test, not a vocabulary
“Is it AI?” is the wrong question, and it produces months of argument about whether a rules engine with a classifier counts. The question that produces a usable register is about consequence. There are four properties, any one of which means an entry. Shared with other people or acting on their behalf. Persistent, carrying instructions, memory, knowledge or a schedule that outlives a session. Sensitive, able to receive or retrieve a data class you protect. Or action-capable, able to change state outside the conversation. Whether a vendor markets it as an agent is irrelevant to all four.
| The thing in question | Verdict | Why, and what the entry has to carry |
|---|---|---|
| A personal chat session with the enterprise assistant — no connectors, no shared configuration | Out | The session is not an entry. The tenancy is: one register line for the approved assistant covering its data-handling posture, its identity integration and its connector policy. |
| A custom GPT one person built for themselves and never shared | It depends | Out while it is private, has no file knowledge base and calls no action. In the moment it is shared with anyone, given uploaded documents, or wired to an API — all three change what a failure would cost. |
| A custom GPT shared to a team with an uploaded knowledge base | In | Shared, persistent and holding data somebody classified. The entry needs the sharing scope, the data classes in the knowledge base, and who is accountable for what it tells colleagues. |
| A Copilot Studio agent published to a Teams channel | In | Shared, persistent, running under a configured identity and almost always connected to something. Publishing is the graduation event, and it is worth making publishing a permission rather than a default. |
| A workflow automation with one model step that drafts and sends customer email | In | Action-capable and externally visible, even though nobody in the organisation calls it an agent. The label is irrelevant, but the send capability is not. |
| A coding agent with write access to a repository or a CI credential | In | It can change what ships. Register it against the software supply chain, with the scopes it holds and the review gate that stands between it and the release branch. |
| A summarisation feature switched on inside a SaaS product you already own | In, against the existing system | Do not create a parallel system record. Add the AI-specific fields — what data the feature processes, the vendor terms that govern it, whether it is on by default — to the entry that system already has. |
| A model evaluated on synthetic data on one engineer’s laptop, no connectors, no real data | Out | Genuinely out, and saying so in the policy is what keeps the register credible. It becomes in the moment it sees production data, gains a tool, or is shown to anyone as a working capability. |
| An agent that creates other agents at runtime | In, by class | You register the parent, the template and the constraint envelope. The children are not individually pre-registered, but they must be enumerable after the fact from a log, and they must not be able to exceed the parent’s tools, identity or budget. |
The exclusions matter as much as the inclusions, and they should be written down with the same care. A register that tries to hold every prompt anyone has ever typed is not more rigorous. It is unreviewable, and an unreviewable register is abandoned. The signal you are protecting is that an entry means something — that when a reviewer opens the elevated tier they are looking at systems that can genuinely cause harm, not at a haystack assembled to demonstrate diligence.
What holds the two ends together is a graduation event. An experiment that gains any one of the four properties enters the register at that moment, and the entry route has to be cheap enough that nobody routes around it — a short form and a same-week answer, not a monthly board. If registering something is harder than not registering it, the register is measuring your process rather than your estate. The boundary with unsanctioned usage on personal accounts is a separate topic, covered in shadow AI governance, and the distinction between approving a supplier and approving a purpose is set out in vendor approval is not use-case approval.
The fields that make an entry worth keeping
One test decides whether a field belongs: does a decision change when its value changes? Fields that pass are maintained because people need them. Fields that fail are filled in once, never updated, and quietly discredit the register around them. The last column is the one to read carefully — it describes how each field fails in practice, which is usually more instructive than the definition.
| Field | What a useful entry contains | Why it is asked for | How it fails |
|---|---|---|---|
| Registry ID and name | A stable identifier that survives renaming, plus the name people actually use for it in conversation, plus any alias it carries inside the vendor console. | Every other record — an incident, a change, an approval, a review — has to point at something. Names drift, but identifiers must not. | Two entries for the same agent under a display name and a technical name, and a third that is the same thing again in a different team. |
| Accountable owner and deputy | Two named individuals, not a team, not a distribution list, not a function. The owner answers for intended use, and the deputy exists so the entry survives a resignation or a holiday. | Ownership is the field that makes every other field maintainable, and it is the first thing an assessor tests by asking the named person a question. | An owner who left in November. A team name that means nobody. A vendor account manager listed as owner of your use of their product. |
| Sponsoring function and business process | The business process the system serves — claims triage, first-line support, code review — and the function that funds it. | Risk is a property of the process, not of the model. The same summarisation capability is trivial in marketing and consequential in clinical intake. | The entry says “IT”, so the review lands on an engineer who cannot say what an unacceptable output would be. |
| Intended use — and declared out-of-scope uses | A paragraph a non-specialist can check a real usage against, plus an explicit short list of uses that are not approved for this system. | NIST AI RMF MAP 1.1 asks that intended purpose, context-specific laws, norms and expectations, and the prospective settings of deployment are understood and documented. ISO/IEC 42001 carries a dedicated Annex A control, A.9.4, on intended use of the AI system. | The single word “productivity”. It is not checkable, so scope creep is undetectable and no reviewer can ever say the system is being used wrongly. |
| Lifecycle status | Proposed, piloting, in production, deprecated or retired — with the date the status last changed and who changed it. | Status decides review depth and whether the entry belongs in the population an assessor samples from. It also stops pilots living for three years. | Everything is “active”, including four pilots that ended, so the register overstates the estate and nobody trusts the count. |
| Model, provider and version posture | Which model family and provider, whether the version is pinned or floating, and how you learn that it has changed. | A floating version means the system you assessed is not necessarily the system running today. That is a change-management fact, not a technical curiosity. | The field says the provider only. When behaviour shifts, nobody can establish whether anything changed or when. |
| Hosting and tenancy | Where inference happens: the vendor’s multi-tenant service, a dedicated tenancy, your own cloud account, or on-device. | Tenancy determines what you can log, what you can enumerate, what you can delete, and which contractual terms actually apply to you. | An entry that assumes your cloud controls apply to a capability that runs entirely inside a supplier’s tenancy. |
| Data classes in | The classes the system can receive — by your own classification scheme, not by adjectives — including anything it can retrieve through a connector rather than only what a user types. | Retrieval is the part teams miss. A system with a permissioned connector can reach far more than its user pastes into it. | “No sensitive data” written by someone who did not consider what the connected drive contains for the person invoking it. |
| Data classes out, and retention posture | What the system emits and where the output lands, plus the retention and training-use position for your plan tier as documented at the time of writing, with a date and a link. | Consumer and enterprise tiers generally differ in retention and contractual protection, and vendor terms change. What you record is the verified position and when you verified it. | A confident sentence about what a provider does with your data, written eighteen months ago, with no source and no review date. |
| Identity used | Whether the system acts as the invoking human under delegated authority, as its own service principal, or on a shared secret — and, for a service principal, who owns it and when its credential expires. | This determines whose permissions bound the blast radius and whether your access logs will attribute an action to a person or to nothing. | A shared API key in an environment variable, created by someone who has left, with no expiry and no owner. It is the single most common orphan. |
| Tools, connectors and granted scopes | Each tool or connector named, with the OAuth scopes or permissions actually granted — exported from the platform rather than described from memory. | OWASP’s LLM03:2026 Excessive Agency decomposes into excessive functionality, excessive permissions and excessive autonomy. Two of those three are read directly off this field. | The entry lists three connectors. The platform export lists nine, two of which carry write scopes nobody remembers approving. |
| Action capability | Graded rather than boolean: read-only, write to internal systems, send external communications, move money, deploy code, delete. Note which actions are irreversible. | Reversibility is the property that decides whether a mistake is an inconvenience or an incident, and it drives the human-checkpoint design more than model quality does. | A tick-box that says “can take actions: yes”, which tells a reviewer nothing about what the worst afternoon looks like. |
| Autonomy and human checkpoints | What proceeds unattended, what requires confirmation, what requires a second person, and what the reviewer is actually shown at the moment they approve. | A checkpoint that presents a summary the human cannot check is a rubber stamp with an audit trail, which is worse than no checkpoint because it manufactures assurance. | Approval fatigue: one confirmation dialog, forty times a day, always clicked. |
| Risk class and its basis | The class, the date it was set, and the two or three attributes that put it there — so the classification can be argued with rather than merely accepted. | A class without a basis cannot be re-derived when something changes, so it silently becomes permanent. | Every entry is “medium”, which is the classification scheme announcing that it has stopped working. |
| Review status and next review | Last reviewed, by whom, what they examined, next due date, and the list of change events that force a review before that date arrives. | This is the field that converts a register into a control. Without it there is nothing to sample and nothing to test. | A file modification date offered as evidence of review. It records that a cell was edited, not that anyone looked. |
| Dependencies | Upstream systems it reads, downstream consumers of its output, other agents it invokes or is invoked by, and the human process that consumes the result. | NIST AI RMF MAP 4.1 asks for documented approaches to mapping technology and legal risks of components, including third-party data or software. Dependencies are also how you answer “what breaks if we switch this off?” | Nobody knows that a reporting pipeline consumes the agent’s output, so the retirement decision quietly breaks a board pack. |
| Lineage | The registry ID of the entry this was copied from, the date of the copy, and what was changed in the instructions, the knowledge base or the connector set. | A fix applied to the original leaves every variant carrying the original defect, and a review of the original tells you nothing about the estate. | Eleven near-identical agents, each pointed at a different data source, with no way to tell which one the security review actually covered. |
| Logging location and retention | Where prompts, tool calls, outputs and administrative changes are recorded. The retention window, and whether that window exceeds your assessment period plus the lag before anyone asks. | Retention is usually a plan or edition setting rather than a platform property, and it is the detail that turns an orderly assessment into a scramble. | Thirty-day retention behind a twelve-month certification cycle, discovered during fieldwork. |
| Retirement plan and departure trigger | What happens when it is switched off: which access is removed, which identity is disabled, what happens to accumulated data, who is told — and the rule that fires when the owner leaves. | NIST AI RMF GOVERN 1.7 asks for processes and procedures for decommissioning and phasing out AI systems safely, in a manner that does not increase risks or decrease the organisation’s trustworthiness. | The entry is marked retired while the service principal is still authenticating successfully every night at three in the morning. |
Three of those nineteen are skipped almost universally on a first pass and regretted almost universally afterwards. Identity used is skipped because it feels like an implementation detail. It is in fact the field that decides whether an action is attributable to a person and whose permissions bound the damage — the subject of agent identity and delegated authority. Granted scopes are skipped because people describe connectors from memory. The platform export routinely shows more than the entry claims, and the difference is where excessive permissions live. And the retirement plan is skipped because nothing has been retired yet — which is exactly when it is cheap to write, and it is the field that prevents the orphan problem two sections below.
A note on where the register lives. It matters less than people expect, provided two things hold: entries are versioned so you can show what an entry said on a date inside an assessment period, and the register sits close to whatever process actually reviews it. A versioned table in the system your risk team already uses beats a specialised tool nobody opens. What does not work is a document, because a document cannot answer the question every assessor asks first, which is what the register said six months ago.
What one entry looks like filled in
Field definitions are easy to agree and hard to apply. Below is a single entry from the worked example further down this page — the scheduled agent that posts a weekly revenue summary into a leadership channel, as the entry reads at the end of the ninety-day pass. All nineteen fields, populated. It is illustrative, not a client. Read it for the shape of an answer rather than the content: every value is dated, every claim about a vendor carries the date it was verified, and every scope was exported rather than remembered.
| Registry ID and name | AIR-0034 · “Weekly revenue summary agent”. Console alias revsum-weekly. The ID is referenced by the impact assessment, the change records and two other entries that were copied from it. |
| Accountable owner and deputy | Owner: Head of Revenue Operations. Deputy: Finance Systems Lead. Both assigned 30 March 2026, after the claim step escalated the entry — the person who built it left in November 2025. |
| Sponsoring function and business process | Revenue Operations. The process is the weekly revenue read that goes to the executive leadership channel each Monday morning, ahead of the trading meeting. |
| Intended use — and declared out-of-scope uses | Reads booked revenue for the completed week from the warehouse, compares it to the same week in the prior quarter, and writes a five-line summary naming the three largest movements. It is a reporting aid: the figures it quotes exist in the warehouse and can be checked there. Two out-of-scope uses are declared, written so a non-specialist can test a real usage against them. (1) It does not forecast, and its output must not be presented as a forecast. (2) Nothing generated by it leaves the organisation — no customer, investor or board-pack text without the figure being re-derived from the warehouse first. |
| Lifecycle status | In production since 14 August 2025. Status last changed 30 March 2026, when ownership was reassigned. Changed by the AI governance lead. |
| Model, provider and version posture | Hosted general-purpose model on the provider’s default endpoint — version floating, not pinned. We learn about a change from release notes only, which is recorded on the entry as a known weakness. A pinned version was requested on 20 April 2026 and is open. |
| Hosting and tenancy | Vendor multi-tenant API, called from our own cloud account. The scheduler and the prompt assembly run in our tenancy and are logged there. Inference does not, and is not. |
| Data classes in | Confidential — booked revenue by customer, current and prior period. Internal — pipeline stage names. Both are retrieved through a read-only warehouse connector rather than pasted by a person, so the sensitivity does not depend on user behaviour. |
| Data classes out, and retention posture | Internal aggregate summary, posted to one channel. The provider’s documented retention and training-use position for our contract was read and recorded on 2 April 2026 with a link to the source. The entry carries a re-verification date at contract renewal, because vendor terms change and a statement without a date is not evidence of anything. |
| Identity used | Service principal svc-revsum-01, created 14 August 2025 with a non-expiring credential. Rotated 31 March 2026 and now set to a ninety-day expiry. Human owner: Head of Revenue Operations. This is the field that made the entry serious — the creator’s user account was disabled correctly on their last day and the agent kept running for four months. |
| Tools, connectors and granted scopes | Two connectors, scopes exported verbatim from the platform on 2 April 2026 rather than described from memory. Warehouse connector: read on two schemas. Chat connector: post-message on one channel — narrowed on 8 April 2026 from a tenant-wide post scope that nobody could account for approving. |
| Action capability | Write. One message, one channel, once a week. Reversible within twenty-four hours by deleting the message, but readable before it is deleted, which is why it is treated as irreversible in practice. No external send, no money movement, no deployment, no delete. |
| Autonomy and human checkpoints | Ran fully unattended on a Monday 06:00 schedule with no human between the model and the leadership channel. Changed on 27 April 2026: the draft now posts to the Revenue Operations channel first and the owner or deputy releases it, with the underlying warehouse query shown alongside so the reviewer is checking something rather than approving a summary of itself. |
| Risk class and its basis | Elevated. Set 24 March 2026. Basis, stated so it can be argued with: an action that is irreversible in practice, plus access to the confidential revenue data class. The non-human trigger is recorded as an aggravating attribute — it fails into an empty room at six in the morning. |
| Review status and next review | Last reviewed 24 April 2026 by the AI governance lead with the owner. What the reviewer examined is recorded: the scope export, and the last four posted summaries checked back against the warehouse. Next due 24 October 2026, semi-annual per the elevated tier. The seven change triggers are listed on the entry itself. |
| Dependencies | Upstream: the revenue warehouse table fct_bookings, read-only. Downstream: nothing automated — but the quarterly board pack has quoted this figure since December 2025, which is now recorded here, because that dependency is exactly the kind that a retirement decision breaks silently. |
| Lineage | Original. Two entries were copied from it in September 2025 — AIR-0039 (pipeline summary, different schema) and AIR-0040 (regional variant). Both inherited the un-narrowed chat scope and both were corrected on 8 April 2026. Without this field the scope fix would have been applied once and believed to be finished. |
| Logging location and retention | Prompt and tool-call records in the gateway log, and administrative changes in the tenant audit log. Default retention was 180 days, which does not cover a twelve-month cycle — extended retention was confirmed as available on our plan and enabled on 2 April 2026. Confirm what your own plan tier retains before citing a log as evidence. |
| Retirement plan and departure trigger | On retirement: disable svc-revsum-01, revoke both connector grants, notify the board-pack owner, retain twelve months of posted summaries, and change the status with a date and an actor. Departure trigger: if either the owner or the deputy leaves, this entry appears on the offboarding checklist before their account is disabled. |
Three things in that entry are worth noticing, because they are the three most teams leave out. The scopes were exported, not described — and the export found a tenant-wide post scope nobody could account for approving. The vendor retention position carries a date and a link, because a confident sentence about a provider with no source and no review date is not evidence of anything. And the lineage field turned a single scope fix into three, because the two entries copied from this one in September had quietly inherited the same defect.
A scanner finds agents. It cannot find owners.
Technical discovery is necessary. Nobody enumerates an estate this diffuse by asking, and the sources below routinely surface things no self-declaration exercise would have produced. It is also insufficient in a specific and predictable way: every one of these signals answers “what exists?” and none of them answers “so what?” The last column is the human question each source leaves open — and answering those questions is the actual work.
| Discovery source | What it reliably finds | What it structurally misses | The question only a person can answer |
|---|---|---|---|
| Identity provider — OAuth grants and enterprise app consents | Which third-party applications hold a token against your tenant, which scopes they were granted, who consented, and when. The strongest single starting point in most organisations. On Entra ID the path is Enterprise applications, then Permissions, and the same data is exposed through the Microsoft Graph oauth2PermissionGrants collection. Other identity providers expose an equivalent grant listing under a different name. | Anything reached without OAuth: a pasted API key, a personal account, a capability embedded in a product you already federated years ago. | Which of these grants is still needed, and who decided the scope was appropriate for the job it does? |
| Assistant and workspace admin consoles | Created and shared agent configurations — custom GPTs, workspace agents, published Copilot Studio agents — usually with a creator, a creation date and a sharing scope. Availability of these exports differs by product and plan tier, so verify what yours actually exposes. | Why the agent exists, whether the person who made it still works here, and whether the knowledge base it holds contains anything classified. | Is this shared with three people or three thousand, and does its creator still consider themselves responsible for it? |
| Egress proxy, CASB or DNS telemetry | Traffic to model-provider and AI-product domains from managed devices, which reveals usage that never touched procurement or identity. | Everything on unmanaged devices and personal networks, and the difference between an employee reading a vendor blog and an employee pasting a customer list into it. | Is this an approved system used unapprovedly, or an unapproved system altogether? The remedies differ. |
| Expense, card and procurement data | Paid subscriptions bought on a personal or team card. Often the fastest route to the tools a function has quietly standardised on. | Free tiers, which is where the most sensitive shadow usage tends to sit precisely because it left no financial trace. | What is this being used for, and would we have approved that use if we had been asked? |
| Code repositories and secret scanning | Model SDK imports, provider base URLs, API keys in environment files and configuration, and the services that call a model directly rather than through a gateway. | Whether the calling service is in production or a dead branch, what data reaches the prompt at runtime, and which customer-facing feature it powers. | Which product feature does this key serve, who rotates it, and what data reaches the prompt in production? |
| MCP client configuration and IDE agent settings | Which servers a developer assistant is configured to reach on a managed endpoint — file systems, ticketing, cloud consoles, internal databases. | What each server exposes today. A server can add or change tools without the client configuration changing at all, so the file tells you the connection, not the capability. | What can this assistant actually do this week, and who reviews it when the server adds a tool? |
| LLM gateway or API management logs | Volume, model, calling service and often the prompt-level record for everything routed through the gateway — the highest-quality signal available. | Everything that bypasses the gateway, which is precisely the traffic you most need to know about. Coverage is an assumption to test, not a fact. | What proportion of model traffic is on this path, and how would we detect a service that went around it? |
| Endpoint management and software inventory | Locally installed model runtimes, desktop assistants and browser extensions with page-reading permissions on managed devices. | Inference that never leaves the device produces no network signal at all, so nothing outside endpoint management will ever see it. | What leaves this device, under which licence terms, and is any of it customer data? |
Four fields recur in that last column, and no product will ever supply them. Ownership is a decision about accountability, not an observation — the creator of an agent is often not the person who should answer for it. Intended use is a statement of purpose that only exists once someone writes it. Data sensitivity at runtime depends on who invokes the system and what their permissions reach, which is a property of your classification scheme rather than of the traffic. Acceptable failure — what a wrong answer costs and who absorbs it — is a business judgement that a tool cannot even represent.
The operational shape that resolves this is a two-stage process rather than a single scan. Discovery produces candidates. A claim step converts candidates into entries: the apparent creator is asked to confirm ownership, state the purpose and answer three or four questions, within a stated window. Candidates nobody claims escalate to the head of the function they sit in — never to a shared mailbox, and never to nothing. The unclaimed items are not an administrative nuisance to be cleared. As the worked example shows, they are the most interesting output of the whole exercise.
One caution on method. Discovery that reaches into personal accounts, browsing history or device-level activity has employment, privacy and in several jurisdictions works-council implications, and it changes how people behave toward the programme. Scope the telemetry to organisational data leaving organisational systems, disclose what is collected, and take advice before extending it. A register built on surveillance gets one honest enumeration and then a much quieter estate.
Custom GPTs, workspace agents, Copilot Studio and MCP
Each surface has its own enumeration path, and the paths do not resemble each other. Product capabilities, admin exports and plan tiers change frequently — treat the routes below as the shape of the problem and confirm the specifics in current vendor documentation for your own tenancy and contract before relying on them.
| Surface | Where it actually lives | How you enumerate it | What the entry must capture |
|---|---|---|---|
| Custom GPTs in an enterprise assistant tenancy | Inside the vendor tenancy, created through the product UI by ordinary users with no admin rights. | The workspace or compliance admin console — the GPT listing and the compliance export, which returns creator, created date and sharing scope — plus any available admin API. Export creator, creation date, sharing scope and whether actions or file knowledge are attached, then confirm in current vendor documentation which of those fields your plan tier actually exposes to administrators, because the export surface differs by tier and changes. | Sharing scope, uploaded knowledge, configured actions and their scopes, and whether the instructions direct it to make claims on the organisation’s behalf. |
| Workspace assistants and saved agents in a productivity suite | Inside the suite’s identity and permission model, invoked from documents, mail and chat. | The suite admin console audit log, filtered to the agent-creation and agent-sharing event types, combined with the console reporting for the same feature. Which event types your edition actually emits differs by edition and changes — verify current availability rather than assuming the filter you wrote last quarter still returns everything. | Which corpus it can retrieve from at invocation time. Retrieval inherits the invoking user’s permissions, so the sensitivity of the entry depends on who uses it. |
| Copilot Studio agents | In a maker environment, published to channels such as a Teams chat, a website or an internal portal. | Environment-level administration in the Power Platform admin center: Environments first, then the agents inside each environment, then the connections bound to each agent. The PowerShell administration module exposes the same listing for a scripted export — confirm which cmdlets and which fields your tenant and licence expose before relying on it. The environment sprawl is the trap: a governance model that covers only the default environment covers only part of the estate. | The publication channel and audience, the connectors bound to it, whether it authenticates as the end user or as a stored connection, and who can edit it. |
| MCP-connected desktop and IDE assistants | On developer endpoints, configured per user, reaching internal systems through servers the developer chose. | Endpoint management for the client, plus collection of the per-user MCP client configuration file — a JSON file in the application support or configuration directory on macOS, the roaming application data directory on Windows, and the XDG configuration directory on Linux. Collect the server list from it, and treat a new server as a capability grant requiring review rather than as a preference change. Confirm the current file name and location for each client you actually deploy. | Each server, the credentials it holds, the tools it exposes today, and the review that fires when its tool surface changes. |
| Coding agents with repository or pipeline credentials | In the software supply chain: pull requests, CI jobs, sometimes deployment. | The organisation audit log, filtered to app-installation and machine-account events, plus the installed-app and deploy-key listings per repository and the CI credential inventory. On a hosted forge this is the organisation settings audit log and the installed GitHub Apps or equivalent integrations list. Self-hosted forges expose the same three things under different names. | Write scopes, whether its changes can reach the release branch without a human review, and which secrets it can read. |
| Model steps inside workflow automation platforms | Inside automation tools that predate the AI conversation and are usually governed by nobody in particular. | Platform administration: list flows, then filter for model connectors. Also look for outbound webhooks to provider domains from the egress data. | The trigger, the action it takes at the end, and whether the output reaches a customer without a human in between. |
| AI features embedded in SaaS you already bought | Inside a product with an existing contract, an existing owner and an existing system record. | Vendor release notes, tenant admin settings, and a direct question in the annual supplier review. Some features arrive switched on. | Whether it is enabled, the data it processes, the vendor’s documented position on retention and training use for your contract, and whether you can turn it off. |
| Model-backed features in your own product | In your codebase, shipped to customers, and therefore in the scope of the commitments you make to them. | Architecture review and repository scanning, reconciled to the product feature list. | Customer-facing disclosure, the failure modes you have committed to prevent, evaluation results, and the contractual and regulatory role you occupy when you ship it. |
MCP deserves a paragraph of its own, because it breaks an assumption the rest of the table relies on. Everywhere else, enumerating the client tells you roughly what the client can do. With the Model Context Protocol, the client’s configuration tells you only which servers it may reach. What those servers expose is decided on the server side and can change without any file on the endpoint changing. An assistant that could read a ticket queue last month may be able to close tickets this month because a server added a tool. The register entry therefore has to carry the server list, the credential each server holds and a review that fires on capability change rather than on configuration change — a distinction developed in MCP tool approval and capability change.
The other surface worth singling out is the low-code agent platform, because of environment sprawl. A governance model that inspects the default environment and stops there will produce a confident, incomplete count. List environments first, then agents within each, then the connections bound to each agent — and treat the ability to publish an agent to a customer-facing channel as a permission worth restricting rather than a capability everyone gets by default.
Agents that create agents, and agents nobody owns
Two properties of agentic systems defeat the register as usually designed. The first is that the population is dynamic: an agent can spawn sub-agents at runtime, and pre-registering each one is neither possible nor useful. The second is that entries outlive people, and the usual mechanism for keeping records accurate — the person who cares about it maintains it — stops working the moment that person changes team or leaves.
For agents that create agents, register the envelope. The parent gets an entry, and the entry describes the constraint envelope its children inherit: which tools they may use, which identity they act under, what budget or call limit bounds them, and how long they live. The governing rule is that a child may never exceed the parent — no tool the parent lacks, no scope the parent was not granted, no identity the parent cannot act as. Then the requirement on the implementation is that children are enumerable after the fact: a run log that lists every sub-agent instantiated, its task and its tool calls. You are not inventorying instances. You are inventorying the capability to create them, and retaining the ability to reconstruct what happened.
Scheduled and triggered agents belong in a higher tier than their function suggests. An agent invoked by a person fails in front of that person. An agent that runs at three in the morning on a cron trigger fails into an empty room, and the failure is discovered when somebody notices a consequence days later. Where an entry has a non-human trigger and an action capability, the review cadence should be shorter and the stop mechanism explicit — the subject of kill switches and circuit breakers.
Templates propagate. One well-made agent gets copied by eleven colleagues, each of whom changes the instructions slightly and points it at a different data source. Lineage is worth a field: which entry this was copied from, and what was changed. Without it, a fix applied to the original leaves ten variants carrying the original defect, and a review of the original tells you nothing about the estate.
Orphans are the concrete version of all of this. An analyst builds a scheduled agent that posts a weekly summary into a leadership channel. It runs on a service principal they created, with a credential that does not expire. They leave. Their user account is disabled correctly and on time — the offboarding control worked perfectly — and the agent keeps running, because it never used their account. Nobody maintains it, nobody reviews what it reads, and if it starts producing something wrong, nobody knows whom to ask. The failure is not that the agent survived the leaver. It is that the leaver process had no reason to look at it.
The fix is four small mechanisms rather than one large one. Every entry carries a named owner and a deputy, so there is always a second person to ask. Offboarding queries the register by owner before the account is disabled, and ownership transfer is a step with a name on it rather than an assumption. Every non-human identity in the register has a human owner and an expiry date, so an unmaintained credential eventually announces itself by failing rather than by quietly continuing. And a periodic reconciliation of register owners against the personnel roster catches whatever the first three miss — the same reconciliation pattern a user access review has used for years, applied to non-human principals.
Expiry deserves emphasis because it is the only one of the four that works without anybody remembering anything. A credential with a ninety-day life either gets renewed by someone who still cares about the agent, or it stops. Both outcomes are better than a token that authenticates successfully for three years after its author left the company.
One enumeration pass, ninety days
An illustrative composite, not a client. A 340-person B2B software company with an existing SOC 2 report covering Security and Confidentiality, now preparing for ISO 42001 certification. One enterprise assistant tenancy, a Microsoft estate, three cloud accounts. Read the middle column first — the dates are the point, because each stage depends on the one before it.
| Starting belief | 12 January 2026 | Leadership can name six AI systems: the enterprise assistant tenancy, a support-triage classifier, two customer-facing product features, a coding assistant and a marketing tool. The board has been told six. |
| Discovery | 13–23 January | Five sources are pulled: identity-provider OAuth grants, the assistant admin console, the Copilot Studio environment list, ninety days of egress telemetry, and card spend. A repository scan is added on day four. The raw candidate list reaches 138 items — including 71 custom GPTs, of which 9 are shared beyond their creator, and 12 published Copilot Studio agents across three environments nobody had listed before. |
| Triage | 26 January – 13 February | Each candidate is tested against the four inclusion triggers. 138 candidates become 41 register entries. 97 fall out as private and unconnected, duplicates of the same tenancy, or vendor domains that turned out to be documentation reading. |
| Claim | 16 February – 13 March | Every entry is sent to its apparent creator to claim, with a ten-working-day window. 34 are claimed. 7 are escalated to function heads. 2 are never claimed by anyone. |
| Classification | 16–27 March | 41 entries are classified from their own fields: 6 elevated, 14 standard, 21 minimal. The 6 elevated all share two attributes — an irreversible or externally visible action, and access to a class of data the organisation treats as confidential. |
| Treatment | 30 March – 30 April | The 6 elevated entries receive impact assessments. Connector scopes are narrowed on 3. The orphaned service principal is rotated, given a human owner and a ninety-day expiry. The unclaimed customer-facing agent is unpublished pending review. |
The interesting number is not 138. Raw discovery counts are easy to produce and almost useless — they inflate with the sensitivity of the query and they frighten boards without informing them. The number that mattered here was the distance between leadership’s six and the register’s forty-one: a factor of seven, made up almost entirely of things nobody had hidden and nobody had thought to mention. Nothing in the 138 was misconduct. The custom GPTs were people doing their jobs slightly faster.
The triage step is what made it survivable. A register of 138 entries would not have been reviewed in April, or in any other month. The 97 that fell out were not ignored — they were tested against a published rule and excluded on the record, which is a different thing from being overlooked, and it is the difference an assessor asks about.
The two entries that mattered most came from the claim step, not from discovery. Both had been on the discovery list since day three, and both looked unremarkable there: one scheduled job, one published agent. What made them serious was that when their apparent owners were asked to confirm, one had left in November and the other had moved teams and did not consider it theirs. The scheduled agent was posting a revenue summary into a leadership channel on a service principal created in August with a non-expiring credential. The published agent was answering questions in a customer-facing channel with nobody accountable for what it said. Neither would have been surfaced by any amount of additional scanning, because scanning had already found them. What was missing was a person.
The entry that matters is rarely the one that looked interesting on the discovery list. It is the one nobody would claim.
The whole pass ran to about ninety days at roughly one full-time equivalent across the period, most of it spent on the claim and classification stages rather than on discovery. Discovery itself was ten days of pulling exports. That ratio holds fairly reliably: the technical half is the cheap half, and any plan that budgets the other way round is planning for a list rather than a register.
A register that does something
An inventory that is only consulted when somebody asks how many AI systems there are will not survive its second year. The register earns its cost by classifying — by taking the fields it already holds and deriving, without a meeting, how much governance each entry deserves. The inputs are the ones you have collected: data classes, action capability, reversibility, autonomy and exposure.
| Class | What puts an entry here | What it triggers | Evidence the tier produces | Re-review |
|---|---|---|---|---|
| Minimal | Read-only, internal audience, no regulated or confidential data class, no connector holding write scopes, output always consumed by a human before it goes anywhere. | A register entry with a named owner and a documented intended use. Nothing else. Keeping this tier genuinely light is what makes the heavy tier affordable. | The register entry itself, plus a dated owner confirmation naming the person who gave it. | Annual confirmation by the owner — a two-minute check that the entry is still accurate. |
| Standard | Shared with a team, holds internal data, has connectors with read scopes, or produces output that materially informs a human decision. | Documented intended use with declared out-of-scope uses, a connector and scope review, logging that reaches the assessment window, and a named deputy. | The connector-scope export placed alongside the entry, and an annual review record that names what the reviewer actually looked at rather than that a review occurred. | Annual, plus re-review on any change event. |
| Elevated | Any one of: an irreversible action, an external communication or transaction, regulated or special-category data, a customer-facing deployment, or an effect on an individual’s access to a service, a price, or an opportunity. | An impact assessment, second-line review before go-live, a human checkpoint on irreversible actions with the reviewer shown something they can actually check, prompt and tool-call logging with defined retention, a documented stop mechanism, and a named accountable executive. | The completed impact assessment, the second-line sign-off with a date preceding go-live, prompt and tool-call logs with a stated retention window, the documented stop mechanism, and the re-review record produced by each change event in the period. | Semi-annual at minimum, and immediately on any change event. |
| Not permitted | Fully automated decisions producing a legal or similarly significant effect on an individual, unreviewed model output reaching a customer as a factual assertion, and any agent holding a standing credential that can move money. Most schemes omit this tier, and then discover they have no way to say no. | Either the use does not proceed, or it proceeds under a written exception approved by a named executive with an expiry date on it — an exception without an expiry is a policy change made by accident. | The exception register: the approver, the compensating control, the expiry date, and the quarterly review that either renews or closes each entry. | Quarterly review of the exception register, and closure at expiry unless renewed. |
The mechanism that keeps the classification honest is the change event. Cadence alone is not enough, because the thing that moves an entry between tiers rarely waits for a review date. Seven events should force a re-review regardless of when the last one happened: a model or version change, a new tool, connector or widened scope, a change in the identity the system acts under, an expansion of audience (particularly from internal to customer-facing), an incident or near miss, a change of owner, and a change in the supplier’s documented terms. Wiring those to the register — even crudely, as a required field update that opens a task — is what converts a record into a control that can be tested.
Where this lands in the standards
ISO/IEC 42001:2023 is a certifiable AI management system standard, and it contains no control titled “AI system inventory”. What it contains are requirements the register makes satisfiable. Determining the scope of the AI management system at clause 4.3 requires you to know what is in it. The AI risk assessment at clause 6.1.2 and the AI system impact assessment at clause 6.1.4 — whose methodology is set out in ISO/IEC 42005:2025, with Annex A.5 covering the assessment process and its documentation — both operate on a defined population of systems. Annex A.4.2 covers resource documentation, A.6.2.7 AI system technical documentation, A.6.2.8 recording of event logs, and A.9.4 the intended use of the AI system. Each of those maps to a field in the table above, which is not a coincidence: the schema was built backwards from what has to be evidenced.
NIST AI RMF 1.0 is more direct. GOVERN 1.6 names the inventory, and its supporting text describes it as an organised database of artefacts relating to an AI system or model — documentation, incident response plans, data dictionaries, links to implementation software, and contact information for the relevant actors. GOVERN 1.7 covers decommissioning. MAP 1.1 requires intended purpose, context-specific laws, norms and expectations and prospective deployment settings to be understood and documented, and MAP 4.1 asks for documented approaches to mapping technology and legal risks of components, including third-party data or software.
SOC 2 mentions AI nowhere, and that is worth saying plainly rather than implying otherwise. The 2017 Trust Services Criteria are technology-neutral, so an AI system is examined through the criteria you already have. The first point of focus under CC6.1 asks that the entity identifies, inventories, classifies and manages information assets. CC3.2 covers the identification and analysis of risks to objectives. CC9.2 covers vendor and business-partner risk. CC6.2 and CC6.3 cover access provisioning and least privilege, which is where a service principal with unreviewed scopes surfaces. CC8.1 covers change, and CC7.2 covers monitoring. A SOC 2 report is an attestation performed under AT-C 205 by a licensed CPA firm — there is no SOC 2 certificate, and no separate AI criterion to claim.
The EU AI Act allocates obligations by role — the provider of a system is treated differently from its deployer — and by the risk category the system falls into. The register is the input to both questions: without an entry recording intended use, deployment context and who put the system into service under whose name, you cannot determine which role you occupy for a given system, let alone which obligations attach. Application dates are staged and have been subject to legislative amendment, so verify the current text and timetable for your circumstances rather than working from a summary. Our own comparison is in ISO 42001 versus the EU AI Act, and the role question is developed in AI roles under ISO 42001.
OWASP’s Top 10 for LLM Applications 2026 contributes the sharpest test of whether your schema is doing any work. LLM03:2026 Excessive Agency decomposes into three root causes — excessive functionality, excessive permissions and excessive autonomy. If your register cannot answer all three for an entry, in the form of the tools it can reach, the scopes those tools hold, and what proceeds without a human, then the entry does not describe the risk it exists to describe. Cite the edition you mean when you use these identifiers in a policy: the item numbering moves between editions, and a control document referring to a bare “LLM06” will be read against whichever list the reader has open.
The crosswalk: requirement, field, artifact
This is the table to have open when an assessor asks how the register supports the management system rather than merely accompanying it. The middle column is the reason the schema has the fields it has, and the right-hand column is what actually gets handed over. Clause and control references are to ISO/IEC 42001:2023 and NIST AI RMF 1.0 as published — check them against your own copy of the standard rather than against a summary, including this one.
| Requirement | Standard reference | Register field that evidences it | Artifact an assessor accepts |
|---|---|---|---|
| Determining the scope of the AI management system | ISO/IEC 42001:2023, clause 4.3 | Lifecycle status · hosting and tenancy | A dated register export reconciled line by line to the written scope statement, with anything inside the estate but outside the scope explained rather than absent. |
| AI risk assessment | ISO/IEC 42001:2023, clause 6.1.2 | Risk class and its basis | The classification worksheet showing the two or three attributes that set each class, so the class can be re-derived when an attribute changes. |
| AI system impact assessment | ISO/IEC 42001:2023, clause 6.1.4, plus Annex A.5.2 (process) and A.5.3 (documentation). ISO/IEC 42005:2025 is separate methodology guidance. | Risk class · data classes in and out · action capability · autonomy and human checkpoints | A completed impact assessment for each elevated entry, dated before the system went live rather than assembled during fieldwork. |
| Resource documentation for the AI system | ISO/IEC 42001:2023, Annex A.4.2 | Model, provider and version posture · hosting and tenancy | A vendor documentation snapshot with the date it was verified and a link to the source, not a paraphrase written eighteen months ago. |
| AI system technical documentation | ISO/IEC 42001:2023, Annex A.6.2.7 | Dependencies · hosting and tenancy · lineage | The architecture record for the deployment, referenced from the entry by registry ID so the two cannot drift apart silently. |
| Recording of event logs | ISO/IEC 42001:2023, Annex A.6.2.8 | Logging location and retention | The retention setting as actually configured, plus a sample log extract drawn from a date inside the period — the setting alone does not prove the log existed then. |
| Intended use of the AI system | ISO/IEC 42001:2023, Annex A.9.4 | Intended use · declared out-of-scope uses | The use-case approval record. This is a different record from the vendor approval that put the product on the approved list, and assessors ask for it by name. |
| Allocation of responsibilities, and supplier relationships | ISO/IEC 42001:2023, Annex A.10.2 and A.10.3 | Hosting and tenancy · model, provider and version posture · data classes out and retention posture | The supplier’s own assurance report with its period and scope stated, plus your documented review of the complementary user entity controls it hands back to you. |
| Mechanisms are in place to inventory AI systems | NIST AI RMF 1.0, GOVERN 1.6 | The register as a whole | Reconciliation to four or more independent sources, with counts stated and every difference enumerated and explained. |
| Decommissioning and phasing out safely | NIST AI RMF 1.0, GOVERN 1.7 | Retirement plan and departure trigger | A decommissioning record showing credential revocation and access removal — not a status field changed to “retired”, which is a claim rather than evidence. |
| Identifies, inventories, classifies and manages information assets | SOC 2 — a point of focus under CC6.1 in the 2017 Trust Services Criteria (2022 revised points of focus) | Registry ID · data classes in and out · owner | The population reconciliation, tested the way any information produced by the entity is tested: completeness and accuracy established before the list is relied on. |
What an assessor actually requests
Two different audiences ask overlapping questions. A certification body auditor examining an AI management system tests whether the register supports the scope, risk assessment and impact assessment claimed. A service auditor performing a SOC 2 examination tests it as information supporting an asset-inventory or risk-identification control. Both start in the same uncomfortable place: prove the register is complete. The register is itself information produced by the entity, so it faces the same completeness-and-accuracy question as any other export you hand over.
| The request | What satisfies it | What gets rejected |
|---|---|---|
| The register as it stood at a date inside the period | A CSV or table export carrying a generation timestamp in the header, a record count, the field definitions, and version history showing the entries accumulated over time rather than in one sitting. Name the system it came from and who ran it. | A spreadsheet whose modification date falls after the period end with no history behind it. It answers a question about today, not about the period being examined. |
| Evidence that the register is complete | Reconciliation to independent sources with counts stated, differences enumerated and each difference explained. Name the five artifacts: the identity-provider OAuth grant export, the assistant compliance-console export carrying creator, created date and sharing scope, the published-agent listing per low-code environment, the gateway destination report, and the card-spend extract — or your own tenant’s equivalents, since what each plan tier exposes differs and changes. | “We asked every team and this is what they told us.” A self-reported population cannot establish its own completeness, which is the same completeness-and-accuracy problem any information produced by the entity faces. |
| Proof that ownership is real | The owner field reconciled to the personnel roster at two dates inside the period, a named deputy on every entry, and at least one worked ownership transfer triggered by a leaver. | A distribution list, a team name, or an owner whose account was disabled four months ago. Assessors check this by asking the named person a question about the system. |
| Intended use is documented and bounded | The intended-use text, the declared out-of-scope uses, and the use-case approval record — which is a different record from the vendor approval that put the product on the approved list. | A one-word purpose. A signed enterprise agreement offered as evidence that a particular use was approved. Approving a supplier is not approving a purpose. |
| The connector and scope inventory matches reality | Granted scopes exported from the platform at two points inside the period — the identity-provider grant listing for OAuth applications, the per-environment connection listing for low-code agents — placed alongside the register entry, with any difference explained and dated. | The register entry standing alone as its own evidence. A screenshot of a consent screen taken during fieldwork, which describes today rather than the period. |
| Sampled entries were reviewed on the stated cadence | Per selection: who reviewed it, what information they were shown, what they concluded, what changed as a result, and the date — with at least one instance where the review actually changed something. | A last-modified date. A review that has never altered a single entry in a year, which invites the question of whether it is performed at all. |
| The change triggers actually fired | A model version change, a new connector or a widened audience traced through to a re-review record inside the window your own procedure promises. | A procedure describing event-driven review with no instance of an event driving one. Your own documents are the standard you are measured against. |
| Retirement completed | A decommissioning record: access removed, identity disabled or credential revoked, data disposition decided and executed, dependants notified, entry status changed with a date and an actor. | An entry marked retired while its service principal still authenticates nightly. Status is a claim. The authentication log is the evidence. |
Two mechanics are worth knowing before the request list arrives. The first is how the population is sampled. With a register of forty-one entries, expect the completeness question to be handled at the population level first — reconciliation against independent sources — and then a small number of entries selected for detailed testing, weighted toward the elevated class and toward entries whose status changed during the period. Sample sizes are a matter of professional judgement rather than a published rule — no standard sets them — and they behave the way selections behave for any small population: the smaller the population, the less a selection is drawn and the more it is chosen. Both weightings are worth anticipating. The elevated class is where a deviation costs the most, and an entry whose class, owner or connector set changed mid-period is the one that tests whether the change triggers fired, which is the control rather than the record.
What follows is market practice rather than requirement — the selection counts commonly seen for a moderate level of assurance where the control is operating without exception, offered so you can size the evidence effort before fieldwork rather than during it. Your own auditor sets the numbers, and they will move if the control has deviated, if it is the only control addressing a criterion, or if it depends on a system whose completeness has not been established.
| Control frequency | Typical selections | What the selection looks like for a 41-entry register |
|---|---|---|
| Annual | 1 | The single annual register reconciliation, with its source counts and its explained differences. |
| Quarterly | 2 | Two quarter-end owner-confirmation cycles, each showing who was asked and who answered. |
| Monthly | 2 to 5 | Monthly change-trigger review records — the meeting or queue where new connectors and version changes are worked through. |
| Weekly | 5 to 15 | Weekly output checks on scheduled entries, where you have committed to running them. |
| Daily | 25 to 40 | Daily gateway-to-register reconciliation records, if that is how you detect systems bypassing the gateway. |
| Ad hoc, event-driven | Every instance in the period | Each occurrence of the seven change events — traced from the event to the re-review inside the window your own procedure promises. |
One population note that changes how you should prepare. With six entries in the elevated tier, expect coverage of all six rather than a sample of them. There is no sampling risk to absorb a deviation in a population that small: one elevated entry whose impact assessment is dated after go-live is not a percentage, it is the finding.
The second is the request nobody prepares for: the assessor selects something that is not on your register. They take a name from an OAuth grant list or a published-agent export, find no corresponding entry, and ask why. There are two acceptable answers — it fails the published inclusion test, and here is the test. Or it should have been included, here is when we found that out and here is what changed. There is one unacceptable answer, which is not knowing. That is the whole reason the exclusion rule has to be written down before the enumeration rather than reconstructed afterwards.
A certification body auditor will also, almost always, interview the named owner of a sampled entry. It takes about ten minutes to establish whether the owner knows what the system does, what data it reaches and what they would do if it behaved badly. An entry whose ownership is nominal does not survive that conversation, and no amount of documentation quality compensates for it. This is the strongest practical argument for keeping the register small and real: every entry is a person who may be asked to account for it.
The cases that generate the arguments
The inclusion test above settles the common eighty per cent within a week. These are the situations where reasonable people inside the same organisation disagree, and where writing the answer down before the enumeration saves the argument being had again every quarter.
Is an embedded vendor feature a new system?
Your CRM ships a summarisation feature and enables it by default. Creating a separate register entry duplicates a system you already manage, while ignoring it hides a new data flow. The workable answer is to attach AI-specific fields to the existing system record — what the feature processes, whether it is enabled, the vendor’s documented retention and training-use position for your contract, and whether it can be turned off — and to make those fields part of the annual supplier review. What fails is treating the existing contract as evidence that the new feature was assessed. It predates the feature.
One entry per model, or per system?
The unit of the register is the deployed use, not the weights. The same model behind three different processes carries three different risk profiles, so either three entries or one entry with three declared uses and per-use risk attributes will work. What does not work is one entry per vendor, which collapses a support classifier and a customer-facing recommendation into a line that says the provider’s name. If you cannot answer “what would an unacceptable output be?” for the entry as written, the entry is at the wrong granularity.
Where the register stops and shadow AI starts
The register describes what you sanction. Unsanctioned usage on personal accounts is a finding, not an entry, and the two need different treatment. Detection that reaches into personal accounts or device-level activity carries employment, privacy and, in several jurisdictions, works-council consequences — scope it narrowly to organisational data leaving organisational systems, disclose the monitoring, and take advice before extending it. The governance objective is to make the sanctioned path better than the unsanctioned one, which is a product problem more than a policing one.
A supplier’s agents acting on your data inside their tenancy
You cannot enumerate a vendor’s internal agents, and asking them to list every one is usually unproductive. What you register is the relationship: the data classes exposed, the processing the supplier performs, the contractual position on sub-processors and model changes, and whether they have committed to notify you when the model behind the service changes. ISO/IEC 42001 addresses this in Annex A.10 — allocation of responsibilities at A.10.2 and suppliers at A.10.3 — and a SOC 2 examination reaches it through the vendor and business-partner criterion at CC9.2.
Experimentation and evaluation environments
A blanket exclusion for experiments is reasonable and also the most abused clause in most AI policies, because production quietly relocates there. The rule that holds is a time-boxed sandbox with three conditions: no production data, no connectors to systems of record, and a recorded expiry date. Anything that needs one of those three has left the sandbox and graduates to an entry. Recording the expiry centrally is what makes the exclusion enforceable rather than rhetorical.
Locally run open-weights models
Inference on a laptop produces no network signal, so egress telemetry, gateways and identity data are all blind to it. Endpoint management is the only enumeration path, and it finds the runtime rather than the use. The governance questions here are narrower than people expect: what data is being fed to it, whether any of it leaves the device afterwards, and whether the model licence permits the use to which it is being put. Registering the practice and the approved runtimes usually beats trying to register every local model.
Contractors, partners and agents you do not administer
An agent operating on your data under someone else’s tenancy and identity is not yours to enumerate, but the access is yours to govern. Register the access rather than the agent: which of your systems the third party reaches, under which identity, with what scopes, and with what right of review. Then put the enumeration duty in the contract — a clause requiring notification when automated or agentic processing is introduced against your data is far easier to negotiate before the engagement than after an incident.
When the register turns into a second CMDB
The most common way this work fails after six months is duplication. The AI register starts carrying hostnames, cost centres and support hours, diverges from the asset system, and both records become untrustworthy. Keep the register to the risk-bearing AI-specific fields — intended use, data classes, identity, scopes, action capability, autonomy, class, review — and reference the asset record for everything else by identifier. A short register that is right beats a comprehensive one that is stale.
Where a register grows past a few dozen entries and several teams are building at once, the coordination problems change shape — that is the subject of governing many agents at once. Where the question is what a supplier owes you about their own systems, start with AI supplier due diligence.
What people push back on and the answer
Some of these come from a customer’s security team, but most come from inside your own organisation, which is the harder audience. In both cases the difference between a good answer and a defensive one is that the good answer concedes the true part first.
“We already have an asset inventory. Add a column.”
Try it for one entry and the problem surfaces quickly. An asset record answers what and where. An AI entry has to answer on whose authority, with what scopes, taking which actions, with what human checkpoint, and against which declared purpose. None of those are properties of a host. The pragmatic shape is a linked register: the AI entry carries the risk-bearing fields and points at the asset record by identifier, so neither system pretends to own the other. Where the asset inventory genuinely helps is completeness — it is one of the reconciliation sources.
“The discovery tool covers this.”
It covers the half that can be observed, and that half is genuinely valuable — it will find grants, agents and traffic that nobody would have declared. What it cannot produce is the owner, the intended use, the sensitivity of what actually flows at runtime, or what an acceptable failure looks like. Those four are judgements, not signals. A tool that reports two hundred detections and no owners has moved the work rather than done it. Buy the tool for the population, and run a claim step for the context.
“This will slow every team down.”
It does if the register is a committee. Keep the minimal tier to a two-minute form and an owner name, and reserve the assessment machinery for entries that can take irreversible or externally visible actions. In practice most of an estate lands in the light tier. The thing that actually slows teams down is the alternative: a customer question, a regulator query or an incident that forces a two-week manual reconstruction of what was running, because nobody wrote it down while it was cheap to write down.
“Engineering says it is just another API call.”
At the transport layer that is true and unhelpful. What distinguishes this call is that its output is non-deterministic, its behaviour can change when a provider updates a model you did not pin, its inputs can carry instructions from untrusted content, and it is increasingly wired to tools that change state. None of those are properties of an ordinary REST dependency. The register is not asking engineering to treat the call as exotic — it is asking for the version posture, the scopes and the failure mode, which are the same three things you would want for any privileged integration.
“The board was told six. You are saying forty-one.”
Both numbers can be honest, and the recovery is to explain the counting rule rather than the discrepancy. Six was systems somebody built or bought deliberately. Forty-one is entries that meet a published inclusion test, most of which are low-risk configurations rather than projects. Present the class breakdown alongside the count so the shape is visible: the number that should worry a board is the elevated tier and the unclaimed entries, not the total. Then publish the inclusion test so the next count is comparable to this one.
“Our vendor has a SOC 2 report and an ISO 42001 certificate, so we do not need an entry.”
Their report describes their controls over their system. It says nothing about which of your data classes you send them, who in your organisation is accountable for that decision, or what purpose you use the service for. A SOC 2 report also frequently allocates responsibilities back to you through complementary user entity controls, and those responsibilities land on the owner named in your entry. The supplier assurance belongs on the entry — recorded against the provider and tenancy fields, with the report’s period, its scope and the date you reviewed it — not treated as a reason the entry does not exist.
“We cannot inventory what people do in a browser.”
Not exhaustively, and a register that claims otherwise is worse than one that states its coverage. Say plainly what the enumeration covers — managed devices, federated identity, gateway-routed traffic, administered tenancies — and what it does not. Then reduce the residual: make the sanctioned assistant genuinely good, put the data-handling difference between the enterprise and consumer path in front of people at the moment of choice, and treat repeated unsanctioned use as a signal that something the business needs is missing.
The first ninety days, in order
The sequence matters more than the tooling, and the sequence is not negotiable in one respect: the rule comes before the list. A candidate list assembled without a published inclusion test cannot be triaged without inventing one retrospectively. The day ranges below track the worked example’s own calendar, and the column that repays the most attention is the last one.
| Days | Step | Who owns it | Deliverable that must exist at the end | Where teams get it wrong |
|---|---|---|---|---|
| Days 1–5 | Publish the inclusion test | AI governance lead, signed off by the CISO | Inclusion policy v1.0: the four properties, the written exclusions, and the graduation event that moves something from excluded to included. | Writing it after the candidate list exists. A rule reverse-engineered to fit a list is the first thing an assessor unpicks, and it cannot be defended in the interview. |
| Days 1–5 | Freeze the schema | AI governance lead | The nineteen field definitions with allowed values, and a named system to hold them that keeps version history. | Adding fields that would be interesting. Every field nobody maintains reduces confidence in the fields somebody does. |
| Days 6–15 | Discovery from four or more independent sources | IAM and SecOps, with procurement supplying card and subscription data | A candidate list with a source column on every row, so a later completeness argument has something to stand on. | Running one source because it was the easy export. Completeness then has to be asserted rather than argued, and asserting it is what fails. |
| Days 16–40 | The claim step | Function heads answer, and the AI governance lead runs the queue | A claim response per candidate inside a ten-working-day window, with a named escalation path for the ones nobody answers. | Escalating to a shared mailbox. Unclaimed entries are the most informative output of the exercise and they need a person, not an address. |
| Days 41–55 | Classification | AI governance lead with each entry owner | A class, a basis and a date on every entry — the basis being the two or three attributes that put it there. | Classifying before the claim step has returned, which produces classes derived from guesses about purpose. |
| Days 56–90 | Treatment of the elevated tier | Entry owners, with second line or internal audit reviewing before go-live | Impact assessments, narrowed connector scopes, expiry dates on non-human credentials, and a documented stop mechanism per elevated entry. | Assessing the systems you already knew about. Teams that invert the last two steps never reach the ones they did not know about, which are the reason for the exercise. |
Two roles are easy to leave implicit and expensive to leave out. Procurement and vendor management own the supplier side permanently, not just during discovery: the annual supplier review is where you ask directly whether an AI feature has been switched on inside a product you already buy, and it is the only reliable route to features that arrive enabled. Second line or internal audit owns the pre-go-live review for the elevated tier — not because the first line cannot be trusted, but because a sign-off by the person who wants the system shipped is the specific artifact an assessor looks at hardest.
Two more things belong on day one because they are cheap then and expensive later. Check the retention window on every log you intend to cite — administrative logs in SaaS tenancies are frequently shorter than an annual certification cycle, and a register whose evidence expired in month four is a problem discovered during fieldwork. And record where each entry’s evidence lives at the moment the entry is created, rather than reconstructing it from memory nine months afterwards.
Tranquility Cybersecurity builds these registers with clients as part of AI governance and ISO 42001 readiness work — the inclusion test, the schema, the enumeration pass, the classification model and the evidence structure behind them. We advise, implement and coordinate. ISO 42001 certificates are issued by accredited certification bodies and SOC reports by licensed CPA firms. That separation is what makes the eventual assessment worth having.
Frequently Asked Questions
What should an AI system inventory contain?
Does ISO 42001 require an AI system inventory?
Does SOC 2 require an AI inventory?
How is an AI inventory different from an asset inventory?
Do we need to register every custom GPT?
How do we find AI agents nobody told us about?
Is a technical discovery tool enough on its own?
Who should own an AI inventory entry?
What happens to an AI agent when the person who built it leaves?
How do we inventory agents that create other agents?
How often should the AI inventory be reviewed?
Related reading: the ten questions that govern any AI agent, when a tool becomes an agent, shadow AI, AI risk versus impact assessment, MCP server security, and the ISO 42001 hub.
Related Reading
The Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreWhen Does a Tool Become an AI Agent?
The four properties that move something from assistant to agent — and why the product label tells you nothing.
Read moreVendor Approval Is Not Use-Case Approval
Signing the enterprise agreement approves the supplier, not every purpose someone will use it for.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more