TL;DR

  • Power Readiness Scheduling: Grid interconnection wait times reaching five to ten years in many regions require maintaining a dedicated power-readiness schedule that tracks utility upgrades, energization permissions, and phased deployment dependencies.
  • Rack Level Cooling and Water Strategy: Facility engineering must look beyond hall averages to accommodate high rack densities with direct liquid cooling, traceable heat paths, and site-specific water management plans.
  • Shared Acceptance Decisions: AI platform, facilities, and energy procurement leaders must jointly approve site readiness under real-world operating conditions, explicitly pricing the financial risk of delayed or restricted operations.

# # #

Picture an AI project with everything lined up: accelerators secured, lease signed, installation window booked. Then the utility’s service date slips, or the cooling design cannot support the specified racks through a hot afternoon with a pump unavailable. The hardware exists, but the computing capacity the business expected does not. Buying the machines was never the same as buying the ability to run them.

That distinction should change how AI infrastructure is planned. Chip availability still matters, but a site can become the binding constraint long before its floor space is full. Power delivery, heat removal and workload commitments need to be settled together, while there is still time to change the location or deployment plan.

Even without pinning every data center kilowatt-hour on AI, the scale is substantial. The IEA’s April 2026 outlook estimates global data center electricity consumption at about 485 terawatt-hours in 2025 and projects roughly 950 TWh in 2030, nearly double. Those totals cover data centers broadly; the report separately projects electricity use by AI-focused facilities to triple over that period. The 2030 figures are projections, not measured demand.

Start with a deliverable service date

A power discussion needs a location, a date and operating conditions, not just a megawatt figure. In its 2026 report, the IEA identifies grid-connection waits reaching five to ten years in many jurisdictions. That is a warning about constrained markets, not a universal lead time to paste into every project schedule.

Queue statistics also require care. Berkeley Lab’s 2026 Queued Up analysis reports a median exceeding five years from interconnection request to commercial operation for projects completed in 2025, in regions with available data. It tracks generation and storage projects, not data center load connections. Treating that number as the average wait for an AI campus would misstate the evidence.

The rules for connecting large loads are also in flux. In June 2026, FERC directed six regional grid operators to justify or revise their tariffs for large loads, addressing studies, cost allocation, co-location and flexible service. That action was not an energization approval for any individual campus. Developers still need to establish what their particular service agreement permits and what infrastructure must be completed first.

My recommendation is to maintain a power-readiness schedule alongside the construction schedule. It should name the dependencies for each deployment phase: studies, utility upgrades, equipment delivery, protection testing and permission to energize. Ask which dates are commitments, which are estimates and who carries the cost of slippage. A smaller first phase with power you can count on may beat a larger phase whose power date is still conditional.

Design around the demanding rack rather than the average hall

Once electricity reaches the building, the challenge becomes more local. Two hypothetical halls could have identical IT megawatts while placing very different demands on individual rows, electrical branches and cooling loops. Averaging across the hall would hide that difference. Require the proposed rack layout and expected workload profile before accepting a cooling-capacity claim.

Direct liquid cooling moves heat into fluid close to where it is generated, rather than first moving it through room air. The Department of Energy’s 2024 design guide describes its ability to serve higher heat densities. But selecting liquid-cooled servers is not the same as specifying the facility’s entire heat-removal system.

Temperature compatibility deserves particular attention. ASHRAE’s liquid-cooling guidance explains that increasing component power can require lower supply-water temperatures, potentially reducing opportunities to cool without mechanical refrigeration. A loop suitable for one hardware generation is therefore not automatically suitable for the next. Validate the actual equipment envelope rather than assuming that “liquid-ready” settles the question.

For design reviews, I would ask for a traceable heat path from the chip to the outside environment. Which components remain air-cooled, what temperatures and flow rates are required, and how does capacity change during maintenance? Include coolant distribution units, pumps, piping, controls and leak response in commissioning scenarios. A cooling system should earn its operating limits through testing, not through a label on the sales specification.

