Why the ban fails
The all-staff email banning AI tools produces a specific, predictable outcome. Usage drops on company laptops and continues everywhere else. Someone opens the same chatbot on their phone. Someone else forwards the document to a personal email address first. The data still leaves your control, the only difference is that you can no longer ask anyone about it. You have traded a visible problem for an invisible one and called it progress.
A ban also punishes exactly the wrong people. The employee who came to you and asked whether a tool was allowed now learns that asking gets a no, so they stop asking. The employee who never asked carries on unchanged. Over a few months the policy quietly selects for the least communicative people on your team, and your picture of what is happening gets worse rather than better.
There is a practical problem too. AI is no longer a separate category of software you can wall off. It is a note-taker that joins your video calls, a summarize button in your CRM, a drafting assistant inside the office suite you already pay for, a rewrite feature in your email client. Telling people not to use AI tools is not enforceable when half the features arrived through products you approved two years ago and updated last week.
Find out what is actually in use
Start by asking, but ask in a way that can produce an honest answer. Send a short, specific request: we are building the approved list, tell us what you use for work and what it does for you. Ask about the task before the tool. "I use it to turn meeting notes into a client recap" tells you far more than a product name, because it tells you what capability you need to replace if the answer turns out to be no.
Then corroborate, because self-reporting is always incomplete. Expense reports and the company card statement are the highest-yield place to look: recurring charges in the twenty to forty dollar range to AI vendors show up clearly once you know to scan for them. Your identity provider is the second: Google Workspace and Microsoft 365 both list the third-party apps employees have granted access to company mail, calendar, and files, and that list is often longer and stranger than anyone expects. If you manage devices, pull the browser extension inventory. If you have a firewall or DNS filtering, look at outbound requests to AI vendor domains over the past month. None of these is complete alone. Together they give you a real map.
Somewhere in this process you need to have the amnesty conversation, and you need to mean it. Say plainly that nothing anyone did before today is a disciplinary matter, and that from a stated date there are rules. The reason is not generosity, it is information. If sensitive data has already gone into a tool, you want to hear about it now, quietly, while you can still check the retention setting and delete the conversation. Punish the first honest answer and you will not get a second one from anybody.
Triage what you find into three buckets
Once you have a list, sort every tool into one of three outcomes: approved for normal work, approved with limits, and not for company data. That third label is deliberate. It is not a statement about the tool's quality or about what people do on their own time. It says this specific service does not get our client files, and saying it that way keeps the conversation about data instead of about trust.
Decide by reading the terms of the exact tier in use, not the vendor's marketing page. The free consumer tier and the business tier of the same product frequently differ on the things that matter most: whether your inputs train the model, how long conversations are retained, whether an administrator can see or delete them, and whether the account can be tied to your SSO so it disappears when someone leaves. A tool can move from the third bucket to the first purely by upgrading the plan and changing two settings, which is often the cheapest fix available to you.
Be generous where the stakes are low. A tool someone uses to tighten up a public blog post does not need the scrutiny you apply to one that reads client contracts. Sorting by data sensitivity rather than by how serious the tool sounds keeps your review effort proportional and keeps your credibility intact. Every unexplained no teaches people to route around you next time, so when you do refuse something, say which data concern drove it and what they should use instead.
Write a one-page rule people will actually follow
Length is a control, not a formatting preference. A rule that does not fit on one page will not be read, and you cannot hold someone to a document they never finished. This is where a short operating rule differs from a formal AI policy: the policy is the governing document you keep in the handbook and review with counsel, while the one-pager is what gets pinned in Slack and repeated in onboarding. Both should say the same things. Only one of them needs to be readable in ninety seconds.
Four things belong on the page. The approved tools and which account to sign in with. The short list of data that never goes into a general AI tool. One sentence on how to request something new. The name of the person to ask when the page does not cover the situation. Write it as instructions to a colleague, not as clauses. "Use your work Google account, not your personal one" lands better than a paragraph about authorized access credentials.
Make the forbidden-data list concrete and short. Categories like confidential information get interpreted generously by a person in a hurry at 6pm, and they will interpret in favor of finishing the task. Name the actual things: customer contact lists, signed contracts, payroll and personnel files, passwords and API keys, anything covered by a client NDA, source code from a client repository. Six specific items beat two abstract ones, and people can hold six items in their head.
Make the sanctioned path faster than the shadow one
The speed of your approval process determines the outcome more than the content of your rules does. If getting a tool approved takes two weeks and putting it on a personal card takes two minutes, you will keep having this problem no matter how well the one-pager is written. Set an internal target and publish it: same day for anything already on the approved list, one week for a genuine review of something new. If you cannot meet that, the process is the risk.
The fastest sanctioned alternative is usually the business tier of the tool people are already using. This gets skipped surprisingly often in favor of an enterprise platform that nobody asked for and nobody wants, which produces a well-governed product with no users and a shadow problem that never goes away. Buying the paid tier of the incumbent gives you administrative control, retention settings, and SSO, while people keep the habits and prompts they have already built. It is a boring answer and it works.
After the switch, measure adoption rather than compliance. Compliance is what people tell you in a meeting. Adoption is whether the company account is actually being used, and whether the expense report scan comes back clean next quarter. If people still drift back to personal accounts, something in the sanctioned option is missing: a model they preferred, file uploads, a mobile app, or just speed. Ask them, fix the gap if you can, and explain the constraint if you cannot. Shadow AI is a symptom, and the useful reading of it is that someone found a better way to work before you did.
You cannot secure AI use you cannot see, and you will not see it if asking gets punished. Find out what people already use, sort the tools by what data they touch, and provide a sanctioned option quickly enough that the unsanctioned one stops being worth the trouble.