How to write a workplace AI policy.
That people actually follow.
Most workplace AI policies fail the same way: written once, announced once, and never seen again. This guide covers what an AI acceptable use policy for employees actually needs to include, who should own it, how it differs from guardrails, and how to write one your team will follow — without a legal team drafting it.
Cloud Systems Engineer · MCT · PMP · Azure Solutions Architect Expert. 40+ years in IT and operations. Builder of the Blair AI Rollout Framework.
Published July 2026 · About Steve →What is a workplace AI policy?
A workplace AI policy is a written document that defines how employees may use AI tools on the job — which tools are approved, what data can and cannot be entered into them, how AI outputs must be reviewed before use, and who is accountable when something goes wrong. Unlike informal guardrails, a policy is documented, versioned, and owned: it has a named owner, a written record, and a review date.
A policy without an owner is just a document.
Ask most organizations whether they have an AI policy and you'll get one of two answers: "no, we should probably write one" or "yes, it's in the employee handbook somewhere." Both answers describe the same situation — nobody owns how AI is actually being used.
Here's the honest truth: the document is the least important part of an AI policy. What matters is the set of decisions the document records — what's allowed, what isn't, who decides, and what happens when reality doesn't match the plan. An unwritten policy with a clear owner beats a beautifully formatted PDF that nobody has opened since the day it was announced.
That's why this guide starts with ownership and coverage, not formatting. Get those decisions right and the writing takes an afternoon.
What a workplace AI policy needs to cover at minimum.
You don't need forty pages. You need clear written answers to six things:
1. Approved tools and acceptable use
Which AI tools are approved for work use, which are explicitly not, and what happens when someone wants to add one to the list. This is the section most policies skip — and it's where shadow AI comes from.
If there's no sanctioned path to request a tool, employees don't stop using AI. They stop telling you about it.
2. Data handling boundaries
What data classifications can and cannot go into AI tools — especially cloud-based ones. Customer records, employee data, confidential contracts, strategic plans: each needs a clear answer before someone pastes it into a prompt. A simple three-category framework (freely usable, use with caution, never use with AI) covers most organizations.
3. Output review expectations
AI makes mistakes — sometimes subtle ones. Your policy should define what "review before acting" means for the use cases your team actually has. A customer-facing email drafted by AI needs a different review standard than a summary of internal meeting notes.
4. Ownership and escalation
Who owns the policy, who answers questions about gray areas, and who gets told when an AI output causes a real problem. A named person, not a committee.
5. Error reporting without blame
If reporting an AI mistake gets someone in trouble, mistakes stop getting reported — they don't stop happening. The policy should make clear that documented errors are organizational learning, not individual failure.
6. A review date
AI tools change faster than most policies do. A policy without a scheduled review date is a snapshot, not a system. Quarterly works for most small and mid-sized organizations.
Who should own the AI policy — IT, legal, or operations?
The honest answer: whoever is closest to the workflows where AI is actually being used. In most organizations of 200 to 5,000 employees, that's operations — not IT, and not legal.
IT can tell you which tools are secure. Legal can tell you where the liability sits. But neither one sees the daily reality of how AI is changing the work — which workflows people are quietly accelerating, where outputs are going unreviewed, and which teams are furthest ahead. The policy owner needs that visibility, because a policy written without it describes an organization that doesn't exist.
That doesn't mean operations writes the policy alone. It means operations owns it — with IT consulted on tool security, legal consulted where regulation or liability demands it, and leadership signing off on the boundaries. Ownership means one named person is accountable for the policy being current, known, and followed. If you can't name that person today, that's your starting point.
This is the same ownership-and-accountability principle that runs through the guardrails guide — a policy is where that ownership gets written down.
AI policy vs. AI guardrails: what's the difference?
The two terms get used interchangeably. They shouldn't be.
Guardrails are the working norms — the practical rules a team applies day to day: what data is off-limits, how outputs get reviewed, who to ask when something's unclear. Guardrails can exist without a formal document, and in the first 30 days of a rollout, they usually should. (How to set them: How to Set AI Guardrails in the Workplace →)
A policy is what happens when those norms mature: written down, versioned, owned, and applied consistently across teams. A policy makes guardrails durable — they survive personnel changes, apply to new hires automatically, and hold up when someone asks "where does it say that?"
The sequence matters. Organizations that write the policy first, before running anything real, produce documents full of guesses. Organizations that run a structured pilot first — with working guardrails — write policies grounded in evidence. Set guardrails now; formalize the policy once you've seen how they hold up in practice.
What a good AI policy structure looks like.
Principle-level — no template needed to start:
- One page to start. If your first AI policy is longer than a page, it will be skimmed once and never read again. You can expand it as your rollout matures; you can't un-bore your team.
- Plain language, not legal language. The test is whether a new hire could read it and know what to do Monday morning. "Exercise appropriate caution" fails that test. "Never paste customer data into a public AI tool" passes.
- Written from real use, not hypotheticals. The best source material is what your team is already doing — which is why getting visibility into existing AI use comes first. If employees adopted AI before any policy existed, that's not a crisis; it's your requirements document. (What to do with it: Your Employees Are Already Using AI — Here's What to Do About It →, from the podcast.)
- Versioned and dated. Policy v1.0 with a review date signals this is a living system. An undated document signals it's already abandoned.
The Blair AI Rollout Framework includes a governance policy starter template.
The framework's governance module includes a policy starter template built for managers who don't have a legal team drafting their AI policies — along with the gate documents that turn a written policy into practiced governance. Principle to practice, in sequence.
See What's Inside the Framework →Related resources.
AI Guardrails Guide →
The working norms your policy will eventually formalize.
AI Rollout Framework Guide →
Where policy fits in the full 90-day rollout.
AI Readiness Assessment →
Measure your governance pillar before you write anything.
Common questions.
Write the policy after you know where you stand.
The free AI Readiness Score measures your governance pillar — including policy and ownership gaps — in about 5 minutes. The Blair AI Rollout Framework then gives you the policy starter template and the structure to make it real.