AI infrastructure conversations usually begin with accelerators. In practice, a data center can have building space and a hardware order yet still be unable to run the workload because the electrical connection is not ready. Power is a physical dependency, not a detail to add at the end.
The short answer
An AI campus needs a reliable electricity supply, substations, transformers, backup systems, cooling, and a contract that defines availability and cost. A gigawatt announcement describes potential electrical capacity, not automatically usable compute. The delivery timeline depends on grid access, permits, equipment, and construction.
Why a grid connection is not enough
A utility connection can be approved before the site has the equipment to receive that power. Transformers and switchgear may have long lead times. The building may also need upgrades before dense accelerator racks can be installed safely.
Cooling changes the equation. More compute creates more heat, and cooling consumes part of the site’s electricity. Water availability, ambient temperature, and the chosen cooling design affect how much of the headline power becomes useful compute.
This is why I separate contracted power, delivered power, installed IT load, and actual workload utilization. They are four different measurements. A 2-year wait between an agreement and an operating cluster is possible when a project depends on several infrastructure suppliers.
The contract questions
Ask who pays for grid upgrades, who owns the substation, what happens during curtailment, and whether electricity pricing is fixed or indexed. Also ask whether the customer pays for reserved power even when servers are idle. These terms influence margins more than the headline site size.
A developer does not need to read a power-purchase agreement to understand the risk. Look for commissioning dates, capacity in service, power usage effectiveness, and the proportion of the site actually allocated to productive workloads.
What this means for AI products
Power constraints can affect model availability, regional pricing, and launch schedules. A provider with multiple sites may route traffic around a local problem, but that can increase latency or cost. Products should treat region and provider as observable configuration, not hidden assumptions.
Record the region, model, latency, error rate, and retry count for every request. Run a representative 2-hour test after a provider changes its hardware or region. A lower advertised price is not an improvement if retries double.
Reading capacity announcements carefully
OpenAI’s compute infrastructure article names land, power, permits, and workforce as core build requirements. The Stargate and SB Energy announcement shows how leases and infrastructure partners can be combined. NVIDIA’s AI financing announcement illustrates why capital and physical delivery are linked.
The useful takeaway
When you see a large AI capacity target, ask “when is the power live, and how much is being used?” That question turns a striking number into an operational timeline and helps both engineers and investors avoid counting unfinished infrastructure as production capacity.
Spend 2 hours checking the utility, construction, and commissioning milestones before comparing two data-center plans. A larger announced site is not necessarily a faster or cheaper site.
Sources and limits
OpenAI’s compute infrastructure article names land, power, permits, and workforce as core build requirements. The Stargate and SB Energy announcement shows how leases and infrastructure partners can be combined. NVIDIA’s AI financing announcement illustrates why capital and physical delivery are linked. Public announcements do not establish that every planned megawatt is already serving customers.
The same caution applies to local claims about cheap power. A low energy rate can be offset by transmission upgrades, demand charges, cooling, backup generation, or a long connection queue. Good analysis follows the complete delivered-cost path rather than quoting the utility rate alone.
Ask for the commissioning schedule and update the analysis when the site moves from promise to operation. Physical delivery is the proof.
That proof should include measured output, not only a ribbon-cutting date.
It should also show stable service over time.
Discussion
What would you try, change, or challenge after reading this guide? Specific results and errors help the next reader.
Comments will load as you reach this section.