Chapter 34: Environmental Data Ethics and Climate

"There is no cloud. It's just someone else's computer." — Common tech industry saying — which understates the problem. Those computers use electricity, occupy land, consume water, and generate heat. The cloud has a carbon footprint.

Chapter Overview

In 2019, researchers at the University of Massachusetts Amherst published a paper that changed the conversation about artificial intelligence. Emma Strubell, Ananya Ganesh, and Andrew McCallum estimated that training a single large natural language processing model produced approximately 284 tons of CO2 — roughly five times the lifetime emissions of an average American car, including its manufacture.

The paper provoked immediate controversy. Some AI researchers questioned the methodology. Others argued that the emissions were a worthwhile cost given the benefits of the resulting models. Industry leaders pointed out that inference (using trained models) was far more energy-efficient than training, and that the total energy footprint of AI was small relative to other industries.

But the paper accomplished something essential: it made the material costs of data systems visible. For most of this book, we've discussed data as if it were immaterial — flows of information, algorithmic decisions, governance frameworks. This chapter insists that data systems are also physical systems. They require electricity generated by burning fossil fuels. They require water to cool the servers that process computations. They require rare earth minerals mined from the earth to manufacture the hardware they run on. And when that hardware becomes obsolete — which it does with remarkable speed — it becomes electronic waste that often ends up in landfills in the Global South.

This chapter examines the environmental ethics of data systems from three angles: the carbon footprint of AI model training (including a Python tool for estimating emissions), the role of data systems in environmental monitoring and climate response, and the environmental justice question of who bears the environmental costs of the data economy.

In this chapter, you will learn to: - Calculate and contextualize the carbon emissions of AI model training - Build and use a CarbonEstimator Python class for training emission estimation - Evaluate proposals for more environmentally sustainable AI development - Analyze how data systems contribute to both environmental harm and environmental monitoring - Apply environmental justice frameworks to data infrastructure decisions

34.1 The Environmental Footprint of AI

34.1.1 Energy Consumption: How Much Power Does AI Use?

Data centers — the physical facilities that house the servers powering cloud computing, AI training, and digital services — consumed approximately 460 terawatt-hours (TWh) of electricity globally in 2024, representing approximately 2% of global electricity consumption (IEA, 2024). This is roughly equivalent to the total electricity consumption of France.

AI workloads represent a rapidly growing share of this consumption. Training large language models is particularly energy-intensive because it requires thousands of specialized processors (GPUs or TPUs) running continuously for weeks or months. The key factors driving AI energy consumption are:

Model size. The number of parameters in a model directly correlates with its computational requirements. GPT-2 (2019) had 1.5 billion parameters. GPT-3 (2020) had 175 billion. GPT-4 (2023) is estimated to have over 1 trillion parameters in a mixture-of-experts architecture. Each generation requires substantially more computation — and therefore more energy — to train.

Training duration. Training a large model involves passing through the training data many times (epochs), adjusting model weights with each pass. GPT-3 required approximately 3,640 petaflop-days of computation. At the energy consumption rates of NVIDIA A100 GPUs, this translates to thousands of megawatt-hours of electricity.

Hardware efficiency. Newer GPU generations (NVIDIA H100, H200, B200) are more energy-efficient per computation than older generations. But the increase in model size has outpaced efficiency gains, resulting in higher total energy consumption for each new generation of models.

Data center efficiency. The Power Usage Effectiveness (PUE) metric measures how much total energy a data center uses relative to the energy consumed by its computing equipment. A PUE of 1.0 would mean all energy goes to computing; in practice, energy is also consumed by cooling, lighting, networking, and other infrastructure. Google reports an average PUE of 1.10; the industry average is approximately 1.58 (Uptime Institute, 2023). The difference matters: a data center with a PUE of 1.58 uses 58% more total energy than the computing alone requires.

34.1.2 Carbon Emissions: From Energy to Impact

Energy consumption becomes an environmental problem through carbon emissions — the greenhouse gases produced by generating the electricity that powers data centers. The carbon impact of a given computation depends on the carbon intensity of the electricity grid in the region where the computation occurs.

Carbon intensity varies dramatically by region:

The same computation — training the same model on the same hardware for the same duration — can produce vastly different carbon emissions depending on where it is performed. Training a large model in Quebec (hydro-powered) might produce 1% of the carbon emissions of training the same model in West Virginia (coal-powered).

