Unraveling the Hidden Environmental Impacts of AI Solutions for Environment

In plain words

Using AI to help the environment, for example a smart building that cuts its heating, only makes sense if the AI itself does not eat up what it saves. The authors say that most work on this question counts only the electricity that the model uses, and often not even that. The making of the hardware and its disposal are usually left out.

They propose borrowing life cycle assessment, a standard way of adding up environmental damage from raw materials through to disposal. The idea is to compare the same application with and without the AI and look at the difference across several kinds of impact, not just carbon. The paper also asks readers to keep in mind rebound effects, where savings get spent on more use, and to check whether the AI works in real life, not only in the lab.

TL;DR

• A position and methodology paper. It has no experiments, no trained model and no code.
• It proposes judging an AI-for-environment service by the net life-cycle impact of the AI-enhanced application minus the reference application eq. 1.
• It argues that the common practice of measuring only use-phase energy misses production and end-of-life impacts §2.1, §3.1.
• A literature check of one review's references finds about half of the cited AI-for-Green work gives no environmental evaluation §4.2.

Problem

Training and running deep learning models consume energy, and this is usually reported as greenhouse gas (GHG) emissions §1. The authors say this energy cost is only part of the environmental picture §1. The tools for measuring this cost are of two kinds: integrated tools that measure energy during training, and online tools that estimate it from a few parameters but are less accurate §2.1. Most AI literature addresses only a small part of the direct impacts and neglects production and end of life, which goes against recommended ICT life-cycle practice §2.1. Cited work reports that manufacturing would account for about 75% of the total emissions of an iPhone 5 §2.1, and that a CPU-only data center in France had about 40% of its GHG emissions in the production phase §3.2.

The paper also argues that AI-for-Green claims lack a cost-benefit balance: the environmental gain of the AI solution has to be weighed against its own impacts §2.2, §4.1. Second-order effects (what AI changes in the application) and third-order effects (changes in technology and society, including rebound effects) are part of this picture §3.1, §4.1.

Method

The paper proposes applying life cycle assessment (LCA) to an AI service, and then comparing the result with a reference application. It defines the scope in three levels of impact §3.1:

• First-order (direct): the life cycle of the equipment that runs the AI service. Raw material extraction, manufacturing and transport are merged into a production phase; use and end of life are kept separate §3.1.
• Second-order: the change in the whole application that the AI causes, for example occupancy-based energy savings in a building §4.1.
• Third-order: broader technological and societal changes, including rebound effects. The paper says these are beyond the scope of the method and only discussed §4.1, §5.3.

Steps of the method, as the paper describes them:

1. Name the two systems: a reference application M1 without AI, and an AI-enhanced application M2 §4.
2. Choose impact criteria that match the goal and scope of the study. Examples are greenhouse gas emissions (global warming potential), water footprint, human toxicity and abiotic resource depletion. The number d of criteria is not fixed §3, eq. 1.
3. Define the functional unit, the service both systems deliver. The paper's example is heating 1 m² to 20 °C for one year §2.3.
4. Build the life cycle inventory of the AI service. It has two views: a software view of AI tasks (data acquisition, ..., inference) and a hardware view of the life cycle phases of each device used by each task §3.2, fig. 2.
5. Cover three equipment tiers, each with its support equipment: terminals, network, and data center or server. Power supply and cooling of the data center are included §3.2.
6. Assign each unit process to a life cycle stage using the ITU/ETSI recommendation for ICT. Table 1 lists the stages §3.2, tab. 1.
7. Allocate shared equipment with an allocation key. Production and end of life of shared servers can be allocated by execution time. Static use-phase energy can be split across concurrent programs §3.2.
8. Compute LCA(M1) and LCA(M2), then take the difference. LCA(M2) includes the AI service itself, LCA_AI(M2) §4.1, eq. 1.
9. Interpret the result per criterion, not as one score. The paper argues against collapsing the criteria into a single number §4.1.

The paper relates its method to a monetary value function from prior work §4.1, eq. 2 and rewrites it in terms of the LCA difference §4.1, eq. 3. It rejects the monetary form because it mixes unlike impacts into dollars §4.1.

Life cycle stages for an AI service, following the ITU recommendation and the ADEME digital services standard §3.2, tab. 1:

Source: tab. 1, which applies the ITU recommendation §3.2.

Equations, as numbered in the compiled paper:

\Delta(M_2 | M_1) = LCA(M_2) - LCA(M_1) \in \mathbb{R}^d eq. 1

V(M) = S(M) - E(M) - O(M) eq. 2

V(M_2) \approx S(M_2 \mid M_1) - E(M_2) - O(M_2) eq. 3

In eq. 1, Δ is the net change in each of d impact criteria. In eq. 2, V(M) is the value of using model M and S, E and O are the environmental benefit, the energy cost and all other impacts. The paper states that eq. 3 relates the two: V(M2) corresponds to −Δ(M2|M1), and E(M2) + O(M2) corresponds to LCA_AI(M2) §4.1.

Classification of the environmental evaluation in the case study, applied to each reference the authors read §4.2:

a. No mention of the environmental gain. b. General mention of the environmental gain. c. Brief remarks on the gain, with no figure or only an indirect one. d. An energy estimate for the application alone, leaving out the AI's own energy. e. An energy estimate that includes the AI's use phase. f. A full environmental comparison of both systems through LCA.

