Cybersikkerhet har alltid vært et kappløp. Angripere leter etter svakheter. Forsvarere prøver å tette dem. Leverandører publiserer oppdateringer. Virksomheter tester, prioriterer og installerer. Noen rekker det. Andre blir kompromittert før de får oversikt.
AI endrer ikke denne grunnlogikken. Men AI endrer tempoet.
Det viktigste med AI-drevne cyberangrep er ikke at maskiner plutselig blir allmektige hackere. Den mer realistiske faren er at AI senker terskler, automatiserer deler av angrepskjeden, hjelper angripere med å forstå kode og sårbarheter raskere, og gjør sosial manipulering mer skalerbar og mer troverdig.
Når tempoet øker, krymper patch-vinduet. Tiden mellom offentlig sårbarhetsinformasjon og aktiv utnyttelse blir kortere. Tiden en virksomhet har til å oppdage, prioritere og oppdatere, blir mindre. Og hvis en sårbarhet allerede utnyttes i det fri, er "vi patcher neste måned" ikke lenger en akseptabel plan.
Dette er grunnen til at AI og zero-days hører sammen i samme diskusjon. Ikke fordi alle AI-angrep bruker ukjente sårbarheter. De fleste angrep bruker fortsatt kjente svakheter, stjålne legitimasjoner, phishing, feilkonfigurasjoner og dårlig drift. Men AI kan gjøre hele prosessen raskere, billigere og mer tilgjengelig.
For norske virksomheter betyr det at grunnsikring blir viktigere, ikke mindre. AI gjør ikke sikkerhetsarbeidet magisk. Det gjør slurv dyrere.
Angripere bruker AI som arbeidsverktøy
OpenAI, Anthropic, Microsoft og Google Cloud har alle publisert materiale om misbruk av AI i trusselaktivitet. Fellesbildet er nøkternt: trusselaktører bruker AI sammen med tradisjonelle verktøy. AI erstatter ikke hele angrepskjeden, men hjelper i deler av den.
Det kan være rekognosering, tekstproduksjon, oversettelse, phishing, kodeforståelse, malware-utkast, feilretting, skripting, automatisering, dokumentasjon av angrepssteg eller analyse av stjålne data. For lavere kompetente aktører kan AI gi et løft. For mer avanserte aktører kan AI spare tid.
Anthropic har analysert kontoer som ble stengt for skadelig cyberaktivitet, og fant omfattende bruk av AI til blant annet malware-relaterte aktiviteter og senere faser av angrepsoperasjoner. Selskapet har også beskrevet en AI-orkestrert spionasjekampanje der menneskelig styring ble kombinert med agentisk bruk av verktøy.
Dette betyr ikke at man skal tro alle dramatiske overskrifter. AI-hacking er fortsatt begrenset av tilgang, kontekst, verktøy, sårbarheter og operasjonell kompetanse. Men det betyr at flere aktører kan gjøre mer, raskere.
I sikkerhet er det nok.
Zero-days er bare toppen av problemet
En zero-day er en sårbarhet som utnyttes før leverandøren har publisert en fiks, eller før forsvarerne har hatt realistisk mulighet til å beskytte seg. Slike sårbarheter får mye oppmerksomhet fordi de er farlige og ofte brukes av avanserte aktører.
Men for de fleste virksomheter er problemet bredere: kjente sårbarheter som ikke er patchet, systemer som ingen eier, gamle VPN-løsninger, åpne tjenester, svake passord, manglende flerfaktor, feilkonfigurerte skyer og tredjepartsprogramvare med for høy tilgang.
CISAs Known Exploited Vulnerabilities Catalog er nyttig nettopp fordi den skiller mellom teoretisk risiko og sårbarheter som faktisk utnyttes. Når en sårbarhet havner der, er spørsmålet ikke lenger "kan noen bruke dette?" Svaret er allerede ja.
AI gjør dette mer presserende. Når informasjon om en sårbarhet publiseres, kan angripere bruke AI til å lese tekniske beskrivelser, sammenligne patcher, skrive proof-of-concept-kode, tilpasse eksisterende exploit-kode og finne systemer som sannsynligvis er sårbare. Forsvarere kan bruke AI til det samme, men angripere trenger bare ett hull.
Det betyr at patch-prioritering må bli mer operasjonell. Ikke alle CVE-er er like viktige. Men kjente, utnyttede, internett-eksponerte sårbarheter i kritiske systemer må behandles som hendelser, ikke som administrativt vedlikehold.
Identitet er fortsatt den enkleste veien inn
Selv med AI og zero-days er identitet ofte den svakeste delen av sikkerheten. Microsofts Digital Defense Report peker på passordangrep, phishing, ransomware, dataeksfiltrering og flertrinnsangrep som sentrale trusler. AI kan gjøre phishing mer overbevisende, mer personlig og bedre tilpasset språk, rolle og kontekst.
Dette gjelder særlig i små og mellomstore virksomheter. En angriper trenger ikke finne en ukjent sårbarhet hvis en ansatt kan lures til å gi fra seg innlogging, godkjenne en MFA-forespørsel eller åpne en ondsinnet fil. AI gjør slike angrep enklere å skalere og vanskeligere å avsløre med klassiske tegn som dårlig grammatikk.
Derfor er identitetssikring fortsatt et av de mest effektive tiltakene. Phishing-resistent flerfaktor, betinget tilgang, gode passordrutiner, deaktivert eldre autentisering, minst mulig privilegier og rask avvikling av gamle kontoer er ikke glamorøst. Men det virker.
AI endrer også intern trusseloverflate. Ansatte kan lime inn sensitiv informasjon i AI-verktøy for å få hjelp. Det kan være kundedata, passord, konfigurasjoner, kontrakter, logger eller kildekode. Da har virksomheten ikke blitt hacket i klassisk forstand, men data er likevel delt med en tredjepart.
Dette må behandles som sikkerhet, ikke bare personvern. En intern logg med feilmeldinger kan inneholde tokens, IP-adresser, kundenavn og systemdetaljer. En kodefil kan inneholde hemmeligheter. En eksport fra CRM kan inneholde personopplysninger. AI-verktøy kan bli en ny lekkasjekanal hvis de brukes uten rammer. Det er samme problemstilling som i Kunnskapsrom-artiklene om hvem som egentlig kontrollerer dataene dine og GDPR-data i amerikanske skyløsninger.
Tredjepartsverktøy gjør risikoen bredere
Moderne IT-drift er bygget på tredjepartsverktøy: skyløsninger, SaaS, RMM, EDR, backup, dokumentdeling, integrasjoner, plugins, API-er og automatiseringsplattformer. Det gjør virksomheter effektive, men også avhengige.
AI legger et nytt lag på toppen. Mange sikkerhets- og produktivitetsverktøy får AI-funksjoner. De analyserer logger, skriver rapporter, prioriterer sårbarheter, foreslår tiltak, oppsummerer hendelser og automatiserer respons. Det kan gi stor verdi, men det betyr også at mer sikkerhetsdata sendes til leverandører.
Sikkerhetsdata er ekstremt sensitive. Logger kan avsløre nettverksstruktur, brukermønstre, sårbare systemer, feilede innlogginger, interne prosesser og hendelser under etterforskning. Hvis slike data brukes til AI-analyse, må virksomheten vite nøyaktig hvordan leverandøren håndterer dem.
Spørsmålene bør være konkrete: Brukes data til modelltrening? Lagres de utenfor valgt region? Har underleverandører tilgang? Kan supportpersonell se innhold? Hvordan slettes data? Hvordan håndteres hendelser hos leverandøren? Hvilke rettigheter har virksomheten til eksport og revisjon?
Det er ikke nok at verktøyet markedsføres som "secure AI". Sikkerhet må dokumenteres.
Forsvarere får også bedre verktøy
AI er ikke bare en fordel for angripere. Forsvarere kan bruke AI til å analysere store loggmengder, oppsummere hendelser, finne mønstre, prioritere sårbarheter, skrive deteksjonsregler, forklare alarmer, generere playbooks og hjelpe mindre team med oppgaver som tidligere krevde spesialister.
Dette kan være svært verdifullt for SMB-er og kommuner som ikke har store sikkerhetsteam. En god AI-assistent kan hjelpe med å forstå hva en alarm betyr, hvilke systemer som er påvirket, og hvilke tiltak som bør prioriteres.
Men forsvarende AI må også styres. En modell som får tilgang til logger, identitetsdata og sikkerhetshendelser, behandler noen av virksomhetens mest sensitive data. Den må brukes innenfor klare avtaler og tekniske grenser.
Det er også fare for falsk trygghet. AI kan oppsummere feil, overse viktig kontekst eller foreslå tiltak som ikke passer miljøet. Sikkerhetsteam må derfor bruke AI som assistent, ikke som autoritet. Mennesker må fortsatt eie beslutningen.
Den beste bruken av AI i forsvar er ofte å redusere støy og frigjøre tid, ikke å automatisere bort ansvar.
AI gjør sårbarhetsforskning mer tilgjengelig
Sårbarhetsforskning har tradisjonelt krevd mye spesialkompetanse. Man må forstå kode, protokoller, minnehåndtering, patcher, arkitektur og hvordan små feil kan bli sikkerhetsproblemer. AI gjør ikke dette enkelt, men kan hjelpe flere med deler av arbeidet.
En modell kan forklare en kodeendring, sammenligne en gammel og ny versjon, foreslå hvor en feil kan ligge, skrive testkode eller hjelpe til med fuzzing-oppsett. For forsvarere er dette positivt. Små team kan få hjelp til å forstå hvorfor en patch haster, hvilke systemer som er utsatt, og hvilke kompenserende tiltak som kan brukes.
Men det samme gjelder angripere. Når en leverandør publiserer en sikkerhetsoppdatering, kan angripere analysere hva som er endret og forsøke å finne sårbarheten patchen lukker. Dette er ikke nytt, men AI kan gjøre prosessen raskere. Det betyr at tiden mellom patch og utnyttelse kan krympe.
Dette er spesielt farlig for programvare som står eksponert mot internett: VPN, brannmurer, filoverføring, e-postsystemer, fjernstyring, identitetsløsninger og webapplikasjoner. Når slike systemer har kjente sårbarheter, er de attraktive mål fordi de kan gi direkte inngang. Den samme utviklingen gjør også AI-kodeagenter og utviklerrollen mer relevant for sikkerhet, fordi mer kode og mer analyse kan produseres raskere enn review-prosessen tåler.
Derfor bør virksomheter ha en egen kategori for "ekstern angrepsflate". Alt som kan nås fra internett, må ha raskere patchløp, tydelig eier og bedre overvåking enn interne støtteverktøy. Det høres enkelt ut, men mange virksomheter mangler fortsatt en komplett oversikt.
Leverandørkjeden er en snarvei rundt forsvaret
AI endrer ikke bare direkte angrep mot virksomheten. Den kan også gjøre leverandørkjedeangrep mer effektive.
Angripere kan bruke AI til å kartlegge hvilke leverandører en virksomhet bruker, lage mer troverdige e-poster, etterligne supportdialoger, analysere offentlig dokumentasjon, skrive skadelig kode som ligner legitim oppdateringslogikk, eller finne svake integrasjoner mellom systemer.
Dette er alvorlig fordi mange virksomheter har gitt leverandører høy tilgang. IT-partnere, driftssystemer, backup, RMM, regnskap, HR, dokumentflyt og sikkerhetsverktøy kan alle ha brede rettigheter. Hvis en leverandør kompromitteres, kan angriperen få en snarvei inn.
AI-funksjoner i leverandørprodukter gjør spørsmålet bredere. Hvis et leverandørverktøy plutselig får AI-assistent som leser logger, bilag, tickets eller kundedata, er det en ny behandlingsaktivitet. Det må vurderes, ikke bare aksepteres som en produktoppdatering.
Virksomheter bør derfor ha en leverandøroversikt som inkluderer tilgangsnivå, datafangst, AI-funksjoner, underleverandører og hendelsesvarsling. Det er ikke nok å vite hvem man betaler faktura til. Man må vite hvem som faktisk kan se, endre eller hente data.
Dette er særlig viktig for små virksomheter som outsourcer mye IT. Outsourcing flytter arbeid, men ikke ansvar. Hvis leverandøren bruker AI-verktøy i drift eller support, bør kunden vite hvilke data som inngår.
Styret må stille bedre spørsmål
AI-cybersikkerhet er ikke bare et teknisk tema. Styre og ledelse bør forstå hovedrisikoene godt nok til å prioritere penger, tid og ansvar.
De trenger ikke kunne skrive deteksjonsregler. Men de bør spørre: Har vi oversikt over internett-eksponerte systemer? Hvor raskt patcher vi sårbarheter som utnyttes aktivt? Har alle privilegerte kontoer phishing-resistent MFA? Hvilke AI-verktøy er godkjent for ansatte? Sender sikkerhetsleverandørene våre logger til eksterne AI-tjenester? Har vi testet gjenoppretting fra backup? Vet vi hvem som beslutter nedstenging ved angrep?
Hvis ledelsen ikke får konkrete svar, er det et styringsproblem. Det er ikke nok med en generell forsikring om at "IT har kontroll". I en raskere trusselverden må kontroll kunne dokumenteres.
Hva norske virksomheter bør gjøre nå
Det første tiltaket er å få oversikt over eksponerte systemer. Hvilke tjenester er tilgjengelige fra internett? Hvilke VPN-er, brannmurer, fjernstyringsverktøy, webapplikasjoner og skyressurser finnes? Hvem eier dem? Hvordan patches de?
Det andre er å bruke risikobasert patching. Alle oppdateringer er ikke like kritiske, men sårbarheter som er kjent utnyttet, internett-eksponert eller knyttet til privilegert tilgang må prioriteres raskt. CISA KEV er et godt startpunkt, men virksomheten må koble katalogen til egen systemoversikt.
Det tredje er å stramme inn identitet. Phishing-resistent MFA, rollebasert tilgang, betinget tilgang, logging av privilegerte handlinger og rask fjerning av gamle kontoer bør være standard.
Det fjerde er å lage en AI-datapolicy. Den må si hvilke data som aldri skal inn i eksterne AI-verktøy, hvilke verktøy som er godkjent, og hva ansatte skal gjøre hvis de er usikre. Policyen bør være kort nok til å bli brukt.
Det femte er å teste hendelsesrespons. Hvis en AI-assistert angriper beveger seg raskere, må virksomheten vite hvem som tar beslutninger, hvem som kan stenge tilgang, hvordan backup kontrolleres, og hvordan kunder varsles.
Det sjette er å stille krav til leverandører. Sikkerhetsleverandører, IT-partnere og SaaS-aktører bør kunne forklare hvordan AI-funksjoner behandler data. Hvis de ikke kan svare presist, bør funksjonen ikke få sensitive data.
Patch-vinduet må behandles som et forretningsspørsmål
Mange virksomheter ser fortsatt patching som en teknisk oppgave som skjer når IT har tid. Det holder ikke. Patching handler om drift, risiko, forsikring, kundetillit og ledelsesansvar.
Når en kritisk sårbarhet publiseres, oppstår en beslutning: Kan vi oppdatere raskt? Kan vi kompensere med brannmur, isolering eller midlertidig nedstengning? Hvilke systemer er påvirket? Hvilken risiko tar vi ved å vente?
Disse spørsmålene må kunne besvares før krisen. Hvis virksomheten først må finne systemeier, leverandørkontakt, backupstatus og vedlikeholdsvindu etter at utnyttelsen er aktiv, er den allerede på etterskudd.
AI forsterker dette fordi angripere kan automatisere mer av analyse- og utnyttelsesarbeidet. Det betyr ikke at alle virksomheter blir angrepet med avansert AI. Det betyr at tidsmarginene blir mindre.
En god patchprosess bør derfor ha ferdige kategorier. Kritisk og aktivt utnyttet: håndteres straks. Kritisk, men ikke observert utnyttet: rask prioritet. Medium i isolerte systemer: planlagt vedlikehold. Sårbarheter i systemer uten eier: eskaleres som styringsproblem.
Zero trust må bli mer konkret
Zero trust er et slitt begrep, men prinsippet er relevant: ikke stol automatisk på noe bare fordi det er på innsiden. Verifiser identitet, begrens tilgang, logg aktivitet og anta at kompromittering kan skje.
I AI-tiden blir dette enda viktigere. Hvis angripere får hjelp til å bevege seg raskere, må virksomheten redusere hva én kompromittert konto kan gjøre. Hvis et AI-verktøy får tilgang til data, må tilgangen være begrenset til det som er nødvendig. Hvis en integrasjon kompromitteres, må den ikke åpne hele miljøet.
Dette er også et argument for dataminimering. Ikke gi AI-verktøy, scripts, plugins eller tredjepartsintegrasjoner bred tilgang "for sikkerhets skyld". Gi dem minst mulig tilgang, logg bruken og fjern tilgangen når den ikke trengs.
I praksis er dette ofte mer verdifullt enn å kjøpe enda et sikkerhetsverktøy.
Backup er siste skanse, men må testes
Ransomware og datautpressing forsvinner ikke fordi AI kommer. Tvert imot kan AI gjøre utpressing mer effektiv ved å hjelpe angripere å finne sensitive dokumenter, oppsummere stjålne data og lage mer målrettede trusler mot ledelse, kunder eller leverandører.
Derfor er backup fortsatt en av de viktigste kontrollene. Kunnskapsrom har også en egen forklaring av 3-2-1 backup-regelen, nettopp fordi backup må forstås som beredskap, ikke bare lagring. Men backup som aldri er testet, er mer håp enn beredskap. Virksomheter bør vite hvor raskt kritiske systemer kan gjenopprettes, om backup er isolert fra domenet, om angripere kan slette eller kryptere den, og om gjenoppretting faktisk fungerer under tidspress.
AI kan hjelpe med dokumentasjon og øvelser, men den kan ikke erstatte en faktisk restore-test. Den dagen alt står stille, er det bare fungerende gjenoppretting som teller.
Det bør også være klart hvem som kan ta vanskelige beslutninger. Kan IT stenge ned en tjeneste uten å vente på ledermøte? Hvem kontakter kunder? Hvem varsler Datatilsynet hvis personopplysninger er berørt? Hvem vurderer politianmeldelse? Hvem har kontakt med forsikring og leverandører? Når angrepet går raskt, er uklare beslutningslinjer en risiko i seg selv.
En enkel øvelse hvert halvår kan avdekke mye. Legg fram et scenario: en kjent utnyttet sårbarhet finnes i VPN-løsningen, mistenkelig innlogging er observert, og backupstatus er usikker. Be teamet gå gjennom første time, første dag og første uke. Det er bedre å oppdage hull i fredstid enn midt i en AI-akselerert hendelse.
Konklusjon: AI gjør tempoet til hovedproblemet
AI gjør ikke cybersikkerhet fundamentalt nytt. Angripere bruker fortsatt kjente metoder: phishing, sårbarheter, legitimasjonstyveri, feilkonfigurasjoner og leverandørkjeder. Men AI gjør mange av metodene raskere, billigere og mer skalerbare.
Derfor må virksomheter redusere tregheten i eget forsvar. Oversikt, patching, identitet, leverandørkontroll og datadisiplin blir viktigere enn noen gang.
Det farlige er ikke bare den spektakulære zero-dayen. Det farlige er kombinasjonen av gamle svakheter, raskere angripere og organisasjoner som fortsatt behandler sikkerhet som periodisk vedlikehold.
AI kan hjelpe forsvarere også. Men bare hvis den brukes kontrollert. Det siste en virksomhet trenger, er å beskytte seg mot datainnbrudd ved å sende sikkerhetsdata ukritisk til nye tredjepartsplattformer.
I 2026 er den beste sikkerhetsstrategien fortsatt nøktern: vit hva du har, patch det viktigste først, beskytt identiteter, begrens datadeling, og øv på hva som skjer når noe går galt.
Videre lesing
