An AI inventory built from self-declaration alone undercounts, because the systems carrying the most risk are the ones nobody thinks to declare: AI features inside software already bought, models inside vendor services, and agents built on internal platforms. A usable inventory pairs technical discovery with structured disclosure, records a minimum set of fields per system, and reconciles the two continuously.

Why does asking people what AI they use always undercount?

The 2024 Work Trend Index from Microsoft and LinkedIn, a survey of 31,000 knowledge workers in 31 countries, found that 78 percent of AI users brought their own AI tools to work and that 52 percent of people using AI at work were reluctant to admit using it for their most important tasks. A questionnaire sent to that population returns a partial answer by design.

Reluctance is one failure mode. Each of the following hides from a survey for a different reason.

• AI features inside SaaS the business already owns arrive as a release note, not a procurement. The CRM added lead scoring, and nobody describes their CRM as an AI system when asked.

• Individual subscriptions on expense cards are coded as software, sit below every procurement threshold, and are declared only if the cardholder connects a $20 monthly charge to governance.

• Models inside vendor services are invisible to the business unit that bought the service. A claims triage outsourcer may run AI on the organization's behalf, and under Article 3(4) of the EU AI Act the body "using an AI system under its authority" is the deployer, whoever built it.

• Agents built on internal automation platforms are described by their builders as workflows. A flow that calls a model and then writes to a system of record is an agent, and no survey about AI tools will catch it.

• Notebooks promoted to production produce scores that a downstream process consumes. Nobody commissioned them, so nobody owns them, so nobody declares them.

The common thread is that the person who could declare a system either does not classify it as AI, does not own it, or has a reason not to say. Everything else needs a signal that does not depend on a person. Enzai's guide to shadow AI discovery and governance covers why shadow AI differs from shadow IT; this piece is about finding it.

Which discovery methods find unsanctioned AI, and what does each miss?

No single method covers the failure modes above, and the useful question about each is not what it finds but what it cannot see.

The blind spots differ, so a system seen by two signals is a confirmed record and a system seen by one is a lead to verify. Self-attestation stops being the inventory and becomes the enrichment step: technical signals establish that a system exists, and the owner supplies what only a person knows. Vendor-side AI, where the model runs in the supplier's environment, is the one category no technical signal reaches, so vendor questionnaires and contract review stay on the list.

How do you discover AI agents specifically?

Agents leave different traces from tools. A person using an AI assistant shows up as a domain in the proxy log or an app in the identity provider. An agent shows up as a non-human identity: a service account holding a model-provider API key, a tool registration in an agent framework, a scheduled job that calls a model and then something else.

The signals are the identity provider's list of non-human identities and what they may touch, cloud accounts' inventory of secrets scoped to model providers, automation platforms' connector logs, and repository scans for agent frameworks. The tell is a model call followed by an action on its output with no person in between.

Agents also delegate to other agents. Once an organization has more than a handful, an agent mesh forms, in which agents discover and hand work to one another through shared infrastructure. Discovering the mesh means mapping which non-human identities call which, so one record shows an agent's upstream callers and downstream targets. The controls that follow are in Enzai's agentic AI governance guide.

What is the minimum usable inventory record?

The full field template, with roughly forty fields, is in the guide to building an AI inventory. The question here is the floor: the smallest record that still supports a governance decision. Nine fields meet that test.

Each record is a claim with support. "This system is limited risk" is an assertion; the same statement with an owner, a purpose, a data field and a link to the assessment is evidence. Article 26 of the EU AI Act shows why the fields are not optional: paragraph 2 requires human oversight by competent people (the owner and autonomy fields), and paragraph 6 requires logs kept for at least six months (the model version and evidence fields). Enzai's AI inventory is built on the same shape of record: owner, purpose, vendor and model references, autonomy level, risk tier, mapped frameworks and assessment evidence per entry, with data sensitivity as a tag.

Which regulations and standards require an AI inventory?

Few regimes use the word inventory. Most impose obligations that cannot be met without one.

ISO/IEC 42001 Annex A control numbers are not published on iso.org and are not cited here. Enzai's glossary entry on OMB M-25-21 covers the federal memorandum in more depth.

How does an AI inventory stay current after the first sweep?

An inventory decays through three mechanisms, each with its own countermeasure.

The first is unreconciled discovery. Every signal produces candidates, and if candidates sit in a spreadsheet beside the inventory, the two drift apart within a quarter. Each candidate should be matched to an existing record, merged as a duplicate, or opened as a new record marked unowned with a deadline for assigning an owner. The count of unowned records older than thirty days is the first health metric.

