How to write a shadow AI policy for your company

If you've noticed people on your team pasting customer data or source code into ChatGPT, you already know the problem. This is the follow-up: what to actually write down and roll out, so the policy changes behavior instead of just existing as a document nobody reads. (For the evidence on how widespread this is and why blocking it outright doesn't work, see our earlier piece on shadow AI. This one skips the case-building and goes straight to what to do.)

A policy that's just a list of banned tools will be ignored, for the same reason a firewall block gets routed around: it removes an option without replacing it with anything, and the underlying need to get work done faster doesn't go away because you wrote a rule against it. The policies that actually change behavior have three parts: a clear list of what's approved, a simple way to classify what data can go where, and an alternative good enough that people don't feel like they're giving something up.

1. An approved tools list, kept current

Name the specific tools people are allowed to use, and under which accounts. "AI tools are permitted" is not a policy; "ChatGPT Enterprise under the company workspace is permitted, personal ChatGPT accounts are not" is one. The distinction matters because the risk usually isn't the tool, it's the account: a personal account has no admin console, no contractual protection, and no visibility for your IT or security team into what was typed into it.

Assign someone to own this list and review it quarterly. New tools show up constantly, and a list that was accurate in January and never touched again is worse than no list, because it trains people to treat the whole policy as stale.

2. Data classification simple enough people actually use it

Complicated classification schemes get ignored under deadline pressure. Three tiers, plainly labeled, work better than five with subtle distinctions:

• Public. Already published or fine to publish. Marketing copy, public documentation, general research questions. No restriction on which AI tool.
• Internal. Not secret, but not for outside parties either. General internal process questions, non-sensitive code, draft communications. Fine for any approved enterprise-tier tool with training disabled.
• Restricted. Customer PII, source code for the core product, unreleased financials, anything under an NDA, contracts, and HR records. Only the sanctioned internal tool, if one exists, or no AI tool at all.

Give concrete examples for your specific business, not abstract categories. "Restricted" means nothing to a new hire under deadline pressure; "don't paste customer account numbers, even to summarize a support ticket" does.

3. A sanctioned alternative that's actually good

This is the part most policies skip, and it's the part that determines whether the policy works. If the approved option is slower or worse than what people already use, the policy gets worked around the first time someone's in a hurry, exactly the pattern behind the Samsung ChatGPT leaks in 2023, where a network ban was announced before an alternative existed, and employees kept finding ways to use the tool anyway until the ban was made total.

The alternative doesn't have to match a frontier model's every capability. It has to be good enough that a reasonable employee, choosing between "use the sanctioned tool" and "paste this into ChatGPT on my phone", picks the sanctioned tool without a second thought. In practice that means: a familiar chat interface, response speed that doesn't feel like a downgrade, and access to it that's as easy as opening a bookmark, not a multi-step VPN and login process that makes the unsanctioned option feel faster even when it isn't.

A self-hosted assistant running on infrastructure your organization controls is one way to get there: same day-to-day usefulness as a consumer chat tool, but nothing typed into it leaves your network, and restricted-tier data has somewhere to go instead of nowhere. That's the gap a private, internally hosted model closes, and it's why "provide the alternative" has to come before "restrict the rest" in the rollout order, not after.

Rolling it out without it becoming shelfware

• Announce the alternative before the restriction. If people hear about the sanctioned tool and the new rule in the same email, the rule reads as the headline and the tool as an afterthought. Give the alternative a week or two of quiet adoption first if you can.
• Explain the why, briefly, every time. A rule with no stated reason gets treated as bureaucracy and worked around. "Customer data going through a personal ChatGPT account isn't covered by our data processing agreements with customers" is one sentence and it's the actual reason.
• Make reporting a near-miss low-stakes. Someone who realizes after the fact that they pasted something they shouldn't have needs a clear, non-punitive way to flag it, because finding out fast is much better than finding out during an audit.
• Revisit every two quarters. New tools, new browser extensions, and new AI features quietly added to existing software (a "smart compose" that's secretly calling an external API) all shift the landscape faster than most policies get updated.

What this looks like as an actual document

Keep the written policy to one page. A one-paragraph statement of intent, the three-tier data classification with your own concrete examples, the current approved-tools list with account requirements, and one sentence on who to ask when something isn't covered. Anything longer gets skimmed once and never read again. The tools list will change quarterly; the rest of the document shouldn't need to.