The Next MSP Evolution Is Managing Intelligence, Not Just Infrastructure

TL;DR

MSPs can build AI services by starting with their own internal use cases, then helping customers assess readiness, clean up data, set governance, and adopt AI in focused workflows. The opportunity extends beyond tool deployment to training, human review, and ongoing management.

Why customers need help managing AI

AI is already showing up in the tools businesses use every day. Employees are testing public chatbots, software vendors are adding AI features, and teams are experimenting with agents to speed up routine work. For customers, the question is shifting from “Should we use AI?” to “Who can help us use it well?”

That shift creates a practical opportunity for managed service providers. The work isn't simply choosing a product and switching it on. It means helping customers decide where AI can make a meaningful difference, prepare the data and systems it will rely on, set access and governance policies, train people, and keep deployments useful and accountable over time.

At Thrive 2026, AppDirect’s Mariane Louvet, director of ITCloud Provider Management, and David Gibson, general manager of managed services, joined Chris Bomberger, chief technology officer and chief architect at Higher Information Group, for a presentation and fireside chat about the shift to managed intelligence. The discussion paired a practical service framework with an honest look at AI adoption inside an MSP.

“You’ve got to learn how to adopt AI internally—how to make it part of your day-to-day—before you can guide customers through that change.”

— Mariane Louvet, director of provider management, AppDirect

This guide turns those ideas into a starting point for providers and technology companies that serve business customers: how to assess an opportunity, move from experimentation to governed use, and build services around the work customers will need after they choose an AI tool.

For many organizations, AI use is advancing faster than the policies and processes around it. People may already be using public tools, AI features embedded in SaaS products, or early agents built to handle specific tasks. They may not know what information is appropriate to share, who can approve an automated action, or how to check an AI-generated result.

That leaves customers with two understandable impulses: they don’t want to fall behind, and they don’t want to expose sensitive information or create new operational risks. In the session, participants described this as a mix of urgency and concern. Some customers want to move quickly; others have blocked AI altogether. Many are somewhere between those positions, trying to understand what’s safe and useful for their business.

Louvet framed the MSP’s role as helping customers embrace AI without overlooking the risks. AI tools are spreading faster than many businesses can govern them, but caution shouldn’t become inaction. Customers need to learn how to adopt AI internally and incorporate it into their day-to-day and MSPs can help customers move forward and build their own experience along the way. “They’ve got to learn to leave the past behind and start to use the new tools—or they’re going to get left behind.”

MSPs are well placed to help because customers already rely on them to make technology decisions, manage complex environments, and translate technical options into operational outcomes. AI adds new questions, but the advisory role is familiar. As Gibson put it during the discussion, AI is forcing MSPs to evolve while also giving them new ways to evolve.

The opportunity, then, is broader than reselling a license. Providers can help connect a growing collection of AI-enabled products and services into a workable operating model: who has access, what data can be used, how results are reviewed, and who maintains the system as needs change.

Start with the business problem, not the tool

A customer may arrive asking for “AI,” or jump straight to an agent. Before recommending a product, bring the conversation back to the work they want to improve.

A useful first discussion establishes:

• The process: What task or workflow is slow, repetitive, error-prone, or difficult to scale?

• The outcome: What should improve: turnaround time, consistency, quality, capacity, customer experience, or cost?

• The current baseline: How is the work done today, and what does that approach cost in time, effort, and risk?

• The people involved: Who owns the process, who will use the result, and who can approve changes?

• The constraints: What data, privacy, security, compliance, or contractual requirements apply?

This is the functional and financial evaluation described in the session. The question isn’t simply whether AI can perform a task. It’s whether applying AI is worthwhile compared with the status quo, and whether the proposed use can deliver a result the customer values.

That distinction matters. If a customer wants to improve a process, the right solution might be a built-in feature in software they already use, a governed workspace, a carefully scoped agent, or no AI at all. The provider’s value comes from helping the customer choose the right path, not from forcing every problem into a new tool.

For providers and companies distributing business solutions through B2B commerce, this is also a useful way to frame an offer. Connect the product to a specific customer outcome and explain what implementation, enablement, governance, and ongoing support are needed to realize it. A product listing can start the conversation, but a clear adoption path helps customers understand what success will take.

Build a foundation with data, access, and governance

AI systems are only as useful as the information and permissions they work with. If data is inaccurate, scattered, outdated, or more broadly accessible than it should be, adding AI can make existing problems harder to spot and contain.

Bomberger described data preparation as an early and substantial part of his organization’s own AI work. He said the team spent six to eight months cleaning and organizing data, including knowledge bases and runbooks, while testing systems and checking their outputs. That experience offers a useful reminder for providers: readiness work can be real project work, not a quick preflight step.

“If I don’t deploy a good data model, understand why, and know what I’m trying to solve before I start throwing AI at it, I can make the problem 100 times worse.”

—Chris Bomberger, CTO and Chief Architect, Higher Information Group [TBC]

A readiness assessment can examine:

• Where relevant data lives and who can access it

• Whether records, documentation, and knowledge bases are current and consistent

• Which AI tools or AI-enabled features are already in use

• How customer and business information is handled by each tool

• What security, compliance, and contractual obligations apply

• Which workflows are appropriate for an initial deployment

From there, governance should be made concrete. Define permitted use, data boundaries, roles, approval paths, logging or auditing expectations, and how exceptions are handled. Consider both the customer’s environment and the MSP’s own use of AI, including the customer information the provider holds or processes.

