An AI policy for agencies that people actually follow.

Why agencies need this more than most companies.

When a product company leaks its own roadmap into a chatbot, that's an internal incident. When an agency pastes a client's unreleased campaign or customer list into a consumer AI account, that's a confidentiality breach of someone else's data. Agencies sit on a pile of third-party secrets: pitch decks, performance data, source code, contracts. That's the asset an AI policy protects.

The second reason: your team is already using AI, with or without a policy. Every agency we've worked with that 'hadn't rolled out AI yet' had people quietly using personal accounts on client work. A written policy replaces invisible, ungoverned usage with visible, governed usage, which is why the policy and getting people to actually use AI are the same project: permission in writing raises usage, and rules in writing make it safe.

What an AI policy for agencies must cover.

Four sections. If your draft has more, you're probably restating your employment contract or security policy.

Client data rules: the part that actually matters.

Write these rules around data categories, not tool names. Three tiers cover almost every agency: public or non-sensitive data (fine in any approved tool), internal agency data (approved tools on business tiers), and confidential client data (business tiers only, and only when the client contract doesn't forbid third-party processing).

The tier of the account matters as much as the tool, because vendors treat consumer and business traffic differently on model training. On personal ChatGPT plans (Free, Plus, and Pro), conversations are used to train OpenAI's models by default unless the user opts out in settings; ChatGPT Business, Enterprise, and API traffic is not used for training by default. Anthropic's consumer Claude plans (Free, Pro, and Max) ask each user to choose whether chats can be used for training, with five-year retention for those who allow it; Claude for Work and the API are excluded under the commercial terms. These defaults have changed before and will change again, which is why your policy should say 'business tiers for client data' rather than naming versions and toggles.

Disclosure: what you tell clients, and when.

Our position: disclose the practice, not every keystroke. A line in your MSA or proposal saying you use AI tools in production under human review is honest and sufficient. Announcing 'this deliverable was made with AI' on every asset is theater; hiding AI use when a client asks directly is how you lose the account. Decide your one-sentence answer in advance and put it in the policy so an account lead isn't improvising it on a call.

Two cases deserve explicit rules. First, client-facing AI: if you deploy a chatbot or anything else that talks to your client's customers, the customer should know it's AI. In the EU this is law, not preference: the AI Act's Article 50 transparency obligations apply from August 2, 2026, requiring AI systems that interact with people to disclose it and AI-generated synthetic media to be marked as such. Second, contractual bans: some client contracts already prohibit third-party data processing broadly enough to cover AI tools. The policy should name whoever checks new contracts for this, because the person pasting the brief into a chatbot won't be the person who read the MSA.

Tool approval without a bottleneck.

The instinct is a whitelist guarded by a committee. The result is a three-week wait and people using unapproved tools in the meantime, the outcome the whitelist existed to prevent. Run it as a fast lane instead:

• Keep a short approved list with named tiers. 'Claude on our Team plan, ChatGPT Business, our transcription tool' beats a spreadsheet of forty apps. Fewer, better-understood tools also make training the team tractable.
• Give requests a named owner and a deadline. One person (ops lead, technical founder) answers within a week using three checks: what tier is the account, does the vendor train on inputs, where is data retained.
• Default-deny only for client data. Someone trying an unapproved tool on public or dummy data is doing research; the same tool with client data is a policy breach. The distinction keeps experimentation alive.
• Log what people ask for. A cluster of requests for the same category of tool is a roadmap signal, not noise to be managed down.

The template: ten principles to adapt.

Rewrite each of these in your own words, add your owners and tool list, and you have a one-page policy:

• 1. We use AI openly. Approved tools on company accounts are encouraged on real work. Personal accounts are never used for client work.
• 2. Data rules follow the data, not the tool. Public data goes anywhere approved; internal data needs business tiers; client data needs business tiers plus a compatible contract; regulated data and credentials go nowhere without review.
• 3. We check the contract before the tool. A named person reviews client agreements for processing restrictions before AI touches that client's work.
• 4. We disclose the practice. Our contracts state that we use AI under human review. When a client asks, we answer with the agreed sentence, not an improvisation.
• 5. Client-facing AI announces itself. Anything we build that talks to a client's customers identifies itself as AI.
• 6. A human owns everything that ships. AI output reaching a client or the public has a named reviewer, and the reviewer owns the error if one gets through.
• 7. New tools go through the fast lane. One owner, one week, three checks. Until approved, no client data.
• 8. Incidents get reported, not punished. Pasted the wrong thing into the wrong tool? Say so the same day. Silence is the only unfixable version.
• 9. The policy lives in onboarding and gets reviewed quarterly. Vendor terms and regulations move; a policy last touched a year ago is documentation of what you used to believe.
• 10. Someone owns this document. A name, not a department. Unowned policies rot.

Making it stick.

A policy becomes real through the same mechanics as any process change: it's in onboarding, leadership visibly follows it, and it lives where work happens rather than in a drive folder. Pair the rules with capability: a team that has been properly trained on AI breaks policy far less often than one that got a PDF and a warning, because most violations are improvisation by people who were never shown the sanctioned path.

The quarterly review is the part agencies skip, and it's the part that keeps the policy true. Vendor training defaults shift, AI Act obligations arrive in stages, and your own tool list drifts. Twenty minutes a quarter, owned by a named person, keeps the document matching reality.

Write it yourself, or bring us in.

Everything above is doable internally in an afternoon plus a quarterly habit: adapt the ten principles, name the owners, publish the tool list, put it in onboarding. Where agencies stall is where every process stalls: the quarterly review dies after the second quarter, vendor terms drift, and two years later the policy describes tools nobody uses anymore.

We handle this as part of managed AI operations: the policy, the approved-tool list, and the reviews are maintained alongside the workflows they govern, so governance moves when the stack moves. Either way the deliverable is the same one page: your team knows what's allowed, your clients know what to expect, and nobody is improvising confidentiality decisions at a paste prompt.

Frequently asked questions.

Keep reading.