A carbon accountant asks a chatbot for the emission factor for purchased steel. Back comes a clean answer: "2.89 kgCO2e per kilogram, per the GHG Protocol." It is formatted perfectly, even cites a source. She drops it into the inventory. Two months later the assurer asks for the page in the GHG Protocol where that factor appears. It is not there. The number was never in any database. The model did not lie, exactly. It did the one thing it is built to do: it predicted the most plausible next words, and a plausible-looking factor is just words that fit. This lesson explains why the same machine that drafts a flawless ESRS narrative will also, with the same calm confidence, hand you a number that does not exist.

What the Model Is Actually Doing

You do not need to be an engineer to use a generative AI safely, but you do need one accurate mental model of what it is doing, because the wrong mental model is what gets people into trouble. So here is the accurate one, in plain disclosure language.

A large language model, or LLM, is a system that predicts the next chunk of text given the text so far. That is the entire job. It was trained by reading an enormous quantity of human writing and learning, statistically, which words tend to follow which other words in which contexts. When you give it a prompt, it does not look anything up. It generates, one piece at a time, the continuation that its training makes most probable. Why you care: the model is a probability engine for language, not a database of facts. It produces what sounds right, and sounding right and being right are two different properties that happen to overlap a lot of the time, which is exactly what makes the gaps so dangerous.

The chunk the model predicts is called a token. A token is a small piece of text, often a word or part of a word. The model reads your prompt as tokens and emits its answer as tokens, each one chosen because it is the most probable next token given everything so far. Why you care: when you hear that a model has a "context window" or is "predicting tokens," all it means is the model is assembling an answer piece by piece from probabilities, with no separate step where it checks whether the assembled pieces are factually true. There is no fact-checker inside the box. There is only the prediction.

Why Plausibility Is Not Truth

Hold onto one sentence and you will understand ninety percent of what can go wrong: the model optimizes for plausibility, not truth. It is extraordinarily good at producing text that looks like the kind of text a knowledgeable person would write. An emission factor has a recognizable shape: a number, a unit like kgCO2e per kilogram, and a source that sounds official. The model has seen thousands of real factors in its training, so it knows that shape cold. When you ask for a factor it does not actually have, it does not stop and say "I do not have that." It fills the shape. The result is a number with the right number of decimal places, the right units, and a confident citation, and it is fiction.

This is the deep reason the same model can do two opposite things. Drafting a clean ESRS narrative paragraph and inventing an emission factor are, to the model, the same operation: produce plausible next tokens. When you ask it to describe your transition plan in fluent prose, plausibility and usefulness line up, and you get a good first draft. When you ask it for a specific factual value it was never given, plausibility and truth come apart, and you get a confident fabrication. The machine cannot tell the difference, because from the inside there is no difference. Both are just text that fits.

The model is not trying to deceive you. It is trying to sound right. Deception requires knowing the truth; the model only knows what is probable.

Hallucination in a Disclosure Context

The industry word for this is hallucination: a confident, fluent output that has no basis in any real source. In casual use a hallucination is an annoyance. In a disclosure, a hallucination is a misstatement waiting for an assurer to find it. Why you care: every hallucinated number that reaches your inventory or your narrative is a figure you cannot trace to evidence, and a figure you cannot trace is the precise thing that fails assurance.

Hallucinations in reporting work come in a few recognizable shapes, and naming them helps you hunt them.

The Invented Emission Factor

The model produces a factor that has the right form but appears in no database. It may even cite a real source, the GHG Protocol or a national inventory, because citing a plausible source is part of producing plausible text. The citation is generated, not retrieved. This is the steel-factor failure from the opening, and it is the most common and most dangerous, because a single wrong factor silently multiplies through an entire category of your footprint.

The Fabricated Activity Figure

Asked to "estimate" a missing supplier's tonnage or a site's fuel use, the model produces a specific number that sounds reasonable and was never measured or even properly computed. It is not an estimate with a method; it is a guess wearing the clothes of a measurement.

The Target the Company Never Set