The procedure in pseudocode, a reading of the steps above §3.2 eq. 1:

# Net life-cycle impact of an AI-enhanced application  [§3.2] [eq. 1]
# Input:  reference app m1, AI-enhanced app m2, d impact criteria
# Output: delta, shape (d,); positive means more impact than the reference

def net_impact(m1, m2, criteria):
    # Scope every life cycle phase and tier of each system  [§3.2]
    # Each LCA sums environmental flows for the functional unit  [§2.3]
    lca_m1 = life_cycle_assessment(m1, criteria)
    lca_m2 = life_cycle_assessment(m2, criteria)
    # LCA(M2) already includes the AI service's own impacts  [§4.1]
    # Keep one value per criterion; do not collapse them  [§4.1]
    delta = lca_m2 - lca_m1  # (d,)
    return delta

Static use-phase energy of a shared device, split across the programs that run on it §3.2:

# Share of a device's static use-phase energy charged to one program  [§3.2]
# Input:  static_energy (J), n_concurrent (int, >= 1)
# Output: energy charged to this program (J)

def static_share(static_energy, n_concurrent):
    # Split evenly: with n programs running, each takes 1/n  [§3.2]
    return static_energy / n_concurrent

Hyperparameters

The paper trains no model and reports no numerical settings. Its only parameters are allocation rules and criteria, listed here.

Results

The paper reports no experiments. The only quantitative findings come from a literature check by the authors. They took references from the high-leverage domains of one climate-and-machine-learning review, and classified each reference by the kind of environmental evaluation it contains §4.2, fig. 4. These are author-reported counts from a qualitative coding.

Figure 4 shows the same counts as a Sankey diagram fig. 4. The paper also states that many references give only a distant proxy, such as a qualitative description of impacts or the run time of the program §4.2.

Paper vs code

No official code.

The footnote links in §2.1 point to third-party tools (Experiment Impact Tracker, Carbon Tracker, CodeCarbon, Green Algorithms, ML CO2 impact) and to a workshop page. None of them is this paper's code. The LCI that the paper mentions in a footnote §2.3 is not in the arXiv source we fetched. The source bundle contains a CSV of the literature reviewed (the paper's supplementary list §4.2). A GitHub repository search for "life cycle assessment AI services" returned no repositories.

Pitfalls

• This is a method with no defaults. An implementer can build the framework but cannot reproduce any number. Every input (impact criteria, functional unit, inventory, allocation keys) must come from the user's own study §3, §2.3.
• The inventory is missing. The paper says the complete LCI of a generic AI service is in its supplementary material §2.3, and that file is not in the arXiv source. Do not invent LCI values for GPUs or servers from this card.
• Data gaps are central. The production phase is important for GPUs and TPUs, yet the paper says LCAs for them are lacking §3.2. The paper also says manufacturing data for GPUs is scarce from both manufacturers and LCA databases §5.2. End-of-life data is poor; the paper cites a figure that about 80% of electronic equipment is not formally collected §3.2.
• Sign and direction. Eq. 1 is a difference of impacts; a positive value means the AI-enhanced application causes more impact. The paper does not state this sign convention in words; it follows from the definition of Δ eq. 1 and its link to V §4.1. Eq. 3 uses ≈ and does not give a formula for S(M2|M1). The paper says the sign of S cannot be stated in advance and depends on complete LCAs of both applications §4.1.
• Eq. 2 is rejected, not used. The paper argues that expressing value in dollars mixes unlike impacts, and that the monetary cost-benefit approach it relates to lacks practical means for computation §4.1. Use eq. 1.
• Allocation is judgment. The shared-server allocation key is "for instance" execution time, and the static share is 1/n only in the paper's example §3.2. Two studies with different keys will not be comparable.
• Scope changes with scale. The method is attributional. At large deployment the paper says a consequential LCA is needed, which accounts for knock-on effects such as new mines or more fossil-fuel generation §5.4. Third-order effects are out of scope §4.1.
• Terminology. "Use phase" means the use of a device §3.2. "Application phase" means the inference step of the AI service §3.2. "AI service" is the equipment; "AI solution" is the whole application §3.
• The case-study classification is subjective. The categories a–f are the authors' own coding, and the paper does not describe how references were coded or checked by a second coder. The "about half" figure should be treated as indicative §4.2.
• Technical potential, not real-world effect. The authors say even a sound LCA only shows technical potential. Socio-technical effects, such as autonomous vehicles that increase total travel, can cancel the gain §5.3.

Lineage

• Builds on: LCA methodology as standardised by ISO 14040 and 14044 and the ETSI/ITU recommendation for ICT §2.3. The paper also uses the LCA formalism of Heijungs (2002) §2.3 and the first-, second- and third-order impact taxonomy cited as Hilty (2010) and Horner (2016) §3.
• Builds on, as a starting point: Bommasani et al.'s cost-benefit framework for foundation models. The paper gives no arXiv id for it. This card adopts its value form and rejects its monetary units §2.2, §4.1.
• Compared against: Strubell et al. (GHG of NLP training) §2.1; Schwartz et al. (Green AI) §2.1; Patterson et al. (GHG reduced by a factor of 100 with low-carbon data centers and a sparse architecture) §2.1; Gupta et al. and Wu et al. (life-cycle view of devices) §2.1, §5.1; Rolnick et al. (climate applications of machine learning) §4.2.
• Superseded by: not stated.