"Location is a governance choice," Dr. Adeyemi emphasized. "When a company decides where to build its data center, it's making a decision about carbon emissions. And that decision is shaped by factors — tax incentives, land costs, proximity to customers — that have nothing to do with environmental impact."

34.1.3 Water Consumption: The Hidden Cost

Data centers require enormous quantities of water for cooling. A 2023 study by researchers at the University of California Riverside and the University of Texas Arlington estimated that training GPT-3 consumed approximately 700,000 liters of fresh water — enough to fill approximately 370 standard bathtubs — and that a typical conversational session with ChatGPT (20-50 queries) consumed approximately 500 milliliters of water (Li et al., 2023).

Water consumption is a critical environmental justice issue because data centers are often located in regions already experiencing water stress. Microsoft's data centers in Arizona, Google's facilities in The Dalles, Oregon, and various data center projects in drought-affected regions have faced opposition from local communities concerned about the impact on water supplies.

34.1.4 E-Waste: The End of the Lifecycle

The hardware lifecycle of AI has an end as well as a beginning. GPUs and TPUs used for AI training have effective lifespans of 3-5 years before they are replaced by more efficient models. The resulting electronic waste contains toxic materials — lead, mercury, cadmium, brominated flame retardants — that pose environmental and health risks.

Global e-waste reached 62 million metric tons in 2022 (UN STEP Initiative), with only approximately 22% formally collected and recycled. The remainder is landfilled, incinerated, or exported — often illegally — to countries in the Global South, where informal recycling operations expose workers (including children) to toxic substances.

Callout Box: The Full Environmental Cost of a Large Language Model

Environmental Dimension	Estimated Impact (GPT-3 scale)
Training energy	~1,287 MWh
Training carbon (US average grid)	~502 tCO2e
Training water	~700,000 liters
Hardware manufacturing emissions	Substantial but poorly documented
Inference energy (annualized)	Likely exceeds training energy
E-waste (hardware lifecycle)	Hundreds of GPUs, 3-5 year lifespan

Note: These are estimates based on publicly available information. Actual figures are proprietary and not disclosed by model developers.

34.2 Calculating Carbon: The CarbonEstimator Python Class

34.2.1 Motivation

Understanding the environmental impact of AI requires the ability to estimate carbon emissions from model training. In this section, we build a CarbonEstimator class that takes training parameters — GPU type, number of GPUs, training duration, and cloud region — and calculates estimated carbon emissions, comparing them to familiar equivalents.

This is a simplified estimation tool. Real carbon accounting involves additional complexities (embodied carbon in hardware manufacturing, cooling overhead, transmission losses). But even a simplified estimate is more informative than no estimate — and the exercise of building the estimator reinforces the material reality of computational work.

34.2.2 The Code

"""
CarbonEstimator: A tool for estimating the carbon footprint of AI model training.

This module provides a class for calculating the estimated CO2 emissions
associated with training machine learning models, based on GPU type, count,
training duration, and data center location.

Usage:
    estimator = CarbonEstimator(
        gpu_type="A100",
        num_gpus=64,
        training_hours=720,
        cloud_region="us-east"
    )
    report = estimator.estimate()
    estimator.print_report(report)
"""

from dataclasses import dataclass, field
from typing import Optional


# GPU power consumption in watts (TDP — Thermal Design Power)
GPU_POWER_WATTS: dict[str, float] = {
    "V100":  300.0,
    "A100":  400.0,
    "H100":  700.0,
    "H200":  700.0,
    "B200":  1000.0,
    "A10G":  150.0,
    "T4":    70.0,
    "L4":    72.0,
    "TPUv4": 170.0,
    "TPUv5": 250.0,
}

# Carbon intensity by cloud region in gCO2 per kWh
# Sources: US EIA, EU EEA, IEA (2023-2024 estimates)
CARBON_INTENSITY_G_PER_KWH: dict[str, float] = {
    "us-east":        340.0,    # Virginia — natural gas, nuclear
    "us-west":        210.0,    # California/Oregon — gas, solar, wind, hydro
    "us-central":     420.0,    # Iowa/Texas — gas, wind, coal
    "us-south":       380.0,    # Texas/Georgia — gas, coal, nuclear
    "eu-west":        250.0,    # Ireland/Netherlands — gas, wind
    "eu-north":       25.0,     # Sweden/Finland — hydro, nuclear, wind
    "eu-central":     350.0,    # Germany/Poland — coal, gas, renewables
    "eu-france":      55.0,     # France — nuclear, hydro
    "canada-central": 30.0,     # Quebec/Ontario — hydro, nuclear
    "canada-west":    15.0,     # British Columbia — hydro
    "asia-east":      550.0,    # China (coastal) — coal, gas
    "asia-south":     700.0,    # India — coal, gas
    "asia-southeast": 500.0,    # Singapore/Indonesia — gas, coal
    "japan":          450.0,    # Japan — gas, coal, nuclear
    "australia":      550.0,    # Australia — coal, gas, solar
    "brazil":         75.0,     # Brazil — hydro, wind, biomass
    "middle-east":    500.0,    # UAE/Saudi — gas, oil
    "africa-south":   900.0,    # South Africa — coal
}

