I recently wrote that our own Control Gap report got the diagnosis right and the frame wrong. AI has spread through organizations faster than IT can account for, but calling it a control gap tells IT to buy a gate when it needs a road. The honest version is an enablement gap: people route around you when going through you is slower than going around.
The argument targeted internal IT teams. For MSPs, it changes shape, because the estate isn't yours and the exposure is contractual.
A client buying AI without you is a commercial event
When an internal IT team discovers shadow AI, it's an inventory problem. When you discover it in a client environment, something else has happened. A client made a technology decision and didn't call you.
That's the part worth sitting with. You were hired to be the technology function for that business. If a department head bought an AI platform, wired it into a system you manage and you found out afterward, then for that decision you weren't the technology function. Someone else was, or nobody was.
It rarely arrives as a dramatic event. It shows up as a client asking you to "just connect" something you've never seen, or a workflow that depends on a tool that never came up in a QBR. But the trajectory should worry you: the fastest-growing category of spend in your clients' businesses is moving through channels you aren't in.
You can respond to that by trying to lock it down, which confirms to the client that going around you was the right call. Or you can treat it as a signal that your intake was too slow, your answer was too often no and the AI conversation started somewhere you weren't in the room.
The second estate is your own shop
The report didn't cover this, and for an MSP it’s probably the more urgent half.
Your technicians have the same incentives as your clients' employees. A tech with a stubborn script, a log dump they can't parse, or forty tickets to summarize before end of day will reach for whatever tool makes that faster. Frequently that's a consumer LLM account, and what goes into it is client configuration data, log output, credentials embedded in a config file, or personal data belonging to a client's customers.
The difference between this and ordinary shadow AI is custody. When an internal IT team leaks its own company's data, the company has harmed itself. When your technician pastes a client's data into a consumer AI service, you have moved data you hold under contract, on behalf of a named counterparty, into a third party neither of you has assessed.
Most MSPs have no written position on this, no tooling that would detect it, and no way to answer the question if a client asks. That's a governance gap sitting directly on your liability, and you can close it without anyone's permission but your own.
Where control genuinely is the right word
I argued that the control reflex is mostly a liability. For MSPs, the exception is sharper and easier to name than it is for internal IT, because it's written down.
You've signed things. An MSA with defined scope and defined data handling. A BAA, if you touch healthcare. Compliance attestations made on a client's behalf. And a cyber policy that comes up for renewal every year. If that renewal questionnaire asked you what AI tooling was running across the environments you manage, could you answer it? In writing, under a policy that pays out based on what you put down?
Inside that boundary, saying no isn't gatekeeping. It's the contract. The distinction is that you should know exactly where the boundary sits and be able to explain it, rather than defaulting to refusal for anything unfamiliar.
Where the service line actually is
The most interesting number in our survey was the one about human approval. Around 72% of respondents want a person to sign off before patches reach production. We read that as a trust deficit.
It isn't. We've pushed patches automatically for twenty years. Nobody holds that gate because they doubt the tooling can reach the endpoint. They hold it because the mechanics were never the hard part. What does this patch touch? What breaks if a dependency isn't there? Does it need downtime, and can that downtime land where the business won't feel it? Now multiply that by every environment you manage.
Which is where the opportunity sits, and it isn't autonomy. It's decision support: assembling advisories, dependency state, configuration detail, change calendars and client business context in one place so the person with the authority makes a better call than they could yesterday. Autonomy on reversible, low-consequence work is already fine and already happening. For irreversible work, better human decisions are the prize and clients will pay for it because they can see it protecting them.
What to do about it
Get into the AI conversation before the purchase, not after the integration request. That means having an answer ready when a client asks about AI, rather than needing two weeks to come up with one.
Write your own internal AI policy before a client asks you for it. What tools are approved, what client data may never leave your tenancy, what happens when a tech needs something faster than your process allows. Then build a path that's fast enough that they don't need to route around it.
Build visibility across client estates, and be clear with yourself about why. Not so you can say no faster. So you can support, price and improve what's actually running — and so you can answer the insurance questionnaire.
And be wary of maturity as a goal. You can run a well-run shop, hit every SLA and still be the provider whose clients are quietly making their most consequential technology decisions without you. If that's happening, the scorecard is measuring the wrong thing.
Access the full report here
