AI-drevne sårbarheter krymper patch-vinduet til minutter

Nøkkelpunkter per 27. oktober 2026:

• 87 prosent av lederne i en global undersøkelse peker på AI-relaterte sårbarheter som den raskest voksende cyberrisikoen gjennom 2025 (World Economic Forum, 2026).
• Angrepskoden kom dagen etter: utnyttelsesforsøk mot to kritiske PHP-hull ble observert under et døgn etter at oppdateringen var publisert (Digi.no).
• Patch-sykluser i uker er ute. For kritiske eksponeringer bør virksomheter jobbe mot sykluser målt i dager, ikke uker eller måneder (EY, 2026).
• 77 prosent av organisasjonene bruker allerede AI i cyberforsvaret, mest til phishing-deteksjon og anomalirespons (World Economic Forum, 2026).
• Telenor oppgir at de i verste fall har minutter til å agere, mot timer og dager tidligere (Teknisk Ukeblad).

---

Hva som faktisk er nytt med AI-drevne sårbarheter

Sårbarheter i programvare er ikke noe nytt. Det nye er tempoet i hele kjeden: hvor fort hull blir funnet, hvor fort de blir gjort om til fungerende angrepskode, og hvor kort tid du har mellom at en oppdatering kommer og at noen banker på døren din. 87 prosent av respondentene i en global lederundersøkelse oppgir at AI-relaterte sårbarheter var den raskest voksende cyberrisikoen gjennom 2025 (World Economic Forum, 2026).

Samme undersøkelse viser at 94 prosent mener AI blir den viktigste driveren for endring i cybersikkerhet det kommende året. For en norsk SMB er det likevel ikke prosentene som gjør vondt. Det er kalenderen: hvem har vakt, hvem kan bestemme nedetid, og hva skjer hvis varselet kommer en fredag ettermiddag.

Maskinen leser kode raskere enn mennesker klarer

Det tekniske skiftet er lettere å forstå enn man tror. AI-systemer kan resonnere på tvers av programvare og kombinere flere funn med lav og middels alvorlighetsgrad til troverdige ende-til-ende-kompromisser på minutter eller timer (EY, 2026). Risikobildet ditt er altså ikke lenger summen av enkeltfunn i en skannerapport. Det er alle måtene de små funnene kan settes sammen.

Konsekvensen merkes allerede i norsk drift. Telenor sier de har måttet lappe systemer flere ganger det siste året etter at AI-verktøy oppdaget sårbarheter, og at de i verste fall har minutter til å agere mot timer og dager før (Teknisk Ukeblad). Når en av landets største tekniske driftsorganisasjoner beskriver det slik, er det lite grunn til å tro at en bedrift med to IT-ansvarlige har bedre marginer.

Hull som har ligget i koden i tjue år

Den mest ubehagelige delen er ikke at ny kode har feil. Det er at gammel kode har hatt feil hele tiden. De to kritiske PHP-sårbarhetene som stengte ned norske nettsteder i oktober, hadde ligget i koden i mer enn ti år, kanskje over 20 år, og ble funnet ved hjelp av AI-verktøy (Digi.no). Alle revisjoner, alle penetrasjonstester og alle kodegjennomganger i den perioden gikk forbi dem.

Det samme mønsteret dukker opp på forsvarssiden. Epic, leverandøren som indirekte håndterer 325 millioner pasienter på verdensbasis, brukte en AI-modell til å analysere egne systemer og fant at enkelte oppsett kunne gi tilgang til sensitive pasientjournaler (Teknisk Ukeblad). Selskapet satte alt utviklingsarbeid på vent i seks uker for å rette opp. Det er prisen når du finner noe selv, med god tid. Alternativet er å finne det samtidig som angriperen.

Begge sider har fått samme verktøy

Debatten om AI i sikkerhet blir ofte fremstilt som et fremtidsspørsmål. Det er den ikke. 77 prosent av organisasjonene har tatt i bruk AI for cybersikkerhet, og Epic-eksempelet viser at de samme modellene som finner hull for angripere også finner dem for eiere (World Economic Forum, 2026). Teknologien er distribuert. Det som skiller virksomheter er hva de gjør med den.

Alura mener at AI allerede brukes bredt i forsvaret, og at spørsmålet for norske bedrifter derfor er rutiner og ansvar, ikke om teknologien finnes. Den diskusjonen er en modenhetsdiskusjon, ikke en innkjøpsdiskusjon. Hvis du vil se hvor din organisasjon faktisk står før du kjøper verktøy, start med en nøktern gjennomgang av AI-modenhet i egne prosesser.

