Someone has handed you a sixty-page enterprise policy template and told you to make it fit a ninety-person business. You can already feel how this ends. The document is thorough, it cites the right frameworks, and nobody in the building will ever read it. You know your team well enough to know that. They will keep using whatever tool gets the job done, the policy will sit in a shared drive as proof that governance exists, and the first time something goes wrong it will turn out the policy never touched the actual behaviour. The version that works is shorter, plainer, and built around a different starting assumption.
What makes an AI policy people actually follow?
A policy people follow is short, specific, and built on permission rather than prohibition. It names the handful of genuinely banned uses, shows clear examples of safe use, and fits on two or three pages. The real test is whether someone three weeks into the job can read it once and know what they are allowed to do. A policy that fails that test governs nothing, however thorough it looks.
The common failure modes are two. One policy is so restrictive that the team quietly routes around it, and you lose sight of where AI is being used at all. The other is all prohibition and no permission, a list of things you must not do that leaves people genuinely unsure what they can do. Both produce the same result, which is a document that exists on paper and not in practice. Getting the posture right is the first decision, and it shapes everything else.
Why default-allow beats default-ban
Default-allow with guardrails beats default-ban because a ban drives AI use underground, and underground use is the one thing you cannot manage. The evidence on shadow AI is consistent. The Microsoft Work Trend Index found a majority of knowledge workers already using generative AI for work, frequently without any organisational guidance. People adopt these tools because they help, and a blanket ban does not change that. It just moves the activity out of your sight.
A default-ban posture is easier to write and harder to live with. It reads cleanly as a single line, no AI tools except the approved list, but it creates a perverse incentive. ISACA found organisations worried about unmanaged adoption yet unable to enforce the policies that would stop it, which is the trap exactly. The moment an approved tool is missing or clunky, someone reaches for the free one and tells nobody. You end up blind to your own risk. Default-allow flips the deal. People may use AI unless a use is explicitly forbidden, in exchange for transparency about what they are using and a requirement to flag the higher-risk cases before they proceed. That trade keeps adoption visible and keeps you in a position to intervene early.
This posture asks more of whoever owns the policy, and that is the honest cost. Default-allow needs someone watching where adoption is happening and making judgment calls about new uses as they appear. A ban needs nobody, right up until it fails. For a business that genuinely wants AI working in the operation, the active version is the one that pays off, because it surfaces the productivity signal instead of suppressing it.
What belongs on the short ban list
The genuine bans are few, and naming them explicitly is what gives the rest of the policy its freedom. Feeding client-confidential data into free public AI tools is the first and clearest. Free tiers train on what you type, so a client note pasted in becomes part of the model, with no Data Processing Agreement behind it. The Samsung leak in 2023 was exactly this, and it can happen at any scale.
The second ban is publishing AI-generated content without disclosure where disclosure is required. Under the EU AI Act and ICO guidance, AI-generated text, images or audio that could mislead must be labelled, and that reach extends to UK firms with any EU audience. The third is using AI as the sole basis for a consequential decision about a person. UK GDPR Article 22 gives individuals the right not to be subject to solely automated decisions with legal or similar effects, so AI cannot be the deciding factor in hiring, credit or, in a clinical setting, diagnosis. Each of these carries human review as the control, not removal of the tool.
These three cover the cases where the risk genuinely outweighs the benefit. The Samsung leak was employees pasting source code and internal notes into a free tool, the kind of slip that happens in any business under deadline. Sector rules sharpen the edges. The Solicitors Regulation Authority holds a solicitor responsible for catching an AI error before advice leaves the firm. The Financial Conduct Authority expects human oversight of any material AI-informed recommendation. Whatever sector you sit in, the principle holds. Ban the inputs and outputs that create real exposure, name them in plain language, and stop there. A ban list that runs to a page is a sign the posture has drifted back to default-ban.
The permission half people forget to write
The permission half is the part many policies skip, and it is what makes the document useful day to day. Telling people not to put confidential data into AI is no help to someone whose job is drafting client proposals within that rule. A policy that works gives worked examples of good use, not just a wall of prohibitions. It tells people what they can do, with the guardrail attached.
The examples should be concrete. Using AI to draft an email, summarise a long document or generate a first version of a proposal section is fine, provided someone with the relevant knowledge reviews the output before it goes to a third party. Brainstorming and internal analysis are fine, provided no personal or client-confidential data goes into the prompt. A customer-facing chatbot is fine, provided it identifies itself as AI and offers an easy route to a human. In each case the guardrail is a single sentence the person can actually remember, which is the point.
A simple data classification helps people make the call themselves. Sort information into public, internal, confidential and restricted, and map each tier to the tools allowed to touch it. Public data can go into any tool. Internal data goes into paid commercial tools that carry a Data Processing Agreement and do not train on your inputs. Confidential and restricted data stay out of general external tools entirely unless a specific approved arrangement exists. A one-page table showing which tool may handle which tier does more for compliance than three pages of prose, because it answers the question people actually have in the moment.
How to keep the policy alive
A policy stays alive when it has a named owner, a short length, and a regular review. It dies the moment it is written once and never reopened. Give it an owner, usually the managing director for sign-off and a single operations lead for the register. Keep it to two or three pages. Then review it quarterly, because the tools move faster than any annual cycle can track.
The review does not need ceremony. A short quarterly session looks at what new tools people are using, what went wrong with existing ones, and whether the ban and permission lists still match reality. Borrowing the structure from the NIST AI Risk Management Framework helps here without the overhead. Govern is your owner and your policy. Map is a simple register of tools in use and the data they touch. Measure is the quarterly look at what is working. Manage is the decision to add a tool, retire one, or tighten a guardrail. That is governance an owner-managed business can sustain, and it keeps the policy connected to how the business actually runs.
The honest measure of an AI policy is behaviour, not the document. If people read it, understand it, and act on it, two pages have done more than sixty ever would. If you want a second pair of eyes on where the line should sit for your business, that is the kind of decision worth talking through. Book a conversation.
