Writing an AI Policy People Will Actually Follow

Roughly 80% of organizations describe shadow AI as moderate to pervasive, according to a 2026 enterprise governance survey. Only 25% of those same organizations have full visibility into what their employees are actually doing with AI tools.

Those two numbers tell you everything wrong with how most companies approach AI policy. They wrote a prohibition-heavy document, posted it to the intranet, and called it governance. Their employees kept using AI anyway, just outside any audit trail, any approved tooling, and any quality control.

A policy failed before anyone violated it.

Any company AI policy that works does one thing above all else: it makes safe use easier than unsafe use. That means defaulting to permission, drawing hard lines only where the risk is real, and building the training and measurement to back it up. Everything else is theater.

Why Restrictive Policies Backfire

Access to AI tools in the enterprise rose 50% in 2025, according to Deloitte's 2026 enterprise AI report. That growth did not wait for governance frameworks to catch up. Employees already have opinions about which tools are useful, they already have free accounts, and they are already using them on work tasks whether or not you have a policy in place.

A restrictive policy does not stop this. It just removes your visibility into it.

When employees lack sanctioned tools and explicit guidance, they improvise. Results are not a more cautious workforce. Results are a workforce doing the same things in the shadows, with no training on where AI actually fails.

The failure mode matters because AI does fail in predictable places. BCG's field experiment associated with Ethan Mollick's research found that consultants using GPT-4 completed 12.2% more tasks, worked 25.1% faster, and produced outputs rated 40% higher quality on tasks that fell within the model's capability range. That same research identified a "jagged frontier" effect: performance dropped when workers used AI on tasks outside that range. They did not know they had crossed the line.

A blanket restriction prevents the gains. It does not prevent the failures, because employees who use AI without guidance cannot see the frontier either.

Writing the right policy means drawing the frontier explicitly. It tells people where to go, and warns them clearly about where not to.

The Framework Behind a Policy That Sticks

Patrick Gilbert covers the operational logic behind this in Never Always, Never Never, specifically in the chapters on building an AI-first culture. At AdVenture Media (adventuremedia.ai), this framing maps directly to the AI Double Helix framework: Internal Efficiency and External Value as two strands that have to rise together.

Internal Efficiency, the first strand, is exactly where most AI policy should focus. Drafting emails, summarizing documents, generating first-pass analyses, writing code with human review before release. These are the tasks where AI produces consistent gains, where the risk of a bad output is low, and where the time savings compound quickly. Your policy should make these uses frictionless.

External Value, the second strand, is where the hard lines belong. Content going to customers, decisions affecting hiring or compensation, outputs that carry legal or regulatory weight. Here, human review is not optional.

Most organizations make the mistake of writing a policy that treats all AI use as External Value risk. Everything requires approval. Everything is suspect. Low-risk, high-gain uses get suppressed alongside the genuinely risky ones, and the policy collapses under its own friction.

Separate the two strands. Make the first strand easy. Protect the second strand seriously.

The 4x2 Model Applied to Policy Design

