Artificial intelligence is increasingly sold as a clean, weightless technology: code in the cloud, intelligence on demand, value delivered without the mess of factories or the visible footprint of heavy industry. But a growing chorus of readers and researchers is challenging that story. In a debate that has moved from specialist circles into mainstream commentary, the question is no longer whether AI has an environmental impact, but what the “real cost” actually includes—and why so much of it remains difficult to see, compare and verify.
The discussion now centres on two linked demands. First, that the energy use and emissions associated with AI—especially those tied to data centres—are measured with more rigour and reported with more consistency. Second, that transparency is treated not as a public-relations add-on, but as a prerequisite for accountability across the AI supply chain. If AI’s costs are distributed across hardware manufacturing, electricity generation, cooling systems, model training and inference, and even the software layers that determine how efficiently workloads run, then simply quoting a single figure for “AI emissions” will never be enough. Readers want a clearer map of where the costs show up, who pays them, and how those costs change over time.
What makes the debate feel urgent is that AI demand is not static. It is scaling in multiple directions at once: larger models, more frequent retraining, and—perhaps most visibly—inference at massive scale as chatbots, assistants and AI features become embedded in everyday products. Training is often the headline-grabber because it can involve large compute runs. Yet inference—the ongoing computation required to answer queries—can dominate total energy use depending on how widely a system is deployed and how long it stays in production. That shift matters because it changes what “cost” means. A one-off training run may be measurable as a discrete event; a service that runs continuously turns energy use into a recurring bill, one that can grow quietly as user numbers rise.
At the centre of the environmental concern is the data centre. Data centres are not just buildings full of servers; they are complex energy systems. Electricity powers compute, networking and storage, while cooling systems remove heat generated by hardware operating at high utilisation. The efficiency of these facilities varies widely depending on design choices, climate, workload patterns and the carbon intensity of the local electricity grid. Even when two data centres consume the same amount of power, their emissions can differ substantially if one draws electricity from cleaner sources than the other.
This is where the transparency debate becomes more than a moral argument. Without consistent reporting, it is hard to know whether claims about “green AI” reflect genuine reductions in emissions or merely shifts in accounting. Some companies point to renewable energy procurement, such as purchasing renewable energy credits or entering power purchase agreements. These can reduce net emissions in certain accounting frameworks, but they do not automatically guarantee that the electricity used at the moment of computation is low-carbon. Readers are asking for clarity on what exactly is being claimed: is it about matching consumption with renewables over time, about physical delivery of clean power, or about offsets? And if offsets are involved, what quality standards apply?
The demand for transparency also extends to the operational details that determine efficiency. Model training and inference are not “one size fits all.” The same model architecture can be run with different optimisation strategies, batch sizes, quantisation levels, caching approaches and scheduling policies. These choices affect how much compute is required per output token, how effectively hardware is utilised, and how much waste occurs when systems are underloaded or poorly matched to demand. In other words, the environmental footprint is not only a function of the model; it is also a function of engineering discipline.
Yet many of the metrics that would allow outsiders to evaluate these differences are not routinely disclosed. Companies may publish aggregate performance benchmarks, but rarely provide enough information to estimate energy use per training run or per unit of inference. Even when disclosures exist, they can be difficult to compare because they use different assumptions: different estimates of energy per GPU hour, different methods for converting electricity consumption into emissions, and different boundaries for what counts as “AI-related.” Does the calculation include only the servers, or also the cooling infrastructure, networking and storage? Does it include the embodied emissions of manufacturing hardware, or only operational emissions during use? Does it account for the electricity used during idle periods, or only during active computation?
Readers are pushing for a more standardised approach because they recognise a basic problem: if every actor defines “cost” differently, then transparency becomes performative. A number without context can mislead. A claim without methodology can be impossible to audit. And a comparison without shared boundaries can turn into marketing rather than measurement.
One unique angle emerging in the debate is the idea that “real cost” should be treated like a product attribute, not a vague externality. In consumer markets, costs are often broken down into components—materials, labour, logistics, packaging—so buyers can understand what they are paying for. AI’s environmental costs, by contrast, are frequently bundled into a single narrative: either “it’s too complex to measure” or “we’re working on sustainability.” Readers want something closer to a bill of materials for computation: what went into the model, what it took to train it, what it takes to run it, and what trade-offs were made.
That framing also highlights another issue: accountability across the supply chain. Data centres rely on semiconductor manufacturers, server vendors, power utilities, cooling equipment suppliers and cloud operators. Each layer influences energy efficiency and emissions. A company that deploys a model may not control the carbon intensity of the grid, but it can influence where workloads run, how they are scheduled, and whether the infrastructure is designed for high utilisation. Similarly, a model developer may not own the data centre, but it can influence how much compute is required through architecture choices and training strategies. Transparency, then, is not only about publishing numbers; it is about clarifying responsibilities.
The debate also touches on a less discussed but crucial point: the environmental impact of AI is not limited to emissions. Water use is increasingly relevant in regions where cooling relies on evaporative processes. Land use and local environmental effects can matter too, especially when data centres expand rapidly in areas with constrained resources. While the most visible metric in public discussion is carbon, readers are asking for broader disclosure that reflects the full environmental footprint. They want to know whether “sustainable” means low emissions only, or whether it includes water stewardship, waste management and local ecological impacts.
Another thread in the conversation is the tension between efficiency improvements and demand growth. Even if AI systems become more energy-efficient per task, total energy use can still rise if overall usage expands faster than efficiency gains. This is not a reason to abandon efficiency efforts; it is a reason to measure both intensity and scale. Transparency should therefore track not only how much energy is used per query or per training run, but also how quickly demand is growing and whether efficiency improvements are keeping pace.
Readers also want to understand the difference between “compute used” and “compute wasted.” In real-world systems, there is often slack: models may be overprovisioned, workloads may be rerouted during peak times, and some computations may be repeated unnecessarily due to lack of caching or suboptimal retrieval strategies. There is also the question of how much compute is spent on experimentation and iteration before a model reaches production. Training runs can multiply during development, and the environmental footprint of those iterations is rarely visible to the public. If the goal is to understand the real cost of AI, then the full lifecycle—including experimentation—should be part of the conversation.
This is where the transparency debate intersects with governance. Many readers argue that voluntary disclosures are not enough because incentives can favour selective reporting. If the market rewards impressive capabilities more than environmental performance, then companies may have little reason to publish inconvenient details. That has led to calls for stronger standards: common reporting frameworks, third-party verification, and requirements that disclosures include methodology and boundaries. The aim is not to punish innovation, but to make comparisons meaningful and to enable regulators, researchers and consumers to evaluate claims.
There is also a growing recognition that transparency should not be limited to the largest frontier labs. Smaller developers and downstream deployers can also contribute to environmental impact, especially when they build applications that run models at scale. If a chatbot is integrated into a customer service workflow, the number of daily interactions can be enormous. The environmental cost then depends on how the application is designed: whether it uses retrieval-augmented generation to reduce unnecessary generation, whether it routes requests to smaller models when appropriate, and whether it limits responses to what users actually need. In this sense, “real cost” is partly a product design question.
A particularly interesting and sometimes overlooked point is that transparency can drive better engineering. When teams know that energy and emissions metrics will be scrutinised, they have incentives to optimise. That can mean using more efficient model architectures, improving batching and scheduling, adopting quantisation and distillation techniques, and designing systems that reduce redundant computation. It can also mean measuring and reporting energy use in a way that helps internal decision-making. In other words, transparency is not only about public trust; it can be a lever for technical improvement.
Still, readers are wary of simplistic solutions. Some proposals focus on carbon offsets or renewable energy purchases as a substitute for deeper efficiency. Others suggest that the only responsible path is to slow down AI deployment. But the debate is increasingly nuanced: many commenters argue that the right approach is neither denial nor delay, but measurement plus mitigation. That means disclosing what is known, estimating what cannot yet be measured precisely, and improving the accuracy of those estimates over time. It also means setting expectations for continuous improvement rather than one-time commitments.
So what would “greater transparency” look like in practice? Readers are asking for disclosures that are specific enough to be audited and comparable enough to be useful. At minimum, they want information that connects compute to energy and emissions. That could include reporting energy use per training run and per unit of inference, along with the assumptions used to convert energy into emissions. It could include the carbon intensity of electricity used, ideally