Shadow AI policy: what it must say, and why a blocklist fails

Why a blocklist moves the data instead of stopping it

A blocklist assumes the tool is the risk and the employee will comply. The UK's National Cyber Security Centre takes the opposite line: organisations cannot block every AI tool, so the aim is to reduce unapproved use and keep a route open for staff to propose tools.

A blocklist changes where the work happens. Data moved into a consumer AI service may be stored, retained or used to improve that service, and the employer loses visibility and control of it, which the NCSC says raises breach, intellectual-property and compliance risk.

The scale is not small. Microsoft research cited by the NCSC found 71% of UK employees had used AI tools their employer had not approved.

The unapproved route has no single sign-on, no prompt log and no contract. What leaves through a personal account on a personal device sits outside the estate's inventory, where no retention rule, legal hold or data-loss policy reaches it. The risk moved off the books rather than away.

What the policy has to say

Start with an approved tool list and give it a published route in: a named owner, a short request form, a review of data flows and vendor terms, and a stated decision window. The deadline matters more than the template, because an intake queue that never answers is a shadow AI programme with a form attached.

Then a data rule in two columns. One lists what may never be pasted into any external tool: credentials and API keys, customer records, unpublished financials, security findings, and source code holding live secrets. The other lists what may go into an approved enterprise tenant. NIST's AI Risk Management Framework puts documented policy, defined roles and accountability in its govern function, which is where that rule has to live to be auditable.

Add a disclosure rule for output that leaves the building. The EU AI Act's transparency obligations took effect in August 2026 and cover labelling of deep fakes and of AI-generated text published to inform the public on matters of public interest, so tenders, filings and published material need one rule naming who declares what.

Two clauses keep the rest alive. An amnesty: past use reported before a cutoff is not disciplined, because a retroactively punitive policy guarantees nobody reports anything. And an owner with a review date, so the approved list is re-tested against what people ask for.

The controls that hold

Buy the enterprise tier and put it behind single sign-on, so usage is tied to a named account that can be attributed, capped and revoked, and the administrator console answers retention and audit questions. A licence bought on a personal card with a shared login produces none of that.

Control the egress point rather than the tool. Microsoft Purview data-loss prevention policies cover enterprise applications and devices and inline web traffic in Edge for Business and on the network, and Microsoft's documentation names ChatGPT, Gemini, DeepSeek and Copilot among the unmanaged cloud apps in scope. A matched policy can tip, block, or block with a justified override, and every match reaches the audit log.

Manage browsers and extensions, and treat API keys as credentials with budgets. Register each key to an owner and a purpose, cap the spend, alert on anomalies and rotate it. An unmanaged key sits in no endpoint inventory and writes no prompt log, so it is the leak nobody sees until the invoice arrives.

The contractual side

An approved tool is a contract before it is a feature. Anthropic's commercial terms are a published example: the customer keeps its inputs and owns its outputs, Anthropic may not train models on customer content from the services, and a data processing addendum is incorporated into the agreement.

Read four clauses before anything reaches the approved list. Whether your data is used for model improvement by default; how long prompts and outputs are retained and how deletion is evidenced; whether zero-retention or regional processing is available; and what the supplier will tell you if something goes wrong.

The gap is usually the tier rather than the vendor. A consumer subscription often has no data processing addendum, no retention control and no administrator console, which is why the approved list should say nothing confidential goes into it.

Measure adoption instead of fighting it

The metric worth reporting is the share of AI work happening inside the approved tenant, not the count of blocked attempts. Track sanctioned active users, how long intake requests take to answer, and how often a user overrides a data-loss block and why. Overrides cluster where the policy is wrong, which makes them the best tuning signal the owner gets.

NIST's framework organises the work into four functions, govern, map, measure and manage, and treats measurement as a function of its own. Adoption rising while block counts stay flat means the policy is working; block counts climbing alone usually mean the approved list is too short.

What a questionnaire or an auditor will ask

Expect the same questions from a customer security questionnaire, an insurer or an auditor. Which AI systems are in use and who approved each one. Which data classes may enter them. Whether usage is attributable to a named person. Where the logs are and how long they are kept. What the contract says about training and retention. Who owns the policy and when it was last reviewed.

ISO/IEC 42001 gives that a management-system shape. Published in December 2023, the standard requires a documented AI policy, defined roles, an impact assessment, internal audit and continual improvement, and a third party can certify against it.

The EU AI Act adds a training duty on top of the paperwork. Its AI literacy obligation applied from February 2025, so an organisation deploying AI systems is expected to make sure the people using them understand them well enough, and a questionnaire may ask for the record.