AI Data Center Power Constraints: Capacity Planning When the Grid Sets the Ceiling

The GPUs arrived before the transformer did. That is the version of the story most operators will not tell publicly, but it is the shape of the problem in 2026: an allocation secured, racks staged in a warehouse, and a utility interconnection study that will not clear for another eighteen months. The capital was never the hard part. Neither, at this point, are the chips. The hard part is a 230 kV substation with spare capacity and a delivery date you can put in a contract.

This is a change in what "capacity planning" means. For most of the last decade, planning AI infrastructure meant negotiating chip allocation and rack density. The chip conversation has not gone away, but it has stopped being the thing that decides whether capacity lands on schedule. RAND's analysis of what actually blocks US power expansion for AI points at the same set of physical and procedural bottlenecks rather than at money or silicon. If you are building, buying, or budgeting AI capacity, your plan needs to treat megawatts and calendar dates as first-class variables, because they now set the ceiling on everything else.

The bottleneck moved from allocation to energization

Start with scale, because the numbers explain why utility planners stopped being accommodating. Berkeley Lab's data center energy work put US data center consumption at roughly 176 TWh in 2023, about 4.4% of national electricity, with a 2028 range running as high as 12% depending on how the buildout lands. The IEA's Energy and AI report puts global data center demand near 415 TWh in 2024 and has it roughly doubling by 2030. Those are not marginal adjustments to a load forecast. They are new industrial loads showing up in territories that spent twenty years planning around flat demand.

The utility response is rational and slow. Load forecasts get revised, integrated resource plans get refiled, and every one of those steps has a statutory clock. Meanwhile the interconnection queue itself is congested from the generation side. Berkeley Lab's Queued Up research has tracked more than two terawatts of proposed generation and storage sitting in US queues, which is more than the entire installed US fleet, and found that the typical project reaching commercial operation waited about five years from its original request. FERC's interconnection final rule moved the process from serial first-come studies to cluster studies with firmer deadlines and financial commitments, which helps in the medium term and does very little for a site you need energized in 2027.

Equipment is the second clock. Large power transformers that quoted around a year pre-2020 are now routinely quoted in multiples of that, high-voltage breakers and switchgear are on similar curves, and gas turbine slots at the major OEMs are effectively sold out into the early 2030s. Bloom Energy's 2026 data center power report is a vendor document and should be read as one, but its central claim matches what developers say privately: the constraint has moved from generation capacity in the abstract to specific pieces of steel and copper with named delivery dates.

The takeaway is unglamorous. Your AI capacity plan is now a procurement and permitting schedule wearing a compute costume.

Four clocks decide your site date

Any serious site evaluation should produce four dates, not one. The latest of them is your real energization date, and the difference between the earliest and latest tells you where to spend management attention.

The fourth row is the one plans underweight. Municipal opposition does not show up in a spreadsheet until it kills a project, and it has become a live risk in exactly the counties that look attractive on every other axis. A site with a clean interconnection and a hostile zoning board is not a fast site.

Plan in megawatt-years, not megawatts

Nameplate megawatts is the wrong unit because it hides timing. The right unit is the megawatt-year: one megawatt of usable IT load, available for one year. It collapses size and schedule into a single comparable number, which is the only way to honestly evaluate a small site that energizes soon against a large site that energizes late.

Run it on two real options, over a four-year horizon from January 2027 to January 2031.

Option A. A 150 MW greenfield campus with a signed utility commitment and full energization in January 2029. Two years of availability inside the horizon. That is 300 megawatt-years.

Option B. A 60 MW phase at an existing substation with headroom, energized July 2027, expanding to 150 MW in January 2030. Two and a half years at 60 MW gives 150 megawatt-years, plus one year at 150 MW gives another 150. Also 300 megawatt-years.

The two options are equivalent on capacity delivered, and they are not remotely equivalent on risk. Option B produces revenue, operational learning, and a live customer reference eighteen months earlier. It also front-loads the schedule risk into a phase small enough to survive, while Option A concentrates every risk into one date in 2029 that four different parties have to hit.

Three refinements make the model usable:

• Use IT load, not utility load. Divide the grid-side megawatts by your design PUE. A 150 MW utility service at 1.25 PUE is 120 MW of IT load. Getting this wrong overstates capacity by 20% or more.
• Derate for ramp. Sites do not go from zero to full draw on energization day. Model a ramp curve, typically 6 to 12 months to full load, and count the area under it.
• Probability-weight the dates. Assign each site a P50 and P90 energization date, and compute megawatt-years at both. An option that looks strong at P50 and collapses at P90 is a bet on nothing going wrong, which is not the base case in this market.

This is the same discipline that applies to the rest of the buildout. We have written before about how the compute buildout's dependencies decide whether it lands on schedule, and power is the dependency with the longest and least compressible lead time.

The queue is not a line

The most common planning error is treating the interconnection queue as a ticket counter where position number predicts wait time. Under cluster study frameworks it does not. Requests get grouped, studied together, and the network upgrades get allocated across the cluster. Your outcome depends on three things that have nothing to do with your position:

