# Why Teams Behind Restrictive AI Policies Use Shadow AI More **By Dan Cumberland** · Published September 25, 2026 · Categories: Leadership ![Featured image for Why Teams Behind Restrictive AI Policies Use Shadow AI More](https://cms.dancumberlandlabs.com/uploads/featured_image_77f3dff9a7.webp) Illustration: Dan Cumberland Labs with Gemini. > Your organization has an AI policy. Maybe you wrote it, maybe someone handed you one to review, or maybe your legal team produced something after a vendor... Your organization has an AI policy\. Maybe you wrote it, maybe someone handed you one to review, or maybe your legal team produced something after a vendor inquiry\. Either way, there's a document in a shared folder somewhere— and research from WalkMe[1](/blog/blog-ai-policy-clauses-to-remove#ref-1) shows that 78% of your employees are using AI tools it doesn't cover\. What matters most comes first: the problem usually isn't effort\. Most AI policies fail because they contain specific ai policy clauses that make them unenforceable, overbroad, or legally counterproductive— regardless of how carefully the rest was written\. CloudEagle puts it directly: an unenforceable clause is worse than a missing one, because it documents awareness without mitigation[3](/blog/blog-ai-policy-clauses-to-remove#ref-3)\. UpGuard research[2](/blog/blog-ai-policy-clauses-to-remove#ref-2) found that more than 80% of employees— including nearly 90% of security professionals— use unapproved AI tools in their jobs\. And 69% of organizations suspect employees are using prohibited tools regardless of what the policy says[1](/blog/blog-ai-policy-clauses-to-remove#ref-1)\. The policy exists\. The behavior continues\. Something in the document is creating that gap\. Restrictive AI policies don't control the behavior\. They drive it underground— and then organizations lose the visibility they most need to manage the actual risk\. That's the real cost of a poorly designed clause\. If you're building or auditing an [AI strategy](/services/ai-strategy/) that includes governance, start here\. These six patterns appear in nearly every template, and each one causes a different kind of damage before anyone reads the rest of the policy\. - **The blanket ban**— drives AI use underground instead of managing it - **The vague restriction**— unenforceable and legally exposed - **The missing output accountability clause**— an unsigned liability blank - **The overbroad confidentiality clause**— protects against the wrong risk - **No client disclosure default**— inconsistency disguised as flexibility - **Missing review cadence**— the clause that turns a good policy into an outdated one The first clause is the most common— and the most counterproductive\. ## Clause 1: The Blanket Ban A blanket ban stops employees from reporting AI use, not from doing it— which is a worse outcome\. **What the problematic clause looks like:** - "Employees must not use unapproved AI tools for any work purpose\." - "All AI use requires prior written approval from IT\." - "Use of generative AI tools such as ChatGPT or Claude is prohibited\." Oliver Patel, who has written extensively on AI governance failures, describes blanket bans as "conceptually unsound and difficult to justify, implement, and enforce"[4](/blog/blog-ai-policy-clauses-to-remove#ref-4)\. The failure is structural, not behavioral\. When enterprise AI approval cycles take 6–12 weeks while browser\-based AI is accessible in seconds[5](/blog/blog-ai-policy-clauses-to-remove#ref-5), the policy doesn't change what employees do— it changes whether they report it\. Adaptive Security research[5](/blog/blog-ai-policy-clauses-to-remove#ref-5) found that employees in low\-trust environments conceal AI use at nearly four times the rate of those in high\-trust environments\. A blanket ban signals low trust\. The concealment follows\. And the talent cost is real\. Organizations that prohibit AI tools competitively disadvantage themselves in retention— especially with team members whose peers at other firms use these tools daily\. **What to put instead:** - An approved tools register with specific use\-case categories - Targeted boundaries for high\-risk data \(not blanket prohibition\) - A path to request approval for tools not yet on the register - Training requirements tied to tool access The goal is [building an AI culture](/blog/building-ai-culture) where employees bring their AI use into the open— not deeper underground\. ## Clause 2: The Vague Restriction "Use AI responsibly" documents awareness without telling anyone what to do— which is a vulnerable position when something goes wrong\. **What the problematic clause looks like:** - "Employees must use AI tools responsibly and in compliance with applicable law\." - "Use good judgment when working with AI\-generated content\." - "AI use must align with our company values\." Good Transformer's analysis of common policy failures[6](/blog/blog-ai-policy-clauses-to-remove#ref-6) identifies vague restrictions as the most frequent template gap: unclear rules force employees to guess rather than ask\. And the legal exposure is specific: Sprintlaw[7](/blog/blog-ai-policy-clauses-to-remove#ref-7) flags vague AI use restrictions as an FTC enforcement risk— if an organization makes an AI\-related claim or puts AI\-generated content in front of customers, the vagueness of the underlying policy becomes a liability, not protection\. An unenforceable clause documents that you knew about the risk\. That's the opposite of mitigation\. **What to put instead:** Specific prohibited categories by data type, not by intent: - "Do not input customer PII, employee records, unpublished financial data, NDA'd content, or credentials into AI tools\." - Name the specific data categories\. Name the specific consequences\. - Add a note that specific legal language should be reviewed with counsel before publication\. The difference between "use AI responsibly" and a real clause is the difference between awareness and governance\. ## Clause 3: The Missing Output Accountability Clause If your policy doesn't specify who reviews AI output for accuracy before it reaches a client, customer, or regulator, you have an unsigned liability blank\. The output will get used\. The question is whether anyone was accountable for it\. **What the missing clause looks like:** Any policy that addresses AI use without addressing who reviews what comes out of it\. Or a policy that says only "verify AI output for accuracy" without naming a role or process\. Gartner research[8](/blog/blog-ai-policy-clauses-to-remove#ref-8) found that 74% of enterprise AI projects with significant production failures lacked a formal risk management process at the time of deployment\. The accountability gap is real and measurable\. In practical terms: if your policy doesn't name a reviewer before the output reaches a client, the output will reach a client without review\. For AEC firms specifically, this gap is acute\. Unicel Architectural[9](/blog/blog-ai-policy-clauses-to-remove#ref-9) documents the specific risks: AI\-generated design documentation, cost estimates, or specifications put in front of a client without named human review creates accountability gaps that have no legal cover\. The output reached the client\. No one was responsible for whether it was accurate\. **What to put instead:** ```html-table
Without this clauseWith this clause
"AI output should be reviewed before use.""AI-generated output is a draft. [Project Manager / named role] is responsible for accuracy, completeness, and client-readiness before delivery or publication."
``` Name the role\. Name the standard\. The clause needs an owner— and we'll return to that principle at the end\. ## Clause 4: The Overbroad \(or Under\-Specific\) Confidentiality Clause Standard confidentiality clauses weren't written for AI\. They cover what you share with competitors— not what your AI vendor does with the data in your prompts\. **Two failure modes exist here**, and both are common\. The first is a clause that misses AI\-specific risks entirely\. Tish Law's analysis[10](/blog/blog-ai-policy-clauses-to-remove#ref-10) of AI vendor contracts finds that standard SaaS agreements may address uptime and user accounts while overlooking essential questions about data usage and model training\. Information may be "copied into prompts, stored in logs, reviewed by vendor personnel, transmitted to model providers"[10](/blog/blog-ai-policy-clauses-to-remove#ref-10) without clear restrictions in standard agreements\. The second failure is a clause that prohibits "sharing data with third parties" without specifying AI tools— creating interpretation ambiguity that employees resolve however they need to\. Both failure modes focus on the enterprise contract\. They're missing the bigger exposure\. **The real risk is internal\.** Tech Business News[12](/blog/blog-ai-policy-clauses-to-remove#ref-12) put it plainly: the actual exposure usually isn't the enterprise AI contract— it's thirty people pasting client material into chat windows on personal accounts that no one can track\. According to published research[11](/blog/blog-ai-policy-clauses-to-remove#ref-11), 68% of employees use free\-tier AI tools via personal accounts; 57% input sensitive data\. For AEC firms, this is compounded: BIM models \(Building Information Modeling files— the integrated data sets that govern construction projects\) contain client IP, third\-party copyrighted content, and personally identifiable information about building users[13](/blog/blog-ai-policy-clauses-to-remove#ref-13)\. Standard confidentiality language doesn't address any of it\. **Three things your confidentiality clause needs to say about AI:** - Explicit prohibition on using your data to train vendor models without prior written consent[10](/blog/blog-ai-policy-clauses-to-remove#ref-10) - Prohibition on enterprise data in free\-tier or personal\-account AI tools \(named specifically\) - Specific data categories that cannot enter AI systems: client proposals, BIM data, unpublished financials, employee records, vendor credentials > **AEC note:** BIM data and client project information deserve their own named prohibition\. The SMPS AI Governance Policy[13](/blog/blog-ai-policy-clauses-to-remove#ref-13) for AEC firms treats these as a distinct governance category, separate from general confidentiality\. ## Clause 5: No Client Disclosure Default If your policy doesn't define when to disclose AI use to clients, every team member is making a different judgment call\. That inconsistency is compliance exposure waiting to materialize\. **What the missing clause looks like:** Policies that mention "transparency" or "honesty" in AI use without specifying a default position\. Or policies that leave disclosure to individual judgment\. Sprintlaw[7](/blog/blog-ai-policy-clauses-to-remove#ref-7) identifies missing disclosure defaults as a top compliance failure\. Inconsistent disclosure patterns open organizations to regulatory scrutiny under state AI transparency laws\. They also create exposure under client contracts that may include AI disclosure requirements organizations don't know about\. A defined policy is easier to defend than a pattern of inconsistent individual decisions\. The Partnership on AI's 2026 governance priorities[14](/blog/blog-ai-policy-clauses-to-remove#ref-14) list "Preserve Human Voice" as a core focus— which requires knowing when AI was used in client\-facing work\. Regulatory direction is moving toward disclosure requirements, not away from them— state AI transparency laws are already creating disclosure obligations many organizations don't know they have\. **What to put instead:** ```html-table
Disclose by defaultNot required
Client-facing deliverables written with AI assistanceInternal research, analysis, and draft documents
Content published under a named person's byline where AI contributed substantiallyInternal communications and process documentation
Proposals where AI generated substantive content, not formattingAdministrative tasks (scheduling, formatting, organization)
``` Define the line\. Remove the gray area\. ## Clause 6: Missing Review Cadence An AI policy published today without a review date is an AI policy that will be wrong by Q2\. Tools release major updates monthly\. Regulations change\. Use cases expand\. The policy needs a maintenance schedule\. **What the missing clause looks like:** Any policy without a named reviewer, a scheduled review date, or criteria for immediate review\. IAPP \(the International Association of Privacy Professionals— the leading professional organization for privacy governance\)[15](/blog/blog-ai-policy-clauses-to-remove#ref-15) recommends quarterly reviews at minimum, with event\-driven reviews for additional assessments\. Consumer AI tools iterate weekly with cutting\-edge models while enterprise alternatives lag months behind[5](/blog/blog-ai-policy-clauses-to-remove#ref-5)— which means what was "approved" six months ago may be a substantially different product today\. Ethisphere[16](/blog/blog-ai-policy-clauses-to-remove#ref-16) makes the structural argument: AI policy can't be a single static document\. It requires a three\-layer structure \(principles, policy, guidance\) to stay maintainable— and all three layers need scheduled review\. The EU AI Act's high\-risk obligations became enforceable in August 2026[17](/blog/blog-ai-policy-clauses-to-remove#ref-17), creating a concrete example of how regulatory changes can require immediate policy updates\. **What to put instead:** - Scheduled cadence: "This policy will be reviewed quarterly by \[role\]\." - Event\-driven triggers for immediate review: **Triggers requiring immediate policy review:** - A new AI tool is approved for organizational use - A significant regulatory change affects AI compliance obligations - An AI\-related data incident is identified - A major capability update to an existing approved tool - A client contract includes AI governance terms that affect current policy The [AI decision framework for founders](/blog/ai-decision-framework-founders) addresses how to build governance structures that scale— a policy without a review cadence doesn't scale, it just ages\. ## The Enforcement Test Before publishing any AI policy clause, ask whether it has all three: an owner, a detection signal, and an automated action\. Without all three, it's a principle— not a policy\. CloudEagle's enforcement test[3](/blog/blog-ai-policy-clauses-to-remove#ref-3) is the clearest version of this: every enforceable clause needs three attributes\. > **The Three\-Part Enforcement Test** 1\. **Owner**— Who is responsible for monitoring and enforcing this clause? 2\. **Detection signal**— How will a violation be identified? What triggers review? 3\. **Automated action**— What happens automatically when a violation is detected? \(For teams with IT tooling, that might mean automated access revocation or a Slack alert\. For everyone else, it means a consequence that activates through the workflow without requiring a manager to remember to enforce it\.\) Walk any of the six clauses above through this test\. "Use AI responsibly" fails immediately: no owner, no detection signal, no action\. "AI\-generated client deliverables require review by the project manager before submission" passes: owner named, detection is submission workflow, action is review gate\. The principle generalizes\. Any clause that doesn't survive this test is compliance theater[3](/blog/blog-ai-policy-clauses-to-remove#ref-3)— a worse position than no clause at all, because it documents awareness without mitigation\. That's the standard you're publishing against\. For more on building [AI governance strategy](/blog/ai-governance-strategy), this test applies at every level of policy design\. ## FAQ The questions below cover the most common gaps in how AI policies are built and maintained\. ### What's the difference between a good AI policy and compliance theater? Enforcement mechanisms\. A real policy clause names who enforces it, how violations are detected, and what happens when one occurs\. A compliance theater clause names the rule without any of the infrastructure to back it up[3](/blog/blog-ai-policy-clauses-to-remove#ref-3)\. The distinction matters most when something goes wrong: a clause that documented awareness without mitigation is not a defense— it's evidence\. ### Why do employees ignore AI policies? Three structural gaps drive the behavior\. First, enterprise AI approval cycles take 6–12 weeks while browser\-based AI is instant[5](/blog/blog-ai-policy-clauses-to-remove#ref-5); the friction of compliance is higher than the friction of circumvention\. Second, free consumer tools often outperform enterprise alternatives, so approval isn't worth waiting for\. Third, policies that are vague or overly restrictive generate low trust— and research[5](/blog/blog-ai-policy-clauses-to-remove#ref-5) shows employees in low\-trust environments conceal AI use at nearly four times the rate of high\-trust organizations\. Ignoring the policy is the rational response to all three gaps\. ### How often should an AI policy be reviewed? Quarterly at minimum, per IAPP guidance[15](/blog/blog-ai-policy-clauses-to-remove#ref-15)\. Plus event\-driven reviews when new tools are approved, regulations change, or an AI\-related incident occurs\. This isn't excessive— it reflects how quickly the landscape moves\. A policy that was accurate in January may have three gaps by April\. ### What data should be explicitly prohibited in AI tools? At minimum: customer PII, unpublished financial data, NDA'd content, employee records, and vendor credentials\. AEC firms should add BIM model data and client project information, which carry distinct IP and liability exposure[13](/blog/blog-ai-policy-clauses-to-remove#ref-13)\. The prohibition should name the data categories specifically— "sensitive information" is a vague restriction\. Name what can't go in; don't leave employees to define it themselves[10](/blog/blog-ai-policy-clauses-to-remove#ref-10)\. ## Conclusion A well\-designed AI policy is the infrastructure that makes responsible innovation possible\. Remove the clauses that create the illusion of governance\. Build the ones that hold up when something goes wrong\. Six clauses removed means one thing: your employees can follow the policy, your leadership can enforce it, and your organization keeps the visibility it needs to manage real risk\. That's the goal\. A document in a SharePoint folder that nobody reads isn't governance\. It's liability\. If auditing an existing policy feels like the right next step but the scope is unclear, this is exactly the kind of work [Dan Cumberland Labs](https://dancumberlandlabs.com) does with organizations— assessing what's in place, identifying what's missing, and building governance frameworks that scale with how your AI use actually grows\. You can also learn more about [what a fractional AI officer does](/blog/what-is-a-fractional-ai-officer) to see whether a structured advisory engagement fits your situation\. Your policy should be the thing your team actually follows\. Remove these six clauses and you might be surprised how much simpler that becomes\. ## References 1. WalkMe, "Knowledge Worker Survey on Shadow AI Usage" \(2025\)— [https://www\.worklytics\.co/blog/writing\-an\-ai\-policy\-that\-actually\-works](https://www.worklytics.co/blog/writing-an-ai-policy-that-actually-works) 2. UpGuard, "Shadow AI Is Widespread— And Executives Use It the Most" \(2025\)— [https://www\.cybersecuritydive\.com/news/shadow\-ai\-employee\-trust\-upguard/805280/](https://www.cybersecuritydive.com/news/shadow-ai-employee-trust-upguard/805280/) 3. CloudEagle, "AI Usage Policy Template: What to Include" \(2025\)— [https://www\.cloudeagle\.ai/blogs/ai\-usage\-policy\-template](https://www.cloudeagle.ai/blogs/ai-usage-policy-template) 4. Oliver Patel, "Banning AI Is Not an Effective AI Policy" \(2026\)— [https://oliverpatel\.substack\.com/p/banning\-ai\-is\-not\-an\-effective\-ai](https://oliverpatel.substack.com/p/banning-ai-is-not-an-effective-ai) 5. Adaptive Security, "Why Employees Use Shadow AI: Psychology, Pressures, and Structural Gaps" \(2025\)— [https://www\.adaptivesecurity\.com/blog/why\-do\-employees\-use\-shadow\-ai\-the\-psychology\-pressures\-and\-structural\-gaps\-behind\-unauthorized](https://www.adaptivesecurity.com/blog/why-do-employees-use-shadow-ai-the-psychology-pressures-and-structural-gaps-behind-unauthorized) 6. Good Transformer, "The AI Policy Clauses Most Templates Miss" \(2024\)— [https://goodtransformer\.ai/insights/ai\-acceptable\-use\-policy\-clauses/](https://goodtransformer.ai/insights/ai-acceptable-use-policy-clauses/) 7. Sprintlaw, "Common AI Acceptable Use Policy Mistakes That Create Customer Risk" \(2025\)— [https://www\.sprintlaw\.com/articles/common\-ai\-acceptable\-use\-policy\-mistakes\-that\-create\-customer\-risk/](https://www.sprintlaw.com/articles/common-ai-acceptable-use-policy-mistakes-that-create-customer-risk/) 8. Gartner 2025 Technology Risk Management Survey, cited in Splunk— [https://www\.splunk\.com/en\_us/blog/learn/ai\-governance\.html](https://www.splunk.com/en_us/blog/learn/ai-governance.html) 9. Unicel Architectural, "AI Governance in AEC: Building Trust, Accountability, and Long\-Term Value" \(2025\)— [https://unicelarchitectural\.com/ai\-governance\-in\-aec\-building\-trust\-accountability\-and\-long\-term\-value/](https://unicelarchitectural.com/ai-governance-in-aec-building-trust-accountability-and-long-term-value/) 10. Tish Law, "AI Vendor Contract Clauses: Training Data, Confidentiality, Output Ownership, Human Review, and Indemnity" \(2025\)— [https://tish\.law/blog/ai\-vendor\-contract\-clauses\-training\-data\-confidentiality\-output\-ownership\-human\-review\-and\-indemnity/](https://tish.law/blog/ai-vendor-contract-clauses-training-data-confidentiality-output-ownership-human-review-and-indemnity/) 11. Ramsac, "The Unintended Consequences of Blocking AI at Work" \(2025\)— [https://www\.ramsac\.com/blog/the\-unintended\-consequences\-of\-blocking\-ai\-at\-work/](https://www.ramsac.com/blog/the-unintended-consequences-of-blocking-ai-at-work/) 12. Tech Business News, "Your AI Use Policy Is Probably Protecting Against The Wrong Risk" \(2025\)— [https://www\.techbusinessnews\.com\.au/your\-ai\-use\-policy\-is\-probably\-protecting\-against\-the\-wrong\-risk](https://www.techbusinessnews.com.au/your-ai-use-policy-is-probably-protecting-against-the-wrong-risk) 13. SMPS, "AI Governance Policy Standard Templates" \(2025\)— [https://onlinelearning\.smps\.org/products/ai\-governance\-policy\-standard\-templates](https://onlinelearning.smps.org/products/ai-governance-policy-standard-templates) 14. Partnership on AI, "Six AI Governance Priorities for 2026" \(2026\)— [https://partnershiponai\.org/resource/six\-ai\-governance\-priorities/](https://partnershiponai.org/resource/six-ai-governance-priorities/) 15. IAPP, "AI Assessments: How and When to Conduct Them" \(2025\)— [https://iapp\.org/news/a/ai\-assessments\-how\-and\-when\-to\-conduct\-them](https://iapp.org/news/a/ai-assessments-how-and-when-to-conduct-them) 16. Ethisphere, "AI Policy Is Not One Policy: How to Build AI Governance Employees Can Actually Use" \(2025\)— [https://ethisphere\.com/insights/ai\-policy\-ai\-governance\-compliance\-controls/](https://ethisphere.com/insights/ai-policy-ai-governance-compliance-controls/) 17. NeuralTrust, "The Complete Guide to AI Governance: Frameworks, Policies & Best Practices" \(2026\)— [https://neuraltrust\.ai/blog/ai\-governance\-complete\-guide](https://neuraltrust.ai/blog/ai-governance-complete-guide) --- **How we made this article:** We use AI in our research and writing so our small team can share more of what we learn. We verify the sources and take responsibility for every article we publish. [Read how we use AI.](https://dancumberlandlabs.com/how-we-use-ai/) --- ## About the author **Dan Cumberland** — Founder, Dan Cumberland Labs Dan Cumberland helps engineering and construction firms see where they stand with AI and decide what to build first. He created Pacemark, the AI maturity model behind that work, from research on more than 300 companies. - Take the assessment: https://pacemark.ai/signal/assessment/?track=aec&utm_source=dcl-site&utm_medium=link&utm_campaign=pacemark-assessment - Book a call: https://book.dancumberland.com/ai-strategy --- Source: https://dancumberlandlabs.com/blog/ai-policy-clauses-to-remove/