AI adoption governance in the energy sector: how utilities grant AI the authority to act

Stage 1 is not an absence of AI. It is an absence of any instrument that acknowledges AI exists. Ask a stage-1 utility how many AI systems it operates and the honest answer is a shrug, because the question has no owner and no register to answer it from. That is not negligence; it is what happens when a technology arrives faster than the delegation of authority that governs it, which is the normal condition for the first two or three years.

The structural problem is default ownership. In a utility, every consequential act has an explicit holder of authority: a senior authorised person for switching, a responsible engineer for protection settings, an accountable officer for a safety case. When AI enters without an instrument, authority over it does not vanish — it falls, silently, to whoever built or bought the thing. A data scientist who chose a training window, a vendor who shipped a model inside a firmware update and a graduate who pasted an asset list into a chatbot are all, at stage 1, exercising decision rights nobody consciously granted them.

This stage is cheap to leave and expensive to occupy. The cost is not a dramatic failure; it is that nothing is portable. Every proposal restarts the argument about whether AI is allowed, because there is no prior decision to point at. Programmes at stage 1 spend most of their calendar in the pre-approval fog rather than in build, and they cannot say how long approval will take because no path exists to time.

Stage 2 is where most energy and utilities operators are, and it feels like a solved problem for about nine months. The charter is signed, the accountable executive is named, the register has forty entries and a classification scheme, and the first two deployments went through a committee that asked sensible questions. Everything about that is genuine progress, and it is why the stage is so sticky: the artefacts exist, so the governance box reads as ticked.

The structural weakness is that the instrument grants no standing authority. It says AI must be approved; it does not say by whom, against what evidence, within what timescale, or what happens on silence. So every deployment becomes a negotiation whose outcome depends on who is in the room. Two similar models get different answers. A proposal that would have passed in March fails in September because a different director chairs the meeting. Delivery teams learn, correctly, that the way to move fast is to avoid the committee, which is exactly how a chartered organisation grows an undeclared shadow estate underneath its register.

Time at stage 2 is not neutral. Each bespoke approval teaches the organisation that AI is slow, and that lesson gets priced into the next business case as a delay allowance. Operators who sit here for three years are harder to move than operators at stage 1, because the charter is now cited as evidence that governance is handled, and proposing a real approval path reads as criticism of a document a director signed.

Stage 3 is the first stage at which AI is governed the way the rest of the utility is governed. The decisive move is not a new committee — it is the opposite. The AI approval path is folded into the management-of-change process that already handles protection setting changes, control-room procedure updates and network switching programmes, so an AI change is reviewed by people who understand consequence and can say no with authority. Utilities that build a parallel AI governance track almost always end up with a well-documented track nobody in operations respects.

Two artefacts make the stage real. The first is the tiered submission standard: a Tier 1 grid-facing system needs a validation report, a limits statement, a monitoring plan and a rollback drill record, while a Tier 4 back-office assistant needs an owner and a data-handling declaration, and both standards are published so a delivery team can prepare before it asks. The second is the authority to operate — the written, bounded, dated permission that names what the system may affect, within what limits, held by a named individual. An ATO is what converts approval from an event into an ongoing accountable position, and its expiry date is what stops a 2024 decision governing a 2027 network.

The constraint that emerges at stage 3 is throughput. Every deployment still consumes a bespoke approval, so the governance function becomes the bottleneck at roughly the sixth or eighth live system. Programmes that miss this plateau spend a year adding approvals and wondering why the calendar stopped moving, and their engineers begin to describe governance as the reason nothing ships — which is, at this stage, accurate.

At stage 4 the object of approval changes. Instead of approving deployments one at a time, the organisation approves classes: retraining an existing Tier 3 model on the same data sources within stated performance bounds is pre-authorised; anything outside those bounds is an exception that escalates. That single shift collapses the governance queue, because the volume of work moves from the approval path to the exception path, and exceptions are rare by construction.

The discipline that makes delegation safe is measurement of the governance system itself. Three numbers matter: cycle time from submission to decision, exception rate as a share of changes made under standing authorisation, and evidence completeness across the live estate. A rising exception rate is the leading indicator that the world has moved outside the limits the authorisation was written against — new connections, a changed generation mix, a new customer segment — and it should trigger a review of the authorisation before it triggers an incident. Utilities already think this way about protection settings and operational limits; delegation for AI is the same instinct applied to a newer object.

The remaining constraint is external. Everything at stage 4 is internally coherent and internally verified, which is sufficient right up to the moment someone outside the organisation asks a question — a regulator reviewing a price-control submission, a safety body reviewing a filing, an auditor testing a control, a customer contesting a decision. The evidence usually exists at stage 4 and is usually assembled by a project. Stage 5 is where it stops being a project.

Stage 5 is narrower and less glamorous than it sounds. It is not autonomy and it is not a mature AI strategy. It is a management system for AI that an outsider can examine and form a view on — the same relationship a utility already has with its safety management system, its asset management system and its cyber compliance regime. The reference objects are public: ISO/IEC 42001 defines a certifiable AI management system, and the NIST AI Risk Management Framework organises the same territory around a GOVERN function that runs across everything else rather than sitting beside it.

The test that distinguishes stage 5 from a well-documented stage 4 is reconstruction. Choose a decision the AI influenced eleven months ago — a circuit that was prioritised, a connection study that was sequenced, a customer who was flagged — and rebuild it from the record: the input data as it stood, the model version, the thresholds in force, the authority under which it ran and the person who held it. If that takes an afternoon and no conversations, the system is assured. If it takes a team and a Slack archaeology dig, it is documented, which is a different thing.

Sustaining stage 5 is a maintenance discipline, and it is the stage most likely to regress. Authorisations expire, methodology documents fall behind the model, validation staff move on, and a filing that satisfied last year's reviewer does not satisfy this year's. The most reliable protection is that the evidence is generated by the operating process rather than assembled for the examination — which is also the only version that stays affordable as the estate grows.