Every MSP that manages security for SMB clients is now fielding client AI requests, and they all sound like the call that comes in on a Tuesday: your client’s CEO watched a demo over the weekend, and by Friday she wants the whole team on an AI notetaker that will sit in every meeting, including the ones about payroll, layoffs, and the lawsuit. You are the provider responsible for her security posture. Everything you know about the tool’s data handling says this is a problem, and everything you know about the account says a flat refusal will cost you standing you’ve spent years building.
The request won’t actually go away either, it will just stop going through you. The way out of that corner is empowering your SMB clients with an AI governance process. The service providers and vCISOs who keep accounts through these disagreements have one ready before the phone rings.
Why a Flat No Fails With Client AI Requests
Start with what the refusal actually buys you. When Cynomi surveyed the questions MSPs are asking each other for its report on what MSPs are actually asking about AI, this exact dilemma surfaced as the number-one burning question, and the community’s field experience was blunt: outright banning tools such as ChatGPT or Claude drives usage underground. The employees who wanted the tool keep using it on personal accounts, the sensitive data flows anyway, and you lose the visibility you were trying to protect. The refusal also repositions you. David Primor, Cynomi’s CEO and Co-Founder, puts the alternative simply: “The companies that win with AI are not the ones that say no the most, they are the ones that help customers achieve their goals safely and responsibly.”
Your clients are uneasy about this from their side too. Among SMBs, 83% say AI raises their threat level, yet only 51% have implemented any security policy for AI use. The anxiety is real and the rulebook rarely exists yet. That gap is your opening: the provider who writes the rulebook becomes the advisor, and the provider who just says no becomes the obstacle the client learns to route around.
Ask What the Client Needs From the AI Tool
Your first step is discovery, because nearly every risky AI request is a business outcome wearing a product name. Andrew Morgan, founder of the security community Right of Boom, handles the moment with curiosity instead of judgment: “That’s really interesting… what are you trying to accomplish? What inspired this idea? If you could have the perfect outcome, what would it look like?” In his experience, “Nine times out of ten, those three questions surface the real business outcome.”
The discovery step matters because the request is often not the requirement. The CEO who wants the meeting notetaker actually wants decisions documented and action items assigned without an admin in every call. Once the outcome is on the table, you have room to solve it with a tool you can stand behind, and Primor’s advice applies: if you already have a solution that addresses the need, adapt it to the client’s use case rather than explaining why the original request is impossible. If you don’t, you’ve just received free product feedback about where your service catalog is headed.
Thomas Bergman, a practicing vCISO at Proven IT, takes the same step further into delivery: anchor the conversation to a specific business process, then demonstrate value on it. “Once value is established through a targeted demo, the client is far more likely to invest in the required controls, which, in turn, represents incremental revenue for the MSP.” Read that twice, because it reverses the usual assumption: the security controls that make the tool safe are billable advisory work, and the request you almost refused becomes an engagement.
Evaluate AI Tools Against Fixed Security Criteria
The second step is where your qualified yes gets its substance. Put every requested tool through the same evaluation, visibly, so the answer is never personal and never arbitrary. The criteria that matter for SMB environments fit on one list:
- Data handling: where data is stored, whether prompts and files are used for model training, and what the retention and deletion terms say
- Identity and access scope: what the tool requests against Microsoft 365 or Google Workspace, and whether it wants tenant-wide permissions to do a narrow job
- Regulatory and contractual fit: whether the client’s industry rules or customer contracts restrict sharing data with third-party AI services
- Vendor standing: security attestations, breach history, and whether the company is mature enough to still exist next year
- Operational fit: whether your team can support, monitor, and audit it, or whether it becomes a one-off outside your standard stack
Time-box the review, because speed is part of its credibility. Against fixed criteria, a standard evaluation takes days, and the client should hear the timeline when they hear the process: “We conduct a standard AI risk review on anything that touches your environment. You will have a recommendation this week.” A process that reads as stalling is just a slower no, and the client who wanted the tool by Friday will treat it that way.
The criteria also solve a quieter problem: your team doesn’t need deep AI expertise to apply them. The questions about data training, permission scope, and retention terms are answerable from the vendor’s own documentation in an afternoon, which means a capable generalist can conduct the review by checklist while your senior people stay reserved for the judgment calls the checklist surfaces.
Land on One of Four AI Request Outcomes
The third step is the decision itself. A credible process has to produce more than one answer, and the client should know the possible outcomes before the review starts. Four cover the territory:
| Outcome | What the client hears |
|---|---|
| Approved | “It passed. It goes on your approved list, and here is how we will roll it out.” |
| Approved with conditions | “Yes, with the business plan, SSO, and these data rules. Here is what that costs and protects.” |
| Safer equivalent | “This tool fails on data handling, but here is the approved tool that gets you the same outcome.” |
| Not yet, with reasons | “Here is exactly what failed and what would change our recommendation.” |
The fourth outcome is where Don Monistere, CEO of General Informatics, has changed the conversation entirely. His team built a sandbox to test agentic AI deployments before client conversations, so the risk discussion runs on evidence instead of authority: “I’m not telling you no. I’m showing you what the risk is. If you want to take it, that’s on you. But my responsibility is to show you how these decisions impact your overall risk posture.” The client keeps their autonomy, you keep your advisor standing, and the account survives the disagreement regardless of which way the decision goes.
Notice what the outcome table does to the “MSPs just block everything” objection: if your approved list never grows, your process is a blocking ritual with extra steps. The list has to visibly produce yes-outcomes to keep its authority.
Build the Approved AI Tools List and the Acceptable Use Policy
A good conversation evaporates unless you land it in two documents the client’s whole team can follow. The first is the approved AI tools list: which tools are cleared, at which subscription tier (business plans with training opt-outs, never personal accounts), for which kinds of work. Treat it as a living instrument with a review cadence, because the categories and criteria age far more slowly than the tools do, and a quarterly refresh keeps you ahead of the next Tuesday call. The maintenance burden worries providers more than it should: you’re not re-evaluating the whole AI market each quarter, you’re reviewing the handful of new requests your clients made, checking whether anything on the list changed its data terms, and retiring what nobody adopted.
The second is an AI acceptable use policy (AUP) written for the client’s employees rather than their auditor. Short enough to be read, concrete enough to be followed:
- Scope: who the policy covers and which tools it governs
- Approved tools and tiers: the list, and how to request an addition
- Data rules: what never goes into a prompt, in plain categories their staff recognize (client records, financials, personnel matters, and anything under NDA)
- Verification: where human review is required before AI output ships or executes
- Incident path: what to do the moment someone realizes the wrong data went in
Between them, the list and the policy convert your judgment into the client’s operating rules, which is the difference between being consulted once and governing the relationship. This is also the layer where the strategy work you may already be doing, from proactive AI risk management down to per-client guardrails, becomes something an employee can actually follow on a Wednesday afternoon.
The AI Request You Almost Refused Is a Governance Service Line
Add up what the process produces: discovery conversations that surface business outcomes, a repeatable evaluation, a governed toolset, a client-specific policy, and periodic reviews as the tools churn. The sum is an advisory engagement with a monthly rhythm and monthly recurring revenue to match, and practices are already packaging it that way, turning AI governance into a revenue engine rather than absorbing it as unbilled friction. The request you almost refused was the entry point.
Delivering that engagement across a whole client base is where structure pays. Cynomi’s Security Growth Platform provides the rails: your team assesses each client’s posture, generates the policies from a common baseline, tracks the rollout tasks, and keeps the whole thing current per client without rebuilding it from scratch each time. The framework above is the conversation; the platform is how your team delivers it at every client, at every maturity level, without the senior person writing every report by hand.
The next Tuesday call is coming, and the tool will be one neither of you has heard of yet. Have the process ready before the phone rings: run a security posture assessment that includes AI use, stand up the approved list and the policy, and walk in as the advisor with a path instead of the vendor with a no. At Cynomi, we carry the complexity, so you can lead the conversation.
Table of contents
