Why this reaches you even if you never touch a data centre
Most AI teams buy capacity rather than build it, and it is tempting to file grid constraints under someone else's problem. That holds right up until it does not, and the transmission mechanism is fairly direct.
Power scarcity propagates into four things you do control. Region availability — a provider cannot sell you capacity in a region where it has not energised a connection. Lead time — reserved capacity that arrives two quarters late is a roadmap problem, not a procurement one. Price volatility — where power is contested, compute pricing becomes less predictable, and we have already seen GPU lease prices rise even as model prices fall, a divergence covered in the inference margin trap. And residency deliverability — if you have promised a customer that their data stays in a specific jurisdiction, you need capacity in that jurisdiction, and that is now a physical question rather than a configuration one.
The two markets this site covers are both constrained, using opposite instruments. Britain is rationing: Ofgem opened a consultation on 29 July 2026 proposing a refundable Data Centre Commitment Fee of £237,500 to £712,500 per megawatt — roughly 2.5% to 7.5% of average project costs — to clear speculative projects out of a connection queue that grew from 41 GW to 125 GW in under a year, at least 80 GW of it data centres. India is expanding: the government now projects AI data centres will add 26.3 GW of demand by FY32, against a March 2026 projection of 13.56 GW, with the load intended to be met primarily by renewables. We covered the detail in India doubling its own AI power forecast.
You do not need to track energy policy to plan well. You need a method that assumes capacity is contested and time-lagged, which is what follows.
Step 1: Classify every workload by what actually binds it
Almost every capacity plan improves the moment someone writes down which workloads genuinely cannot move. Most teams discover that the honest answer is fewer than they assumed.
| Class | What binds it | Typical examples | Region-portable? |
|---|---|---|---|
| Latency-bound | User-perceived response time | Interactive inference, autocomplete, live chat | No — must sit near users |
| Residency-bound | Legal or contractual commitment | Regulated customer data, public sector work | No — jurisdiction is the constraint |
| Gravity-bound | Cost of moving a large dataset | Training on a multi-terabyte corpus in place | Expensive, not impossible |
| Portable | Nothing structural | Batch training, evals, index rebuilds, offline enrichment | Yes — this is your flexibility |
The portable row is the asset. It is where you can chase available power, cheaper contracts and spare capacity, and every hour of load you can move into that row increases your negotiating position for the rows you cannot move.
Audit the residency-bound row hardest, because it is where teams over-classify. Organisations routinely mark a workload as region-locked based on a general policy rather than a specific obligation. Go and read the actual contract clause or regulatory requirement. Often the binding commitment covers personal data at rest, which leaves derived artefacts, embeddings, evaluation runs and model training on anonymised extracts genuinely portable. Our guide to data residency and request routing under DPDP and GDPR covers where the line actually falls.
Step 2: Interrogate the provider properly
Procurement conversations about AI capacity tend to focus on price per GPU-hour and instance availability. Those are the wrong first questions in a constrained market. Here is the list that separates a real commitment from an optimistic one.
- What is the energisation date, and what is the status of the grid connection agreement? This is the single highest-value question. Contracted capacity in a facility whose connection has not energised is an option on power, not power.
- Which substation does this capacity depend on, and is that dependency shared with your other customers? Concentration risk is invisible until it is not.
- For UK capacity: have you posted the commitment fee on this queue position? Once Ofgem's proposal lands in some form, a provider with skin in the game is making a materially stronger claim than one holding a speculative application.
- What is the power contract structure? Regulated tariff, corporate power purchase agreement, or green open access. This determines how volatile your costs are and whether you inherit someone else's exposure.
- What is the firming arrangement? If the answer is "primarily renewable", ask what runs when it is not generating. Storage, thermal backup or grid draw — each has different cost and carbon implications, and "primarily renewable" is a statement about an average.
- What is your contracted-to-live conversion rate historically? A provider that has delivered on schedule before is worth more than a cheaper one that has not.
- What happens to my capacity if you are oversubscribed? Ask for the allocation policy in writing. Everyone is priority until capacity is short.
You will not always get straight answers. The quality of the evasion is itself information — a provider who cannot tell you its energisation date usually does not have one.
Step 3: Contract clauses that actually protect you
Capacity contracts written in the GPU-scarcity era optimised for allocation. In a power-constrained era, the clauses that matter are about timing, substitution and price pass-through.
| Clause | What to ask for | Why it matters |
|---|---|---|
| Ramp schedule with milestones | Capacity delivered in dated tranches, not a single end date | Slippage becomes visible early rather than at go-live |
| Late-delivery remedy | Service credits or exit rights if a tranche misses by a defined margin | Converts a delivery risk into a priced risk |
| Region substitution right | Your right to take equivalent capacity in a named alternate region | Useful only for portable workloads — which is why Step 1 comes first |
| Energy price pass-through cap | A ceiling on how much energy-cost movement reaches your bill | Prevents an open-ended exposure to a market you cannot hedge |
| Oversubscription allocation policy | Written priority rules, not a verbal assurance | Determines what happens to you on the worst day |
| Data location warranty | Explicit jurisdiction commitment for residency-bound workloads | Your customer promise is only as good as this clause |
The region substitution right deserves a note. It is worth very little if your architecture cannot use it — which is why the engineering work in Step 4 is what makes the commercial term real.
Step 4: Engineer so a region change is an inconvenience
The goal is that moving a portable workload between regions is a configuration change and a data transfer, not a project. Four properties get you there.
Checkpoint everything long-running
Any training or batch job that runs longer than about an hour should checkpoint to object storage on a cadence that makes a mid-run interruption survivable. This is the same discipline that makes spot and preemptible capacity usable, and if you have already done that work you are most of the way there — see the checkpoint-resume playbook for spot and preemptible GPUs. A job you can resume elsewhere is a job that can follow available power.
Keep artefacts portable, not just code
Container images in a registry replicable to a second region. Model weights and datasets in object storage with a documented replication path. Configuration in code. The failure mode here is almost always something small and undocumented — a bespoke driver version, a hand-tuned kernel, a licence key pinned to a host — that nobody notices until the move.
Understand your data gravity honestly
Measure how long it would actually take to move your largest training corpus between the regions you care about, and what it would cost in egress. Do this once, write it down, and revisit annually. Teams routinely assume a move is impossible when it takes a weekend, or assume it is trivial when it takes three weeks and a five-figure egress bill.
Separate the control plane from the compute plane
If your orchestration, queueing and metadata live in one region while compute runs wherever capacity exists, you can shift compute without touching the system of record. If they are entangled, every region change touches everything. This is ordinary distributed systems design and it pays for itself the first time capacity moves.
Region portability and data residency pull in opposite directions, and the tension is real rather than something to design away. The resolution is not to make everything portable — it is to be precise about which workloads are genuinely bound and to stop paying the flexibility cost on the ones that are not. A team that treats all workloads as residency-bound because one of them is has given up its only source of capacity flexibility for no compliance benefit.
Step 5: Measure the things that will move
Three metrics belong on a capacity dashboard once power is the constraint.
Cost per successful task, tracked over time. Not tokens, not monthly spend. This absorbs retries, failures and clean-up, and it is the number that reveals a price increase reaching you through a provider's contract rather than through a headline. The method is in LLM unit economics and cost per task.
Headroom against contracted capacity. Not utilisation — headroom, expressed in weeks until you hit the ceiling at current growth. Utilisation percentages hide the thing you need to act on, which is time. Pair it with realistic load testing, covered in load testing and capacity planning for LLM apps.
Portable-workload share. The proportion of your compute hours that could move region within a week. This is your negotiating position rendered as a number, and watching it fall is an early warning that you are accumulating lock-in without deciding to.
Two worked examples
A UK fintech with a residency commitment
Customer contracts require personal data to remain in the UK. Interactive inference is latency-bound and UK-resident. But the team's nightly evaluation suite, its embedding regeneration and its fine-tuning runs all operate on anonymised extracts, and a careful read of the contract shows the commitment covers personal data rather than derived artefacts.
Reclassifying those three workloads as portable moves roughly 60% of compute hours out of the constrained UK pool. That matters commercially: the team now needs a smaller UK capacity commitment, which is precisely the capacity most affected by queue rationing, and can source the rest where capacity is available. The compliance position is unchanged and better documented than before.
An Indian GCC serving a European parent
The GCC runs model training and evaluation for a parent whose customers are in the EU. Training data is anonymised, so training is portable; the parent's inference must sit in an EU region.
Here the opportunity is the reverse of the UK case. Indian capacity is expanding rather than rationed, and subsidised routes exist — the IndiaAI Mission's GPU pool among them. The work is to make training genuinely region-independent so it can run where capacity is cheapest, while ensuring the artefacts it produces can be promoted into the EU inference region with a documented, auditable path. The engineering task is a clean artefact-promotion pipeline; the commercial payoff is training on the cheaper side of the map.
Planning cadence
- Quarterly: refresh the demand forecast, review headroom in weeks, recheck portable-workload share.
- Annually: re-run the provider interrogation list, review contract clauses at renewal, re-measure data gravity.
- Event-triggered: whenever a regulator consults or a government revises a projection. India's FY32 forecast moved by roughly 94% in five months during 2026; an annual planning cycle would have missed it entirely.
Every article here is written by a Verified Builder. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →Reserved, on-demand and the shape of your commitment
Grid constraint changes the reserved-versus-on-demand calculation in a way that is easy to get backwards.
The instinct under scarcity is to reserve more, and lock in capacity before someone else takes it. That instinct is right for the workloads you cannot move and wrong for the ones you can. A long reservation in a constrained region is expensive precisely because the capacity is contested, and you pay that premium on every hour whether you use it or not. For portable workloads, the same money buys more compute in a region where capacity is not contested, and the flexibility is worth keeping.
A reasonable default is a three-tier commitment shape. Reserve only for latency-bound and residency-bound baseline load, sized to your realistic floor rather than your peak — reserving to peak in a constrained region is the most common way teams overpay. Commit at medium term, typically annual rather than multi-year, for the predictable portion of portable load, in whichever region currently has slack. Leave on-demand and spot for burst and for anything genuinely elastic, which for most teams means evaluation runs, index rebuilds and experimentation.
Two things make this shape work in practice. The first is honest floor measurement: you need to know your genuine baseline rather than your comfortable one, which usually requires a quarter of clean utilisation data. The second is that the portable tier must actually be portable, which is the engineering in Step 4 — a medium-term commitment in a second region is only useful if you can run there without a migration project.
The carbon question is arriving alongside the capacity one
Worth flagging because it is about to become a procurement question rather than a reporting one. Where power is scarce, the distinction between annual renewable matching and hourly matching starts to matter commercially: a provider claiming renewable supply on an annual-volume basis may be drawing on high-carbon marginal generation precisely during the sustained, high-utilisation hours your training load creates.
If your organisation reports on emissions, or sells to customers who do, ask providers for the matching basis rather than the headline claim. Annual matching and hourly matching produce very different numbers for a workload with your load shape, and the gap is not something you can reconstruct later from an invoice. Ask early, because it is a much harder conversation to open at renewal.
Common mistakes
- Treating contracted megawatts as available megawatts. The energisation date is the real number.
- Reserving to peak in a constrained region. Reserve to your floor; buy the rest where capacity is not contested.
- Accepting an annual renewable claim without asking the matching basis. Your load shape is exactly where annual and hourly matching diverge.
- Over-classifying workloads as residency-bound. Read the actual clause. Most teams find derived artefacts are portable.
- Negotiating price without negotiating timing. A cheap contract that lands two quarters late is expensive.
- Buying a region substitution right you cannot exercise. The clause is worthless without the engineering.
- Tracking utilisation instead of headroom in weeks. One is a status, the other is a deadline.
- Assuming "primarily renewable" answers the firming question. Ask what runs when generation is low.
- Planning annually in a market revising forecasts quarterly. Set event triggers.
Next steps
Start with the classification exercise, because it is cheap and it changes the shape of every subsequent decision. Write down every workload, mark what genuinely binds it, and calculate your portable share. Most teams find it is higher than they assumed and that they have been paying a constrained-capacity premium on work that never needed to sit there.
Then take the provider question list into your next renewal conversation. Asking for an energisation date is a small thing that reliably surfaces whether the capacity you are being sold exists yet.