EU AI Act for Energy & Utilities: Where the High-Risk Line Is Real (2026)
Grid-balancing and SCADA AI can be high-risk under Annex III point 2; back-office AI usually is not. The Articles 9-15 stack, NIS2 overlap and a worked example.
A grid operator's AI closes a control loop and sheds load automatically when a fault threatens frequency stability. That system is high-risk under the EU AI Act. The billing-analytics model is not. For most regulated sectors the argument is whether their AI is high-risk at all; for energy and utilities the regulation names the sector outright, so the question is operational, not theoretical. This guide draws the line system by system, walks the obligation stack for the systems that cross it, and maps the NIS2 overlap.
Annex III point 2 of Regulation (EU) 2024/1689 covers AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating and electricity. The sector is on the list by name. So the dividing question is not "are we an energy company?" — you are — but "is this specific AI system a safety component in the management or operation of supply?" Most AI in a utility is not. A critical minority is. The discipline is classifying each system against Article 6 and Annex III rather than treating the whole estate as one risk bucket. One deadline tension runs underneath it: the stand-alone Annex III timeline is in flux, covered in full at the end.
The two questions that decide classification
Classification under this route turns on two limbs, and a system has to satisfy both. Miss either, and Annex III point 2 does not apply.
What "safety component" means under Article 3(14)
Article 3(14) defines a safety component as a component of a product or system that fulfils a safety function, and whose failure or malfunctioning endangers the health and safety of persons or property. That is the gating concept — explained in full at /glossary/safety-component. It is a functional test, not a label: a system earns the description because of what its failure does, not where it sits on an org chart.
Annex III point 2 then requires the second limb on top: the AI must be a safety component and used in the management or operation of the supply of electricity, gas, heating or water (or critical digital infrastructure, or road traffic). Both, or neither.
Why most utility AI fails the safety-component test
This is the honest answer, stated plainly: a system that merely supports a utility is not a safety component and is generally not high-risk on this route. Billing analytics, customer-churn models, marketing optimisation, document search, demand forecasting for procurement — these do not fulfil a safety function in the operation of supply. Their malfunction costs money or annoys customers; it does not endanger persons or supply continuity in the Article 3(14) sense. Treat them as minimal-risk. The work is to find the few systems that genuinely steer the physical operation of the network.
The Article 6(3) non-high-risk filter — and why it is hard to rely on here
Article 6(3) offers a derogation: an Annex III system is not high-risk where it performs only a narrow procedural task, improves the result of a prior human activity, detects decision patterns without replacing human assessment, or is purely preparatory. A forecasting model that only feeds a human control-room decision can fit; a system genuinely steering grid stability in a closed loop rarely does. And the derogation never removes the Article 49 duty: a provider claiming non-high-risk status under Article 6(3) must still document that assessment and register the system before placing it on the market.
One boundary to keep clear: a general-purpose model fine-tuned into a grid tool is assessed as the high-risk system it is integrated into, not as a free-floating GPAI model. Do not conflate the two.
Grid and SCADA AI vs back-office AI: a classification map
The same neural forecasting model can be minimal-risk on a trading desk and high-risk inside a closed-loop SCADA control action. Intended purpose and the safety-function test decide it — not the algorithm. The table maps common utility AI use cases against where they sit, their likely classification, the governing route, and the trigger that decides each one.
| AI use case | Where it sits | Likely classification | Route | Deciding trigger |
|---|---|---|---|---|
| Automatic generation control / frequency regulation | SCADA / control room | High-risk | Annex III point 2 | Closed-loop safety function on supply |
| Automated load-shedding logic | SCADA protection layer | High-risk | Annex III point 2 | Acts on supply without human in the loop |
| Protection-relay decision logic | Substation OT | High-risk | Annex III point 2 | Failure endangers persons / continuity |
| DMS / EMS load forecasting | Control-room advisory | Grey zone | Annex III point 2 or Art 6(3) | High-risk only if it drives an automated action |
| Predictive maintenance (transformers) | Asset management | Grey zone → usually out | Art 6(3) | Advises a human; no safety loop |
| Outage prediction | Operations planning | Usually out | Art 6(3) | Informs, does not control |
| Wholesale energy trading model | Trading desk | Not high-risk | — | No safety function in supply |
| Demand forecasting for procurement | Commercial | Not high-risk | — | Commercial, not operational |
| Billing / metering analytics | Back office | Not high-risk | — | No safety function |
| Customer-service chatbot | Customer ops | Not high-risk | Art 50 transparency only | Interacts with people |
| Vegetation / asset-imagery analytics | Field operations | Not high-risk | — | Analytical, not control |
| Recruitment screening (field techs) | HR | High-risk | Annex III point 4(a) | Employment route, not point 2 |
The high-risk candidates are the systems embedded in the control layer: AI in automatic generation control or frequency regulation, AI-driven protection logic, and automated load-shedding inside SCADA — each fulfils a safety function whose malfunction endangers persons or supply continuity.
The grey zone is where Article 6(3) bites hardest: distribution-management-system (DMS) and energy-management-system (EMS) load forecasting, plus predictive maintenance. These are high-risk only if the output directly drives an automated safety action; if it informs a human who decides, the derogation opens.
The clearly-out rows matter for scoping. Trading, procurement forecasting, billing and metering analytics, asset-imagery work and HR tooling are not safety components in the operation of supply. Two caveats: the chatbot still owes Article 50 transparency, and the recruitment tool is high-risk — but under Annex III point 4(a) on employment, a different heading with its own obligation set, not point 2.
The Articles 9-15 obligation stack for high-risk energy AI
For the systems that land high-risk, classification is the start of the workload, not the end. Chapter III, Section 2 of Regulation (EU) 2024/1689 sets out the full stack; walking it shows the real cost of a control system that crosses the line.
Article 9 risk management and Article 10 data governance
Article 9 requires a continuous, iterative risk-management system maintained across the lifecycle — detailed at /eu-ai-act/article-9. It is especially demanding where a malfunction can destabilise supply, because the risk analysis has to account for cascading network effects, not the system in isolation. Article 10 layers data and data-governance requirements onto the training, validation and testing data — relevant where control models learn from years of telemetry.
Articles 11-12: technical documentation and automatic logging
Article 11 requires technical documentation with the content specified in Annex IV — design, development process, control logic, validation results. Article 12 requires automatic event logging over the system's lifetime. For a utility this dovetails with the telemetry SCADA and EMS platforms already record; the obligation is less about building new infrastructure than retaining and structuring what the operational-technology layer already captures.
Articles 13-15: transparency, human oversight, and accuracy/robustness/cybersecurity
Article 13 requires the system to be transparent enough that a deployer can interpret its output and use it appropriately. Article 14 human oversight is the linchpin for grid operators: the design must let a control-room operator understand, intervene in, and override the AI. That oversight feeds back into classification — a system built so an operator genuinely decides may have qualified for Article 6(3); a closed loop did not. Article 15 requires appropriate accuracy, robustness and cybersecurity, where the EU AI Act and the sector's existing operational-technology security regimes most obviously meet — the bridge into the NIS2 section below.
Allocate the obligations to the right actor. Vendors of grid AI are typically providers under Article 16, carrying conformity assessment and the heavier duties. The grid operator deploying the tool is typically a deployer under Article 26 — use per instructions, ensure oversight, monitor operation. But under Article 25, an operator that substantially modifies the system or markets it under its own name flips into provider status. The deeper treatment of this route sits at /annex-iii/critical-infrastructure-safety.
NIS2 and Critical Entities Resilience: coordinate, do not duplicate
Energy operators are essential entities under the NIS2 Directive and often critical entities under the Critical Entities Resilience Directive. These are separate instruments from Regulation (EU) 2024/1689: AI Act compliance does not satisfy them, and they do not satisfy the AI Act. Running them as two disconnected programmes is wasteful; the answer is one evidence base mapped to multiple regimes.
The genuine overlaps are worth exploiting. Article 15 cybersecurity expectations align closely with NIS2 risk-management measures, and Article 12 logging supports both AI-Act traceability and NIS2 incident-handling evidence. Build the log store once, map it twice.
The gaps are where NIS2 gives no shelter. Data governance (Article 10), human oversight (Article 14), the Annex IV technical documentation, and CE-marking and conformity assessment are AI-Act-specific. A utility with a mature NIS2 programme has covered perhaps a third of the high-risk AI obligation stack, not all of it.
Incident reporting runs on parallel tracks. Article 73 serious-incident reporting goes to the market-surveillance authority; NIS2 incident notification goes to the national CSIRT. A single grid malfunction caused by a misfiring control AI may trigger both — on separate timelines, to separate bodies. Map the triggers in advance so an incident does not become a reporting failure on top of an operational one.
Worked example: a regional DSO classifies its AI estate
Consider Verdalux Netze GmbH, a regional electricity distribution-system operator (DSO) in Lower Saxony — roughly 1,400 employees and around 900,000 connection points, an essential entity under NIS2. Its compliance lead inventories five systems:
- An AI module inside SCADA performing automated load-shedding under fault conditions.
- A DMS load-forecasting model that recommends switching actions to control-room operators.
- A predictive-maintenance model for distribution transformers.
- A customer-service chatbot.
- A recruitment-screening tool for field technicians.
The classification falls out cleanly once the safety-component test is applied per system. The automated load-shedding module is high-risk under Annex III point 2: a safety component acting in a closed loop on supply, its malfunction endangering continuity. The load-forecasting model and the predictive-maintenance model likely fall outside via Article 6(3) — each advises a human who decides, neither closes a loop — provided Verdalux documents that reasoning and the human decision is real, not nominal. The chatbot owes only Article 50 transparency. The recruitment tool is high-risk, but under Annex III point 4(a) — a different route with its own obligation set.
The obligation split follows. For the load-shedding module Verdalux is a deployer under Article 26 — unless it substantially modifies the vendor's tool and tips into provider status under Article 25, which its engineering team should check before any in-house change. It must run Article 14 oversight design at the control-room interface and feed the module's logs into both its Article 12 record and its NIS2 evidence base.
The sequencing lesson is the durable one. A one-line determination per system, dated and documented — "load-shedding module: high-risk, Annex III point 2, deployer"; "forecasting model: not high-risk, Art 6(3) advisory, registered under Art 49" — lets Verdalux defend its scoping to the market-surveillance authority later. That dated, rule-based determination is exactly the output Confir is built to produce.
How Confir helps
Energy and utilities face a sharper version of the classification problem than most sectors: the law names you, so the answer is never "we are out" wholesale — it is system by system, and the line between an advisory model and a closed-loop control action is where mistakes happen.
Confir's classification engine works each system through Article 6 and Annex III point 2 in sequence, applying the Article 3(14) safety-component test and the Article 6(3) derogation conditions as explicit rules. The intake surfaces the facts that decide it — does this AI close a control loop on supply, or does a human operator decide? — and produces a dated classification rationale a control-room engineer or a market-surveillance authority can follow and challenge. The engine is deterministic and rule-based — no model inference, no hallucination. Same inputs, same output.
For the systems that land high-risk, Confir structures the Article 11 and Annex IV technical documentation, tracks the Article 9 risk-management record, and keeps a Risk Register that holds a mixed estate — minimal-risk back-office AI alongside high-risk control AI — in one view, with role, route, and deadline visible per system.
Frequently asked questions
Is grid-balancing or SCADA AI automatically high-risk under the EU AI Act? No. It is high-risk only if it meets both limbs of Annex III point 2: the AI must be a safety component (Article 3(14)) and used in the management or operation of electricity, gas, heating or water supply. AI that closes a control loop on supply, such as automated load-shedding or frequency regulation, typically qualifies. A forecasting model that only advises a human control-room operator may fall outside, often via the Article 6(3) derogation. The deciding factor is the safety function and intended purpose, not the algorithm.
Is back-office or trading AI at a utility high-risk? Generally no. Wholesale energy trading models, demand forecasting for procurement, billing and metering analytics, asset-imagery analysis, and customer-service chatbots are not safety components in the operation of supply, so Annex III point 2 does not apply. They are usually minimal-risk. Two caveats: a customer chatbot still owes Article 50 transparency, and a recruitment-screening tool is high-risk — but under Annex III point 4(a) on employment, a different route with its own obligation set, not the critical-infrastructure heading.
What obligations apply once an energy AI system is high-risk? The full Chapter III Section 2 stack: Article 9 risk management, Article 10 data governance, Article 11 technical documentation per Annex IV, Article 12 automatic logging, Article 13 transparency to operators, Article 14 human oversight, and Article 15 accuracy, robustness and cybersecurity. For grid operators, Article 14 oversight is central — a control-room operator must be able to understand and override the system. Article 15 cybersecurity is where the AI Act most clearly meets a utility's existing operational-technology security obligations.
How does the EU AI Act interact with NIS2 for energy operators? They are separate regimes. Energy operators are essential entities under NIS2 and often critical entities under the Critical Entities Resilience Directive; compliance with one does not satisfy the other. There is genuine overlap — Article 15 cybersecurity aligns with NIS2 risk-management measures, and Article 12 logging supports both. But data governance, human oversight, Annex IV documentation and conformity assessment are AI-Act-specific. Incident reporting runs in parallel: Article 73 to the market-surveillance authority, NIS2 to the national CSIRT, on different clocks.
Is the grid operator or the AI vendor responsible for compliance? Usually both, in different roles. The vendor that develops and supplies grid AI is typically the provider under Article 16, carrying conformity assessment and CE marking. The operator deploying it is typically a deployer under Article 26, responsible for using it per instructions, ensuring human oversight, and monitoring. Under Article 25, an operator that substantially modifies the system or markets it under its own name becomes a provider and inherits the heavier obligations. Mapping each system to the right role early avoids gaps.
When do these obligations actually apply? Most grid and SCADA high-risk systems sit on the stand-alone Annex III route (Article 6(2)). The statute reads 2 August 2026, deferred to 2 December 2027 under the Digital Omnibus, now adopted — the European Parliament passed it on 16 June 2026 and the Council on 29 June 2026. Only publication in the Official Journal, expected before 2 August 2026, remains outstanding, as a formality; plan against the adopted 2 December 2027 date. AI embedded in Annex I products follows the separate 2 August 2027 timeline, deferred to 2 August 2028 under the same adopted Digital Omnibus.
What are the penalties for getting classification wrong? Breaches of high-risk obligations carry fines up to €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). Supplying incorrect or misleading information to authorities — for example, an indefensible Article 6(3) non-high-risk assessment — carries up to €7.5 million or 1% (Article 99(5)). Prohibited-practice breaches reach €35 million or 7% (Article 99(3)). Under Article 99(6), SMEs and start-ups are capped at the lower of the applicable amounts. Documenting each classification decision is the practical defence.
Deadlines, penalties, and what to do before the law settles
The stand-alone Annex III timeline is in flux
Most grid and SCADA high-risk systems sit on the stand-alone Annex III route under Article 6(2). The statute reads 2 August 2026. The Digital Omnibus is now adopted — the European Parliament passed it on 16 June 2026 and the Council on 29 June 2026 — so the deferral to 2 December 2027 for stand-alone high-risk Annex III is settled; only publication in the Official Journal, expected before 2 August 2026, remains outstanding, as a formality. The deferral is fixed calendar dates, and the standards-contingent "stop the clock" variant was rejected. Not everything is delayed.
The product-embedded route is separate. AI embedded in regulated products under Annex I via Article 6(1) follows 2 August 2027, deferred to 2 August 2028 under the now-adopted Digital Omnibus — relevant where energy AI sits inside a type-approved or other Annex I product rather than as a stand-alone control.
Penalty exposure under Article 99
Article 99 sets the ceilings. Non-compliance with high-risk and most other obligations carries up to €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). Supplying incorrect or misleading information to authorities — including an indefensible Article 6(3) self-assessment — carries up to €7.5 million or 1% (Article 99(5)). Prohibited-practice breaches reach €35 million or 7% (Article 99(3)). Under Article 99(6), SMEs and start-ups are capped at the lower of the applicable amounts.
A no-regret action plan for 2026
The work is identical whether the deadline lands in 2026 or 2027, so start now. Inventory every AI system. Apply the safety-component test per system, separating closed-loop control from human-advisory tooling. Document the Article 6(3) reasoning wherever non-high-risk status is claimed, and register under Article 49. Begin the Articles 9-15 evidence base for the systems that cross the line — risk register, Annex IV documentation, oversight design, logging mapped to NIS2. None of it is wasted either way.
Related guides
- Annex III point 2 and the safety-component doctrine
- how Article 6 classifies high-risk AI
- what counts as a safety component
- the Article 9 risk-management system
- the two routes to high-risk in manufacturing
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.
Start free trial →