<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.0 20040830//EN" "journalpublishing.dtd"><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" dtd-version="2.0" xml:lang="en" article-type="research-article"><front><journal-meta><journal-id journal-id-type="nlm-ta">JMIR AI</journal-id><journal-id journal-id-type="publisher-id">ai</journal-id><journal-id journal-id-type="index">41</journal-id><journal-title>JMIR AI</journal-title><abbrev-journal-title>JMIR AI</abbrev-journal-title><issn pub-type="epub">2817-1705</issn><publisher><publisher-name>JMIR Publications</publisher-name><publisher-loc>Toronto, Canada</publisher-loc></publisher></journal-meta><article-meta><article-id pub-id-type="publisher-id">v5i1e90770</article-id><article-id pub-id-type="doi">10.2196/90770</article-id><article-categories><subj-group subj-group-type="heading"><subject>Original Paper</subject></subj-group></article-categories><title-group><article-title>Quantifying and Disclosing the Environmental Footprint of AI in Research: Life Cycle&#x2013;Informed Framework and Open-Access Calculator Development Study</article-title></title-group><contrib-group><contrib contrib-type="author" corresp="yes"><name name-style="western"><surname>Mozafari</surname><given-names>Kaveh</given-names></name><degrees>MSc, MD</degrees><xref ref-type="aff" rid="aff1">1</xref></contrib><contrib contrib-type="author"><name name-style="western"><surname>Ma</surname><given-names>Yuanchao</given-names></name><degrees>PhD</degrees><xref ref-type="aff" rid="aff2">2</xref><xref ref-type="aff" rid="aff3">3</xref></contrib><contrib contrib-type="author"><name name-style="western"><surname>Amoei</surname><given-names>Mohsen</given-names></name><degrees>MSc</degrees><xref ref-type="aff" rid="aff2">2</xref></contrib><contrib contrib-type="author"><name name-style="western"><surname>Lebouche</surname><given-names>Bertrand</given-names></name><degrees>MD, PhD</degrees><xref ref-type="aff" rid="aff2">2</xref><xref ref-type="aff" rid="aff4">4</xref></contrib><contrib contrib-type="author"><name name-style="western"><surname>Osmanlliu</surname><given-names>Esli</given-names></name><degrees>MDCM, MSc</degrees><xref ref-type="aff" rid="aff5">5</xref></contrib><contrib contrib-type="author"><name name-style="western"><surname>Poenaru</surname><given-names>Dan</given-names></name><degrees>MA, MHPE, MD, PhD</degrees><xref ref-type="aff" rid="aff2">2</xref><xref ref-type="aff" rid="aff3">3</xref></contrib></contrib-group><aff id="aff1"><institution>Department of Surgical &#x0026; Interventional Sciences, McGill University</institution><addr-line>Montreal General Hospital 1650 Cedar Avenue, T5-110</addr-line><addr-line>Montreal</addr-line><addr-line>QC</addr-line><country>Canada</country></aff><aff id="aff2"><institution>McGill University Health Centre Research Institute</institution><addr-line>Montreal</addr-line><addr-line>QC</addr-line><country>Canada</country></aff><aff id="aff3"><institution>Department of Pediatrics, McGill University</institution><addr-line>Montreal</addr-line><addr-line>QC</addr-line><country>Canada</country></aff><aff id="aff4"><institution>Department of Family Medicine, Faculty of Medicine and Health Sciences, McGill University</institution><addr-line>Montreal</addr-line><addr-line>QC</addr-line><country>Canada</country></aff><aff id="aff5"><institution>Department of Pediatrics, Division of Pediatric Emergency Medicine, Montreal Children's Hospital</institution><addr-line>Montreal</addr-line><addr-line>QC</addr-line><country>Canada</country></aff><contrib-group><contrib contrib-type="editor"><name name-style="western"><surname>Yin</surname><given-names>Zhijun</given-names></name></contrib></contrib-group><contrib-group><contrib contrib-type="reviewer"><name name-style="western"><surname>Bux</surname><given-names>Christian</given-names></name></contrib><contrib contrib-type="reviewer"><name name-style="western"><surname>Tan</surname><given-names>Zuowen</given-names></name></contrib></contrib-group><author-notes><corresp>Correspondence to Kaveh Mozafari, MSc, MD, Department of Surgical &#x0026; Interventional Sciences, McGill University, Montreal General Hospital 1650 Cedar Avenue, T5-110, Montreal, QC, H3G 1A4, Canada, 1 (514) 396-2190; <email>kaveh.mozafari-lorestani@mail.mcgill.ca</email></corresp></author-notes><pub-date pub-type="collection"><year>2026</year></pub-date><pub-date pub-type="epub"><day>18</day><month>8</month><year>2026</year></pub-date><volume>5</volume><elocation-id>e90770</elocation-id><history><date date-type="received"><day>03</day><month>01</month><year>2026</year></date><date date-type="rev-recd"><day>09</day><month>05</month><year>2026</year></date><date date-type="accepted"><day>18</day><month>05</month><year>2026</year></date></history><copyright-statement>&#x00A9; Kaveh Mozafari, Yuanchao Ma, Mohsen Amoei, Bertrand Lebouche, Esli Osmanlliu, Dan Poenaru. Originally published in JMIR AI (<ext-link ext-link-type="uri" xlink:href="https://ai.jmir.org">https://ai.jmir.org</ext-link>), 18.8.2026. </copyright-statement><copyright-year>2026</copyright-year><license license-type="open-access" xlink:href="https://creativecommons.org/licenses/by/4.0/"><p>This is an open-access article distributed under the terms of the Creative Commons Attribution License (<ext-link ext-link-type="uri" xlink:href="https://creativecommons.org/licenses/by/4.0/">https://creativecommons.org/licenses/by/4.0/</ext-link>), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR AI, is properly cited. The complete bibliographic information, a link to the original publication on <ext-link ext-link-type="uri" xlink:href="https://www.ai.jmir.org/">https://www.ai.jmir.org/</ext-link>, as well as this copyright and license information must be included.</p></license><self-uri xlink:type="simple" xlink:href="https://ai.jmir.org/2026/1/e90770"/><abstract><sec><title>Background</title><p>AI research increasingly depends on energy-intensive computation, yet energy use, greenhouse gas emissions, hardware life cycle burdens, and water consumption are rarely reported in a standardized way. This lack of reproducible environmental accounting limits comparisons across studies and obscures the trade-offs among model performance, infrastructure choices, carbon intensity, and cooling water demand.</p></sec><sec><title>Objective</title><p>This study aimed to develop and describe an open-access, life cycle&#x2013;informed AI Environmental Footprint Calculator and propose a minimum reporting dataset for transparent environmental disclosure in AI research.</p></sec><sec sec-type="methods"><title>Methods</title><p>We developed a browser-based calculator that combines operational energy, regional grid carbon intensity, power usage effectiveness (PUE), water usage effectiveness, hardware embodied emissions, and workload-specific metrics for training and inference. The framework was evaluated in 3 representative scenarios: a single&#x2013;graphics processing unit laboratory fine-tuning task, a midsized academic cluster workload, and a large-scale industrial training cycle. Outputs were compared with those of established tools to identify how boundary choices and parameter assumptions affect emission estimates.</p></sec><sec sec-type="results"><title>Results</title><p>Across the scenarios, the inclusion of PUE and hardware life cycle allocation increased reported emissions compared with operational-only estimates. In the small laboratory scenario, optimization reduced total emissions from approximately 0.07 kg carbon dioxide equivalents (CO<sub>2</sub>e) to 0.05 kg CO<sub>2</sub>e and improved the proposed label from C to B. In the midsized cluster scenario, carbon-aware scheduling reduced emissions from approximately 665 kg CO<sub>2</sub>e/month to 450 kg CO<sub>2</sub>e/month&#x2014;a 32% reduction. In the large-scale scenario, shifting to renewable-backed, lower-PUE infrastructure reduced operational emissions by approximately 79% while increasing the importance of water-carbon trade-off reporting.</p></sec><sec sec-type="conclusions"><title>Conclusions</title><p>The calculator provides a practical and transparent method for reporting AI environmental footprints using auditable parameters and publication-ready outputs. Routine disclosure of energy use, emissions, water use, hardware assumptions, and regional context can improve reproducibility and support more equitable and sustainable AI research evaluation.</p></sec></abstract><kwd-group><kwd>AI</kwd><kwd>environmental impact</kwd><kwd>carbon footprint</kwd><kwd>life cycle assessment</kwd><kwd>energy consumption</kwd><kwd>water consumption</kwd><kwd>sustainable AI</kwd><kwd>data centers</kwd><kwd>AI transparency</kwd><kwd>environmental reporting</kwd></kwd-group></article-meta></front><body><sec id="s1" sec-type="intro"><title>Introduction</title><sec id="s1-1"><title>Study Motivation</title><p>AI has become a defining technology of modern science, but its rapid expansion has created a measurable environmental burden through electricity consumption, hardware manufacturing, cooling infrastructure, and water use. Data centers already account for a substantial and growing share of global electricity demand, and recent analyses indicate that AI-oriented infrastructure can intensify local grid demand, operational carbon emissions, and water withdrawals when high-density computing is paired with evaporative or liquid cooling [<xref ref-type="bibr" rid="ref1">1</xref>-<xref ref-type="bibr" rid="ref10">10</xref>]. Despite this growth, most AI manuscripts still report computational costs only as graphics processing unit (GPU) hours, floating-point operations (FLOPs), or model size, without translating these quantities into energy, emissions, hardware life cycle burdens, or water use. This prevents meaningful comparison across studies, particularly when the same workload may have very different impacts depending on the region, time of execution, power usage effectiveness (PUE), water usage effectiveness (WUE), and hardware amortization assumptions. The purpose of this study was, therefore, to develop and describe a transparent, open-access AI Environmental Footprint Calculator that integrates operational energy, life cycle hardware emissions, cooling overhead, regional grid intensity, water use, and workload-level metrics into a reproducible reporting framework for AI research.</p></sec><sec id="s1-2"><title>Theoretical Background and Literature Review</title><p>In response to the growing awareness of AI as a high-energy technology, multiple tools have emerged to quantify the environmental footprint of machine learning (ML) workloads. These frameworks aim to translate computational activity, primarily central processing unit and GPU utilization, into measurable ecological indicators, such as electricity use (kWh) and carbon dioxide equivalent (CO<sub>2</sub>e) emissions, and have become critical first steps toward standardized sustainability reporting in AI research and engineering.</p><p>The models described above have been instrumental in encouraging reproducibility and environmental awareness across diverse laboratories. They enable the quantification of sustainability even in institutions without direct metering infrastructure, providing low-barrier entry points for academic users. Their underlying methodology, however, remains grounded in operational energy measurement, typically runtime power &#x00D7; grid intensity, without integrating a life cycle assessment (LCA) of hardware manufacturing, infrastructure, and cooling systems. Recent studies have shown that these unaccounted phases can constitute a large share of the total environmental impact, particularly for large-scale model training and inference [<xref ref-type="bibr" rid="ref1">1</xref>-<xref ref-type="bibr" rid="ref6">6</xref>,<xref ref-type="bibr" rid="ref9">9</xref>].</p><p>While these existing tools form the methodological foundation for transparent reporting, their variability in scope, required inputs, and regional assumptions limits comparability across studies. The growing complexity of AI infrastructure calls for next-generation frameworks that incorporate cradle-to-grave accounting, inference energy, and real-time regional grid data, thereby bridging operational measurements with holistic life cycle sustainability analyses [<xref ref-type="bibr" rid="ref1">1</xref>-<xref ref-type="bibr" rid="ref9">9</xref>].</p></sec><sec id="s1-3"><title>Gaps in Existing Models and the Need for an Accessible Life-Cycle Approach</title><p>Recent data-center life cycle studies strengthen the rationale for this broader boundary. The critical analysis by Bux et al [<xref ref-type="bibr" rid="ref10">10</xref>] of the global warming potential of data centers emphasizes that digital services should be assessed using life cycle thinking rather than only operational electricity because infrastructure, cooling systems, regional grid mix, equipment lifetime, and utilization all shift the resulting footprint. Studies of data-center water and electricity footprints further show that decarbonization strategies may shift impacts between categories: lower-carbon electricity or liquid-cooled facilities can reduce CO<sub>2</sub>e while increasing water demand or local resource pressure [<xref ref-type="bibr" rid="ref4">4</xref>,<xref ref-type="bibr" rid="ref7">7</xref>,<xref ref-type="bibr" rid="ref10">10</xref>,<xref ref-type="bibr" rid="ref11">11</xref>]. These findings support a calculator design that reports both carbon and water indicators and makes all parameter sources explicit.</p><p>Existing carbon-tracking tools, such as those described above, represent essential first steps toward accountability but face several technical and practical limitations that limit their widespread scientific adoption.</p><p>First, existing models often lack granularity and completeness: most estimate operational energy during model training by multiplying the average device power by runtime and applying a regional emission factor (EF). This approach can omit hardware manufacturing and end-of-life burdens, cooling energy, and water consumption associated with data-center operation [<xref ref-type="bibr" rid="ref1">1</xref>-<xref ref-type="bibr" rid="ref7">7</xref>,<xref ref-type="bibr" rid="ref10">10</xref>,<xref ref-type="bibr" rid="ref11">11</xref>].</p><p>Second, current models lack sufficient temporal and geographic resolution. Current calculators typically use country-level or annualized carbon-intensity factors, ignoring hourly grid fluctuations and renewable intermittency [<xref ref-type="bibr" rid="ref7">7</xref>]. Intermittency refers to fluctuations in the supply of renewable energy (eg, solar and wind) over time, which affect grid carbon intensity and the accuracy of emission estimates. This coarse approach can misrepresent actual emissions by factors of 2 to 3, depending on when and where the computation occurs [<xref ref-type="bibr" rid="ref4">4</xref>,<xref ref-type="bibr" rid="ref7">7</xref>]. None of the popular frameworks currently integrate real-time grid data or regional proportions of PUE and WUE, despite evidence from Alissa et al [<xref ref-type="bibr" rid="ref4">4</xref>] and the International Energy Agency (IEA) [<xref ref-type="bibr" rid="ref7">7</xref>] that such variables significantly alter life-cycle outcomes.</p><p>Third, current models offer limited accessibility for nonexperts; most tools require command-line installation, API keys, or specialized logging frameworks, posing challenges for researchers in the health and social sciences, as well as in small academic laboratories. These users often lack permission to install monitoring agents on shared clusters, leaving them dependent on rough manual estimates [<xref ref-type="bibr" rid="ref2">2</xref>,<xref ref-type="bibr" rid="ref5">5</xref>,<xref ref-type="bibr" rid="ref8">8</xref>]. The absence of intuitive interfaces and standardized reporting templates also undermines consistency across publications.</p><p>There is, therefore, a clear need for a more accessible, holistic, and precise framework that combines fine-grained life cycle accounting (hardware, operational, and cooling phases) with user-friendly automation. Such a system should integrate seamlessly into existing research workflows, offer meaningful uncertainty ranges, and automatically produce publication-ready environmental reports. This combination of scientific rigor and usability would bridge the gap between advanced sustainability analytics and everyday research practice, supporting broader transparency and reproducibility in AI [<xref ref-type="bibr" rid="ref1">1</xref>-<xref ref-type="bibr" rid="ref9">9</xref>].</p></sec></sec><sec id="s2" sec-type="methods"><title>Methods</title><sec id="s2-1"><title>Calculator Framework and Core Features</title><p>The proposed AI Environmental Footprint Calculator [<xref ref-type="bibr" rid="ref12">12</xref>] (REF-CALC) expands on prior carbon-tracking tools by integrating fine-grained LCA, real-time energy data, and multidimensional environmental indicators within a single platform. Its design philosophy is grounded in the 2025 recommendations for cradle-to-grave transparency in AI systems [<xref ref-type="bibr" rid="ref1">1</xref>-<xref ref-type="bibr" rid="ref6">6</xref>,<xref ref-type="bibr" rid="ref9">9</xref>].</p><p>The calculator incorporates the following methodological features:</p><list list-type="bullet"><list-item><p>Comprehensive boundary coverage: Unlike most operational-only models, the calculator quantifies 4 emission components:</p><list list-type="bullet"><list-item><p>Operational energy (runtime GPU and central processing unit power &#x00D7; regional grid intensity)</p></list-item><list-item><p>Hardware manufacturing and end-of-life burdens are assessed using embodied carbon factors derived from Schneider et al [<xref ref-type="bibr" rid="ref1">1</xref>] and Falk et al [<xref ref-type="bibr" rid="ref6">6</xref>]</p></list-item><list-item><p>Cooling and infrastructure overheads are accounted for through dynamic PUE and optional WUE parameters [<xref ref-type="bibr" rid="ref4">4</xref>,<xref ref-type="bibr" rid="ref7">7</xref>]</p></list-item><list-item><p>Inference energy per output unit is expressed as CO<sub>2</sub>e/1000 tokens or per inference request [<xref ref-type="bibr" rid="ref3">3</xref>]</p></list-item></list></list-item></list><list list-type="bullet"><list-item><p>Finer temporal and regional granularity: The model retrieves hourly grid-carbon-intensity data from public APIs (eg, Electricity Maps and IEA datasets) and automatically adjusts calculations based on the user&#x2019;s selected location, enabling realistic estimates for carbon-aware scheduling scenarios [<xref ref-type="bibr" rid="ref7">7</xref>].</p></list-item><list-item><p>Transparent equations and open documentation: All assumptions, conversion factors, emission coefficients, and device lifetimes are visible within the interface. Each calculation is traceable and auditable, aligning with the reproducibility standards advocated by Morrison et al [<xref ref-type="bibr" rid="ref2">2</xref>] and the Federation of American Scientists (FAS) [<xref ref-type="bibr" rid="ref8">8</xref>].</p></list-item><list-item><p>Multi-indicator labeling: In addition to total CO<sub>2</sub>e, the system outputs energy (kWh), water (L), and renewable-energy share, generating a standardized AI environmental label rated from A (very efficient) to E (inefficient). This label mirrors established consumer energy-rating systems and embodies the &#x201C;sustainable scaling&#x201D; principles described by Desroches et al [<xref ref-type="bibr" rid="ref5">5</xref>]. Displaying the label alongside model cards or dataset statements would make environmental performance an explicit part of model evaluation criteria. The A-E grade is assigned by positioning a workload&#x2019;s carbon intensity, expressed as CO<sub>2</sub>e per 10&#x2079; FLOPs for training or per 1000 tokens for inference, within a reference distribution constructed from a curated set of published AI workloads and standardized benchmark configurations reported in the recent literature. This reference group includes representative training and inference workloads spanning small academic experiments, midscale research clusters, and large-scale industrial models, using harmonized assumptions for hardware type, utilization, and grid-carbon intensity. In the current implementation, grade A denotes the top 15% of the most carbon-efficient workloads within this reference distribution, grade B the next 20%, grade C the middle 30%, grade D the following 20%, and grade E the bottom 15%. These percentile-based thresholds provide intuitive interpretability while accommodating ongoing improvements in model architecture, hardware efficiency, and energy infrastructure.</p></list-item></list><p>Collectively, these features form the core computational framework of the AI Environmental Footprint Calculator. To provide a consolidated view of the 4 components described above, <xref ref-type="table" rid="table1">Table 1</xref> summarizes the inputs and computational pathways of the AI Environmental Footprint Calculator. As detailed in the <italic>Calculator Framework and Core Features</italic> section, the calculator integrates hardware life cycle emissions, operational energy use, cooling overhead, and inference-level granularity into a unified estimation pipeline.</p><p>These components collectively generate the environmental indicators (kWh, CO<sub>2</sub>e, water use, and A-E label) applied in the validation scenarios presented in the <italic>Results</italic> section.</p><table-wrap id="t1" position="float"><label>Table 1.</label><caption><p>Components of the AI Environmental Footprint Calculator and corresponding outputs.</p></caption><table id="table1" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Component</td><td align="left" valign="bottom">Description</td><td align="left" valign="bottom">Formula and inputs</td><td align="left" valign="bottom">Contribution to final output</td></tr></thead><tbody><tr><td align="left" valign="top">1. Hardware life cycle assessment</td><td align="left" valign="top">Embodied emissions from manufacturing, transportation, and end-of-life disposal of hardware</td><td align="left" valign="top">Embodied CO<sub>2</sub>e<sup><xref ref-type="table-fn" rid="table1fn1">a</xref></sup> (kg) per device, amortized over lifetime (h)</td><td align="left" valign="top">Adds embodied CO<sub>2</sub>e component</td></tr><tr><td align="left" valign="top">2. Operational energy</td><td align="left" valign="top">Energy consumed during training or inference</td><td align="left" valign="top">Device power (kW) &#x00D7; runtime (h)</td><td align="left" valign="top">Produces kWh, contributes to CO<sub>2</sub>e, and water (L)</td></tr><tr><td align="left" valign="top">3. Cooling and infrastructure overhead</td><td align="left" valign="top">Data-center overhead energy and cooling water</td><td align="left" valign="top">PUE<sup><xref ref-type="table-fn" rid="table1fn2">b</xref></sup> &#x00D7; IT energy; WUE<sup><xref ref-type="table-fn" rid="table1fn3">c</xref></sup> &#x00D7; IT energy</td><td align="left" valign="top">Contributes to additional CO<sub>2</sub>e and water (L)</td></tr><tr><td align="left" valign="top">4. Inference-specific granularity</td><td align="left" valign="top">Per 1000-token or per-request footprint</td><td align="left" valign="top">CO<sub>2</sub>e/1000 tokens from operational+overhead components</td><td align="left" valign="top">Produces inference-level CO<sub>2</sub>e and A-E classification</td></tr></tbody></table><table-wrap-foot><fn id="table1fn1"><p><sup>a</sup>CO<sub>2</sub>e: carbon dioxide equivalent.</p></fn><fn id="table1fn2"><p><sup>b</sup>PUE: power usage effectiveness.</p></fn><fn id="table1fn3"><p><sup>c</sup>WUE: water usage effectiveness.</p></fn></table-wrap-foot></table-wrap></sec><sec id="s2-2"><title>Integration With Research Workflows</title><p>The calculator is intentionally lightweight and designed to integrate seamlessly into everyday ML workflows without imposing additional software dependencies. Because the tool runs entirely on the client side in a web browser, it requires no installation, can be used on any operating system, and does not access or transmit user data. Researchers can directly input model characteristics, hardware configurations, and workload parameters&#x2014;or retrieve live hourly grid-carbon intensity values via the integrated Electricity Maps API&#x2014;to generate reproducible environmental estimates aligned with emerging reporting recommendations for transparency and life cycle completeness [<xref ref-type="bibr" rid="ref2">2</xref>,<xref ref-type="bibr" rid="ref7">7</xref>].</p><p>All equations, assumptions, emission coefficients, and device lifetimes are fully exposed within the interface, supporting auditable and traceable reporting, consistent with the reproducibility standards emphasized by Morrison et al [<xref ref-type="bibr" rid="ref2">2</xref>] and the FAS [<xref ref-type="bibr" rid="ref8">8</xref>]. The calculator also provides inference-specific metrics (eg, CO<sub>2</sub>e per token and per 1000 tokens), automated PUE and WUE adjustments, and intuitive household-energy equivalences to facilitate communication across technical and nontechnical audiences.</p><p>By emphasizing accessibility, transparency, and zero-setup use, the tool embeds environmental accounting directly into the researcher&#x2019;s workflow and lowers the barrier to routine sustainability reporting in ML projects.</p></sec><sec id="s2-3"><title>Minimum Reproducible Dataset and Parameter Sources</title><p>To address reviewer concerns about reproducibility, the revised framework specifies how each minimum reporting parameter should be measured or documented. Hardware should be reported as the accelerator model, count, memory class when relevant, and hardware life cycle reference source or version, such as a manufacturer disclosure, ecoinvent or Boavizta-style factor, or peer-reviewed LCA. Energy should be reported as measured kWh when direct metering is available, or estimated from device power, utilization, and runtime when metering is unavailable. PUE and WUE should be taken from the facility operator when possible; otherwise, authors should state the assumed value and source. Grid intensity should include the region, date or time window, and whether an hourly API value or annual average was used. Workload information should include total tokens, images, FLOPs, runtime, batch size, or sequence length when applicable, and whether inference or training is being assessed. This structure creates a unified basis for reporting while remaining usable by laboratories without direct metering infrastructure.</p></sec><sec id="s2-4"><title>Accessibility and Ease of Use</title><p>The interface prioritizes inclusivity across expertise levels:</p><list list-type="bullet"><list-item><p>For nonexperts and small laboratories: The web version offers a minimal-input mode that requires only the GPU type, runtime hours, and location to produce immediate results with uncertainty ranges.</p></list-item><list-item><p>For advanced users: An &#x201C;expert view&#x201D; unlocks adjustable LCA parameters, grid profiles, and batch-processing capabilities. To enhance interpretability, the calculator not only presents numerical results (kWh and CO<sub>2</sub>e) but also visualizes them through real-world household equivalences, allowing users to relate computational energy use to familiar activities such as lighting, heating, or appliance operation.</p></list-item><list-item><p>Visualization: Interactive graphs display emissions by source (operations, hardware, and cooling) and over time, enhancing interpretability for grant proposals and sustainability reports.</p></list-item><list-item><p>No installation barriers: Because calculations run entirely in the browser or via an HTTPS API, the tool functions on institutional machines without administrative privileges, a key limitation noted for prior models [<xref ref-type="bibr" rid="ref13">13</xref>-<xref ref-type="bibr" rid="ref15">15</xref>].</p></list-item></list><p>By promoting scientific rigor and usability, the calculator enables researchers at any scale, from individual graduate projects to industrial LLM training, to quantify and report their environmental impact with transparency and precision.</p></sec><sec id="s2-5"><title>Ethical Considerations</title><p>Environmental transparency must coexist with equitable access to computing. The tool, therefore, encourages low-carbon scheduling for publicly funded and academic research while discouraging &#x201C;grid shopping&#x201D; practices that merely relocate emissions geographically. This approach supports fair access to clean computing and aligns with the broader goals of responsible AI development.</p></sec></sec><sec id="s3" sec-type="results"><title>Results</title><sec id="s3-1"><title>Illustrative Scenarios</title><p>To demonstrate the functionality and practical relevance of the proposed calculator, 3 representative scenarios were modeled. Each example corresponds to a different research scale, from an individual small-laboratory training run to a large-scale generative AI deployment, and illustrates how the environmental insights produced by the calculator can guide optimization and decision-making. <xref ref-type="table" rid="table2">Table 2</xref> illustrates how the 3 example workloads presented in the <italic>Results</italic> section translate into household electricity use, using common appliances as reference points. For context, all 3 examples below report the corresponding A-E environmental label, where A indicates high efficiency relative to benchmarked workloads and E represents comparatively inefficient processes (see <italic>Calculator Framework and Core Features</italic> section).</p><table-wrap id="t2" position="float"><label>Table 2.</label><caption><p>Comparison of representative AI workloads with everyday household electricity use<sup><xref ref-type="table-fn" rid="table2fn1">a</xref></sup>.</p></caption><table id="table2" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Household device or activity</td><td align="left" valign="bottom">Small laboratory (5 kWh)</td><td align="left" valign="bottom">Midsized cluster (1900 kWh)</td><td align="left" valign="bottom">Large-scale industrial training cycle (68,000 kWh)</td></tr></thead><tbody><tr><td align="left" valign="top">Energy use (kWh)</td><td align="left" valign="top">5</td><td align="left" valign="top">1900</td><td align="left" valign="top">68,000</td></tr><tr><td align="left" valign="top">60 W light bulb</td><td align="left" valign="top">&#x2248;83 h (3.5 d)</td><td align="left" valign="top">&#x2248;31,667 h (3.6 y)</td><td align="left" valign="top">&#x2248;1.13 million h (129 y)</td></tr><tr><td align="left" valign="top">Laptop (50 W)</td><td align="left" valign="top">&#x2248;100 h (4 d)</td><td align="left" valign="top">&#x2248;38,000 h (4.3 y)</td><td align="left" valign="top">&#x2248;1.36 million h (155 y)</td></tr><tr><td align="left" valign="top">Space heater (1.5 kW)</td><td align="left" valign="top">&#x2248;3.3 h</td><td align="left" valign="top">&#x2248;1267 h (53 d)</td><td align="left" valign="top">&#x2248;45,333 h (5.2 y)</td></tr><tr><td align="left" valign="top">Clothes dryer (2 kW)</td><td align="left" valign="top">&#x2248;2.5 h (&#x2248;1 load)</td><td align="left" valign="top">&#x2248;950 h (&#x2248;380 loads)</td><td align="left" valign="top">&#x2248;34,000 h (&#x2248;13,600 loads)</td></tr><tr><td align="left" valign="top">Refrigerator (150 W)</td><td align="left" valign="top">&#x2248;33 h (1.4 d)</td><td align="left" valign="top">&#x2248;12,667 h (1.4 y)</td><td align="left" valign="top">&#x2248;453,000 h (&#x2248;52 y)</td></tr><tr><td align="left" valign="top">Electric vehicle charging (7 kW)</td><td align="left" valign="top">&#x2248;0.7 h (~7 km range)</td><td align="left" valign="top">&#x2248;271 h (~2700 km)</td><td align="left" valign="top">&#x2248;9714 h (~97,000 km)</td></tr><tr><td align="left" valign="top">Average Canadian home electricity (750 kWh/mo)</td><td align="left" valign="top">&#x2248;0.007 mo (~5 h)</td><td align="left" valign="top">&#x2248;2.5 mo</td><td align="left" valign="top">&#x2248;90 mo (~7.5 y)</td></tr></tbody></table><table-wrap-foot><fn id="table2fn1"><p><sup>a</sup>Energy consumption from the 3 example scenarios (5 kWh, 1900 kWh, and 68,000 kWh) is expressed as equivalent operation time or quantity for typical household appliances. Appliance power ratings are based on average Canadian household data [<xref ref-type="bibr" rid="ref7">7</xref>].</p></fn></table-wrap-foot></table-wrap></sec><sec id="s3-2"><title>Small Laboratory Fine-Tuning Scenario</title><p>A small academic group fine-tuned a pretrained language model (7B parameters) on 1 A100 GPU (Nvidia) for 12 hours in Montr&#x00E9;al, where the grid mix is ~95% renewable (<xref ref-type="fig" rid="figure1">Figure 1</xref>). The following example illustrates the estimated carbon footprint before and after optimization:</p><list list-type="bullet"><list-item><p>Initial configuration: Mixed-precision disabled; inefficient data loading resulted in an average draw of ~420 W.</p></list-item><list-item><p>Baseline result:</p><list list-type="bullet"><list-item><p>Operational energy &#x2248; 5.0 kWh &#x2192; 0.05 kg CO<sub>2</sub>e (@10 g CO<sub>2</sub>e/kWh)</p></list-item><list-item><p>Embodied (amortized) &#x2248; 0.02 kg CO<sub>2</sub>e [<xref ref-type="bibr" rid="ref1">1</xref>,<xref ref-type="bibr" rid="ref6">6</xref>]</p></list-item><list-item><p>Total &#x2248; 0.07 kg CO<sub>2</sub>e &#x2192; Label &#x201C;C&#x201D;</p></list-item></list></list-item><list-item><p>After optimization: Mixed-precision (FP16) enabled and loaders parallelized, reducing wall time by 35% and average power consumption by 10%.</p><list list-type="bullet"><list-item><p>Operational energy &#x2248; 3.0 kWh; total &#x2248; 0.05 kg CO<sub>2</sub>e &#x2192; Label &#x201C;B&#x201D;</p></list-item></list></list-item></list><fig position="float" id="figure1"><label>Figure 1.</label><caption><p>Sensitivity of total carbon dioxide equivalent (CO<sub>2</sub>e) estimates to key model parameters. Horizontal bars show the relative change in total CO<sub>2</sub>e when grid emission factor varies by &#x00B1;30%, power usage effectiveness (PUE) varies from 1.1 to 1.7, and hardware utilization varies from 50% to 95%. Orange denotes the lower-bound parameter value; blue denotes the upper-bound parameter value. Values shown within the bars are relative changes from the baseline.</p></caption><graphic alt-version="no" mimetype="image" position="float" xlink:type="simple" xlink:href="ai_v5i1e90770_fig01.png"/></fig><p>This case highlights how simple software optimizations can yield material carbon reductions, even where grid emissions are low. The calculator&#x2019;s disaggregation of operational versus embodied impacts clarifies that the hardware footprint remains dominant when renewable energy is available [<xref ref-type="bibr" rid="ref1">1</xref>,<xref ref-type="bibr" rid="ref3">3</xref>,<xref ref-type="bibr" rid="ref6">6</xref>].</p></sec><sec id="s3-3"><title>Midsized Research Cluster Scenario</title><p>A university research group operates an 8-GPU node (A100 80 GB) shared among several projects. Using batch import mode, the team uploaded a month&#x2019;s worth of Slurm Workload Manager logs (SchedMD; &#x2248;1400 GPU-h total).</p><list list-type="bullet"><list-item><p>Baseline scenario: Continuous queuing produced 1900 kWh total consumption with a regional grid intensity of 0.25 kg CO<sub>2</sub>e/kWh; PUE = 1.4 &#x2192; CO<sub>2</sub>e &#x2248; 665 kg/month.</p></list-item><list-item><p>After implementing carbon-aware scheduling:</p><list list-type="bullet"><list-item><p>Jobs dispatched preferentially during low-intensity hours reduced the average EF to 0.17 kg CO<sub>2</sub>e/kWh [<xref ref-type="bibr" rid="ref7">7</xref>].</p></list-item><list-item><p>Operational energy remained unchanged, but total emissions fell to 450 kg CO<sub>2</sub>e (&#x2212;32%); water consumption also dropped by &#x2248;10% due to cooler nighttime operation [<xref ref-type="bibr" rid="ref4">4</xref>,<xref ref-type="bibr" rid="ref7">7</xref>].</p></list-item></list></list-item></list><p>The calculator&#x2019;s hourly-resolved grid factors and visualization dashboard highlight the benefits of time-shifting workloads and document month-to-month trends for sustainability reporting [<xref ref-type="bibr" rid="ref2">2</xref>,<xref ref-type="bibr" rid="ref5">5</xref>,<xref ref-type="bibr" rid="ref7">7</xref>]. Following this optimization, the label improved from C to B.</p></sec><sec id="s3-4"><title>Large-Scale Training and Facility Scenario</title><p>A commercial consortium trained a 70-B-parameter generative model using 512 A100 GPUs for 24 days (~300,000 GPU-h).</p><p>The calculator is integrated:</p><p>Assuming a mean accelerator power-draw fraction of 39.4% relative to rated power, estimated IT energy was 512 x 0.45 kW x 0.394 x 24 days x 24 h/day = approximately 52,300 kWh. Applying a PUE of 1.3 resulted in approximately 68,000 kWh of facility energy.</p><list list-type="bullet"><list-item><p>Grid EF: 0.38 kg CO<sub>2</sub>e/kWh &#x2192; 25.8 t CO<sub>2</sub>e.</p></list-item><list-item><p>Embodied hardware (amortized): 0.09 t CO<sub>2</sub>e per GPU &#x00D7; (24 d/3 y &#x2248; 0.022) &#x2192; 1.0 t CO<sub>2</sub>e.</p></list-item><list-item><p>Total: ~26.8 t CO<sub>2</sub>e.</p></list-item></list><p>The calculator presents both CO<sub>2</sub>e-WUE trade-offs and per-token metrics:</p><disp-formula><mml:math id="eqn1"><mml:mstyle displaystyle="true" scriptlevel="0"><mml:mrow><mml:mstyle displaystyle="true" scriptlevel="0"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="normal">p</mml:mi><mml:mi mathvariant="normal">e</mml:mi><mml:mi mathvariant="normal">r</mml:mi><mml:mtext>&#x00A0;</mml:mtext><mml:mi mathvariant="normal">t</mml:mi><mml:mi mathvariant="normal">o</mml:mi><mml:mi mathvariant="normal">k</mml:mi><mml:mi mathvariant="normal">e</mml:mi><mml:mi mathvariant="normal">n</mml:mi></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="normal">s</mml:mi><mml:mi mathvariant="normal">i</mml:mi><mml:mi mathvariant="normal">t</mml:mi><mml:mi mathvariant="normal">e</mml:mi></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="normal">t</mml:mi><mml:mi mathvariant="normal">o</mml:mi><mml:mi mathvariant="normal">k</mml:mi><mml:mi mathvariant="normal">e</mml:mi><mml:mi mathvariant="normal">n</mml:mi><mml:mi mathvariant="normal">s</mml:mi></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">C</mml:mi><mml:msub><mml:mi mathvariant="normal">O</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:mrow><mml:mtext>&#x00A0;</mml:mtext><mml:msub><mml:mrow><mml:mi mathvariant="normal">e</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mi mathvariant="normal">p</mml:mi><mml:mi mathvariant="normal">e</mml:mi><mml:mi mathvariant="normal">r</mml:mi><mml:mtext>&#x00A0;</mml:mtext><mml:mi mathvariant="normal">t</mml:mi><mml:mi mathvariant="normal">o</mml:mi><mml:mi mathvariant="normal">k</mml:mi><mml:mi mathvariant="normal">e</mml:mi><mml:mi mathvariant="normal">n</mml:mi></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="normal">p</mml:mi><mml:mi mathvariant="normal">e</mml:mi><mml:mi mathvariant="normal">r</mml:mi><mml:mtext>&#x00A0;</mml:mtext><mml:mi mathvariant="normal">t</mml:mi><mml:mi mathvariant="normal">o</mml:mi><mml:mi mathvariant="normal">k</mml:mi><mml:mi mathvariant="normal">e</mml:mi><mml:mi mathvariant="normal">n</mml:mi></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x00D7;</mml:mo><mml:msub><mml:mrow><mml:mi mathvariant="normal">E</mml:mi><mml:mi mathvariant="normal">F</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mi mathvariant="normal">g</mml:mi><mml:mi mathvariant="normal">r</mml:mi><mml:mi mathvariant="normal">i</mml:mi><mml:mi mathvariant="normal">d</mml:mi></mml:mrow></mml:mrow></mml:msub></mml:mstyle></mml:mrow></mml:mstyle></mml:math></disp-formula><p>This yielded approximately 0.45 g CO2e per 1,000 tokens before optimization and 0.11 g CO2e per 1,000 tokens after optimization. The resulting label improved from D to B.</p><p>This scenario illustrates the calculator&#x2019;s ability to conduct cradle-to-grave assessments, compare facility scenarios, and quantify trade-offs among carbon, water, and efficiency [<xref ref-type="bibr" rid="ref1">1</xref>,<xref ref-type="bibr" rid="ref4">4</xref>-<xref ref-type="bibr" rid="ref7">7</xref>].</p><p>To better contextualize the scale of these computations, the calculator translates each example&#x2019;s total energy expenditure into familiar household electricity uses. <xref ref-type="table" rid="table2">Table 2</xref> illustrates how the same energy values correspond to the operation of standard appliances, ranging from lighting and heating to refrigeration and laundry. These equivalences help users intuitively grasp the physical magnitude of AI workloads by relating them to everyday activities and durations.</p><p>Complementing the 3 validation scenarios, we also conducted a sensitivity analysis of the model&#x2019;s most influential parameters, including grid EF, PUE, WUE, GPU utilization, and hardware lifetime (<xref ref-type="supplementary-material" rid="app1">Multimedia Appendix 1</xref>). This assessment confirmed that the calculator responds consistently to realistic variations in parameters and that grid intensity and PUE dominate overall uncertainty. Incorporating both empirical scenarios and parameter-level robustness checks strengthens the validity of the proposed framework.</p><p>These comparisons make the calculator&#x2019;s results more relatable for nonspecialists and demonstrate the societal scale of energy demand across different levels of AI development.</p><p>Across different application scales, the calculator consistently produced interpretable metrics that guided meaningful operational improvements. In smaller projects, the most significant reductions came from algorithmic efficiency improvements, with optimized code and precision settings directly reducing energy consumption. At the medium scale, temporal grid variability and carbon-aware scheduling delivered the most significant relative benefits, demonstrating that aligning computation with lower-emission hours can meaningfully reduce footprints. At the largest, hyperscale level, infrastructure design and energy-source selection, such as the use of renewable-backed power or efficient cooling systems, became the dominant factors determining total emissions. Collectively, these findings validate the calculator&#x2019;s adaptability and show that integrating life-cycle data, temporal resolution, and a user-friendly interface can enable practical decarbonization strategies across diverse research environments [<xref ref-type="bibr" rid="ref1">1</xref>-<xref ref-type="bibr" rid="ref9">9</xref>].</p></sec><sec id="s3-5"><title>Comparison With Existing Tools</title><p>To quantitatively validate the proposed framework, we compared its outputs with CodeCarbon and the Green Algorithms Calculator across the 3 validation scenarios (<xref ref-type="table" rid="table3">Table 3</xref>). The differences between the tools were not interpreted as errors; rather, they reflect distinct methodological boundaries. CodeCarbon primarily estimates operational emissions from device power, runtime, and grid intensity, so it yields lower values when cooling and hardware life cycle burdens are excluded. Green Algorithms includes a broader data-center energy adjustment through PUE but generally does not allocate accelerator manufacturing impacts at the workload level. The proposed calculator reports higher totals when PUE, WUE, and embodied hardware allocation are included because it uses a life-cycle boundary that includes facility overhead and accelerator manufacturing. Therefore, the variation in <xref ref-type="table" rid="table3">Table 3</xref> can be attributed mainly to 4 variables: whether cooling overhead is included, whether hardware life cycle emissions are amortized to the workload, whether grid factors are static or time-resolved, and whether inference or per-unit workload metrics are reported. Making these boundary choices visible is a central contribution of the calculator because it allows readers to understand why 2 tools can produce different emissions estimates for the same AI workload.</p><table-wrap id="t3" position="float"><label>Table 3.</label><caption><p>Quantitative comparison of environmental impact estimates across tools for the 3 validation scenarios<sup><xref ref-type="table-fn" rid="table3fn1">a</xref></sup>.</p></caption><table id="table3" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Scenario and tool</td><td align="left" valign="bottom">Energy Estimate (kWh)</td><td align="left" valign="bottom">Cooling included (PUE<sup><xref ref-type="table-fn" rid="table3fn2">b</xref></sup>)</td><td align="left" valign="bottom">Hardware LCA<sup><xref ref-type="table-fn" rid="table3fn3">c</xref></sup> included</td><td align="left" valign="bottom">Total CO<sub>2</sub>e<sup><xref ref-type="table-fn" rid="table3fn4">d</xref></sup></td></tr></thead><tbody><tr><td align="left" valign="top" colspan="5">Small laboratory (1 &#x00D7; A100, 12 h, Montreal)</td></tr><tr><td align="left" valign="top"><named-content content-type="indent">&#x00A0;&#x00A0;&#x00A0;&#x00A0;</named-content>CodeCarbon</td><td align="left" valign="top">5.0</td><td align="left" valign="top">No</td><td align="left" valign="top">No</td><td align="left" valign="top">0.05 kg</td></tr><tr><td align="left" valign="top"><named-content content-type="indent">&#x00A0;&#x00A0;&#x00A0;&#x00A0;</named-content>Green Algorithms</td><td align="left" valign="top">5.0</td><td align="left" valign="top">Yes</td><td align="left" valign="top">No</td><td align="left" valign="top">0.06 kg</td></tr><tr><td align="left" valign="top"><named-content content-type="indent">&#x00A0;&#x00A0;&#x00A0;&#x00A0;</named-content>Proposed calculator</td><td align="left" valign="top">5.0</td><td align="left" valign="top">Yes</td><td align="left" valign="top">Yes</td><td align="left" valign="top">0.07 kg</td></tr><tr><td align="left" valign="top" colspan="5">Midsized cluster (8 &#x00D7; A100, monthly)</td></tr><tr><td align="left" valign="top"><named-content content-type="indent">&#x00A0;&#x00A0;&#x00A0;&#x00A0;</named-content>CodeCarbon</td><td align="left" valign="top">1900</td><td align="left" valign="top">No</td><td align="left" valign="top">No</td><td align="left" valign="top">475 kg</td></tr><tr><td align="left" valign="top"><named-content content-type="indent">&#x00A0;&#x00A0;&#x00A0;&#x00A0;</named-content>Green Algorithms</td><td align="left" valign="top">1900</td><td align="left" valign="top">Yes</td><td align="left" valign="top">No</td><td align="left" valign="top">520 kg</td></tr><tr><td align="left" valign="top"><named-content content-type="indent">&#x00A0;&#x00A0;&#x00A0;&#x00A0;</named-content>Proposed calculator</td><td align="left" valign="top">1900</td><td align="left" valign="top">Yes</td><td align="left" valign="top">Yes</td><td align="left" valign="top">665 kg</td></tr><tr><td align="left" valign="top" colspan="5">Large-scale training (512 &#x00D7; A100, 24 d)</td></tr><tr><td align="left" valign="top"><named-content content-type="indent">&#x00A0;&#x00A0;&#x00A0;&#x00A0;</named-content>CodeCarbon</td><td align="left" valign="top">52,000</td><td align="left" valign="top">No</td><td align="left" valign="top">No</td><td align="left" valign="top">19.8 t</td></tr><tr><td align="left" valign="top"><named-content content-type="indent">&#x00A0;&#x00A0;&#x00A0;&#x00A0;</named-content>Green Algorithms</td><td align="left" valign="top">55,000</td><td align="left" valign="top">Yes</td><td align="left" valign="top">No</td><td align="left" valign="top">22.5 t</td></tr><tr><td align="left" valign="top"><named-content content-type="indent">&#x00A0;&#x00A0;&#x00A0;&#x00A0;</named-content>Proposed calculator</td><td align="left" valign="top">68,000</td><td align="left" valign="top">Yes</td><td align="left" valign="top">Yes</td><td align="left" valign="top">26.8 t</td></tr></tbody></table><table-wrap-foot><fn id="table3fn1"><p><sup>a</sup>Energy estimates are not uniform outputs across tools. Values reflect each tool&#x2019;s power, utilization, and system-boundary assumptions. CodeCarbon primarily reports estimated IT energy, whereas facility overhead may be incorporated through PUE by Green Algorithms and the proposed calculator. In the proposed calculator&#x2019;s large-scale scenario, estimated IT energy was approximately 52,300 kWh and facility energy after application of PUE = 1.3 was approximately 68,000 kWh. Differences in total CO2e also reflect grid-emission factors, cooling treatment, and whether amortized hardware life-cycle emissions are included.</p></fn><fn id="table3fn2"><p><sup>b</sup>PUE: power usage effectiveness.</p></fn><fn id="table3fn3"><p><sup>c</sup>LCA: life cycle assessment.</p></fn><fn id="table3fn4"><p><sup>d</sup>CO<sub>2</sub>e: carbon dioxide equivalent.</p></fn></table-wrap-foot></table-wrap></sec></sec><sec id="s4" sec-type="discussion"><title>Discussion</title><sec id="s4-1"><title>Principal Findings</title><p>This study introduced a life cycle&#x2013;informed calculator and reporting framework for AI environmental disclosure. The main finding is that AI footprint estimates change substantially when the reporting boundary expands from operational electricity alone to include PUE, WUE, hardware life cycle allocation, and regional grid intensity. Across the 3 scenarios, the calculator produced interpretable estimates that showed how software optimization, carbon-aware scheduling, and facility selection can reduce emissions while also revealing cases where carbon reductions may increase water demand. These findings support the need for transparent, parameter-level reporting rather than a single, unqualified emissions value.</p><p>Environmental transparency should, therefore, be considered a fundamental element of research integrity. Just as ethical statements and data availability sections have become standard components of scientific reporting, so too should <italic>environmental impact disclosures</italic> become routine in computational publications. The inclusion of such information allows peers, reviewers, and the broader public to evaluate research not only by its accuracy and novelty but also by its ecological responsibility [<xref ref-type="bibr" rid="ref2">2</xref>,<xref ref-type="bibr" rid="ref5">5</xref>,<xref ref-type="bibr" rid="ref8">8</xref>].</p><p>To operationalize this vision, we propose that AI journals, conferences, and institutional repositories adopt a dedicated &#x201C;Environmental Impact Statement&#x201D; or &#x201C;Carbon Footprint Reporting&#x201D; section for all computational manuscripts. The AI Environmental Footprint Calculator [<xref ref-type="bibr" rid="ref12">12</xref>] enables researchers to automatically generate this information, reporting total energy use (kWh), emissions (CO<sub>2</sub>e), grid region, and key infrastructure parameters in a consistent, auditable format [<xref ref-type="bibr" rid="ref2">2</xref>,<xref ref-type="bibr" rid="ref8">8</xref>].</p><p>Integrating such disclosures will not only improve scientific reproducibility but also catalyze the cultural shift toward sustainable computing. As the 2025 <italic>Energy and AI</italic> report by the IEA notes, transparency is the essential first step toward measurable emissions reduction and informed infrastructure planning [<xref ref-type="bibr" rid="ref7">7</xref>]. With clear reporting tools and standardized metrics in place, the research community can collectively work toward a lower-carbon future for computational science.</p><p>To translate these principles into practical action, the following subsection outlines specific policy and practice recommendations for institutions, publishers, and researchers.</p></sec><sec id="s4-2"><title>Policy and Practice Framework</title><p>Building on the principles of transparency and accountability outlined above, this subsection translates these commitments into actionable recommendations for researchers, institutions, and publishers.</p><list list-type="bullet"><list-item><p>Requesting transparent and standardized reporting in publications: Every AI research article should include a concise, standardized environmental reporting subsection that details emissions from training, inference, hardware production, and facility operations. This subsection can be automatically generated through tools such as the AI Environmental Footprint Calculator [<xref ref-type="bibr" rid="ref12">12</xref>], which outputs structured text and bibliographic references suitable for insertion into the methods section [<xref ref-type="bibr" rid="ref2">2</xref>,<xref ref-type="bibr" rid="ref8">8</xref>]. Including such a disclosure normalizes sustainability reporting and facilitates direct comparison across studies.</p></list-item><list-item><p>Adopting a community-wide environmental label: To complement numerical disclosure, journals and conferences should encourage the use of an AI Environmental Label, a simple A-E grade derived from total CO<sub>2</sub>e per 10&#x2079; FLOPs (training) and per 1000 tokens (inference).</p></list-item><list-item><p>Minimum dataset for reproducibility: For each computational experiment, authors should report at least the following parameters (adhering to this dataset ensures reproducibility and enables downstream meta-analyses of AI&#x2019;s environmental trends):</p><list list-type="bullet"><list-item><p>Hardware: GPU or Tensor Processing Unit (Google) model and count, memory size, and hardware LCA reference source or version [<xref ref-type="bibr" rid="ref1">1</xref>,<xref ref-type="bibr" rid="ref6">6</xref>,<xref ref-type="bibr" rid="ref9">9</xref>]</p></list-item><list-item><p>Energy: Total kWh, measured or estimated PUE, and WUE if available [<xref ref-type="bibr" rid="ref4">4</xref>,<xref ref-type="bibr" rid="ref7">7</xref>]</p></list-item><list-item><p>Grid: Geographic region and either hourly grid-EFs or an averaged intensity with a date range [<xref ref-type="bibr" rid="ref7">7</xref>]</p></list-item><list-item><p>Workload: Total FLOPs or token count, batch and sequence length, and mean utilization rate [<xref ref-type="bibr" rid="ref2">2</xref>,<xref ref-type="bibr" rid="ref8">8</xref>]</p></list-item><list-item><p>Inference disclosure: Per-1000-token or per-request footprint using standardized formulas [<xref ref-type="bibr" rid="ref3">3</xref>]</p></list-item></list></list-item><list-item><p>Positive-sum efficiency guidance: Environmental transparency should not be viewed as a constraint but as an opportunity for efficiency gains. Algorithmic improvements, such as mixed-precision training, model pruning, or distillation, can simultaneously reduce cost and emissions. Similarly, carbon-aware scheduling and renewable-backed compute supply can minimize CO<sub>2</sub>e without sacrificing performance [<xref ref-type="bibr" rid="ref2">2</xref>,<xref ref-type="bibr" rid="ref5">5</xref>,<xref ref-type="bibr" rid="ref7">7</xref>]. Embedding these practices into research culture will allow sustainable computing to advance in parallel with scientific innovation.</p></list-item></list><p>Together, these recommendations provide a practical roadmap for integrating environmental accountability into computationally intensive AI research. By institutionalizing disclosure, labeling, and reproducibility standards, the community can align methodological transparency with planetary sustainability. Importantly, this framework underscores that environmental assessment must become a routine and integral component of evaluating any AI project [<xref ref-type="bibr" rid="ref1">1</xref>-<xref ref-type="bibr" rid="ref9">9</xref>].</p></sec><sec id="s4-3"><title>Summary of Contributions</title><p>This work introduces the AI Environmental Footprint Calculator. This fully transparent, browser-based tool integrates 4 core components of environmental accounting for AI workloads: (1) operational energy use derived from hardware power measurements and utilization, (2) life cycle&#x2013;based embodied emissions of accelerators, (3) cooling and facility overheads via configurable PUE and WUE parameters, and (4) inference-level granularity expressed as CO<sub>2</sub>e per token and per 1000-token output. The calculator additionally incorporates live grid carbon intensity data from the Electricity Maps API, a standardized A-E environmental efficiency label, and household energy-equivalent comparisons to support interdisciplinary communication. These elements collectively address ongoing calls in the 2025 literature for transparent, reproducible, and accessible AI environmental reporting frameworks [<xref ref-type="bibr" rid="ref1">1</xref>-<xref ref-type="bibr" rid="ref9">9</xref>].</p></sec><sec id="s4-4"><title>Comparison With Existing Tools and Methodologies</title><p>While prior tools, such as CodeCarbon, ML CO<sub>2</sub> impact, and Green Algorithms, have advanced operational carbon tracking for ML workloads, they differ from the present tool in several respects (<xref ref-type="table" rid="table4">Table 4</xref>). CodeCarbon emphasizes integration with Python workflows and local logging but provides limited inference-level granularity and does not incorporate hardware-embodied emissions by default. Green Algorithms provides life-cycle components and region-based performance factors but does not expose the underlying equations directly through the interface. The present calculator complements these efforts by prioritizing transparency, allowing users to inspect and modify every assumption, including hardware lifetime, embodied emissions, PUE and WUE factors, and grid intensity, directly in the interface without requiring installation or coding. In addition, the A-E label introduced here offers an interpretable ranking system explicitly tied to CO<sub>2</sub>e per 1000 generated tokens, a level of granularity not commonly supported in existing tools. Together, these features position the calculator as a methodological bridge between simple footprint estimators and complete LCA approaches. This study is methodological in nature and does not involve hypothesis testing or statistical inference using <italic>P</italic> values.</p><table-wrap id="t4" position="float"><label>Table 4.</label><caption><p>Comparison of main tools for estimating AI carbon footprints<sup><xref ref-type="table-fn" rid="table4fn1">a</xref></sup>.</p></caption><table id="table4" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Tool or model</td><td align="left" valign="bottom">Type and platform</td><td align="left" valign="bottom">Input requirements</td><td align="left" valign="bottom">Outputs</td><td align="left" valign="bottom">Training vs inference coverage<sup><xref ref-type="table-fn" rid="table4fn2">b</xref></sup></td><td align="left" valign="bottom">Ease of use and target user</td><td align="left" valign="bottom">Main limitations<sup><xref ref-type="table-fn" rid="table4fn3">c</xref></sup></td></tr></thead><tbody><tr><td align="left" valign="top">CodeCarbon</td><td align="left" valign="top">Python library (open source)</td><td align="left" valign="top">Device type, power draw (auto), run time, region (ISO country code)</td><td align="left" valign="top">CO<sub>2</sub>e (kg), energy (kWh)</td><td align="left" valign="top">Primarily training (can log inference with wrappers)</td><td align="left" valign="top"><list list-type="bullet"><list-item><p>Moderate ease of use; intended for ML<sup><xref ref-type="table-fn" rid="table4fn4">d</xref></sup> practitioners and researchers with Python experience.</p></list-item><list-item><p>Requires installation and integration into training scripts but provides automated logging once configured.</p></list-item></list></td><td align="left" valign="top">Uses static grid factors; ignores embodied hardware and cooling effects [<xref ref-type="bibr" rid="ref13">13</xref>]</td></tr><tr><td align="left" valign="top">ML CO<sub>2</sub> impact</td><td align="left" valign="top">Web calculator</td><td align="left" valign="top">FLOPs<sup><xref ref-type="table-fn" rid="table4fn5">e</xref></sup> or GPU<sup><xref ref-type="table-fn" rid="table4fn6">f</xref></sup> hours, region, PUE<sup><xref ref-type="table-fn" rid="table4fn7">g</xref></sup></td><td align="left" valign="top">CO<sub>2</sub>e (kg), equivalent cars or flights</td><td align="left" valign="top">Training only</td><td align="left" valign="top"><list list-type="bullet"><list-item><p>High ease of use; intended for nontechnical researchers and authors.</p></list-item><list-item><p>Fully browser-based with manual input fields, requiring no installation or programming knowledge.</p></list-item></list></td><td align="left" valign="top">Manual inputs only; no live metering; training focus [<xref ref-type="bibr" rid="ref14">14</xref>]</td></tr><tr><td align="left" valign="top">Carbon tracker</td><td align="left" valign="top">Python and CLI<sup><xref ref-type="table-fn" rid="table4fn8">h</xref></sup></td><td align="left" valign="top">Power sensor (nvidia-smi), job duration, grid intensity API</td><td align="left" valign="top">Energy (kWh), CO<sub>2</sub>e (kg) over time</td><td align="left" valign="top">Training (predictive during run)</td><td align="left" valign="top"><list list-type="bullet"><list-item><p>Low-to-moderate ease of use; intended for system administrators and advanced ML users.</p></list-item><list-item><p>Requires Linux-based servers, GPU power monitoring, and command-line execution, limiting accessibility for nonexpert users.</p></list-item></list></td><td align="left" valign="top">Does not track inference or hardware manufacturing [<xref ref-type="bibr" rid="ref15">15</xref>]</td></tr><tr><td align="left" valign="top">Experiment impact tracker</td><td align="left" valign="top">Python library (open source)</td><td align="left" valign="top">GPU and CPU<sup><xref ref-type="table-fn" rid="table4fn9">i</xref></sup> utilization, runtime logs</td><td align="left" valign="top">Energy (kWh), CO<sub>2</sub>e (kg)</td><td align="left" valign="top">Training</td><td align="left" valign="top"><list list-type="bullet"><list-item><p>Low ease of use; intended for advanced research teams with experiment-management infrastructure.</p></list-item><list-item><p>Requires detailed runtime logging and integration into experimental pipelines, making setup complex for small laboratories.</p></list-item></list></td><td align="left" valign="top">Complex setup, local power profiling required [<xref ref-type="bibr" rid="ref15">15</xref>]</td></tr><tr><td align="left" valign="top">Green Algorithms calculator</td><td align="left" valign="top">Web app+spreadsheet model</td><td align="left" valign="top">Hardware type, runtime, memory use, data-center PUE</td><td align="left" valign="top">Energy (kWh), CO<sub>2</sub>e (kg)</td><td align="left" valign="top">General scientific computing (training and inference both possible)</td><td align="left" valign="top"><list list-type="bullet"><list-item><p>High ease of use; intended for general scientific researchers, including non-ML users.</p></list-item><list-item><p>Graphical web interface with simplified inputs enables use without programming or system-level access.</p></list-item></list></td><td align="left" valign="top">Based on generic emission factors, no GPU-specific calibration [<xref ref-type="bibr" rid="ref16">16</xref>]</td></tr></tbody></table><table-wrap-foot><fn id="table4fn1"><p><sup>a</sup>Each tool converts compute power and runtime into carbon dioxide equivalent (CO<sub>2</sub>e) using regional grid factors.</p></fn><fn id="table4fn2"><p><sup>b</sup>Phases of the machine learning workflow supported by the tool, including training, inference, or both.</p></fn><fn id="table4fn3"><p><sup>c</sup>Low granularity, missing embodied impacts, and static grid assumptions.</p></fn><fn id="table4fn4"><p><sup>d</sup>ML: machine learning.</p></fn><fn id="table4fn5"><p><sup>e</sup>FLOPs: floating-point operations.</p></fn><fn id="table4fn6"><p><sup>f</sup>GPU: graphics processing unit.</p></fn><fn id="table4fn7"><p><sup>g</sup>PUE: power usage effectiveness.</p></fn><fn id="table4fn8"><p><sup>h</sup>CLI: command-line interface.</p></fn><fn id="table4fn9"><p><sup>i</sup>CPU: central processing unit.</p></fn></table-wrap-foot></table-wrap></sec><sec id="s4-5"><title>Interpretation of Findings and Practical Implications</title><p>Across the 3 validation scenarios, the calculator consistently demonstrates how environmental impacts scale nonlinearly with model size, token throughput, and cluster configuration. Even modest inference workloads can accumulate operational emissions when multiplied across large user bases or when operated in carbon-intensive regions. Conversely, workloads executed in low-carbon grids (eg, Quebec) with efficient cooling infrastructures exhibit markedly reduced footprints, underscoring the opportunity for carbon-aware scheduling and region selection. The A-E label further contextualizes these impacts by providing a simple benchmark for comparing workloads across models, research groups, and deployment environments. For nonexpert stakeholders, including clinicians, policymakers, and general audiences, the household-equivalent comparisons offer a relatable way to interpret energy use that can support informed discussions about AI deployment, sustainability trade-offs, and responsible scaling.</p></sec><sec id="s4-6"><title>Limitations, Equity, and Scope</title><p>Despite its strengths, the calculator has several limitations. First, embodied emissions values for accelerators remain uncertain because public LCAs and manufacturer disclosures vary in scope, allocation methods, and assumed lifetimes. Second, the Electricity Maps and similar APIs provide high-quality data for many regions, but coverage remains incomplete, requiring some users to rely on static averages. Third, training workloads involving distributed optimization, communication overheads, and dynamic scheduling can deviate from simplified FLOP- and runtime-based estimates. Fourth, the calculator does not yet ingest cloud billing records, cluster logs, or Python runtime traces automatically. Finally, environmental labels must be interpreted carefully across regions. Researchers in countries with carbon-intensive grids may receive lower labels for reasons outside their direct control, which could create unfairness if labels were used as punitive evaluation metrics. We therefore recommend that labels be reported with regional context and used to encourage transparent mitigation strategies, not to penalize researchers for infrastructure constraints. Equity-oriented interpretation should distinguish controllable choices, such as model efficiency and scheduling, from structural constraints such as national grid mix and access to low-carbon compute.</p></sec><sec id="s4-7"><title>Future Directions</title><p>Future development will focus on expanding interoperability with research workflows via optional Python and command-line interface wrappers, batch import of Slurm Workload Manager and Kubernetes logs, and automated integration with ML frameworks such as PyTorch Lightning and Hugging Face Trainer. Extending API support to additional sources (eg, IEA datasets, regional utility providers) will improve the robustness of real-time grid intensity estimation. Enhancing the embodied-emission module with more granular manufacturing and supply-chain data, including memory-specific and interconnect components, would further strengthen life-cycle accuracy. Additionally, aligning the A-E environmental label with wider community standards, or integrating it into a broader disclosure framework, may facilitate adoption in peer-reviewed publications and regulatory contexts. As transparency expectations in AI research continue to increase, lightweight tools such as the one presented here can play a central role in fostering accountable, environmentally aware development and deployment of AI systems.</p></sec><sec id="s4-8"><title>Conclusions</title><p>This work introduced a comprehensive, life cycle&#x2013;aware framework for quantifying and reporting the environmental footprint of AI systems. Through the development of the AI Environmental Footprint Calculator, we provided a transparent, user-friendly, and scientifically rigorous tool that integrates hardware life cycle emissions, operational energy, cooling overhead, and inference costs into a single, reproducible assessment model.</p><p>Validation across 3 representative scenarios&#x2014;a small laboratory fine-tuning task, a midsized academic cluster, and a large-scale industrial training cycle&#x2014;demonstrates the calculator&#x2019;s flexibility and practical value (<xref ref-type="supplementary-material" rid="app2">Multimedia Appendix 2</xref>). These examples confirmed that algorithmic optimization, carbon-aware scheduling, and renewable-backed infrastructure can collectively achieve meaningful emission reductions without constraining research output [<xref ref-type="bibr" rid="ref2">2</xref>,<xref ref-type="bibr" rid="ref4">4</xref>,<xref ref-type="bibr" rid="ref5">5</xref>,<xref ref-type="bibr" rid="ref7">7</xref>].</p><p>The policy recommendations outlined in the <italic>Principal Findings</italic> section establish a clear path forward: integrating standardized environmental reporting into every AI publication, adopting a universal labeling framework, and defining a reproducibility dataset that includes hardware, energy, grid, and workload parameters. Together, these steps can institutionalize environmental accountability in computational research.</p><p>Looking ahead, the next phase of this work will involve expanding the open-access hardware LCA registry, linking the calculator to cloud-platform APIs for automated data retrieval, and collaborating with publishers and funding agencies to pilot environmental reporting requirements. Embedding these practices across the research life cycle will ensure that the progress of AI remains aligned with the broader goal of planetary sustainability.</p></sec></sec></body><back><ack><p>AI-based tools were used for language editing and clarity improvement of the manuscript. The authors reviewed, edited, and took full responsibility for the content of the final version.</p></ack><notes><sec><title>Funding</title><p>The authors declared no financial support was received for this work.</p></sec></notes><fn-group><fn fn-type="conflict"><p>None declared.</p></fn></fn-group><glossary><title>Abbreviations</title><def-list><def-item><term id="abb1">CO<sub>2</sub>e</term><def><p>carbon dioxide equivalent</p></def></def-item><def-item><term id="abb2">EF</term><def><p>emission factor</p></def></def-item><def-item><term id="abb3">FAS</term><def><p>Federation of American Scientists</p></def></def-item><def-item><term id="abb4">FLOP</term><def><p>floating-point operation</p></def></def-item><def-item><term id="abb5">GPU</term><def><p>graphics processing unit</p></def></def-item><def-item><term id="abb6">IEA</term><def><p>International Energy Agency</p></def></def-item><def-item><term id="abb7">LCA</term><def><p>life cycle assessment</p></def></def-item><def-item><term id="abb8">ML</term><def><p>machine learning</p></def></def-item><def-item><term id="abb9">PUE</term><def><p>power usage effectiveness</p></def></def-item><def-item><term id="abb10">WUE</term><def><p>water usage effectiveness</p></def></def-item></def-list></glossary><ref-list><title>References</title><ref id="ref1"><label>1</label><nlm-citation citation-type="other"><person-group person-group-type="author"><name name-style="western"><surname>Schneider</surname><given-names>I</given-names> </name><name name-style="western"><surname>Xu</surname><given-names>H</given-names> </name><name name-style="western"><surname>Benecke</surname><given-names>S</given-names> </name><etal/></person-group><article-title>Life-cycle emissions of AI hardware: a cradle-to-grave approach and generational trends</article-title><source>arXiv</source><comment>Preprint posted online on  Feb 1, 2025</comment><pub-id pub-id-type="doi">10.48550/arXiv.2502.01671</pub-id></nlm-citation></ref><ref id="ref2"><label>2</label><nlm-citation citation-type="confproc"><person-group person-group-type="author"><name name-style="western"><surname>Morrison</surname><given-names>J</given-names> </name><name name-style="western"><surname>Na</surname><given-names>C</given-names> </name><name name-style="western"><surname>Fernandez</surname><given-names>J</given-names> </name><name name-style="western"><surname>Dettmers</surname><given-names>T</given-names> </name><name name-style="western"><surname>Strubell</surname><given-names>E</given-names> </name><name name-style="western"><surname>Dodge</surname><given-names>J</given-names> </name></person-group><article-title>Holistically evaluating the environmental impact of creating language models</article-title><access-date>2026-06-30</access-date><conf-name>International Conference on Learning Representations 2025 (ICLR 2025)</conf-name><conf-date>Apr 24-28, 2025</conf-date><comment><ext-link ext-link-type="uri" xlink:href="https://openreview.net/pdf?id=04qx93Viwj">https://openreview.net/pdf?id=04qx93Viwj</ext-link></comment></nlm-citation></ref><ref id="ref3"><label>3</label><nlm-citation citation-type="other"><person-group person-group-type="author"><name name-style="western"><surname>Jegham</surname><given-names>N</given-names> </name><name name-style="western"><surname>Abdelatti</surname><given-names>M</given-names> </name><name name-style="western"><surname>Koh</surname><given-names>CY</given-names> </name><name name-style="western"><surname>Elmoubarki</surname><given-names>L</given-names> </name><name name-style="western"><surname>Hendawi</surname><given-names>A</given-names> </name></person-group><article-title>How hungry is AI? benchmarking energy, water, and carbon footprint of LLM inference</article-title><source>arXiv</source><comment>Preprint posted online on  May 14, 2025</comment><pub-id pub-id-type="doi">10.48550/arXiv.2505.09598</pub-id></nlm-citation></ref><ref id="ref4"><label>4</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Alissa</surname><given-names>H</given-names> </name><name name-style="western"><surname>Nick</surname><given-names>T</given-names> </name><name name-style="western"><surname>Raniwala</surname><given-names>A</given-names> </name><etal/></person-group><article-title>Using life cycle assessment to drive innovation for sustainable cool clouds</article-title><source>Nature</source><year>2025</year><month>05</month><volume>641</volume><issue>8062</issue><fpage>331</fpage><lpage>338</lpage><pub-id pub-id-type="doi">10.1038/s41586-025-08832-3</pub-id><pub-id pub-id-type="medline">40307558</pub-id></nlm-citation></ref><ref id="ref5"><label>5</label><nlm-citation citation-type="other"><person-group person-group-type="author"><name name-style="western"><surname>Desroches</surname><given-names>C</given-names> </name><name name-style="western"><surname>Chauvin</surname><given-names>M</given-names> </name><name name-style="western"><surname>Ladan</surname><given-names>L</given-names> </name><name name-style="western"><surname>Vateau</surname><given-names>C</given-names> </name><name name-style="western"><surname>Gosset</surname><given-names>S</given-names> </name><name name-style="western"><surname>Cordier</surname><given-names>P</given-names> </name></person-group><article-title>Exploring the sustainable scaling of AI dilemma: a projective study of corporations&#x2019; AI environmental impacts</article-title><source>arXiv</source><comment>Preprint posted online on  Jan 24, 2025</comment><pub-id pub-id-type="doi">10.48550/arXiv.2501.14334</pub-id></nlm-citation></ref><ref id="ref6"><label>6</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Falk</surname><given-names>S</given-names> </name><name name-style="western"><surname>Ekchajzer</surname><given-names>D</given-names> </name><name name-style="western"><surname>Pirson</surname><given-names>T</given-names> </name><etal/></person-group><article-title>More than carbon: cradle-to-grave environmental impacts of GenAI training on the Nvidia A100 GPU</article-title><source>Environ Impact Assess Rev</source><year>2026</year><month>09</month><volume>121</volume><fpage>108525</fpage><pub-id pub-id-type="doi">10.1016/j.eiar.2026.108525</pub-id></nlm-citation></ref><ref id="ref7"><label>7</label><nlm-citation citation-type="report"><article-title>Energy and AI</article-title><year>2025</year><access-date>2026-06-30</access-date><publisher-name>International Energy Agency (IEA)</publisher-name><comment><ext-link ext-link-type="uri" xlink:href="https://iea.blob.core.windows.net/assets/de9dea13-b07d-42c5-a398-d1b3ae17d866/EnergyandAI.pdf">https://iea.blob.core.windows.net/assets/de9dea13-b07d-42c5-a398-d1b3ae17d866/EnergyandAI.pdf</ext-link></comment></nlm-citation></ref><ref id="ref8"><label>8</label><nlm-citation citation-type="web"><person-group person-group-type="author"><name name-style="western"><surname>Jhaveri</surname><given-names>M</given-names></name><name name-style="western"><surname>Palat</surname><given-names>V</given-names> </name></person-group><article-title>Measuring and standardizing AI&#x2019;s energy and environmental footprint to accurately access impacts</article-title><source>Federation of American Scientists</source><year>2025</year><month>06</month><day>27</day><access-date>2026-07-30</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://fas.org/publication/measuring-and-standardizing-ais-energy-footprint/">https://fas.org/publication/measuring-and-standardizing-ais-energy-footprint/</ext-link></comment></nlm-citation></ref><ref id="ref9"><label>9</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Plociennik</surname><given-names>C</given-names> </name><name name-style="western"><surname>Watjanatepin</surname><given-names>P</given-names> </name><name name-style="western"><surname>Acker</surname><given-names>KV</given-names> </name><name name-style="western"><surname>Ruskowski</surname><given-names>M</given-names> </name></person-group><article-title>Life cycle assessment of artificial intelligence applications: research gaps and opportunities</article-title><source>Procedia CIRP</source><year>2025</year><volume>135</volume><fpage>924</fpage><lpage>929</lpage><pub-id pub-id-type="doi">10.1016/j.procir.2025.01.079</pub-id></nlm-citation></ref><ref id="ref10"><label>10</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Bux</surname><given-names>C</given-names> </name><name name-style="western"><surname>Rana</surname><given-names>RL</given-names> </name><name name-style="western"><surname>Lombardi</surname><given-names>M</given-names> </name><name name-style="western"><surname>Giungato</surname><given-names>P</given-names> </name><name name-style="western"><surname>Tricase</surname><given-names>C</given-names> </name></person-group><article-title>A critical analysis of global warming potential of data centers in the digital era</article-title><source>Int J Life Cycle Assess</source><year>2025</year><month>11</month><volume>30</volume><issue>11</issue><fpage>2390</fpage><lpage>2402</lpage><pub-id pub-id-type="doi">10.1007/s11367-024-02419-2</pub-id></nlm-citation></ref><ref id="ref11"><label>11</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Siddik</surname><given-names>MAB</given-names> </name><name name-style="western"><surname>Shehabi</surname><given-names>A</given-names> </name><name name-style="western"><surname>Marston</surname><given-names>L</given-names> </name></person-group><article-title>The environmental footprint of data centers in the United States</article-title><source>Environ Res Lett</source><year>2021</year><month>06</month><day>1</day><volume>16</volume><issue>6</issue><fpage>064017</fpage><pub-id pub-id-type="doi">10.1088/1748-9326/abfba1</pub-id></nlm-citation></ref><ref id="ref12"><label>12</label><nlm-citation citation-type="web"><article-title>AI Environmental Footprint Calculator</article-title><source>Kaveh Mozafari</source><access-date>2026-06-30</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://www.kavehmozafari.com/calc">https://www.kavehmozafari.com/calc</ext-link></comment></nlm-citation></ref><ref id="ref13"><label>13</label><nlm-citation citation-type="other"><person-group person-group-type="author"><name name-style="western"><surname>Anthony</surname><given-names>LFW</given-names> </name><name name-style="western"><surname>Kanding</surname><given-names>B</given-names> </name><name name-style="western"><surname>Selvan</surname><given-names>R</given-names> </name></person-group><article-title>Carbontracker: tracking and predicting the carbon footprint of training deep learning models</article-title><source>arXiv</source><comment>Preprint posted online on  Jul 6, 2020</comment><pub-id pub-id-type="doi">10.48550/arXiv.2007.03051</pub-id></nlm-citation></ref><ref id="ref14"><label>14</label><nlm-citation citation-type="other"><person-group person-group-type="author"><name name-style="western"><surname>Lacoste</surname><given-names>A</given-names> </name><name name-style="western"><surname>Luccioni</surname><given-names>A</given-names> </name><name name-style="western"><surname>Schmidt</surname><given-names>V</given-names> </name><name name-style="western"><surname>Dandres</surname><given-names>T</given-names> </name></person-group><article-title>Quantifying the carbon emissions of machine learning</article-title><source>arXiv</source><comment>Preprint posted online on  Oct 21, 2019</comment><pub-id pub-id-type="doi">10.48550/arXiv.1910.09700</pub-id></nlm-citation></ref><ref id="ref15"><label>15</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Henderson</surname><given-names>P</given-names> </name><name name-style="western"><surname>Hu</surname><given-names>J</given-names> </name><name name-style="western"><surname>Romoff</surname><given-names>J</given-names> </name><name name-style="western"><surname>Brunskill</surname><given-names>E</given-names> </name><name name-style="western"><surname>Jurafsky</surname><given-names>D</given-names> </name><name name-style="western"><surname>Pineau</surname><given-names>J</given-names> </name></person-group><article-title>Towards the systematic reporting of the energy and carbon footprints of machine learning</article-title><source>J Mach Learn Res</source><year>2020</year><access-date>2026-06-30</access-date><volume>21</volume><fpage>1</fpage><lpage>43</lpage><comment><ext-link ext-link-type="uri" xlink:href="https://www.jmlr.org/papers/volume21/20-312/20-312.pdf">https://www.jmlr.org/papers/volume21/20-312/20-312.pdf</ext-link></comment></nlm-citation></ref><ref id="ref16"><label>16</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Lannelongue</surname><given-names>L</given-names> </name><name name-style="western"><surname>Grealey</surname><given-names>J</given-names> </name><name name-style="western"><surname>Inouye</surname><given-names>M</given-names> </name></person-group><article-title>Green algorithms: quantifying the carbon footprint of computation</article-title><source>Adv Sci (Weinh)</source><year>2021</year><month>06</month><volume>8</volume><issue>12</issue><fpage>2100707</fpage><pub-id pub-id-type="doi">10.1002/advs.202100707</pub-id><pub-id pub-id-type="medline">34194954</pub-id></nlm-citation></ref></ref-list><app-group><supplementary-material id="app1"><label>Multimedia Appendix 1</label><p>Methods, uncertainty and sensitivity analysis, and ethics notes.</p><media xlink:href="ai_v5i1e90770_app1.docx" xlink:title="DOCX File, 15 KB"/></supplementary-material><supplementary-material id="app2"><label>Multimedia Appendix 2</label><p>Supplementary uncertainty analysis and methodological details for the AI Environmental Footprint Calculator, including Figures S1 and S2, the amortization policy, water and thermal trade-offs, and the mathematical framework.</p><media xlink:href="ai_v5i1e90770_app2.docx" xlink:title="DOCX File, 97 KB"/></supplementary-material></app-group></back></article>