top of page

JPMorgan Data Center Warning Puts Local Opposition at the Center of the AI Buildout

47 minutes ago
11 min read

JPMorgan is warning that public resistance threatens AI infrastructure schedules, even as developers continue building new capacity. The JPMorgan data center warning shifts attention from Nvidia’s chips to the communities expected to host them. Electricity bills, water supplies, and development approvals are becoming conditions that technology companies must resolve before expansion becomes usable computing capacity.

Stephanie Aliaga, a global market strategist at J.P. Morgan Asset Management, published the analysis on November 6, 2026. Stocktwits highlighted her warning in its November 8 AI buildout coverage. The issue reaches beyond hardware procurement: developers need permission, infrastructure, financing, and community acceptance to deliver facilities.

The central conflict is between companies’ expansion commitments and communities’ willingness to absorb the consequences. Nvidia remains relevant because its processors need somewhere to operate. Microsoft and Google matter because their infrastructure policies show how developers are responding. For enterprise buyers, the question is whether future capacity arrives where promised, when needed, and under economically workable conditions.

The JPMorgan Data Center Warning Targets Projects Beyond the Current Construction Wave

Aliaga’s data center backlash analysis identifies longer negotiations, higher costs, and delays as consequences of growing opposition. It singles out development from 2028 onward as particularly exposed. Projects already under construction generally face less vulnerability to new restrictions.

The note cites Wood Mackenzie’s count of more than 400 state and local moratorium actions since January 2026. That compares with 45 across 2023 through 2025. A moratorium is a temporary development pause, although its duration and scope depend on the measure.

The warning concerns how future projects advance, while construction already underway continues to expand.

Aliaga also cites more than 430 gigawatts of proposed U.S. capacity, with 59% under active development. A gigawatt measures power capacity; it does not measure completed buildings, available processors, or customer access. The remaining pipeline therefore cannot be treated as ready supply.

Those distinctions change how readers should interpret an infrastructure announcement. A proposed campus establishes an ambition and a location. It does not establish that electricity, construction approvals, equipment, and financing have reached compatible schedules.

For a project developer, the difficult work begins where those separate schedules intersect. A building can have a prospective customer while its electricity connection remains uncertain. Equipment can become available before the site receiving it is ready.

An announcement therefore carries less operational meaning than an achieved development milestone. The practical question is which obstacle has been removed and which commitments remain conditional. That question applies even when the company involved has a credible operating history.

The warning also changes the meaning of delay. Postponement does not necessarily represent permanently lost demand. A customer might wait, move to another region, or use existing facilities while a new site advances.

Each response has different consequences for suppliers and buyers. Waiting changes timing. Relocation changes geography. Using existing capacity changes the balance between immediate access and the customer’s preferred deployment plan.

These possibilities explain why the headline should not become a blanket claim that AI construction has stopped. The evidence supports a narrower judgment: future supply deserves closer examination at the project level.

That judgment places responsibility on developers to explain their delivery assumptions. Announced capacity becomes more informative when companies describe what has already been secured and what still depends on negotiation.

Developers Face a Local Bargain That Chip Orders Cannot Settle

The pressure falls most directly on organizations that must assemble land, electricity, financing, and public approval into a functioning site. Their customers can demand capacity, but customers cannot independently grant the permissions required to build it.

Strong demand for AI services does not settle who should bear the local costs of supplying them.

Microsoft acknowledged this problem in its January 13 community infrastructure commitments. Brad Smith, the company’s vice chair and president, said technology companies should cover the electricity costs their facilities create. Microsoft also committed to working with utilities and regulators on infrastructure funding.

The company described a concrete water project in Quincy, Washington. Microsoft says it partnered with the city on a reuse utility that treats and recirculates cooling water. The stated purpose is to reduce reliance on local groundwater.

These are company commitments and descriptions, rather than independent findings about every Microsoft location. They nevertheless show that community concerns have entered the planning process well before the latest warning.

