Insights · Governance · September 2026
How to write an AI policy your staff will actually follow
Surveys through 2026 put AI use at work near 67 percent of employees, while only 18 percent of organisations hold a formal AI policy and another 44 percent say they are still drafting one. Most firms read that gap as a drafting problem and commission a document. That is the wrong diagnosis. It is a design problem, and the document they commission usually makes it worse.
Your staff already decided
The numbers are consistent across independent 2026 surveys even where the samples differ. Around 67 percent of employees report using AI tools at work, roughly 52 percent of organisations have no formal policy covering external AI tools, and a further 44 percent say they are drafting one and have not finished. Meanwhile 38 percent of employees admit to putting sensitive company information into an AI tool without permission, and 43 percent of organisations say they could not produce an inventory of which AI tools their people are using if you asked them today.
Read those four numbers together. The conclusion is uncomfortable. The decision about whether your organisation uses AI has already been taken, by your staff, one browser tab at a time, and the only open question is whether you find out through a policy or through an incident.
The policy nobody reads twice
Here is the finding that should change how you write yours. Research into disclosure behaviour in 2026 found that having an AI usage policy did not, on its own, predict whether employees told anyone they had used AI on a piece of work. Neither did giving them an approved tool. People hid it anyway.
That result makes sense once you read the average policy. It is written as a list of prohibitions by a legal team with no visibility of the actual work, it names three banned products in a market that ships a new one every fortnight, and it offers the employee nothing in exchange for compliance except the absence of trouble. So a competent person facing a deadline does the obvious thing: they use the tool, get the work done well, and say nothing about how.
The failure is predictable. A policy that only forbids creates a cost for honesty and no cost for silence, which is exactly backwards from what you need.
What the document has to settle
Skip the preamble about the organisation's commitment to innovation. A working policy answers four questions, and a staff member should be able to find each answer in under a minute.
Which data may leave the building. Classify the data, never the tool. Three tiers is enough: open (marketing copy, public filings, anything already on your website), internal (drafts, process notes, anonymised figures), and restricted (client records, personal data, anything under contract or regulation). Then say plainly which tier may be pasted where. Tool lists rot within a quarter; a data rule written in 2026 still reads correctly in 2028.
Which tools are sanctioned, and how a new one gets added. The second half matters more than the first. Name the route, name the person who answers, and commit to a response time you will actually meet. If adding a tool takes six weeks, your staff will not use the route, and you are back to browser tabs.
When AI use must be disclosed. Be specific about where it counts: client deliverables, hiring decisions, anything that goes on a letterhead. Be equally specific about where it does not, because a policy demanding disclosure of every autocomplete teaches people to ignore the whole document.
What a person is still accountable for. This is the shortest clause and the one that carries the weight. The employee who sends the work owns the work. AI performing a task changes nothing about whose name is on it.
Four moves that change behaviour
A policy is followed when the sanctioned path is the fastest path. Everything below serves that one idea.
One page, in the language of the work. If it runs past a single side of A4, it becomes an onboarding attachment nobody opens. Write it for the person doing the job, and test it by handing it to your newest hire and asking what they may paste into a chatbot.
Pair every restriction with a route. "Do not put client data into public models" is half a sentence. Finish it: here is the approved workspace, here is who sets it up, here is how long that takes.
Train on the actual systems, not on principles. This one now has a deadline attached in Europe. The EU AI Act's Article 4 literacy duty applied from February 2025, and supervision and enforcement opened on 2 August 2026, six weeks before this article was published. It covers any organisation deploying AI systems, of any size, and extends to contractors operating those systems on your behalf. There is no obligation to test your staff, but you are expected to be able to show what training happened, so keep the register.
Review it on a date, not on an incident. Put a quarterly review in the calendar with a named owner. The market moves faster than your document, and a policy last touched in March is a policy your staff have already worked around by September.
One limit, stated plainly, because most people selling governance will not say it. A policy will not stop a determined employee with a personal phone and a deadline, and no amount of drafting changes that. What it does is remove the excuse of not knowing, give the careful majority a defensible path, and leave you able to answer the question a regulator or a client will eventually ask about how this work was done.
Write the policy with the people who have to live with it
Policy and practice fail separately. Our team training engagement runs the document and the hands-on work together in the same week, for that reason. Staff build automations for their own processes, the data tiers get decided against real documents rather than hypotheticals, and you finish with a one-page policy, a sanctioned tool route, and a training register that satisfies Article 4.