Assume it is already happening. In every organisation where we have run discovery on this question, the answer has been the same: a meaningful proportion of staff are using consumer AI tools for work, and the business has no record of it.

This is not a disciplinary matter. The tools are free, immediately useful, and often faster than the sanctioned process. Someone summarising a forty-page supplier contract in thirty seconds rather than an afternoon is responding sensibly to the incentives you have given them.

The question is not how to stop it. It is how to make it visible, bounded and safe.

Why a ban does not work

The instinct is to prohibit it, and the instinct is understandable. It is also the worst available option, for three reasons.

It is unenforceable. These tools are reachable from a phone, a home laptop, or a personal browser profile. Blocking the domain on the corporate network moves the activity to a device you cannot see, using an account you do not control.

It removes your visibility entirely. A policy that drives usage underground converts a manageable problem into an invisible one. You lose the ability to answer the question you will eventually be asked: has our client data been processed by an AI system?

It costs you the benefit. Competitors whose staff use these tools well are getting real productivity gains. A prohibition forfeits that while achieving none of the protection it promised.

What the actual risk is

Being precise about the risk helps, because it is narrower than the general anxiety suggests.

Data leaving your control. Text pasted into a consumer tool leaves your environment and sits on a third party’s infrastructure under their terms. For most free tiers, those terms have historically permitted the provider to use submitted content to improve their models. Even where they no longer do, the copy exists outside your governance.

No record of what was shared. This is often the more serious problem. If a client asks whether their information has been through an AI system, or a tender questionnaire asks about your AI controls, “we don’t know” is a commercial answer as much as a technical one.

Personal accounts holding business material. An employee’s personal AI account accumulates work context — documents, client details, draft strategy — and leaves with them.

Browser extensions and plug-ins. Frequently overlooked and often the largest exposure. An AI extension with permission to read every page a user visits has access to your CRM, your finance system and your webmail simultaneously.

Unverified output entering business processes. Confidently wrong content in a customer email, a report or a regulatory return. This is an operational risk rather than a data protection one, and it needs a review step rather than an access control.

The approach that works

Every successful governance position we have implemented shares one property: the approved route is faster than the workaround. If it is not, the policy is decorative.

1. Find out what is happening

Before writing anything, establish the facts. Useful sources include enterprise application and consent data in Entra ID, browser extension inventory from your device management, network or proxy logs, expense claims showing personal AI subscriptions, and — most productive of all — asking teams directly.

That last one works better than people expect, provided it is framed as fact-finding rather than an investigation. Staff generally have no idea they are doing anything problematic and will tell you exactly what they use and why.

2. Provide a good sanctioned tool

This is the step that determines whether everything else succeeds. A business-tier AI tool, reached through your normal sign-in, with contractual protection against training on your data.

The specific choice matters less than the properties: tenant-bound identity, data-retention controls, a commitment that your content is not used for training, administrative visibility, and the ability to revoke access when someone leaves. Microsoft, OpenAI, Anthropic and Google all offer business tiers meeting that description; which fits depends on what your staff actually do and what you already pay for.

3. Write two pages, not twelve

A policy people will read. It needs to answer three questions:

  • Which tools may I use for work?
  • What information must never go into them?
  • What do I do if I am not sure?

Name the categories of information that are off-limits in terms specific to your business — client personal data, unpublished financial results, HR records, anything covered by a client confidentiality clause. “Confidential information” is too vague to act on.

Include what happens when someone gets it wrong. If the answer is disciplinary action, nobody will report a mistake and you will find out from the client instead.

4. Enforce through identity, not documents

Bring the approved tool inside your identity provider so it inherits your conditional access, device requirements and offboarding. Restrict user consent for applications so staff cannot grant a new tool broad access to their mailbox. Get browser extensions under management. These controls do the real work; the policy explains them.

5. Say it out loud, and revisit it

Brief the organisation in plain terms: here is what we have provided, here is what it is for, here is the short list of things that must not go into it, and here is who to ask.

Then schedule a review. The tool landscape in six months will not be the one you wrote for.

What this achieves

You will not eliminate every instance of unapproved use, and aiming for that is a mistake. What you will achieve is proportionate and genuinely valuable: you will know what is in use, the majority of activity will run through a tool with contractual protection and logging, the categories of information that matter most will be named and understood, and you will be able to answer a client’s question honestly.

That is a considerably better position than a prohibition nobody follows — and considerably better than not having asked.