For developers, the commercial issue extends beyond paying an ordinary electricity bill. A project can require infrastructure that serves it for years. Negotiations must address the relationship between that investment and the customer expected to support it.

Consider a hypothetical facility whose expected electricity demand increases as customers install equipment. The surrounding utility must plan for that growth before the building reaches full operation. Residents have an understandable interest in what happens if the expected demand fails to arrive.

The developer has a different concern. It needs enough certainty to commit to construction and customer contracts. An arrangement that leaves essential decisions unresolved can undermine that commitment even when everyone supports development in principle.

That creates a coordination problem rather than a dispute that marketing alone can resolve. Developers need credible schedules. Utilities need dependable information. Local officials need arrangements they can explain to constituents.

Community benefits also require careful interpretation. Construction activity, permanent employment, tax revenue, water use, and electricity demand describe different effects. A favorable result in one category does not automatically answer concerns in another.

This matters for large cloud operators and smaller infrastructure providers alike. A recognized brand can help establish credibility, but it cannot substitute for an agreement addressing a specific community’s concerns.

The immediate pressure is therefore contractual and operational. Developers must make their commitments concrete enough for other parties to rely on them. Customers, in turn, need to understand which local obligations underpin the delivery dates they receive.

For enterprise buyers, this is a supplier evaluation issue. The relevant question is whether a promised expansion rests on settled arrangements or on assumptions still awaiting public decisions.

Paying for Infrastructure Is Becoming Part of Delivering AI Capacity

The mechanism behind the warning is straightforward: a facility’s readiness depends on more than its computing equipment. Agreements about electricity and infrastructure can determine whether construction plans translate into customer access.

A developer’s ability to resolve local obligations belongs alongside its ability to acquire processors.

Google’s March 4 ratepayer protection commitments illustrate its approach. The company says it will pay for all electricity its facilities consume and infrastructure costs directly driven by its growth. Its framework asks large energy users to guarantee funding for the infrastructure needed to serve them.

Google and Microsoft therefore express a similar principle: households should not inherit the incremental infrastructure costs created by technology companies’ expansion. Their statements establish intended approaches, while implementation still depends on specific projects and agreements.

The comparison is useful because it moves the discussion toward enforceable responsibilities. A commitment becomes more meaningful when a regulator, utility, or municipality can identify the obligation behind it.

From a customer’s perspective, this creates a broader definition of delivery capability. A provider must organize equipment, buildings, energy arrangements, and local agreements. Weakness in any essential dependency can interrupt the overall schedule.

The timing of those commitments matters as much as their existence. An agreement reached after a public dispute may resolve the conflict but leave the project behind its original timetable. Earlier coordination offers a different planning position.

That does not mean every concern can be eliminated before a project becomes public. Development involves uncertainty, and local review can reveal issues that deserve changes. The practical goal is to make the remaining uncertainty visible.

A clearer agreement can also redistribute risk. If the developer accepts a defined obligation, another party has less uncertainty to price into its decisions. The developer must then account for that obligation in its own economics.

This helps explain why a project can become more expensive without experiencing a change in processor specifications. Additional responsibilities can affect the overall cost of making computing capacity available.

For buyers, comparing facilities solely by their advertised hardware misses this difference. Similar equipment can sit behind different readiness assumptions, electricity arrangements, and development conditions. Those differences affect how confidently customers can plan around future access.

There is also an important distinction between securing an agreement and delivering the underlying infrastructure. A funding commitment identifies responsibility. Construction and commissioning determine whether the physical system is ready.

Operators should consequently describe milestones in language that separates legal commitments from physical completion. Customers benefit when those milestones appear as distinct achievements rather than a single general statement about progress.

The commercial implication is a shift toward judging the complete delivery process. Processor access remains necessary. The ability to turn that access into an operating service depends on obligations that extend far outside the server room.

That is where the JPMorgan warning becomes relevant to AI procurement. Community arrangements are becoming part of the evidence supporting a capacity promise.

Public Opposition Does Not Establish That the AI Buildout Is Collapsing