PHP-hullene som ble utnyttet under et døgn

Hendelsen i oktober er den beste norske caseen vi har på hva det nye tempoet betyr i praksis. Den er verdt å gå gjennom i detalj, fordi hvert steg i tidslinjen svarer på et spørsmål du må ha avklart i egen virksomhet.

To hull, fjernkjøring uten autentisering

Det ble funnet to kritiske sårbarheter i PHP som åpnet for fjernkjøring av kode uten autentisering (Digi.no). Uten autentisering betyr at angriperen ikke trenger brukernavn, passord eller en stjålet nøkkel. Fjernkjøring av kode betyr at angriperen kan kjøre sine egne kommandoer på serveren din. Kombinasjonen er den alvorligste klassen av sårbarhet som finnes, og PHP ligger under en betydelig del av nettet.

Responsen i Norge var å trekke ut stikkontakten. Nettstedene til Digitaliseringsdirektoratet, OsloMet og Feide ble stengt ned (Teknisk Ukeblad). Det er en rasjonell avgjørelse når alternativet er ukontrollert eksponering, men den er bare rasjonell hvis noen har myndighet til å ta den raskt.

Angrepskoden kom dagen etter

Allerede dagen etter at nyheten var ute, fantes det angrepskode som utnyttet sårbarheten (Teknisk Ukeblad). Sikkerhetsmiljøer observerte forsøk på å utnytte hullene under et døgn etter at PHP-prosjektet publiserte sikkerhetsoppdateringene (Digi.no). Det er hele vinduet ditt: fra patchen er tilgjengelig til noen tester den mot deg gikk det mindre enn en arbeidsdag.

Cybersikkerhetsselskapet Mnemonic har registrert angrep knyttet til sårbarhetene, og ser trafikk mot norske virksomheter fra infrastruktur knyttet til bekreftede utnyttelsesforsøk (Digi.no). Måten forsøkene er gjennomført på tyder dessuten på at flere ulike aktører står bak. Dette er altså ikke en målrettet kampanje mot noen få store navn, men bredt maskinelt søk etter alt som svarer.

Noen var i gang før offentliggjøringen

Den detaljen som bør endre planleggingen din, er denne: noen observasjoner av utnyttelsesforsøk strekker seg tilbake til 17. oktober, altså før sårbarhetene ble offentliggjort (Digi.no). Varselet ditt er ikke starten på angrepet. Det er beskjeden om at angrepet kan ha pågått en stund.

Halen etterpå er like talende. Etiske hackere anslo at minst 21.500 danske sider fortsatt var sårbare etter at patchen var tilgjengelig (Teknisk Ukeblad). Patchen eksisterte. Nyheten var over alt. Likevel sto tusenvis av nettsteder åpne, fordi ingen hadde en rutine som gjorde noe med informasjonen.

---

Les også: Tolv AI-agenter per bedrift endrer CRM for norske SMB-er. Organisasjoner kjorer i snitt tolv AI-agenter, og adopsjonen ventes a oke 67 prosent pa to ar.

---

Fra årlig sikkerhetsprosjekt til løpende drift

De fleste SMB-er håndterer sikkerhet som et prosjekt. Man kjøper en penetrasjonstest, får en rapport, lukker de verste funnene, legger rapporten i en mappe og kommer tilbake til temaet neste år. Den modellen var alltid litt for treg. Mot et angrepstempo målt i timer er den ikke lenger en modell, bare en følelse av kontroll.

Alura mener at sårbarhetshåndtering hører inn i den daglige driften, ikke i et årlig sikkerhetsprosjekt. Det er ikke et sikkerhetsfaglig standpunkt så mye som et driftsfaglig: oppgaver som oppstår daglig kan ikke løses av prosesser som kjører årlig.

Hvorfor årshjulet svikter

Et årlig prosjekt svikter på tre punkter samtidig. Det gir et øyeblikksbilde av en beholdning som endrer seg hver uke. Det gir ingen eier mellom prosjektperiodene, så varsler havner i en innboks ingen har ansvar for. Og det gir ingen innøvd beslutningsvei, så når noe faktisk skjer må virksomheten improvisere mens klokka går.

EY beskriver den nye forventningen tydelig: virksomheter må kunne demonstrere hvordan konkrete sårbarhetsfunn identifiseres ved hjelp av flere skannere og verktøy, prioriteres raskt og håndteres i tide (EY, 2026). Ordet som gjør jobben her er demonstrere. Det holder ikke å mene at man er flink.

Nedetid er en beslutning du tar på forhånd