# Familiar equivalents for contextualization
# Sources: EPA, IEA, airline emissions calculators
EQUIVALENTS: dict[str, dict[str, float]] = {
    "transatlantic_flights": {
        "kg_co2_per_unit": 1600.0,  # One-way NYC to London per passenger
        "label": "one-way transatlantic flights (NYC-London)",
    },
    "car_miles": {
        "kg_co2_per_unit": 0.21,    # Average US passenger vehicle
        "label": "miles driven in an average US car",
    },
    "household_electricity_years": {
        "kg_co2_per_unit": 4200.0,  # Average US household annual electricity
        "label": "years of average US household electricity",
    },
    "smartphone_charges": {
        "kg_co2_per_unit": 0.0084,  # One full smartphone charge
        "label": "smartphone charges",
    },
    "trees_year_offset": {
        "kg_co2_per_unit": 22.0,    # CO2 absorbed by one tree per year
        "label": "tree-years needed to offset",
    },
}


@dataclass
class CarbonEstimator:
    """
    Estimates the carbon footprint of training a machine learning model.

    Attributes:
        gpu_type: The type of GPU used (e.g., "A100", "H100").
        num_gpus: The number of GPUs used concurrently.
        training_hours: Total wall-clock training time in hours.
        cloud_region: The cloud region where training occurs.
        pue: Power Usage Effectiveness of the data center (default: 1.1).
        gpu_utilization: Average GPU utilization during training (default: 0.7).
    """
    gpu_type: str
    num_gpus: int
    training_hours: float
    cloud_region: str
    pue: float = 1.1
    gpu_utilization: float = 0.7

    def __post_init__(self) -> None:
        """Validate inputs after initialization."""
        if self.gpu_type not in GPU_POWER_WATTS:
            available = ", ".join(sorted(GPU_POWER_WATTS.keys()))
            raise ValueError(
                f"Unknown GPU type: '{self.gpu_type}'. "
                f"Available types: {available}"
            )
        if self.cloud_region not in CARBON_INTENSITY_G_PER_KWH:
            available = ", ".join(sorted(CARBON_INTENSITY_G_PER_KWH.keys()))
            raise ValueError(
                f"Unknown cloud region: '{self.cloud_region}'. "
                f"Available regions: {available}"
            )
        if self.num_gpus <= 0:
            raise ValueError("num_gpus must be a positive integer.")
        if self.training_hours <= 0:
            raise ValueError("training_hours must be positive.")
        if not (1.0 <= self.pue <= 3.0):
            raise ValueError("PUE must be between 1.0 and 3.0.")
        if not (0.0 < self.gpu_utilization <= 1.0):
            raise ValueError("gpu_utilization must be between 0.0 and 1.0.")

    def _gpu_power_kw(self) -> float:
        """Return the power consumption of a single GPU in kilowatts."""
        return GPU_POWER_WATTS[self.gpu_type] / 1000.0

    def _total_energy_kwh(self) -> float:
        """
        Calculate total energy consumed in kilowatt-hours.

        Accounts for:
        - GPU power draw (TDP) adjusted by utilization
        - Number of GPUs
        - Training duration
        - Data center overhead (PUE)
        """
        gpu_energy = (
            self._gpu_power_kw()
            * self.gpu_utilization
            * self.num_gpus
            * self.training_hours
        )
        # PUE accounts for cooling, networking, storage, lighting, etc.
        total_energy = gpu_energy * self.pue
        return total_energy

    def _carbon_intensity(self) -> float:
        """Return the carbon intensity of the selected region in kgCO2/kWh."""
        return CARBON_INTENSITY_G_PER_KWH[self.cloud_region] / 1000.0

    def _total_carbon_kg(self) -> float:
        """Calculate total carbon emissions in kilograms of CO2."""
        return self._total_energy_kwh() * self._carbon_intensity()

    def _compute_equivalents(self, carbon_kg: float) -> dict[str, float]:
        """Convert carbon emissions to familiar equivalents."""
        results = {}
        for key, info in EQUIVALENTS.items():
            results[key] = carbon_kg / info["kg_co2_per_unit"]
        return results

    def estimate(self) -> dict:
        """
        Produce a full carbon estimate report.

        Returns:
            A dictionary containing energy consumption, carbon emissions,
            regional information, and familiar equivalents.
        """
        energy_kwh = self._total_energy_kwh()
        carbon_kg = self._total_carbon_kg()
        equivalents = self._compute_equivalents(carbon_kg)

        return {
            "gpu_type": self.gpu_type,
            "num_gpus": self.num_gpus,
            "training_hours": self.training_hours,
            "cloud_region": self.cloud_region,
            "pue": self.pue,
            "gpu_utilization": self.gpu_utilization,
            "gpu_power_kw": self._gpu_power_kw(),
            "carbon_intensity_g_per_kwh": CARBON_INTENSITY_G_PER_KWH[
                self.cloud_region
            ],
            "total_energy_kwh": round(energy_kwh, 2),
            "total_energy_mwh": round(energy_kwh / 1000.0, 2),
            "total_carbon_kg": round(carbon_kg, 2),
            "total_carbon_tonnes": round(carbon_kg / 1000.0, 2),
            "equivalents": {
                key: {
                    "value": round(val, 1),
                    "label": EQUIVALENTS[key]["label"],
                }
                for key, val in equivalents.items()
            },
        }

    def print_report(self, report: Optional[dict] = None) -> None:
        """Print a human-readable carbon estimate report."""
        if report is None:
            report = self.estimate()

        print("=" * 64)
        print("  CARBON FOOTPRINT ESTIMATE — AI MODEL TRAINING")
        print("=" * 64)
        print()
        print("  Configuration:")
        print(f"    GPU type:          {report['gpu_type']}")
        print(f"    Number of GPUs:    {report['num_gpus']}")
        print(f"    Training hours:    {report['training_hours']:,.1f}")
        print(f"    Cloud region:      {report['cloud_region']}")
        print(f"    PUE:               {report['pue']}")
        print(f"    GPU utilization:   {report['gpu_utilization']:.0%}")
        print()
        print("  Energy & Emissions:")
        print(f"    Total energy:      {report['total_energy_mwh']:,.2f} MWh")
        print(f"    Carbon intensity:  "
              f"{report['carbon_intensity_g_per_kwh']:.0f} gCO2/kWh")
        print(f"    Total emissions:   "
              f"{report['total_carbon_kg']:,.1f} kg CO2")
        print(f"                       "
              f"{report['total_carbon_tonnes']:,.2f} tonnes CO2")
        print()
        print("  Equivalents:")
        for key, info in report["equivalents"].items():
            print(f"    ~ {info['value']:,.1f} {info['label']}")
        print()
        print("=" * 64)

    def compare_regions(self, regions: Optional[list[str]] = None) -> None:
        """
        Compare carbon emissions across multiple cloud regions.

        Useful for demonstrating how location choices affect
        environmental impact.
        """
        if regions is None:
            regions = sorted(CARBON_INTENSITY_G_PER_KWH.keys())

        print(f"\nRegion comparison: {self.gpu_type} x{self.num_gpus}, "
              f"{self.training_hours}h training\n")
        print(f"  {'Region':<20} {'gCO2/kWh':>10} {'Total kg CO2':>14} "
              f"{'Flights equiv':>14}")
        print("  " + "-" * 60)

        original_region = self.cloud_region
        results = []
        for region in regions:
            if region not in CARBON_INTENSITY_G_PER_KWH:
                continue
            self.cloud_region = region
            carbon_kg = self._total_carbon_kg()
            flights = carbon_kg / EQUIVALENTS["transatlantic_flights"][
                "kg_co2_per_unit"
            ]
            results.append((region, carbon_kg, flights))

        self.cloud_region = original_region

        results.sort(key=lambda x: x[1])
        for region, carbon_kg, flights in results:
            intensity = CARBON_INTENSITY_G_PER_KWH[region]
            print(f"  {region:<20} {intensity:>10.0f} "
                  f"{carbon_kg:>14,.1f} {flights:>14.1f}")


