How AI Infrastructure Uses Water

A question typed into an AI service feels almost weightless. Behind the interface, software assigns work to specialized chips in a data center. Those chips use electricity and release heat, which must be carried away to keep the equipment within a safe operating range. Depending on the facility, that heat may move through air, chilled-water equipment, evaporative cooling, or liquid loops that bring coolant close to the chip. The system also relies on substations, backup power, network equipment, buildings, and the factories that made the hardware.

Water can enter that stack in several places. A facility may withdraw water directly for cooling, while the power plants supplying its electricity may use additional water. Construction and semiconductor manufacturing add other demands that are usually counted in separate inventories. Even the words matter: a withdrawal is water taken from a source, while consumption is the portion not promptly returned to that source. A claim about “water-free cooling” may describe direct cooling operations without describing the grid, construction, or supply chain. The first honest question is therefore not “How much water does AI use?” but “Which part of the system are we counting?”

Why AI water use varies

A 2025 analysis from Lawrence Berkeley National Laboratory modeled the water used by data-center workloads and found estimates varying by more than 10,000-fold. That enormous range is not a rounding error. It reflects differences in model and hardware efficiency, how fully servers are used, the cooling system, weather, the water intensity of the electric grid, and the place and hour in which work runs. A short request on efficient hardware in a cool region with a lower-water grid is not equivalent to a long training run at a different facility.

The U.S. Government Accountability Office has likewise noted that public reporting and attribution remain limited. A fleet-wide annual average can help track a company over time, but it can hide a difficult summer in one basin. A site water-use-efficiency number can illuminate cooling operations while excluding electricity and hardware. And a modeled “per prompt” estimate can be useful for research without becoming a universal conversion factor. Independent evidence does not make the issue unknowable; it shows which facts must accompany a responsible number: boundary, geography, season, workload, method, and uncertainty.

Company initiatives are useful evidence—with a label attached

Major operators report several practical changes. Microsoft says newer data-center designs use closed-loop, direct-to-chip cooling that recirculates a one-time fill instead of continually evaporating water for cooling, and it reports broader gains in fleet water-use efficiency. AWS reports expanding reclaimed-water use, relying on outside air when conditions allow, and improving the liters of water withdrawn per kilowatt-hour of computing infrastructure. OpenAI says its Abilene Stargate campus uses closed-loop cooling rather than evaporative towers. These are concrete design choices, but each statement comes from the company and uses its stated operational boundary.

Google reports a different part of the portfolio as well: watershed restoration and replenishment projects alongside facility efficiency. Its 2026 environmental reporting said projects replenished 7.7 billion gallons in 2025, about 78 percent of the freshwater its offices and data centers consumed. That is progress toward a future goal, not the same thing as zero water use or a positive result in every local watershed. Replenishment may occur in another place or season, and estimated project benefits should not be confused with measured reductions at a cooling tower.

The constructive response is to ask for better, comparable reporting while recognizing real improvements. Companies can publish site-level withdrawals and consumption, identify water-stressed locations, use reclaimed water where treatment and infrastructure support it, avoid evaporative cooling when local conditions favor another design, improve workload efficiency, and fund projects shaped by watershed needs. Readers can then distinguish an installed system from a planned one, an independently measured result from a company estimate, and a global goal from conditions near a particular community. That is how a digital service becomes accountable to its physical address.