The next wave of AI capacity will not be decided by accelerator availability alone. Developers, cloud providers, governments and infrastructure investors increasingly have to decide what operating model should sit around those accelerators before they decide where a project belongs. A hyperscale campus can offer enormous integration and operating scale, while colocation can give customers access to third-party facilities without requiring them to own the underlying real estate and physical plant. Sovereign environments introduce another dimension because data location, administrative access and operational control can become explicit design requirements.

These models increasingly overlap rather than occupying perfectly separate markets, making simple labels less useful for infrastructure planning. The International Energy Agency expects worldwide data-center electricity consumption to roughly double from 485 TWh in 2025 to about 950 TWh in 2030, while AI-focused facilities grow considerably faster. That growth places power, networks, financing and regulatory constraints alongside compute performance when projects move from concept to construction. The important question for Panel 5 is therefore not which model wins, but which model fits the workload, jurisdiction, capital structure and control requirements attached to the capacity being built.

The Infrastructure Decision Now Starts Before the Server Hall

AI infrastructure planning increasingly begins outside the server hall because electrical capacity can determine whether a theoretically attractive site can actually support deployment on schedule. The IEA notes that a data center can become operational within two to three years, while broader energy infrastructure can require longer planning and construction periods, creating a mismatch between digital deployment schedules and power-system development. That mismatch changes the economics of choosing among hyperscale, colocation and sovereign environments because each option gives the customer a different degree of control over site selection and supporting infrastructure.

Hyperscale operators can coordinate facilities, computing platforms and networks at very large scale, but their preferred regions still depend on available power and infrastructure. Colocation operators can aggregate demand from multiple customers and provide access to facilities in markets where building independently may be slower or operationally unnecessary. Sovereign deployments can impose additional requirements involving geography, legal jurisdiction, administrative access or infrastructure control. Consequently, the physical location of compute becomes inseparable from questions about who operates it, who can access it and which legal regime governs it. A procurement decision that once centered heavily on computing capacity can now require simultaneous evaluation of power delivery, deployment speed, compliance architecture and operating authority.

Hyperscale Still Has a Powerful Economic Logic

Hyperscale infrastructure remains compelling when organizations need extensive cloud ecosystems, large distributed platforms and access to services that extend well beyond raw accelerator capacity. Major cloud environments combine compute with storage, networking, databases, security services, orchestration and software platforms, reducing the number of separate infrastructure layers that customers must integrate themselves. Their scale can also support capacity expansion across multiple regions rather than forcing every workload into a single physical facility. Evidence of continued hyperscale investment remains substantial: Microsoft announced a $17.5 billion investment across 2026 through 2029 to advance cloud and AI infrastructure, skilling and operations in India, describing it as its largest investment in Asia. Large technology companies are also directing extraordinary capital toward the physical systems required for AI, although their expenditure figures frequently include infrastructure supporting both AI and established businesses.

Meta, for example, said in January 2026 that it expected 2026 capital expenditures of $115 billion to $135 billion, with growth driven by investment supporting its AI efforts and core business. Those figures should not be interpreted as spending solely on data centers, yet they illustrate the capital intensity surrounding large-scale computing expansion. Hyperscale deployment therefore remains difficult to separate from the broader economics of vertically integrated cloud platforms. For customers, the attraction is less about owning infrastructure and more about consuming a deep technology stack without reproducing every physical and software layer internally.

Colocation Changes the Ownership Question

Colocation occupies a different position because the facility operator and the computing customer can remain economically distinct while sharing the same physical infrastructure ecosystem. Customers can deploy owned or leased servers inside third-party facilities while relying on the operator for building systems, electrical distribution, cooling infrastructure, security and connectivity according to the commercial arrangement. That separation becomes important when AI developers want greater hardware control without taking responsibility for developing an entire data-center campus. It can also support cloud providers and other large users that lease significant capacity rather than owning every building supporting their infrastructure. Current market conditions show why the model matters: CBRE reported that the weighted average vacancy rate across the data-center markets in its global analysis fell 2.1 percentage points year over year to 6.6% in the first quarter of 2025.

