The first hit is access. I have talked with technology leaders whose teams had a working model but could not secure the capacity to operate it at production scale on the economics they had forecast. The available capacity sat outside the assumptions behind the existing agreement, and market pricing had moved well beyond the budget. As CIO.com has reported, AI is exposing the limits of enterprise cloud strategies created before these workloads became material.

Data movement creates another problem. AI workloads may cross regions or providers in search of an available GPU or a better price on a particular chip. I have seen finance teams confront cloud bills that ran well beyond forecast because data had to leave one cloud to reach compute available in another. The increase had nothing to do with headcount or a wave of new applications. It came from an architecture assembled around capacity rather than cost.

Egress pricing also changes the economics of portability. Consolidating with one hyperscaler may simplify operations, but it can become expensive to change course when the provider cannot supply the right capacity in the right place. By the time the CIO needs alternatives, the cost of moving data may have weakened the negotiating position.

Then the question reaches the board: What will AI cost next year? Some CIOs cannot answer with confidence because the contract and cost model were built around a different workload. That is more than a forecasting problem. It tells the board that the company has committed to an AI roadmap without understanding the infrastructure economics beneath it.

What prepared CIOs are doing differently

The CIOs in the best position separated AI economics from the rest of the cloud estate before returning to a provider. They stopped defending cloud spend as one number and accounted for training and inference by workload, region and chip. That work gave them something far more useful than another high-level forecast: evidence they could negotiate from.

Some have resisted the usual pressure to consolidate everything with one hyperscaler. They have kept selected AI workloads portable across providers or moved GPU-heavy training to specialized infrastructure companies. Portability carries its own engineering and governance costs, so it is not automatically the right answer. But a credible ability to move a workload creates leverage that a cloud strategy built around dependence cannot.

The contract requests have changed as well. CIOs are asking for guarantees tied to named chip types, shorter terms for volatile AI capacity and the ability to rebalance spend categories as the workload mix changes. One structure is a reserved allocation for a specific GPU generation rather than a general compute credit. Another is a shorter AI-specific commitment layered over a longer agreement for the general-purpose estate. The two workloads do not have to be forced into the same planning horizon.

The work should start before the provider puts a proposal on the table. Once the negotiation has been reduced to a renewal number and a discount percentage, the most important assumptions have already escaped scrutiny.

Start with the workload rather than the existing agreement. Which AI use cases are expected to reach production during the next term? Which require training, which rely mostly on inference and which can use a managed model without dedicated GPU infrastructure? Those distinctions determine whether the company needs reserved capacity, flexible consumption or no direct GPU commitment at all.

Then test the location assumptions. Where does the underlying data reside? What residency or sovereignty rules limit where it can move? If the preferred capacity is available only in another region or from another provider, calculate the transfer, egress and operational costs before calling that option cheaper. A lower compute rate can disappear quickly when the data has to travel to reach it.

Capacity and discounts also need to be separated. A favorable price does not guarantee that the required chip will be available when a production workload needs it. Conversely, a capacity reservation can protect access while creating a cost for infrastructure the company does not fully use. The CIO needs both numbers: the economics of consuming the capacity and the economics of holding it.

Finally, decide what must remain portable. Full multi-cloud portability is expensive and often unnecessary. But there may be a small number of high-cost AI workloads where dependence on one provider creates more risk than portability costs. That is where an alternative architecture can become negotiating leverage rather than an abstract cloud principle.

None of this requires treating the original agreement as a mistake. It was often a reasonable decision based on the company’s workload at the time. What has changed is the cost of leaving it unexamined.

A three-year cloud agreement cannot be treated as a three-year suspension of judgment. Before the next renewal, test the commitment against the workload the company is actually running, not the company it was when the agreement was signed.