The Changing Cloud Forecast

A Pattern I’ve Seen Before

I was working professionally when the cloud became a thing. From that vantage I saw initial adoption: the excitement, the flexibility, the sense that everything was going to move faster. This led to massive adoption, where every workload was a candidate and every vendor had a cloud story.

Adoption, though, was only the first half of what I watched. Then I saw the other side of it: repatriation. Companies moving specific workloads back, asking whether every application really needed cloud flexibility. That second move happened for a reason. With economic shifts and workload maturity, the assumptions that made cloud the obvious choice for literally everything stopped holding up once organizations started examining them at scale.

Having lived the full arc once, I recognize its shape when it starts forming again. Now, as I help companies sort out what AI should actually be doing in their environments, the massive adoption/repatriation pattern is starting to look familiar.

The Cloud Correction

To see why the resemblance matters, it helps to start with what actually happened to cloud, on its own terms. The move to cloud was rational. It removed friction, gave organizations flexibility and speed, and made sense for workloads that were uncertain or fast-changing. It was rational because of the specific kind of work it was built for. DevOps teams went cloud-first because cloud was built for work that is iterative, variable, or hard to predict.

But the thing they were building for did not stay still. The cloud didn’t change, but the workloads did. As processes matured and became predictable, organizations got familiar with the costs around getting their own data back. Egress fees, storage costs, transfer charges: expenses that were easy to ignore when the flexibility was worth it, and hard to ignore once the workloads stabilized. In 2024, after years of charging for data egress, AWS, Azure, and Google Cloud all waived those fees for customers migrating off their platforms, as DataCenterDynamics reported.

Once those costs were visible, the math stopped working for a growing share of the portfolio. The economics that had made cloud a good strategy with some downside became economically not viable for a growing set of AI-oriented workloads. Companies sharpened their pencils and asked whether every application really needed what cloud was providing. When they actually ran the numbers, the answer, for a lot of workloads, was no.

Those accumulated answers became a correction the industry mislabeled. That correction came to be called “cloud repatriation,” and it gets described incorrectly most of the time. It is actually workload maturity: mature companies learning to match each workload to the infrastructure model that fits it. The data backs the selective reading rather than the wholesale one. IDC found that roughly 80% of organizations expect some repatriation over the next 12 months, even as fewer than 10% have repatriated entire workloads, according to reporting in CIO.com.

Read correctly, the conclusion is not that cloud was a mistake. Cloud remains valuable, but it stopped being universal. The mature state is hybrid: cloud where it has earned its place, private or dedicated infrastructure everywhere else.

Same Correction Curve, Different Technology

That arc is finished and labeled now. The same shape is visibly beginning with AI. Every single vendor, every single conference, every single sales call right now is about AI. The saturation is identical to what I watched happen with cloud. The spend underneath the noise is real: Gartner forecasts worldwide generative-AI spending of $644 billion in 2025, up 76.4% year over year.

The same saturation implies the same coming correction. I believe a similar correction is coming, not because AI is bad, but because the same dynamic that produced cloud repatriation applies here, too. It is coming because organizations are pushing hard into AI-driven workflows without always knowing, within their own environments, how the story ends. The adoption-versus-maturity gap is measurable: McKinsey finds that 88% of organizations now report regular AI use in at least one function, yet the majority are still piloting and only about 39% report enterprise-level EBIT impact.

Push that hard without a strategy and the reckoning is not a maybe. That correction comes. It always does. You push too hard without a strategy, and eventually the economics and the operational reality force a reckoning.

There is already a name for the corrective pattern, and it is not mine. AI repatriation, the act of moving specific tasks out of probabilistic AI systems and back into deterministic workflows once those tasks become stable and repeatable, is not a concept I invented. It’s a pattern I’m watching unfold. I am not alone in watching it: Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.

What the AI Correction Looks Like

To anticipate the correction, it helps to have clean definitions for the two types of workflows involved.

A deterministic workflow is rule-based, predictable, and repeatable. The same input and the same rules produce the same output, every time. It is fast, it is fixed. It does exactly what it is designed to do, nothing more, nothing less. A probabilistic workflow uses AI or model-based reasoning to interpret context and produce a likely answer. It is useful when processes involve ambiguity, unstructured information, or judgment calls where fixed rules break down and inferences carry the load.

With the definitions set, the timing question answers itself. Probabilistic workflows are often the right tool early on when processes are not yet fully understood. They become problematic when companies continue using them when processes are clarified.

A concrete workflow makes that early-versus-late distinction tangible. Part of that workflow genuinely requires AI. Identifying the right account from a call transcript, for instance, requires inferences that a deterministic system can’t do. Other parts, attaching a file to a record or posting a notification, are deterministic tasks. A fixed rule, a direct API call, is the same output every time. I’m guilty of this myself: I’m currently building an internal automation that strings together call transcripts, routes information into our CRM, assigns action items, and pushes updates to Slack.

The temptation is to run all of it through AI, and that temptation carries a real, recurring burden. While there’s a temptation to run the whole thing through AI-mediated calls, every AI call introduces latency and carries usage and infrastructure cost. AI systems require monitoring, prompt management, and guardrails, because the underlying model is being constantly (and unpredictably) developed by its owner. You never know when it will start performing differently; outputs can vary in ways that create governance problems at scale, quickly.

Played out far enough, that burden turns into pure waste. Think about a company using AI to analyze 50,000 support tickets. The AI identifies the five most common resolution paths. At first, AI handles routing probabilistically: reading each ticket and making a judgment. Over time, the company validates those patterns. The resolution paths are now known. Turning them into deterministic workflow branches doesn’t remove AI from the process, but it is removing the redundant practice of paying AI to rediscover answers that are now known.

That’s the probabilistic tax: the added cost, latency, and governance burden of running AI as the runtime for work that no longer requires probabilistic reasoning.

What Mature Operating Models Look Like

If running solved work on AI is a tax, the mature move is to split work by type. Cloud maturity produced hybrid infrastructure, cloud where it earned its place, dedicated infrastructure everywhere else. I predict AI maturity will produce hybrid operations with the same logic.

That split produces a clear operating rule. Probabilistic systems are valuable where genuine ambiguity exists. Humans are ambiguous. Unstructured data is ambiguous. Processes that are not yet fully understood are ambiguous. Inference is the right tool for all of that. The other half of the rule is just as important: deterministic systems are where scale, cost, speed, and governance matter. The probabilistic layer discovers and interprets. The deterministic layer executes.

On the ground, two signals tell you which side a given workload belongs on:

1. If you find your team relying on AI for something that has become stable, repeatable, and well-understood, that’s a candidate for repatriation, as you are paying a probabilistic tax on deterministic work.
2. If you find your deterministic code filling up with exception handlers and variability considerations, that’s a sign that you may actually need AI. The rule set is trying to approximate inference.

In practice, that boundary gets drawn as a confidence threshold. A specific confidence threshold, committing to a decision when the model is above 90% certain, or failing gracefully below it, is often where that boundary gets drawn in practice.

Which reframes what winning with AI actually requires. The most successful companies adopting AI will not be those that use it the most, but those that know when to use it and when to supplement it.