EN 18286 in AI procurement: what energy utilities should require from vendors
On 14 October 2026 the Commission published the reference of EN 18286 in the Official Journal. The standard covers the quality management of providers of high-risk AI, and nothing else. Grid operators, heat suppliers and their IT departments buy almost every AI system from vendors, and they are signing contracts right now that run past 2 December 2027.
EN 18286:2026 is the European standard for the quality management system that Article 17 of the AI Act requires from providers of high-risk AI systems; since its reference was published in the Official Journal on 14 October 2026 (Implementing Decision (EU) 2026/2274), it gives a presumption of conformity for the requirements it covers, and the high-risk obligations under Annex III apply from 2 December 2027. For energy utilities that buy AI and run it as deployers, the standard is not a list of their own duties but a question to put to the vendor. It is not proof about the delivered system: it covers Article 17(1) and the first sentence of Article 11(1) only, while the standards on risk management, logging and cybersecurity are still drafts. What deployers need for their Article 26 duties therefore belongs in the tender and the contract as a requirement: classification, instructions for use under Article 13, access to logs for at least six months, advance notice of model changes and incident reporting routes. German sector contracting entities refer to standards under Section 28 SektVO with the words "or equivalent". A utility that changes the name, the system or the purpose of a high-risk system becomes its provider under Article 25.
What happened on 14 October 2026
The AI Act got its first harmonised standard on 14 October 2026. That day the Official Journal carried Commission Implementing Decision (EU) 2026/2274, dated 12 October. Its annex has exactly one line: EN 18286:2026, "Artificial intelligence, Quality management system for EU AI Act regulatory purposes". It applies from the day of publication.
The standard itself was finished earlier. CEN-CENELEC published it on 30 July 2026. In law, though, only the citation counts: Article 40 of the AI Act presumes conformity only for standards whose reference sits in the Official Journal. On 14 October the standardisation committee CEN-CENELEC JTC 21 put it plainly: "Only that citation gives the standard legal effect under Article 40 of the AI Act."
So what does it cover? Less than "first harmonised standard" suggests. According to an analysis by Nico Schmidt of Intertek (29 September 2026), its Annex ZA maps the standard to Article 17(1), points (a) to (m), the building blocks of quality management, and to the first sentence of Article 11(1) on technical documentation. Article 17(2) to (4) are expressly not covered.
Everything else is missing. Several of the core drafts are being revised after their public enquiries, JTC 21 wrote on 14 October 2026, without naming them. Which ones, so far only the AI Standardisation Watch newsletter says (edition 16, as at 8 September 2026): there, risk management (prEN 18228), cybersecurity (prEN 18282) and logging (prEN 18229-1) failed their enquiries, and human oversight, prEN 18229-3, is listed as in enquiry until 22 October 2026. We found no public vote results from CEN-CENELEC. JTC 21 says the Commission's standardisation request runs until 28 February 2027.
A standard for providers, then, with a narrow reach. It will still land at utilities. Just somewhere else: in procurement.
Provider and deployer: who carries which duty
A utility that buys an AI system is, as a rule, its deployer under the AI Act. Provider means whoever develops the system or has it developed and places it on the market under its own name (Article 3(3)). Articles 16 and 17 put quality management, technical documentation, conformity assessment and the EU declaration of conformity on the provider. EN 18286 is the vendor's standard, not the Stadtwerk's.
Deployers have their own duties once a system is high-risk. Article 26 requires them to use it in line with the instructions for use, to assign human oversight to people with the competence and authority for it, to monitor operation and to report risks and serious incidents. Logs generated automatically must be kept for at least six months, to the extent they are under the deployer's control (Article 26(6)).
None of these deployer duties can be met without the vendor. No instructions, no use according to instructions. No log access, nothing to retain. When the system runs as a cloud service the logs live with the vendor, and whether the deployer "controls" them is decided by the contract.
How many systems at a utility are high-risk at all? Under the Commission's draft guidelines of 19 May 2026, AI falls under Annex III point 2 only if, as a safety component, it directly protects the physical integrity of an installation and its operator is designated a critical entity. Details are in our article on which AI at a utility is really high-risk. Load forecasts and customer service chatbots fall outside under the draft, and so do systems that only inform or optimise. Probably not many, then.
One point for the buyer: for high-risk systems under Annex III points 2 to 8, the provider carries out the conformity assessment under Article 43(2) through internal control, with no notified body involved. Nowhere does the AI Act ask for an "EN 18286 certificate". What counts as evidence is the EU declaration of conformity under Article 47, which the provider has to keep available for ten years.
When the utility becomes the provider
Article 25(1) names three cases in which a deployer takes on provider duties. It puts its own name or trademark on a high-risk system. It makes a substantial modification. Or it changes the intended purpose of a system so that it becomes high-risk. From then on, EN 18286 is its standard too.
The third case happens more easily than it sounds. A grid operator buys anomaly detection for after-the-fact analysis. Two years later, grid operations wire it into the control centre as the basis for switching decisions. Same code. Different purpose, and the role can flip with it.
The Digital Omnibus tightened exactly this point. Since Regulation (EU) 2026/1744, the original provider must give the new provider technical documentation sufficient for an assessment under Article 16, inform it about known limitations and failure modes, and grant targeted technical access, including for testing. Breaches of Article 25(2) and (4) now appear in the fines catalogue of Article 99(4), with a ceiling of 15 million euros or 3 percent of worldwide annual turnover.
There's a catch. That duty to cooperate falls away if the original provider has clearly specified that its system must not be turned into a high-risk system. If that sentence sits in the product documentation and a utility uses the system as a protective function anyway, it carries the provider duties alone. Procurement should find that sentence before signing.
Organisations with an approval route for AI catch the change of purpose there. Our AI governance building blocks describe what such a route looks like.
Nine requirements for tender and contract
What the vendor has to deliver belongs in the specification and the contract, not in renegotiation. Below: what a deployer needs for its own duties and how it can tell. It is a general overview for the role, not an assessment of your individual case.
| Requirement | Basis | What the vendor provides |
|---|---|---|
| Classification and intended purpose | Art. 6, Art. 25(2) | written classification with reasons; statement whether high-risk use is excluded |
| Quality management | Art. 17, EN 18286 | statement whether it works to EN 18286 or an equivalent system; for high-risk systems from 2 December 2027 the EU declaration of conformity (Art. 47) |
| Instructions for use | Art. 13 | performance limits, accuracy metrics, foreseeable misuse, oversight measures, maintenance |
| Logs | Art. 12, Art. 26(6) | access, storage location, export format, retention of at least six months |
| Changes to the model | Art. 13(3)(c), Art. 3(23) | pre-determined changes, notice period for new model versions, right to switch off new AI features |
| Human oversight | Art. 14, Art. 26(2) | means to intervene and stop, material for training oversight staff |
| Risks and incidents | Art. 26(5), Art. 73 | reporting routes both ways, contacts, response times |
| Use of data | GDPR, contract | no training on metering or customer data without a separate agreement, storage location |
| Cooperation on role change and supervision | Art. 25(2), KI-MIG | documentation and technical access if the utility becomes provider; support with Bundesnetzagentur requests |
Not every row fits every system. For a customer service chatbot the high-risk rows are usually empty, but the labelling duty under Article 50 applies, in force since 2 August 2026. For anomaly detection in the control centre, every row counts.
For systems that might have a protective function, the draft guidelines help. Deployers need not disclose their critical entity status to the vendor; they can require high-risk compliance through the procurement documents instead, as the law firm McCann FitzGerald summarised the draft on 2 June 2026. Convenient for procurement. Into the tender it goes, no explanation needed.
The Federal Network Agency (Bundesnetzagentur) has been the market surveillance authority for AI since 29 July 2026. What it may do is set out in our piece on KI-MIG and the Bundesnetzagentur. If it asks a deployer for information, the deployer needs the vendor's documents fast. A cooperation clause costs one sentence in the tender.
Procurement law: how sector entities may require standards
Many German municipal utilities and grid companies are sector contracting entities under Section 100 of the Act against Restraints of Competition (GWB): they carry out an activity in energy supply and are controlled by municipalities. From 432,000 euros for supplies and services, the EU threshold for 2026 and 2027, the Sector Procurement Ordinance (SektVO) applies.
Section 28(2) SektVO allows two routes: describe functional requirements, or refer to technical specifications in a fixed order, with national standards transposing European standards at the top. Every reference needs the words "or equivalent". A requirement such as "quality management to EN 18286 or equivalent" fits that grid.
Section 31 SektVO covers evidence. A contracting entity may ask for certificates from an accredited conformity assessment body, but has to accept equivalent certificates from other bodies. If a bidder has no access to such certificates through no fault of its own, a manufacturer's technical dossier counts too.
Our reading for practice: making an EN 18286 certificate mandatory is a bad idea right now. Under Annex III point 2 the AI Act provides for no third-party assessment at all, the market for such certificates is young, and shutting out good vendors costs more than a self-declaration with documents. Whether your organisation is a sector contracting entity and which procedure applies is for the procurement office to settle. Private utilities without that status are free, but "describe the function, treat the standard as one route" works there as well.
The EU model clauses: useful, but from 2025
There is a template for the contract clauses. On 5 March 2025 the Community of Practice on Public Procurement of AI published the updated EU model contractual clauses for AI procurement (MCC-AI): a full version for high-risk systems, a light version for everything else and a commentary, now in 24 languages.
Three caveats. The clauses are written for public organisations, and the commentary itself considers it inappropriate for others to adopt them wholesale, though individual clauses may be reused. They predate the Digital Omnibus, so the postponed high-risk dates and the sharper Article 25 are missing. And Tom Joseph of Crux Digits names a gap on 1 October 2026: there is no clause that keeps the buyer from being classed as a provider. "The MCC-AI have no equivalent."
For a Stadtwerk that buys under procurement law anyway, the MCC-AI are a quarry. Clauses on instructions for use, logs and human oversight carry over; the rest needs updating to the post-Omnibus text.
What a reference to the standard is worth in a contract
What does a reference to the standard give the buyer? Since publication, the voices have answered differently. We don't settle it here.
Nico Schmidt of Intertek wrote on 29 September 2026 that citation shifts the burden: "Once cited, a harmonised standard changes the evidential posture." An authority that challenges conformity then has more to show.
The same text adds that applying the standard "does not by itself ensure fulfilment of every regulatory requirement". The platform Reglog was blunter on 2 September 2026: "Do not describe yourself as "AI Act compliant" on the strength of a standard." The target there is vendors who advertise with the standard.
Tom Joseph of Crux Digits aims at the contracts themselves on 1 October 2026. A template, he writes, captures the law on the day it was drafted: "It is a snapshot, and it says so." JTC 21, for its part, announces more standards and names 28 February 2027 as the end of the standardisation request.
What utilities should do now
High-risk obligations apply from 2 December 2027, which is exactly why now is the moment. A multi-year contract signed today will be in its middle by then. Our AI regulatory matrix gives the overview of deadlines and roles.
Next steps in procurement
-
Review procurements in progress
List every open tender and contract that contains AI, including AI embedded in grid control, forecasting or customer service software. Mark those that run past 2 December 2027.
-
Agree a requirements catalogue
Procurement, IT, data protection and legal agree once on the rows of the table above. The catalogue becomes an annex to every tender with an AI component.
-
Ask the high-risk question
For systems with a possible protective function, ask about high-risk conformity and about any exclusion of high-risk use in the product documentation.
-
Tie changes of purpose to approval
New purpose, new data source, new model version: the case goes back for review. This is where the Article 25 role change arises, and where it can be prevented or decided on deliberately.
-
Track the standards
Once a quarter.
How we support utilities in setting up an AI register, an approval route and procurement rules is described on the page AI governance for energy utilities. More articles on the subject are collected in the topic AI in the energy industry.
This article gives a general overview of the standard and the legal position for typical roles at energy utilities. It is not legal advice and not an assessment of your individual case; whether a system in your organisation is high-risk and which procurement procedures apply is for your legal department or procurement office to determine. As of 17 October 2026.
Further reading
Frequently asked questions
EN 18286:2026 is the European standard for the quality management system that Article 17 of the AI Act requires from providers of high-risk AI systems. CEN-CENELEC published it on 30 July 2026, and the Commission published its reference in the Official Journal on 14 October 2026 with Implementing Decision (EU) 2026/2274. It is the first harmonised standard under the AI Act.
Not directly. The standard is addressed to providers. A utility that buys and operates an AI system has the deployer obligations under Article 26. The standard only becomes its own standard if the utility turns into the provider of a high-risk system under Article 25.
The AI Act does not require one. For high-risk systems under Annex III points 2 to 8, the provider assesses conformity under Article 43(2) through internal control, without a notified body, and issues an EU declaration of conformity. Applying the standard is voluntary; a provider that does not apply it has to show compliance with Article 17 another way.
Under Section 28(2) of the German Sector Procurement Ordinance (SektVO), technical specifications may refer to European standards, but every reference must carry the words "or equivalent". Under Section 31 SektVO, certificates from equivalent bodies and, in some cases, a manufacturer's technical dossier must be accepted. Whether an organisation is a sector contracting entity and which procedure applies is for its procurement office to establish.
Under Article 25(1) of the AI Act, in three cases: when it puts its own name or trademark on a high-risk system, when it makes a substantial modification to one, or when it changes the intended purpose of a system so that it becomes high-risk. The provider obligations under Article 16 then apply to the utility.
As a source for individual clauses, yes; as a finished contract, no. The current version of the MCC-AI dates from 5 March 2025, is written for public organisations and does not reflect the changes made by the Digital Omnibus in July 2026.
Let's collaborate
One contact, a team behind it
Thirty minutes on what you're working on, whether grid, metering, market processes, IT architecture or AI. Afterwards you'll know how we'd approach it and who would sit at the table.
Energy and measurement technology since 2010 · innobu GmbH since 2014 · Based in Schleswig-Holstein, Germany
Whoever pitches also delivers: whoever leads the first call stays your contact right through to the steering committee, with established partners in the project. Direct: info@innobu.com