Infrastructure buyers are rewarding control over capacity

Capacity, uptime and price remain central to infrastructure deals. Buyers are now testing portability, sovereign control and cost visibility with equal care.

At ADAPT’s Cloud & Infrastructure Edge 2026, 28% of infrastructure leaders said they intended to move workloads out of public cloud.

The planned moves cover an average of 13% of their cloud estates, while 57% still expect public cloud GPUs to support the next wave of AI demand.

Public cloud remains part of the operating model, but individual workloads are being reassessed against cost, sovereignty, performance and risk.

Procurement questions now cover whether customers can change models, consumption methods or environments without rebuilding workloads or absorbing prohibitive costs.

AI infrastructure is facing the same scrutiny.

Buyers want to know who controls the model, whether access can be withdrawn, how consumption will be tracked and what the service will cost once orchestration, assurance and exception handling are included.

In this article, we examine what changing buyer expectations mean for infrastructure providers:

• Portability and consumption choice in platform decisions
• Sovereign control beyond data residency
• Total cost of outcome in commercial proposals
• Product, contract and pricing changes that strengthen the offer
• Buyers want an exit path before they choose a platform

Buyers want an exit path before they choose a platform

Infrastructure providers have traditionally benefited from the difficulty of moving established workloads.

Proprietary data formats, tightly coupled services, exclusive management tools and high migration costs can make an incumbent platform difficult to replace.

Those dependencies may support retention, but they also add risk for buyers whose workload requirements are changing more quickly.

David Walker, former CTO at Westpac and DBS and an ADAPT Advisor, described how both banks evaluated workloads against security, availability, performance and economics.

Approximately 70% were more economical on infrastructure operated by the banks.

The remaining 30%, including bursty workloads requiring short periods of specialised capacity, suited public cloud economics.

The 70–30 split reflects the scale and capability of large banks.

The assessment process could be repeated as usage, pricing and operating requirements changed.

At DBS, the team also compared pricing between cloud providers and directed compute towards the more economical option.

David described “built for change” as a guiding architectural principle.

Lightweight abstraction layers preserved the option to change models or environments as costs, capabilities and requirements evolved.

Vendors are competing to remain viable each time a customer reviews the workload, not only when the initial migration or deployment is approved.

A three-year contract may still be signed, but token pricing, hardware performance, regulatory requirements, internal capability and alternative providers can all change during that period.

Contracts and architectures that support periodic review are easier to defend when those assumptions move.

Buyers will increasingly expect clear answers on:

• How data, models and configurations can be exported
• Which proprietary dependencies affect a future move
• What migration tooling and support are included
• How long offboarding is expected to take
• Which charges apply when services are reduced or terminated
• Whether workloads can move between public, private, sovereign and edge environments

Andrew Leece, Co-founder and Chief Operating Officer at Sharon AI, described another form of choice emerging within AI infrastructure.

Customers may want to consume the same underlying capacity through bare metal, virtual machines, Kubernetes clusters or tokens.

The appropriate model depends on the workload, internal capability and how much of the stack the organisation wants to manage.

A fixed consumption model narrows the addressable deal.

An organisation may begin by consuming tokens, move to managed clusters as usage grows, then require direct infrastructure access for a sensitive or high-volume workload.

Offers that allow movement between those layers without rebuilding the surrounding architecture are better aligned with how enterprise AI capability develops.

Portability does not require providers to remove every proprietary advantage from their products.

It does require clarity about where dependencies sit, what value they create and what the customer would need to do to leave.

Unclear exit costs give buyers another reason to build internally, distribute workloads across providers or repatriate when the economics change.

Back to top

Sovereign claims now need technical proof

Sovereign infrastructure was once discussed mainly through the location of data and facilities.

Those questions remain important, but buyers are examining a wider set of dependencies.

They want to know where the compute runs, who operates it, who owns the encryption keys, which jurisdiction applies and whether an external party can change, restrict or withdraw the service.

For AI workloads, the assessment can extend to model weights, training pipelines, audit trails, update processes and the organisation’s ability to modify or replace the model.

A data residency certificate does not answer those questions.

Dean Nelson, Founder and Chairman at Infrastructure Masons, described enterprises seeking greater control by building private models on open-source foundations and applying their own data.

He characterised the shift as organisations wanting to control “the keys to their kingdom”.

Proprietary models will continue to provide capabilities and scale that many organisations cannot reproduce internally.

The difficulty arises when customers cannot determine how a model may change, who can intervene or whether access will continue under different legal, geopolitical or commercial conditions.

Greg Boorer, Founder and CEO at CDC Data Centres, described a model used in data centre operations becoming unavailable following an external decision.

He compared the interruption with disruption to fuel passing through the Strait of Hormuz.

Physical fuel reserves may give an economy time to find alternative supply. Access to a model can be withdrawn within minutes.

Procurement teams now have to account for the operational and financial exposure created by sudden loss of access.

The assessment is no longer limited to whether a model performs well today.

It also covers how quickly another model could be introduced if the service were restricted.

