Cloud Capacity Crunch
Cloud infrastructure is having a moment — and not in a subtle way.
First, a data point from CIO Dive, citing new numbers from analyst firm Omdia: global spending on cloud infrastructure services hit $110.9 billion in Q4 of 2025, up 29% year over year. That’s not a niche uptick — that’s a step-change in demand. And the growth is showing up in the places you’d expect to be the beneficiaries: Omdia notes AWS revenue up 24%, Microsoft Azure up 39%, and Google Cloud up 50% in the same period. The reporting frames the vendor challenge as no longer simply “can we scale fast enough,” but scaling with discipline — and it flags something important: even with all that spending, data center construction rates fell for the first time in six years in the second half of 2025, constrained by power and electrical equipment availability. So you’ve got money pouring in, demand rising, and real-world constraints showing up in the buildout.
Now layer on a second signal from CRN, pulling from Synergy Research Group analysis and commentary from John Dinsdale, their chief analyst. The global data center capacity market is shifting hard toward hyperscalers. In 2018, enterprise on-prem data centers represented 56% of capacity. By the end of 2025, that was down to 32% — and Synergy projects it will fall to 19% by 2031. Meanwhile hyperscalers — think Amazon, Microsoft, Google — are already at 48% share as of late 2025, and Synergy says there are nearly 800 hyperscale data centers in the pipeline, with hyperscale capacity positioned to double in just three years.
For MSPs, that turns into a Tuesday-morning operations problem: the client expects AI to be available on demand, but the underlying capacity and cost profile may be far less elastic than the software experience suggests.
What this suggests is that cloud still looks elastic at the user layer, but underneath, the capacity that matters most for AI is becoming more concentrated, more physical, and harder to scale instantly.
And that matters for MSPs because the next wave of AI demand isn’t just more users hitting a chatbot—it’s longer-running workloads consuming finite infrastructure for longer periods of time.
Agentic AI Rises
The reason that infrastructure constraint matters is that AI work is shifting from short interactions to long-running execution—so demand is becoming harder to predict, govern, and price.
When AI tools were mostly “ask a question, get an answer,” you could treat them like software features. But now, the tools are being built around long-running execution — work that doesn’t happen in a single moment, and doesn’t stay neatly inside one application. VentureBeat reports that Z.ai’s new open-source GLM-5.1 model is designed to run autonomously for up to eight hours on a single task, pushing what they call “agentic engineering” — not just generating output, but iterating through steps and tool calls over time. That matters because an eight-hour task isn’t a prompt. It’s a process. And a process that runs for hours changes both the management burden and the infrastructure economics behind it. Processes need oversight, checkpoints, and someone — or something — to keep them from drifting.
And as this shifts from “AI as a feature” to “AI as a running system,” you can see the tooling adapting to the new reality. TechCrunch highlights Astropad’s Workbench, a remote desktop product positioned not for classic IT support, but for monitoring and managing AI. The problem is no longer “can we buy the tool,” it’s “can we keep the work coherent while it runs.”
And that’s the mechanism. These systems don’t just produce answers; they create persistent workloads that consume compute over time and create a management layer someone has to own.
Liability Shifts Down
The more AI becomes embedded in real workflows, the less the vendor will stand behind it—and the more the operator will be expected to absorb the mess.
Look at Microsoft’s own positioning around Copilot. TechCrunch flagged language in Microsoft’s terms of use that says Copilot is “for entertainment purposes only,” and explicitly warns users not to rely on it for important advice. They acknowledge it can make mistakes and may not work as intended, and that you use it at your own risk. Even if that phrasing gets softened later, the posture is the tell: when the system is wrong, the platform is already stepping back from accountability. And if your client is using these tools inside business processes, that accountability doesn’t disappear—it moves. It lands on whoever integrated it, operationalized it, and represented it as usable. That’s you.
Now, the exact terms vary by product, SKU, and contract, but the broader posture is what matters: vendors are making clear that use of the tool does not eliminate the customer’s obligation to review, govern, and own the outcome.
And then there’s the human side of what “operationalized” actually means day to day. The Next Web story frames a growing body of evidence that AI is not simply boosting productivity—it’s also driving cognitive overload. It points to a Boston Consulting Group finding that 14% of workers using AI tools reported significant mental fatigue, with entry-level workers showing higher burnout than executives. That’s not a philosophical debate. That’s the reality of adoption: someone has to verify outputs, juggle tools, manage exceptions, and keep work moving when the automation is “almost right.”
Put those two proof points together and the consequence is singular: as AI gets woven into operations, the cost of coherence—accuracy checks, guardrails, user workflow design, and responsibility for failure—shifts away from platforms and onto the operator. If you don’t explicitly productize that layer, you end up providing it for free. That means the MSP either productizes governance, monitoring, and accountability as a priced service—or absorbs those responsibilities as unpaid liability, because anything not explicitly scoped and billed will still be expected when the workflow fails.
Why Do We Care?
Because if MSPs treat AI as just another software feature, they’ll make three bad assumptions at once: that capacity will always be available, that the workload will stay lightweight, and that the vendor will stand behind the output. None of those assumptions hold. The result is underpriced service, weak contracts, and accountability landing on the provider closest to the client.
If they get that wrong, the result is predictable: bill shock, contract fights, and accountability landing on the provider closest to the client.
What to Consider
- Audit every AI tool deployment for vendor liability language before the next client renewal. Microsoft’s Copilot disclaimer is documented. If you’ve represented these tools as business-grade without a corresponding service wrapper, you have an exposure gap. Fix it in writing before a client incident forces the conversation.
- Build a constrained-capacity clause into cloud service agreements. Hyperscaler buildout is physically limited by power and equipment availability. Your SLAs should not promise performance outcomes you cannot guarantee when the underlying infrastructure is supply-constrained. Add force majeure or capacity-constraint language now.
- Evaluate hybrid and colocation positioning for regulated clients. The on-prem-to-hyperscaler migration story is real, but 32% of global capacity remains on-prem for reasons that won’t disappear. Clients in regulated industries are a natural hedge against full hyperscaler dependency — and a differentiation opportunity if you can articulate the risk clearly.
- Treat the eight-hour autonomous task model as a new service category trigger. Agentic workloads will require monitoring infrastructure, not just deployment. MSPs who develop an AI agent operations practice now — even a basic one — will have a defensible position when this becomes mainstream in 12 to 18 months.
If this trend continues, MSPs will have to implement AI runtime quotas and compute governance the way they already govern backup retention and security policy—because scarce capacity and vendor non-liability will make unmanaged AI usage financially and legally uninsurable.”