Governance also has to account for a mixed technology environment. Customers may use a general AI assistant, several SaaS products with embedded AI, and purpose-built tools for particular workflows. A policy that addresses only one application can leave important gaps elsewhere. Providers can help customers map this landscape and establish consistent controls across it.

The session’s deck describes governed workspaces as environments configured with access controls, data boundaries, and policy frameworks. The broader principle is to establish the rules before expanding access or connecting sensitive systems. In the transcript, the group discussed beginning with limited access and a small user group, and being deliberate about integrations such as CRM and email. That kind of staged approach can help a customer learn while keeping the initial scope manageable.

Move from crawl to walk to run

The session used a simple crawl, walk, run model to make AI adoption feel more manageable. It’s not a maturity test, and organizations won’t all move at the same speed. It’s a way to choose a sensible next step.

Crawl: Learn and test in a contained use case. Start with a task that has a clear owner, a measurable outcome, and limited risk. Examples discussed in the session materials included expense and credit-card reconciliation using locally hosted models, variance reporting, and improving the quality of professional responses. The goal is to learn how the tool behaves and where human checks are needed.

Walk: Apply AI to a defined workflow. Once the team has experience, it can consider more involved uses, such as support-desk agents with access to a knowledge base, proactive analysis of historical support data, or assistance with reviewing documents. Set boundaries for what the system can access and do. Test results against a known baseline, and make clear who is responsible for reviewing them.

Run: Operate and improve AI-supported processes. More advanced uses can involve agents that perform multiple steps or connect information across systems. The deck’s examples include a connectivity-analysis agent that prepares recommendations and AI-assisted comparisons of competitor proposals. These applications require a stronger operating model: monitoring, permissions, maintenance, cost management, incident handling, and regular performance reviews.

The model applies to the provider, too. Gibson’s advice was to understand a use case, start simply, and build from there. An MSP that has tried AI internally can speak from experience about the work involved, including the data preparation, policies, training, and review process. Internal practice also gives the team a chance to develop skills before guiding customers through similar decisions.

Six service areas MSPs can develop

The presentation outlined six categories that can form a practical managed AI services portfolio. They don’t have to be packaged as six separate offerings. Think of them as capabilities that can be combined around the customer’s goals and readiness.

1. Functional and financial evaluation. Identify the business driver, understand the current process, and compare the likely cost and value of an AI-supported approach with the status quo.

2. Readiness assessment. Review data, security posture, existing tools, and organizational needs. Use the findings to recommend a prioritized adoption roadmap.

3. Governed workspace setup. Configure the environment, permissions, data boundaries, and policies needed for a controlled deployment.

4. Professional development. Help employees understand how to use AI tools responsibly and effectively. Training should reflect people’s roles and the work they do, rather than stopping at a generic introduction.

5. Agent deployment and management. Implement agents for specific workflows, then maintain, monitor, and optimize them. This can turn a one-time deployment into an ongoing service relationship.

6. Ongoing optimization and compliance. Review usage, update policies, monitor performance and costs, and revisit controls as the customer’s needs and obligations change.

Together, these capabilities extend familiar MSP strengths. Providers already help customers plan, deploy, secure, and maintain technology. Managed intelligence adds AI-specific assessment, enablement, controls, and ongoing care to that work.

Make adoption and human review part of the service

A deployed tool doesn’t guarantee adoption. Customers may buy licenses, try a few prompts, and then stop because they don’t know how to apply AI to their real work. In the session, participants emphasized that customers need help moving beyond basic chat use and identifying a sensible next step.

That makes enablement part of the service, not a finishing touch. Work with customer leadership to identify a small group of champions, select workflows, set expectations, and provide role-based training. Check whether people are using the tool and whether it’s helping the process. If adoption stalls, ask whether the workflow, training, permissions, or tool choice needs to change.

Human review should also be designed into the workflow. Bomberger described his organization’s approach as having AI generate work that a person reviews before it leaves the company. That’s a useful model for outputs that affect customers, employees, financial decisions, or important business records. The specific review threshold will depend on the use case, but accountability should be explicit: who checks the output, what they check for, and what happens when it’s wrong or uncertain.

“We have a person review AI-generated work in-house before it goes out.”

—Chris Bomberger, CTO and Chief Architect, Higher Information Group

As deployments become more capable, providers can also help customers manage the ongoing work behind the scenes: data cleanup, policy updates, access changes, usage and cost reviews, system maintenance, and workflow improvements. That continuing work is where a provider can demonstrate value well beyond initial setup.

A practical first step for providers

If you’re deciding where to begin, choose one internal process that is frequent enough to evaluate and limited enough to manage. Define the problem and a baseline. Check the data and permissions. Decide what success would look like, who will review the output, and what conditions would make you stop or revise the test. Then run a small pilot and document what you learn.

Once your own team has worked through that cycle, you’ll have a more grounded conversation with customers. You can discuss what went well, what required preparation, where human judgment mattered, and what ongoing support the use case needs. That credibility is more valuable than presenting AI as an effortless fix.

For each customer, the right starting point will differ. Some may need an assessment and a plan; others may be ready for a narrow workflow pilot. The consistent sequence is to understand the business need, prepare the foundation, establish guardrails, start with a focused use case, and keep reviewing the results.

That’s the next evolution for MSPs: helping customers manage not only the infrastructure beneath their business, but also the intelligence being introduced into their workflows. The work calls for technical judgment, operational discipline, and human support. Providers that build those capabilities can help customers turn AI experimentation into a managed, useful part of how they work.

• Become an MSP Partner

• Why AppDirect for MSPs

• Access the MSP playbook today