Shadow AI in SaaS Apps: MSP Client Governance Guide

Your client has a policy: no AI. No ChatGPT, no Copilot, no generative tools of any kind. You documented it, they signed off on it, and everyone moved on. The problem is that policy was out of date the moment the ink dried.

AI did not wait for an invitation. It arrived through the SaaS tools your clients already pay for, embedded in the productivity suites they use every day, tucked inside browser assistants and CRM update prompts and customer support widgets. Notion is summarizing notes. Salesforce is drafting emails. Zoom is transcribing and analyzing calls. None of this required a purchase order or an IT ticket. It just showed up.

This is the shadow AI problem, and it puts MSPs in a genuinely difficult position. You cannot enforce a policy against something your clients cannot see. And if you are not actively tracking which SaaS tools have AI features enabled by default, what data those features train on, and whether admins can actually turn them off, you are governing a gap you have not yet mapped.

Why a "No AI" Policy Is No Longer Enforceable

There was a time when blocking AI meant blocking a handful of consumer tools. You could put ChatGPT on a deny list, restrict certain browser extensions, and call it a governance posture. That approach is functionally broken now.

Major SaaS vendors have spent the last two years embedding AI capabilities directly into their core products. Microsoft 365 Copilot, Google Workspace's Duet AI, HubSpot's AI content tools, Zendesk's intelligent triage, Intercom's AI agent features. These are not add-ons your clients opted into consciously. Many are enabled by default with existing licensing tiers, or rolled out through product updates that do not require administrator approval.

When AI is a feature of a tool your client already uses and trusts, the psychology shifts. Employees do not think of themselves as violating policy when they click a button that was already there. They think they are just using the software. A blanket prohibition does not account for this reality, and it does not give your clients any guidance about which risks are actually worth worrying about.

The practical result is that a "no AI" policy creates a false sense of security. Clients believe they are protected. You believe the policy is being followed. Meanwhile, AI is operating across their stack, possibly training on client data, customer communications, or regulated information, and no one is watching.

What Shadow AI in SaaS Actually Looks Like

Shadow AI is not always someone sneaking ChatGPT past the firewall. In most MSP client environments right now, shadow AI looks like this:

• A project management tool auto-generating task summaries using content from project files
• A customer success platform using conversation data to train its own AI models, with that behavior enabled by default
• A browser with a built-in AI assistant that can read and summarize the contents of any page the user visits, including internal tools
• A recruiting platform using AI to score candidates based on historical hiring data that may contain protected class information
• A video conferencing tool storing AI-generated transcripts and meeting intelligence in a vendor-managed environment

None of these require a separate AI purchase. All of them involve data leaving the client's direct control in some form. Some of them have administrator controls that can limit or disable the behavior. Many do not.

The challenge is that this picture looks different for every SaaS application in your clients' stacks. There is no universal AI governance setting. Every vendor makes different choices about defaults, data usage, training consent, and administrative control.

The Governance Gap MSPs Need to Close

If you accept that shadow AI is already present in your clients' environments, the question shifts from "how do we prevent AI" to "how do we govern AI that is already here.

That governance work has four components:

1. Visibility. You need to know which SaaS tools in your clients' stacks have AI features, which are enabled by default, and which involve data processing that may affect compliance posture. You cannot make good decisions without this inventory.
2. Data behavior mapping. For each AI-enabled feature, you need to understand what data it processes, where that data goes, whether the vendor trains on it, and what the data retention posture looks like. This is especially critical for clients in regulated industries like healthcare, finance, or legal services.
3. Administrative control assessment. Many SaaS vendors offer administrator controls that let you disable AI features, opt out of data training, or restrict feature access to specific user groups. You need to know which tools offer these controls and whether they are currently configured correctly.
4. Policy alignment. Once you have visibility into what AI is actually doing, you can help clients build policies that reflect reality: which AI uses are acceptable, which require review, and which are genuinely off-limits given their regulatory environment.

This is not a one-time audit. SaaS vendors are shipping AI features continuously. The governance posture you establish today needs a mechanism to stay current as the landscape changes.

How MSPs Can Build a Scalable AI Governance Practice

The opportunity here is real. Most of your clients do not have the internal expertise to evaluate AI risk across their SaaS stacks on their own. They are not reading vendor documentation about model training terms or checking release notes for AI feature rollouts. That is work they need help with, and it is work MSPs are positioned to do.

Building a scalable AI governance practice starts with standardizing your own methodology. That means having a consistent framework for evaluating AI features in SaaS applications, a reference source for vendor AI behavior, and a way to communicate findings to clients in terms they can act on.

The MSPs who will do this well are the ones who treat AI governance as a service offering rather than a one-off conversation. That means incorporating AI feature review into onboarding assessments, adding it to your regular security and compliance touchpoints, and creating the documentation that lets clients see their actual exposure.

It also means being honest with clients about what is controllable and what is not. Some AI features cannot be disabled. Some vendor data practices are non-negotiable. Part of your value is helping clients understand where the real risk sits and make informed decisions about which tools they continue to use.

a

Conclusion

The clients who asked you to keep AI out of their environments were not wrong to have concerns. Those concerns are legitimate, and they deserve a real response. The response that actually protects them is not a blanket prohibition that gets bypassed by every SaaS product update. It is a governance posture that accounts for the AI that is already there.

Your role as their MSP is to give them an accurate picture of their current exposure and a practical path to managing it. That work starts with knowing what AI is doing inside the tools they already use, and that requires a systematic way to track vendor AI behavior across a client's full SaaS stack.

Atlas is Lemhi's reference database for exactly that work. It documents the AI posture of 176-plus SaaS applications in plain English: whether the tool trains on your data by default, whether admins can disable it, whether an opt-out exists. Before a client asks what their software has been doing with their data, you should already know the answer. Atlas is free and open.