Providers should be ready to explain who can access customer data, models and logs, whether a model can be modified or disabled without approval, and how changes to export controls, sanctions or jurisdiction would affect the service.

Buyers may also ask whether they can retain model weights or fine-tuned versions, use customer-owned encryption keys, identify offshore dependencies, maintain continuity if a primary model becomes unavailable, and substitute another model without redesigning the workflow.

The answers will differ by provider and service.

Complete domestic ownership of every component will not be necessary for every workload.

Dependencies still need to be visible.

A proprietary model may still be the right choice, but unclear access rights, jurisdictional exposure and limited replacement options will count against it when buyers assess sovereign control.

Customer-controlled keys, Australian-operated environments, local support, open-model options, transparent update policies and contractual commitments on access restrictions make sovereign claims more specific.

The product needs to show what remains under the customer’s control.

Back to top

Buyers are evaluating the total cost of a working outcome

Production AI costs can include model calls, data movement, storage, orchestration, graph databases, conventional compute, monitoring, security controls, human review, exception handling, retries and compliance.

A low price per token can still produce an expensive operating outcome.

Gabby Fredkin, Head of Analytics & Insights at ADAPT, shared an example of an organisation that consumed its entire annual token budget within three months.

The use case recorded meetings, produced transcripts and distributed notes.

Consumption was only identified when the organisation reached its scheduled reporting point three months later.

By then, the annual allocation had been exhausted.

Delayed reporting leaves customers with little opportunity to intervene before costs accumulate.

Real-time dashboards, configurable thresholds, forecast alerts, departmental attribution and automated controls allow spend to be addressed while the workflow can still be changed.

Reporting also needs to extend beyond model consumption.

David Walker noted that agents can depend on graph databases, CPUs and other infrastructure.

FinOps models that capture only tokens or model charges will understate the cost of running the full system.

Production costs can also differ sharply from pilot estimates.

Gabby described a comparison in which an agent appeared to complete a task with 30 effort points against 100 for a human. Once deployed, the agent required 140.

Retries, human checks, escalation and the compliance chain added costs that had not been included in the pilot.

Commercial proposals that omit those requirements may appear competitive before production and lose credibility once the workflow is operating.

A credible cost model should account for model and infrastructure consumption, orchestration, integration, human review, exception handling, monitoring, security, compliance, data transfer and storage.

It should also show how costs change at different volumes, which assumptions could materially alter the estimate and which business outcome the spend is expected to deliver.

Leonard Rawat, Head of Infrastructure, Security and Operations at Harris Farm Markets, built an evaluation tool to assess 94 security vendors against multiple frameworks.

A heat map showed how many coverage areas each product addressed, where tools overlapped and where gaps remained.

Harris Farm could then assess which combination of providers suited its requirements.

The same method can be applied to cloud and AI infrastructure.

Buyers can use their own data and AI tools to decompose vendor claims, compare coverage and identify duplication.

Statements about being comprehensive, integrated or AI-ready can be tested against defined requirements.

Clear capability maps, integration boundaries, measurable service levels and acknowledged gaps are easier to evaluate than broad claims of end-to-end coverage.

Back to top

What infrastructure vendors need to change

Portability, sovereign control and cost visibility need to appear in the product, contract and commercial model before the final pitch.

• Include portability and offboarding in the base offer

Document export formats, migration support, timelines, dependencies and termination charges upfront. Do not leave the exit path until the architecture has already been selected.

• Support more than one consumption model

Allow customers to engage through managed services, tokens, clusters, virtual machines or direct infrastructure where the product allows it. Movement between those layers should be technically and commercially practical.

• Publish a clear control and jurisdiction model

Show who can access, modify, suspend or revoke each component of the service, where those parties are located and which laws govern their actions.

• Offer customer-controlled and open-model options

Proprietary services can remain part of the portfolio, alongside open-source, customer-owned or independently deployable alternatives for workloads requiring greater control.

• Build continuity protection into the architecture

Provide fallback models, exportable configurations, model substitution paths and contractual processes for external access restrictions.

• Expose consumption before the invoice arrives

Give customers real-time usage, forecasting, thresholds, attribution and alerts across tokens, compute, storage and data movement.

• Model the full cost of production

Include integration, orchestration, monitoring, human review, exceptions and compliance when presenting expected economics.

• Position smaller models as a serious option

Fine-tuned and use-case-specific models can be presented as cost, control and performance choices rather than lower-tier substitutes for frontier models.

• Offer recurring workload-placement reviews

Reassess workloads as volume, regulation, model capability and economics change. This keeps the provider involved before the customer begins considering repatriation.

Back to top

Capacity is only one part of the decision

Infrastructure buyers still need scarce compute, resilient facilities and scalable cloud services.

They are also assessing how easily workloads can move, who retains control and what production will cost once the surrounding operating model is included.

Workloads are more likely to move when the original assumptions on cost, control or continuity no longer hold.

Providers that make portability, continuity and cost transparent have a stronger basis for retaining them.

The contract should make clear how a workload enters, operates, changes and exits.

Back to top