01
Protection tripping.
A system whose purpose is to cut supply before people or property are harmed: in scope, and rightly so.
THE INVERSION
Critical infrastructure got the opposite of what everyone expected.
Three things the fear-sellers won't tell you. First, the heavy rules only reach AI used as a safety component in the operation of supply, and the definitions explicitly exempt performance optimisation, service efficiency, automation and quality control.
Second, the fundamental rights impact assessment that hits other sectors explicitly does not apply to the critical-infrastructure category, and that exception holds even when the deployer is a municipal utility, because it follows the system's use, not your legal form. Third, registration for this category happens nationally, not in the EU database.
The sector everyone assumed would carry the heaviest burden got a lighter one. A supplier who hasn't read that far will sell you the burden anyway. And an operations team that postpones its maintenance analytics because someone scared them with the AI rules is losing money to a misunderstanding.
THE HONEST CLASSIFICATION
What is actually high-risk out here.
02
Leak detection with a safety purpose.
Identifying pipe breaks or gas releases to prevent exposure: likely in scope.
03
Load balancing and frequency control.
The genuine borderline. If the documented purpose is grid integrity, it leans in scope. If it is cost optimisation of balancing services, it leans out. The documentation decides.
04
Predictive maintenance.
Outside, as a rule: the purpose is service efficiency. The nuance sits at failures with direct safety consequences, and that nuance belongs in the documentation.
05
Load forecasting.
Outside. A support tool without a safety function.
THE EVIDENCE
Classification turns on the documented intended purpose. An energy company that cannot show a system's intended purpose cannot substantiate its classification, in either direction. Producing that evidence is a service, and it is ours: a classification memo per system that your board, your owner municipality and your auditor can hold.
INCIDENT REPORTING
Two clocks, one incident.
When an incident hits a high-risk AI system in your operation, two reporting chains start at once.
Sweden's cybersecurity act, which implements NIS2, requires an early warning within 24 hours. It goes to the CSIRT unit, which since 1 July 2026 is the National Defence Radio Establishment.
The EU AI Act runs the other way: the reporting duty sits with the system's provider. But the deadline is two days and not fifteen when the incident is a serious and irreversible disruption of the management or operation of critical infrastructure, which out here is the normal case. And it runs from when you became aware, not from when the case reached the provider.
Your own role does not end with calling the provider. Article 26(5) requires you to inform the market surveillance authorities yourself, and where the provider cannot be reached the reporting falls to you.
Different recipients. Different deadlines. Different definitions of what counts as an incident. And no mechanism in Swedish law coordinates them: the operator designs the coordination, or discovers the gap live.
That design is exactly our kind of work: one process across both clocks, with roles, thresholds and templates, developed together with your security function and handed over to the team that runs it.
WHAT WE DELIVER
Where the value is, and what to call it.
An honest distinction first. Much of what this sector is sold as AI is classic automation and sensor analytics: detection thresholds, control logic, statistical forecasting. Often that is exactly the right tool, cheaper and more reliable than any model, and telling you so is part of the job.
We evaluate those investments, classify them, and write the decision basis. Building and running them is your operational technology (OT) vendors' and engineering partners' craft, and we stay on your side of that table.
Where we deliver ourselves is the knowledge work around the operation, because that is where language-model AI actually earns its keep today: the regulatory reporting your team drowns in, drafted on your own data. Permit and tender documents. Board and owner reporting. Customer communication that answers before the phone rings.
Assistants on your own manuals, protocols and history. And the analysis layer this sector underuses: maintenance logs, outage histories and consumption data turned into decision bases, which assets to replace, where the losses sit, what the next investment should be. Built to production criteria, owned by your team at handover, fixed price.
One more efficiency worth naming: the governance this sector needs should plug into the security work you already run under the cybersecurity rules, not sit beside it in a second binder. One governance, both rulebooks.
WHAT TO DO, IN ORDER
What to do, in order.
01
Classify with evidence.
The AI Readiness Assessment inventories what you run and produces the documented purpose per system: the proof of what is in scope, and the proof of what is not.
02
Design the incident coordination.
One process across both clocks, developed with your security function, owned by your team.
03
Reuse your security machinery.
Governance built into the structures NIS2 already gave you, with named owners rather than binders.
04
Unfreeze the roadmap.
The projects a misunderstanding put on hold, with each investment called by its right name: automation where automation wins, AI where it earns its place.
Delivered for an operation that cannot stand still.
SwedaviaVarberg Energi
PROOF
Our work in this segment includes engagements with teams at Swedavia and Varberg Energi, alongside our delivery for Swedish public institutions. The consultant who leads your engagement is the person who delivered those.
QUESTIONS
Before you restart the projects.
Load forecasting is not normally a high-risk system under the EU AI Act: performance optimisation is explicitly exempted from the safety-component definition in Annex III point 2. The classification evidence is still worth producing, because the documented intended purpose is what proves the no if anyone asks. The high-risk requirements for Annex III apply from 2 December 2027, so the time to document it is now.
No, a grid owner does not need a fundamental rights impact assessment for systems in the critical infrastructure category. That category is Annex III point 2 of the EU AI Act, and it is explicitly excepted from the Article 27 duty, for every deployer, public and private alike. The exception follows the system's use and not the form of ownership, and it covers only that one duty: the remaining high-risk requirements still apply from 2 December 2027.
A municipal energy company that counts as a public body has until 2 August 2030 under Article 111(2) of the EU AI Act to bring existing Annex III systems into line with Chapter III. Private deployers have no equivalent transition period and follow 2 December 2027. Which side you land on is a judgement about the company's legal form, and we make it early in the AI Readiness Assessment.
A control room in an energy or water utility gets two reporting chains at once. Sweden's cybersecurity act, which implements NIS2, requires an early warning within 24 hours to the CSIRT unit, which since 1 July 2026 is the National Defence Radio Establishment. The EU AI Act puts the reporting duty on the provider, but the deadline is two days and not fifteen for a serious and irreversible disruption of the management or operation of critical infrastructure, and it runs from when you became aware. Article 26(5) also requires you to inform the market surveillance authorities yourself. Different recipients, different thresholds, and no coordination in Swedish law.
No, Ampliro does not build grid and control systems. We will not build the system that watches your pump, but give us its log file and you will know when to replace it. We deliver analysis and decision bases. For systems that watch and control we classify, write requirements, and sit on your side of the table facing the OT vendors. The classification itself is done in the AI Readiness Assessment.
No, a vendor's assurance does not discharge your own duties under the EU AI Act. Your deployer duties stay with you, and classification rests on the documented intended purpose. A sales slide is not documentation. No harmonised standards under the regulation have been published yet, so there is no presumption of conformity to lean on. We get the evidence in writing, from the vendor and into your files.
INSIGHTS
Recent analysis for this sector.
The rules
Who NIS2 covers in Sweden, and who decides it
NIS2 scope in Sweden is settled by six provisions, and the assessment rests on the operator itself. The size threshold moves in both directions, and essential or important answers another question.
Read the analysis
The rules
Who reports what when NIS2, DORA and the AI Act overlap
Sweden's Cybersecurity Act exempts firms covered by DORA from incident reporting altogether. The two cyber clocks therefore never start together, and what remains is the deadline nobody gave an outer limit.
Read the analysisClassify it. Prove it. Then build.
One conversation settles which of your systems actually sit in scope, what evidence proves it, and whether your incident process survives both clocks. If most of your list lands outside the heavy rules, you will have that in writing. And if classic automation beats the model, we will say so.