How MSPs Should Govern Client AI Adoption

More than 80% of employees are already using AI tools their company has not approved. Before you have that governance conversation with a client, their employees have already made the decision for you.

That is the cold hard truth MSPs are working with in 2026. The question is not whether your clients’ employees are using AI. They are. The question is whether you are in the conversation that shapes how they use it, or whether you find out about the exposure after something goes wrong.

The MSPs losing this conversation are treating it as a security problem when their clients are framing it as a productivity question. Saying no to an AI request, or responding with a policy document, repositions the MSP as a gatekeeper rather than an advisor. It also does not work. 68% of enterprise employees used unauthorized AI tools as of early 2026, up from 41% in 2023. Shadow AI adoption does not slow down when IT says no.

What works is a posture that gives clients a path forward while managing the risks the MSP is responsible for.

What Shadow AI Is Actually Costing Your Clients

When a client thinks shadow AI is low-stakes, three numbers move the conversation.

48% of employees have entered non-public company information into AI tools without employer guidance. That includes customer data, internal financials, legal documents, and personnel records. The exposure is concrete: one in five organizations has experienced a security breach linked to shadow AI.

The governance gap is equally clear on the policy side: only 18% of organizations have a formal AI security policy. Your clients almost certainly do not have one. The tools arrived faster than governance frameworks could catch up, and that gap is the opening.

Clients are not asking for an enterprise AI governance program. They want someone to help them figure out what is safe to use and what is not. That is an advisory conversation.

Why Saying No Does Not Work

The r/MSP community’s most-commented thread on client AI governance in the past year came to a clear consensus: “You can’t say no to AI and you shouldn’t try.” Don Monistere, CEO General Informatics,featured in Cynomi’s MSP security research, put it more precisely: “I’m not telling you no. I’m showing you what the risk is. If you want to take it, that’s on you.”

That framing matters because it repositions the MSP’s role. You are not the barrier between the client and a tool they want to use. You are the advisor who helps them understand what they are taking on and how to take it on safely. That shift keeps the MSP in the conversation rather than outside it.

For clients who have already deployed tools without telling you, that posture also makes the disclosure conversation easier. If they know the outcome of coming to you is “here is how we manage this” rather than “shut it down,” they will tell you what they are using.

The Four-Step MSP AI Governance Posture

The framework that works for MSPs is an operating posture: four steps that can be applied across a client base, adapted to each client’s tooling and risk profile, and delivered as an ongoing advisory service.

Step 1: Discover what is already in use

Do not start with a policy. Start with a discovery conversation. What tools are employees using? What data is going into them? Which teams have adopted AI workflows, even informally?

This step is deliberately non-threatening. You are building a map of current AI usage across the client’s environment before you make any recommendations. What you find will almost always include tools the client did not know were in use. The compliance pressure on SMB clients is expanding; the discovery step is where you surface the regulatory exposure in concrete terms.

Step 2: Define an approved lane

Once you know what the client is using, recommend an approved alternative that meets the same productivity need with lower exposure. For most SMB clients, this means a clear answer to: “What AI tools are we allowed to use, and for what?”

The approved lane does two things. It gives employees a path forward. It also creates a service line: the MSP becomes the provider of the approved AI stack and a named advisory layer on top of it. Roy Azoulay, Co-Founder and COO of Cynomi, describes this as the difference between being the “department of no” and being the advisor who helps clients “use AI responsibly and competitively.” The compliance-backed security services that follow from a defined approved lane are where the recurring revenue sits.

Keep the approved list short. Two or three tools with clear use-case guidance work better than a comprehensive policy that nobody reads.

Step 3: Deploy technical controls at the point of risk

This is the layer the MSP can actually control, regardless of what the client decides to do with the approved lane. Controls at the point of risk include:

• Data loss prevention (DLP) at the browser or endpoint level, configured to flag or block uploads of sensitive data types to AI tools
• DNS filtering that can block categories of AI services for specific user groups
• Email and file attachment controls that limit what can be shared with external AI platforms
• Identity and access scoping that limits which employees have access to AI tools with elevated permissions

These controls enforce the risk boundary at the technical level without requiring the client to change their behavior. They are also within the MSP’s standard scope of work, which means they can be delivered without a separate governance engagement.

For clients who are running any HIPAA-covered workflows, the technical controls layer is where the Business Associate Agreement (BAA) question surfaces. Most AI tool vendors will not sign a BAA. That limits what can go into them, and the DLP controls are what enforce that limit in practice.

Step 4: Train at the moment of behavior

Annual security awareness training does not change AI usage habits. The moment of risk is when an employee is about to paste client data into a prompt. Training that lands at that moment has to be in-context.

Practical options include:

• Browser-level warnings triggered when an employee accesses an AI tool (a notification, not a block, that reminds them of what cannot go in)
• Short, role-specific guidance on what data types are off-limits in AI tools, delivered in the onboarding flow for the approved toolset
• Escalation prompts for edge cases (“I need to analyze this contract — what can I use?”) that get the employee into a supported workflow rather than an unsanctioned one

The goal is a clear enough mental model that the safe path is also the easy path.

What This Posture Looks Like in Practice

The four steps above are sequential but not rigid. A client who has already had a data incident will move through them faster. A client who is just starting to ask questions may need step one to take several conversations.

The table below maps common client scenarios to where the posture starts:

The MSP’s advantage is the same across all scenarios: visibility into the technical environment, a relationship with the client’s leadership, and the ability to move faster than an internal IT team can. The governance conversation is where you use all three.

Starting the Conversation

Open with a question before reaching for data or a framework: “Do you know what AI tools your employees are using today?”

Most clients do not, and that gap is the entry point. From there, the discovery step follows naturally. The approved lane and technical controls follow from discovery. And the training step becomes part of the normal security awareness conversation you are already having. This posture layers onto the advisory relationship you have already built.

The MSPs who are winning client AI governance conversations are the ones who arrived with a framework before the client had a problem. Cynomi’s Security Growth Platform gives MSPs the structure to deliver that advisory support across every client, at every maturity level. Request a demo to see how this AI governance workflow fits into your practice.