The same research identified limited power availability as the primary inhibitor of growth in certain major markets. Colocation therefore does not eliminate scarcity; it creates a commercial route for accessing infrastructure within that scarcity. Capacity procurement can still depend on available megawatts, delivery schedules and the technical specifications of the facility. Customers evaluating this route need to treat a colo contract as an infrastructure decision rather than merely a real-estate lease.

Power Availability Can Matter More Than Market Prestige

Established data-center hubs continue to hold important infrastructure advantages, but CBRE’s 2025 market analysis shows that limited power availability in several core markets is creating opportunities for capacity growth in emerging locations. CBRE found that supply constraints persisted across major global markets during 2025 while demand continued to outpace new capacity in both established and emerging hubs. This creates an important change in site-selection logic because the most familiar market may not offer the fastest route to energized capacity. Developers can examine secondary locations where land and electrical infrastructure present a more workable development path, although every alternative brings its own network, workforce, permitting and operating considerations. The IEA estimates that grid constraints could put around 20% of planned global data-center capacity through 2030 at risk of connection delays unless those constraints are addressed.

Those delays matter because an AI facility produces little economic value while expensive computing equipment waits for the supporting electrical system. Location strategy must therefore compare the timing and reliability of delivered power rather than simply comparing headline electricity prices. Network connectivity, equipment supply, cooling architecture and access to skilled operators must remain part of that assessment because cheap electricity cannot compensate for an unusable facility. The resulting map of AI capacity may expand beyond traditional hubs wherever the combined infrastructure equation supports deployment.

Sovereign Infrastructure Is Becoming a Distinct Architecture Choice

Sovereignty introduces requirements that neither the term hyperscale nor colocation captures on its own because sovereignty can concern data residency, administrative access, encryption control, legal jurisdiction and operational authority. The concept also exists across multiple architectures rather than describing one universal technical design. Microsoft, for example, describes its sovereign offerings as spanning public-cloud and private infrastructure models, with controls intended to address residency, compliance and operational requirements. Google similarly offers sovereignty options ranging from data-boundary controls in public cloud to dedicated infrastructure operated with local partners. AWS has committed €7.8 billion through 2040 to its European Sovereign Cloud initiative in Germany, demonstrating that sovereign requirements can coexist with hyperscale economics rather than simply replacing them.

Saudi Arabia provides another form of nationally anchored AI development through HUMAIN, which PIF launched in 2025 to operate across data centers, cloud infrastructure, AI models and applications. These examples differ significantly in ownership, technology and governance, which is precisely why “sovereign” should not function as shorthand for one facility type. Buyers must identify the specific control they require before choosing the infrastructure intended to provide it. A residency requirement, for example, does not automatically create the same architecture as a requirement for locally controlled operations or disconnected computing.

Regulation Is Moving Into Infrastructure Design

Regulation increasingly affects architecture because cloud portability, data governance and jurisdictional requirements can influence how workloads are deployed and moved. The European Union’s Data Act provides a useful example of infrastructure policy reaching into cloud operations. Its provisions establish requirements intended to make switching between data-processing services easier and reduce contractual and technical barriers that can keep customers tied to one provider. The European Commission says providers must remove obstacles preventing customers from switching providers or using multiple services simultaneously, while infrastructure-as-a-service providers must take measures supporting materially comparable outcomes for shared features when customers switch to the same service type. Switching charges, including applicable data-egress charges associated with switching, are scheduled for removal from Jan. 12, 2027, after the transitional period described by the Commission.

Such requirements do not dictate whether an organization should select hyperscale, colo or sovereign capacity. They do show that portability and interoperability can become regulatory considerations rather than optional architecture preferences. Buyers designing large AI environments should therefore examine whether data, applications and operating processes can move before a regulatory or commercial event forces that question. Infrastructure flexibility becomes more valuable when policy and technology both continue to evolve.

