The pitch version of AI in managed services sounds like efficiency, automation, competitive advantage. The reality I see day to day is something closer to this: tools getting deployed before anyone has defined the problem they're solving, outputs being accepted without the context to evaluate them, and clients being pushed toward a yes-or-no relationship with technology that deserves a more nuanced conversation.
AI is replacing thinking way too often instead of enhancing it.
That's the part nobody in the sales cycle wants to say.
Here's a concrete example of what I mean. Standards assessments can be largely automated. You can pull stale accounts, identify missing MFA enforcement, and flag outdated configurations. APIs will surface most of that data faster than any human can. On paper that sounds like a win.
The problem is that data without context isn't useful, and in some cases it's actively misleading.
When my team runs manual discovery on a client environment, we're not just gathering data. We're learning the history. Why does this account still exist? Why is this server configured this way? Is this application actually in use or has it been dormant for two years while still running in the background? The answers to those questions don't live in an API. They live in conversations, in documentation that may or may not be current, in the institutional knowledge of whoever built the environment and what they were solving for at the time.
The tasks I'd hand to AI without hesitation: stale account enumeration, MFA gap reports, bandwidth utilization summaries, patch compliance snapshots. The tasks I keep under human oversight: server role mapping, application dependency analysis, anything where the question isn't "does this exist" but "why does this exist and what breaks if we touch it."
That's not a philosophical position. It's a practical one. When we get those two categories confused, the roadmaps we build have gaps in them, and the gaps show up six months later as client problems we didn't anticipate.
On the client side, I deal with two types. The ones who are afraid of AI usually just need it scoped. "AI" as a concept is enormous and abstract, and it's easy to imagine it touching things it has no business touching. When I can show a client specifically what we're automating, what we're not, and what safety nets exist around the parts we are, the conversation shifts from fear to curiosity pretty quickly.
The ones who trust AI too much are a harder conversation, because they usually got there through a sales pitch that didn't include the failure cases. There are real-world examples of AI deployments going wrong, systems making confident decisions based on incomplete information, outputs that sound authoritative and turn out to be wrong, integrations that created more problems than they solved. I use those examples not to scare clients away from AI but to calibrate their expectations to something realistic.
Both conversations end up in the same place: policy before tools.
Figure out what you're comfortable letting AI touch in your environment. Define where human review is required before anything moves forward. Decide what data AI can access and what stays off limits. Build those guardrails before you deploy anything, not after.
Most organizations do it backwards. They deploy the tool, then figure out the policy when something goes wrong. That's not an AI problem. That's the same sequencing mistake that breaks technology rollouts in every category. The tool doesn't create the problem. The absence of a framework around the tool does.
AI is genuinely useful. We use it to strengthen original ideas, expand on where to go next, and catch things human review misses. The combination of human judgment and AI analysis consistently gets us further than either one alone.
But "we use AI" isn't a strategy. And "we don't use AI" isn't a defense.
The strategy is knowing exactly where each one belongs.