aceModerate evidence
Published recordClimateProblem Space
More
Green artificial intelligence and its lifecycle, hardware, and measurement dimensions
- Truvace record
- TRV-2026-2630raw data (JSON)
- Version
- v1Published
- First published
- Evidence type
- Systematic review or meta-analysis
- Sources
- 1 sourcePeer-reviewed
- sha256
- 4787177b1ebe…check it
Context: Across the artificial intelligence (AI) lifecycle—from hardware provisioning and development to deployment, operation, and end-of-life— environmental burdens span energy, CO 2 e emissions, water use, and embodied/material footprints. Cloud-provider tools can improve operational visibility but remain heterogeneous and only partially cover water and value-chain effects, limiting comparability and reproducibility. Objective: Addressing these multidimensional burdens benefits from a lifecycle-oriented persp…
The problem
A review of 103 studies found AI environmental research centres on training and deployment energy, while water use, Scope 3 value-chain impacts and end-of-life hardware are thinly covered and cloud dashboards cannot be compared.
What this doesn’t fix
The authors list review coverage bias, discrepancies between estimators and meters, non-comparable provider dashboards and incomplete treatment of water and Scope 3 impacts as limits, and say the proposed constructs remain candidate tools until validated.
Sources
1 on file- Information and Software Technologydoi:10.1016/j.infsof.2026.108186
Cite this record
v1Truvace Impact Record TRV-2026-2630, v1: “Green artificial intelligence and its lifecycle, hardware, and measurement dimensions.” Truvace, 2026-11-12. /record/TRV-2026-2630 (accessed on the day you copy it). sha256 4787177b1ebe08bd…
Change history
1 versionEvery change made to this record since it was first published, and why. Nothing has changed since it went up.
Certified into the record
Check this record hasn’t been altered
How to check it yourself, without trusting this page
Download any version from /api/record/TRV-2026-2630 and hash its canonical field yourself, for example with shasum -a 256. You should get its content_hash. Each version’s text also ends with prev:and the hash of the version before it (version 1 points to 64 zeros). If anyone had changed a single character of any version after it was saved, those hashes wouldn’t line up.