What Discovery Will Not Find
The blind spots are structural rather than fixable. Knowing them prevents the dangerous conclusion that you have a complete picture.
Discovery · Analysis
A thorough discovery exercise produces a good picture. Several categories remain invisible, and believing otherwise is worse than knowing less.
The recommendations in “What Discovery Will Not Find” become easier to sustain when implementation work has visible owners, dates and review time. Teams evaluating the platform summary can use it to coordinate the operational side of AI adoption and identify where governance tasks are being missed, without treating activity data as evidence of misconduct or as a substitute for asking people why they chose a tool.
For an independent benchmark, compare the local approach with CISA cyber-risk guidance; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.
Personal devices
Phones, home computers, personal tablets.
Entirely outside your technical sources, and after any blocking attempt this is where a substantial share of the activity lives.
Only asking finds it, and only if people trust the asking.
AI inside approved tools
Features arriving in updates: summarisation in a document editor, drafting in email, analysis in a spreadsheet.
Traffic goes to the approved domain, so network discovery sees nothing.
Nobody installed anything, so endpoint inventory sees nothing.
This is the fastest-growing category and the hardest to see, and it needs a separate deliberate check of each approved tool.
Use through intermediaries
A tool you approved that itself calls a model provider you did not assess.
Subprocessors, in contract terms.
Which means your data may reach a service you have never heard of, with the approved supplier as the only visible party.
Ask your suppliers which model providers they use. Many will not volunteer it.
Automations and agents
Scripts calling an API, scheduled jobs, workflow automations with an AI step.
No browser, no installed client, and traffic that looks like ordinary API calls.
Frequently built by capable people in business teams rather than by IT, which is why nobody thought to declare them.
What people will not report
Anything they believe is already prohibited.
Anything embarrassing: using a tool to write something they were expected to write themselves.
And anything they do not consider a tool at all, which includes most embedded features.
The honest position
Your inventory is a lower bound.
Say so in the document, so that nobody treats it as complete when deciding policy.
And design controls that do not assume full visibility, which means classification-based rules rather than tool-based ones.
What reduces the blind spots
A declaration route that is quick and usually ends in yes.
Asking suppliers about subprocessors at procurement.
A deliberate audit of AI features in approved tools, twice yearly.
And an amnesty framing that makes reporting safe, which is the only thing that reaches the personal-device category at all.
What to check
Does your inventory state that it is incomplete?
Have you asked your approved suppliers which model providers they use?
Has anybody looked for automations with an AI step?
And do your controls depend on knowing about every tool?
The point
Your inventory is a lower bound.
Say so in the document, so nobody treats it as complete when deciding policy.
Underlying all of this
Everything in this collection reduces to four habits: find out what people are doing and why before deciding anything, provide something good enough that the approved route is the easy one, write rules about information rather than about tools, and monitor the destination rather than the content. None requires a product, and a programme doing all four controls more than one built on prohibition.
The recurring pattern
The recurring pattern across every section here is the same: the response that feels like control reduces it. A ban removes visibility rather than use. Content inspection drives activity to personal devices. A discovery exercise with consequences produces quiet answers. In each case the organisation ends up knowing less about a risk it believes it has handled.