Your employees are already using AI. Whether you've authorised it or not, tools like ChatGPT, Claude, Copilot, Gemini, and dozens of others are being used every day to draft emails, summarise documents, generate code, analyse data, and research competitors. The question isn't whether to have an AI policy, it's whether you're going to manage shadow AI with intention or by default.
An AI policy is not a technology project. It's a people and risk management initiative. Done well, it gives your organisation a shared framework for what's acceptable, what's not, and who's responsible. Done badly, or not at all, it leaves you exposed to data breaches, IP disputes, compliance failures, and reputational risk that could easily have been avoided.
Why most AI policies fail
Before getting into what to include, it's worth understanding why so many AI policies fail to stick. The most common failure modes are:
- Too long and too legalistic. When a policy requires a law degree to parse, employees skip it. They sign the acknowledgement form, file it away, and carry on as before.
- Written without operational input. Legal or compliance teams write a policy based on risk exposure without speaking to the people who actually use AI in their work. The result is a document that doesn't map to reality.
- No guidance on the grey areas. Most employees don't want to do something wrong, they want to know what's acceptable. A policy that only says "use AI responsibly" without defining what that means in practice is close to useless.
- No update cadence. AI tools and risks change fast. A policy written in 2023 may be dangerously out of date in 2025. Most organisations have no mechanism to keep it current.
A good AI policy is short, plain-English, grounded in real use cases, and tied to someone's accountability. Here's what it needs to cover.
The four things every AI policy must cover
1. Sanctioned vs prohibited tools
Be explicit about which AI tools are approved for use, which are being evaluated, and which are not permitted. This doesn't have to be exhaustive, and it shouldn't try to be, since new tools appear constantly, but it should cover the tools your employees are most likely to encounter.
A practical approach is to create three categories: Approved (you can use these without seeking further permission), Seek Approval (these may be appropriate for specific use cases, ask before using), and Not Permitted (these are off the table for defined reasons, usually data handling or vendor risk). Include the reasoning briefly, so employees understand the logic rather than just the rule.
2. Data classification rules — what can and cannot go into AI
This is the highest-stakes section of most AI policies. When employees use consumer AI tools, even approved ones, they may be sending your data to third-party systems where it could be used for model training, retained on foreign servers, or accessed by the vendor's team.
Your policy needs to define data classifications clearly and map them to AI usage permissions. A common framework:
- Public information: No restrictions on AI use
- Internal information: Can be used in approved enterprise AI tools with appropriate data agreements in place; not in consumer tools
- Confidential information: Can only be used in AI tools with explicit data processing agreements and where data residency is confirmed; requires manager approval
- Restricted information: Customer PII, financial data, health data, legally privileged material, not to be used in AI tools without specific authorisation and legal review
Give concrete examples. "Confidential" is abstract. "The terms of an unannounced acquisition" is concrete and memorable.
3. Output review obligations
AI generates outputs. Those outputs can be wrong, biased, misleading, or inappropriate. Your policy needs to establish clearly that AI output is a starting point, not a finished product, and that the employee who uses that output is responsible for its accuracy and appropriateness.
This matters legally, commercially, and reputationally. If a customer-facing document contains a hallucinated statistic, or a tender response cites a policy that doesn't exist, or code deployed in production has a security flaw that an AI introduced, the organisation bears the consequences. The policy should require review proportionate to the risk of the output, a first draft of an internal memo needs less scrutiny than a client proposal or a regulatory submission.
4. IP ownership and confidentiality
Who owns work that was created with significant AI assistance? This is a live legal question in most jurisdictions, and your policy needs to address it practically even before the law fully settles. Define that AI-assisted work product created during the course of employment belongs to the organisation (consistent with how you treat other work product), establish that employees must not represent AI-generated content as entirely their own to third parties without disclosure where required, and clarify obligations around any creative work where IP origin matters.
Separately, address the risk that employees inadvertently disclose confidential information through AI prompts. Even if the output is fine, the input may have contained sensitive information that is now in a third-party system.
"The most dangerous AI risk in most organisations isn't a rogue AI, it's an employee who pastes a client contract into a consumer chatbot without thinking."
How to structure the policy document
The structure matters almost as much as the content. Aim for a document that can be read in ten minutes, navigated quickly for specific questions, and updated section by section as things change. A practical structure:
- Purpose: One paragraph explaining why the policy exists and what it's trying to achieve. This sets tone and intent.
- Scope: Who does this apply to? Employees, contractors, board members? Which systems and tools? What geographies?
- Definitions: Plain-English definitions of key terms, AI tool, generative AI, LLM, data classification categories. Don't assume shared understanding.
- Rules: The actual do's and don'ts, organised by the categories above. Keep these short, specific, and scannable. Avoid ambiguous language like "appropriate" or "reasonable" without defining what those mean in context.
- Accountability: Who is responsible for what? Who can grant exceptions? Where do employees go with questions? Who owns the policy?
- Review cadence: When will this be reviewed? Who triggers an out-of-cycle review if something significant changes?
Getting employee buy-in
A policy that employees resent or ignore is worse than useless, it gives you a false sense of protection while providing none. Getting genuine buy-in requires more than a mandatory read-and-sign exercise.
Launch it with examples, not just rules. Show employees what good AI use looks like in the context of their actual job. A sales team understands "you can use AI to draft initial outreach emails but must review before sending and should not include client-specific revenue data in the prompt" far better than an abstract policy statement.
Brief line managers first. Managers will field questions from their teams. If they haven't had a chance to read and understand the policy before it lands with their team, they'll either give inconsistent guidance or escalate everything to HR and legal, which slows adoption.
Tie it to your existing data governance framework. AI policy shouldn't feel like a separate foreign document, it should slot naturally alongside your existing data handling policies. If employees already understand your data classification system, extending it to AI use is a small step rather than a new mental model.
Create a clear escalation path. Employees need to know where to go when they're unsure. If the answer is "talk to your manager, who will talk to IT, who will talk to legal," the friction is high enough that most people will either ask nobody or just proceed anyway. Make the escalation path simple and fast.
Keeping the policy current
AI tools and the risks they create are changing faster than the annual policy review cycle that most organisations operate on. A policy that was comprehensive in Q1 may have material gaps by Q3 — a new tool category emerges, a high-profile data breach changes the risk landscape, a new regulation creates compliance obligations.
Build in quarterly review triggers rather than relying on an annual cycle. Define specific events that automatically trigger a policy review: a major AI tool being adopted by a significant portion of the workforce, a security incident involving AI, a regulatory update, or a significant change in the vendor landscape. Assign ownership clearly, whoever owns the AI policy should have both the authority and the remit to update it without a lengthy governance process.
For the major AI vendors you're using, follow their changelog. When a vendor changes its data retention policies, updates its training data practices, or introduces new features that change the risk profile of the tool, your policy may need to be updated to reflect that.
Common mistakes
Banning AI entirely. This is the most counterproductive response to AI risk. Blanket bans don't prevent AI use, they drive it underground. Employees find workarounds, use personal devices, or simply ignore the policy. You lose visibility, control, and the ability to channel AI use towards genuine value. Address the actual risks instead.
Copying another company's policy. A policy that works for a regulated financial services firm in London won't necessarily work for a growing e-commerce business in Barcelona. Context matters enormously, your data, your risks, your tools, your people. Use external examples as inspiration for structure, not as templates to copy wholesale.
Writing only in legal language. Your legal team needs to be involved in the policy. They also shouldn't be the only voice. The finished document needs to be understood by everyone it applies to, which means plain language is not optional.
No named owner. A policy with no clear owner is a policy that will drift. Assign accountability explicitly. The owner should be senior enough to have authority, close enough to the work to understand the operational reality, and have a mandate to keep the policy current.
AI governance vs AI policy
An AI policy is one component of a broader AI adoption framework. It addresses the rules for individual AI use. AI governance is the broader system, how decisions about AI investment are made, how AI projects are evaluated and approved, how AI performance and risk are monitored at an organisational level, and how accountability is structured from board level downwards.
Most organisations need both, but they're not the same thing and shouldn't be conflated. Start with the policy if you don't have one, it's the most immediately actionable. Build toward governance as your AI usage matures and becomes more significant to the business.
Need help drafting your organisation's AI policy?
I work with leadership teams to build practical AI governance frameworks. let's talk →