Keep efficiency claims within their measurement boundaries, too. DOE defines power usage effectiveness, or PUE, as annual facility energy divided by annual IT energy; it measures infrastructure overhead, not useful computing output. A favorable annual PUE does not establish peak electrical or thermal capacity. For an AI deployment, I would review it alongside completed work, service quality, total energy and peak demand.

Water belongs in the siting decision

Water accounting has two distinct operational boundaries. Berkeley Lab’s 2024 U.S. data center report estimates 2023 direct water consumption at about 66 billion liters and the indirect footprint from electricity at nearly 800 billion liters. These are sector-wide estimates, not AI-only measurements. The indirect estimate uses regional electricity mixes and excludes facility-specific power-purchase agreements and behind-the-meter generation.

Liquid cooling does not, by itself, tell you how much water a facility consumes. In December 2024, Microsoft described a new design using recirculating water without evaporation for cooling, while acknowledging increased energy demand when mechanical cooling replaces evaporation. That was a design announcement, not evidence that its whole fleet had eliminated cooling-water use. Nor does zero evaporation at the site erase water consumption associated with electricity generation.

The local source matters as much as the annual total. Google’s published water-risk framework considers community demand, available supply, delivery infrastructure and changing climate conditions. It describes choosing air cooling for Mesa, Arizona, after identifying elevated risk to the proposed water source. That is a site-specific decision, not a universal endorsement of one cooling architecture.

For a new project, request a water plan before making the final siting commitment. Separate withdrawal from consumption, identify potable and reclaimed supplies, and test the plan against seasonal restrictions and extreme heat. Ask what happens to electrical demand if water availability falls. A design that saves electricity by using water needs a credible operating plan for the days when that water is hardest to obtain.

Buy flexibility only when the workload can deliver it

There is public evidence that some computing demand can move. In August 2025, Google announced utility agreements targeting machine-learning workloads for demand response and reported reducing associated demand during three grid events in 2024. It also described shifting non-urgent tasks. These are specific operator disclosures, not proof that every AI workload can be interrupted economically.

I would qualify flexibility workload by workload. A batch job with deadline slack might be deferrable; an interactive service with a tight response-time commitment may not be. For training, examine checkpoint overhead, restart time and the cost of leaving accelerators idle. Moving work elsewhere also requires spare capacity, sufficient connectivity and permission to move the relevant data.

The useful deliverable is a tested operating specification: how many megawatts can be reduced, with how much notice, for how long, and at what recovery cost? Measure the reduction at the facility boundary rather than assuming that an application-level pause produces an equal grid benefit. Test the recovery period as well; deferred work still needs somewhere and some time to run. Do not promise flexibility to an energy supplier before the service owners have accepted those constraints.

Make site readiness a shared acceptance decision

Before approving an accelerator purchase, I would bring the AI platform lead, facilities engineer and energy-procurement lead to the same review. Their shared acceptance record should answer three questions:

  • What capacity can be delivered at commissioning, and which electrical or thermal conditions reduce it?
  • What evidence supports the next expansion date, and what happens if a dependency slips?
  • Who owns each unresolved constraint, including decisions that cut across facilities, software and energy procurement?

Compare candidate locations against the same workload, including the earliest usable power date, supported rack envelope, water restrictions, curtailment obligations and network constraints. Then price a delayed deployment and a restricted operating year, rather than comparing only steady-state electricity costs. If the preferred site wins only when every upgrade arrives on its earliest estimated date, examine the downside before discarding the alternative. This comparison also gives the business a concrete choice: wait, deploy less, change the workload or move.

The central planning question is straightforward: what work can this site reliably deliver under the conditions in which it will actually operate? A hardware count cannot answer it. Neither can an annual energy contract, a good PUE number or a promise of future cooling upgrades. AI capacity becomes real when those pieces work together.

The views expressed here are my own. This article does not represent the views, policies, practices, or technology stack of my employer, LinkedIn. All examples are based on public sources or explicitly hypothetical scenarios. 

# # #

About the Author

Silu Panda is a staff software engineer at LinkedIn, focused on AI infrastructure and model serving. His interests include reliable inference, distributed systems, and open source. He writes about evaluating, deploying, and operating AI applications.