AI som minskar risken för BESS-avbrott och miljonförluster

En enda störning i ett batterilager på 100 MW kan enligt ny branschresearch motsvara cirka 1,2 miljoner US-dollar i förlorade intäkter per månad. Det är en siffra som får CFO:er att spetsa öronen – men den borde också få riskchefer, cybersäkerhetsansvariga och försäkringsbolag att titta upp från sina modeller.

För här finns en missuppfattning som jag ofta stöter på: att batterilager (BESS, Battery Energy Storage Systems) främst är en teknisk fråga för driftteamet. Nej. BESS är numera kritisk infrastruktur i elsystemet – och kritisk infrastruktur handlar alltid om risk, ansvar, försäkringsbarhet och resiliens.

Det här inlägget är en del av vår serie ”AI inom försäkring och riskhantering”, och jag vill koppla ihop tre saker som annars hamnar i varsin silo: driftsäkerhet, cybersäkerhet och AI-driven riskstyrning. För i praktiken är det samma sak: att minska sannolikheten för avbrott och att begränsa konsekvensen när något går fel.

Varför ett BESS-avbrott blir en försäkringsfråga

Ett BESS-avbrott är inte bara ”nedtid”. Det är ofta en kedja av händelser som snabbt blir dyr.

På intäktssidan handlar det om utebliven ersättning från stödtjänster, arbitrage, kapacitetsmarknader eller lokala flexibilitetsaffärer. På kostnadssidan kan det handla om extra inköp, kontraktsbrott, startkostnader, förlorad kundtillit och i vissa fall även regulatoriska följder.

För försäkring och riskhantering blir BESS särskilt intressant av tre skäl:

1. Hög kapitalintensitet: Ett nätanslutet batterilager är dyrt och avskrivningstungt.
2. Komplex skadebild: Skada kan vara allt från mjukvarustörning till termisk incident och permanent komponentförlust.
3. Cyber som möjlig skadeorsak: Avbrott kan vara ett ”vanligt fel” – eller resultatet av en riktad attack.

När branschaktörer bedömer att permanent skada kan ge kapitalförluster som är mer än tio gånger intäktsbortfallet, då pratar vi om risknivåer som påverkar både premier, villkor och underwriting.

Standardisering gör intrång enklare – det är inte en paradox

Marknaden strävar efter standardiserade BESS-lösningar för att pressa kostnader. Det är rationellt. Men standardisering innebär också att angripare kan skala sin metod.

När många anläggningar har liknande:

• kommunikationsprotokoll
• fjärråtkomstlösningar
• styrsystem och HMI
• leverantörskedjor och uppdateringsrutiner

…då blir en framgångsrik attack återanvändbar. Och idag finns dessutom skadeprogram som är byggda för industriella styrsystem (ICS), vilket gör att barriären sjunker ytterligare.

Hotbilden 2025-12: från leverantörskedja till driftmiljö

Det mest användbara budskapet i den research som lyfts i branschen är egentligen inte dollarsiffran. Det är att cybersäkerhet i BESS måste byggas in tidigt – i design, byggnation och driftsättning – annars hamnar man i dyra efterhandslösningar.

Leverantörskedjan: när du inte får titta under huven

En konkret risk som återkommer är komponenter och mjukvara från leverantörsled där operatören inte fullt ut kan:

• inspektera firmware och binärer
• verifiera uppdateringskedjan
• styra åtkomst och loggning
• ställa krav på transparens och spårbarhet

I vissa avtal begränsas insynen, vilket gör att riskägaren i praktiken tar ansvar för en miljö som inte går att kontrollera.

Det här är exakt den typ av problem som försäkringsbolag brukar reagera på: oklara kontrollpunkter och svårt att bevisa ”rimliga skyddsåtgärder” efter en incident.

Nätverksarkitektur: små genvägar blir stora hål

BESS är inte bara ”en stor batteribox”. Det är ett ekosystem: EMS, SCADA, gateways, mätning, kommunikation mot aggregatorer, ibland molntjänster och leverantörers fjärrsupport.

Varje extra integration ger affärsvärde, men också en ny angreppsyta. En bra tumregel i riskarbetet är:

Ju fler system som kan styra eller påverka dispatch, desto mer behöver du behandla BESS som ett styrsystem – inte som IT.

Där AI faktiskt gör nytta: från brandkårsutryckning till prediktion

AI hjälper inte för att det är ”modernt”. AI hjälper för att BESS producerar stora mängder data som människor och traditionella regler inte hinner tolka i tid.

Jag brukar dela upp nyttan i tre nivåer: prediktion, detektion och beslutsstöd.

Prediktivt underhåll: fånga fel innan de blir avbrott

Prediktivt underhåll med maskininlärning bygger på att du hittar svaga signaler i driftdata innan ett fel eskalerar. För BESS kan det handla om:

• cell-/modultemperaturer och avvikelser per rack
• spänningsspridning och obalanser
• degraderingsmönster (SoH) och intern resistans
• kylsystemets beteende (flöde, delta-T, kompressorcykler)
• larmfrekvens och ”nästan-larm” som aldrig triggar hårda larm

Praktisk effekt: du minskar sannolikheten för en oplanerad outage och kan planera service när intäktsförlusten är lägst.

