Collaboratively, we’ve been working with utility operators for decades, and while we’re seeing AI adoption in grid operations accelerate, reported ROI is lagging.

Across industries, 79% of enterprises have adopted AI agents in some form, but only 11% have them running in production — the largest deployment backlog in enterprise tech history — while a separate cross-study analysis finds 95% of generative AI pilots fail to deliver expected returns.

But for utilities specifically, the obstacle is rarely the model. It’s that AI tools optimize a single narrow task without ever connecting to the broader operational picture.

Where investment gets decided

The most common pattern behind stalled AI investment is that the pilot is funded as an experiment, not as phase one of a deployment. The budget covers the sandbox, the demo data and a few months of vendor support; success is declared when the model produces promising results.

What rarely gets scoped up front is the work that makes AI operational: integration with OT systems; data pipelines from SCADA and AMI infrastructure whose integration interfaces exist but vary widely in format and capability from one utility’s implementation to the next; security review; compliance mapping; and the change management that gets operators to trust the output. That second half usually accounts for most of the cost and the calendar time. The technology didn’t fail; the procurement was designed around a demonstration instead of an outcome.

The bigger mistake is treating AI as something you acquire rather than a decision about how the organization operates. An organization that talks about AI as something you buy will buy things. A tool for outage prediction here, one for vegetation management there. Each with its own data requirements and vendor relationship.

Eighteen months later, there’s a portfolio of point solutions, each adequate in isolation, none compounding, because the real problem lies in the connections between systems, not in any one tool.

That framing gets locked in at budget approval. If the approved objective is to “demonstrate that AI can predict transformer failures,” the pilot is already in trouble — that goal can be met fully while delivering zero operational value. The objective that belongs in that document is narrower: reduce unplanned outages by a defined percentage, measured in real time, feeding into the existing work-order system. No AI spend should be approved without a named operational owner, a real business metric and a defined production pathway in the original task.

Measuring what works

Utilities are good at measuring traditional capital investments – an asset deploys, performs to spec, value accrues on a known schedule. AI doesn’t follow that line; it arrives on a curve that starts flat while data pipelines get built and operators learn to trust the output, then compounds as that foundation lowers the cost of the next use case. Judged at month six by capital-investment logic, almost every AI pilot looks like a failure.

The initiatives that do reach the control room share a pattern: operations owned them from day one, not innovation or IT; OT, IT, cybersecurity and compliance sat together from the start instead of being consulted sequentially; and governance was written before deployment, not negotiated after an incident. None of this is technically sophisticated; its organizational design was made in the first thirty days.

Why the integration layer decides the outcome

Those organizational fixes only work if the technical layer underneath can support them. Scott’s point about procurement lands squarely on an engineering reality: most utility AI pilots are evaluated against data that was cleaned and curated in a lab environment. Production is a different world. SCADA, AMI and outage management systems were built over decades, on different protocols and different assumptions about who (or what) would be reading their data.

A model that performs well against a static dataset can behave unpredictably once it’s wired into a live telemetry stream with gaps, latency and format inconsistencies the pilot never had to account for. Interoperability isn’t a connector problem solved with an API; it’s a data-quality and data-lineage problem that must be solved before a model is trusted to handle anything that touches grid operations.

The second gap is architectural. Utilities operate under compliance regimes (NERC CIP, among them) designed for fixed control systems, not for adaptive models retrained on new data. Bolting security and compliance review onto a finished pilot is where many otherwise-promising deployments stall, because the architecture wasn’t designed to answer the questions a reviewer will ask: What happens if the input feed is compromised? How are model updates authenticated and audited, and what’s the fallback if the system loses confidence in its own output? Those answers belong on the first architecture diagram, not retrofitted after a security team finally sees the project — by then, redesigning is often more expensive than starting over.

“Production-ready” means something specific in a control room that it doesn’t mean in typical enterprise software: deterministic, auditable behavior under conditions the model hasn’t seen before, a defined fallback when confidence drops and a clear boundary between what the system recommends and what a human confirms. Building that boundary requires a clean, governed, interoperable data foundation — because a model can’t know the limits of its own knowledge if the data feeding it is inconsistent to begin with.

This is also a sequencing problem. Utilities that try to layer AI onto legacy OT/IT architecture in one motion tend to inherit every unresolved data-quality and access-control issue that the architecture was quietly carrying. The model just makes those gaps visible, usually at the worst possible moment. The utilities seeing durable returns invert that order: they treat integration and governance as the deliverable of phase one, funded and staffed like real infrastructure work, with the AI capability layered on top only once the plumbing already works. It’s slower up front, and it’s the only version of the sequence that doesn’t have to be redone.

Half of utility AI investments aren’t paying off for two reasons that compound each other: the budgeting and governance discipline to define what production means, and the technical discipline to build for it from day one.

Neither gap shows up in a pilot demo. Both show up the moment a utility tries to turn a promising model into something a control room can rely on. Closing them doesn’t require better algorithms. It requires treating AI as an operating model decision with a named owner, a real metric and an integration architecture designed for production before the first line of code is written.