Dilemmaet mellom oppetid og sikkerhet er reelt, og det blir ikke borte av gode intensjoner. Når PHP-hullene traff, var svaret flere steder å stenge ned tjenester helt (Teknisk Ukeblad). Spørsmålet er ikke om du noen gang vil stå i det valget. Spørsmålet er om du vil ta det valget med ledergruppen samlet, eller alene klokka 23.

Alura mener at når utnyttelsesforsøk kommer under et døgn etter en patch, må beslutningen om nedetid være tatt på forhånd, ikke under angrepet. Konkret betyr det en skrevet setning som sier hvilke tjenester som kan tas ned uten ny godkjenning, hvem som kan utløse det, og hvem som varsler kunder. Den setningen er billigere å skrive i dag enn å improvisere senere.

Rammeverk for kontinuerlig sårbarhetshåndtering

Et rammeverk for en SMB må være lite nok til å faktisk brukes. EY peker på fem områder virksomheter bør styre på: sårbarhetsstyring, patch-styring, sikker programvareutvikling, leverandørrisiko og penetrasjonstesting (EY, 2026). Oversatt til en bedrift med femti ansatte handler det om beholdning, varsling, prioritering, gjennomføring og dokumentasjon.

Område	Hva det betyr i en SMB	Hvem eier det
Sårbarhetsstyring	Oppdatert liste over systemer, versjoner og eksponering mot internett	IT-ansvarlig
Patch-styring	Fast vindu, definerte hastegrader, dokumenterte unntak	IT-ansvarlig, med fullmakt fra ledelsen
Sikker utvikling	Krav til egne og innleide utviklere om avhengigheter og gjennomgang	Produkt eller teknisk leder
Leverandørrisiko	Programvareleverandører vurdert som kritiske leverandører	Innkjøp, sammen med IT
Testing	Jevnlig ekstern testing, ikke bare ved revisjon	Daglig leder beslutter omfang

Beholdning: du kan ikke patche det du ikke vet om

Første trinn er kjedelig og avgjørende. Du trenger en liste over hva du faktisk kjører: servere, nettsteder, API-er, integrasjoner, SaaS-tjenester med tilgang til dine data, og hvilke versjoner de ligger på. De 21.500 danske sidene som fortsatt sto sårbare etter patchen var sannsynligvis ikke resultat av en bevisst risikovurdering (Digi.no). De var glemt.

EY-materialet refererer en studie som anslår at 36 prosent av eiendelene i organisasjoner er sårbare for cybersikkerhetstrusler (EY, 2026). Du kan diskutere metoden, men retningen er klar: andelen er høy nok til at «vi har oversikt» bør bevises, ikke antas. Listen skal ha en eier og en dato.

Varsling og triage: alvorlighetsgrad er ikke hast

Mange blander sammen to ting: hvor alvorlig en sårbarhet er i teorien, og hvor fort den må håndteres hos deg. En kritisk sårbarhet i et system som ikke er eksponert mot internett kan vente til neste vindu. En middels alvorlig sårbarhet i en åpen tjeneste med kundedata kan ikke. Det er eksponering ganget med verdi som bestemmer rekkefølgen.

Her gjør AI-dimensjonen en reell forskjell i vurderingen. Når modeller kan kjede sammen flere mindre funn til et fullverdig kompromiss på timer, kan du ikke lenger skyve en samling middels funn til neste kvartal fordi ingen av dem er røde alene (EY, 2026). Vurder kombinasjoner, ikke bare enkeltlinjer.

Gjennomføring: vinduet, rullebanen og rollback

Et patch-vindu som bare eksisterer på papiret kollapser første gang det er travelt. Det som gjør det robust er tre ting: et fast tidspunkt alle kjenner, en rekkefølge som starter i test og ender i produksjon, og en dokumentert vei tilbake hvis oppdateringen knekker noe. Frykten for at patchen skal ta ned driften er den vanligste grunnen til at patching utsettes, og rollback-planen er svaret på den frykten.

Legg også inn en hurtigbane. Den brukes når noe oppfyller to kriterier samtidig: aktiv utnyttelse observeres i markedet, og systemet er eksponert. Da gjelder ikke det ordinære vinduet. Mnemonics observasjoner viser at utnyttelse kan være i gang før offentliggjøring, så hurtigbanen må kunne utløses på rapporter utenfra, ikke bare på egne funn (Digi.no).

Patch-sykluser målt i dager, ikke uker

Dette er den klareste konkrete anbefalingen i hele kildematerialet. Patch-sykluser målt i uker eller måneder for kritiske eksponeringer er ikke lenger akseptable, og virksomheter bør jobbe mot sykluser målt i dager (EY, 2026). Det er et driftskrav, og det har kostnadskonsekvenser du bør ta stilling til med åpne øyne.

