How to Write a Company AI Usage Policy (Free Template + 2026 Checklist)

An AI usage policy is a binding document that tells everyone working for your company which AI tools they may use, what data they may put into those tools, how to check the output before relying on it, and who answers for the result. Writing one is a two-week job if you make five decisions in the right order: posture, data, tools, oversight, disclosure.

Most guides hand you a template. The template is the easy part. The hard part is the judgment that makes a template fit your company, because a policy describing a hypothetical organisation gets filed and forgotten. What follows is the decision sequence, the clause language attached to each decision, and the controls that turn those clauses into something more than a wish.

What an AI usage policy actually is

A usable company AI policy answers four questions in language an ordinary employee can act on without asking IT:

•     Which AI tools may I use for work?

•     What data am I allowed to put into them?

•     How much do I have to check the output before I rely on it?

•     Who is accountable when an AI-assisted decision goes wrong?

Everything else in the document supports those four answers. If a section does not help someone answer one of them faster, it belongs in a standard or a guideline, not the policy.

Policy, standard, guideline, governance program

These four terms get used interchangeably and cause real confusion during drafting. Keep them separate. Principles state what you value. The AI usage policy sets binding rules and consequences. Standards specify how a rule is met for a particular system. Guidelines are advisory good practice. The AI governance program is the whole management system that produces and maintains all of it.

An AI acceptable use policy is usually the same artefact under a different label. Pick one name and use it consistently across your intranet, your onboarding pack and your customer security questionnaires.

Who the policy has to bind

Scope is where most drafts leak. Cover employees, contractors, agencies, consultants and vendors acting on your behalf. Cover company-managed devices and personal devices used for company work. The commonly missed case is the vendor who quietly uses generative AI to produce your deliverables, sometimes training a public model on your campaign data or your product roadmap in the process. Agreements signed before your policy existed should be audited for that conflict.

The numbers that should shape your policy

IBM's 2025 Cost of a Data Breach Report, conducted by the Ponemon Institute across 600 breached organisations, was the first edition to study AI governance directly. The results explain why auditors and insurers now ask for this document by name.

Shadow AI, meaning tools staff adopt without approval, added roughly USD 670,000 to the average breach cost, and shadow AI incidents exposed personally identifiable information in 65% of cases against a 53% global average. Those breaches also cost more against a backdrop of falling global breach costs, which makes the gap more visible rather than less.

Two incidents make the abstraction concrete. In 2023, engineers in Samsung's semiconductor division pasted proprietary source code and internal meeting content into ChatGPT within weeks of the division sanctioning the tool, and Samsung responded by banning generative AI on company devices. In 2024, the British Columbia Civil Resolution Tribunal ruled in Moffatt v. Air Canada that the airline was responsible for what its website chatbot told a customer, rejecting the argument that the bot was a separate entity and that the correct policy published elsewhere on the site was a sufficient defence.

The gap that actually causes failures

Okta's AI Agents at Work 2026 study, run with Apprize360 across roughly 300 technology executives and 500 knowledge workers, found executives confident their AI usage policies were clear while more than half of employees described those same policies as unclear, hard to find or non-existent. Around 52% of knowledge workers admitted using unapproved AI tools. Your policy is far more likely to fail on comprehension than on defiance.

Decision 1: pick your posture before you write a word

Posture is the single choice that determines the shape of every clause that follows. There are three, and one of them is right for you.

A blanket ban looks decisive and reads well in a board pack. In practice it converts governable usage into ungovernable usage, because people who need the tool find an unmonitored path to it. Choose prohibition only where the consequence of a single leak genuinely outweighs total loss of visibility. Otherwise, risk-tiered is the working default.

Three inputs to gather before drafting

Name one owner, then a small cross-functional group

A policy written by IT alone will govern the parts of the problem IT can see and miss the rest. Pull in security, legal, HR and at least one operating team that uses AI daily. Then name a single accountable owner. Committees produce documents nobody maintains.

Inventory what is already in use

You cannot govern tools you cannot name. Work through single sign-on and OAuth grant logs, expense reports and browser or network telemetry. Then run the step almost everyone skips: an amnesty survey.

Amnesty survey wording you can send today

"We are writing the company AI policy and we want it to reflect how people actually work. Tell us every AI tool you have used for work in the last 90 days, including personal accounts. Nothing you report here will result in disciplinary action. Anything we discover after the policy is published will be handled under the policy."

