AI in Energy and Utilities

Utilities have quantitative forecasting teams that have been good at their job for decades, and a document burden that nobody has ever had time to touch. Almost every successful project in this sector is on the second of those.

Forecasting is already priced

Load forecasting and renewable output forecasting look like obvious targets, and they are the clearest example in this cluster of a problem a language model should not be near. The reason is not that models are bad at numbers, although they are. It is that the incumbent methods are optimising against a target that is already denominated in money.

In most electricity markets a participant nominates a position and is settled for the difference between that and what actually happened, at an imbalance price. Every megawatt-hour of forecast error has a price attached, published, per settlement period. That means the forecasting team already knows exactly what an improvement is worth, already measures it continuously, and is already using gradient-boosted trees or statistical models over weather ensembles, calibrated to that loss. There is no gap for a text model to fill, and a system that produces a plausible number without a calibrated distribution is a step backwards.

Where language work does touch forecasting is at the edges — reading the outage notifications, maintenance schedules and market notices that change the assumptions behind a forecast, and getting them into the model’s inputs as structured events instead of sitting in somebody’s inbox.

The industry runs on documents

The document estate in a utility is enormous, long-lived and highly structured by convention, which is the ideal combination.

• Interconnection and connection applications. Long submissions with standard sections, assessed against published criteria, queued for months. Completeness checking against the criteria before submission is worth more than generation: the expensive failure is a resubmission that goes to the back of a queue.
• Asset inspection reports. Decades of field observations in free text, describing corrosion, vegetation encroachment and component wear, which nobody can query. Structuring them against an asset register makes a maintenance history searchable for the first time.
• Outage tickets and customer contacts. During a storm, thousands of reports arrive describing the same events in different words, and clustering them to physical assets is a triage problem with a direct effect on restoration order.
• Regulatory and compliance filings. Recurring, structured, deadline-bound, assembled from data the business already holds. Assembly and cross-checking, with a human filing.
• Procedures. Field crews and control engineers work to written procedures; finding the right one under time pressure is a retrieval problem, and the retrieval has to be exact rather than approximate.

Aerial and drone inspection imagery deserves a note of its own, because the volume makes it a triage problem rather than a detection one. Nobody can look at every frame of a transmission corridor. The useful system surfaces candidates for human review, and the metric is recall at a fixed human review budget — how many true defects appear in the top thousand frames an inspector will actually open. Precision beyond that budget is irrelevant, and average accuracy across all frames is meaningless when almost every frame is fine.

The control room boundary

Energy systems separate operational technology from information technology rigorously, for the same safety reasons described in manufacturing, and the consequences are stricter here because the system is critical national infrastructure in most countries. Nothing generative writes a setpoint, and any tool used by a control engineer is advisory to a person working under a procedure.

That has a design implication that is easy to state and easy to get wrong. During an incident, a control engineer is time-pressured and a confident summary is exactly the wrong output, because deviation from procedure is itself a reportable event and a summary that omits a step invites one. What helps is retrieval that puts the relevant procedure section in front of them with its identifier and revision, unmodified, rather than a paraphrase of it. The system’s job is to find the page, not to tell them what it says — and where it cannot find one with confidence, saying so is the correct output.

Deployment shape follows the same logic as elsewhere: assets and topology data are sensitive in a security sense rather than a commercial one, so where processing happens is a question asked early and answered contractually. See on-premises deployment and data residency.

Units, signs and the errors they hide

One failure mode is worth naming because it recurs in every energy project and it produces answers that look right. Power and energy are different quantities with confusable units — kW and kWh, MW and MWh — and the industry writes both constantly. A model summarising a report will interchange them without hesitation, producing a sentence that parses, sounds technical, and is dimensionally wrong.

Sign conventions do the same thing. Import and export, generation and consumption, charge and discharge are represented as positive or negative depending on which system produced the file, and the convention is often documented only in a header. A summary that gets the sign backwards describes a site exporting when it is importing.

Neither is fixable by prompting. Extract quantities with an explicit unit field and an explicit sign convention field, reject records where either is absent, and check dimensional consistency in code before anything is displayed — the same posture as extract-then-reconcile. In an industry where a report goes to a regulator, an unnoticed unit error is not an embarrassment, it is a correction filing.