Two reporting clocks start when an AI system fails in critical infrastructure

Among Swedish companies with at least 250 employees, 72 percent used AI during 2025. The figure comes from Statistics Sweden's compilation of AI statistics, published in May 2026, and rests on companies with at least ten employees in industry codes SNI 10 to 63, 68 to 82 and 95.1. The reporting is done by size class, so the figure describes the largest Swedish companies and not the energy sector. A larger utility with a control room, a customer service function and network planning nevertheless belongs to the size class where the share is highest.

For anyone running supply, the question is therefore not whether there is AI in the business. It is what happens the day one of those systems stops working, who has to be told, and how fast. Two frameworks meet there that were written independently of one another and that do not cross-refer a single time.

What the system does matters less than what breaks

On 27 July 2026 the AI omnibus regulation entered into force and inserted a new point into Article 6. It provides that for the purposes of the entire regulation, not only for classification under Article 6(1), AI systems used only for non-safety-related aspects of user assistance, performance optimisation, service efficiency, automation or convenience, or quality control, are not to be regarded as safety components. That point lifts a whole class of systems out of high-risk classification.

The sentence immediately after pulls the other way. Article 6(1b): notwithstanding point 1a, AI systems whose failure or malfunction would endanger health and safety are to be regarded as safety components. Two points in sequence, and the second tests something entirely different from the first.

The exemption asks what the system is used for. The sentence below it asks what breaks.

That matters out here, because point 2 of Annex III makes safety components in the management and operation of critical digital infrastructure, road traffic and the supply of water, gas, heating and electricity high-risk systems. The test in Article 6(1b) therefore decides which of your installations land in that point, and the test is applied to failure states rather than to a description of function. The date on which the high-risk requirements start to apply is a separate question, and it moved over the summer.

The clock starts in your control room

Article 73 of the AI Act places the reporting of serious incidents on the provider, who notifies the market surveillance authority. The general rule in Article 73(2) is 15 days at the latest.

Article 73(3) makes an exception to that general rule. In the event of a widespread infringement or a serious incident as defined in Article 3(49)(b), the report must be provided immediately and no later than two days. Article 3(49)(b) is in turn a serious and irreversible disruption of the management or operation of critical infrastructure. For a supply business, the two-day period is therefore not a special case but the normal outcome, and the fifteen-day period covers the incidents that do not concern operations.

Two details in the wording decide what that means in practice. The period runs from when the provider, or where applicable the deployer, became aware of the incident. The provider's two days therefore begin to run in your control room. And Article 26(5) places a duty on the deployer in its own right: a deployer that has identified a serious incident must immediately inform first the provider, and then the importer or distributor and the market surveillance authorities. The role is not to call the provider and then be finished.

Which authority is to receive that report in Sweden is described in the inquiry into adapting Swedish law to the AI Act, SOU 2025:101, which proposes the Swedish Post and Telecom Authority as market surveillance authority responsible for point 2 of Annex III.

The other clock has changed recipient

The Swedish cybersecurity act (2025:1506) entered into force on 15 January 2026. Under Chapter 2, section 5, a significant incident must be notified as soon as possible and no later than 24 hours after becoming aware of it. The incident report under section 6 is due within 72 hours for entities other than trust service providers, and the final report under section 8 within one month of the notification.

The recipient is not named in the act but in the cybersecurity ordinance (2025:1507), which in section 6 directs the reporting to the CSIRT unit designated in section 31. And section 31 has two versions. Until 30 June 2026, MSB was the CSIRT unit. From 1 July 2026 it is the National Defence Radio Establishment, following the consolidation of cyber operations at the National Cyber Security Centre. Under the same ordinance the supervisory authority for the energy sector is the Swedish Energy Agency.

An incident procedure written in the autumn of 2025 therefore names a different recipient from the one that receives today, and it does so in the document meant to work during the worst hour you will have. The sector is not otherwise lagging on the cyber side: ENISA's NIS360, third edition published in May 2026, describes electricity as the most mature of the subsectors covered by NIS2. That assessment rests, according to ENISA, on input from entities, national supervisory authorities and EU data, and sector positions are given in maturity bands rather than as measured values.

The two frameworks mean different things by the word incident

The cybersecurity act sets its threshold in Chapter 2, section 5, second paragraph: an incident is significant if it has caused or may cause serious operational disruption to the service provided or financial loss to the entity, or if it has affected or may affect other natural or legal persons by causing considerable damage. The AI Act's threshold for the two-day period is a different one: serious and irreversible disruption.

The difference is not academic. A four-hour outage that is fully restored is probably significant, but hardly irreversible. A model that has spent months writing systematically incorrect setpoints may have an effect that cannot be undone, without any single operational disturbance having occurred.

The same event can start one clock without starting the other.

That is why a shared assessment point is needed. An organisation that makes a threshold assessment per framework, in two different teams, will make them at different times, and one of the two has a single day to work with.

The duty is in the text before it bites

Here lies the objection to everything above, and it is a strong one. Article 73 sits in Chapter IX. The classification rules in Article 6 and the deployer's duties in Article 26 sit in Chapter III, Sections 1, 2 and 3, and the omnibus gave those sections the application date of 2 December 2027 for systems under Annex III. Chapter IX is not covered by that postponement. An organisation waiting for an authority to ask for the classification memo can therefore wait until the end of 2027 without breaching the high-risk requirements.

The counterweight is that the other clock is already running. The 24-hour deadline has applied since January, the recipient changed in July, and supervision of the energy sector sits with an authority whose job is to look. The incident procedure is also the document with the longest lead time of them all, because it has to be rehearsed and not merely written, and because it requires operations, security and legal to agree on a threshold before the alarm goes off.

The question that decides which of your systems this covers

The legislation's own question is whether a failure or malfunction would endanger health and safety. It can be put to every system you run, and it gives different answers in different businesses.

A load forecast that a planner reads and then acts on: no, both because the purpose is performance optimisation and because a person stands in between. A model that writes setpoints directly to the control system: yes, whatever it is called in the budget. Leak detection is the borderline case, and the answer turns on whether the alarm is the only thing standing between a discharge and exposure to it, or whether there is a protection system underneath.

Whoever answers that question has thereby also answered which reporting deadline applies, which threshold belongs in the incident procedure, and which systems need a documented intended purpose before December 2027. An organisation that has not written the purpose down cannot evidence its assessment in either direction, and it is that assessment, not the technology, that decides what will be required of you.