Amnesty is the cheapest discovery mechanism available, and the honesty it buys is worth more than the enforcement you give up.

Map the rules that apply to you

This is where competing guides go stale fastest. As of September 2026, the position that matters for a typical employer:

Sector rules sit on top: HIPAA, GLBA, FINRA, PCI DSS and export control regimes each restrict what may enter a prompt. If the jurisdictional map feels unmanageable, use the shortcut. Adopt the NIST AI Risk Management Framework as your control baseline. Its GOVERN function is designed to anchor exactly this kind of policy, it maps cleanly onto ISO/IEC 42001 if you later need certification, and substantial compliance with it earns an explicit enforcement safe harbour in Texas.

Decision 2: classify data before you classify tools

Almost every template on the internet opens with an approved tools list. That is backwards, and it is why those policies are obsolete within a quarter. Tool names change constantly. Data classes do not.

Build the spine of your policy on data tiers, then attach tools to tiers. Map onto your existing classification scheme rather than inventing a parallel one.

Then publish a named prohibited-inputs list. "Do not share sensitive data" is unenforceable because two people will read it differently. "Do not paste credentials, API keys, customer personal data, protected health information, cardholder data, unreleased financial results, production source code or anything covered by a customer contract restricting AI processing" is testable.

Decision 3: tool tiers and the exception path

Sort tools into three tiers rather than a flat approved list. Tier one is approved for all data classes, which requires an enterprise tenant, training opt-out, single sign-on, audit logs and a data processing agreement. Tier two is approved for public and internal data only. Tier three is prohibited.

Publish the evaluation criteria alongside the list so people can reason about tools you have never assessed: does the vendor train on inputs, how long is data retained, who are the sub-processors, and where does the data sit? Note that the same product often appears in two tiers, because a consumer account and an enterprise tenant of the same brand carry different terms.

The exception path is the clause that prevents shadow AI

This is the most consistently omitted section across competing templates and arguably the highest-impact one. If the answer to "I need a tool that is not on the list" is silence or a six-week wait, you have designed shadow AI into your own policy.

•     Publish a request route and a target decision time. Five business days is realistic.

•     Capture use case, data class, requested permissions, retention terms, a named owner and an expiry date.

•     Keep a standing exception register that expires entries automatically.

•     Review expired exceptions quarterly and either promote the tool to a tier or retire it.

Decision 4: human oversight and accountability

State the accountability principle in one sentence and put it near the front: the person who ships the work owns it, regardless of how much of it an AI produced. Then set review thresholds that scale with consequence, so the rule is applicable without a judgement call every time.

•     Internal draft or scratch work: spot-check for obvious errors.

•     External content and marketing: full human review before publication.

•     Customer-facing communication: named reviewer, review recorded.

•     Legal, financial, medical or safety-relevant output: documented review by a qualified person.

Verification duties deserve their own short clause, because generic instructions to "check the output" do not tell anyone what to look for. Name the failure modes: fabricated citations and case law, invented statistics, silent factual drift in long documents, and generated code carrying licence or security problems.

Then draw the hard line. Hiring, promotion, discipline, termination, compensation, credit decisions and safety determinations must never be made by an AI system without a human decision-maker. That single clause does most of your work under Illinois HB 3773, NYC Local Law 144 and the incoming California ADMT rules at once.

Decision 5: disclosure, handled by context

Blanket disclosure rules get ignored because nobody wants to append a notice to every internal Slack message. Segment it instead. Internal work drafted with AI needs no disclosure. External reports, published content and client deliverables should carry an acknowledgement. Regulated contexts and contracts that require disclosure override everything else, and EU AI Act transparency obligations for AI-generated content apply from August 2026.

Add one line on copyright while you are here. Output generated without meaningful human authorship attracts limited protection in the United States, which matters for anything you intend to own outright.

Governing AI agents, not only chatbots

Here is the widest gap in published policies. Almost every template governs a person pasting text into a chat window. Few govern software that takes actions on its own.

The distinction matters because the failure mode changes. A chatbot produces output a human then uses. An agent books the meeting, merges the pull request or issues the refund before anyone reviews it. Published research has noted that frontier safety policies, the NIST AI RMF, ISO/IEC 42001 and the EU AI Act contain no references to agentic systems, while Gartner projects that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from under 5% in 2025.

Okta's 2026 research found only about a third of organisations securing AI agents with the same rigour applied to human staff. Write the clause set anyway, and let oversight rise as autonomy and consequence rise.