Hva «dager» krever av organisasjonen

For å komme ned til dager må fire ting være avklart før varselet kommer: hvem som ser varselet, hvem som vurderer det, hvem som godkjenner nedetid, og hvem som bekrefter at jobben er gjort. Hvis noen av disse rollene må finnes ut underveis, bruker du opp hele vinduet på koordinering. Tempoet ligger sjelden i det tekniske arbeidet. Det ligger i beslutningsveien.

Hasteklasse	Kriterium	Mål for respons	Hvem beslutter
Akutt	Internetteksponert, aktiv utnyttelse observert	Samme døgn, nedetid tillatt	IT-ansvarlig, forhåndsgodkjent fullmakt
Høy	Kritisk sårbarhet, eksponert, ingen kjent utnyttelse	Innen få dager	IT-ansvarlig varsler ledelsen
Normal	Interne systemer, ingen direkte eksponering	Neste ordinære vindu	IT-ansvarlig
Utsatt	Patch bryter kritisk integrasjon	Neste vindu med kompenserende tiltak	Daglig leder, skriftlig unntak

Unntak skal dokumenteres, ikke glemmes

Noen ganger kan du ikke patche. Et gammelt fagsystem tåler ikke oppgraderingen, eller leverandøren har ikke sluppet en versjon ennå. Det er en legitim situasjon, men bare hvis den er skrevet ned: hva som ikke er patchet, hvorfor, hvilke kompenserende tiltak som er satt inn, og når beslutningen vurderes på nytt. Et udokumentert unntak er ikke et unntak, det er en glemt sårbarhet.

Dette er også den delen revisorer og kunder vil se. Forventningen er at du kan vise hvordan funn identifiseres, prioriteres og utbedres, og unntakslisten er ofte den mest ærlige dokumentasjonen du har (EY, 2026). En kort, oppdatert unntaksliste gir mer tillit enn en tykk policy ingen følger.

Mandag morgen: dette gjør du før neste patch-vindu

Resten av artikkelen er analyse. Denne seksjonen er oppgaver. Alt under kan gjøres av en IT-ansvarlig og en daglig leder i løpet av noen timer, uten innkjøp og uten konsulenter. Rekkefølgen er bevisst: beholdning først, fordi alt annet henger på den.

Skriv beholdningslisten ferdig denne uken

Åpne et regneark. En rad per system som er tilgjengelig fra internett eller behandler kundedata. Kolonner: navn, versjon, hvem som drifter det, om det er eksponert, hvilke data det rører, og hvem som kan godkjenne nedetid. Listen blir ufullstendig første gang. Det er fortsatt enormt mye bedre enn ingen liste.

Marker deretter alt du ikke drifter selv. Det er leverandørlisten din, og den blir utgangspunktet for leverandørsamtalene lenger ned. Hvis du har bygget en AI-roadmap eller er i ferd med å rulle ut nye AI-verktøy, hører de inn i samme liste. Nye integrasjoner er ny angrepsflate.

Sett opp en varslingskanal med en eier

Varsler fra leverandører, nasjonale myndigheter og sikkerhetsmiljøer må inn i en kanal noen leser hver dag, ikke i en personlig innboks. Det kan være en felles e-postadresse som videresendes til en Slack- eller Teams-kanal. Kravet er at det finnes en navngitt person med ansvar, og en stedfortreder for ferie og sykdom.

Legg til en enkel regel: varsler som nevner fjernkjøring av kode eller uten autentisering skal vurderes samme dag. Det var nettopp den kombinasjonen som gjorde PHP-hullene så alvorlige (Digi.no). To stikkord i en regel er lettere å følge enn et scoringssystem ingen husker.

Avtal vinduet og fullmakten skriftlig

Bestem et fast ukentlig patch-vindu, og skriv en kort fullmakt som sier at IT-ansvarlig kan ta ned navngitte tjenester uten ny godkjenning når kriteriene for akutt er oppfylt. Avklar samtidig hvem som informerer kunder, og med hvilken formulering. Denne delen tar tjue minutter nå og sparer timer under press.

Gjør så en tørrøvelse. Velg et scenario: en kritisk sårbarhet i rammeverket nettbutikken din kjører på, aktiv utnyttelse observert. Gå gjennom hvem som gjør hva, i rekkefølge, med klokkeslett. Finn flaskehalsen. I de fleste SMB-er er den ikke teknisk, den er at en enkelt person må nås på telefon.

