Truace
Subscribe
30/100

Emerging evidence

ProblemPublished recordPolicyProblem Space

Full story
More
Export record JSONEmailLinkedInX

Data centres and the new strategic infrastructure governance: From cloud ESG to compute sovereignty

Truvace record
TRV-2026-2578raw data (JSON)
Version
v1Published
First published
Evidence type
Commentary, opinion, or narrative review
Sources
1 sourcePeer-reviewed
sha256
ad5a30bcd6af…check it

Data centres have moved from the background of the digital economy to the foreground of energy, climate, industrial and national-security politics. Artificial intelligence is intensifying this shift through growing demand for compute, electricity, cooling, land, hardware and critical materials. Yet governance remains largely organised around facility-level metrics that treat data centres as bounded technical assets rather than strategic infrastructure embedded in grids, water systems, supply chains, communities…

The problem

An integrative review of data centres in Chile, Australia, Querétaro, Ireland and Singapore found that no institution governs trade-offs across electricity, water and planning, and that hosting a data centre gives no assured claim on compute access.

What this doesn’t fix

The CLOUDS framework is proposed for testing rather than presented as validated.

Sources

1 on file
  1. The Extractive Industries and Societydoi:10.1016/j.exis.2026.102036
    Peer-reviewed2026-09-01

Cite this record

v1

Truvace Impact Record TRV-2026-2578, v1: “Data centres and the new strategic infrastructure governance: From cloud ESG to compute sovereignty.” Truvace, 2026-11-12. /record/TRV-2026-2578 (accessed on the day you copy it). sha256 ad5a30bcd6af416b…

Change history

1 version

Every change made to this record since it was first published, and why. Nothing has changed since it went up.

  1. Publishedv1ad5a30bcd6af…

    Certified into the record

Check this record hasn’t been altered

Check this record hasn’t been altered
How to check it yourself, without trusting this page

Download any version from /api/record/TRV-2026-2578 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.