How to write an AI policy for your organisation
Most organisations that have started using AI tools have not written a policy governing them. They have relied on acceptable use guidelines borrowed from IT security, verbal guidance from managers, or nothing at all. Meanwhile, their employees are feeding customer data into public LLMs, using AI-generated content without disclosure, and making decisions informed by outputs nobody has audited.
The problem is not that business leaders are reckless. It is that writing an AI policy feels either too early or too complicated. So it gets deferred - until something goes wrong.
This article will show you what an effective AI policy actually needs to cover, how to structure it without producing a document nobody reads, and the specific decisions your organisation needs to make before you can write it honestly. It will not give you a template to copy. It will give you a framework for thinking through the decisions that make an AI policy meaningful rather than decorative.
Why most AI policies fail before they are published
The most common failure mode is writing a policy before making the underlying decisions.
A retail business we spoke to had published a two-page AI policy that prohibited the use of "unapproved AI tools" without defining what approval looked like, who granted it, or what tools were currently approved. The policy created the impression of governance without providing any. Six months later, they discovered that three teams were using different AI writing and analysis tools, none of which had gone through any process because no process existed.
A policy written around vague principles - "use AI responsibly", "ensure accuracy", "maintain data privacy" - gives employees no usable guidance. It also gives the organisation no defensible position if something goes wrong.
Before you write a word, your leadership team needs to answer four questions:
- Which AI tools are currently in use across the business, sanctioned or otherwise?
- What categories of data are employees permitted to process using external AI systems?
- Who owns AI-related decisions - technology, legal, operations, or a combination?
- What does accountability look like when an AI-assisted decision causes harm or error?
Until you have honest answers to those questions, you are not ready to write a policy. You are ready to do an inventory.
What an AI policy actually needs to cover
An AI policy is not an ethics statement. It is an operational document. It should tell people what they can do, what they cannot do, who to ask when they are not sure, and what happens if they get it wrong.
There are five components a policy needs to address.
Scope. Which tools, systems and use cases does this policy cover? Is it all AI, or only generative AI? Does it cover AI embedded in existing software - the summarisation feature in your CRM, the forecasting module in your ERP? Scope creep in the other direction is just as dangerous: a policy that tries to cover every conceivable AI scenario will paralyse teams and be ignored.
Data classification. This is the most practically important section. It should state, unambiguously, which categories of data may be processed using which categories of tool. A useful starting structure is three tiers: internal and non-sensitive data that can be used freely with approved tools; commercially sensitive or personally identifiable data that requires specific approval and tool vetting; and regulated or confidential data that may not be processed through external AI systems at all. A logistics firm handling third-party supply chain data will draw those lines differently from a professional services firm handling client communications.
Approved tools and the approval process. List what is currently approved. Describe the process to get something approved. Assign ownership of that process. Without this, the prohibition on "unapproved tools" is unenforceable.
Human oversight requirements. Not all AI use cases carry the same risk. A copywriter using AI to generate first drafts of product descriptions carries very different risk from a credit analyst using AI to summarise financial statements. Your policy should define where AI outputs must be reviewed and approved by a qualified human before acting on them, and at what stakes that requirement kicks in.
Accountability and reporting. Who is responsible when an AI-assisted output causes a problem? The policy should name roles, not individuals, and it should include a mechanism for employees to raise concerns without requiring them to prove wrongdoing first.
How to make the policy usable, not just defensible
Length is not the problem with most AI policies. Abstraction is.
A policy that runs to twenty pages and uses phrases like "commensurate risk controls" and "responsible innovation principles" will not change behaviour. A policy that tells a marketing manager exactly which tools she can use to draft copy for a client campaign, and exactly what she needs to do before that copy goes live, will.
The most effective format separates the governing document from the practical guidance. The governing document sets principles, defines categories and establishes accountability. Separate, shorter guidance notes cover specific use cases: how to use AI in customer communications; how to use AI in financial analysis; how to use AI when working with third-party data.
This structure also makes the policy easier to maintain. When a new tool or use case emerges, you add or update a guidance note rather than reopening the governing document.
One manufacturing client structured their AI guidance as a decision tree embedded in their intranet. Three questions - what data are you using, what will the output be used for, who will see it - routed employees to the right guidance in under thirty seconds. Adoption was measurably higher than their previous text-heavy policy.
The regulatory and contractual dimension you cannot ignore
UK organisations are not operating in a regulatory vacuum. The EU AI Act has extraterritorial reach that will affect UK businesses with European customers or operations. The ICO has published guidance on generative AI and data protection that sits directly alongside your obligations under UK GDPR. If you operate in financial services, the FCA's expectations around model risk and explainability add another layer.
Your AI policy needs to reflect your actual regulatory exposure, not a generic interpretation of it.
The contractual dimension is frequently overlooked. Many enterprise software contracts now include clauses governing how AI may be used in conjunction with the vendor's platform. Client contracts, particularly in professional services and consulting, may include provisions about whether client data can be processed by third-party AI systems. A policy that ignores these obligations is not just incomplete - it is a liability.
Before finalising your policy, legal review is not optional. But legal should be reviewing a document your operational teams have shaped, not writing one from scratch. A policy written only by lawyers will be technically defensible and practically useless.
Who should own the AI policy, and how often should it change
Ownership matters more than most organisations realise. An AI policy owned by IT becomes a technical control document. Owned by legal, it becomes a risk register. Owned by no one, it becomes shelf furniture.
The most effective model we have seen places a named senior leader - a CDO, a COO, or a technology-fluent CFO - as the policy owner, with a cross-functional working group responsible for maintaining it. That working group should include legal, technology, operations and at least one business unit lead who can represent the day-to-day reality of how people actually work.
On frequency: AI capabilities are changing fast enough that an annual review cycle is likely insufficient. A pragmatic approach is a formal review every six months, with a standing mechanism to trigger an unscheduled review when a materially new tool, use case or regulatory development emerges.
The cost of not having an AI policy is not hypothetical. It is a data breach that was entirely preventable. It is a regulatory inquiry triggered by an employee who did not know the rules. It is a client relationship damaged because AI-generated content was passed off as original analysis without disclosure.
Writing a policy is not complicated. Making the decisions the policy encodes - that is the hard part. Most organisations avoid it because those conversations require someone to take a position.
Start with a diagnostic. Understand what tools are actually in use, where your data exposure sits, and what your regulatory obligations require. From there, the policy writes itself.
If you want a structured way into that process, Rodan's diagnostic engagement is designed to surface exactly these questions - and give you a clear picture of where your AI governance gaps are before they become problems. [Book a diagnostic at rodan.io.]
