Find out what is already being used

Running one of these and stopping is the common mistake. Expense data finds what was paid for, which is the smallest and least risky category, because a tool somebody paid for usually went past somebody.

The tools that matter most are free, signed into with a personal account, and invisible to everything except the device.

Employee AI adoption has moved extremely quickly: industry reporting through 2025 and 2026 put it at roughly a threefold rise inside a single year, and incidents attributed to shadow AI have risen several times over in DLP data sets.

IBM's breach cost research put the shadow AI premium at roughly $670,000 on top of an average breach, which is the figure most useful in a business case because it is about consequence rather than volume.

Check the figures before you quote them. These numbers move every reporting cycle, and a slide citing last year's study is easy to challenge in a room.

Discovery is not a prelude to a ban. The organisations that handle this well pick a small number of tools, put them under contract properly, and make those the easiest option available.

Everything outside that list is then a reporting question rather than an enforcement one, and the policy can be written against measured behaviour instead of an assumption. A tool that reports a hostname and never the content is what makes that defensible to the people being measured.

The first discovery run produces a longer list than expected, and the instinct is to start at the top by request count. That ranking is almost exactly wrong.

The tool with four thousand events is usually a translation or summarising habit with nothing regulated in it. The tool with nine events can be the one where somebody pasted a patient list. Sort by what was in the message, with destination as the second key, and the queue becomes short enough to work through in an afternoon.

Two entries deserve attention on their own. Personal accounts on tools you have already approved, because your contract governs the tenant and not the login. And hostnames nobody recognises, which is where a genuinely new tool shows up before procurement has heard of it. A count of unrecognised hosts is a better weekly number than a total event volume, and it is the one we would look at first.

Running one discovery method and treating the output as the answer is the common mistake. The useful move is to run two and read the distance between them.

The pair worth running is the survey and the endpoint. The survey tells you what people believe they are doing and are willing to write down. The fleet tells you what is actually happening. Where they agree, you have a tool people use openly and you can go and contract for it. Where the fleet shows something the survey did not, you have either a tool people were not sure they should mention or one that arrived inside software you already approved, and those need different responses.

Report the gap rather than the raw count. A steering group that hears "staff named four tools and the fleet shows nineteen" understands the problem immediately, where a list of nineteen hostnames produces a debate about whether each one matters.

Discovery is usually run once, which is the mistake that guarantees running it again in a year as though it were new.

The number worth reporting every month is not total AI usage, which rises as adoption rises and tells you nothing about risk. It is the count of destinations nobody has seen before. That number is a direct measure of how fast your approved list is decaying, and it is the one that tells you whether your review cycle is frequent enough or whether your policy is describing a world that has moved on.

Two or three new destinations a month is ordinary and healthy, and means the triage is working. Twenty means your sanctioned tool is not doing the job people need, and no amount of policy will fix that. The limit worth stating: this measures the devices you manage, so a rising number is a signal and a flat number is not proof of anything.