Most organisations now have employees using AI at work; far fewer have written down what is allowed. The gap is not harmless — it produces the worst of both worlds, where cautious staff avoid legitimate productivity gains while confident staff paste confidential material into unvetted tools. An AI usage policy closes that gap, and writing one is less daunting than it sounds. This guide walks through what a good policy contains, section by section, and the decisions you need to make before drafting.
Decide what the policy is for before writing it
A policy written purely to forbid things will be ignored; a policy written purely to signal innovation will not protect anyone. The useful framing is an enablement document with guardrails: its job is to tell a well-intentioned employee, quickly, what they can do freely, what needs approval, and what is never acceptable — so that the default answer to "can I use AI for this?" becomes findable in two minutes rather than escalated or guessed.
Before drafting, three decisions set the policy's shape. First, your risk posture: a healthcare provider, a law firm, and a design studio will legitimately land in different places. Second, your tool stance: whether you approve specific tools, approve categories with conditions, or allow anything meeting stated criteria. Third, ownership: which named role answers questions, approves exceptions, and updates the policy as tools change. A policy without an owner is stale within months.
The core sections every policy needs
Scope and definitions. Say plainly what counts as AI use under the policy — generative assistants, AI features embedded inside existing software, code assistants, transcription and meeting-summary tools. Embedded features are the commonly missed case: staff often do not register that a meeting recorder or an email drafting feature is an AI tool processing company data.
Approved tools. List the tools the organisation has reviewed and sanctioned, ideally with the account type that is approved — business tiers with contractual data handling, not personal free accounts. State how to request a new tool's review rather than just banning the unlisted, because an easy request path is what keeps shadow usage low.
Data rules. This is the heart of the policy. Define what may never be entered into AI tools — customer personal data, credentials and keys, unreleased financials, material under confidentiality agreements, anything covered by specific regulation in your sector — and what is fine, such as public information and generic drafting. Concrete examples beat abstract classifications: staff follow "never paste a client contract" more reliably than "avoid disclosing category-two information assets".
Review and accountability. State the human-review rule: who must check AI-assisted output before it reaches customers, the public, regulators, or decisions that affect people. The clean principle is that accountability does not transfer — the person who ships the work owns it, whether or not AI helped draft it. This single sentence prevents the "the AI got it wrong" defence from ever taking root.
High-stakes uses. Some uses deserve stricter treatment or prohibition regardless of tool: decisions about hiring, performance, or credit affecting individuals; legal, medical, or financial advice going to clients; anything where regulation requires explainability. Name these explicitly, and require named human decision-makers where AI contributes analysis.
Disclosure. Decide when AI assistance must be disclosed — internally (often, so reviewers know what they are checking), and externally (as required by clients, platforms, sector rules, or plain honesty, such as never presenting AI output as human testimony).
Common mistakes that sink AI policies
The blanket ban is the most self-defeating choice. Staff facing deadline pressure will use tools anyway, on personal devices and accounts where the organisation has zero visibility, and the ban converts a manageable risk into an invisible one. If leadership genuinely believes some uses are unacceptable, the credible move is to name those uses while enabling the rest.
The mirror-image mistake is the vague blessing — "we encourage responsible AI use" — which delegates every hard question to each employee's private judgement and provides no defence when judgement varies. Policies earn their keep precisely at the specific edges: this tool yes, that data never, this output reviewed.
Two quieter mistakes: writing the policy once and never revisiting it, though the tool landscape shifts continuously; and writing it without consulting the people who already use AI daily, who know where the real workflows and real temptations are. A short consultation round surfaces the cases the policy must answer and buys the goodwill that makes it followed rather than resented.
Rolling it out so it actually changes behaviour
A policy PDF in a shared drive changes nothing. Three moves make it real. Pair the policy with training — not a compliance slideshow, but practical instruction in using the approved tools well, because staff who are competent with sanctioned tools have little reason to wander. Skills-based training with graded practice, of the kind Square 1 AI provides through role-specific tracks where an AI tutor assesses learners' actual prompts, doubles as both capability building and policy reinforcement: people follow rules more readily when they can see the approved path works.
Second, make the safe path the easy path: approved tools available on request within days, the never-paste list pinned where work happens, a named human who answers grey-area questions quickly. Most policy violations in practice are friction problems, not intent problems.
Third, review on a schedule. A light quarterly pass — new tools to evaluate, incidents to learn from, rules that proved unworkable — keeps the policy a living instrument. Date each version and tell staff what changed.
Frequently asked questions
How long should an AI usage policy be?
Short enough to be read: a few pages for most organisations, with the never-paste list and approved tools on the first page. Length correlates with shelf-life, not safety. Detailed procedures for specific departments belong in appendices or separate playbooks, not in the core policy every employee must absorb.
Should the policy name specific AI tools?
Yes, in an appendix or linked register rather than the policy body, so the list can be updated without re-approving the whole document. Tool-by-tool approval with account-type detail gives staff certainty; criteria-only policies push evaluation burden onto people without the context to do it.
Who should own the AI policy?
A named role with authority to answer questions and grant exceptions quickly — often within IT, legal, or operations depending on the organisation's shape, ideally with input from each. What matters more than the department is responsiveness: a policy owner who answers grey-area questions in hours keeps shadow usage low; one who takes weeks recreates the problem the policy exists to solve.
Where to go from here
A policy works best alongside genuine staff capability. Gauge where your team currently stands with the free 3-minute skill check, and build practical, role-relevant skill through AI for your work — role tracks.