Another framework from the book, the 4x2 Model of Work, gives you a concrete way to think about which tasks belong in which category. Every work task falls into one of four modes: Design, Problem-Solving, Decision-Making, and Building. In an AI-first organization, workers engage with those tasks through exactly two methods: Copiloting (human in the driver's seat, AI as navigator) or Delegating (AI executes, human reviews the output).

For policy purposes, this translates directly:

Copilot-appropriate tasks include Design (brainstorming, ideation, strategic drafting) and Decision-Making (synthesizing data, pressure-testing assumptions). Human control stays constant. Your policy should encourage this without requiring approval workflows.

Delegate-appropriate tasks include Building (producing drafts, code, reports, templates) and repetitive Problem-Solving. Human review happens before output ships. Your policy should define what review looks like before output leaves the building.

If your policy does not make this distinction, it is not actually governing AI use. It is just hoping people make good choices.

What Goes in the Policy (and What Doesn't)

Most AI policies fail for one of three reasons: they read like legal disclaimers, they prohibit more than they permit, or they define no ownership for anything. A policy that people actually follow reads like an operating standard, not a warning label.

Keep it short. A policy that requires a lawyer to interpret will not be read by the people who need it most. One page is not a weakness. It is a feature.

Define what employees may do, not just what they cannot. Approved uses should outnumber prohibited ones. Most AI use inside an organization is low-risk and high-value. Treat it that way.

Draw the hard lines clearly. Four categories warrant genuine restriction: client confidential data and regulated data pasted into unapproved tools; externally facing content sent without human review; high-stakes decisions (hiring, termination, legal, medical, financial) made without approved controls; and factual claims shipped without verification. These are not arbitrary. They are the places where a bad AI output creates real liability.

Assign ownership. A policy with no named owner is a policy with no accountability. Business teams own the use case. Security, legal, and IT own the guardrails. Every AI use case needs a named business owner who can be asked: did you review the output before it went out?

Build in a review cadence. AI capabilities are changing faster than most policy cycles. Commit to quarterly reviews. Put someone's name next to the commitment.

Teams thinking about how to build an AI-first organization more broadly should treat the policy as a foundation, not a destination. It creates the conditions for adoption. Culture does the rest.

Training Is the Policy's Other Half

A policy without training is a liability document. It tells people the rules without giving them the judgment to apply them.

BCG's research makes the training requirement concrete: performance gains are real, but so is the jagged frontier. Employees need to know not just that AI can help, but where it can hurt. Training centered on abstract AI ethics misses this entirely. What employees need is task-level guidance: here is where AI helps, here is where it fails, here is what to do when you are not sure.

Three tiers of training match three levels of exposure:

All employees need a short onboarding module covering approved tools, hard lines, and escalation paths. Thirty minutes. Specific examples. A clear answer to "what do I do if I'm not sure?"

Managers need role-specific guidance on reviewing AI-assisted output before it ships. Checking for AI use is not the goal. Quality standards are. What does an acceptable reviewed output look like in your function?

High-risk teams, anyone handling regulated data, producing external-facing content at scale, or building AI-assisted workflows, need additional training on data handling, documentation, and escalation.

Context from the AI Maturity Ladder in Never Always, Never Never is useful here. People arrive at wildly different starting points. A Dabbler using ChatGPT to polish an email is not the same problem as a Practitioner building automated output workflows. Policy and training should acknowledge that range without shaming either end of it. Urgency is appropriate. Contempt is not.

Shared language matters more than most leaders realize. When people understand the framework, what copiloting means, what delegating means, where the frontier is, they can make better decisions without escalating everything. Judgment at the team level is the goal, not approval chains for every AI interaction.

Measure What the Policy Is Actually Doing

Without measuring adoption, you do not know whether the policy is working. You are hoping.

Deloitte's 2026 data shows that companies with production-stage AI deployment pair broad access with governance visibility. Organizations still stuck in pilot mode tend to have either broad access without governance (shadow AI problem) or tight governance without broad access (adoption problem). Measurement connects the two.

Four categories of metrics matter:

Adoption: monthly active users on approved tools, repeat usage rates, which use cases are being used most. If adoption is low, the policy is too restrictive or training is missing.

Quality: error rates in AI-assisted output, rework frequency, customer complaints on externally facing content. If quality is dropping, review standards are not being applied.

Risk: policy violations, shadow AI incidents, sensitive data exposures. If these are rising, the hard lines are not clear or enforced.

Value: cycle-time reduction, throughput, hours saved on specific task categories. This is the number that justifies the program to leadership and funds the next round of investment.

AI ROI measurement is real and worth taking seriously. A policy that cannot demonstrate value will eventually get defunded or ignored. See the AI ROI measurement guide for a practical starting point.

The Copyable Policy Skeleton

Below is a working draft. Copy it, edit the brackets, and put a real name on the ownership line. It is designed to fit one page when formatted normally.

---

AI Usage Policy — [Company Name]

Effective Date: [Date] | Owner: [Name, Title] | Next Review: [Date + 90 days]

Purpose

AI tools are approved for everyday work when they help us move faster, improve quality, or reduce routine effort. This policy exists to make safe use easy, not to block experimentation.

What You May Use AI For

• Drafting first versions of emails, memos, plans, reports, FAQs, and analyses
• Summarizing internal documents that do not contain restricted data
• Brainstorming alternatives, checklists, and talking points
• Assisting with code, tests, and documentation, with human review before release
• Generating creative variations, templates, and structured outlines

Approved tools: [List specific approved tools here, e.g., Microsoft Copilot, ChatGPT Enterprise, Gemini for Workspace]

Hard Lines — Do Not Cross These

• Do not paste client confidential data, regulated data (HIPAA, PII, financial records, trade secrets) into any unapproved tool
• Do not send AI-generated content to customers, regulators, or the public without a human editor reviewing and approving it
• Do not allow AI to make final decisions in hiring, termination, compensation, legal, medical, or compliance matters without approved controls in place
• Do not ship facts, numbers, or citations from AI output without verifying them against a primary source

Required Behavior

• Verify AI-generated facts, numbers, and citations before use
• Disclose AI assistance where required by law, contract, or internal rule
• Escalate uncertain cases to your manager or to [Legal / Security / Data Governance contact]

Ownership

• Business teams own each use case and are responsible for output quality
• Security, legal, and IT own the tool approval process and guardrails
• Every AI use case needs a named business owner: [Name format / directory link]

Training

• All employees: complete [Module Name] before using approved AI tools on work tasks. Estimated time: 30 minutes.
• Managers: complete [Manager Review Module] covering output review standards for your function
• High-risk teams ([list teams]): complete additional data handling and documentation training

How We Measure This

• Adoption: monthly active users, approved tool usage, repeat usage by function
• Quality: error rates, rework, review exceptions, external complaint flags
• Risk: policy violations, shadow AI incidents, sensitive data exposures
• Value: cycle-time changes, throughput by function, hours redirected from routine tasks

Review Cadence

This policy will be reviewed every 90 days. Tools, law, and work practices are changing fast enough that an annual review is not sufficient. [Owner name] is responsible for initiating each review.

---

The skeleton above is an operating standard. Run it through your legal team before publishing, particularly if you operate in regulated industries. It is not a substitute for legal review of your specific context.

The One Thing to Do First

Before you write a single line of policy, audit your current state honestly. Ask your managers one question: Do your direct reports use AI tools today, and if so, which ones?

If they do not know, you already have a shadow AI problem. Policy alone does not fix that. Knowing the real starting point tells you whether your first job is to legalize what is already happening, redirect it, or build adoption from scratch. Those are three different problems with three different solutions.

Get the answer. Then write the policy.

Teams working through the broader organizational shift will find the AI Double Helix implementation guide and the how to build an AI-first marketing team guide useful for the structural changes that a policy alone cannot make. Policy creates permission. Culture creates capability. You need both.