AI Data Centers Faced 41 Local Votes. Voters Favored Limits in 40

A data center can have GPUs, land, financing, and a power contract, then still run into a constraint no capacity-planning spreadsheet can solve: the people who live nearby do not trust the deal.

That became difficult to ignore after the November 3, 2026 U.S. elections. Ballotpedia reported that voters favored limiting data-center development in 40 of 41 local ballot measures. The measures were not all the same. Some were bans or moratoriums, some changed zoning, some required voter approval, and some were nonbinding statements of support or opposition. In the one exception, Harwood, North Dakota voters rejected a proposed review requirement. So the result is not a single nationwide referendum on AI. It is a broad warning that local approval cannot be treated as a formality. (Ballotpedia's results and measure breakdown)

For developers and operators, the useful question is not whether AI should stop growing. It is what a project must demonstrate before a community is asked to host it. The answer looks surprisingly similar to a well-run engineering change: identify the external dependencies, quantify the blast radius, publish the operating assumptions, assign owners, and agree on what happens when reality differs from the plan.

What the 40-of-41 result does and does not say

It is a signal about local governance. Ballotpedia's tally included 27 measures that limited development or expressed opposition, including five full bans, 12 partial bans, three six-month moratoriums, zoning changes, voter-approval rules, and other requirements. Voters also defeated 13 measures that would have favored data centers or expressed support for development. The range matters: some results directly restricted projects, while others were advisory or applied only to a specific site. (Ballotpedia)

It is not proof that voters oppose every AI application. The Associated Press reported that about three-quarters of U.S. voters opposed a new data center in their community, while about one-quarter said data centers were crucial to their vote for Congress. Those are different questions: people can have concerns about a facility near their home without making it their top national voting issue. The AP also noted opposition across both red and blue states. (AP's election analysis)

It does not establish one cause. Energy bills, water, land use, noise, tax incentives, transparency, and confidence in local decision-making can all enter a project debate. A ballot tally cannot isolate which factor changed each vote. Treating the result as “people hate AI” is too broad; treating it as “just misinformation” ignores the concrete questions communities are raising.

The distinction is useful for engineers. A service outage metric does not tell you which dependency failed. Likewise, a failed ballot measure does not automatically tell a developer what to fix. It does tell the project team that its assumptions need to be tested with the people who bear the local effects.

Infrastructure has external dependencies too

Software teams are used to documenting dependencies: databases, queues, cloud regions, identity providers, and network paths. A compute campus has dependencies that are just as real, even if they sit outside the architecture diagram.

• Electricity: generation, substations, transmission capacity, and the local rate structure.
• Water and cooling: the source, seasonal availability, consumption, and discharge plan.
• Land and zoning: what is being built, where, and which future expansions the approval covers.
• Public services: roads, emergency response, schools, and municipal capacity.
• Community trust: whether residents can see the terms, question assumptions, and get answers from an accountable owner.

Lawrence Berkeley National Laboratory's 2025 update estimated that U.S. data centers could account for 11.8% of national electricity use by 2030, with scenarios from 9.5% to 15.3%. That is a scenario estimate, not a guaranteed outcome, and it covers data centers generally rather than only AI workloads. It is still a reason to treat power planning as a first-class design constraint instead of a footnote in a site announcement. (Berkeley Lab's 2025 report)

The analogy to software reliability has limits. Residents are not merely “stakeholders” to be managed, and a community cannot be reduced to a service-level indicator. But engineering has useful habits here: make dependencies visible, define measurable promises, validate them independently, and plan for failure before it happens.

A public-infrastructure checklist for AI campuses

A credible project proposal should answer operational questions in language people can inspect. These are not a substitute for local law, permitting, or community-led decisions. They are a practical baseline for transparency.

1. Publish the resource envelope. State expected power demand in megawatts, expected annual energy use, water requirements, cooling approach, and the range of uncertainty. Separate current demand from planned phases. Explain which values are estimates and which are contractual limits. “We will use efficient technology” is not a measurable commitment.

2. Explain who pays for grid upgrades. Identify the generation, transmission, and distribution work required to serve the campus. Show which costs are assigned to the project and which could flow through to other ratepayers. Describe the financial assurance available if a project is delayed, reduced, or canceled after infrastructure work begins.

3. Make flexibility testable. If a campus promises to reduce demand during grid stress, publish the conditions that trigger a reduction, the amount of load that can be shed, the response time, the duration, and the number of events it can support. Report actual performance afterward. A promise to be “grid friendly” without an operating definition cannot be evaluated.

4. Publish local water and cooling plans. Identify the water source, expected use by season, reuse assumptions, and any limits during drought or shortage. If water use is expected to change as the campus expands, publish the phase-by-phase estimate. Avoid presenting a site-wide or company-wide figure as if it described one facility.

5. Define independent monitoring. Specify which data will be measured, who verifies it, how often results are published, and how residents can report a discrepancy. Where commercial or security details must remain confidential, explain the narrow reason and publish the non-sensitive performance data.

6. Create a named accountability path. Give the community a local contact with authority to answer questions and escalate problems. Publish response targets, meeting schedules, and a record of unresolved issues. A generic corporate inbox is not an operating model.

7. Show benefits with the same precision as impacts. Estimate permanent jobs separately from temporary construction jobs. Describe local hiring, training, procurement, tax arrangements, and community investments. State the time period and conditions attached to each promise. Do not count a one-time announcement as a benefit delivered.

8. Revisit the agreement as the project changes. A campus may expand, adopt different cooling equipment, or draw more power than its initial phase. Define what changes require renewed review or public notice. A permit for one project description should not silently become approval for a substantially different one.

This list is an engineering translation of public concerns, not a claim that every community should approve a campus that satisfies it. The decision belongs to the applicable community and authorities. Transparency makes the decision better informed; it does not guarantee a yes.

OpenAI's new commitments are a proposal to test, not proof of success

The political signal was followed by a response from industry. On November 5, OpenAI published a National Community Compact and a Compute Campus Policy Blueprint. The company says future campuses it owns and operates will have local compacts, early resident engagement, annual public reporting, energy and infrastructure cost coverage, water plans, noise studies, job reporting, and no nondisclosure agreements with public officials except for narrow protections. (OpenAI's announcement)

Those are company commitments, not independent evidence that the commitments have already worked. The distinction matters. A vendor can publish a policy and still need to show how it applies to a specific project, how data is audited, what remedies exist when targets are missed, and whether future campuses follow the same standard.

OpenAI's separate Grid Protectors announcement says the company will work with utilities and policymakers to reduce campus demand during grid stress. It describes an agreement for its planned Effingham County, Georgia campus that includes up to 1,000 megawatts of flexible demand response. The same announcement says the campus is still in development. That means the figure describes a planned agreement, not measured operating performance. (OpenAI's Grid Protectors announcement)

A useful review asks for a verifiable chain:

• What did the company promise?
• Which facility and phase does it cover?
• What is the measurement method?
• Who can independently inspect the data?
• What happens if the target is missed?
• How can the public see whether the remedy occurred?

This is the difference between a statement of intent and an operational control. The same distinction applies in software: a runbook is not proof that a service met its SLO; telemetry and incident records are.

The developer lesson: operational externalities belong in the design review

Data-center permitting is not a software engineering task, and developers should not pretend that a checklist can settle a political dispute. But the compute behind AI products has a physical footprint. Teams that depend on large-scale inference should understand the assumptions behind that footprint rather than treating capacity as an invisible API.

For a product or platform team, practical questions include:

• Can the workload be scheduled to avoid the most constrained hours or regions?
• Can non-urgent jobs tolerate delay, batching, or lower-power inference?
• Do model and hardware choices change energy use per request?
• Are capacity forecasts based on measured usage or optimistic growth assumptions?
• Can the system degrade gracefully if a region or provider has limited capacity?
• Does the procurement process ask providers for facility-level resource and cost disclosures?

These questions do not mean every team should build its own power model. They mean infrastructure decisions should include cost, availability, latency, and resource constraints together. A cheaper token price can hide costs elsewhere; a fast-growing workload can create dependencies the product team never reviewed.

The election results are not an engineering benchmark, and the ballot counts are not a clean experiment. They are evidence of a growing permission and trust constraint around physical AI infrastructure. If the industry wants predictable deployment, project plans need more than a land parcel and a megawatt target. They need public assumptions, accountable owners, and results that can be checked after construction.

Save this review checklist

Before a compute-campus proposal advances, ask:

• Power: Is demand published by phase, and are grid-upgrade costs assigned clearly?
• Flexibility: Are demand-response promises quantified and independently reported?
• Water: Are the source, seasonal use, reuse plan, and drought limits public?
• Transparency: Are resource figures facility-specific, audited, and accessible?
• Accountability: Is there a named local owner and a path to resolve missed commitments?
• Benefits: Are jobs, procurement, taxes, and community investments measurable over time?
• Change control: Does expansion or a material design change trigger renewed review?

The strongest infrastructure plan is not the one with the most ambitious claim. It is the one whose assumptions can be tested, whose costs have owners, and whose promises remain visible after the announcement leaves the news cycle.

I write about software engineering, infrastructure, and AI. Subscribe, it is free, if you want practical, source-grounded analysis of the systems behind the software.

How should AI infrastructure projects prove that they are paying their way and protecting local resources? What would you add to this checklist?

Save this review list for your next discussion about AI infrastructure, cloud capacity, or a large compute deployment.

Sources

• Ballotpedia: Voters favored limiting data center development in 40 of 41 local ballot measures
• Associated Press: AI data centers took a beating in the midterm elections
• Lawrence Berkeley National Laboratory: United States Data Center Energy Usage Report, 2025 Update
• OpenAI: Setting a new standard for responsible AI infrastructure
• OpenAI: Introducing the Grid Protectors Program