An AI roadmap can look credible on paper while overlooking whether the infrastructure can support it. Power availability can delay deployment, while higher-density hardware can change what a chosen facility can deliver. 

An AI programme can have executive backing and a clear compute requirement and still miss its delivery window because the infrastructure cannot support what has been planned. 

A chosen site may have enough capacity on paper but no connection available when the project needs it. Elsewhere, the power may exist, but the facility cannot support the density of the proposed hardware. Cooling can become another constraint once that hardware is concentrated into a small number of racks. 

These are infrastructure questions, but their consequences reach directly into AI delivery. 

The problem is often one of timing and ownership. AI demand can be forecast long before anyone tests whether the physical capacity required to support it will be available. 

Power is Now Part of the AI Delivery Plan 

The scale of the wider infrastructure challenge is becoming clearer. 

The International Energy Agency has projected that global electricity demand from data centres will more than double by 2030 to around 945TWh, with AI expected to be the largest driver of the increase. The IEA has also stressed that the trajectory remains uncertain. Adoption could develop differently, efficiency may improve and energy bottlenecks could limit growth. 

In Britain, those bottlenecks are already influencing infrastructure policy. 

The UK Government has described timely grid connections as the “single biggest blocker” to establishing AI Growth Zones. Connection queues can leave proposed projects waiting for the electricity capacity needed to proceed. 

Ofgem's connections reform is changing how that queue operates. Its new process introduces “ready” and “needed” criteria into decisions about which projects receive connections. 

For CIOs, CTOs and infrastructure leaders, the relevance is straightforward. A requirement for additional compute eventually becomes a requirement for physical capacity somewhere. 

Last week's analysis looked at whether organisations should buy more GPU capacity before establishing how efficiently their existing compute is being used. Once the case for additional capacity has been made, the next question is whether that capacity can be delivered. 

Different Teams Plan Capacity in Different Units 

The infrastructure constraint can expose a wider organisational problem. 

The teams involved are often describing the same AI programme in completely different terms. AI leaders forecast demand through models and expected usage. Infrastructure teams translate that demand into compute. 

By the time the requirement reaches facilities, the conversation has changed again. The relevant question may be how much load a particular rack or site can actually support. Finance and procurement then have to reconcile those requirements with investment timing and contractual commitments. 

Each view can be valid while still describing only part of the requirement. 

Problems emerge when those assumptions meet too late. Hardware can be selected before the implications for rack density are understood. A preferred location can turn out to have a connection date that misses the planned launch. Another technically viable option may alter the economics enough to change the business case. 

Cloud changes who provide the infrastructure, but it does not make the physical layer disappear. Capacity constraints still exist underneath the service and can affect availability, location, and cost. 

The wider UK electricity system has illustrated why those assumptions matter. The National Energy System Operator (NESO) has said it expects electricity demand in Great Britain to rise by more than 30% by the mid-2030s and identifies AI data centres among the emerging loads requiring network reinforcement. It has warned that connection delays could limit economic growth if reinforcement does not keep pace. 

An individual enterprise cannot solve that system-level problem. It can avoid discovering its implications after major technology decisions have already been made. 

Available Megawatts Do Not Tell the Whole Story 

Having power available at a site does not necessarily mean it can support the proposed AI deployment. 

AI hardware can concentrate demand into a relatively small physical footprint. The constraint can therefore move from total site capacity to what can be delivered to individual racks and whether the resulting heat can be removed. 

ASHRAE's work on liquid cooling has illustrated the underlying engineering pressure. Its research links rising CPU and GPU socket power with greater cooling difficulty and a movement towards liquid cooling for higher-power systems. It has also noted that continuing to extend air cooling requires greater airflow, with consequences for facility infrastructure. 

Changing the cooling method can reach well beyond the server itself. 

ASHRAE identifies implications for existing facility infrastructure, from piping and heat exchangers to the temperatures at which facility water systems operate. Some existing data centres may not have been designed to accommodate those changes easily. 

Liquid cooling is therefore not a universal answer to AI infrastructure. The appropriate design depends on what the workload requires and what the existing estate can support. It also depends on how quickly those requirements are expected to change. 

The planning implication is simpler: a power forecast without a density and cooling path is incomplete. 

Build a Range Rather Than One AI Forecast 

AI demand is uncertain enough that treating one capacity forecast as a commitment can create a different problem: infrastructure built for demand that never materialises. 

A more useful plan considers several possible trajectories. A base case establishes what is reasonably expected. A growth scenario tests what happens if adoption accelerates. A constrained scenario shows what can still be delivered if infrastructure, funding or demand develops differently. 

Workload type matters too. 

Training does not necessarily create the same infrastructure requirement as real-time inference. Batch workloads may provide more flexibility around when or where they run. Fine-tuning introduces another demand profile. 

Each scenario can then be translated through the same planning chain: 

Workload demand → compute → rack density → power → cooling → space → location → delivery date → cost and resilience. 

Using the same requirements creates a more useful basis for comparing cloud, colocation, retrofit, and owned infrastructure. 

It can also prevent flexibility from being confused with overbuilding. An organisation might prepare a site for higher-density hardware without immediately installing infrastructure for the highest forecast. Capacity can be phased as demand becomes clearer. 

This is important to consider when the external assumptions are changing too. The IEA has highlighted uncertainty around both AI adoption and efficiency, while Britain's reformed connection regime places greater emphasis on projects demonstrating readiness and need. 

A range makes that uncertainty visible. One aggressive forecast can hide it. 

Someone Needs to Own the Assumptions 

None of this requires facilities to own the AI roadmap, or AI leaders to become data centre engineers. 

It does require somewhere for their assumptions to meet. 

An executive sponsor can provide that accountability, supported by a capacity group bringing together the people responsible for AI demand and the infrastructure needed to satisfy it. Finance and procurement need visibility early enough to understand when a technical choice creates a longer-term commercial commitment. 

The organisation can then maintain one rolling view of expected demand and available capacity. 

Major commitments should be tested against that view before they become difficult to reverse. A proposed hardware order might trigger a check on physical feasibility. Site selection should account for the connection timetable. Before production launch, the organisation should know whether the resilience assumptions made during planning still hold. 

This also makes trade-offs easier to understand. 

A faster route to capacity may cost more. The preferred location may introduce a longer wait for power. Building for the highest demand scenario could preserve headroom but leave expensive infrastructure unused if growth is slower than expected. 

Actual utilisation should then feed back into the forecast. Otherwise, ambition can quietly become stranded capacity. 

Minimum Viable AI Capacity Plan 

Before a major AI infrastructure commitment, the organisation should be able to identify: 

Workload type; demand range and ramp date; latency and availability target; deployment location; compute requirement; expected rack density; power and cooling path; connection or delivery lead time; resilience level; cost and carbon impact; named owner; and next decision date. 

Leaders do not need a perfect forecast of future AI demand. They need shared assumptions and enough visibility to identify when those assumptions collide with physical constraints. 

An AI roadmap becomes executable when major compute commitments have a credible path to power, cooling, location and delivery. 

Once an organisation knows it genuinely needs more compute, someone also needs to own the plan for making that capacity possible.