A ban does not end the use. It ends the visibility

The framing that decides everything else

Shadow AI is the use of AI tools the organisation has not provided, approved or in many cases heard of. It is widespread, it is mostly done by conscientious people, and how you frame it determines what you learn.

Applying the boundary described in “A ban does not end the use. It ends the visibility” requires a clear operational purpose and a record that can be reviewed without reading private content. Teams considering the time-recording overview can use workload and time evidence to understand how approved processes are actually used, while keeping AI discovery, security telemetry and employee monitoring separate and proportionate.

For an independent benchmark, compare the local approach with OECD AI Principles; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

"Shadow" implies concealment, and most of this is not concealed — it is simply unasked about. Somebody used a tool, it helped, and no process existed to declare it. Treating that as misconduct produces a compliance exercise and a quieter shadow.

The more useful reading: shadow AI is a measurement of the gap between what people need and what they were given. Every instance tells you that a task was hard enough that somebody went looking, and the approved route did not cover it. That is information about your tooling, not about the person.

Why bans do not work

The instinctive response is to block. The effect is consistent and well documented in adjacent areas: use continues and the organisation stops being able to see it.

A block covers the corporate network and managed devices. It does not cover personal phones, home machines, personal accounts accessed from anywhere, or tethering. Within weeks the activity resumes on those channels — where there are no logs, no data loss controls and no enterprise terms. The risk increases and the visibility goes to zero.

And nobody reports it, because reporting means admitting a breach. The organisation now believes it has solved the problem, which is the most dangerous of the three states.

Bans are correct for specific tools with genuinely unacceptable terms, for specific data categories, and for narrow contexts like an agent with access to production systems. Narrow, explicable, enforceable — which a blanket prohibition is not.

What actually leaves

Policy arguments here are usually conducted without anybody having traced what physically happens to the text somebody types. It goes over the network to the provider, is processed, and — depending on the service and the account type — may be logged, retained, reviewed by humans for abuse or quality, and used to improve models. Each is a separate question with a separate answer, and the answers differ by account type more than by provider.

The largest practical risk is the least discussed. Most data exposure here is not somebody deciding to send confidential information. It is somebody not reading what they selected — the whole document rather than the paragraph, the full thread rather than the question. Which points at training and at tooling that redacts, rather than at rules.

Four sources, in the right order

Discovery conducted as a hunt produces hiding. Conducted as a question it produces an inventory and, more usefully, a requirements list.

Announce it. Say nobody is in trouble for what it finds, and mean it, because the first person disciplined over a discovery finding ends your ability to run another one.

Ask first. Four anonymous questions: what tools do you use for work including on personal devices, what are you using them for, what would you need from an approved tool to switch, and was there a task where you wanted one and there was nothing. The last two are what turn an inventory into a specification.

Then network and DNS evidence, which shows which services are reached. It does not show what was sent, and treating volume as content is a mistake in both directions.

Then endpoint inventory. Installed clients, developer tooling, and above all browser extensions — the finding that usually justifies the whole exercise and that network logs cannot see, because the traffic looks like ordinary browsing.

Then finance data. Expense claims and card statements find the tools people cared enough about to pay for. Free-tier use is casual; paid use is dependence. And personal payment rather than an expense claim usually means the person expected the claim to be refused, which is information about your approval process.

What discovery will never find

Several categories remain invisible, and believing otherwise is worse than knowing less.

Personal devices — entirely outside the technical sources, and after any blocking attempt this is where much of the activity lives. Only asking reaches 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, nobody installed anything, and both technical sources see nothing. This is the fastest-growing category and it needs a deliberate separate check.

Use through intermediaries. A tool you approved that itself calls a model provider you never assessed. Ask your suppliers which ones they use; many will not volunteer it.

And automations — scheduled jobs and workflows with an AI step, frequently built by capable people in business teams rather than by IT, which is why nobody thought to declare them.

Say in the document that your inventory is a lower bound, so nobody treats it as complete when deciding policy. And design controls that do not assume full visibility, which is another argument for classification-based rules.

The clauses that decide the risk

The risk of any given tool is almost entirely determined by what the provider does with what you send. Seven clauses settle it, and they take an hour to check per service.

Training use — whether input may be used to improve models. Consumer tiers frequently do by default, with an opt-out people do not find. Enterprise agreements almost always exclude it contractually, and that single difference is the main practical argument for providing an approved option.

Retention — how long, and whether you can delete. Watch for "as long as necessary", which means whatever they decide.

Human review — whether staff may read submitted content, which is standard for abuse detection and rarely prominent in the terms.

Subprocessors — who else handles it, including the model provider behind a vendor's interface. This matters more here than in most software, because the AI layer is frequently somebody else's.

Processing location, output indemnity, and how terms may change — the last being unilateral and effective on posting for most consumer tiers.

And note that a setting the user controls is not a control. Where a training toggle exists it is a stopgap while you arrange a proper agreement, not a basis for policy.

Rules about information, not about tools

A rule naming tools is obsolete within a quarter: new tools appear monthly, approved tools gain AI features in updates, and the rule says nothing about a tool on neither list.

A rule naming information categories survives all three, because the categories change on a scale of years. Three levels, three rules:

Public: any tool. Say this explicitly, because it covers a large share of what people actually want to do.

Internal: approved tools only, where the terms are known and a contract exists.

Confidential or regulated: approved tools with an agreement covering that category, or nowhere.

Three lines somebody can remember and apply without consulting a document. That is the test of a policy: could a colleague asked at their desk state the rule?

Where monitoring stops being about tools

Several techniques detect AI use, and they differ enormously in what they reveal. Destination logs show which services were contacted. Inventory shows what is installed — including browser extensions, which can read page content by design and are invisible to network logs. Finance data shows what people pay for, which indicates dependence rather than casual use.

Then there is content inspection, and it is different in kind. A URL is a destination. A prompt is a draft. People write things in prompts they would never send: half-formed thoughts, a frank description of a colleague, a question about their own symptoms, a rehearsal of a difficult conversation. Prompts are closer to a private notebook than to browsing history.

Products in this space offer prompt inspection as a feature, framed as data loss prevention. The framing is reasonable and it obscures what is being collected — which is why this should be decided explicitly rather than configured during deployment.

Where the purpose is genuinely preventing defined patterns from leaving, client-side redaction achieves it without transmitting anything for inspection, and without creating a log of what people typed.

Provide before you restrict

Shadow use falls when the approved route is easy and adequate. Nothing else in this collection has as large an effect.

Good enough means available today rather than after a request, capable of the tasks people are actually doing, not noticeably worse than what they were using, and visible. Fail any of those and the shadow tool stays.

The commonest mistake is approving the most restricted configuration available and then wondering why adoption is poor. A tool with the useful features disabled is not an alternative; it is a demonstration that the organisation does not understand the task.

And almost nobody measures whether it worked. Consumer-tier traffic should fall measurably after a rollout, from the same logs discovery used. If approved usage rises and consumer usage does not fall, people kept the other tool for some tasks — which is a finding about capability, not about compliance.

What is deliberately absent here

No products, suppliers or models are named. The field moves faster than any list, and every comparison available online is written by somebody selling one of the options.

No adoption percentages. The figures in circulation come from surveys commissioned by companies selling controls, with elastic definitions and unreproducible methods. Count what you found instead.

And no claim that any of this eliminates the risk. Personal devices remain outside your view, embedded features arrive in updates, and some use will always be invisible. Writing that down with reasons is better than a reassurance that will not survive the first incident.