1. Which cluster you land in. Withdrawals by other projects in your cluster can trigger restudies that reset your timeline, or can free up headroom that accelerates it. This is largely outside your control and should be modeled as variance, not as a point estimate.
2. What upgrades your request triggers. A request that fits inside existing substation and line capacity clears fast. A request that requires a new transmission line inherits that line's permitting timeline, which is measured in years and sometimes decades.
3. What flexibility you offer. Regions that permit non-firm or curtailable service can energize load far faster than firm service allows, because the utility does not have to build for your peak.

ERCOT is the useful case study, and not only because it moves fast. Its load forecasting and large load interconnection materials are published in enough detail that you can see the difference between requests that have signed agreements and requests that are aspirational. That distinction matters when a region's headline "gigawatts in the queue" number gets quoted back at you as evidence that capacity exists. NERC's reliability assessments apply the same skepticism at continental scale, and both are worth reading before you accept a developer's regional thesis.

Practical rule: rank candidate sites by the network upgrades they trigger, not by the power price they quote. At 85% load factor, a one cent per kWh price advantage on 100 MW is worth roughly $7.4 million a year. Two years of delay on the same 100 MW of AI capacity costs considerably more than a decade of that discount. Run your own version of that arithmetic before optimizing for tariff.

Flexibility buys schedule, not capacity

Behind-the-meter generation is the reflexive answer to the queue, and it is half right. On-site turbines or fuel cells can get you to first power sooner. They do not exempt you from air permitting, they require contracted fuel and often new gas laterals, and almost every one of these projects still needs a grid tie eventually. The honest framing is that behind-the-meter capacity buys 12 to 36 months of schedule at a cost premium. Price it as insurance against slip, and it usually pencils. Price it as a cheaper source of power, and it usually does not.

Load flexibility is the more interesting lever, and it is badly underused. Duke's Nicholas Institute published the finding that should reset this conversation: US systems could accommodate roughly 76 GW of new load if that load agreed to curtail 0.25% of hours, which is about 86 hours a year. That is enormous headroom in exchange for a concession that most AI workloads can absorb.

The reason it is underused is that flexibility has to be a contract term, not an operational aspiration. Committing to curtail requires knowing, in advance, which of your workloads can pause. Training runs with checkpointing can shift. Batch inference and evaluation jobs can shift. Latency-bound production inference generally cannot. If you have never classified your workloads that way, you cannot credibly sign a curtailable tariff, and you will end up paying for firm service you did not need.

Storage co-location changes the same math, which is why we track daily CAISO storage behavior as a leading indicator of how much flexible headroom actually exists in a constrained market. The pattern that shows up there also shows up in siting: the hours when the grid is tight are few, predictable, and concentrated. Designing for them is cheaper than building around them.

A siting scorecard you can run this week

Score each candidate site on these seven items. Anything scoring poorly on the first three is not a 2027 or 2028 site regardless of how well it does on the rest.

Two notes on using this. Weight the top three so heavily that they can veto, because they are the only ones that can move your date by years. And rescore quarterly, since the answers change: a cluster restudy or a cancelled neighboring project can move a site up or down a full tier without any action on your part.

The physical dependency chain does not stop at the substation, either. The same lead-time logic applies upstream to the materials and manufacturing that feed it, which we covered in why AI's real bottleneck is materials, and it is the reason to be skeptical of technology narratives that promise to route around the constraint, as in our superconducting data center reality check.

If you buy compute rather than build it

Most organizations reading this will never file an interconnection request. The constraint still reaches them, through pricing, through allocation, and through provider commitments that quietly slip. Four things to do:

• Diligence your provider's power, not their GPUs. Ask for the interconnection milestone and the equipment POs. A provider who will not share the study status is telling you something.
• Get a remedy for slip. If your capacity commitment starts on an energization date, negotiate what happens when that date moves. Credits, alternative region placement, or a right to exit.
• Classify your workloads by latency tolerance now. This unlocks cheaper interruptible capacity from providers who have it, and it is the same classification you would need to sign a curtailable tariff yourself.
• Assume regional concentration is a risk. If all your capacity sits in one interconnection region, one restudy or one moratorium is a single point of failure.

Sanity-check regional load assumptions against public data rather than vendor decks. The EIA's outlooks and electricity data are unglamorous and unbiased, which makes them a decent referee when a provider's growth story and a utility's filing disagree.

How OpenNash Can Help

The capacity model above is a systems problem, and it is the same class of work we do on the software side: map the real dependency chain, put guardrails and decision points where the risk actually sits, and hand over something the client owns and can operate. For teams planning AI capacity, that usually means building the megawatt-year model against your actual workload mix, classifying which of your training and inference jobs are genuinely shiftable, and instrumenting the provider commitments so a slipping energization date shows up in your planning six months early instead of the week it hits.

If you are on the buying side, the higher-leverage work is often upstream of infrastructure. Cutting the compute a workflow needs by restructuring it, batching what does not need to be interactive, and routing by task rather than defaulting every call to the largest model changes how much capacity you have to secure in the first place. Book a call to map this to your workflow.

Build the four-clock table for every site you are considering, this week, and put a name next to each date. The sites where nobody can name the owner of a date are the ones that will slip.