On a morning in late July 2024, at a field station in the southern Cerrado, a team of ecologists was putting the finishing touches on a 340-page environmental impact assessment for a proposed transmission line corridor. The corridor would cut through 87 kilometers of savanna woodland, crossing three micro-watersheds and overlapping with the foraging territory of a known maned wolf population. The assessment had to satisfy federal regulators at IBAMA, state environmental agencies, and the funder’s safeguards team. Species inventories, hydrological modeling summaries, mitigation hierarchies, a community consultation narrative—layers upon layers. The lead ecologist, a researcher affiliated with the University of Brasília, told me she had spent roughly 60 percent of her working hours over the previous three months not on fieldwork or data analysis, but on writing. Structuring. Rephrasing. Formatting. Cross-referencing the report’s narrative sections to meet the documentation requirements of three separate regulatory frameworks.
She is not unusual. Across Brazil and the Andean region, ecologists and sustainability officers are spending an increasing share of their time producing documentation—impact assessments, monitoring summaries, compliance reports, funder updates, community communications. The volume is driven by overlapping regulatory regimes: Brazil’s CONAMA resolutions, state-level environmental licensing steps, lender safeguards like the IFC Performance Standards, and emerging extended producer responsibility and right-to-repair legislation that demands detailed lifecycle documentation for electronic equipment used in monitoring programs. Faced with this burden, many teams have turned to generative AI tools to draft narrative sections, summarize data, and produce first-draft text that they then revise. The labor savings are real. The ecological cost of those savings is not measured anywhere.
The Reporting Cycle: A Concrete Trace
Let me trace a specific reporting cycle. The Cerrado impact assessment I mentioned required the team to produce narrative summaries of bird survey results across twelve sampling points, each surveyed four times over two seasons. The raw data—species counts, detection distances, habitat annotations—lived in a spreadsheet. The narrative needed to describe survey methodology, present results in prose, flag species of conservation concern, and cross-reference habitat conditions documented in a separate vegetation report. A junior researcher on the team used a cloud-based generative AI tool to produce first-draft narrative sections for each sampling point, then revised them for accuracy and consistency. She estimated that the AI-assisted approach saved her roughly 25 hours of drafting time across the full report.
What happened each time she pressed “generate”? The request traveled from her laptop in the field station—connected via a satellite uplink to a ground station, then to a fiber backbone, then to a data center, likely in São Paulo or Virginia—to a cluster of GPUs running a large language model. The model performed inference, generating tokens through a process that draws electrical power for computation and for cooling the servers that house the GPUs. That cooling, depending on the data center’s location and design, may use evaporative systems that consume water. The generated text traveled back through the same chain to her screen. Each iteration—a rephrase, a request for a different tone, a correction—triggered another round of inference. Another set of compute cycles. Another draw on the grid.
The engineering vocabulary for what happens inside that data center is well established. As documented in Google’s Site Reliability Engineering practices, each user request triggers distributed data processing pipelines, load-balanced compute cycles, and redundancy mechanisms designed to ensure reliability—redundancy that multiplies the baseline compute footprint of any single request. The infrastructure that delivers a coherent paragraph of generated text is not a single machine processing a single query. It is a distributed system with consensus protocols, overload handling, and failover mechanisms, all of which consume additional energy beyond the inference computation itself. The Google SRE book’s chapters on data processing pipelines and load balancing in the datacenter make clear that the aggregate resource demand of serving requests at scale is non-trivial, and that the “elimination of toil” via automation—precisely what AI-assisted drafting offers—carries infrastructure costs that are real but invisible to the end user.
The Missing Accounting Layer
No environmental accounting framework I have encountered in Latin American regulatory practice captures the energy and water costs of producing environmental reports themselves. Brazil’s greenhouse gas inventory protocols, following IPCC guidelines, account for emissions from energy, agriculture, land use, and waste. Corporate carbon accounting under the GHG Protocol covers Scope 1, 2, and 3 emissions—but Scope 3 categories for purchased goods and services do not typically include the computational resources consumed in producing regulatory documentation. A consulting firm that drafts 200 environmental impact assessments per year using cloud-based generative AI tools does not report the inference energy as part of its operational footprint. The data center operator reports it, aggregated across all its customers, but the specific allocation to any particular report or any particular ecological assessment is not traced.
This matters more in Brazil than in many other contexts, because the carbon intensity of the Brazilian electricity grid is not constant. In a typical hydrological year, Brazil’s grid is largely powered by hydropower, and its carbon intensity is relatively low. But during drought years—like 2021, when reservoir levels in the Southeast and Midwest fell to historic lows—the grid’s carbon intensity spikes as thermal plants, including natural gas and coal-fired units, are dispatched to compensate for reduced hydroelectric output. A generative AI query processed in a São Paulo data center during a drought year carries a substantially higher carbon cost than the same query in a wet year. The variability is not marginal. Brazil’s grid carbon intensity has been documented to fluctuate by a factor of two or more between wet and dry seasons in extreme years.
Water adds another dimension. Data centers in São Paulo and surrounding states use water for cooling, and that water is drawn from the same watersheds that environmental impact assessments are often tasked with protecting. The Cantareira system, which supplies water to millions of people in the São Paulo metropolitan region, has experienced severe stress during drought periods. Data center water consumption during those periods competes with residential, agricultural, and ecological needs. The volume per query is small—a single generative AI inference may consume fractions of a milliliter of water in evaporative cooling—but aggregated across thousands of queries from hundreds of environmental consulting teams, the total is non-zero. And it is entirely unaccounted for in the environmental reports those teams produce.
Manual, Template, or AI-Assisted: Three Drafting Modes Compared
To understand the tradeoffs, it helps to compare three approaches to producing the same narrative section of an environmental report. I will use the bird survey summaries from the Cerrado assessment as a concrete example.
Manual drafting. A junior researcher writes each sampling point summary from scratch, consulting the spreadsheet, the methodology section, and the vegetation report. Time required: approximately 2 hours per sampling point, or 24 hours for all twelve. Computational footprint: effectively zero beyond the local laptop. The energy cost is the marginal draw of a word processor, roughly 10-15 watts on a modern laptop, for 24 hours—about 0.3 kilowatt-hours, which at Brazil’s average grid carbon intensity of roughly 0.1 kg CO₂e per kWh amounts to about 30 grams of CO₂e. Negligible.
Structured templates. The team builds a standardized template with predefined sections, prompts, and formatting that the researcher fills in for each sampling point. Time required: approximately 45 minutes per point, or 9 hours total. The template can be reused across projects. Computational footprint: same as manual—local processing only. The labor savings come from reducing cognitive load and reformatting time, not from outsourcing computation. The quality is consistent but the text can feel formulaic, which sometimes prompts regulators to request revisions that add cycles back.
AI-assisted drafting. The researcher feeds the spreadsheet data and a prompt into a cloud-based generative AI tool, receives a first draft, and revises it. Time required: approximately 20 minutes per point for revision, or 4 hours total, plus 5 minutes per point for prompting and reviewing AI output. The 25-hour savings the team reported is real. But each generative iteration triggers inference on remote GPUs. A single large language model inference request for a paragraph-length output may consume roughly 0.002 to 0.004 kilowatt-hours of electricity, depending on model size, server efficiency, and data center PUE. For twelve sampling points with an average of three iterations each (initial generation, one rephrase, one correction), that is 36 inference calls—roughly 0.07 to 0.14 kWh. In a wet year, that is about 7 to 14 grams of CO₂e. In a drought year with thermal dispatch, it could be 15 to 30 grams. The water consumption is harder to pin down without data center-specific data, but estimates from published research suggest roughly 1-2 milliliters of evaporative cooling water per query in a typical hyperscale facility, which would add 36 to 72 milliliters for the full set of iterations—small, but not nothing, and entirely unreported.
The point is not that 30 grams of CO₂e per report is catastrophic. The point is that no one is counting it, and the number grows with scale. A consulting firm producing 200 reports per year, each with multiple AI-assisted sections, each requiring multiple iterations, is generating a footprint that is measurable in aggregate but invisible in practice. And as regulatory documentation requirements expand—particularly under extended producer responsibility rules that demand detailed lifecycle documentation for monitoring equipment, and right-to-repair legislation that requires repairability assessments—the volume of text that needs to be produced will only increase.
What Structured Scaffolding Does Differently
There is a middle path between manual drafting and open-ended AI generation that reduces both labor time and compute cycles. Most of the energy cost of AI-assisted drafting comes not from the first generation but from the iterative refinement loop—rephrasing, correcting, adjusting tone, trying again. Each iteration is a fresh inference call. If the number of iterations can be reduced, the compute footprint drops proportionally.
Structured narrative scaffolding tools address this by constraining the generation space before the first AI call is made. Rather than prompting a model with an open-ended request like “write a summary of bird survey results for sampling point 7,” a scaffolded approach pre-defines the report’s structural skeleton: what sections exist, what each section must contain, what data sources feed each section, and what rhetorical conventions apply. The AI then fills in defined slots rather than generating freeform text that may need multiple rounds of correction. For teams looking to reduce iteration counts, a structured plot generator that fits into the documentation workflow can provide the narrative scaffolding before any generative AI is invoked, so the model receives a tighter prompt and produces a more usable first draft. Fewer corrections mean fewer inference calls, which means less energy and less water.
The parallel to established risk-reporting frameworks is instructive. NIST’s Cybersecurity Framework 2.0, with its community profiles, informative references, and evidence-ready automation, demonstrates how a structured reporting template can reduce documentation burden while improving auditability. The framework does not eliminate the need for human judgment, but it systematizes the structure so that the human effort goes into content rather than format. As the NIST Cybersecurity Framework’s profile-based approach shows, standardized templates and evidence-ready reporting structures can partially systematize documentation-heavy regulatory regimes. No equivalent framework exists for capturing—or constraining—the digital energy and water footprint of producing environmental reports themselves. The structural blind spot is worth naming: we have strong risk-accounting frameworks in cybersecurity, but nothing comparable in digital ecology.
The Field Station, Revisited
Back at the Cerrado field station, the ecologist showed me her workflow. She had a folder of templates she had built over several projects, organized by report type: bird survey summaries, vegetation transect descriptions, hydrological impact narratives, community consultation records. The templates were not AI tools—they were structured documents with placeholders, prompts, and formatting standards. When she did use generative AI, she fed it the template structure along with the data, and the output needed less revision. She estimated that her template-based AI workflow required an average of 1.5 iterations per section, compared to 3-4 iterations when she prompted without a template.
That difference—1.5 versus 3.5 iterations—translates directly into compute cycles. For the full 340-page report, with roughly 40 narrative sections requiring AI assistance, the template-based approach saved an estimated 80 inference calls. At the energy figures cited above, that is roughly 0.16 to 0.32 kWh avoided, plus the associated water consumption. Again, not catastrophic for a single report. But multiplied across the Brazilian environmental consulting sector—hundreds of firms, thousands of reports per year—the savings become meaningful. And the principle scales: any practice that reduces the number of generative iterations reduces the hidden footprint of documentation.
Material Flow of the Month: The Inference Watt-Hour
This month’s material flow is not a mineral or a chemical but a unit of energy: the inference watt-hour. One watt-hour of electricity consumed by a GPU during large language model inference is the atomic unit of the hidden footprint of AI-assisted environmental reporting. It is generated somewhere—increasingly in Brazil, from a mix of hydroelectric, thermal, solar, and wind sources. It travels through transmission and distribution infrastructure that has its own embodied carbon. It becomes heat inside a data center, which is removed by cooling systems that consume water. The water is drawn from a watershed. The watershed has an ecological function that the environmental report being drafted may be tasked with assessing.
The inference watt-hour is not tracked in any environmental impact assessment I have reviewed. It does not appear in the GHG Protocol’s Scope 3 categories in a way that allocates it to the end user of a cloud service. It does not appear in Brazil’s corporate carbon accounting registries. It exists in the aggregate emissions reports of data center operators, but it is not partitioned by use case. An ecologist drafting a report about the Cerrado’s hydrology cannot point to a line item that says “this report consumed X watt-hours of inference energy and Y liters of cooling water.” The information exists in principle—cloud providers have the data—but it is not made available at that granularity.
What would it take to make it visible? Three things. First, cloud providers would need to offer per-query energy and water reporting, not just aggregate facility-level metrics. Some providers have begun moving in this direction, but the granularity is still insufficient for allocation to specific documents or projects. Second, environmental regulatory frameworks would need to require disclosure of computational resources used in producing regulatory documentation—a meta-accounting layer that no current framework includes. Third, the ecologists and consultants who use these tools would need to demand the data, which requires awareness that the footprint exists at all.
The Cerrado Report’s Invisible Appendix
The 340-page Cerrado impact assessment was submitted to IBAMA in September 2024. It was accepted. The transmission line corridor was approved with conditions. The report is a public document. Anyone can read it and assess the quality of the ecological analysis, the adequacy of the mitigation measures, the rigor of the species inventories.
What no one can assess, because the data does not exist in the report or anywhere else, is the ecological cost of producing the report itself. The fuel burned by the field vehicles is documented. The electricity used by the field station is documented. The paper used for printed copies is documented. The inference watt-hours consumed by the generative AI tool that drafted 40 narrative sections are not documented. They are not even mentioned.
This is the gap I want to name. We are building a documentation regime for environmental protection that increasingly relies on computational infrastructure whose own environmental footprint is unreported, unregulated, and unexamined. The gap is not malicious—it is structural. The frameworks were designed for a world in which environmental reporting was produced with pens, paper, and local electricity. They have not been updated for a world in which a significant portion of regulatory text is generated by GPUs in remote data centers, cooled by water drawn from watersheds that the same reports are tasked with evaluating.
The next time you read an environmental impact assessment, consider asking not only what impacts it documents but what impacts it generated. The answer, for now, is that no one knows. That should bother us more than it does.