We find 31 unsanctioned AI tools per engagement. Here is how

Every AI governance engagement starts with the same request: please send us your AI system inventory. The response is almost always a list of the three or four models the data science team built.

By the end of discovery, the count is typically between twenty-five and forty. The median number of AI systems the organisation did not know about is thirty-one.

These are not exotic. They are the AI features switched on by default in tools already in use, the API integrations built by a product team in a sprint, the browser extensions individual employees installed, and the "AI-powered" capability a SaaS vendor added in a release note nobody read.

Why the inventory has to come first#

Governance without an inventory is a policy nobody applies to anything. Every substantive obligation — ISO 42001 impact assessment, EU AI Act classification, DPDPA purpose limitation, model risk oversight — presumes you know which systems exist.

It also has an immediate practical value: roughly a fifth of what discovery surfaces should simply be switched off. Tools with no business owner, no assessment and no ongoing use are pure exposure.

Method one: procurement and expenditure reconciliation#

Start with money, because money leaves records.

Pull twenty-four months of accounts payable and card expenditure, and filter for software vendors. Then classify each vendor against a keyword set — model, AI, GPT, LLM, copilot, assistant, intelligence, automation, prediction, and vendor names from the current model provider landscape.

What this catches: subscriptions bought on a departmental card. Individual seats on transcription tools, writing assistants and code generators. Vendors procured before AI features existed who have since added them.

What it misses: free tiers, personal accounts, and features bundled into existing contracts at no incremental cost.

Method two: identity provider audit#

The highest-yield single method. Query your identity provider for every application with an OAuth grant or SAML assertion, then filter as above.

Azure AD / Entra ID
  Enterprise applications → filter by sign-in activity in last 90 days
  Also check: user consent grants (delegated permissions)
 
Okta
  Applications → assigned + self-service enrolled
  Also check: API service integrations
 
Google Workspace
  Security → API controls → App access control → Connected apps

The critical step, and the one usually skipped: check user-granted OAuth consents, not just administrator-assigned applications. In most organisations any user can grant a third-party application read access to their mail and files unless that has been explicitly restricted. That is how an AI meeting-notes tool ends up with a standing grant to a general counsel's calendar and attachments.

Method three: network and egress telemetry#

For organisations with egress inspection or a secure web gateway, query for traffic to model provider API endpoints and consumer AI application domains over ninety days, grouped by source identity and volume.

This catches direct API usage from application code and developer machines — which procurement and identity methods both miss because there is no application registration and often no invoice, only a corporate card charge under a generic name.

Volume is the useful signal. A handful of requests is experimentation. Sustained daily traffic from a production subnet is an undocumented production dependency.

Method four: structured interviews with the right question#

The discovery interview question that works is not "do you use AI?" — everyone says no, or names the obvious tools.

The questions that work:

• What part of your work is faster now than it was a year ago, and what changed?
• What tool did you start using without asking anyone?
• Is there anything in your workflow where a system suggests an answer and a person accepts it?
• Which of your vendors has released something new recently that you liked?

The third question is the one that surfaces embedded AI, because employees do not classify a suggestion engine in their existing CRM as an AI system. It is also the question that finds the highest-risk cases, since a system whose output a person routinely accepts without independent judgement is functionally making the decision.

What to record per system#

An inventory entry that supports governance needs more than a name:

The two fields that most often reveal a serious problem are human oversight present and population affected. A system with no meaningful oversight that affects customers or employees is where you concentrate everything else.

Tier, then govern proportionately#

Discovery produces a list; tiering makes it actionable. Our default structure:

The point of tiering is not paperwork. It is that a fifteen-minute self-assessment for tier 3 keeps teams productive and honest, which is what makes them willing to register tier 1 systems rather than hide them.

Uniform governance produces the opposite behaviour, reliably.

Keeping it current#

An inventory built once decays within a quarter. Three mechanisms keep it alive:

1. Procurement gate — any purchase with an AI component triggers tier determination before signature.
2. Quarterly rediscovery — re-run the identity and network queries; they are cheap once scripted.
3. Vendor change notification — a contract term requiring notice when a vendor adds an AI capability or changes an underlying model.

The third is the one that prevents the most unpleasant surprises, and it is straightforward to add to standard terms.

Do not try to win by prohibition#

The instinct after a discovery exercise is to block. It fails, and the way it fails makes things worse.

Blocking the well-known model providers at the proxy moves usage to personal devices and personal accounts. You have not reduced the data leaving your organisation; you have removed your visibility of it, and you have converted a governable problem into an invisible one. The number of AI systems in your inventory goes down while actual exposure goes up.

The organisations that get this right compete with the shadow tool instead. If a sanctioned assistant is available, works well enough, and does not require a ticket to access, most people will use it — because they were never trying to evade governance, they were trying to finish a task faster.

That reframes the response. Discovery is not an enforcement exercise; it is a demand signal. Thirty-one unsanctioned tools tells you where people needed help and did not get it. Two or three sanctioned options covering the most common needs will retire most of the list without a single blocked domain.

An acceptable use policy people will actually follow#

Most AI acceptable use policies fail for the same reason: they are written as prohibitions against categories of technology rather than as guidance about categories of data.

The version that works is short and turns on a single question — what are you putting in?

Never, in any AI tool: customer personal data, health or financial records, credentials or keys, unreleased financial results, anything under a specific confidentiality undertaking, source code from systems handling payments or authentication.

Sanctioned tools only: internal documents, meeting content, draft customer communications, non-sensitive code, anything covering commercial strategy.

Any tool, including public ones: published material, general research, public documentation, learning and experimentation on synthetic data.

Three tiers, one page, no technology names — so it does not go stale when the market shifts.

Pair it with two conditions rather than a list of banned products. Register anything that touches a consequential decision about a person, and do not turn on an AI feature in an existing vendor product without telling the owner of that vendor relationship. Those two conditions catch the cases that matter and leave the rest alone.

The measure of success is not zero unsanctioned tools. It is that the tools people use are known, their data flows are understood, and the consequential ones are governed. Perfect prohibition is not available; accurate visibility is.

Our AI Governance & Assurance practice runs this end to end, and the deployer-obligation analysis and vendor question set are published in Governing AI You Did Not Build.