Data Center Protests: Lessons the US Can Learn Abroad

A local decision can shift the footprint, not remove it

If one area limits new connections, companies may build somewhere else rather than shrink the overall footprint. After Dublin limited new grid connections, operators looked to other parts of Ireland. Some explored using the gas network or building dedicated gas-fired power plants to supply their facilities.

That's a key point for US communities. If a county rejects a proposal, the demand can end up in another county, another state, or another utility territory. That doesn't mean opposition is pointless - it means reviews need to think regionally. Communities should consider how the project might be reshaped and where the supply chain and power arrangements could move. A facility that can't connect to the grid may still seek approval for on-site generation, transmission lines, or other arrangements.

Public infrastructure needs public accountability

Ireland's grid is publicly operated, and data center companies lobbied for changes that would let private firms build electricity cables. That raises a broader problem: if a private operator builds infrastructure to serve its own facility, who controls access, who pays for maintenance, and who carries the risk if the business model changes?

The same issue shows up in the US, where responsibilities are split across utilities, regulators, and local governments in different ways. Residents should ask who pays for grid upgrades and whether those costs could land on other customers. They should also ask whether an approval creates a precedent for private infrastructure that sits outside normal public planning and oversight.

The practical lesson: don't judge only the building permit. Map the full chain - generation, transmission, water, emissions, and eventual decommissioning. A proposal can look modest at the site boundary while creating much larger obligations beyond it.

Ask what "off-grid" actually means

Phrases like behind-the-meter power or self-supply can suggest a project is independent of the wider energy system. In practice, details matter. Even if a data center builds its own generation, it may still rely on the grid at certain times, need backup capacity, or affect utility planning.

If a proposal includes on-site power, ask for specifics:

• What fuel will the generators use, and how many hours are they expected to run?
• Is the generation meant to be backup or routine supply?
• What emissions permits are required, and what limits apply?
• Will the facility connect to the public grid? If yes, at what capacity?
• Who pays for new lines, substations, fuel infrastructure, and ongoing maintenance?
• What happens if the proposed generation is delayed or unavailable?

Without that information, "the project will provide its own power" doesn't tell you what the project will actually do.

Transparency is part of infrastructure planning

A data center's water and energy use can be hard for residents to evaluate when the operator or local government treats the numbers as confidential. In The Dalles, Oregon, Google tried to keep water-use information secret. After the community obtained the figures, it learned the company was using 29 percent of the city's water, according to the reporting in Paris Marx's book Hyperscale.

That's the basic point: communities can't assess impacts based on general assurances. They need usable numbers, clear measurement periods, and a way to compare promised benefits with actual consumption. Water use also has to be considered alongside local supply conditions, seasonal shortages, and other users - not just as a national average.

When information is withheld, the uncertainty itself becomes a planning risk. Local officials should set reporting requirements before permits are granted, rather than trying to negotiate access after a facility is operating.

Long-lived power assets create a separate liability

A gas plant built to serve a data center doesn't automatically disappear if the data center is canceled or demand falls. The owner may seek other customers or argue that the plant should keep running to recover costs. In other words, the facility can outlast the business case that justified it.

That's why local reviews should treat the data center and its attached energy infrastructure as separate things. Each deserves its own economic and environmental assessment. Officials should ask whether a power plant has other customers, whether it can operate independently, and who is responsible for retirement or remediation if it's no longer needed.

The dotcom boom offers a partial comparison. Back then, excess fiber capacity accumulated, and some data center companies failed. Some survivors acquired facilities and were positioned to use capacity when demand returned. But the analogy has limits today. Many AI-focused facilities depend on specialized hardware that may need replacement on a shorter cycle. You can still have a building standing while the equipment that made it valuable becomes obsolete.

Require scenarios, not just a growth forecast

A credible proposal should cover more than the best-case, high-demand scenario. Ask developers and public authorities to model at least three outcomes:

1. Expected demand: the project reaches its planned use and operates as forecast.
2. Delayed demand: equipment or grid connections arrive later, leaving the site partly built or underused.
3. Lower demand: AI or other workloads don't grow as quickly as expected, or the operator changes plans.

For each scenario, clarify who pays for unused capacity, what happens to power infrastructure, and how local environmental obligations would be met. This isn't an argument against building. It's a way to make the downside explicit before a community commits land, water, or public funds.

Key takeaway: the risk isn't only that a data center fails. It's that supporting infrastructure remains in place, along with costs and emissions, after the original justification has weakened.

Use a four-part decision framework

1. Resource fit. Identify projected electricity demand, water use, land requirements, and emissions. Compare them with local capacity and competing needs. Require figures for normal operations, peak demand, and backup systems. If the operator won't provide meaningful data, decision-makers should be clear about what they're being asked to approve without knowing.
2. Public value. Ask what the community receives and whether those benefits are measurable. Jobs should be described by type, duration, and expected numbers - not only as construction totals. Tax arrangements and infrastructure contributions should be spelled out. Big capital spending isn't automatically a lasting public benefit.
3. Enforceable conditions. Put key commitments into permits or agreements: reporting, water and energy limits, emissions rules, construction milestones, and consequences for non-compliance. Voluntary targets can help, but they don't replace requirements that still apply when managers change or market conditions shift.
4. Exit and contingency plans. Specify what happens if the project is delayed, downsized, or abandoned. Clarify who maintains or removes equipment and who is responsible for the related power infrastructure. Use financial safeguards where appropriate, rather than assuming a future owner will absorb every obligation.

Consider what a different model could look like

Communities don't have only two options - approve every data center or reject all computing infrastructure. New Zealand offers one different approach: a community-led effort to build speech-recognition technology for the Māori language, using local cloud providers to host data. The model puts a specific community need first, instead of treating more general-purpose capacity as the goal.

That example doesn't prove that local or smaller-scale systems can replace hyperscale infrastructure for every workload. But it does show that technology can be organized around defined public needs, local control, and a more deliberate use of resources. Before approving a project, communities can ask: what problem does this facility solve, who sets priorities, and could the same outcome be achieved with less resource use or a different hosting arrangement?

Governments also need to evaluate the software and services that drive demand. Data center rules alone can't tell you whether a particular AI product delivers enough public value to justify its energy, water, and hardware requirements. Infrastructure policy and product oversight need to be considered together.

A short checklist for public meetings

• What are the project's expected and maximum power and water demands?
• Which grid upgrades or new generation assets are required, and who pays?
• Are the figures independently verifiable and reported on a regular schedule?
• What local benefits are guaranteed, not just forecast?
• What happens if the project is delayed, scaled back, or closed?
• How does the proposal affect climate targets and other local resource users?
• Has the community compared this proposal with lower-impact alternatives?

These questions shift the discussion away from vague claims about innovation - or generic arguments for and against - and toward evidence that can actually be tested.