Oppgave	Ansvarlig	Resultat du skal ha
Beholdningsliste	IT-ansvarlig	Regneark med eksponering og dataklasse per system
Varslingskanal	IT-ansvarlig	Felles kanal med navngitt eier og stedfortreder
Patch-vindu	IT-ansvarlig	Fast tidspunkt i kalenderen, kjent av alle
Nedetidsfullmakt	Daglig leder	Skriftlig fullmakt med navngitte tjenester
Tørrøvelse	Ledergruppen	Tidslinje med identifisert flaskehals
Leverandørspørsmål	Innkjøp	Standard spørsmålssett i nye avtaler

Markedet: 77 prosent bruker allerede AI i forsvaret

Hvis du lurer på om du er sent ute, er svaret sannsynligvis ja, men ikke på den måten du tror. Flertallet av organisasjoner har tatt i bruk AI i cybersikkerhetsarbeidet, og bruken konsentrerer seg om noen få, veldig konkrete oppgaver (World Economic Forum, 2026). Dette er ikke eksperimentering. Det er driftsverktøy.

Hva AI faktisk brukes til, og hva det ikke erstatter

Bruksområde	Andel organisasjoner	Hva det løser
Phishing-deteksjon	52 %	Filtrerer bedre skrevne og mer personlige svindelforsøk
Inntrengnings- og anomalirespons	46 %	Fanger avvik i trafikk og logger raskere enn manuell gjennomgang
Brukeratferdsanalyse	40 %	Oppdager kontoer som oppfører seg uvanlig

Legg merke til hva som ikke er på listen. Ingen av disse bruksområdene erstatter beholdningsliste, patch-vindu eller beslutningsfullmakt. AI gjør deteksjon bedre og raskere, men den fjerner ikke behovet for at et menneske har myndighet til å ta ned en tjeneste. Verktøy løser deteksjonsproblemet. Rutiner løser responsproblemet.

Sikkerhetsvurdering av AI-verktøy har nesten doblet seg

Mens AI rulles ut i forsvaret, strammes det samtidig inn på inngangssiden. Andelen organisasjoner som vurderer sikkerheten til AI-verktøy før utrulling har nesten doblet seg, fra 37 prosent til 64 prosent på et år (World Economic Forum, 2026). Det er den enkeltstatistikken i rapporten som er lettest å kopiere for en SMB: en sjekkliste før du kobler et nytt verktøy til dataene dine.

Spørsmålene behøver ikke være avanserte. Hvor lagres dataene, hvem har tilgang, brukes de til trening, hvordan varsles vi om hendelser, og hva skjer med dataene ved oppsigelse. Dette er de samme vurderingene som hører inn i et valg av språkmodell, og de bør tas før piloten starter, ikke etter at den har vokst inn i driften.

---

Les også: LLM-er og valg av språkmodell: GPT-4, Claude, Gemini eller lokal modell – hva passer for norsk bedrift?. Valget mellom GPT-4, Claude, Gemini og norske modeller handler om mer enn ytelse.

---

Kostnad og kapasitet uten eget sikkerhetsteam

De fleste norske SMB-er har ikke et sikkerhetsteam, og kommer ikke til å få et. Det er en premiss, ikke en unnskyldning. Spørsmålet er hva som må eies internt og hva som kan kjøpes, og hvor mye av gapet som faktisk skyldes penger.

Penger eller kompetanse: hva som egentlig mangler

Lederundersøkelsen skiller interessant mellom modne og mindre modne virksomheter. Blant CEO-er i lite resiliente organisasjoner oppgir 63 prosent manglende midler og 56 prosent manglende cybersikkerhetskompetanse som største utfordring. I de svært resiliente organisasjonene peker 78 prosent i stedet på avhengigheter i leverandørkjeden (World Economic Forum, 2026).

Det er et nyttig diagnostisk signal. Så lenge du diskuterer budsjett og bemanning, jobber du med grunnmuren. Når du begynner å bekymre deg for leverandørene dine, har du kommet videre. Begge samtalene er riktige, men de hører til ulike stadier, og det er bortkastet å kjøpe avansert overvåking før beholdningslisten finnes.

Hva du kan kjøpe og hva du må eie selv

Funksjon	Kan kjøpes	Må eies internt
Overvåking og deteksjon	Ja, som tjeneste	Hvem som mottar og kvitterer varselet
Skanning av systemer	Ja, verktøy eller tjeneste	Beholdningslisten skanningen måles mot
Patching av egne servere	Delvis, via driftspartner	Godkjenning av nedetid og rekkefølge
Hendelseshåndtering	Ja, beredskapsavtale	Kundekommunikasjon og ledelsesbeslutninger
Leverandøroppfølging	Nei	Kontraktskrav og jevnlig gjennomgang

