Hey there 👋, I’m Bryan
Welcome to my newsletter. I share practical advice and tackle tough questions on putting AI to work. Thank’s for being here! Send me your questions and in return I’ll humbly offer actionable real-talk advice 🤜🤛
Does your organization already have an AI use policy? If so, congratulations! Less than half of organizations and businesses have one. But having a policy doesn’t necessarily mean it’s doing its job. Whether you’re writing one from scratch or wondering if your existing policy is effective, here is what I’ve learned about writing an AI policy your team will actually follow (jump to the six steps).
Years before anyone could paste sensitive customer data into a chatbot, I spent what felt like a lifetime (ok, just a year) under the fluorescent lights of a 1950s office-building basement working on a market conduct exam for a big insurance company (Backrooms, anyone?). If you’ve never had the pleasure, a market conduct exam is when insurance regulators pull every business decision you’ve ever made and check it against the rules and the procedures you created and swore you were following. Ours went back 10 years.
Insurance is a unique industry where the policy is literally the product, and even so, most policies go unread by the very customers who are paying for them. This is where examiners come in.
Turns out, having the right procedures on paper doesn’t count for much. The examiners demanded proof we had actually followed them, file after file, and the stakes were quite high. Another big insurer came out the other end of an exam like ours with a $19.75 million fine and more than $189 million in payback payments. We had this in the back of our minds as we worked diligently in that basement. It was the cautionary tale everyone on our team was quietly trying not to become.
I think about that basement a lot now in my AI work, because the examiner’s question matters for an AI policy too: do people’s actions actually match what the policy says?
Most policies go unread. Why?
Be honest, when was the last time you read the terms and conditions for your latest app update?
The legal system rewards companies for having policies, making it tempting to write one for the auditor and call it a day. Legal and compliance usually hold the pen, and they’re tasked with avoiding liability, so they draft the document to hold up in a deposition rather than to be read by the average Joe on a Tuesday morning. Most policy sign-offs only check that you clicked “I acknowledge,” so that’s what gets optimized.
And every time a new issue arises, compliance adds a clause. But nobody ever takes one out. A lot of policies are like scar tissue from an isolated incident, and the policy outlasts everyone who remembers why it’s there.
That’s how you end up with policies people quietly work around. Most policy violations are workarounds for a real problem, and if you ban the workaround while leaving the problem in place, people will just route around it.
The good news is that the auditor is getting harder to fool. Regulators increasingly want proof that a policy actually changed behavior, which is exactly what those examiners in the basement were digging for, file after file. So the best legal defense and the best adoption strategy are turning into the same thing: a policy people actually follow.
Here’s what makes an AI use policy difficult to write
An AI use policy might sit in the same handbook as the travel and expense policy, but it’s far more complex.
First, your people are already using AI, with or without your blessing. A huge survey of UK workers this year found nearly two-thirds use it for work, and about a third of those users haven’t mentioned it to their boss. By the time your policy shows up, it’s walking into a party that started hours ago, mostly on personal accounts. And being fashionably late here is definitely not cool.
Second, your go-to fix of reminding everyone about the risks doesn’t do much. In one recent survey, plenty of healthcare and finance workers were using unapproved AI tools even though most of them said they understood the risks. Nearly half of IT workers said they’d keep using those tools even if their employer banned them and threatened discipline. These people read the warning label and decided the tool was worth it anyway.
Third, you’re writing rules about a quickly changing landscape. The share of big companies reporting serious employee adoption of AI roughly doubled in a single quarter, and a lot of them are now building AI agents. A policy written for a chatbot that drafts emails doesn’t apply to an agent that’s now sending them.
A simple takeaway is that a “ban-first” policy doesn’t stand much of a chance. It sends your employees to their personal phones and accounts, where whoever owns the policy can’t see a thing. How do I know? This hidden use is exactly what’s been showing up in more and more breach reports. The job isn’t just to write rules that address today’s risks. It’s to write something people will actually choose to follow, even as the tools change.
Six steps to writing a useful AI policy
Remember, none of this is complicated. Follow these six steps to avoid accidentally writing an ineffective policy.
Find out how people use AI now. Do this before you write the policy.
Send a short, anonymous survey.
Talk to people in different roles.
Get data from IT about which AI sites people use.
Ask what worries them about AI.
Ask people which tools they use and what they use them for. Tell them that their answers will not get them in trouble. Each workaround you find helps you write your policy.
Write the policy with the people who must follow it. Make a small working group comprising a healthy mix of:
Your heaviest AI users.
One or two skeptics.
A frontline manager.
Legal, privacy, security, HR, and IT.
The group’s first task is to complete one sentence: “This policy keeps _____ safe from _____.” If the only answer is “the company from lawsuits,” start again. Legal will help set the minimum requirements, but the others will make it usable.
Give people an approved tool before you restrict anything. Before launch, have these items ready:
One or more enterprise tools with the necessary data protection.
A clear list of approved uses, in plain verbs (for example: summarize, draft, rewrite, translate).
A process to request new tools, with an established response time.
If the approved tool is worse than the workaround, people will still use the workaround. Last week I explained in Microsoft Copilot is the Frontdoor to AI why free tools and their lack of context are inferior in the workplace.
Set clear limits and explain the reason for each. Most AI policies need limits for these topics:
Which data can go into which tools (customer, employee, health and financial data).
Who is responsible for AI output (the user, which human being must check it).
When to disclose AI use.
Which decisions need human approval (for example, hiring, pay and patient care).
What AI agents can do without human approval.
What to do when you are not sure, and what to do after a mistake. Importantly, do not punish people for reporting their own mistakes. If you do, people stop reporting.
Give a reason for each limit. People who understand the reasoning are better equipped to make good decisions in new situations. Keep the policy short, and provide real examples when possible.
Separate stable rules from rules that will change. Write the policy in two sections:
The core: include main principles, data limits and accountability. This part should be evergreen and rarely need changing.
A living page: list of approved tools and use-case guidance. Plan to update this section on a published schedule, for example monthly or quarterly.
Major policy reversals cause confusion. A published update schedule can help prevent most reversals. Write the next review date and the owner’s name directly in the policy.
Test the policy before launch. Use 10 to 15 real scenarios from step 1. For example:
A recruiter summarizes resumes.
An analyst uses customer data in a spreadsheet.
A manager wants an agent to send follow-up emails.
A clinician writes a visit note.
If two people get widely different answers, change the policy. Then do a pilot with one or two teams for a few weeks. Add the hard scenarios and their answers to the policy as examples.
Ready to launch it?
But wait! After all that work, it’s tempting to just email the PDF to the whole company and head out for lunch. Not so fast. How you introduce the policy matters just as much as how you write it.
A lot of damage can happen in the first few weeks after a policy goes out, and in my experience, it usually follows the same script: It was drafted without the right people and shipped before anyone tested it against real work. Six weeks later, a revised version is reissued because somebody added something obvious the right people would have caught earlier. By then, employees have possibly read one of two versions and heard three interpretations from their managers. What then? They’ve quietly gone back to whatever they were doing before. And then your policy just collects dust on the proverbial shelf.
My solution? Plan the release in tiers. Give your managers the policy at least a week early, with talking points and room to push back. Nothing sinks a policy faster than an employee asking their boss about it and finding out the boss is reading it for the first time, too.
When it’s finally ready to go out to everyone, lead with callouts of what people can use starting today, then the handful of lines they can’t cross and why each one is there. By the end of that week, everyone should know who to ask when they’re unsure, how to report a mistake without dreading the conversation, and when the next update is coming. If your managers can’t explain all of that in their own words, there is more work to be done.
In the following weeks and months, find ways to measure what people actually do, instead of counting who clicked “I agree.” Look at how many people are using the approved tools, whether traffic to unapproved AI sites is dropping, and how many mistakes get reported.
Early on, more reports are a good sign, because it means people trust the process enough to use it. Those numbers tell you whether the policy is working, and they’re exactly the evidence a regulator could ask for someday.
The one question to ask of any policy
When someone hands you a policy, AI or otherwise, one question tells you most of what you need to know about it: if I can’t do this, what am I supposed to do instead?
A policy that can answer that question was written by someone who understood the work. It points you to the approved tool, the person to call, or the process to follow when the usual way isn’t allowed. A policy that can’t answer it was written for the auditor. It tells you to stop solving a problem without telling you how else to solve it. Earlier I said most policy violations are workarounds for a real problem, and this question is the quickest way to find out whether a policy left one of those problems in place.
If you’re the one writing the policy, run every line of your draft through the same question. Anywhere the answer is “nothing” or “it depends,” you’ve found a gap worth fixing before the policy goes out.
The tools in your policy are going to change a lot over the next few years. As long as each version still answers that question, people will have a reason to keep following it. And if those examiners ever come knocking, you’ll have something better than a beautifully written document. You’ll have evidence that people actually use it.
Thanks for reading!
Sincerely,
Bryan 👋
PS - Let me know in the comments if you found this newsletter helpful. Your feedback would mean the world to me 🙏
Know someone that would benefit from this newsletter? Feel free to forward this to them.