The second is ownership decay. Owners change roles and leave. If the owner field is a free-text name, the inventory is out of date the day HR processes the departure. Tying the owner to a directory identity, so a leaver event triggers reassignment, makes the field mean something.

The third is change the inventory does not see. A vendor updates the base model behind an embedded feature; an agent is granted a new tool; an OAuth grant gains a wider scope. The existing guide lists the business triggers; the technical triggers are the day-one signals run continuously, with a diff against the last state. The second health metric is the time from a signal first appearing to a record existing. The third is the ratio of systems found by discovery to systems declared through intake: if discovery keeps finding what intake never saw, intake is the broken part, and the intake process guide is where to start. Continuous AI monitoring of this kind is the premise of Enzai's inventory, which updates as the estate changes and syncs with AWS, Azure, GCP, Databricks, watsonx and Snowflake for asset discovery.

What should you do with the AI you find?

The first time an unsanctioned tool is found, it is cheap to find, because it left a trace: an expense line, an OAuth grant, a domain in the proxy log. If the consequence is removal or discipline, the second wave moves to personal accounts, personal devices and home networks, none of which the signals above can see. Enforcement-first converts a visible population into an invisible one.

The alternative is a time-boxed amnesty with a service level attached. Every disclosed tool gets an inventory record and a decision within a stated period: approve, approve with conditions, replace with a sanctioned equivalent, or retire. The person who disclosed it receives the decision, not a case number. Enforcement is reserved for the post-amnesty period and for data-classification breaches, which are violations whether or not AI was involved. The shadow AI guide covers the paved road and acceptable-use design.

If disclosed tools wait months for a decision, disclosure stops. Enzai's AI use case intake is built for this pattern: AI found in use that never came through intake can be folded into governance without blame, low-risk cases are fast-tracked, and approved cases enter the inventory with the rationale recorded. That is the operational form of AI enablement.

What should you look for in a tool for finding unsanctioned AI?

Eight criteria separate a discovery tool that produces a list from one that produces an inventory.

1. More than one discovery signal, named. Ask which of the seven methods above the tool runs itself and which it ingests. A single-signal tool inherits that signal's blind spots.

2. Correlation into one record. Three signals about one system should produce one record, not three alerts.

3. Coverage of embedded and vendor AI, not only consumer AI domains, since those are the failure modes a domain block list never sees.

4. Non-human identities in scope. A tool that cannot see service accounts and API keys cannot find agents.

5. Output as a governance record: an entry with an owner, a risk tier and a framework mapping, not a security event waiting for triage.

6. Evidence attached per system, so an assessment, an approval and a vendor document travel with the record into an audit.

7. Handoffs into where work happens: ticketing tools for owner assignment, cloud and ML platforms for asset discovery.

8. A proportionate intake path, so that finding a system leads to a decision about it.

Network security tooling deserves a fair word. CASB and secure service edge products are very good at seeing SaaS use, blocking exfiltration and enforcing policy at the edge. Their output is a security event about a domain or an app; the governance record is a different artifact, and the shortlist question is which tool produces it. Enzai's inventory runs five discovery methods in parallel (procurement signals, SaaS telemetry, browser signals, network traffic and manual disclosure), auto-maps each system to the EU AI Act, ISO 42001 and NIST AI RMF, and hands work into Jira, ServiceNow and Slack. Where an organization sits on a governance maturity model decides how many of the eight it needs on day one; automating the governance workflow becomes the priority once the estate outgrows a spreadsheet, the point at which AI sprawl sets in.

What this means operationally

For a governance team starting from a self-declared list, or from nothing:

1. Run every discovery signal you can access once, in parallel, and reconcile the candidates into one list. Record which signal found each system and whether another confirmed it; the single-signal finds tell you which signals to keep running.

2. Open a record for every candidate using the nine minimum fields. Allow blanks on everything except owner and purpose, and set a thirty-day deadline to assign an owner to any record that has none.

3. Announce the amnesty with the decision service level attached, and route every disclosure through intake so it lands as an inventory record with a decision date.

4. Put the three currency metrics (unowned records over thirty days, time from signal to record, discovered-to-declared ratio) in front of the committee that owns AI risk, monthly.

5. Map each record to the obligations that apply to it, starting with EU AI Act Article 4 and Article 26, ISO/IEC 42001 scope, and NIST GOVERN 1.6, so the inventory is the evidence base for every framework.

Enzai's AI inventory is built for steps one, two and five: multi-method discovery into one record per system, with framework mapping and the evidence trail attached. To see it against your own estate, talk to the Enzai team.