AI Won't Fix Your ESG Data. It Will Reproduce It, Faster.

There is a moment most ESG teams encounter at some point in the AI experimentation cycle. You paste your data into a tool, type a prompt, and get back something that reads better than anything you've produced in weeks. The language is crisp. The structure is logical. It sounds, unmistakably, like a sustainability report. 

Then a reviewer asks:  
• Where does that number come from?  
• Who approved this explanation?  
• Can you show me the evidence behind this figure? 

And the answer, in most cases, is: not really.

The AI only worked with what it was given, and what it was given had no evidence, no owner and no approved context. And that is the most expensive mistake ESG teams are making right now: not because the output is obviously wrong, but because it reads convincingly enough to travel further than it should. 

The illusion: when AI makes bad data sound credible 

Here is what AI does exceptionally well: it takes whatever you give it and produces fluent, structured prose. That is also, in the wrong context, its greatest risk. 

Consider a data submission that includes one line: "Employee turnover increased from 14% to 31%." No explanation. No evidence. No approved context. Feed that to an AI drafting tool and it will produce something like: 

"The increase in employee turnover reflects a competitive labour market and higher voluntary attrition across the sector." 

That sentence reads well. It is completely unverifiable. No one in the organisation approved that explanation. The data owner never confirmed it. It is the AI's best guess at a plausible reason; and it will travel into a draft, through a review, and potentially into a published report unless someone specifically catches it. 

This is what we call the plausible sentence problem. It is not a hallucination in the technical sense. It is something subtler: AI filling a gap to finish a paragraph, because that is what it was implicitly asked to do. 

The diagnosis: data without context is not data 

The root cause is almost always the same, and it predates any decision about AI. 

A single number — say, 100 kWh of electricity consumption — is not useful ESG data. It becomes useful only when it carries the context that makes it trustworthy and interpretable:  

• The reporting period 
• The organisational boundary 
• The prior year figure for comparison 
• The reason for any significant change 
• The evidence supporting it 
• The name of the person who owns and approves it 

Without that context, what you have is a claim, not a data point. And what AI produces from a claim is a more convincing claim. 

Those six elements are exactly what an investor will probe when they read your Scope 1 figure. A fluent paragraph won't satisfy them; a submission that can't supply that context isn't investor-ready, however well it's written. 

The question worth sitting with before any conversation about AI tools: does our ESG data currently carry that context? If not, the first investment is not in AI. It is in data structure. 

The right sequencing: data architecture before agentic flow 

This is the sequencing mistake that costs ESG teams the most time: choosing the technology before designing the data. 

An agentic flow — a series of AI tasks connected in a defined sequence, with human review at set points — can genuinely transform ESG reporting. It can automate completeness checks, flag anomalies, anticipate investor questions, and produce first-draft narratives from approved data. These are real capabilities, and they are available today without advanced technical infrastructure. 

But they only work in that order: approved, structured data first, then AI agents operating on it. 

A well-designed agentic flow for ESG reporting breaks down into four distinct AI tasks, each with a specific job and a specific output: 

1. Completeness — before anything else, an AI agent reviews the submission and checks whether every metric has a value, a unit, a reporting period, an owner, evidence, and a status. It does not estimate what is missing. It identifies what is missing and routes the submission back to the data owner with a specific request.  
2. Variance — a second agent compares the current period against the prior period and flags movements above a defined threshold. It does not explain the movement. It writes a question to the relevant data owner: "Turnover increased from 14% to 31%. What factors contributed to this change in the 2026 reporting period?" The explanation comes from the human, not the AI. 
3. Investor lens — only once the data has been reviewed and approved does a third agent analyse it from an investor's perspective: what are the material movements? What questions will an investor reasonably ask? This agent separates facts from observations and flags where more context is needed — it does not decide what is material. That judgement stays with a person. (Read more on Pricing ESG)  
4. Drafting — the final agent writes the narrative using only the approved information provided. Where something is missing, it inserts [INFORMATION REQUIRED] rather than completing the sentence. The output is a draft with visible gaps, not a polished narrative with invisible ones. 

Four separate tasks. Four separate outputs. Four natural points for human review. The reason for the separation is accountability rather than procedural tidiness. When tasks are collapsed into one prompt, a failure anywhere in the output is invisible, because the whole thing still reads coherently. When tasks are separated, a failure is visible exactly where it happened. 

The two things you never hand to AI 

Across all of this, there are two decisions that must remain with humans. Not as a precaution, but as a governance requirement. 

The first is approving the explanation. When a variance is flagged and the data owner provides a reason, a human reviewer must assess that reason against the evidence before it travels any further in the process. An unapproved explanation reaching a draft — and from there, a report — is one of the most common failure points in AI-assisted ESG workflows. The AI did not cause the problem. The absence of a human gate did. 

The second is approving the disclosure. After the draft is produced, before anything is published, Investor Relations, Finance and Sustainability must review the output together: confirm the materiality framing, confirm that every marked gap has been closed or disclosed, and record their approval of the final wording. This is not a rubber stamp. It is the moment where professional judgement is applied to a document that will be seen by investors, regulators, and rating agencies. 

These two gates are not the parts of the process to streamline. They are the parts to protect. 

The first step: design the flow before the technology designs it for you 

ESG teams that struggle with AI tools have something in common: they started with the technology and worked backward. They picked a tool, started prompting, and tried to fit their data to what the tool could produce. 

The teams getting the most out of agentic AI did it the other way around. They started with a question: what do we need to report, and what does the data behind that need to look like? They structured the data before they automated anything. They mapped their existing workflow — collection, checking, consolidation, assurance, disclosure — and identified where a human genuinely needed to be involved versus where a rule or an AI agent could do the work reliably. 

Then they built the flow. And because the foundation was right, the AI worked with it rather than around it. 

You do not need advanced infrastructure to start. An AI agent is, at its simplest, a clear job description:  

• a specific task 
• a set of instructions 
• the data it needs to work with, and  
• a defined point at which it hands back to a person.  

The sophistication comes from the design of the flow, not the technology powering it. 

Start with one task.
The completeness check is usually the right one. It is low risk, immediately useful, and forces you to confront exactly what your data is and is not currently capturing. Run it for one reporting cycle. Review the results. Then build from there.