# ── Example Usage ───────────────────────────────────────────────

if __name__ == "__main__":
    # Example 1: A moderate-scale training run
    print("\n--- Example 1: Fine-tuning a mid-size model ---\n")
    estimator_small = CarbonEstimator(
        gpu_type="A100",
        num_gpus=8,
        training_hours=72,
        cloud_region="us-east",
    )
    report = estimator_small.estimate()
    estimator_small.print_report(report)

    # Example 2: A large-scale pre-training run
    print("\n--- Example 2: Pre-training a large language model ---\n")
    estimator_large = CarbonEstimator(
        gpu_type="H100",
        num_gpus=2048,
        training_hours=720,      # 30 days
        cloud_region="us-east",
    )
    report_large = estimator_large.estimate()
    estimator_large.print_report(report_large)

    # Example 3: Same training, different region
    print("\n--- Example 3: Same large model, trained in Quebec ---\n")
    estimator_green = CarbonEstimator(
        gpu_type="H100",
        num_gpus=2048,
        training_hours=720,
        cloud_region="canada-central",
    )
    report_green = estimator_green.estimate()
    estimator_green.print_report(report_green)

    # Example 4: Region comparison
    print("\n--- Example 4: Regional comparison for the large model ---")
    estimator_large.compare_regions([
        "canada-west", "canada-central", "eu-north", "eu-france",
        "brazil", "us-west", "us-east", "us-central",
        "eu-central", "japan", "asia-east", "asia-south",
        "africa-south",
    ])