Mønsteret er konsekvent: du kan kjøpe deteksjon og hender, men ikke beslutninger og eierskap. En driftspartner kan patche serveren klokka to om natten. Partneren kan ikke bestemme at nettbutikken skal være nede i to timer midt i en kampanje. Det er din avgjørelse, og den bør være tatt før den blir aktuell.

Ikke regn med at noen andre rydder opp

Tilliten til at myndigheter håndterer store hendelser er ikke overveldende. 31 prosent av respondentene rapporterer lav tillit til nasjonens evne til å håndtere store cyberhendelser, opp fra 26 prosent året før (World Economic Forum, 2026). Samtidig oppgir 23 prosent av offentlige organisasjoner selv utilstrekkelig cyberresiliens.

For en leverandør til offentlig sektor har dette en praktisk side. Du kan bli bedt om å dokumentere din egen håndtering nettopp fordi kunden vet at kjeden er svakere enn ønsket. Og du kan ikke basere beredskapen din på at noen større aktør oppdager problemet for deg i tide.

Leverandørkjeden, kundene og revisorene

PHP-hullene var ikke norsk kode. De lå i et åpent rammeverk som tusenvis av virksomheter bygger på uten å tenke over det, og de hadde ligget der i over et tiår (Digi.no). Det er den typiske formen på problemet: sårbarheten er din konsekvens, men ikke din kode.

Alura mener at programvareleverandører bør vurderes med samme grundighet som kritiske leverandører, fordi hullene oftest ligger i kode du ikke selv skrev. EY formulerer det samme kravet: gjennomgå leverandørbeholdningen med fokus på programvare, og vurder hver leverandør med den grundigheten som historisk har vært forbeholdt leverandører på høyere nivå (EY, 2026).

Spørsmålene leverandøren skal kunne svare på

Fire spørsmål dekker det meste. Hvor fort patcher dere kritiske sårbarheter i egen og underliggende programvare? Hvordan varsler dere kundene, og innen hvilken frist? Hvilke tredjepartskomponenter ligger under løsningen? Og hvem kan vi ringe utenom åpningstid når noe brenner? En leverandør som ikke kan svare raskt på disse, har sannsynligvis ikke rutinene heller.

Dette gjelder også AI-leverandører og integrasjoner som vokser fort. Når bedrifter kobler nye AI-agenter og automatiseringer mot kjernesystemene, utvides angrepsflaten i samme tempo som nytten. Hver integrasjon med tilgang til kundedata er en leverandør, uansett hva den kalles internt.

Revisjon og rapportering endrer form

Det er ikke bare angriperne som har økt tempoet. Forventningene fra kunder og regulatorer følger etter. Fremtidige SOC-rapporter vil i økende grad gjenspeile kontinuerlig kontrollvalidering, mer granulær testing og tydeligere beskrivelse av hvordan sårbarheter identifiseres, prioriteres og utbedres (EY, 2026).

EY peker også på at kunder og regulatorer kan stille spørsmål ved om skjulte sårbarheter finnes, selv hos virksomheter med tradisjonelle rapporter og ingen større hendelser. Fraværet av hendelser er ikke lenger et bevis. Serviceorganisasjoner bør forvente kundehenvendelser som går utover enkel due diligence i løpet av en rapporteringssyklus.

Loggen du vil ha den dagen kunden spør

Minimumsdokumentasjonen er overkommelig: beholdningslisten med dato, en logg over mottatte varsler med vurdering og utfall, en oversikt over gjennomførte patcher, unntakslisten med begrunnelse, og referatet fra siste tørrøvelse. Fem artefakter, oppdatert løpende, slår en policy på tjue sider.

Regulatoriske krav går i samme retning internasjonalt. I India har kritiske sektorer en frist på seks timer for hendelsesrapportering (arXiv). Du behøver ikke tro at Norge får akkurat den fristen for å se poenget: rapporteringsvinduene krymper, og de krymper fortere enn interne rutiner modnes.

Markedsobservasjon: svindel og deepfaker treffer samtidig

Mens IT-avdelingen patcher, treffes resten av organisasjonen av en annen bølge fra samme teknologi. 73 prosent av respondentene rapporterte at de selv eller noen i nettverket deres hadde blitt personlig rammet av cyberaktivert svindel gjennom 2025 (World Economic Forum, 2026). Dette er ikke et sidespor fra patch-diskusjonen, det er den andre halvdelen av regningen.

