← BLOG/CASE STUDIES

Case Study: Rolling Out an AI Usage Policy in One Week

A step-by-step look at how a growing agency drafted, piloted, and rolled out an AI usage policy in five days instead of letting it sit as a someday-project.

CASE STUDIES
Case Study: Rolling Out an AI Usage Policy in One Week
On this page (6 sections)
  1. The goal: a working policy in a week, not a committee project
  2. Day 1: Name an owner, pick a pilot team, start from a template
  3. Day 2: Find out what tools people are actually using
  4. Day 3: Write the data rule in plain language
  5. Days 4-5: Test with the pilot team, then roll out
  6. What this pilot approach gets you that a six-week draft doesn't

The goal: a working policy in a week, not a committee project

Most companies don't have an AI usage policy because writing one sounds like a legal project — weeks of drafts, a lawyer on retainer, a document nobody reads. That's backwards. The real risk isn't a missing clause. It's that your team is already pasting customer data into whatever chatbot is free this week, with no one accountable for it.

The following is illustrative — we're using a hypothetical company to show the steps, not reporting on a real client. Picture a 40-person marketing agency where half the team uses an AI copilot for drafting client emails, a few people have personal ChatGPT accounts open all day, and nobody has ever asked what happens to the data they paste in. That's the starting point for this case study.

The target: a usable, adopted policy live within five working days, piloted with one team before it goes company-wide.

3 weeks
5 days
Time from "we should do this" to live policy
12 tools in use
4 approved
AI tools found once someone actually asked
Illustrative example — not client data

Day 1: Name an owner, pick a pilot team, start from a template

Don't try to write a policy for the whole company on day one. Pick one owner — an ops lead, not a committee — and one team to pilot it with. In the agency example, that's the account management team: heavy AI users, client-facing, and small enough (6 people) to get fast feedback.

The owner's job this week is narrow: produce a draft, test it on one team, and fix what breaks before it goes wider. This mirrors the same logic behind the AI readiness check — fix what's actually broken in your process before you buy or mandate anything new.

Don't draft from scratch, either. Pull a ready-made AI usage policy template and adapt it — company name, approved tools, data rules, owner, review cadence. The sections that matter most for a first pass:

  • Scope (which tools count — copilots, chatbots, embedded AI features)
  • Approved tools list
  • Data handling rules (what can and can't go into a prompt box)
  • Human oversight expectations (AI drafts, a person decides)

Skip the sections that don't apply yet — regulated-industry clauses, for instance, if you're not in a regulated industry. You can add them later. The point of day one is a complete-enough draft, not a perfect one.

Day 2: Find out what tools people are actually using

Before you write an "approved tools" list, find out what's really in use. Send one short survey to the pilot team: "What AI tools do you use for work, including personal accounts?" You will find more than you expect — this is the step that usually turns up shadow AI tools nobody signed off on.

In the agency example, the survey turned up four sanctioned tools (a writing copilot, a transcription tool, two chatbots) and eight more that individuals had added on their own, including a free image generator and a personal ChatGPT account used for client research.

  1. 1Team uses AI tools day to day
  2. !Nobody has asked which ones, or what goes into them
  3. 3Owner sends a 5-minute tool survey
  4. 4Owner builds approved-tools list from real usage, not guesses

Decide, tool by tool: approve it as-is, approve it with a data restriction, or block it pending review. This list is the single most useful artifact to come out of the week — it turns "don't use AI irresponsibly" into a concrete yes/no people can actually follow.

Day 3: Write the data rule in plain language

This is the section people actually need, and the one most policies get too vague to be useful. Don't write "use good judgment with sensitive data." Write the actual rule: what can't go into a non-approved tool (customer personal data, passwords, unreleased financials, anything under an NDA), and what to do when someone's unsure (ask the owner, don't guess).

Test the rule against three real scenarios from the pilot team's week — a client email draft, a competitor research prompt, a meeting transcription. If the rule doesn't give a clear answer for all three, it's still too vague. Rewrite it until it does.

Days 4-5: Test with the pilot team, then roll out

Share the draft with the six-person pilot team and ask them to work a normal day with it open. You're not asking for sign-off yet — you're asking what's confusing, what's missing, and what they'd ignore in practice.

Expect friction on at least one point. In the agency case, the pilot team flagged that the first draft banned using AI for "any client-facing content" — too broad, since half their daily work was AI-assisted drafts a human then edited. The fix: AI drafts, a person reviews and sends. That's the kind of correction you only get by testing on real people doing real work, not by reviewing the document in a vacuum.

Checklist0 of 4 done

Once the fixes are in, send the revised policy to the whole company with a short note: what changed, why, and where to ask questions. Attach a simple acknowledgment — name, date, a line confirming they've read it. This isn't bureaucracy for its own sake; it's the thing that makes the policy enforceable later if something goes wrong, and it gives you a clean count of who's actually seen it.

Set a review date now, while the document is still top of mind — six months out is reasonable for a first version, since tools and regulations will have moved by then.

What this pilot approach gets you that a six-week draft doesn't

A policy tested against one real team for a week surfaces the actual friction points before they become company-wide confusion. It also gets you something a perfect document never will: adoption. People follow rules they've seen tested against their own work, not rules handed down from a document they've never opened.

Once the policy is live, treat it the same way you'd treat any other operational fix worth keeping — write it down as a standard, not a one-off memo. The same logic that applies to locking in a process win as an SOP applies here: a policy that isn't revisited on a schedule quietly goes stale, and a stale AI policy is worse than no policy, because it gives people false confidence that someone's already thought this through.

If you're still deciding which AI tools are worth approving in the first place, that's a separate decision worth its own week — see how to decide what kind of AI leverage you actually need before you expand the approved list much further.

#ai policy#case studies#ai governance#operations#ai strategy
Found this useful? Pass it on.
Share

Want help running this on your own processes?

We'll do the scoring with you on a free 30-minute call and point at the one worth doing first.

Book a discovery call