34.2.3 Understanding the Output

Let's trace through the calculations for Example 1 (fine-tuning a mid-size model on 8 A100 GPUs for 72 hours in us-east):

Step 1: GPU energy. Each A100 draws 400W (0.4 kW) at TDP. With 70% utilization, each GPU draws 0.4 x 0.7 = 0.28 kW.

Step 2: Total GPU energy. 8 GPUs x 0.28 kW x 72 hours = 161.28 kWh

Step 3: Data center overhead. With PUE of 1.1: 161.28 x 1.1 = 177.41 kWh

Step 4: Carbon emissions. The us-east region has a carbon intensity of 340 gCO2/kWh = 0.34 kgCO2/kWh. 177.41 kWh x 0.34 kgCO2/kWh = 60.32 kg CO2

Step 5: Equivalents. - Transatlantic flights: 60.32 / 1600 = 0.04 flights (a small fraction) - Car miles: 60.32 / 0.21 = 287 miles - Household electricity: 60.32 / 4200 = 0.014 years (about 5 days) - Trees to offset: 60.32 / 22 = 2.7 trees for one year

This is a modest fine-tuning run. The environmental impact is real but small.

Now compare Example 2 (pre-training a large model on 2,048 H100 GPUs for 30 days in us-east):

GPU energy: 2048 x 0.7 kW x 0.7 utilization x 720 hours = 722,534 kWh

With PUE: 722,534 x 1.1 = 794,787 kWh (approximately 795 MWh)

Carbon: 794,787 x 0.34 = 270,228 kg CO2 (approximately 270 tonnes)

Equivalents: - Transatlantic flights: ~169 one-way flights - Car miles: ~1.29 million miles - Household electricity: ~64 years - Trees to offset: ~12,283 trees for one year

The difference between fine-tuning a model and pre-training a large one spans three orders of magnitude. And the regional comparison reveals that training the same model in Quebec (carbon intensity ~30 gCO2/kWh) rather than Virginia (340 gCO2/kWh) would reduce carbon emissions by approximately 91%.

Callout Box: What This Estimator Does Not Capture

This estimator provides a reasonable lower bound on training emissions. It does not account for: - Embodied carbon in GPU manufacturing (estimated at 150-200 kg CO2 per GPU) - Network and storage energy beyond what PUE captures - Failed training runs — models that diverge, crash, or underperform and must be retrained - Hyperparameter search — the dozens or hundreds of smaller training runs conducted before the final training - Inference emissions — the ongoing energy cost of running the trained model, which for widely deployed models can exceed training emissions within months - Water consumption — which varies by data center cooling technology and local climate

A comprehensive carbon accounting would include all of these factors. The estimator is a starting point, not a final answer.

34.2.4 Discussion: What Should We Do With This Information?

The CarbonEstimator is a tool for making the invisible visible. But visibility alone does not produce change. The question is: what governance decisions should follow from this information?

