Over the last two years, the conversation about artificial intelligence in the electric utility sector has changed a lot. Instead of asking if AI belongs in grid operations, people now talk about where and how to use it. Battery energy storage systems use predictive simulations at the asset level. Solar fleet operators use machine learning to help decide which maintenance tasks to prioritize. Distribution utilities are trying out edge-based analytics for things like voltage optimization, fault detection and demand response across their growing portfolios of distributed energy resources.

The technology is effective, as pilot projects have shown. However, as utilities move from small-scale tests to AI across many DER sites, new challenges are emerging. These challenges are less about whether the models are correct or powerful enough, and more about a question that is often overlooked: how do you keep AI reliable, trustworthy and manageable once it is running across a distributed fleet in real-world conditions?

This is not a small issue. As utilities with DER portfolios grow and become more complex, how they answer this question will determine whether AI becomes a lasting part of their operations or just an expensive technology that loses value after the first year.

The deployment-to-operations gap

Most AI projects in the utility sector follow a familiar trajectory. A use case is identified. Data is gathered and cleaned. A model is trained, tested against historical data and validated in a controlled environment. It performs well. It’s deployed to a site or a handful of sites, and the early results look promising.

What happens next is where things get complicated.

The model was trained on a snapshot of the world as it existed during that training window. But utility environments do not hold still. A battery storage site commissioned with one OEM’s equipment receives a firmware update that changes the data format for state-of-charge readings. A solar installation adds a new inverter model with a different communication protocol. A distribution feeder gets reconfigured after a capacity upgrade, altering the load profile that the model learned from. A demand response program changes its dispatch rules, shifting the patterns the model uses to make recommendations.

None of these changes are unusual. In a utility managing a growing DER fleet, they happen continuously. Each one has the potential to diminish model effectiveness in ways that are difficult to detect without deliberate monitoring.

In centralized software setups, operational drift is handled with standard DevOps practices, like version control, continuous integration, automated testing and rollback procedures. But AI at the grid edge is different. Edge nodes are spread out over large areas. Many have spotty or no network connections. Hardware varies by site and firmware versions can change over time. Getting physical access to these sites often requires planning and travel.

The tooling and practices that work in the cloud do not translate directly to this environment. And yet, the models running at the edge are making or influencing decisions that affect real grid operations.

What drift actually looks like in DER operations

It helps to be clear about what model degradation looks like in practice. The effects are usually not dramatic. Instead, small drops in performance add up over time.

Take a battery storage fleet where AI models handle charge and discharge schedules to improve market participation and grid support. When the models were first trained, the fleet had lithium-ion systems from two manufacturers using the same protocol. Six months later, a third manufacturer’s system is added, but it reports cell temperature and voltage differently. The model keeps running, but now it gets data that doesn’t match what it was trained on. Its recommendations for the new equipment become less accurate, and over time, this can affect how it manages the entire mixed fleet.

Or consider a distribution utility that uses edge-based fault detection throughout a set of DER-interconnected feeders. The model was trained on fault signatures collected during a specific seasonal period. As conditions shift, new load patterns emerge from EV charging infrastructure that was installed after the model was trained. The fault detection model begins generating false positives on feeders with heavy EV charging loads, because it interprets the new load signatures as anomalies. Operators start dismissing the alerts. Confidence in the system erodes, and an actual fault eventually gets missed.

These are not exotic failure modes. They are expected results of deploying learning models into environments that change faster than the models can adapt on their own.

The four disciplines that fleet-scale AI demands

Utilities that have moved past the pilot stage and are running AI across multiple DER sites tend to converge on the same set of operational requirements, whether they arrived at them through planning or through painful experience.

Ongoing data normalization is critical at this point. Making data usable is a continuous process that must keep up with changes in the fleet. When a new asset is added, a protocol changes, or a SCADA integration is updated, the data pipeline must adjust. This means the edge infrastructure should support multiple protocols, use automated tagging to maintain semantic consistency and normalize data near the source before it reaches the model.

This is particularly important in DER situations where assets from different manufacturers, installed at different times, under different service agreements, all need to produce data that is comparable across the fleet. Without that consistency, models built on data from one subset of the fleet will not generalize well to others.

The second is lifecycle orchestration at fleet scale. A model that works today will need to be updated as conditions change. It may need to be retrained on new data. It may need to be replaced entirely by a newer version. When something goes wrong, it needs to be rolled back to a previous known-good state. All of this has to happen across dozens or hundreds of edge nodes, many of which are not permanently connected to a central management system.

