How Data Centers Connect to Local Water Systems

A student asks an AI system to explain a difficult idea. The response arrives in seconds, with none of the smoke, noise, or moving machinery that usually signals industrial work. Somewhere else, however, software has scheduled calculations across processors packed into a data-center rack. Electricity enters the chips and nearly all of it becomes heat. Fans, pumps, heat exchangers, chillers, cooling towers, or liquid loops carry that heat away so the next request can arrive without damaging the equipment.

Follow the system one step farther and water appears in several forms. It may be withdrawn by the facility for evaporative cooling, circulated inside a closed loop, or supplied as reclaimed wastewater instead of drinking-quality water. It may also be used by parts of the electric grid. The building and semiconductor supply chain create additional demands that do not appear in a cooling metric. These are not accounting details at the edge of the story. The boundary determines what a number means, whose watershed is affected, and which solution could actually reduce pressure.

Why a fixed water-per-prompt estimate is misleading

It is tempting to attach a fixed volume of water to every prompt. The result feels concrete and shareable. Research from Lawrence Berkeley National Laboratory shows why that shortcut breaks down: modeled workload water use varied by more than 10,000-fold across combinations of hardware, utilization, cooling, grid, climate, location, and time. “Per prompt” also changes with the length and type of a request, the model that answers it, batching, and the share of infrastructure assigned to that workload. A carefully bounded estimate can teach us something; a number stripped of those conditions can mislead.

Independent public evidence is still incomplete. The U.S. Government Accountability Office has highlighted gaps in consistent reporting and attribution for generative AI’s environmental effects. Operators may publish fleet-wide water-use effectiveness, total withdrawals, consumption, or estimated replenishment, but these are not interchangeable. A falling liters-per-kilowatt-hour ratio can coexist with rising total use if computing grows quickly. An annual global average can overlook a dry month in a stressed basin. Good reporting places operational efficiency beside site, season, source, electricity, and community context.

How companies are reducing water use

The first approach is to use less freshwater at the facility. Microsoft reports that its newer direct-to-chip systems circulate water in closed loops and avoid ongoing evaporation for operational cooling. OpenAI describes a similar closed-loop approach at the Abilene Stargate campus. AWS says it uses outside air for much of the year where conditions allow and is expanding reclaimed-water supplies. Each can be a meaningful engineering step. Each is also a first-party statement with a particular boundary: operational cooling at one design or fleet, not necessarily construction, electricity, chip manufacturing, or every site the company uses.

A second approach is to return benefits to watersheds. Google’s 2026 environmental report said its projects replenished 7.7 billion gallons in 2025, about 78 percent of the freshwater consumed by its offices and data centers. The linked portfolio describes work across many watersheds. Such projects can restore wetlands, improve irrigation, repair leaks, or recharge groundwater, depending on local needs. Replenishment, however, is an estimated benefit rather than water flowing backward through a facility meter. Geography and timing matter, and progress toward a global goal should not be presented as proof that every community has been made whole.

Quincy, Washington, offers a more concrete local case. EPA describes a city-owned reuse utility that recirculates cooling water and is estimated to offset 138 million gallons of potable groundwater demand each year. Microsoft financed capital and operating costs under the agreement. The useful lesson is not that Quincy supplies a template for every basin. It is that a data center, a municipal utility, treatment equipment, financing, and a defined local water source were considered together. Infrastructure changed because the parties could describe whose water was being replaced, how the loop worked, and who would operate it.

A better standard begins locally

A watershed-aware AI industry would begin before construction with public questions about supply, drought, wastewater capacity, grid demand, ecosystem flows, rates, emergency plans, and expected growth. It would publish site-level withdrawals and consumption alongside fleet efficiency, explain whether reclaimed water is available and appropriate, and update forecasts when workloads change. Community engagement would shape enforceable commitments rather than arrive after the most important decisions had already been made.

The same standard leaves room for technology to help water systems. USGS researchers describe machine-learning work involving streamflow imagery, harmful algae, contaminant risk, and wetland conditions. Those projects illustrate a productive exchange: computing can improve observation and planning even as its own infrastructure faces scrutiny. The point is not to place AI on one side of an environmental ledger and water on the other. It is to make the physical relationship visible enough that efficiency, reuse, restoration, public oversight, and useful research can reinforce one another.