The conversation around AI in sustainability reporting tends to swing between two extremes. One side argues you need a massive cloud-based large language model for everything. The other argues that any use of language models is wasteful. We think both positions miss the real question: which parts of the problem actually benefit from language understanding, and how do you run those as efficiently as possible?

Where Language Understanding Actually Helps

A lot of sustainability reporting is structured math. Invoices, emission factors, and XBRL tags follow deterministic rules that a functional pipeline handles better than any neural network. But a few parts of the workflow genuinely depend on understanding language in context.

Regulation cross-referencing. A compliance team might need to know how an ESRS disclosure requirement maps to a specific clause in the CSRD, or whether a new Omnibus amendment changes an existing obligation. That task is about matching meaning across documents, not just looking up keywords.

Narrative classification. The double materiality assessment collects open-ended input from stakeholders. Categorizing those responses into impact and financial risk themes is a text problem, not a math problem.

Anomaly detection. When an emission factor or a supplier claim looks out of line with historical patterns, flagging it for review benefits from understanding the context around the data point, not just comparing numbers.

Why Small, Local Models

For those three use cases, we are developing small language models designed to run on consumer-grade hardware. No GPU cluster needed. No data traveling to a cloud provider. These SLMs consume a fraction of the energy of a cloud-based LLM per inference, and they run on infrastructure the customer controls.

That last point matters more than most people realize. Sustainability data is commercially sensitive. A company's supplier relationships, emission profiles, and internal risk assessments are not something most organizations want to send through a third-party API. Keeping inference local means keeping the data local.

How It Fits Into the Broader Pipeline

We are not building an AI that tries to do everything. The deterministic engine handles the parts of reporting that should be deterministic (calculation, factor matching, XBRL generation). The SLMs handle the parts that genuinely benefit from language understanding. The two systems work side by side, with clear handoffs and no hidden black boxes.

This layered approach means a company gets the efficiency gains of automation on the structured side and the nuance of language understanding on the unstructured side, without the cost, latency, or privacy tradeoffs of routing everything through a cloud model.

The Practical Impact for CSRD Workflow

What this looks like in practice: a regulation cross-reference query returns in milliseconds on a standard laptop. A batch of stakeholder narratives gets classified overnight on a local server. An anomaly flag comes with an explanation written in natural language, not a cryptic error code.

We built BUME around the idea that the right tool for each job makes the whole pipeline more reliable. The SLM research is the latest piece of that philosophy, and it is the piece that finally lets us handle unstructured text with the same rigor we have always applied to structured data.