FERC’s PJM decision separates load visibility from curtailment authority
The growth of AI infrastructure is making electricity demand harder to forecast and plan around. Large data centers can require hundreds of megawatts, ramp up over time, and depend on power arrangements that affect regional reliability planning.
On October 9, 2026, the Federal Energy Regulatory Commission (FERC) took a step toward improving visibility into that demand. It approved PJM Interconnection’s definition of a “Large Load” and its proposed Large Load Registry. At the same time, FERC rejected much of PJM’s broader proposal for providing interim service to new large loads, including provisions related to curtailment. (elibrary.ferc.gov, utilitydive.com)
The decision highlights an important regulatory distinction: collecting information about large electricity users is different from deciding when their service can be interrupted.
What the registry is meant to show
PJM’s approved definition covers end-use customer load with a cumulative peak of at least 50 megawatts at a single electrical site. The registry is designed to collect information such as a facility’s location, ramp schedule and capacity supply. That information can help PJM understand how large loads may affect forecasts and reliability planning. (elibrary.ferc.gov, utilitydive.com)
A registry improves visibility. It can help answer questions such as:
Where is major new demand expected to connect?
How quickly is that demand expected to ramp up?
What capacity supply is associated with the load?
Those are important planning questions. But data collection does not itself create an operational curtailment rule or settle which regulator has authority over a retail customer’s service.
Why FERC rejected the broader proposal
PJM’s filing also proposed an Interim Resource Adequacy Service framework for certain new large loads. Under parts of that proposal, eligible loads that did not bring their own new capacity could face load-reduction requests as the system approached an emergency.
FERC rejected that framework. The Commission said several provisions appeared to place obligations directly on large loads that are, for the most part, retail customers; to dictate which retail customers would be curtailed; and to establish a retail compensation rate. It also found that PJM had not adequately shown that the proposed treatment of those loads would avoid undue discrimination. (utilitydive.com)
This is where jurisdiction matters. FERC oversees interstate transmission and wholesale market rules. States have a central role in regulating retail electricity service, including determining which retail customers may be curtailed when the system is stressed. FERC’s order treated the issue as a shared regulatory challenge, not as a simple question of whether grid operators can see or manage demand. (utilitydive.com)
What the decision does—and does not—mean
The order does not mean large data centers are exempt from every form of curtailment, or that emergency load reduction is off the table. It addresses the specific tariff framework PJM proposed in this filing. FERC also gave PJM direction on issues it would need to address if it revises and resubmits parts of the proposal. (utilitydive.com, headwaterswire.com)
The distinction is between three separate layers:
Visibility: identifying large loads and gathering information about them.
Grid operations: maintaining system reliability as supply and demand change.
Decision rights: determining which customers can be asked or required to reduce demand, under what rules, and with what protections.
The registry advances the first layer. The order shows that the third requires careful coordination across federal and state authority, as well as rules that can be defended as fair.
The governance question behind AI power demand
For AI infrastructure, the practical issue is not only how much electricity a facility may use. It is also whether the grid and regulators have clear, workable rules for what happens when demand exceeds available supply.
That requires a complete chain: reliable information about large loads, transparent criteria for reliability actions, clear responsibility for issuing those actions, and consistent treatment across customer classes. Without that chain, the grid may know where demand is growing while decision-makers remain uncertain about who can require it to change.
The registry can help the grid see the load. It cannot, by itself, determine who has authority to control it.
Source: FERC, Docket ER26-3515-000, order issued October 9, 2026.
AI infrastructure discussions often begin with the most visible asset: the accelerator. How many GPUs or other AI processors can a company buy, and when can they be installed?
But installed capacity is only part of the equation. Those processors must also exchange data, coordinate work, and receive instructions from the software stack. If those connections cannot keep pace with the workload, adding more processors may not deliver a proportional increase in useful compute.
That makes networking and integration a growing part of the economics of AI infrastructure.
Compute depends on more than the processor
An AI cluster is a system of connected components. Processors move data between memory, storage, and other processors while workloads are divided, coordinated, and recombined. The network affects how quickly those exchanges happen and how well the system handles congestion or failures.
Two networking jobs matter here. Scale-up networking connects accelerators within a pod or rack. Scale-out networking connects systems across racks and throughout a data center. A workload can depend on both.
When data movement or coordination becomes a constraint, some processors may wait for information or for other parts of the workload to finish. The hardware is present, but its potential output is not being fully realized. That can weaken the return on expensive infrastructure investments and complicate capacity planning.
What Token Fabric is trying to do
On October 8, Nvidia-backed Upscale AI introduced Token Fabric, a networking architecture intended to support AI processors from different suppliers. The company describes it as a combination of scale-up and scale-out networking, systems, and shared software for managing operations. Reuters reported that the platform is expected to roll out in stages, with the first component planned for the fourth quarter and the broader platform through 2027. Upscale says general availability is planned for early 2027. (reuters.com, upscale.com)
The proposal addresses a practical challenge for operators: networking has often been assembled from separate components that customers must integrate and manage. A more unified approach could simplify parts of that work and make it easier to build clusters containing different types of accelerators.
That is the opportunity. It is not yet proof that the architecture will deliver a specific utilization gain or make mixed-vendor systems simple to operate. Those results will depend on deployment conditions and independent performance evidence.
Interoperability is useful, but it is not automatic
The possibility of using multiple accelerator suppliers is attractive for organizations that want more choice in hardware procurement or want to match different processors to different workloads. It could also reduce reliance on a single hardware ecosystem.
However, networking compatibility is only one part of interoperability. A system still needs suitable software frameworks, drivers, compilers, memory behavior, and workload orchestration. Operators must also understand how performance changes when different processors share a system.
In other words, “connects different processors” does not necessarily mean every processor can be substituted freely, or that every workload will run equally well across all of them. The relevant test is whether the full system performs reliably and economically for the workloads a customer actually runs.
The business metric is useful output
For decision-makers, the central question is not simply how many processors are installed. It is how much useful work the organization gets from the complete system, at what cost, and with what operational burden.
That means evaluating utilization alongside measures such as workload throughput, latency, energy use, network performance, software compatibility, and the cost of operating the environment. A network upgrade that improves one technical metric may not improve the business outcome if it adds complexity or fails to support the applications that matter.
The same discipline applies to claims about future capacity. Product roadmaps and announced availability dates are signals about where vendors are investing. They are not substitutes for customer deployments, workload-level results, and independently reviewable performance data.
The next bottleneck is system-level
AI infrastructure is moving beyond a simple race to install more chips. The economics increasingly depend on how compute, networking, software, power, and operations work together.
Token Fabric is one example of vendors trying to address that system-level problem and support more heterogeneous infrastructure. The broader industry question is whether these architectures can make processors easier to connect and keep productively occupied—without creating new integration and management burdens.
The next generation of AI capacity may be shaped not only by how many chips organizations can obtain, but by how effectively those chips can work together.
AI’s next capacity gain may come from coordinating existing infrastructure more effectively. The harder question is whether shared capacity can be made dependable enough to use.
AI compute is often described as scarce—and for many organizations, it is. But scarcity can exist alongside underused equipment. Some data centers may have capacity that is idle between workloads, while startups and researchers struggle to secure the right chips at the right time.
The National Compute Grid initiative, announced October 7, aims to connect capacity across providers through shared scheduling. The idea is to make it easier to find available computing resources and match them with workloads, potentially improving access to infrastructure that already exists.
That could add a useful layer to the AI infrastructure market. It does not mean every idle GPU can immediately be combined into a reliable pool—or that shared scheduling makes new data centers unnecessary.
The opportunity is coordination
A GPU sitting unused at one facility cannot automatically help a team whose workload is running elsewhere. Capacity is distributed across providers, hardware types, locations, software environments, and commercial agreements.
A shared scheduling layer could help bridge some of those gaps. In principle, it could show what capacity is available, help match workloads to suitable hardware, and coordinate access across participating providers. The initiative’s organizers have described a network that would pool capacity from labs, cloud providers, and different chip systems.
If it works, the value may be more than simply “more GPUs.” Better coordination could make capacity easier to discover, allocate, and use—especially for organizations that cannot secure large, long-term compute contracts.
“Available” does not always mean usable
A headline capacity figure can describe resources that are connected, planned, or otherwise in sight. That is not the same as compute that a customer can access continuously, at a known price, with a guaranteed performance level.
The initiative’s reported figure of roughly 760 megawatts, for example, was described as capacity “connected or in sight,” alongside a goal of reaching 2 gigawatts by 2030. Those are organizer-reported figures, not proof that all of that capacity is currently available to run customer workloads.
The initiative’s current website describes its capacity figures as dated planning estimates and says access is limited to public-sector partners during a preview. That is a useful reminder to distinguish a developing network and its stated plans from a mature, broadly available service.
The same care applies to utilization statistics. The consortium’s paper reportedly estimates that independent, single-tenant data centers average less than 15% net computing utilization. That figure should not be read as meaning that 85% of all GPUs are sitting idle and ready to be reassigned. Utilization can be measured in different ways, and unused time does not by itself establish that hardware is compatible, accessible, or suitable for another organization’s workload.
Workload fit matters as much as capacity
A pool of GPUs is not automatically a single large cluster. Large training runs can depend on fast networking between thousands of GPUs. If resources are spread across facilities, data movement, network performance, and coordination can limit what workloads are practical. Different chip architectures can also require changes to software and tooling.
Shared compute may therefore be useful first for workloads that can tolerate more flexibility: research jobs, inference, or smaller training runs. Whether a distributed pool can reliably support the most demanding jobs remains an operational question.
The details to watch are concrete:
Availability: Can users get capacity when they need it, and for how long?
Performance: Does the workload complete at the expected speed?
Continuity: What happens if a provider withdraws capacity or a job is interrupted?
Compatibility: Can the workload run across the available chip and software environments?
Data movement: How long does it take to move datasets to the compute—and what does that cost?
Accountability: Who is responsible when capacity is unavailable or performance falls short?
These are not minor implementation details. They determine whether shared capacity behaves like a dependable service or simply appears in a capacity forecast.
A new infrastructure layer, with evidence still to build
The National Compute Grid points toward a broader market question: can software coordination make existing infrastructure more productive and more accessible?
If the answer is yes, some organizations may get useful compute without building their own facilities or negotiating large dedicated contracts. That could expand access and improve the use of resources already deployed.
But the evidence that matters will come from operations: how much capacity is actually available, what workloads it supports, how reliably jobs complete, and whether performance and cost meet users’ expectations.
The next phase of AI infrastructure may include both new buildings and better coordination of existing ones. A shared scheduler can help connect supply and demand. It cannot make every GPU interchangeable—or turn a planning estimate into dependable compute by itself.
The measure of success is not how much capacity a grid can name. It is how much useful work users can reliably complete with it.
As enterprises move toward interconnected AI systems, the infrastructure responsible for governing agent behavior could become a strategically important part of the technology stack.
The next stage of enterprise AI adoption
Enterprise artificial intelligence is entering a more complicated phase.
For years, organizations concentrated on acquiring AI capabilities, experimenting with language models, automating individual tasks, and measuring productivity improvements.
Those activities remain important. However, the architecture of enterprise AI is changing.
Instead of deploying individual assistants that operate within relatively narrow boundaries, organizations are exploring networks of AI agents capable of interacting with multiple applications and executing increasingly complex workflows.
This creates opportunities for operational efficiency, but it also introduces new requirements for coordination, security, financial oversight, and accountability.
A recent development involving Tata Consultancy Services illustrates where this market may be heading.
TCS is developing an enterprise AI governance layer
According to reporting published October 12, 2026, Tata Consultancy Services is developing a governance layer designed to manage AI agents operating across enterprise technology environments.
The proposed architecture would coordinate agents developed internally, by customers, and by third-party providers.
It is intended to support orchestration, security, deployment management, and cost oversight across enterprise applications, including platforms such as SAP, ServiceNow, and Oracle.
This is a notable architectural direction.
Instead of treating every AI agent as a separate deployment requiring independent management, an enterprise control plane can provide a shared supervisory layer.
The concept is especially relevant as organizations introduce agents from multiple vendors, each with different capabilities, permissions, and operating requirements.
The more distributed the AI ecosystem becomes, the more valuable consistent oversight may be.
From model governance to system governance
Traditional AI governance frequently concentrates on individual models.
Organizations assess model accuracy, reliability, fairness, security, and performance. These evaluations remain essential.
However, governing an interconnected system of agents requires additional considerations.
Consider a hypothetical financial institution using several AI agents.
One agent analyzes customer information. Another evaluates documentation. A third prepares a recommendation. A fourth initiates an operational workflow.
Each agent may perform its assigned function correctly.
But that does not automatically establish that the complete workflow was properly authorized, that information was transferred appropriately, or that the final action complied with institutional policy.
The governance challenge now exists between the agents as well as within them.
This introduces a need for controls that operate across applications and workflows, not merely within individual models.
Five capabilities that could define an enterprise AI control plane
1. Agent identity and authorization
Organizations need to establish which agents are operating, who owns them, what resources they can access, and which actions they are permitted to perform.
An agent’s technical capability should not be confused with its authority to act.
2. Cross-system policy enforcement
Enterprise policies should remain applicable as workflows move between applications, models, and service providers.
Centralized policy administration can improve consistency, but enforcement must occur at the appropriate execution boundaries.
3. Operational observability
Organizations need visibility into agent interactions, decisions, exceptions, and system dependencies.
Observability helps identify unexpected behavior. However, monitoring alone does not establish that preventive controls are effective.
4. Financial accountability
As agents consume computing resources, invoke external services, and initiate transactions, cost management becomes an operational concern.
A control plane could help enterprises associate AI resource consumption with business activities, departments, and measurable outcomes.
5. Evidence and decision traceability
For regulated or high-consequence environments, organizations may need to reconstruct the sequence of events behind an AI-assisted action.
That requires reliable records connecting the relevant agent, input, policy, decision, authorization, and resulting action.
Without that continuity, an organization may possess extensive logs while still struggling to demonstrate accountability.
The commercial significance of governance infrastructure
TCS reported $3.1 billion in annualized AI revenue for the quarter ending September 30, 2026, representing more than 10% of its overall revenue.
This figure covers its broader AI business rather than revenue from the governance layer specifically.
Nevertheless, the combination of growing AI-related business and investment in governance architecture is commercially significant.
It suggests that enterprise AI opportunities increasingly extend beyond model development and application deployment.
As organizations scale their AI operations, they may require specialized capabilities for integrating, supervising, and controlling those systems.
Potential sources of commercial value include enterprise platform integration, managed governance services, compliance reporting, cost optimization, and continuous operational assurance.
The strategic opportunity is not necessarily a single universal governance platform.
Different organizations will maintain different technology stacks, risk tolerances, regulatory obligations, and operational requirements.
The opportunity lies in providing consistent control across those differences.
Centralization introduces its own governance risks
A centralized AI control plane is not automatically a complete governance solution.
In fact, consolidating oversight introduces additional design questions.
What happens if the control plane becomes unavailable?
Can agents continue operating without authorization checks?
Are enforcement policies applied consistently across vendor boundaries?
Can an administrator alter policies or records without an appropriate approval process?
How does the organization distinguish between a policy that was configured and a policy that was actually enforced?
These questions illustrate why governance architecture must be evaluated on observed behavior rather than declared capability.
A control plane should not become another layer of software that reports confidence without producing evidence.
The strongest architectures will distinguish policy administration, enforcement, monitoring, and independent verification.
They will also preserve appropriate human authority over consequential decisions.
Implications for financial institutions and regulated enterprises
Financial institutions provide a particularly relevant example because their operations already depend on established accountability, risk management, and control frameworks.
As AI agents become involved in customer operations, compliance analysis, credit processes, and internal decision support, institutions will need to understand how agent activity interacts with existing governance obligations.
Model risk management, information security, operational resilience, third-party oversight, and audit functions cannot operate as completely disconnected disciplines when AI agents cross their boundaries.
An enterprise control plane could provide a valuable coordination mechanism.
However, it should complement rather than replace independent validation, human approval requirements, and established lines of accountability.
The objective is not to centralize every decision.
It is to establish consistent visibility and enforceable boundaries while preserving appropriate responsibility for outcomes.
The distinction between AI capability and governed execution
One of the most important lessons emerging from enterprise AI adoption is that technical capability does not automatically establish operational readiness.
An agent may be able to perform a task.
That does not establish whether the task should be performed, under what conditions, or with whose authorization.
Similarly, a governance platform may be able to observe activity without necessarily preventing unauthorized behavior.
The architecture must distinguish among three separate functions:
Orchestration: Coordinating which agents perform activities and how workflows proceed.
Governance enforcement: Applying permissions, policies, restrictions, and escalation requirements.
Independent assurance: Verifying that the controls operated as intended and that the supporting evidence is reliable.
These functions may be integrated technologically, but they should remain conceptually distinct.
Conclusion: The next enterprise AI advantage may be governability
TCS’s developing enterprise AI governance layer is an important signal in the evolution of the enterprise AI market.
It reflects a shift from managing isolated AI capabilities toward supervising increasingly interconnected AI operations.
The commercial implications could be substantial, particularly for organizations facing complex technology environments and significant accountability requirements.
But the value of an AI control plane should ultimately be measured by more than the number of agents it coordinates.
Its effectiveness depends on whether it can enforce boundaries, preserve accountability, manage operational exposure, and provide defensible evidence of what occurred.
The next stage of enterprise AI competition may therefore be shaped by two questions.
How effectively can organizations deploy intelligent systems?
And how confidently can they demonstrate that those systems remain under control?
Enterprise AI may scale through agents. Sustainable enterprise AI will depend on the ability to govern them.
Sources
Tata Consultancy Services, Q2 FY2027 Financial Results, October 8, 2026.
Financial Express, TCS Bets on Governance Layer to Scale Enterprise AI, October 12, 2026.
TCS, Annual Report 2025–26, enterprise AI strategy and control-plane architecture.
The AI infrastructure conversation has been dominated by scale: more data centers, more generation, more chips, more gigawatts.
Scale is still essential. AI workloads need enormous amounts of compute and power. But a large capacity announcement does not, by itself, mean a project can be financed, built, connected, and operated on a dependable schedule.
That gap is moving to the center of the conversation.
A project’s real value depends on several linked conditions: a site that can be developed, power that can be delivered, equipment that can be procured, financing that can support the timeline, permits that can be secured, and a community willing to live with the project. If one critical dependency remains uncertain, the announced capacity may be far from usable compute.
The signals are converging
Recent developments point toward a more coordinated approach to AI infrastructure.
In the United States, utility and regulatory processes are placing greater emphasis on whether large-load projects are financially ready and accountable for the infrastructure costs they create. Texas has adopted financial security requirements for large-load interconnection requests, while federal regulators have also focused on cost recovery and protections for existing customers.
In Japan, a project involving JERA, Dell, and RHAELM brings together power capabilities, a site, data-center development, financing, and AI infrastructure. The project illustrates the appeal of planning these components as an integrated deployment rather than treating them as separate problems to solve one by one.
Developers are also pursuing onsite generation. Recent reporting describes growing interest in smaller gas turbines and other behind-the-meter options, partly in response to equipment lead times and the challenge of securing grid connections. Onsite power may offer a different schedule path, but it does not erase the trade-offs: fuel supply, permitting, emissions, cost, and the eventual relationship with the grid still matter.
Community relationships are becoming a more visible part of the infrastructure strategy as well. AWS recently announced a multiyear investment in programs for communities near its U.S. data centers. These commitments do not guarantee public support, but they show that local impact and engagement are now part of the deployment conversation.
From announced capacity to predictable dependencies
These examples are different, but they point in the same direction: the challenge is no longer just assembling enough capacity. It is coordinating the conditions that allow capacity to become operational.
That means executives may need to ask a broader set of questions:
Is the power timeline credible, and what assumptions does it depend on?
Who pays for the upgrades needed to serve the load?
Are land, permits, equipment, and financing progressing on compatible schedules?
If grid power is delayed, what alternatives are available—and what new risks do they create?
How are local costs, benefits, and concerns being addressed?
These questions do not replace the traditional focus on capacity. They make the capacity claim more useful by connecting it to execution.
Certainty as a competitive advantage
“Certainty” here does not mean that every project outcome is guaranteed. Large infrastructure projects will always involve uncertainty.
It means that fewer critical dependencies are left unresolved, that assumptions are visible, and that decision-makers have a credible plan for what happens when conditions change.
As AI infrastructure scales, the strongest projects may not be the ones with the largest headline number. They may be the ones that can show how power, capital, land, equipment, compute, and community considerations fit together—and how the project can move from announcement to operation.
The optimization target is shifting from “How many gigawatts can we announce?” to “How many dependencies can we make predictable?”
In AI infrastructure, certainty is becoming part of the product.
A facility’s protection systems are designed to respond when power conditions move outside safe limits. But when a very large load disconnects or transfers to backup power at once, that protective response can become a grid-level event.
That is the issue behind PJM’s proposed ride-through requirements for large computational loads, including data centers and cryptocurrency-mining facilities.
In July 2026, about 3,800 MW of data-center load in northern Virginia transferred from the PJM grid to on-site backup generation after a transmission fault. PJM and Dominion reported voltage and frequency spikes. Operators took action to restore the balance between generation and demand, and PJM reported no significant reliability impacts from the event.
The mechanism is straightforward. If a large amount of demand suddenly leaves the grid while generation remains online, generation temporarily exceeds load. That imbalance can push frequency upward. Voltage can also rise, with the system response depending on the location, size, and timing of the load change.
This does not mean every sudden load transfer will destabilize the grid or cause an outage. The July event was managed. The concern is that repeated or larger events can create operational challenges, especially when the grid has little time to adjust.
PJM presented a proposal, not a final rule, on September 8. It would set performance expectations for how large computational loads respond within defined voltage and frequency disturbance ranges. It also addresses recovery: after voltage returns to an acceptable range, the proposal calls for load consumption to recover to more than 90% of its pre-disturbance level within two seconds, subject to the proposed conditions.
The regulatory status matters. FERC’s June 18 show-cause order asked PJM to address questions about its large-load processes, including whether tariff requirements are needed for ride-through, ramp rates, and load restoration. PJM says it plans to file proposed solutions with FERC in November. The specific ride-through requirements remain under review.
For facility owners and engineers, this shifts the design conversation. The question is not only whether the facility can ride through a disturbance internally. It is whether the combined facility response—its protection settings, power systems, backup transfer, and recovery behavior—will be predictable and compatible with grid needs.
The distinction is important: a protective action can make sense for a single facility and still create a larger system challenge when many facilities react together. As large loads become a bigger part of grid planning, their disturbance response is becoming part of the infrastructure performance discussion.
Source note: PJM proposal and FERC filing timeline; PJM’s account of the July 22 event. Citations above.
For much of the recent discussion about artificial intelligence and electricity, the central question has been how much new power the country can produce.
That question is essential. Data centers, manufacturing, transportation, and other forms of electrification are adding pressure to the power system. More generation can help meet that demand.
But generation is only one part of the system. Electricity must also move from where it is produced to where it is needed, at the time it is needed, within the limits of the network.
That brings a second question into focus:
How efficiently can the existing grid move electricity to the places where demand is growing?
Capacity is not the same as deliverability
A grid can have electricity available somewhere in the system and still face difficulty delivering it to a particular location. Transmission congestion, constraints on individual lines, and limited transfer capability can affect how much power can move between regions.
In practical terms, this means that the amount of electricity a system can generate does not, by itself, tell us how much electricity a particular customer or facility can reliably receive. Location and delivery capability matter too.
This distinction is especially relevant to AI infrastructure. Data centers need large amounts of electricity at specific sites, often on demanding timelines. A national supply figure alone cannot tell a project developer whether power can reach a particular location, or when the necessary network upgrades will be complete.
DOE’s investments highlight the delivery side
The U.S. Department of Energy recently announced investments across 26 states. DOE says project recipients are expected to reconductor or rebuild more than 1,500 miles of transmission lines and deploy grid-enhancing technologies across nearly 21,000 miles. Together, the projects are expected to make more than 23 GW of additional electricity capacity available.
These figures describe a mix of transmission upgrades and technologies intended to improve use of the existing grid. They do not mean that all grid constraints are solved, or that new generation and new transmission will no longer be needed. They do show that improving the performance of existing infrastructure is part of the response to rising demand.
Some grid-enhancing technologies help operators understand or control the network more precisely. Dynamic line ratings, for example, use current conditions to estimate how much electricity a line can safely carry. Power-flow control devices can help redirect electricity toward lines with available capacity.
These measures can help unlock capacity in existing corridors. Their usefulness depends on the specific line, operating conditions, system needs, and the ability of grid operators to deploy and manage the technology.
The value of throughput
It may help to think of the grid as a network with both supply and movement constraints. Adding electricity is one way to increase what the system can serve. Improving the movement of electricity is another.
For executives and infrastructure planners, that suggests a more complete set of questions:
Is generation available?
Can the grid transfer it to the relevant region?
Can it be delivered to the specific site?
Will it be available at the times the load needs it?
What upgrades are needed to make that delivery reliable?
These questions are connected, but they are not interchangeable. A project may have access to a potential energy supply while still depending on transmission work, interconnection steps, or local network upgrades before that power is deliverable.
For large electricity users, this has implications for site selection, project schedules, utility coordination, and the cost of bringing infrastructure online. The grid’s ability to move power can influence whether a location is practical, how quickly a project can be served, and what additional investment may be required.
A broader view of the AI power question
The discussion should not become a contest between building new infrastructure and improving existing infrastructure. Growing demand may call for more generation, new transmission, upgrades to existing lines, and better tools for operating the system.
The strategic point is that grid size and grid performance are different parts of the same challenge.
As AI infrastructure expands, the value of the grid may increasingly be measured not only by how much electricity it can produce or connect, but by how effectively it can move that electricity to the right place at the right time.
The supply question remains important. The delivery question is becoming just as important.
AI infrastructure risk is moving from the grid connection into the contract
A data center can be announced. It can attract financing, begin construction and have a major customer waiting for capacity. Yet those facts do not, by themselves, establish that the facility will have the power it needs when it is supposed to become operational.
A recent report about Oracle’s Project Jupiter in New Mexico puts that gap into contractual terms.
Reuters reported on September 24 that Oracle issued a force-majeure notice to a Blue Owl unit connected to the project, citing potential delays in securing power. Reuters also reported that securing power for the site is Oracle’s responsibility under the contract. Oracle said the project remained on its planned schedule, and Blue Owl said the notice did not change its financial commitments. (reuters.com)
That combination deserves a measured reading. The notice does not prove that the project has failed, that power is unavailable, or that the 2028 target will be missed. It does show that uncertainty around power timing has reached the parties’ contractual relationship.
That is the larger signal.
Planned capacity and operational readiness are different claims
Infrastructure announcements often combine several stages into one story: investment committed, land secured, construction underway, customer demand identified, power planned.
Those are meaningful milestones. But they do not all answer the same question.
“Planned” capacity is not necessarily capacity that has been secured. A power arrangement is not necessarily proof that electricity will be available at the required scale and date. And a building nearing completion does not automatically mean the facility is ready to deliver computing capacity.
Each step needs its own evidence.
For an AI data center, the sequence may involve site development, permits, fuel or grid supply, generation or transmission infrastructure, electrical equipment, commissioning, and the final handoff into operations. A delay in one part can affect the schedule for the whole project.
When power timing reaches the contract
Electricity is often discussed as an operating cost: a major expense that grows as computing demand increases. But power availability can matter before a facility begins operating.
If the power timeline affects a project’s ability to meet an operational milestone, the consequences may include delayed revenue, changed payment timing, pressure on financing assumptions, or disputes about which party carries the cost of the delay.
In the Project Jupiter case, Reuters reported that Oracle’s notice could allow it to delay payments if the data center were derailed and did not come online as planned. The report also said the notice did not amount to Oracle exiting as the main tenant. Blue Owl said its financial commitments were unchanged. (reuters.com)
The precise effect depends on the contract and how the parties resolve the notice. The broader point does not: power risk can become delivery risk, and delivery risk can become contractual and financial risk.
The readiness questions executives should ask
The lesson is not that every data-center project is in trouble. It is that a headline capacity figure is only one piece of the readiness picture.
Executives, investors and customers should ask:
What does “power secured” mean in this project? Is there an executed supply agreement, a completed interconnection, fuel availability, installed generation, or some combination?
Who is responsible for each power milestone? The answer may differ across utility service, transmission upgrades, fuel supply, on-site generation, permits and equipment.
What evidence supports the schedule? A target date is a plan. Milestone records, approvals, construction status and commissioning evidence help show whether the plan is progressing.
What happens if a milestone slips? Review who carries the cost, which payments may change, how notice requirements work, and whether customer commitments depend on the same schedule.
What is the fallback plan? A backup source or phased energization may reduce exposure, but only if it is technically feasible, contractually available and supported by evidence.
The declared-versus-observed distinction applies to infrastructure
This is the same discipline that applies to other forms of risk: separate what has been stated from what has been demonstrated.
A project may declare a capacity target. Operational readiness asks whether the required power is available, tested and usable on the relevant timeline.
That distinction is especially important in AI infrastructure because the project’s value depends on more than a completed building. Compute capacity must be delivered in a form customers can use, when contracts say it will be available.
The force-majeure notice around Project Jupiter is not a final verdict on the project. It is a visible sign that the power timeline has become material enough to enter the contractual conversation.
The next phase of AI infrastructure will be judged not only by what gets announced or financed, but by what can be energized, delivered and supported by evidence.
“AI needs more power” is true as far as it goes. It is also too broad to tell an executive what to build, fund or approve.
A growing data center needs electricity at a specific site, at a specific time, with the reliability its operations require. Several different constraints can stand between that need and an energized facility. There may be too little generation available at the required hours. An existing transmission corridor may be congested. A local substation may need upgrades. An interconnection may still be years from completion.
Those are different problems. They do not all have the same solution.
The Department of Energy’s September 24 announcement offers a useful example. DOE said it intends to help fund 31 grid improvement projects across 26 states through its SPARK initiative. The selected projects are expected to reconductor or rebuild more than 1,500 miles of transmission lines and deploy grid enhancing technologies across nearly 21,000 miles. Together, DOE expects those efforts to make more than 23 GW of additional electricity capacity available.
That 23 GW is not a proposal for 23 GW of new generation. It is an expected increase in what the grid can carry and make available through transmission upgrades. The projects have been selected; the capacity gain still has to be delivered and measured.
The constraint may be the route
Think of generation as the source of electricity and transmission as part of the route it takes to customers. Adding supply at one end does little for a particular site if the route between them is constrained.
Reconductoring replaces the wire on an existing transmission line with a conductor that can carry more power. Other grid enhancing technologies help operators understand or improve how existing lines are used. Dynamic line ratings, for example, use current conditions to assess a line’s safe carrying capability. Power flow controls can help direct electricity across available paths.
These approaches are attractive because they can draw more value from infrastructure and rights of way that already exist. They may be especially useful where obtaining a new corridor would take much longer.
That does not make every existing line an easy upgrade. A project still has to satisfy engineering, reliability and operational requirements. Nor does an increase in transmission capability guarantee that electricity will be available during every hour a customer needs it.
What the announcement changes
The opportunity is wider than the familiar discussion about building new generation.
Advanced conductors, line monitoring, sensors, power flow controls and grid software all become more consequential when transfer capability is the binding constraint. So do the less visible tasks: studying where an upgrade will help, coordinating the work and proving that the promised capacity is available in operation.
For an AI infrastructure developer, the practical question is not simply, “How many megawatts are planned in this region?” It is:
How much power can reach this site, under the required conditions, by the date we need it?
For utilities and policymakers, the question is where targeted upgrades can relieve real congestion—and where new generation, substations or transmission corridors are still necessary.
From announced capacity to delivered power
DOE’s projected 23 GW is a meaningful signal about where grid investment is headed. It is not yet 23 GW of observed, site ready power.
The evidence will come as projects are completed and operators measure the resulting transfer capability, reliability and service to customers. That is where the declared figure becomes an operational result.
AI’s electricity challenge is often framed as a race to produce more power. In some places it will be. In others, a faster opportunity may be to move available electricity more effectively through the grid we already have.
The cheapest megawatt may already exist. The work is proving that it can reach the right place when it counts.
AI Infrastructure Is Entering Its Project-Finance Era
For much of the AI boom, attention has centered on company valuations, model capabilities and venture-capital investments.
That view is becoming incomplete.
The next phase of AI expansion requires physical infrastructure at enormous scale: processors, data centers, substations, transmission capacity, cooling systems and long-term access to electricity. Building that infrastructure requires more capital than even the largest technology companies may want to carry directly on their balance sheets.
That is why one of the most important AI developments of the week came from the financing side of the market.
On September 16, Reuters reported that a consortium of ten banks—including Goldman Sachs, Barclays, BNP Paribas, Sumitomo Mitsui Banking Corporation and Bank of Nova Scotia—was providing approximately $22 billion in financing for Crux AI, a cloud-computing venture backed by Blackstone and Alphabet.
Blackstone had already committed an initial $5 billion in equity. Google is contributing its Tensor Processing Units, along with software and services. The debt is expected to be secured by the TPUs and customer contracts, while the venture is targeting its first 500 megawatts of computing capacity in 2027. The banks may eventually refinance portions of the loan through the bond market. (reuters.com, reuters.com)
Those details deserve more attention than the headline dollar amount.
The capital stack is becoming part of the AI story
This transaction suggests that AI infrastructure is beginning to acquire characteristics commonly associated with project finance.
In traditional project finance, lenders do not rely solely on the reputation or market valuation of a corporate sponsor. They examine the project’s assets, contracts, construction milestones and expected cash flows.
The fundamental question is straightforward:
Can this specific group of assets produce enough reliable revenue to repay the financing used to build it?
That question is now being applied to AI compute.
The collateral is no longer merely an ownership stake in a promising technology company. It can include physical processors and contractual claims on future customer payments.
That represents a significant evolution in how capital is moving through the AI sector.
Money is moving beyond funding companies that develop AI. It is increasingly financing the industrial system required to operate AI at scale.
Contracts are becoming infrastructure
A processor has technical value, but a processor connected to power and committed to a creditworthy customer has financial value.
That distinction explains why customer contracts matter so much to these financing structures.
A long-term contract can transform uncertain future demand into a more predictable stream of revenue. That stream may then support debt financing, which allows the infrastructure provider to purchase more equipment and build additional capacity.
The contract effectively becomes part of the infrastructure.
But not all contracted demand is equally bankable. Lenders will examine the duration of the agreement, the customer’s ability to pay, cancellation provisions, minimum-use commitments and the consequences of delayed delivery.
A large announced customer pipeline may attract attention.
A durable contract with enforceable payment obligations can attract capital.
Utilization is no longer merely an operating metric
When infrastructure is financed with debt, utilization becomes directly connected to debt service.
A data center can be completed. The processors can be installed. Power can be available. But if customers do not use the contracted capacity—or if the contracts allow them to walk away—the economic model can still fail.
This creates an important separation between four different claims:
Announced computing capacity
Constructed computing capacity
Energized computing capacity
Revenue-producing computing capacity
Those categories are not interchangeable.
The AI sector has spent considerable time discussing how much capacity companies intend to build. Financing markets will increasingly ask how much of that capacity can be delivered, utilized and converted into dependable cash flow.
This is another version of the declared-versus-observed problem.
Declared demand may justify an announcement.
Observed utilization must eventually justify the financing.
AI chips are unusual collateral
The inclusion of TPUs as collateral is particularly revealing.
Processors are physical assets, but they do not behave like conventional infrastructure assets. A transmission line, pipeline or toll road may remain economically productive for decades. Advanced AI processors can face much faster technological and economic depreciation.
A chip may continue functioning while becoming less competitive against a newer generation with better performance, lower energy consumption or a more attractive cost per unit of compute.
That creates several underwriting questions:
How quickly will the equipment lose economic value?
Can the processors support multiple customers and workloads?
How dependent is the platform on one chip architecture?
What happens to the loan if utilization declines before the debt matures?
How much value could lenders recover from the hardware in a downside scenario?
The equipment may be tangible, but its future value remains tied to technological relevance.
Power readiness becomes a financial condition
The planned 500 megawatts also connect this transaction to the broader infrastructure constraints surrounding AI.
A processor cannot generate revenue while waiting for electricity.
That means lenders financing AI infrastructure must look beyond chips and customer contracts. They also need confidence in land control, interconnection agreements, permits, construction schedules, cooling capacity and the delivery of dependable power.
An announced 500-megawatt project is not automatically a financeable 500-megawatt project.
The difference lies in whether the capacity can be built, energized and made available when customers expect it.
Grid readiness is therefore becoming more than an engineering concern. It is becoming a credit concern.
Follow what the financing requires
Entrepreneurs and executives trying to understand AI economics should pay attention to more than valuations and funding announcements.
The more useful questions may now be:
What assets secure the financing?
Which contracts support the projected revenue?
How concentrated is the customer base?
What utilization level is required to service the debt?
Who carries the risk of construction delays?
Who absorbs the loss if the equipment depreciates faster than expected?
Is the power capacity announced, contracted or actually deliverable?
Will the debt remain with the banks or be distributed through the bond market?
These questions reveal what sophisticated capital providers believe can withstand scrutiny—and where they still require protection.
That does not mean every heavily financed AI project will succeed. It means the AI boom is entering a stage where enthusiasm must increasingly be translated into assets, contracts, milestones and cash flows.
Valuations show what the market hopes an AI company might become.
Financing structures show what lenders are willing to treat as bankable.
As AI infrastructure grows more capital-intensive, that may become one of the clearest ways to distinguish the sector’s declared promise from its observed economic foundation.