The Decision Framework Starts With Workload Control

The first practical filter should be the level of control that the workload genuinely requires rather than the level of control that sounds strategically attractive. A research team training models with rapidly changing accelerator requirements may prioritize access to scalable compute, networking and software services, while another organization may need predictable hardware configurations for a long-running production environment. Regulated or public-sector workloads can add requirements around residency, operator access, encryption keys or legal jurisdiction that materially change the available choices. Microsoft states that its local and private sovereign models can provide control over hardware, software, data, location and management, illustrating how far the control spectrum can extend. Public-cloud sovereignty offerings can address different requirements without necessarily moving every workload into isolated infrastructure.

Colocation can occupy another point on that spectrum by allowing customers to control computing hardware while purchasing facility services from an operator. None of those models should automatically become the default for an entire organization because workload requirements rarely remain identical across every application. A stronger framework classifies workloads according to control, portability, latency, compliance, availability and hardware requirements before mapping them to physical capacity. This approach makes architecture a consequence of workload characteristics rather than a predetermined corporate preference.

The Second Filter Is the Cost of Waiting

Infrastructure economics should include time because a cheaper facility that becomes operational significantly later can carry a different business value from capacity available when the workload needs it. Grid connection timelines, construction schedules, networking deployment and equipment delivery can all determine when AI hardware begins useful operation. The IEA explicitly highlights the timing mismatch between data centers, which can be deployed relatively quickly, and energy infrastructure that can require substantially longer planning and construction. This means an organization comparing a self-developed campus with available colocation capacity should calculate more than construction cost per megawatt. It should examine the economic effect of delayed model development, postponed product launches, unused equipment commitments and temporary computing alternatives where those exposures apply.

Hyperscale cloud capacity may provide faster access for some workloads, although availability, accelerator type, geography and commercial terms still require evaluation. Colo capacity may shorten the facility-development burden when suitable energized space exists, while dedicated development can provide greater physical control at the expense of assuming more execution responsibility. However, no deployment model can remove every schedule risk because power, networking equipment and supply chains affect the broader market. Time-to-compute therefore deserves its own place beside total cost of ownership in capital-allocation decisions.

Capital Structure Will Shape the Physical Architecture

The enormous financing requirements of AI infrastructure are likely to influence ownership structures as much as technology choices do. The IEA now says data-center investments have grown too large to rely on company balance sheets alone and expects capital markets to play a critical role in funding expansion. That observation matters because different ownership models distribute capital requirements and asset risk differently across cloud companies, operators, developers, investors and customers. A hyperscaler can invest directly while also using leased facilities and other contractual structures, meaning hyperscale computing does not necessarily imply hyperscaler ownership of every underlying building. Colocation structures can allow customers to procure facility capacity without directly developing and financing an entire data-center campus, although the allocation of infrastructure costs and commitments depends on the commercial agreement.

Governments and state-backed entities can use other structures when national capacity, industrial development or digital autonomy form part of the investment rationale. Meanwhile, private capital can participate across land, power infrastructure, buildings, networking and operating platforms rather than treating the data center as one indivisible asset. This variety makes the next investment cycle a question of who should hold which infrastructure risk for how long. Capital allocation will favor structures capable of matching long-lived physical assets with credible demand and financing arrangements.

Energy Strategy Can Separate Otherwise Similar Projects

Two technically comparable AI campuses can produce very different investment cases when one has credible power delivery and the other depends on infrastructure that has not yet arrived. Electricity availability therefore acts as both an engineering input and a financial constraint. The IEA projects data-center electricity consumption at roughly 950 TWh by 2030 in its updated outlook, equivalent to around 3% of worldwide electricity demand. The global percentage can obscure concentrated local effects because large facilities connect to specific grids rather than drawing proportionally from a global electricity pool. Developers must evaluate generation availability, transmission capacity, connection timing and the operating characteristics of the local power system before treating announced megawatts as usable computing capacity.