Deepfake-hendelser tidoblet, og deteksjonen svikter

En forskningsoversikt over AI-drevne trusler beskriver at antall deepfake-hendelser økte tidoblet på verdensbasis fra året før, med vekst på 1740 prosent i Nord-Amerika og 780 prosent i Europa (arXiv). Nesten 75 prosent av sakene involverte identitetssvindel, hovedsakelig med ID-kort. Terskelen er lav: en angriper kan klone en stemme med under 30 sekunder kildelyd.

Det ubehagelige er at verktøyene som skal fange dette ikke holder. Under reelle forhold faller treffsikkerheten til deteksjonssystemer kraftig, med rundt 50 prosent fall i målt ytelse for video (arXiv). Et deepfake-videomøte kostet et offer over 25 millioner dollar. Forsvaret kan altså ikke være teknisk deteksjon alene, det må være prosess: tilbakeringing på kjent nummer, to godkjennere på betalinger, og ingen hastesaker som hopper over kontrollen.

Reguleringen henger etter teknologien

Den samme oversikten konstaterer at det ikke finnes globale lover som regulerer adversarial AI, og at lovgivningen som finnes er fragmentert: i USA har 14 delstater lover mot ikke-samtykkende seksuelle deepfaker, mens 10 delstater har restriksjoner knyttet til politiske kampanjer (arXiv). Det er ikke et rammeverk du kan lene en forretningsrutine på.

Praktisk betyr det at du ikke bør vente på at regulering definerer minstekravene dine. Automatisert skadevare som endrer utseende hvert 30 til 60 sekund bryr seg ikke om hvilken fase lovarbeidet er i (arXiv). Interne kontroller er det eneste som virker i mellomtiden.

Vanlige feil norske SMB-er gjør

Feilene under er ikke hypotetiske. De er mønstre som gjentar seg hos virksomheter som ellers er godt drevet, og de har alle det til felles at de ser fornuftige ut helt til noe skjer.

Å behandle patching som en teknisk oppgave uten eier

Den vanligste feilen er at patching er noe «IT ordner» uten at noen har definert hvem, når og med hvilken fullmakt. Resultatet ser bra ut i normaldrift og kollapser under press. De tusenvis av nettstedene som sto sårbare lenge etter at PHP-patchen var tilgjengelig, er den synlige enden av dette mønsteret (Teknisk Ukeblad).

Nummer to er å kjøpe verktøy før rutiner. Overvåking som varsler inn i en innboks ingen leser gir en falsk trygghet som er verre enn ingen overvåking, fordi den dokumenterer at du visste. Rekkefølgen er alltid eier, rutine, verktøy.

Å måle sikkerhet på fravær av hendelser

«Vi har aldri blitt hacket» er ikke en måling, det er en observasjon. EY peker nettopp på at kunder og regulatorer kan stille spørsmål ved om skjulte sårbarheter finnes selv der det ikke har vært hendelser (EY, 2026). PHP-hullene lå i koden i over et tiår uten at noen merket det. Stillhet er ikke data.

Mål i stedet noe som faktisk beveger seg: tid fra varsel til vurdering, tid fra vurdering til patch i produksjon, andel av beholdningen som er dokumentert, og antall åpne unntak. Fire tall, gjennomgått månedlig i ledergruppen. Det er nok til å se om du faktisk er på dager eller bare håper det.

Å glemme at AI-prosjektene også er angrepsflate

Mange virksomheter kjører nå parallelle løp: et AI-initiativ som skal gi effektivitet, og en sikkerhetsfunksjon som er underbemannet. Nye modeller, agenter og integrasjoner kobles på kjernesystemer uten at noen oppdaterer beholdningslisten. At andelen som vurderer AI-sikkerhet før utrulling har økt kraftig, viser at markedet har oppdaget dette, men også at en tredjedel fortsatt ikke gjør det (World Economic Forum, 2026).

Den siste feilen er å tro at dette er et spørsmål om teknologivalg. Det er et spørsmål om styring. En gjennomtenkt AI-strategi inkluderer hvem som eier sårbarhetshåndteringen av det som bygges, før det bygges.

Ofte stilte spørsmål om AI-drevne sårbarheter

Spørsmålene under er de som oftest kommer fra ledergrupper når tempoet i trusselbildet blir konkret.

Hva er egentlig en AI-drevet sårbarhet?

Begrepet dekker to ting som ofte blandes. Det ene er sårbarheter som blir funnet ved hjelp av AI, slik som PHP-hullene som hadde ligget i koden i over ti år (Digi.no). Det andre er sårbarheter i AI-systemene dine selv, for eksempel modeller med for brede tilganger. Begge krever styring, men det første haster mest akkurat nå fordi det treffer programvare du allerede kjører.

