AI use policy template: what to include before you publish

The problem with most AI use policies

If your organization has an AI use policy at all, there's a reasonable chance it started as a one-page memo someone drafted after a vendor demo or a news story about ChatGPT data leaks. That's not a criticism — it's how most mid-market AI governance efforts begin. The problem is that a memo-level policy doesn't answer the questions that actually come up: Which tools are approved, and on what conditions? Who decides when an edge case shows up? What does an employee do when something goes wrong?

Without answers to those questions, the policy becomes shelfware. Employees route around it — not because they're careless, but because the policy doesn't help them do their jobs. Meanwhile, IT is left managing shadow AI tool sprawl with no formal process to trace what's running, who approved it, or what data it touched. If you've ever discovered that a team has been using an unapproved AI tool for months without anyone flagging it, you already know what that gap costs.

The goal of this page is to orient you on what a credible AI use policy actually needs to cover, give you a structural checklist to pressure-test your draft, and point you to deeper resources for the components that deserve more than a paragraph.

What a good enough AI use policy looks like

You don't need a 40-page policy framework. For a company in the 50–250 employee range, a defensible AI use policy is typically a single structured document — somewhere between 1,500 and 4,000 words depending on your industry — that covers five core areas.

Scope. The policy needs to define what it governs. "AI tools" is not a definition. You need to specify whether the policy covers third-party SaaS tools with embedded AI (think Notion AI, Grammarly, Salesforce Einstein), standalone large language model interfaces (ChatGPT, Claude, Gemini), internally developed models, or all of the above. Scope gaps are how unapproved AI tools end up outside the policy by technicality.

Approved tools and the intake process. The policy should reference your AI tool register — or at minimum, describe the process for getting a tool approved before use. This is the connection point between your written policy and your operational controls. A policy that says "only approved tools may be used" without specifying how approval works is an invitation to creative interpretation. For a lightweight intake process that works without a formal GRC platform, see how a lightweight shadow AI intake process works in practice.

Data handling rules by classification. Not all AI use carries the same risk. Employees drafting marketing copy in an LLM interface is a different exposure than an analyst uploading customer data to a summarization tool. Your policy needs to establish which data classifications are permitted in which tool categories — and which combinations are off-limits regardless of tool approval status.

Roles and accountability. Someone owns AI governance. In most SMBs, that's the IT manager, a security lead, or a fractional CISO — but the policy needs to name the function, not just imply it. The same applies to department-level AI leads if you have them. Accountability without named owners is accountability that evaporates under pressure. If you're working through how to assign ownership without a dedicated GRC team, the NIST AI RMF GOVERN function breakdown covers this in practical terms.

Incident reporting. Employees need to know what constitutes a reportable AI incident and what to do when one occurs. A data leak through an unapproved tool, an AI-generated output that caused a customer-facing error, an unexpected model behavior in a production workflow — these all need a defined path. If your policy doesn't specify the reporting channel and a rough response timeline, most employees will default to doing nothing. The case for logging AI incidents before you have a full risk scoring process explains why this is the right place to start even if the rest of your governance program isn't built yet.

A practical method for building your AI use policy

This is the sequence that works for most mid-market IT teams — not a theoretical framework, just the order of operations that avoids common rework.

1. Inventory what's actually in use before you write scope. You cannot write a credible scope section if you don't know which tools are already running. A discovery exercise — even an informal one — surfaces the shadow AI exposure that your policy will need to address. The 43 shadow AI tools found in 48 hours case study shows what that discovery looks like in a real environment and what typically comes out of it.

1. Draft the approved tool register in parallel with the policy. The policy references the register; the register operationalizes the policy. Building them separately creates gaps. Your register doesn't need to be elaborate — a structured spreadsheet with tool name, owner, data classification permissions, approval status, and review date is enough to start.

1. Map your data classifications to tool tiers. Before you finalize data handling rules, write out the actual classification levels your organization uses (or should use), then explicitly assign each classification to an allowed or prohibited category per tool tier. Vague language like "avoid sensitive data" doesn't survive a real incident review.

1. Name your owners before the policy goes out. Don't publish a policy that refers to "the AI governance function" if that function isn't assigned to a real person. Get the assignment in writing — even an email confirmation — before the policy is live.

1. Add the incident reporting path last, but don't skip it. Once you know what tools are approved and what data handling rules apply, you can define what a reportable incident looks like in your specific environment. Generic incident definitions are better than nothing, but specific ones actually get used.

1. Set a review cadence and put it in the document. AI tooling changes faster than annual review cycles can track. A six-month review trigger — or a trigger tied to any new tool category being added to the register — keeps the policy from going stale.

A compact checklist outline for each of the five policy components is below. These are structural prompts, not the full content — the linked Insights posts above go deeper on each area.

Policy checklist outline

• Scope: tool categories covered, exclusions, effective date
• Approved tools: register reference or location, intake process summary, provisional use rules
• Data handling: classification levels defined, permitted/prohibited tool combinations per level, third-party data processing disclosures
• Roles: named AI governance owner, department-level contacts if applicable, escalation path
• Incident reporting: definition of a reportable incident, reporting channel, initial response timeline, post-incident review process

If you're also navigating EU AI Act obligations — either because your company operates in Europe or because you work with EU-based customers — your policy will need to address a few additional layers around high-risk AI system classification and transparency requirements. The global AI governance landscape and why waiting isn't a strategy gives useful context on where the regulatory environment is heading and what that means for policy scope decisions today.

Once your policy is drafted, the next question is whether your governance infrastructure can actually support it — tracking approved tools, logging incidents, and producing evidence if you're ever asked to demonstrate compliance. InfoDefenders' AI Governance Manager is built for exactly that handoff: it gives mid-market IT teams a structured place to maintain the policy controls, tool register, and incident log that make a written policy enforceable. See AI governance pricing and tiers to find the tier that fits your current program maturity.

If you're still in early stages and want a 30-day plan to get audit-ready before you finalize your policy, the AI governance audit prep guide is the right next read.