The strongest challenge to an alarmist reading is that objections and project failures measure different things. A restriction can alter a development proposal without eliminating it. A contested project can also proceed under revised conditions.

Evidence of resistance warrants closer scrutiny of delivery assumptions, rather than an automatic conclusion that demand has disappeared.

The International Energy Agency’s updated energy demand outlook projects global data center electricity consumption rising from 485 terawatt-hours in 2025 to 950 in 2030. A terawatt-hour measures electricity consumed over time, unlike a gigawatt’s measure of capacity.

That projection includes data centers generally, rather than AI facilities alone. It is also a forecast, not a guaranteed outcome. The IEA identifies physical bottlenecks and social acceptance as constraints on expansion.

Importantly, the agency says electricity price effects depend on local conditions and policy choices. New demand does not produce an identical result everywhere. Cost allocation, available supply, and the timing of investment all matter.

The skeptical interpretation should therefore work in both directions. It should question claims that every announced project will arrive as scheduled. It should also question claims that every development restriction represents permanently lost computing capacity.

A useful assessment requires the outcome behind the headline. Did officials reject a project, request more information, revise conditions, or postpone a decision? Those actions can produce different operational consequences.

The same discipline applies to company responses. A developer’s willingness to fund infrastructure is relevant evidence, but it does not independently demonstrate that residents accept the arrangement. Public agreement and corporate intent remain separate questions.

There is also a measurement problem when observers combine unlike project stages. Proposed capacity, construction activity, completed facilities, and installed computing equipment do not describe the same stock of supply.

An increase in proposals can coexist with difficulty advancing them. Conversely, a decline in speculative proposals can coexist with continued progress on credible developments. Neither combination is inherently contradictory.

This is why the JPMorgan data center warning deserves a project-level reading. Its significance lies in how development conditions affect the path from announcement to operation.

Nvidia data center risks should be evaluated through that path. A delayed facility can affect the timing or destination of hardware deployment. Establishing a company-wide financial effect requires further evidence about orders, customer behavior, and alternative destinations.

The available material does not establish that every delayed development translates directly into canceled processor demand. It also does not establish that hardware suppliers are insulated from infrastructure constraints.

Both claims would require information beyond a general warning about public opposition. Treating the note as a precise forecast of Nvidia’s performance would exceed its evidentiary reach.

The more defensible conclusion is about uncertainty. Buyers and investors should place less confidence in expansion schedules that omit essential development dependencies. That conclusion remains useful even if total construction continues growing.

Flexibility Offers a Response, but Commitments Need Operational Evidence

Developers have responses available beyond accepting delays or abandoning locations. They can redesign projects, negotiate different infrastructure arrangements, or explore ways to make electricity demand easier for the surrounding system to accommodate.

The relevant test is whether an intervention changes an actual constraint while preserving the service customers expect.

Google’s June 2 flexible electricity agreement provides a concrete example. The company announced a three-year arrangement with Voltus covering up to 100 megawatts of capacity in the PJM electricity region. Megawatts measure power capacity at a smaller scale than gigawatts.

Under the announced arrangement, Voltus would coordinate resources such as batteries and smart thermostats. Participating homes and businesses would receive payments for reducing demand when the grid needs relief.

This is a company-described program, not independent proof that every participating resource will deliver as expected. The agreement nevertheless shows an alternative response to constrained electricity systems: improving how existing resources operate.

Demand response, which changes electricity consumption when the system needs it, introduces a practical question for AI infrastructure. Which activities can change timing without undermining the obligations made to customers?

For a hypothetical enterprise service, that question depends on what the application does. A background document-processing job has different scheduling requirements from a service answering employees during working hours. Treating them as interchangeable would produce poor planning.

The point is not that either workload automatically qualifies for a particular energy program. The point is that infrastructure flexibility must align with actual service requirements. Operators need to explain that alignment.

A customer's tolerance for delay also differs from a provider’s ability to move work. A task might technically run elsewhere while contractual, privacy, or operational requirements limit that option.

