A leadership team signs off on the new AI policy. Three pages, carefully drafted, reviewed by legal. Staff receive an email: from now on there are rules for using AI at work. Everyone clicks "read and understood". The document goes into the quality system. Box ticked.
Thirty days later, an analyst pastes a customer file into ChatGPT to draft a quick summary. Not out of defiance. She is busy, the deadline is real, and the policy document is the last thing on her mind.
The question is not whether that happens. The question is whether you would see it if it did. For most organisations, the honest answer is no.
A policy on paper is not control
An AI policy describes what should happen. It says nothing about what does. That difference is exactly where the risk sits, and it is wider than most leaders assume. As long as you cannot see what sensitive data employees enter into AI tools, compliance is an assumption. GDPR does not ask for a document. It asks you to demonstrate compliance. And proof does not begin with a signature under a policy. It begins with visibility at the moment someone types.
Why a policy never reaches the behaviour
Most organisations address AI risk in three ways: write a policy, run a training, and sometimes block a few tools. All three are useful. None of them changes what happens the second a colleague wants to get something done quickly.
A policy is an agreement at a distance. It is written, read, and then largely forgotten. Not because people fail to take it seriously, but because a document does not announce itself at the moment that matters. The decision to paste something into a prompt takes two seconds. At that moment the policy is in a folder nobody opens.
Training works on Monday. The mistake happens on Thursday, when the knowledge has sunk beneath the workload. Knowledge is not behaviour. Someone can know perfectly well that client data does not belong in a free chatbot and do it anyway, because the habit is stronger than the rule.
And blocking? It sounds like the safest choice, but it usually delivers the least visibility. Cut off access to AI and you do not get a safer organisation. You get workarounds: a personal account, the employee's own phone, a tool nobody approved. This is shadow AI, and it is harder to govern than the behaviour you were trying to stop.
So the gap is not in the policy. It is between the policy and the practice. And you cannot close that gap with more policy.
What is actually happening
How wide is the gap? The numbers are uncomfortably concrete.
Research by Cyberhaven, based on the behaviour of millions of employees, found that 39.7% of all workplace AI interactions contain sensitive data. Two years earlier it was 10.7%. The data includes source code, customer records, contracts and salary information. Translated into a working week, the average employee pastes something sensitive into an AI tool roughly once every three days.
These are not edge cases. This is the average.
And it shows up in real incidents. Samsung restricted internal use of ChatGPT in 2023 after engineers pasted confidential source code into the tool, where it could no longer be retrieved. In March 2024, the US House of Representatives banned staff from using Microsoft Copilot, after its Office of Cybersecurity judged that the tool risked exposing House data to non-approved cloud services. In both cases the organisations were not careless. They simply discovered, after the fact, what was actually being entered.
That after-the-fact pattern is the point. The policy existed. The visibility did not.
The objection, taken seriously
Here is the objection I hear most: "Watching what employees type feels like Big Brother. We trust our people."
That is a fair concern, and it deserves an honest answer. Individual surveillance, looking over the shoulder of who typed what, has no place in a workplace built on trust. It meets resistance from staff and from worker representatives, and that resistance is healthy.
But visibility and surveillance are not the same thing. The difference is the level at which you look. You do not need to know that one named person pasted a specific sentence at 2:12pm. You want to know which categories of sensitive data appear in which tools, how often, and whether the number of risk signals falls after you change something. Those are aggregated figures, not files on people.
Trust and proof are not in conflict. You trust your accounts, and you still have an auditor look at them. Not to catch anyone, but to be able to show that they are sound. The same applies to AI use. The goal is not to reveal who got it wrong. It is to help people before a mistake becomes an incident.
From policy to proof
Ask yourself five questions. They are uncomfortable, and that is the point.
- Can you show which categories of sensitive data are going to AI tools in your organisation? Not suspect, but demonstrate.
- Do you know which tools it happens in? Approved tools, or the free versions where input may be retained for training?
- Would you see it if an employee pasted a customer file into a chatbot today? Or would you only hear about it when a breach notification is already filed?
- Does the number of risk signals fall after you run a training or set a rule? Without measurement, you do not know whether you achieved anything.
- Can you show all of this without naming individual employees? Otherwise you get resistance instead of compliance.
If you cannot answer these with figures, you have a policy but no proof. And GDPR's accountability principle, Article 5(2), asks for the second one: demonstrable compliance. Since February 2025, the EU AI Act's AI-literacy obligation sits on top of that.
The practical step is not to write more policy, but to add visibility where the risk begins: the moment of entry. Start small. Measure what actually happens for two weeks. That single insight changes the conversation with your team more than a tenth draft of the policy document.
And that visibility does not have to be about individuals. At board level you want aggregated figures: how much sensitive data was detected, in which tools, which data types recur, and whether the line falls after you change something. This is what that proof layer looks like:
ChatGPT
