Most MSPs are already experimenting with AI in some form, and every vendor at every conference has an AI for MSPs pitch ready. Few have stopped to check whether their own operations are solid enough to scale. Our 2026 IT Trends Report found that three-quarters of IT leaders believe they have an AI policy, while fewer than half of help desk staff agree.
That’s the real risk: AI doesn’t fix drift, unclear ownership, or gaps between what’s documented and what’s actually happening. It scales them, quickly and with total confidence.
Key takeaways:
- AI amplifies whatever operational reality you feed it. If your processes have quietly drifted from what’s documented, AI will scale that drift with total confidence.
- Profiting from AI isn’t a race to package it for clients. It starts with observing your own operations honestly, building structure around experimentation, and assigning real ownership.
- As AI-generated content becomes the norm, authenticity, not polish, is what will set your MSP apart. That applies to your writing and to how you show up for clients.
This post draws on insights from three issues of Amanda Doucette-Lachapelle’s Frankly IT newsletters: “AI Will Scale Your IT Blind Spots,” “So Wait, When Can We Start to Profit From AI??,” and “Unslop Your AI.”
Where the problem starts: Your documentation, what you enforce, and what your team actually does are probably not all the same
Most MSPs hit a point where things stop feeling chaotic. Dashboards populate, reports go out on time, SOPs look solid when you open them, and nothing is obviously on fire. It’s easy to start trusting that system, and just as easy to stop checking reality quite as often.
That’s what creates compounded drift. A process gets built with good intentions, then the team around it changes: people move roles, new hires come in, responsibilities shift. The people running the process today weren’t there when it was created, so they don’t know the context or the tradeoffs behind it. They adjust it in small, reasonable ways to fit how things work now. None of that is wrong in isolation. Over time, though, it adds up to a gap between what’s documented and what’s actually happening.
The result is three versions of the same business running at once:
- The documented system you’d proudly show someone
- The enforced system your tools are trying to maintain
- The lived system your team is actually operating in every day
They’re rarely identical, and the gap between them doesn’t announce itself. It just shows up as quiet variation.
Where the problem grows: AI scales whatever system you hand it, blind spots included
If you’ve rolled out AI and your operations don’t feel measurably better, this is usually why. Drift used to be self-limiting: slow, inconsistent, easy to miss in the moment. This is where AI changes the stakes, because it removes that natural ceiling. As Amanda put it in her post, “AI will scale whatever system you give it, whether it’s tightly aligned or slightly off.”
It doesn’t question the process it’s handed or challenge assumptions. It just executes, consistently and confidently, whatever version of “truth” is baked into your operations. If your foundation is solid, that consistency is a huge advantage. If it’s shaky, AI won’t fix it quietly in the background. It will multiply it faster and with more confidence than any team could on its own.
The instinct here is to fix this with more documentation… tighter enforcement, more rigid systems, etc.. That instinct makes sense, but it misses something. A system can walk someone through the steps. It can even prevent certain mistakes. But it can’t explain why those steps exist in the first place, and it can’t tell team members what problems they were originally built to solve.
That’s why Amanda frames issues with scaling AI as a culture problem before it’s a process problem. To be clear, this doesn’t mean you need to build a “documentation culture” in the sense of writing more things down, but a culture where the documentation and the automation are actually understood, not just followed. In other words, the difference between a technician who knows a step exists and one who knows why it exists – or, more broadly, the difference between a team that drifts quietly and one that catches drift early.
A culture where, if someone notices that a documented process doesn’t feel true anymore, that’s treated as a signal worth investigating. Once that culture is in place, scaling AI actually becomes possible.
Most MSPs and IT teams are approaching AI adoption in the wrong order
Ask ten MSPs how they’re rolling out AI and you’ll hear a familiar sequence:
- Buy tools
- Experiment aggressively
- Try to package AI into client-facing services
- Figure out governance later
- Hope profit follows
Amanda’s take is that this order is backward, and that AI readiness starts somewhere other than the tool stack.
Of course, the pull to externalize quickly makes sense. There’s real demand for AI consulting, readiness assessments, governance advice, and AI-enhanced service offerings. But underneath that pressure, a lot of teams are still working through the basics internally: tool sprawl across half a dozen AI subscriptions, unclear data handling boundaries, prompts shared informally in chat, and outputs that aren’t consistently checked.
Add to that the fact that you’re trying to guide clients through a level of maturity your own team hasn’t reached yet, and reputational risk starts to creep in. This is especially true when AI touches more than a typical software rollout: service desk workflows, documentation, security, onboarding, and even how junior staff learn to think through problems.
How to implement AI in an MSP: observation and containment before automation
Amanda lays out a more deliberate sequence for building AI maturity internally before turning it outward:
- Observe for operational consistency before you automate: AI exposes operational inconsistency fast, so it’s worth finding those gaps yourself first. Where does ticket triage look a little different depending on who picks it up? Where does documentation exist that isn’t actually trusted? Where has a team quietly built its own workflow underneath the official one?
- Build a containment layer, not just a policy document: The goal isn’t to stop experimentation, it’s to make it observable. That means guardrails: approved platforms, acceptable data handling, human review expectations, validation requirements, and escalation paths. Without them, shadow AI quietly becomes your entire AI strategy (and most teams underestimate how much of it is already running).
- Assign real AI operational ownership: Someone needs to own approved tooling, prompt standards, validation, vendor review, training, and what happens when an AI output is wrong. As Amanda puts it, “If nobody owns it, then operationally everyone owns it, which usually means nobody truly does.”
AI in IT operations should mean fewer rough edges, not just faster output
Most AIOps conversations right now are still stuck on novelty metrics: how fast something summarized a ticket, how much time a workflow saved. Those gains can be real, but they aren’t the same as maturity.
The better questions according to Amanda, are:
- Has consistency improved?
- Is onboarding easier?
- Are escalations cleaner?
- Are documentation adherence and rework moving in the right direction?
- Did ticket volume drop, or did it just move somewhere less visible?
Speed without consistency just creates operational debt you’ll have to untangle later.
The MSPs and IT teams likely to come out ahead aren’t necessarily the ones who adopted AI fastest. They’re the ones who stabilized operations first, standardized intentionally, built governance early, and kept human judgment in the loop while everyone else was racing to demo the newest feature.
Auvik AI is built on the same idea: ground it in what is real
Whatever you scale next should be grounded in what’s actually happening in your operations, not assumptions about what should be happening. With Auvik AI, powered by Aurora, we’ve taken our own advice to heart.
Instead of generic answers pulled from the public internet, Auvik AI grounds its troubleshooting and alerting guidance in your actual network data: topology, device relationships, performance metrics, alert history, and vulnerability feeds, all built on 15 years of real-world IT data.
Instead of adding to alert fatigue, Auvik AI:
- Surfaces the alerts that actually matter
- Recommends next steps specific to your environment
- Flags aging or vulnerable hardware before it causes an outage
It’s built around technicians, not instead of them. Auvik AI surfaces likely root causes as hypotheses, not verdicts, and every recommended action still needs a human in the loop to review and approve before it runs, with an audit trail of what was recommended and who signed off. What changes is how much routine troubleshooting stands between your team and the harder problems. Technicians can now spend less time chasing false positives and more time on the escalations and edge cases that actually need their expertise. Those are the judgment calls that build real operational maturity over time.
Go find your drift. Then let’s talk.
Pick one workflow you’d swear is standardized, and go look at how three different technicians actually ran it this week. Whatever gap you find is the thing AI would have scaled for you.
As Amanda puts it: “Use AI. Seriously. But use it well.”
When you’re ready to see what that looks like grounded in your own network, book a demo with Auvik and judge it against what you found.
Book an Auvik demo
See how Auvik simplifies network management in a live, guided demo.