Asked to draft a narrative about your climate commitments, the model writes that the company has "committed to net zero by 2040" because that is the kind of sentence such narratives usually contain. If no such target exists, the model has just invented a public commitment, and a fabricated target in a disclosure is both a misstatement and a greenwashing exposure.

The Softened Negative Impact

This one is subtler. Trained on a great deal of corporate prose that tends to put a positive spin on things, a drafting model may quietly soften a negative impact, turning "a significant pollution incident" into "an environmental event that was addressed." Nothing is fabricated outright, but the meaning has drifted toward the reassuring, and in a disclosure that drift can itself be a misstatement.

Why the Confidence Is the Trap

If hallucinations came labeled, they would be harmless. The danger is that the model expresses a fabricated factor with exactly the same fluent confidence as a correct one. There is no tremor in the voice, no hedge, no flag. The steel factor in the opening was delivered as smoothly as a real one would have been, which is precisely why it sailed into the inventory. Why you care: you cannot rely on the output's tone to tell you what is true, because tone is part of what the model fabricates. A reporting professional who waits for the model to look unsure will wait forever.

This is the practical heart of the discloser's relationship with generative AI. The model's confidence carries zero information about correctness. The only thing that carries information about correctness is the source, which lives outside the model. So your verification can never be "does this look right." It must be "show me where this came from," asked of a source the model does not control.

Treat every number a generative model hands you as a claim, not a fact, until you have seen the source it should have come from.

Grounding: The One Move That Changes Everything

There is a way to make a generative model far safer for reporting work, and it is worth understanding in principle even before you ever configure it. The technique is called grounding, often implemented as retrieval-augmented generation, or RAG. Instead of asking the model to generate an answer from its general training, you first retrieve the relevant real documents, your factor database, the supplier's response, the policy, and you give those documents to the model along with the question, instructing it to answer only from what you provided.

The shift is profound. Now the model's job moves from estimation toward extraction. Instead of producing a plausible factor from its memory, it pulls the actual factor from the database you handed it and can point to where in that document it found it. The probability engine is now constrained to your evidence base rather than its imagination. Why you care: grounding does not make hallucination impossible, but it changes the model's default from "invent something plausible" to "find it in these sources," and it gives you a source to check. An ungrounded model is answering from memory; a grounded model is answering from your evidence. For a discloser, that distinction is the difference between a number you can defend and a number you cannot.

Why the Model Cannot Just Say "I Don't Know"

A reasonable reaction to all this is: why does the thing not simply admit when it does not have the answer? It would solve most of the problem. The reason is structural, and worth understanding because it tells you not to wait for an admission that will rarely come. The model has no internal sense of "I have this fact" versus "I am improvising." From the inside, both feel identical, because both are the same act of predicting probable tokens. When you ask for a real factor it has seen many times, the probable continuation happens to be correct. When you ask for one it has not, the probable continuation is a plausible fabrication. The model experiences no difference between the two, so it cannot flag the difference for you. There is no little light that turns red when it starts making things up.

This is why a discloser's posture toward a generative model can never be "trust unless it warns me." The model does not warn. It produces its best guess at probable text in every case, with uniform confidence. Some newer systems are trained to hedge more, to say "I am not certain" in some cases, and that is genuinely helpful, but it is a softening of the symptom, not a cure for the cause. The cause is that the machine predicts plausibility and has no separate faculty for truth. Your verification, therefore, cannot be conditional on the model looking unsure. It must be unconditional: every figure gets checked against a source, every time, because the one figure that is fabricated will arrive looking exactly like the dozens that are fine.

Do not wait for the model to confess. It cannot tell when it is improvising, so the discipline of checking every number must come entirely from you.

What This Means for Narrative Versus Numbers

Understanding token prediction lets you calibrate your trust differently for two kinds of output, and getting this calibration right is a large part of using generative AI well in reporting work. For narrative drafting, where you want fluent, well-structured prose and you intend to check the substance anyway, the model is genuinely valuable. A first draft of an ESRS narrative paragraph, a restructuring of a clumsy disclosure, a plain-language summary of a policy: these play to the model's strength, which is producing good language, and the risk is contained because you will verify every claim and figure inside the prose before it ships. The model writes; you fact-check; the work product is better and faster.