Mira, who had been working on VitraMed's environmental impact assessment, posed the question to the class: "VitraMed is training models that predict patient health risks. The models save lives. But training them produces carbon emissions. How do we weigh the health benefits against the environmental costs?"

Dr. Adeyemi responded with a question of her own: "Who gets to make that weighing? And who bears the consequences?"

This is the environmental version of the Power Asymmetry: the organizations that benefit from AI training (technology companies, their shareholders, their users in wealthy countries) are not the same populations that bear the environmental costs (communities near power plants, communities near data centers, future generations affected by climate change).

34.3 The Carbon Footprint of Large Models: Key Studies

34.3.1 Strubell et al. (2019): Energy and Policy Considerations

Strubell, Ganesh, and McCallum's 2019 paper, "Energy and Policy Considerations for Deep Learning in NLP," was the first major study to quantify the carbon footprint of training large NLP models. They estimated:

• Training a Transformer model with neural architecture search: ~284 tonnes CO2
• Training BERT (base): ~1.5 tonnes CO2
• Training GPT-2: estimated at similar or greater scale

The paper's most lasting contribution was not the specific numbers — which have been refined by subsequent research — but the argument that carbon emissions should be reported alongside accuracy metrics in machine learning publications. Just as we report a model's accuracy, precision, and recall, we should report its energy consumption and carbon footprint. Environmental cost should be part of the evaluation criteria for model quality.

34.3.2 Patterson et al. (2021): Carbon Emissions and Large Neural Networks

Patterson et al., writing from Google Research, provided more refined estimates and pushed back on some of Strubell's methodology. Their key contributions:

• More precise estimates based on actual hardware configurations and data center efficiency
• Demonstration that carbon emissions vary by a factor of 5-10x depending on data center location and energy sources
• Argument that the trend toward larger models could be offset by hardware efficiency improvements, algorithmic optimization, and renewable energy procurement

The paper acknowledged the problem but framed it as solvable within existing corporate sustainability practices — drawing criticism from researchers who argued that the paper underestimated the rate of model size growth and overestimated the rate of efficiency improvement.

34.3.3 The GPT-4 Scale

OpenAI did not disclose the carbon footprint of training GPT-4. Estimates by independent researchers, based on inferences about model size and training infrastructure, range from 3,000 to 13,000 tonnes of CO2 — equivalent to the annual emissions of 600-2,600 average American cars.

The lack of disclosure is itself a governance issue. If the environmental impact of AI training is not measured and reported, it cannot be governed. The Accountability Gap extends to the environment: organizations that produce significant carbon emissions through model training face no systematic requirement to disclose those emissions.

34.4 Green AI: Efficiency, Compression, and Responsible Scaling

34.4.1 The Green AI Movement

The term Green AI was coined by Schwartz et al. (2020) to describe AI research that prioritizes computational efficiency alongside accuracy. Green AI stands in contrast to what the authors call "Red AI" — the trend toward ever-larger models that achieve marginal accuracy improvements at enormous computational cost.

The Green AI movement advocates:

Efficiency as a first-class metric. Report and optimize for efficiency (accuracy per computation) rather than accuracy alone. A model that achieves 95% accuracy with 10x less computation may be more practically valuable than one that achieves 96% accuracy at 10x the cost.

Reporting compute budgets. Publish the computational resources used to develop and train models, including hardware type, training time, and estimated energy consumption. This enables fair comparison and incentivizes efficiency.

Prioritizing accessible research. The trend toward massive models concentrates AI research in a small number of well-resourced organizations. Green AI supports research that produces useful results within computational budgets accessible to academic researchers, small companies, and researchers in the Global South.

34.4.2 Technical Approaches to Efficiency

Several technical approaches can reduce the environmental footprint of AI without sacrificing performance:

Model compression. Techniques like pruning (removing unnecessary parameters), quantization (reducing numerical precision), and knowledge distillation (training a smaller "student" model to mimic a larger "teacher" model) can reduce model size by 50-90% with minimal accuracy loss.

Efficient architectures. Research into more efficient model architectures — sparse models, mixture-of-experts, linear attention mechanisms — can achieve comparable performance with fewer computations.

Transfer learning and fine-tuning. Rather than training large models from scratch for each task, fine-tuning pre-trained models on specific tasks can achieve strong performance with a fraction of the training cost. This approach distributes the environmental cost of pre-training across many downstream applications.