AI för cyberdetektion i OT-miljö: anomalier som betyder något

I OT/ICS-miljöer är det sällan hjälpsamt att bara ”samla mer loggar”. Det viktiga är att kunna upptäcka avvikande beteenden som är relevanta för styrning och säkerhet.

AI-modeller (ofta en kombination av statistiska metoder och ML) kan flagga:

• ovanliga kommandosekvenser (t.ex. förändrade setpoints utanför driftmönster)
• fjärrsessioner på udda tider eller från nya noder
• förändringar i kommunikationsmönster mellan SCADA och lokala controllers
• avvikande firmware-/konfigurationssignaturer

Det här är extra värdefullt när angripare använder ”living off the land”-metoder: legitima verktyg, legitima protokoll, men fel beteende.

Beslutsstöd: när driftoptimering och säkerhet krockar

BESS körs ofta hårt för att maximera intäkter. Men aggressiv dispatch kan öka termisk stress och degradering. Samtidigt kan överdriven säkerhetslåsthet göra anläggningen svår att drifta.

AI kan hjälpa genom att ge operativa rekommendationer som balanserar:

• intäkt (marknadspris, stödtjänstbehov)
• teknisk hälsa (SoH, termiska marginaler)
• cyberrisk (åtkomstläge, pågående avvikelse, patchnivå)

Det är här kopplingen till riskhantering blir tydlig: du kan sätta en riskbudget och låta systemet optimera inom den.

Så bör riskteam och försäkringsbolag tänka om BESS-cyber

Om du arbetar med riskbedömning, underwriting eller internkontroll är målet inte att bli batteriexpert. Målet är att ställa rätt frågor – och få svar som går att verifiera.

En enkel kravbild som fungerar i verkligheten

Här är en checklista jag tycker är rimlig och praktiskt användbar (utan att kräva perfektion från dag 1):

1. Segmentering och minsta privilegium
   • OT-nätet separerat från IT
   • tydliga zoner för SCADA/EMS, gateways, fjärråtkomst
2. Kontrollerad fjärråtkomst
   • tidsbegränsad åtkomst, MFA, loggning
   • inga ”permanenta supporttunnlar” utan ägarstyrning
3. Supply chain-verifiering
   • krav på SBOM eller motsvarande transparens
   • uppdateringskedja som går att granska
4. Övervakning med tydliga åtgärdsplaner
   • det räcker inte att ”se” anomalier; vem agerar, inom vilken tid?
5. Resiliens och återstart
   • testade rutiner för isolering, fallback och återdriftsättning

Det här är också en bra bas för försäkringsdialog: kontrollpunkter som går att koppla till villkor, självrisk och premier.

Vad betyder 1,2 miljoner US-dollar i svensk kontext?

Du behöver inte översätta valutan exakt för att förstå poängen. Siffran visar storleksordningen: även ett ”medelstort” BESS kan ha ett intäktsbortfall som snabbt når nivåer där:

• en månads outage blir ett styrelseärende
• incidenten påverkar lånevillkor och covenants
• försäkringsgivaren kräver mer dokumentation och hårdare krav

Och runt årsskiftet 2025-12 / 2026-01, när många organisationer sätter nya budgetar och riskplaner, är det här ett bra tillfälle att flytta cybersäkerhet i BESS från ”projektfråga” till portföljrisk.

Vanliga frågor jag får (och raka svar)

”Är det här främst ett tekniskt problem eller ett affärsproblem?”

Det är ett affärsproblem med tekniska orsaker. Intäktsmodellerna för BESS bygger på hög tillgänglighet. Cyber och driftstörningar attackerar direkt den förmågan.

”Behöver vi AI, eller räcker traditionella larm och regler?”

Traditionella larm räcker för mycket, men de är svaga på mönster som byggs upp över tid och på okända attacker. AI är mest värdefullt när du vill gå från reaktivt till proaktivt.

”Vad ska vi mäta för att visa förbättring?”

Mät sådant som kopplar till både drift och risk:

• oplanerad nedtid (timmar/månad)
• antal avvikelser som fångas före outage
• patch-/konfigurationscompliance
• MTTR (mean time to recovery) efter incident

Nästa steg: gör AI till en del av riskkontrollen, inte ett pilotprojekt

BESS kommer att fortsätta växa snabbt internationellt, och när kapaciteten närmar sig traditionella kraftverks nivåer blir kraven på robusthet hårdare – från marknad, myndigheter, investerare och försäkringsgivare.

Min tydliga ståndpunkt: om ni bygger eller förvaltar batterilager utan att integrera AI-baserad övervakning och prediktion tidigt, så skjuter ni en kostnad framför er. Den kommer tillbaka som driftstörning, retrofitting, högre försäkringspremier eller sämre finansieringsvillkor.

Vill du ta ett första, pragmatiskt steg? Börja med att definiera en gemensam målbild för drift, IT/OT-säkerhet och risk/underwriting: vilka data ska finnas, hur ska de användas, och vilka beslut ska de leda till. När det sitter blir frågan intressant på riktigt: hur mycket av de där 1,2 miljonerna per månad tänker ni acceptera som ”normalt brus”?