Hvor fort må vi egentlig patche?

For kritiske eksponeringer er anbefalingen sykluser målt i dager, ikke uker eller måneder (EY, 2026). Når aktiv utnyttelse er observert, slik den var under et døgn etter PHP-oppdateringen, er svaret samme døgn (Digi.no). For interne systemer uten eksponering holder det ordinære vinduet.

Vi har ikke sikkerhetsteam. Hvor begynner vi?

Med beholdningslisten og en navngitt eier av varslingskanalen. Begge er gratis og tar timer, ikke uker. Deretter en skriftlig nedetidsfullmakt. Først når disse tre er på plass gir det mening å kjøpe overvåking eller en beredskapsavtale. Manglende midler og manglende kompetanse er de to hyppigst nevnte hindrene blant mindre modne virksomheter, og ingen av dem løses av et verktøykjøp alene (World Economic Forum, 2026).

Kan vi bruke AI til å finne hull i vår egen kode?

Ja, og noen gjør det i stor skala. Epic brukte en AI-modell på egne systemer og fant oppsett som kunne gi tilgang til sensitive pasientjournaler (Teknisk Ukeblad). Vær forberedt på at du finner noe. Epic satte alt utviklingsarbeid på vent i seks uker. Avklar på forhånd hvem som prioriterer funnene og hvilken kapasitet som faktisk er satt av til å rette dem.

Hva svarer vi når en kunde spør om sårbarhetshåndtering?

Vis dokumentasjon, ikke intensjoner. Forventningen fra markedet er at du kan demonstrere hvordan funn identifiseres med flere verktøy, prioriteres raskt og håndteres i tide (EY, 2026). Beholdningsliste med dato, varsellogg, patch-oversikt og unntaksliste svarer på de fleste spørsmål en kunde eller revisor stiller.

Oppsummering: det korte svaret

Det som endret seg i 2026 er ikke at programvare har feil. Det er at avstanden mellom «feilen er kjent» og «feilen utnyttes mot deg» har krympet til under et døgn, og i verste fall til minutter (Digi.no). En prosess som kjører en gang i året kan ikke svare på en hendelse som utvikler seg på en formiddag.

Flertallet av organisasjoner har allerede tatt AI inn i forsvaret, og nesten alle lederne i undersøkelsen venter at AI blir den viktigste endringsdriveren i cybersikkerhet (World Economic Forum, 2026). Verktøyene er altså ikke flaskehalsen. Beslutningsveien er.

Tre setninger du bør kunne svare på i dag

Hvem leser sikkerhetsvarslene våre hver dag, og hvem gjør det i ferien? Hvem kan ta ned nettsiden uten å spørre noen? Og hvilke tre systemer ville gjort mest skade om de ble kompromittert i natt? Hvis svarene ikke finnes skriftlig, er det den første oppgaven, ikke den neste anskaffelsen.

Resten er vedlikehold av kjedelige artefakter: en liste, en kanal, et vindu, en fullmakt og en unntaksoversikt. Det er lite å skryte av. Det er også forskjellen mellom å ta en kontrollert nedetid på to timer og å stå i en hendelse du oppdaget gjennom en kundehenvendelse.

I Alura hjelper vi norske bedrifter med å bygge AI-strategi som faktisk lar seg gjennomføre. Vi kombinerer dyp teknisk innsikt med erfaring fra alt fra SMB til enterprise, og leverer veikart som virker i praksis, ikke bare i PowerPoint.

Bestill en strategiøkt: en halvdags samtale der vi kartlegger virksomhetens AI-modenhet, identifiserer de tre prosessene med størst potensial, og leverer et konkret veikart med budsjettramme. Uforpliktende.

Kilder

• World Economic Forum (2026). WEF_Global_Cybersecurity_Outlook_2026.pdf
• Digi.no. Sikkerhetsmiljøer ser utnyttelse av kritiske hull – norske virksomheter oppfordres til å oppdatere
• EY (2026). AI vulnerability discovery is reshaping SOC reporting | EY Norway
• Teknisk Ukeblad. KI avdekker og utnytter sikkerhetshull i økende tempo
• Digi.no. KI avdekker og utnytter sikkerhetshull i økende tempo
• arXiv. AI-Driven Cybersecurity Threats: A Survey of Emerging Risks and Defensive Strategies
• arXiv. [2601.03304] AI-Driven Cybersecurity Threats: A Survey of Emerging Risks and Defensive Strategies