Managing this process really cannot be left as an afterthought. Ideally, the system should support staged rollouts, allowing a new model version to be tested on a small number of sites before being deployed more widely. It also needs to be able to cope with sites that have unreliable connections, queueing updates and confirming delivery when a node reconnects. Keeping track of which model version is running on each node is also important.

Utilities that are used to manage firmware updates will recognise some of these requirements, although AI model updates can, in practice, affect system operation in ways that firmware updates typically do not.

Knowing what your models are doing, and what they should not be doing

The next key requirement is ongoing monitoring and observability. Deploying a model without checking its performance over time is a bit like installing a protection relay and then never testing it again. Models need to be monitored on an ongoing basis, with metrics that show not only whether they are running, but also whether their results continue to match expectations.

This requires telemetry designed for distributed environments. Not every edge node will be able to stream performance data in real time. Some will need to batch and forward. Some may need to evaluate model effectiveness locally against predetermined thresholds and generate alerts only when something drifts outside acceptable bounds. The monitoring infrastructure needs to accommodate all these scenarios when providing fleet operators with a consolidated view of model health across the entire DER portfolio.

The fourth requirement is enforcing boundaries. At present, AI in utility operations should only provide advice, with humans retaining control over business-critical decisions. Most people would agree with this in principle, but making it work in practice across a distributed fleet is quite a different challenge.

Enforcing boundaries means laying out clear rules at the platform level for what actions an AI model can suggest, what it can do with human approval and what it cannot do at all. These rules should be the same across the whole fleet, not set differently for each node, so local practices stay in line with company policy. As the industry looks at more autonomous AI, making and enforcing these boundaries at the infrastructure level becomes even more important.

Why the edge is different from the cloud

Some of these problems also exist in cloud-based AI deployments. But the edge introduces constraints that considerably alter the calculus.

Latency requirements are the most obvious differentiator. For DER operations that require sub-second response times, e.g., frequency regulation, voltage support, or rapid dispatch adjustments, processing must occur at or near the asset. Sending data to a cloud environment for inference and waiting for a response introduces delays that are simply incompatible with these use cases.

Operational margins are just as important. Edge environments commonly have limited computing power, memory and storage. They might be in places without reliable network connections and may need to run on their own for long periods. Hardware setups are different at each site, so the edge software must work on anything from small gateways to large servers in substations.

All of this means that the AI lifecycle management infrastructure cannot assume a homogeneous, always-connected, resource-abundant environment. It has to be designed for heterogeneity, intermittent connectivity and constrained resources from the start.

The organizational dimension

It’s important to recognize that managing AI across DER fleets is not only a technical challenge. There is also an organizational side that is just as important and often overlooked.

Who owns the AI models once they are deployed? In many utilities, the data science team that built the model hands it off to operations, and the operational technology team is expected to manage it going forward. But OT teams are accustomed to managing deterministic systems. A protection relay behaves the same way every time it encounters the same input. A machine learning model does not. Its behavior is determined by the data it was trained on, and when that data no longer reflects the operating environment, the model’s behavior changes in ways that are difficult to predict without specialized monitoring.

Utilities that handle this switch well set up clear ownership between data science and operations teams. They define who is responsible for monitoring model effectiveness, when to retrain, and how to handle problems. Utilities that struggle often have gaps in ownership, so no one notices issues until they become obvious operational problems.

Where is this heading?

The trajectory of AI in DER fleet operations is clear. Models will get more capable. Edge hardware will get more powerful. The use cases will expand from advisory analytics into closer integration with control systems. Some of that is already underway.

But none of that progress will matter much if the utility sector does not build the operational infrastructure to manage AI reliably at scale. The models themselves are only as valuable as the organization’s ability to keep them current, monitor their performance and sustain trust in their outputs over time.

This is not simply a technology problem. It is a challenge of operational maturity. Utilities that treat AI governance as a key part of operations, like asset management or cybersecurity, will get lasting value from their investments. Those who see it as a project that ends at deployment will end up with more and more models they cannot trust or verify.

The DER fleet of the future will be more intelligent, more autonomous and more responsive than anything the sector operates today. Getting there doesn’t require just better models, but better infrastructure for managing the models themselves. That work is less visible and less exciting than a new algorithm, but it is the foundation on which everything else depends.