Data efficiency. Better data curation, active learning, and curriculum learning can achieve comparable model performance with smaller datasets and fewer training iterations.

Carbon-aware scheduling. Training runs can be scheduled to coincide with periods of low carbon intensity — when renewable energy generation is high (e.g., midday for solar, windy periods for wind) — reducing emissions without changing the total computation.

34.4.3 The Rebound Effect

A caution is warranted: efficiency improvements can produce a rebound effect (Jevons paradox), in which efficiency gains reduce the per-unit cost of computation, leading to increased demand that offsets or exceeds the efficiency gain. If more efficient models make AI cheaper, organizations may simply train more models, run more experiments, and deploy AI in more contexts — potentially increasing total emissions even as per-model emissions decline.

This dynamic means that technical efficiency alone cannot solve the environmental challenge of AI. Governance mechanisms — carbon reporting requirements, emissions caps, carbon pricing — may be necessary to ensure that efficiency gains translate into actual emissions reductions rather than increased demand.

Connection to Chapter 33: The rebound effect in AI energy consumption mirrors the automation dynamics examined in Chapter 33. In both cases, efficiency gains that are captured entirely by organizations pursuing growth can produce perverse outcomes — more total energy consumption, more total displacement — unless governance mechanisms distribute the benefits differently.

34.5 Environmental Monitoring: Data as Climate Tool

34.5.1 The Dual Role of Data Systems

Data systems are not only environmental costs — they are also environmental tools. Some of the most important environmental monitoring, climate modeling, and conservation efforts depend on data infrastructure:

Satellite earth observation. NASA's Earth Observing System, ESA's Copernicus program, and commercial satellite constellations provide continuous data on deforestation, ocean temperatures, ice sheet dynamics, atmospheric composition, and land use change. This data is essential for climate science and forms the empirical foundation for the IPCC's climate assessments.

Sensor networks. Ground-based sensor networks monitor air quality, water quality, soil moisture, and biodiversity indicators in real time. Community-operated sensor networks — like PurpleAir for air quality monitoring — enable citizens to generate environmental data independently of corporate or government systems.

Climate modeling. Global climate models require enormous computational resources — comparable to those used for AI training. The environmental cost of running these models must be weighed against the environmental benefit of the knowledge they produce.

Conservation AI. Machine learning systems identify endangered species from camera trap images, detect illegal fishing from satellite data, predict wildfire risk from weather and vegetation data, and optimize renewable energy grid management. These applications represent AI's potential to serve environmental goals.

34.5.2 Environmental Monitoring and Indigenous Knowledge

A critical intersection emerges between environmental monitoring and the indigenous data sovereignty principles examined in Chapter 32. Indigenous communities possess ecological knowledge developed over millennia — knowledge about species behavior, ecosystem dynamics, fire management, and sustainable resource use — that is increasingly recognized as essential for effective environmental management.

However, the integration of indigenous knowledge into data systems raises governance questions:

• Who controls the data? If indigenous ecological knowledge is digitized and entered into a database, does it remain under indigenous governance?
• How is credit and benefit shared? If an AI system trained on indigenous ecological knowledge produces commercially valuable predictions, who benefits?
• Are indigenous knowledge systems respected on their own terms, or are they treated as raw material to be extracted and processed by Western analytical frameworks?

"This is data colonialism applied to the environment," Eli observed. "Indigenous peoples managed these ecosystems sustainably for thousands of years. Now their knowledge is being digitized, entered into databases controlled by universities and tech companies, and used to train models that indigenous communities may never benefit from. The pattern is extraction — just of knowledge instead of resources."

34.6 Environmental Data Justice: Who Bears the Costs?

34.6.1 The Distribution of Environmental Harm

The environmental costs of data infrastructure are not distributed equitably. Several patterns of environmental injustice are visible:

Data center siting. Data centers are often located in communities that lack the political power to resist them — rural areas, low-income communities, communities of color. The environmental impacts (noise, water consumption, energy demand, backup generator emissions) are borne locally, while the economic benefits (corporate tax revenue, limited local employment) are modest.

E-waste geography. Electronic waste from data center hardware disproportionately ends up in countries in the Global South — Ghana, Nigeria, India, China — where informal recycling operations expose workers to toxic materials. The communities that bear the health costs of e-waste processing are not the communities that benefit from the digital services the hardware enabled.