For specific factual values, an emission factor, an activity figure, a target, a percentage, the same model is at its most dangerous, because here plausibility and truth come apart and the output is precisely the kind of thing that must be exactly right and fully sourced. The correct instinct is almost the opposite of the narrative case: do not let an ungrounded model originate a number at all. Numbers should come from extraction against a real source or from a documented estimation method, not from the model's memory. If a generative model is involved with a number, it should be retrieving it from a document you provided and pointing to where, never producing it from training. Calibrate this way and you get the best of the tool: fluent help on language, disciplined sourcing on figures, and no confusion between the two.

This calibration also explains a common and dangerous mistake. A team has a good experience using the model to draft narrative, builds justified confidence in it, and then extends that confidence to asking it for emission factors, treating the number request like another drafting task. The trust was earned on a job where the model is strong and silently transferred to a job where it is weakest. The factor comes back fluent and confident, just like the narrative did, and sails into the inventory. The lesson is that trust in a generative model is job-specific, never global. Being good at writing is not the same as being right about a number, and the model gives you no signal that you have crossed from one to the other.

A Worked Example: Before and After

Watch the steel factor travel two paths.

Before (ungrounded). The accountant types into a general chatbot: "What is the emission factor for purchased steel under the GHG Protocol?" The model, answering from training, predicts the most plausible completion: a number, a unit, a citation. Out comes "2.89 kgCO2e per kg, per the GHG Protocol." It looks authoritative and it is fiction. It enters Category 1, multiplies across thousands of tonnes of steel, and quietly inflates or deflates a material slice of the footprint. The assurer asks for the source page. There is none. The figure is pulled and the inventory reopens.

After (grounded and verified). The accountant works inside a tool grounded on the company's licensed emission-factor database. She asks the same question. The system retrieves the actual steel factor from the named, dated database and returns it with the source reference: the specific dataset, the version year, and the line. She still verifies, because grounding reduces but does not eliminate error: she opens the cited dataset and confirms the factor and its boundary. Now the number has provenance. When the assurer asks "where did this come from," the answer is a named database, a version, and a verification note in the file. Same question, same model architecture underneath, completely different defensibility, because the model was pointed at evidence instead of asked to imagine.

The difference was never the model's intelligence. It was whether the model was generating from memory or retrieving from a source, and whether a human checked. That is the whole discipline in one example.

It is worth sitting with how small the change was and how total its effect. The accountant typed nearly the same words both times. The model running underneath was the same kind of system, predicting tokens by probability in both cases. Nothing about the technology improved between the failing path and the passing one. What changed was the plumbing around the model: in the second case the question was answered against a real, named, dated database instead of against a sea of training text, and a human opened the cited source to confirm. That is the entire move. A discloser does not need a better model to be safe. A discloser needs the model pointed at evidence and a human who checks the evidence, and those two habits convert a probability engine that will confidently invent a steel factor into a retrieval tool whose every number can be walked back to a source the assurer accepts.

Key Takeaways

• A large language model predicts the most probable next token of text; it generates rather than looks up, and there is no built-in fact-checker inside it.
• The model optimizes for plausibility, not truth, so sounding right and being right are different properties that only sometimes coincide.
• The same operation, predicting plausible text, produces both a clean ESRS narrative and an invented emission factor; the model cannot tell the two apart.
• A hallucination is a confident, fluent output with no basis in any real source, and in a disclosure it is a misstatement waiting to be found.
• Common reporting hallucinations include invented emission factors, fabricated activity figures, targets the company never set, and quietly softened negative impacts.
• The model's confidence carries zero information about correctness, because tone is part of what it fabricates; never verify by whether output looks right.
• Grounding (retrieval-augmented generation) constrains the model to your real documents, shifting it from inventing plausible answers toward pulling answers from a source you can check.
• Treat every model-supplied number as a claim until you have seen the source it should have come from, and keep that verification in the file for the assurer.