When the EU AI Act Applies to Grid and Transformer AI, and When It Does Not

Two things changed in 2026 for anyone who builds or buys AI for power networks and transformer fleets. In July the Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the high-risk deadlines and rewrote the definition of a safety component. In May the Commission published its draft guidelines on how to classify high-risk systems, with a full section on critical infrastructure and a list of electricity examples on both sides of the line.

The result is a clearer test than the one most procurement questionnaires still use. Whether a system is “AI for the grid” settles nothing. What settles it is what the system is for, who uses it, and where its output goes. This guide walks through that test with the text of the regulation and the examples of the draft guidelines, which remain a draft until the final version, expected by the end of 2026.

What changed with the Digital Omnibus?

The Omnibus entered into force on 27 July 2026. It did not change the structure of the AI Act, but it moved the dates for high-risk systems and added a few obligations on a separate track. The dates below are taken from Article 113 of the consolidated text.

Power transformers are not among the products of Annex I, and the Omnibus moved machinery from section A to section B of that annex. For grid and transformer software the relevant route is Annex III, point 2, which covers AI systems “intended to be used as safety components in the management and operation” of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity.

Is the software an AI system at all?

The AI Act regulates AI systems, not software in general. The Commission’s guidelines on the definition (C(2025) 5053) and recital 12 of the Act exclude systems based on rules defined solely by people to execute operations automatically. A program that applies the thresholds of a standard, such as gas limits or oil acceptance values written by a committee, is in principle not an AI system on its own. Basic data processing and simple statistical estimates, such as a baseline built on past averages, can also fall outside it (paragraphs 46 to 51).

A machine learning model that estimates a condition score from laboratory data is an AI system, and so is an assistant built on a language model. Most real products mix the two. The draft classification guidelines (paragraph 75) say that when several components together serve one intended purpose, “split architectures are assessed as a whole”. Classification therefore starts from the product as the customer receives it, not from the module that happens to contain the model.

When is grid software a safety component?

This is where most of the answer lies. The Omnibus rewrote the definition in Article 3(14): a safety component is one that fulfils a safety function, or whose failure or malfunctioning endangers the health and safety of persons or property. A component fulfils a safety function when its intended purpose is to prevent or mitigate risks to health and safety.

Two new paragraphs of Article 6 frame the test. Paragraph 1a says that systems used solely for non-safety aspects of user assistance, performance optimisation, service efficiency, automation, convenience or quality control are not safety components. Paragraph 1b adds the counterweight: a system whose failure would endanger health and safety is a safety component anyway. The text opens with “For the purposes of this Regulation”, which suggests both paragraphs apply to Annex III as well, although some commentators read them as limited to regulated products. The final guidelines should settle it.

The draft guidelines then add a practical criterion for critical infrastructure. The question is whether the AI system “directly protects the physical integrity” of the infrastructure (paragraph 180), and systems that are “merely supportive, informational, organisational or optimisation-oriented” are excluded (paragraph 181). The availability of a redundant system that directly protects the infrastructure also counts (paragraph 186). On a transformer, that role belongs to the protection scheme: differential relay, Buchholz relay, pressure relief, overcurrent and temperature protection.

The examples for electricity are the most useful part of the draft. Here they are, side by side.

The last row shows the tension. Maintenance detection appears on both sides, and the difference is not the technology. It is whether the system is the layer that keeps people and equipment safe, or one precautionary input next to independent protection that would act anyway. The same holds for anomaly detection: it moves inside when it supports operational decisions on load, stability or shutdown, and stays outside when it enriches an operator’s planning.

Does it matter who the customer is?

According to the draft, yes. Paragraph 190 reads the reference to the Critical Entities Resilience Directive (EU) 2022/2557 so that an AI system is high-risk under point 2 “only if used by an entity identified as a critical entity by a Member State”. For electricity, paragraph 204 lists the entities concerned: supply undertakings, distribution and transmission system operators, producers, nominated market operators and market participants such as aggregators and storage operators. Member States had to identify their critical entities by 17 July 2026.

Two consequences follow. The same software can be high-risk for a designated transmission operator and outside the regime for a steel plant that runs its own furnace transformers, because the plant is not operating electricity supply. And the provider may never know: paragraph 191 notes that a critical entity does not have to disclose its status, and may simply require high-risk compliance in its tender documents. In practice, suppliers to large network operators should expect the question whatever their own reading.

A note for suppliers outside the EU market: the AI Act applies to systems placed on the market or put into service in the Union, and to systems whose output is used in the Union. A deployment that stays entirely outside the EU is generally out of scope.

Connectors do not decide, outputs do

A common worry is that connecting an AI system to SCADA, to online monitors or to a customer’s API makes it high-risk. The text does not say that. Read with the examples above, the test turns on two questions: in which direction the data flows, and what the output is used for.

For a provider, the practical rule is to keep the intended purpose explicit wherever it is stated. Article 3(12) defines the intended purpose through the instructions for use, the promotional and sales materials and the technical documentation. A product described as “condition assessment for maintenance planning” and marketed as something that “protects your transformer” sends two different messages, and an authority may read the second one. If an operational function is ever needed, building it as a distinct system with its own purpose, documentation and assessment is cleaner than letting it grow inside the planning tool. Paragraph 75 is the caveat: the separation has to be real in function and contract, not only on paper.

Online monitoring is the integration most likely to blur the line, because data arrives continuously and alarms are easy to add. Our guide to online condition monitoring of transformers covers the measurement side.

SaaS, APIs and language models: who is the provider?