Four clauses cover most of the risk. Register every agent in an inventory with a named human owner. Give each agent its own machine identity rather than a shared human credential, scoped to least privilege. Set hard limits on spend, rate and reachable systems. Require a logged human approval gate for anything irreversible.

Add two clauses people forget: persistent agent memory is an attack surface, so untrusted content entering an agent's context is a prompt injection risk that needs naming; and when an agent delegates to another agent, accountability stays with the human who deployed the first one.

Make every clause enforceable

A policy is the decision layer. Decisions without controls are aspirations, which is why the clauses about approved accounts and sensitive data are the ones that most often fail in practice. Map each clause to the thing that actually enforces it, including at zero budget.

Monitoring belongs in the same section, disclosed rather than hidden. A policy people know is monitored is a policy people follow. Disclosure is also frequently a legal requirement, and in Europe or a unionised workplace, monitoring clauses may need works council consultation or union notice before publication. Building that into the approval timeline avoids a late block.

Set consequences proportionate to your existing conduct policy, and separate honest mistakes reported promptly from deliberate circumvention. A policy that punishes disclosure guarantees you stop hearing about incidents.

The document itself

Assembled, a complete AI usage policy runs to eleven sections and rarely needs more than 1,500 words: purpose and scope, definitions, policy posture, data classification rules, approved tool tiers, the exception process, prohibited uses, human oversight and accountability, disclosure requirements, agent-specific provisions, and monitoring with enforcement and incident reporting. Add version, owner, effective date and review date to the header.

Two artefacts sit alongside it and matter more than most drafters expect: a one-page employee summary, which is the document people will actually read, and an exception request form.

The 60-second test

Every clause should pass this: an employee facing a real question should be able to find the policy, locate the relevant rule and act on it inside a minute. If a rule needs interpretation, it belongs in a standard. If it needs a lawyer, it belongs in an annex. This is the mechanism that closes the executive and employee comprehension gap described earlier.

Rollout, training and the records that prove it

How you announce the policy determines whether people adopt it or route around it. Brief managers before the company-wide announcement, frame the policy as enablement with guardrails rather than a crackdown, and lead with the approved tools people gain rather than the prohibitions.

Findability is a policy requirement, not a nice-to-have. More than half of employees in Okta's research could not confidently locate their own company's AI rules. Link the policy from onboarding, from the intranet homepage and from inside the tools people use.

Training then does double duty. It changes behaviour, and under EU AI Act Article 4 it is the compliance artefact. Since the Digital Omnibus reframed the duty as an obligation of effort, the question a regulator asks is what measures you took. Keep records of training content, attendance, dates and the reasoning behind your methodology. Differentiate by role, because an engineer using coding agents and a recruiter screening candidates face different risks.

Proving the policy works

Auditors, cyber insurers and enterprise customers increasingly ask for evidence rather than a document. Track a small set of numbers from launch:

•     Count of distinct unapproved AI tools detected, trending down quarter over quarter.

•     Exception requests received and median time to decision.

•     Policy acknowledgement and training completion rates by department.

•     Self-reported AI incidents, where a rise in the first two quarters is a healthy signal rather than a bad one.

Keep those alongside the policy version history, the tool inventory and the exception register. That package answers a customer security questionnaire in an afternoon instead of a fortnight.

Set the review cadence quarterly. Regulatory dates shift, Colorado repealed and replaced its own AI act inside two years, and agent capabilities change faster than either. Define off-cycle triggers too: a new tool tier, entry into a new jurisdiction, a material incident or a law change.

Six ways AI policies fail

If you already have a policy and it is not working, the cause is usually on this list.

•     It leads with a tool list instead of data rules: the list is stale within a quarter and the policy loses authority with it.

•     There is no exception path: every unmet need becomes an unmonitored personal account.

•     IT wrote it alone: it governs what IT can see and misses procurement, contracts and hiring.

•     Clauses have no matching control: nothing on any device checks, so the rule is decoration.

•     It fails the 60-second test: people cannot find it, or cannot parse it when they do.

•     Nobody owns the review: it still describes repealed laws and tools nobody uses.

Work through these in order and the pattern becomes obvious: the policies that survive contact with a real workforce are the ones written around decisions that stay stable while the tools underneath them keep changing. Data classes, oversight thresholds and accountability lines will still be correct in three years. The list of approved chatbots will not last three months. Build on the first set, and the second becomes an appendix you can update in ten minutes instead of a rewrite you keep postponing.