Mining communities. The rare earth minerals used in GPU manufacturing — cobalt, lithium, coltan, tantalum — are often mined in the Democratic Republic of Congo, Bolivia, Chile, and other countries in the Global South, under conditions that include child labor, environmental contamination, and community displacement.

Climate impact distribution. The carbon emissions produced by data centers contribute to global climate change, whose impacts fall disproportionately on the Global South — countries that have contributed least to cumulative emissions and have the fewest resources to adapt.

34.6.2 The Power Asymmetry in Environmental Cost

"This is the Power Asymmetry in its environmental form," Dr. Adeyemi said. "The companies that benefit from AI — headquartered in San Francisco, New York, London — are not the communities that mine the cobalt, process the e-waste, breathe the air downwind of the power plant, or face the rising seas. The benefits accumulate in one place; the costs are externalized to another. And the communities bearing the costs have the least power to influence the decisions that produce them."

This analysis connects the environmental ethics of data systems to the broader framework of data justice examined in Chapter 32. Environmental data justice requires:

1. Transparency about the environmental costs of data systems — including carbon emissions, water consumption, e-waste generation, and supply chain impacts.
2. Accountability for those costs — through carbon pricing, extended producer responsibility for e-waste, and supply chain auditing.
3. Participation by affected communities in decisions about data center siting, mining operations, and e-waste processing.
4. Equitable distribution of both the benefits of data systems (which currently flow disproportionately to wealthy countries) and their costs (which are currently externalized to poorer communities).

Reflection: Use the CarbonEstimator class to calculate the carbon footprint of a hypothetical training run relevant to your field. Then identify the communities that would bear the environmental costs of that training (the communities near the data center, the power plants, and the mines). How might you reduce or redistribute those costs?

34.7 Chapter Summary

Key Concepts

• AI model training is energy-intensive, with large language models consuming hundreds of megawatt-hours and producing hundreds of tonnes of CO2 emissions, depending on model size, hardware, training duration, and data center location.
• Carbon intensity varies dramatically by region — the same computation can produce 30x more carbon in a coal-powered region than in a hydro-powered region. Location is a governance choice.
• The CarbonEstimator Python class provides a tool for estimating and contextualizing training emissions, demonstrating that environmental cost should be as visible as model performance.
• Green AI advocates for efficiency as a first-class metric, reporting compute budgets, and prioritizing research accessible to resource-constrained institutions.
• Data systems serve a dual role — contributing to environmental harm through energy consumption and e-waste, while also enabling essential environmental monitoring, climate modeling, and conservation.
• Environmental data justice demands attention to who bears the costs of data infrastructure — from data center siting to e-waste processing to climate change impacts.

Key Debates

• Should AI model developers be required to disclose the carbon footprint of training and inference, similar to environmental impact reporting in other industries?
• Does the Green AI movement's focus on efficiency adequately address the environmental challenge, or are governance mechanisms (carbon pricing, emissions caps) necessary?
• How should we weigh the environmental costs of climate modeling and conservation AI against their environmental benefits?
• Is it ethically acceptable to train large AI models in high-carbon regions when low-carbon alternatives are available?

Applied Framework

The Environmental Impact Assessment for AI: 1. Measure — Calculate the energy consumption and carbon emissions of training and inference using tools like CarbonEstimator 2. Compare — Evaluate alternative configurations (different hardware, regions, model sizes) and their environmental tradeoffs 3. Contextualize — Express emissions in familiar equivalents so that stakeholders can grasp the magnitude 4. Mitigate — Apply Green AI techniques (compression, efficient architectures, carbon-aware scheduling) to reduce impact 5. Distribute — Ask who bears the environmental costs and whether that distribution is just 6. Report — Disclose environmental impact alongside model performance metrics

What's Next

From the environmental impacts of data infrastructure, we turn to a population that is both uniquely vulnerable to data systems and uniquely poorly served by existing governance frameworks. In Chapter 35: Children, Teens, and Digital Vulnerability, we examine the special challenges of protecting young people in data-driven environments — from COPPA and the UK Age Appropriate Design Code to the mental health effects of social media and the pandemic-era expansion of educational technology. VitraMed's children's health data adds another dimension of ethical complexity.

Chapter 34 Exercises → exercises.md

Chapter 34 Quiz → quiz.md

Case Study: The Carbon Footprint of GPT-4 → case-study-01.md

Case Study: Environmental Monitoring and Indigenous Land Rights → case-study-02.md