The pattern is familiar: critical code that nobody internally understands
A grid operator commissions an AI module for congestion management or capacity planning. It works. The system runs. Two years later, the vendor has been acquired, shut down, or simply become unreachable. Internal engineers know what the system does, but not how. There is no documentation, no handover file, no test environment. The code is a legacy artifact that nobody dares touch. This pattern appears in energy and grid management more often than in other sectors, precisely because pressure is high and time is short: something has to be built quickly to address grid congestion, and governance around handover is treated as a side issue. Until it becomes the main issue.
Why is this risk greater in energy and grid management than elsewhere?
Three factors make this specifically dangerous in this sector. First, grid operators are subject to statutory obligations, including the Wet congestiemanagement and reporting requirements to the ACM. Software that forms part of those processes cannot simply fail or be modified without someone understanding what is changing. Second, the infrastructure is operationally critical: a decision-support system that stops or produces incorrect output has direct consequences for grid balance and security of supply. Third, AI in this domain is increasingly used for forecasting and automated recommendations, but the requirement for transparency and human oversight is fundamentally at odds with software whose internal workings are undocumented. If you do not understand the code, you cannot explain why the system made a particular recommendation.
What happens in practice when the vendor of your AI software disappears?
In the best case, you have a working application you cannot modify. Updates to the environment, new data inputs, or regulatory changes require adjustments that nobody internally can make. You become dependent on a new external party that has to learn the codebase from scratch, which costs time and money. In the worst case, you have a system whose licences, API integrations, or cloud infrastructure are tied to the vendor that no longer exists. Then nothing runs at all. For a grid operator or energy supplier, that means falling back on manual processes, with all the associated risks for capacity management, customer communication, and compliance.
What does a sound handover and management structure actually look like?
A robust handover structure consists of four concrete elements. Ownership of code and data: the source code, training data, and configurations are held on the client's infrastructure, not the vendor's. Working-level documentation: not a technical report filed away in a drawer, but documentation that allows a new engineer to understand within a reasonable time how the system works, how it is fed with data, and how to adjust it when inputs change. A test environment and deployment pipeline: a reproducible way to redeploy the system, so you are not dependent on the specific laptop or server environment of the vendor. And finally, knowledge transfer to internal staff: at least two people internally who have co-built the system or demonstrably understand how it works. This sounds like basic project closure, but in practice it is rarely fully in place for AI projects in energy and grid management.
When do you rebuild the core system from scratch, and when do you opt for a management layer?
Not every energy or grid management company needs to rebuild its core systems. Sometimes an existing system is good enough and it makes more sense to build a manageable AI layer around it, provided the ownership and handover structure is sound. But if an organisation finds that its core operational processes run on software that is not understood internally, is undocumented, and belongs to an external party, that is an argument for addressing the problem more fundamentally. A core system that is fully owned by the organisation, with code that can be understood and maintained internally, is more resilient than a stack of external modules whose interconnections nobody understands. The right choice depends on the complexity of the system, the extent of the dependency, and the regulatory requirements the organisation must meet.