AI usage policy for agencies (free template)

A policy isn't red tape — it's permission

Here's the reality at almost every agency right now: your team is already using AI, whether or not there's a policy. Someone is pasting a transcript into a chatbot to get a recap. Someone is drafting captions with it. Someone is summarising client feedback. The question was never "will we use AI" — that ship sailed. The only real question is whether you're using it safely and deliberately, or whether people are quietly pasting confidential client data into random tools and hoping for the best.

This is why an AI usage policy matters, and why the common objection ("we're too small for policies") gets it exactly backwards. A short, clear policy does two valuable things at once. It protects you and your clients from the genuine risks — data leakage, confidentiality breaches, embarrassing accuracy failures that reach a client. And, counterintuitively, it increases adoption, because the thing holding cautious people back from experimenting is uncertainty about what's allowed. When the rules are clear — these tools are approved, this never goes in, ask this person if unsure — people stop hovering nervously and start trying things. Vague or absent rules make people cautious; clear rules make them confident. A policy is permission with guardrails, not bureaucracy.

The key is to keep it genuinely short. A twelve-page legal document nobody reads protects no one and enables nothing. One page that everyone actually understands is worth far more. Here's a template you can adapt in about ten minutes.

The one-page AI usage policy template

[AGENCY] — AI USAGE POLICY    Last updated: [date]

1. WHY THIS EXISTS
   We encourage using AI to do better work, faster. This policy keeps us
   and our clients safe while we do it. It is permission with guardrails,
   not a list of bans.

2. APPROVED TOOLS
   - [Tool 1], [Tool 2]. Use the company account, not personal logins.
   - Want to use a new tool for client work? Ask [name] first.
   - Check whether a tool trains on your inputs; prefer settings/plans
     that don't, especially for anything client-related.

3. WHAT NEVER GOES INTO AI TOOLS
   - Client personal data, passwords, API keys, or credentials
   - Anything under NDA or marked confidential
   - Unreleased client material, unless that client has approved AI use
   - If you're unsure whether something is sensitive, treat it as sensitive.

4. CLIENT-FACING WORK
   - AI output is always a first draft, never a final deliverable.
     A human reviews and edits everything before it reaches a client.
   - Disclose AI use to clients where your contract or their policy requires it.
   - Match the client's own AI policy when they have one.

5. ACCURACY
   - Assume AI can be confidently wrong. Fact-check claims, names, numbers,
     dates and quotes before anything ships.
   - You own the output. "The AI said so" is never an excuse to a client.

6. QUESTIONS
   - Unsure about anything? Ask [name]. You will never be in trouble for asking.

How to adapt it to your agency

The template is a starting point; spend ten minutes making it yours. Fill in the approved tools you actually pay for and trust, and name a real person as the point of contact — a policy with no named owner gets ignored. If you work in a regulated space or with enterprise clients, tighten section 4: some clients contractually prohibit AI use on their work, and you need your team to know which accounts those are. If most of your work is internal or low-sensitivity, you can keep it loose and lean into the "experiment freely" message. The goal is a document that fits how your agency actually operates, not a generic one that sits in a drawer.

One addition many agencies find useful: a short, evolving list of approved use cases ("drafting show notes," "recapping calls," "first-pass social copy") alongside the rules. It turns the policy from purely defensive ("don't do this") into something that actively points people toward the good uses, which helps adoption.

Make it stick

A policy in a forgotten doc does nothing. The mistake is treating it as a compliance artifact you write once and file away. Treat it instead as part of your rollout. Introduce the policy in the same live session where you teach the first AI workflow, so safety and capability arrive together and the policy is associated with "here's how to use this well," not "here's a list of rules." Then link it somewhere people actually work — a team portal, a pinned channel — so it's findable at the moment someone wonders "wait, can I put this in?" And revisit it as tools change; an AI policy written today will need an update in six months, and that's fine. (For the full rollout approach, see getting your team to use AI and rolling out new tools.)

The real risks a policy protects against

It's worth being concrete about why this matters, because "we should have a policy" is abstract until you've seen the failure modes. The first and most common risk is data leakage: a well-meaning team member pastes a client's confidential strategy doc, customer list, or unreleased campaign into a consumer AI tool whose terms allow it to train on inputs. That data is now, in a meaningful sense, out of your control — and if your contract with that client included confidentiality or data-handling commitments, you may have just breached it without anyone intending to. For an agency, whose entire business runs on client trust, a single incident like this can cost a relationship or worse.

The second risk is accuracy failure reaching a client. AI is confidently wrong on a regular basis — it invents statistics, misattributes quotes, garbles names and dates. Without a hard rule that a human reviews everything before it ships, it's only a matter of time before a hallucinated "fact" lands in a client deliverable and damages your credibility. The policy's accuracy clause exists to make "a human checked this" non-negotiable.

The third risk is subtler: inconsistent or non-compliant use with clients who have their own rules. Enterprise clients increasingly have AI policies of their own, and some prohibit AI use on their work or require disclosure. If your team doesn't know which clients those are, you can violate a client's policy while doing perfectly good work — a completely avoidable own goal. A short policy that names these accounts and the disclosure rule prevents it. None of these risks require bad actors; they happen through ordinary, well-intentioned work, which is exactly why a simple shared rule set is so valuable.

Rolling the policy out (not just writing it)

Writing the policy is the easy part; getting the team to internalise it is the part that actually protects you. Treat the rollout the way you'd treat any tool rollout. Introduce it live, in context, alongside the first AI workflow you teach — not as a standalone "please read this policy" email that gets skimmed and forgotten. Walk through the three or four rules that matter most (what never goes in, human review, disclosure) using real examples from your work, so the rules are concrete rather than abstract. Make it clear that the policy is permission, not prohibition: the headline is "use AI freely, here are the few guardrails," not "here is a list of things you'll get in trouble for." And give people an easy, judgement-free way to ask when they're unsure — most near-misses are prevented by someone feeling comfortable enough to ask "can I put this in?" before they do. A policy the team understands and feels ownership of protects you; a policy filed in a drawer protects no one.

Give the policy a real home

A policy only helps if people can find it, and "it's in a Google Doc somewhere" is where good policies go to be forgotten. The agencies that make this stick give their policies, SOPs and tools a single, findable home that the team actually uses day to day.

That's one of the things Forge builds: internal team portals shaped to your agency, where your AI policy, your prompt library, your SOPs and your tools live in one branded place — not scattered across Slack threads and shared drives. When the rules and the tools live together where people work, both get used. See how it works →

Keep it one page — resist the urge to over-engineer

A final word of caution, because well-meaning founders often go the wrong direction here: the moment you decide to "do AI governance properly," there's a strong pull toward a long, lawyerly document that covers every conceivable scenario. Resist it. A twelve-page policy full of defined terms and edge cases has one reliable effect — nobody reads it, so it changes no behaviour and protects no one. Length is not rigour; it's usually the opposite, because the rules that actually matter get buried.

The whole value of an agency AI policy comes from the team genuinely knowing and following a small number of rules: what never goes in, that a human reviews everything, and who to ask when unsure. Everything else is detail you can add as specific situations arise. If your policy can't be read and understood in two minutes, it's too long to do its job. Aim for clarity a new hire could absorb on day one, keep it to a single page, and treat brevity as a feature rather than a compromise. A short policy people follow beats a comprehensive one they ignore, every time.