Why the AI should never be the one computing your emissions

Every carbon software vendor now ships an AI assistant. That is a good thing: most of the labour in carbon accounting is reading documents and moving data between systems, which language models do well. But there is a line that the better systems will not cross. The model can prepare the work. It should never be the thing that produces the number you file.

What language models are good at

A diesel invoice from a regional supplier, a discom bill with a kVAh line and a power-factor penalty, a scanned e-way bill, a supplier's reply buried in an email thread: this is unstructured, inconsistent input, and reading it is where models shine. They can find the quantity, unit, period, site and supplier. They can notice that a bill covers 45 days, not 30. And they can draft the request to the supplier who hasn't responded.

What they are bad at

• Being deterministic. The same prompt can produce different outputs. A reported emissions figure must be reproducible years later.
• Arithmetic at scale. Models are improving, but a system of record shouldn't rely on a model's multiplication.
• Knowing which factor applies. A model will confidently supply a grid factor from memory. It may be from the wrong year, the wrong country or no real source at all.
• Admitting a gap. Asked for a number, a model tends to give one. In compliance a missing value must stay visibly missing.

The division of labour

An auditable AI system separates three roles and never lets them blur.

1. The model reads and proposes. It extracts activity data from documents and connected systems, and states how confident it is based on what it actually found.
2. A deterministic engine calculates. Emissions are computed in ordinary code from the extracted quantities and a versioned factor with a named source. The same inputs always give the same output.
3. A person approves. Anything that becomes a filing, or changes the ledger, waits for a responsible human to approve it. The approved values are recomputed at that moment instead of being trusted from the draft.

If the answer runs through a model's reasoning, it can't be re-performed. If it runs through extracted fields, a named factor and a line of code, it can.

Five questions to ask any AI carbon tool

1. Can I recompute any reported figure from its inputs and get the identical result?
2. Does every factor have a named source, a year and a version, and can I see which one was used?
3. What happens when data is missing: does the system stop and ask, or fill the gap silently?
4. Is confidence based on what was actually extracted, or is it a fixed number shown on everything?
5. Can the final report be proven unchanged after approval?

How we apply this at ZeroCarbon

Our agents read documents and connected accounts, plan the work and draft requests, but the emissions arithmetic runs in a shared deterministic engine with versioned, sourced factors. When a country or factor isn't covered, the engine fails closed instead of guessing. Agent actions that write to the ledger wait for approval and are recomputed when approved. Every generated report is anchored with a SHA-256 digest so anyone can check it hasn't changed since sign-off.

It is a less magical story than "the AI does your carbon accounting". It is also the only version that survives an audit.