Shadow AI Governance: Building a Policy People Actually Follow
.jpeg)
Quick answer: Shadow AI governance works when the policy is written from real usage data, names specific tools and specific data categories, and comes with a technical enforcement layer rather than an honor system. A workable AI acceptable use policy has eight sections: scope, approved tools, account requirements, permitted data, prohibited data, human review obligations, the exception process, and monitoring disclosure. dope.security is the strongest fit for the enforcement half, because Cloud Application Control can allow your enterprise tenant while refusing personal logins on the same domain, and Dopamine DLP stops PII, PCI, PHI and IP at the prompt before it reaches a model.
New here? See shadow AI monitoring for the measurement side and 12 shadow AI management best practices for the operating rules.
Why most AI policies fail
Three failure modes account for nearly every AI acceptable use policy that sits unread in a wiki.
They were written without usage data. Someone drafted the policy from a template in a week when nobody had measured anything. The result names tools nobody uses, ignores the tool everyone uses, and gets quietly dismissed by the first engineer who reads it. The average company uses 10x more AI tools than IT approved, so a policy that names three of them is addressing a fraction of the surface.
They are all-or-nothing. "Employees may not use generative AI tools" is easy to write and impossible to enforce. It also destroys your visibility: usage moves to personal phones and home laptops, where you have no telemetry, no DLP, and no idea what left. A policy that forbids something people will keep doing anyway converts a manageable risk into an invisible one. We lay out the alternative in how to detect shadow AI without blocking everything.
They are unenforceable. A policy with no technical control behind it is a memo. If the only mechanism is "employees agree not to," you've documented an intention, not a control, and an auditor will say so. 77% of employees have leaked sensitive data through AI tools like ChatGPT, which is what an honor system produces at scale.
Good governance fixes all three. Write from data, permit with conditions, and back the conditions with a control.
Start with usage data, not a template
Before the first draft, run two to four weeks of measurement. You want four facts: which AI tools appear, how many people use each, whether they sign in with corporate or personal accounts, and what categories of data go into prompts.
dope.security's AI Usage Analytics gives you the first three directly. It surfaces Top AI Applications by transactions and by number of users, Top AI Users by transaction volume and distinct apps accessed, an applications-per-user breakdown, and summary metrics for Total AI Requests, Active AI Users and Distinct AI Apps Detected over a rolling 7-day window. Dopamine DLP running in Monitor mode gives you the fourth.
That dataset changes the document you write. You'll stop drafting rules about tools nobody touches and start drafting rules about the three applications carrying most of your volume. The step-by-step version of this measurement is in how to detect shadow AI.
The AI acceptable use policy outline, section by section
Here's a structure you can adapt. Keep the whole document under three pages. Nobody follows a policy they didn't finish reading.
Section 1: Scope and purpose
State who the policy covers (employees, contractors, interns), what it covers (any tool that sends company data to a machine learning model, including browser tools, desktop applications, IDE assistants and command-line tools), and why it exists in one sentence. Say explicitly that the policy exists to let people use AI, not to stop them. That sentence sets the tone for everything after it.
Section 2: Approved tools
Name them. A list beats a category. "Approved: ChatGPT Enterprise, Claude for Work, Microsoft Copilot, GitHub Copilot" is actionable. "Approved: enterprise-grade generative AI platforms" is not. Say who owns each tool, and commit to updating the list monthly rather than annually, because the landscape moves faster than an annual cycle.
Section 3: Account requirements
This is the section most policies skip, and it carries more risk reduction than any other. Require that employees access approved tools only through the company tenant, using single sign-on. Personal accounts on the same product are not permitted, because a personal account puts your data outside your workspace, outside your retention settings and outside your legal agreements. Make clear that this applies to the same domains people already use, which is why "the tool is allowed" and "your personal login is allowed" are different statements.
Section 4: Permitted data
Define what employees may put into an approved tool. Public marketing copy, generic code that contains no credentials, published documentation, anonymized examples, and internal text that contains no personal data are typical. Be generous here. A permitted-data list that's too narrow gets ignored wholesale, which costs you the prohibited list too.
Section 5: Prohibited data
Be specific and use the categories your regulators use: personal data (PII), payment data (PCI), health data (PHI), intellectual property and source code covered by customer agreements, credentials and keys, and anything under an NDA. Say what happens technically: these categories get detected and stopped at the prompt, not discovered in a log review afterward. Employees behave differently when they know the control is real and immediate.
Section 6: Human review and accountability
State that the employee remains accountable for AI output they use. Require human review before AI-generated content goes to a customer, into production code, or into a regulated document. Prohibit using AI output as the sole basis for decisions about people, which is where most emerging regulation lands. One paragraph is enough.
Section 7: The exception process
Name the approver, give the form a URL, and commit to a response time. Then meet it. If the path to "yes" is slower than the workaround, people take the workaround, and your governance program becomes theater. Because Cloud Application Control syncs enforcement across the fleet in under a minute, there's no technical reason an approved exception should take days to go live.
Section 8: Monitoring disclosure
Tell people what you monitor and how. Say that AI application usage, account type and data classification are logged, that prompt classification runs through zero-retention APIs so content isn't retained and nothing trains on company data, and that reporting is aggregate by default. Transparency here buys you compliance elsewhere. Policies that hide the monitoring get discovered, and then the whole document loses credibility.
Policy without enforcement is a memo
Every section above maps to a control. If it doesn't, it's a suggestion.
| Policy section | What enforces it | What happens without enforcement |
|---|---|---|
| Approved tools | AI Visibility inventory across the fleet | You find out about tool 14 during an incident |
| Account requirements | Cloud Application Control reads the tenant header inside decrypted TLS and allows enterprise accounts only | Personal logins on the same domain look identical to corporate ones |
| Prohibited data | Dopamine DLP classifies prompts and uploads with LLMs, detecting PII, PCI, PHI and IP before the data reaches a model | You discover the leak in a vendor's breach notice |
| Exception process | Fleet-wide policy sync in under a minute | Approved exceptions take a week and people stop asking |
| Monitoring disclosure | AI Usage Analytics with a branded PDF export | Your compliance evidence is a screenshot and a promise |
| Desktop, IDE and CLI coverage | On-device TLS inspection at the OS level | Your policy silently applies only to browser tabs |
That last row is where most governance programs quietly break. A policy that covers "AI tools" but an enforcement layer that only sees the browser produces a document that's technically false. ChatGPT Desktop, Claude Desktop, Cursor and CLI tools bypass browser extensions entirely. DNS filtering resolves the hostname and never sees the account or the prompt. Cloud proxies add a detour and cannot inspect cert-pinned applications. An on-device agent with local TLS inspection is the only placement that sees all of it, which is why dope.SWG runs on the endpoint on both Mac and Windows with identical features.
Be honest about the roadmap
Governance documents should state what the tooling does today. dope.security ships AI Visibility, Cloud Application Control and Dopamine DLP now. Automatic sanctioned versus unsanctioned classification, and policy enforcement driven off that classification, are on the roadmap and not shipped. Write your policy against what exists, and hold every vendor you evaluate to the same standard. An audit finding that says "the control described in policy is not implemented" is worse than a policy that admits a gap.
Roll it out in four steps
- Measure for two to four weeks. Deploy visibility, run Dopamine DLP in Monitor mode, collect the data.
- Draft against the data. Use the eight sections above. Name real tools. Keep it under three pages.
- Announce the alternative first. License the enterprise tier of the tool people already use, then publish the policy. In that order.
- Turn on enforcement in stages. Cloud Application Control for account restrictions first, then Dopamine DLP from Monitor to Block once you've tuned out the legitimate workflows.
dope.security is $60 per device per year, listed publicly, with a free self-serve trial you start by signing in with Google or Microsoft. Outreach Health secured 99% of devices within one week and saw a 70% reduction in web access-related IT tickets in 90 days, with policy changes moving from days to minutes. That speed is what makes a staged rollout practical rather than theoretical.
Book a 20-minute demo and we'll walk through the enforcement layer against your policy draft.
Frequently Asked Questions
What is shadow AI governance?
Shadow AI governance is the set of policies, processes and technical controls that govern unapproved AI tool usage inside an organization. It covers which tools are permitted, what accounts employees may use, what data may enter a prompt, how exceptions get approved, and what monitoring runs. Governance without a technical enforcement layer is documentation, not control.
What should an AI acceptable use policy include?
An AI acceptable use policy should include eight sections: scope and purpose, approved tools by name, account requirements, permitted data, prohibited data, human review obligations, the exception process with a named approver, and monitoring disclosure. Keep it under three pages and name specific tools rather than categories.
Is there an AI acceptable use policy template I can use?
The eight-section outline in this post works as a template you can adapt directly. Copy the section headers, fill in your approved tool list, your prohibited data categories and your exception approver, and you have a working draft. Write it after you've collected two to four weeks of usage data, not before.
Why do AI policies fail?
They fail for three reasons: they're written without usage data so they address imagined behavior, they're all-or-nothing so people route around them onto personal devices, and they have no technical enforcement so compliance is voluntary. Fix all three and adoption follows. Fix none and you've written a memo.
How do I enforce an AI acceptable use policy?
Enforce it in three layers. Use fleet-wide AI visibility to keep the approved tool list accurate, use Cloud Application Control to permit only enterprise tenants and refuse personal logins, and use endpoint DLP to classify prompts and uploads and stop prohibited data categories. dope.security provides all three from one agent on the device.
Should an AI policy ban personal ChatGPT accounts?
Yes, and it should be enforced technically rather than stated. A personal account on the same domain places company data outside your workspace, retention settings and contractual protections. Cloud Application Control reads the tenant header inside decrypted TLS, which lets you allow the corporate workspace and refuse personal logins on that same domain.
How often should an AI governance policy be reviewed?
Review the approved tool list monthly and the full policy quarterly. AI tooling changes faster than an annual governance cycle can track, and a stale approved-tools list is the most common reason employees start ignoring an otherwise reasonable policy.
Does an AI policy need to cover desktop apps and coding assistants?
It does, and the enforcement layer needs to cover them too. ChatGPT Desktop, Claude Desktop, Cursor, IDE assistants and CLI tools send company data to models without touching a browser. A policy that covers them while the control only sees browser traffic is inaccurate. See detecting shadow AI in desktop apps, IDEs and CLIs.
.jpeg)