The electricity supporting data centers can come from different combinations of grid supply and generation sources, with the IEA projecting renewables, natural gas and nuclear power among the sources contributing additional electricity for data-center demand. The IEA expects renewables to provide a substantial share of additional electricity needed for data centers while dispatchable sources also contribute to meeting demand. Therefore, the competitive position of a proposed AI site depends partly on whether its energy plan can progress from contractual ambition to reliable physical delivery. The strongest compute design cannot compensate for an electrical system that fails to energize it when required.

Hybrid Deployment May Be the More Durable Answer

The framing of hyperscale versus colo versus sovereign infrastructure can imply that buyers must select one model, yet the market increasingly provides mechanisms for combining characteristics from all three. A company can use public cloud for elastic development workloads, place dedicated accelerator clusters in colocation facilities and reserve more controlled environments for workloads with stronger jurisdictional requirements. Cloud providers themselves are also blurring these boundaries by extending sovereignty controls across public and private environments. Microsoft’s current sovereignty portfolio includes public-cloud, private-cloud and national partner deployment models, while Google offers public-cloud sovereignty controls alongside dedicated infrastructure operated by local partners. This overlap indicates that sovereignty and hyperscale should not always be treated as opposing categories.

At the same time, colocation can serve as physical infrastructure for cloud platforms, dedicated customer hardware and specialized computing providers, making the facility model different from the service model running inside it. The architectural question becomes which layer requires ownership or control: land, power, building, server, network, orchestration platform, data or operational access. Separating those layers prevents procurement teams from paying for control that the workload does not need while overlooking control that regulation or operational risk actually demands. Hybrid architecture becomes rational when different workloads produce different answers to those questions.

The $100 Billion Question Is Really About Allocation

The “next $100 billion” is best understood as a capital-allocation question rather than a prediction that one infrastructure category will capture a fixed pool of precisely that size. Current investment announcements already show that AI and cloud expansion can require tens of billions of dollars from individual technology companies, while the IEA expects broader data-center investment to depend increasingly on capital markets. The choice among hyperscale, colocation and sovereign capacity will therefore be made project by project rather than through one global architectural verdict. Hyperscale environments can capture workloads that value integrated platforms, rapid service development and extensive geographic infrastructure. Colocation can attract customers that want physical hardware control or dedicated capacity without assuming the full responsibility of building and operating the facility.

Sovereign architectures can become necessary where jurisdiction, operational authority or data-control requirements materially affect deployment. Power availability can override all three preferences when a region cannot deliver electricity within the required schedule, while financing conditions can determine whether otherwise viable projects move forward. Buyers that separate workload requirements from facility ownership will have a clearer view of which layer deserves their capital. The infrastructure that gets built will ultimately reflect a negotiated balance among compute demand, power availability, financing, regulation, operational control and deployment speed rather than allegiance to a single model.

Panel 5: The Decision Is About Control, Capital and Time

For infrastructure leaders, the useful outcome of this debate is not a ranking of three deployment models but a repeatable sequence for testing them. First, the workload should establish the required hardware, network performance, geographic placement, data governance and operational authority. Second, the infrastructure team should determine where sufficient power and network capacity can realistically arrive within the deployment window. Third, procurement and finance teams should compare ownership, leasing and cloud consumption structures against the expected duration and utilization of the workload. Regulatory teams then need to establish whether residency alone satisfies the requirement or whether administrative access, encryption control, local operations or legal jurisdiction impose stronger conditions. The architecture can then assign different workloads to hyperscale platforms, colo environments or sovereign capacity without forcing the entire AI portfolio into one model.

This method also creates room to revise the allocation as technology, policy and power markets change. Rapid growth in AI-related data-center demand is encountering grid and infrastructure bottlenecks in some markets, making deployment flexibility increasingly important when capacity faces physical constraints. Where the next major block of capital gets built will depend less on the label attached to the data center than on whether its power, control model, financing and operating architecture match the workloads expected to occupy it.