Flexibility therefore belongs in concrete service discussions. Buyers need to know what changes during constrained conditions and how those changes relate to their agreements. A broad assurance about resilience leaves those questions unanswered.

The same applies to new sources of electricity. A proposal can offer a plausible route around a constraint while introducing additional dependencies. The customer needs evidence that the alternative is advancing.

Evaluating those dependencies requires records that remain connected over time. Project announcements, utility decisions, service commitments, and revised delivery dates should be assessed together. A searchable technical knowledge base can help teams retain that context.

The benefit is practical: procurement teams can distinguish an achieved milestone from a repeated promise. They can also identify when a revised announcement changes an assumption behind their own plans.

For developers, that creates an opportunity to compete on clarity. Detailed explanations of constraints and obligations give customers a better basis for judgment than optimistic capacity language alone.

The broader lesson is that proposed solutions deserve the same scrutiny as proposed facilities. A credible response identifies the constraint, specifies the intervention, and provides observable evidence of progress.

Watch Approvals, Infrastructure Agreements, and Capacity That Actually Enters Service

The next stage of the story will emerge through decisions that connect development promises to operational results. Over the coming months, three signals deserve attention in a specific order.

The most useful evidence will show whether developers are converting contested plans into dependable capacity.

First, watch permitting decisions and changes to announced project schedules. Permitting is the process through which public authorities authorize development. The relevant documents should reveal what officials require and whether developers can satisfy those requirements.

An approval under revised conditions would show that opposition can produce a negotiated outcome. Repeated postponements without a clear route forward would strengthen concerns about delivery uncertainty. Both outcomes provide more information than the existence of opposition alone.

The quality of the explanation matters here. A revised date accompanied by a specific unresolved dependency gives customers something to evaluate. A revised date without an explanation leaves the central planning question open.

Second, watch utility agreements and regulatory decisions that assign infrastructure costs. These reveal whether corporate commitments have become obligations on which other parties can rely. They also clarify what remains subject to further negotiation.

Agreements that identify responsibilities and support physical progress would weaken the case for prolonged uncertainty at those projects. Unresolved disputes over cost allocation would reinforce it.

Readers should also distinguish an agreement’s signing from its implementation. A document can settle who pays while leaving construction milestones ahead. Both developments matter, but they answer different questions.

Third, watch capacity entering service and the explanations providers give when delivery expectations change. An operating facility offers stronger evidence of available supply than an announcement. Customer access adds another practical test.

If providers deliver usable capacity despite tougher conditions, the warning becomes a story about adaptation and added obligations. If schedules slip repeatedly, it becomes stronger evidence that development friction is constraining expansion.

Financial disclosures can help explain the consequences, but readers should avoid assuming the cause of every change. A company’s revised outlook may reflect demand, equipment, financing, development, or several factors together.

The task is to connect each claimed effect with supporting evidence. A local decision and a supplier’s financial result should not be treated as causally linked without that connection.

For developers and enterprise buyers, these signals support a more disciplined conversation about future services. Ask which dependencies remain open, who controls them, and what milestone will establish progress.

For knowledge workers using AI applications, the immediate implications remain indirect. The warning alone does not establish that a specific product will become unavailable or less reliable. Product-level conclusions require product-level evidence.

The closing question is whether infrastructure providers can make their delivery commitments credible under closer local scrutiny. Follow the approvals, the infrastructure obligations, and the facilities entering service. Compare each development with the promises customers originally received. Keep the original documents alongside subsequent revisions so that changes remain visible. The JPMorgan data center warning is most useful as a prompt to examine those connections. Before relying on a future capacity commitment, ask the provider which milestones are complete and which still depend on another party’s decision. Then identify the evidence that would confirm the remaining work is moving forward.

Give every agent the context to do better work

Connect your agents to the knowledge, decisions, and history already organized in remio.

remio currently supports Windows 10+ (x64) and Macs with Apple silicon.

Your AI Partner at Work
Get more done with remio

Plan. Create. Deliver.
All in one place.

bottom of page