Every week, staff at regulated UK firms paste client names, legal documents, financial forecasts, and internal strategy into ChatGPT, Copilot, and Gemini. Most do it without thinking twice. Most have never read the acceptable use policy that forbids it. Most firms have no control that would stop them even if they had.
This is a design problem, not a rogue-employee problem. AI tools are fast, useful, and available everywhere. The pressure to use them is real. When the path of least resistance runs straight through a public chatbot, people take it.
The question worth asking is not whether to let staff use AI at all. The question is how to make safe AI use the easy option and unsafe AI use the path with friction. That requires something more than a policy document.
Why staff paste data into AI tools
The short answer is that it helps them work faster.
Take a straightforward example. A compliance analyst needs to summarise a thirty-page client suitability file. Copying the text into ChatGPT and asking for a summary takes thirty seconds. Writing the summary manually takes forty minutes. The analyst has six more files to review before the end of the day. The choice is obvious, even when the data is regulated.
Nobody trains staff to weigh data handling obligations at speed, under the kind of daily pressure that makes the fast option feel harmless. They are busy. The tools they are reaching for are genuinely impressive. The risk feels abstract compared with the actual deadline they are facing.
Policies that frame the problem as individual irresponsibility miss this entirely. The behaviour continues under a different tool, or in a browser the monitoring does not reach.
What data is actually at risk?
The data that ends up in AI tools tends to cluster around the work that is most cognitively demanding. Document drafting. Research and summarisation. Email composition. Financial modelling.
For regulated firms that means client information, case files, suitability assessments, transaction records, and internal forecasts all sit in scope. The fact that a public chatbot may not retain the data after the session ends does not remove the exposure. The data has left your environment. You do not know where it has been processed, what has been logged, or what the AI provider's actual data handling looks like under their terms of service.
The picture is also wider than consumer AI alone. Productivity assistants built into Microsoft 365 and Google Workspace can reach far more than staff realise. An employee asking Copilot to prepare briefing notes for a client meeting may not know that the assistant is drawing on emails, calendar entries, and shared documents far beyond what the employee consciously chose to share. We covered this in detail for Microsoft 365 Copilot and for Google Workspace Gemini, and in both cases the default data access model is broader than most users expect.
What does the FCA expect?
Neither the FCA nor the PRA has published a specific rulebook on staff AI use. What they have done is make clear, through existing supervisory expectations on model risk, Consumer Duty, and operational resilience, that firms need to know where and how AI touches decisions affecting customers.
The practical reading is this. A firm that cannot show a regulator which AI tools are in use, what data those tools can reach, and what controls prevent misuse is in a weaker position than one that can. An inability to answer those questions is an evidential gap, and evidential gaps attract follow-up questions.
The Senior Managers and Certification Regime sharpens the issue further. Someone with named responsibility for technology or data risk has personal accountability for the firm's AI controls. That accountability is difficult to discharge if the firm does not know which AI tools staff are actually using.
An AI governance framework gives you the structure to document and evidence this. The starting point, though, is knowing what is actually happening.
Can you block it at the network level?
For some categories of AI, yes. Blocking access to consumer AI chatbots at the network perimeter is a reasonable step for many regulated firms. It removes the most obvious vector and is relatively straightforward to implement.
The complication is that it solves only part of the problem.
AI is now embedded in tools staff expect to use every day. Browser extensions. Email clients. Productivity suites. The AI layer inside Microsoft 365 and Google Workspace sits within services that are already approved and cannot simply be cut off. Blocking ChatGPT does not stop data flowing into Copilot. Blocking Gemini at the URL level does not prevent the AI functionality built into Google Docs from processing client material.
Even where blocking is in place, staff find routes. Personal devices on mobile data. Home offices. Tools accessed through a browser the corporate monitoring does not cover.
Network-level blocking is a useful first layer. It is not a complete answer on its own.
Why acceptable use policies alone are not enough
Acceptable use policies are written for calm conditions. Staff make decisions at speed, under pressure, with incomplete information about the data handling implications of the tools in front of them.
The problem is structural. A policy that depends on every employee correctly categorising each piece of information, recalling the relevant clause, and choosing the compliant option under time pressure will fail regularly. People do not process risk the same way in a hurry as they do in a quiet room with the policy open in front of them.
The evidence on training bears this out. In IntelXview's study of hundreds of thousands of employees across hundreds of organisations, recall of conventional annual training fell to around low within weeks of delivery. Knowing a policy exists is not the same as applying it correctly in the moment that matters. The evidence behind behaviour-change learning is clear on this: awareness campaigns wear off, and they wear off fastest when the behaviour they are trying to change is genuinely convenient.
This does not make training pointless. It means training works alongside technical controls, not instead of them.
What a layered approach looks like
The firms that have this under control use several layers working together. None of the layers is sufficient on its own.
An up-to-date AI inventory. You cannot control what you do not know about. Most firms find their shadow AI problem is bigger than their approved tool list suggests. Consumer chatbots, browser extensions, personal accounts on AI platforms, and AI baked into software that came through procurement without anyone flagging the AI component all belong in scope. A detailed look at shadow AI shows how these tools typically enter organisations and why they so often go undetected.
Technical enforcement. Data loss prevention at the network layer, scoped to cover AI endpoints rather than only traditional exfiltration paths. Conditional access policies that prevent personal accounts on AI platforms being used on corporate devices. Explicit configuration of productivity AI tools to limit data scope. The exact tooling varies, but the goal is consistent: friction for unsafe choices, not just a prohibition written on paper.
Configuration review for approved AI. Many firms have Microsoft Copilot or Gemini for Workspace enabled without ever checking what the default data access model looks like in practice. Approved AI can carry as much risk as shadow AI if it is configured to reach everything a user can see across their whole environment. A technical review of your AI configuration is a different exercise from an acceptable use policy. It examines what the tools can actually do, not what you intended when you turned them on.
Ongoing visibility. Controls that are set once and forgotten drift. Users find routes around them. New AI functionality appears inside existing tools without a fresh procurement decision. Maintaining visibility over which AI tools are in use and what data they can reach is a continuous requirement, not a one-time project.
Where to start
The firms that try to build controls without a clear picture of what they are controlling usually build controls that miss the real exposure.
Start with a structured review of your current AI use. Not the approved tool list. The actual pattern of what staff are accessing and what data is involved. That includes consumer AI in use on corporate devices, personal accounts on AI platforms, browser extensions, and the AI capabilities inside the productivity tools already running across the firm.
From that baseline you can prioritise. Some findings warrant immediate action. Data leaving the environment through unapproved services with no data processing agreement sits at the top, as do configuration settings that can be tightened quickly. Policy gaps, logging coverage, and awareness form the work of the following quarter. They are real, but less urgent.
The baseline also gives you something to put in front of a board or a regulator. An evidenced picture of your AI exposure, with a documented plan to reduce it, is a very different conversation from a general assurance that you take AI risk seriously.
An AI Data Leakage Risk Assessment is designed to produce that baseline in two weeks, fixed scope, at £1,500. The written report covers what is leaving, through which tools, and where the controls need work. It includes the configuration review for productivity AI, the shadow AI discovery, and the gap analysis against current policy. The output is practical and prioritised, so you know which problem to solve first.
If you run on Microsoft 365, the Copilot-specific risk assessment goes deeper on how the AI layer inside your existing environment is configured. Google Workspace users can take the same approach through the Gemini risk assessment.
The broader AI governance framework gives you the structure to keep controls current as your tooling changes. But the sequence matters. Get the inventory and the baseline first, then build controls around what you actually have.
