Setting the Ground Rules
Here’s the standard rollout, and you’ve probably lived it: leadership buys licenses, IT flips on access, someone sends the launch email, maybe there’s a lunch-and-learn. Then the project is marked complete.
Look at what that sequence accomplished. Access was granted. Adoption never started.
Adoption is the part after the email — the weeks of noticing that someone still builds their Friday report by hand, sitting with them to find the one step AI genuinely helps with, and checking back to see whether it stuck. That work is real work. It takes hours, judgment, and follow-through, and in most organizations it appears on exactly no one’s job description.
This guide is the first step of that: an owner, and rules people can state from memory. Everything after it waits on these two things.
Name one owner
Not a committee. Not “the team.” One person, with about two hours a week that are actually protected.
The reason is unglamorous: anything that belongs to everybody doesn’t survive a busy quarter. When a tool is optional and unowned, three things happen with total predictability. The enthusiasts self-serve — they were going to tinker regardless. Everyone else tries it twice, hits friction, and quietly reverts, because reverting costs nothing and nobody notices. And a small group opts out on principle and never gets asked why.
The owner’s job is the middle group. Concretely: run the pilot, keep the prompt library, hold office hours, and notice who hasn’t touched the tool in three weeks.
It doesn’t have to be you. It has to be someone, in writing, with the hours real.
Get the data rules, then write the policy
People will not experiment freely until they know where the line is. An unwritten policy doesn’t produce caution — it produces quiet, unmonitored use with no guardrails at all.
The document itself is not the hard part. It’s one page, four sections — what you actively want people using AI for, the one hard line about what never goes in, who verifies what before it ships, and one named person to ask — and it’s already written for you as the one-page policy template. Fill in the brackets. If you’d like to see one completed for a real-shaped team, the worked example has one for a 14-person claims department.
Two things about it are worth arguing for, because they’re the ones people get backwards.
Lead with permission, not prohibition. Name the things you actively want people using AI for before you name the limits. A policy that’s all “don’t” gets ignored, or it scares people off the tool entirely and you lose the upside. Section 1 should be longer than section 2.
Be specific about the hard line. “Confidential data” changes nobody’s behaviour at 4pm on a Thursday; “claim reference numbers and anything from a litigated file” does. The reason for the line isn’t superstition — with many consumer tools, what you type can be retained and used as The material an AI model learns from. Some consumer tools feed what you type back into improving the model, which means confidential text you pasted could, in principle, influence output elsewhere later. Business and enterprise tiers usually contract this away; free consumer versions often make no such promise. Check the specific tool’s data settings. . The plain version of the rule: if you’d hesitate to post it publicly, it doesn’t go in.
The part that actually blocks people
That hard line has to come from security, legal, or IT in writing — not from you, from memory. And this is where most rollouts stall, usually not because anyone said no, but because nobody replied.
Do this on day one, before anything else in this guide, because it’s the only step whose timing you don’t control. Getting the yes is the whole job: who to ask depending on how your company is set up, the five questions that are narrow enough to actually get answered, an email you can send today, what to do at day 10, 20, and 30 of silence, and the six things you can get on with while you wait.
The short version: don’t ask “can we use AI?” — that invites a committee. Ask “given that we already have this tool, what may my team put into it?”, pre-write the answer you expect so they only have to correct it, and name a date after which you’ll tell your team that AI use is limited to public and made-up material until they reply.
That last part is the bit to get right. The deadline commits you to a restriction, not to a policy of your own — narrowing what your team may do is squarely your call as their manager, while deciding what company data may go into a third-party tool is not, however long you’ve been ignored. Don’t write your own never-list and publish it as “provisional.” Publish the interim notice, keep escalating, and let the awkwardness of a visibly paused team do the work.
Nearly everything in the next guide is unblocked while you wait — provided it runs on public or made-up material until the answer lands.
Take a baseline before anything launches
Ten minutes, and you cannot recover it later.
Run the five-question confidence survey — it’s in the full playbook — before anyone has used anything in anger. It’s the only way the write-up at the end of all this has something honest to compare against, and it is the single most commonly skipped item in the whole sequence.
Where this goes next
Two things should now be true: someone owns this by name, and everyone can state what’s allowed without looking it up.
That’s what the pilot needs — the next guide, and the one that turns permission into proof. If the pace here feels slower than you can afford, the same sequence compressed to 30 days is in the compressed version, and it’s a better plan than a long one that keeps slipping.
The takeaway: the rollout everyone runs ends where adoption begins. Name the person who owns the part that comes after the launch email, and you’ve already done more than most.