Delivering a system as a service does not change the roles. The provider is whoever develops the AI system and places it on the market under its own name, including through an online interface or an API: the Commission’s guidelines on prohibited practices (C(2025) 5052) and on transparency (C(2026) 5054) treat cloud and API delivery as making the system available. The organisation that uses it under its own authority is the deployer.

The Omnibus added a useful tool for SaaS and white-label arrangements. Under Article 25(2), an initial provider must cooperate with anyone who turns its system into a high-risk one, handing over documentation and technical access, unless it “has clearly specified that its AI system is not to be changed into a high-risk AI system”. A sentence to that effect in the API terms and partner contracts limits what the original provider inherits.

For assistants built on a third-party language model, the Commission’s guidelines on general-purpose AI models (C(2025) 7719) separate the two layers. The company that integrates the model into its product is the provider of the AI system; the model’s developer remains the provider of the model (paragraph 55). The integrator becomes a model provider only by modifying the model with more than a third of the original training compute. Prompts, retrieval and rule-based checks do not modify the model. The integrator should still obtain the model provider’s documentation for downstream providers (Article 53(1)(b)).

What applies already, whatever the classification?

• AI literacy (Article 4). Since 2 February 2025, providers and deployers take measures to support the AI literacy of their staff and of others who operate the system on their behalf. The Omnibus wording does not require a guaranteed level for each person, and no certificate is required.
• Transparency (Article 50). Since 2 August 2026, people must be told when they interact with an AI system, unless it is obvious, and the output of generative systems must be marked in a machine-readable way. A diagnostic assistant that writes explanations in plain language is covered. Infringements can cost up to 15 million euros or 3% of worldwide turnover, whichever is higher; for SMEs, whichever is lower.
• Data protection. The GDPR applies to user accounts, logs and any free text sent to a language model.
• National rules. In Italy, Law 132/2025 requires professionals to inform clients about the AI systems they use, and Legislative Decree 179/2026, in force from 23 October 2026, sets the national authorities and penalties, with a national register at the cybersecurity agency ACN for high-risk systems in critical infrastructure.

Why the Article 6(3) exemption rarely helps

Article 6(3) lets a provider exempt an Annex III system that performs only a narrow procedural task, improves the result of a completed human activity, detects deviations from earlier decision patterns without replacing the human assessment, or performs a preparatory task. It looks like an easy exit for decision-support tools. The draft closes most of it for condition assessment: a system that produces “a specific recommendation or evaluation of the case” plays a decisive role and is not preparatory (paragraph 108).

Adding a human in the loop does not help either. Paragraph 71 states that a provider “cannot exempt and categorise an AI system as ‘low risk’ simply by adding to it a requirement for human involvement”. Human oversight is a requirement for high-risk systems, not a way out of the category. For grid software the classification is decided earlier, at the safety-component test.

What about systems already on the market?

Article 111(2) gives high-risk systems placed on the market before the application date a transition: they fall under the high-risk rules only if their design changes significantly after that date, with a deadline of 2 August 2030 for systems used by public authorities. For Annex III the date is 2 December 2027. This is not a loophole for new products, but it is a reason to document now the version, the intended purpose and the architecture of what is already in service.

Which standards exist today?

One. EN 18286:2026, the quality management system standard for the AI Act, became the first harmonised standard with Implementing Decision (EU) 2026/2274, published on 14 October 2026. The other European standards on risk management, logging, human oversight, accuracy, cybersecurity and data quality are still drafts in CEN-CENELEC JTC 21, and according to public tracking several failed their first enquiry. Presumption of conformity for those requirements is unlikely before 2027.

For systems outside the high-risk category the standards are voluntary, but they are worth using. They document diligence if a classification is challenged, they prepare a product in case the final guidelines move the line, and network operators are likely to ask for them in tenders. ISO/IEC 42001 and ISO/IEC 23894 are not harmonised but give a recognised structure that fits with EN 18286.

A checklist for providers of grid and asset software

• Write the intended purpose of each AI system in one versioned page, and use the same wording in the terms of use, the instructions, the reports and the website.
• Map where each output goes: to a person for planning, to another system, or into the operation of the grid.
• List the independent protection that acts if your system fails, and check that your marketing never presents the system as that protection.
• Find out whether your customers operate electricity supply and could be critical entities, and expect tender questions either way.
• Put the Article 25(2) statement in API terms and partner contracts.
• For assistants built on language models, add the Article 50 notices, collect the model provider’s documentation and fix the model version you test.
• Record the classification assessment with its date, and plan a review when the final guidelines are published.

The free AI Act Check for Grid and Asset AI walks through these questions and lists the duties that apply, with their dates.

Validation is the other half of the file an authority or a customer will ask for. Our guide on how to validate an AI transformer health assessment covers the evidence a buyer should expect.

This guide explains the regulation and the Commission’s draft guidelines. It is not legal advice on a specific system.

Sources

• Regulation (EU) 2026/1744 (Digital Omnibus on AI), Official Journal of 24 July 2026.
• Regulation (EU) 2024/1689 (AI Act), EUR-Lex, consolidated text of 27 July 2026.
• European Commission, draft guidelines on the classification of high-risk AI systems, 19 May 2026.
• European Commission, guidelines on the definition of an AI system, C(2025) 5053, and on prohibited AI practices, C(2025) 5052, July 2025.
• European Commission, guidelines on the scope of obligations for general-purpose AI model providers, C(2025) 7719, November 2025.
• European Commission, guidelines on transparency obligations under Article 50, C(2026) 5054, July 2026.
• Directive (EU) 2022/2557 on the resilience of critical entities, EUR-Lex.
• Commission Implementing Decision (EU) 2026/2274 on EN 18286:2026, Official Journal of 14 October 2026.