AI sikkerhetsrisiko: slik oppdaterer du risikoregisteret

Nøkkelpunkter per 28. august 2026:

34 prosent av norske virksomheter ser på AI som en sikkerhetsrisiko. Resten lar i praksis trusselen stå utenfor risikoregisteret (kode24, 2025).
29 prosent vurderer risikoen for cyberangrep som svært liten eller liten, og de aller minste virksomhetene vurderer risikoen lavest av alle (kode24, 2025).
AI Act ble gjeldende 2. august 2026, mens høyrisikosystemer får strenge forpliktelser fra 2. desember 2027 (EU-kommisjonen).
Minst 700 millioner mennesker bruker ledende AI-systemer ukentlig, og sikkerhetstesting før utrulling er blitt vanskeligere å stole på (arXiv, 2026).
NIST-retningslinjene for dual-use foundation models er frivillige beste praksiser, revidert etter innspill fra mer enn 70 eksperter (NIST, 2025).

Hva dual-use risiko betyr for en helt vanlig norsk virksomhet

Dual-use betyr at samme teknologi kan brukes til nytte og til skade, uten at teknologien endres underveis. NIST bruker begrepet om dual-use foundation models, altså grunnmodellene som ligger under de fleste AI-produktene en norsk virksomhet kjøper i dag (NIST, 2025). For et regnskapskontor i Bergen eller et industriselskap på Raufoss er ikke dette en akademisk distinksjon. Modellen som skriver gode kundesvar for deg, skriver også overbevisende svindelmeldinger for noen andre.

Det er dette som gjør AI-risiko annerledes fra vanlig IT-risiko. Du kan ikke lenger anta at et angrep krever spesialkompetanse, tid og lokalkunnskap. Adopsjonen er allerede massiv: minst 700 millioner mennesker bruker ledende AI-systemer ukentlig, og i noen land bruker rundt 50 prosent av befolkningen AI (arXiv, 2026). Verktøyene er billige, gode og tilgjengelige for alle, også for dem som vil deg vondt. Hvis du vil ha grunnlaget først, har vi samlet det i en komplett AI-guide.

Samme modell, to formål

Tenk på en typisk kundeservice-assistent. Den leser en henvendelse, henter kontekst fra egne systemer og formulerer et svar på flytende norsk. Snu retningen, og du har en maskin som leser LinkedIn-profilen til økonomisjefen din, henter kontekst fra årsrapporten og formulerer en e-post som ser ut som den kom fra styrelederen. Ingenting i modellen må endres for at bruken skal snu fra nytte til skade.

NIST-retningslinjene handler nettopp om å identifisere, måle og redusere risikoer for offentlig sikkerhet og nasjonal sikkerhet gjennom hele AI-livssyklusen (NIST, 2025). Det praktiske poenget for en SMB er enklere enn det høres ut: når du vurderer et AI-verktøy, må du vurdere både hva det gjør for deg og hva tilsvarende verktøy gjør mot deg.

AI er tre ting samtidig i risikobildet

De fleste risikovurderinger vi ser behandler AI som en ting. Det er minst tre. AI som verktøy er systemene du selv tar i bruk, med de databehandlings- og leverandørrisikoene det gir. AI som angrepsflate er de nye sårbarhetene som oppstår i dine egne AI-systemer, der angriperen manipulerer data eller input i stedet for kode (Advokatfirmaet Hjort, 2024). AI som angrepsvåpen er det motparten bruker mot deg.

Hvis risikovurderingen din bare dekker den første kategorien, har du dekket den minst farlige. De to andre er der hendelsene faktisk skjer. Et nyttig arbeidsgrep er å tvinge frem alle tre perspektivene på hvert AI-system dere har: hva gir dette oss, hva kan angripes i det, og hva kan noen bygge av lignende teknologi for å ramme oss.

Tallene fra Ateas sikkerhetsrapport og hvorfor de bekymrer

Ateas sikkerhetsrapport for 2025 gir et av de tydeligste bildene vi har av norsk risikoforståelse. 34 prosent av respondentene ser på AI som en sikkerhetsrisiko, og 29 prosent vurderer risikoen for cyberangrep som svært liten eller liten (kode24, 2025). IT-sikkerhetsdirektør Thomas Tømmernes i Atea er direkte i sin lesning: de som svarer slik, har ikke forstått hva som skjer.

Tallene er ikke oppsiktsvekkende i seg selv. Det som gjør dem verdt å stoppe ved, er kombinasjonen: lav opplevd risiko, lav kjennskap til regelverk, og samtidig rask innføring av AI-verktøy i de samme virksomhetene. Det er en oppskrift på å bygge nye angrepsflater raskere enn man bygger kontroller.

Funn i undersøkelsen	Andel	Hva det betyr for deg
Ser AI som en sikkerhetsrisiko	34 prosent	Flertallet har trolig ingen AI-post i risikoregisteret
Vurderer risiko for cyberangrep som svært liten eller liten	29 prosent	Lav opplevd risiko gir lav investeringsvilje
Private virksomheter uten kjennskap til NIS2	Nesten 40 prosent	Krav kan treffe indirekte gjennom kunder og kontrakter
Antall respondenter i undersøkelsen	516	Nok til retning, ikke til presisjon per bransje

De minste vurderer risikoen lavest

Undersøkelsen viser at de minste virksomhetene vurderer risikoen for cyberangrep som lavest (kode24, 2025). Logikken bak er lett å kjenne igjen: vi har ingenting av verdi, vi er ikke interessante, vi er for små. Problemet er at logikken forutsetter en angriper som velger mål manuelt og bruker tid per offer.

Den forutsetningen holder ikke lenger. Når kostnaden per angrepsforsøk faller mot null, faller også terskelen for hvem som er verdt å angripe. Alura mener at små virksomheter ikke er for små til å bli angrepet, og at lav egenvurdert risiko i seg selv er et varselsignal. Når en ledergruppe svarer at risikoen er liten uten å kunne peke på hva vurderingen bygger på, er det vurderingsprosessen som er svak, ikke trusselbildet.

Hva 516 svar kan og ikke kan fortelle

Vær presis om hva denne typen tall er. 516 respondenter er nok til å si noe om retning i norsk næringsliv, men ikke nok til å si hva som gjelder i din bransje eller din størrelsesklasse (kode24, 2025). En egenvurdering måler dessuten hva folk tror, ikke hva som faktisk er tilfelle.

Det gjør ikke funnene mindre relevante, men det endrer hvordan du bør bruke dem. Ikke bruk tallene som argument for at bransjen er uansvarlig. Bruk dem som en test på egen organisasjon: hvis dere hadde svart på samme undersøkelse, hva hadde dere krysset av, og hva ville dere kunnet legge frem som dokumentasjon for svaret?

Les også: Det Samsungs ChatGPT-utrulling lærer norske bedrifter. Samsung Electronics ruller ut ChatGPT Enterprise og Codex til ansatte i Korea og DX-divisjonen globalt.

Angriperne bruker de samme verktøyene som deg

Den viktigste endringen de siste årene er ikke at det finnes nye angrepstyper. Det er at gamle angrepstyper er blitt billigere, raskere og mer troverdige. Tømmernes peker på at AI har gjort phishing, deepfakes og sosial manipulering mer troverdig og skalerbart (kode24, 2025). Skalerbarhet er nøkkelordet: det som før krevde en dyktig person i flere timer, krever nå et skript og noen kroner i API-kostnad.

Dette er den delen av trusselbildet som treffer alle, uavhengig av om dere har innført AI selv. Du kan velge bort AI i egen drift. Du kan ikke velge bort at motparten bruker det.

Phishing som ikke lenger har skrivefeil

Den klassiske opplæringen i å oppdage svindel bygget på språkfeil, rar formatering og generiske hilsener. Den opplæringen er utdatert. En modell skriver feilfritt norsk, tilpasser tone til bransjen din og kan referere til reelle prosjekter hentet fra åpne kilder. Skrivefeil som varselsignal er dødt, og sikkerhetsopplæring som fortsatt lærer bort det, gir ansatte falsk trygghet.

Erstatningen er prosess, ikke magefølelse. Verifikasjon av betalings- og kontoendringer gjennom en separat kanal, faste rutiner for hastesaker fra ledelsen, og en kultur der det er greit å ringe tilbake og sjekke. Kontrollen må ligge i arbeidsflyten, ikke i den enkeltes evne til å lukte svindel.

Deepfake mot betalings- og godkjenningsprosesser

Syntetisk lyd og video har flyttet seg fra demonstrasjon til verktøy. International AI Safety Report 2026 beskriver et økosystem der misbruksverktøy er kommersialisert og lett tilgjengelig, og peker blant annet på at 19 av 20 av de mest populære appene i en kartlagt kategori er spesialisert på å generere bilder der kvinner fremstilles avkledd (techuk.org, 2026). Det samme underliggende teknologiske løftet gjør stemmeimitasjon av en daglig leder triviell.

For en SMB er den konkrete risikoen sjelden en avansert videokonferanse-svindel. Den er en telefonsamtale med en stemme som ligner nok, i en situasjon der noen har det travelt. Derfor bør enhver prosess der en muntlig godkjenning utløser penger eller tilgang gjennomgås. Enten fjerner du muntlig godkjenning som eneste kontroll, eller så legger du på et andre steg som ikke kan forfalskes med lyd.

Automatisert sårbarhetsjakt

På den tekniske siden er utviklingen målbar. En AI-agent identifiserte 77 prosent av sårbarhetene i ekte programvare i en konkurranse, og AI-agenter kan nå autonomt fullføre programvareoppgaver som krever flere timer med menneskelig utviklertid (arXiv, 2026). I en stor cybersikkerhetskonkurranse i 2025 plasserte en AI-agent seg i det øverste sjiktet av deltakerne (techuk.org, 2026).

Dette er dual-use i sin reneste form. De samme evnene brukes av forsvarssiden til å finne og lukke hull raskere. Konsekvensen for deg er likevel entydig: tiden mellom at en sårbarhet blir kjent og at den blir utnyttet, krymper. Patcherutiner som var akseptable for tre år siden er det ikke nødvendigvis i dag, og et system uten kjent patchestatus er en åpen post i risikoregisteret.

Fire angrepstyper mot AI-systemer du bør kjenne igjen

Når du selv setter AI i produksjon, får du en ny klasse sårbarheter på toppen av de gamle. Advokatfirmaet Hjort beskriver hvordan AI kan skape nye sårbarheter i IT-systemer som kan utnyttes av cyberkriminelle, og trekker frem dataforgiftning, inferensangrep og adversarial-angrep som sentrale mekanismer (Advokatfirmaet Hjort, 2024). Du trenger ikke å kunne implementere dem. Du trenger å kunne stille spørsmål om dem.

Angrepstype	Hva angriperen gjør	Typisk konsekvens	Førstelinjetiltak
Dataforgiftning	Manipulerer treningsdata eller kunnskapsbasen modellen henter fra	Systematisk feil svar, skjulte bakdører i oppførsel	Kildekontroll og versjonering av data
Modellinversjon og inferens	Stiller mange spørsmål for å rekonstruere sensitive data	Lekkasje av person- eller forretningsdata	Tilgangsstyring, logging, minimering av data i modellen
Adversarial input	Sender bevisst modifisert input som lurer modellen	Feilklassifisering, omgåelse av kontroller	Menneskelig kontroll ved høy konsekvens
Skjevhet og black box	Utnytter, eller avdekker, at modellen er utrenet og uforklarlig	Utilsiktet diskriminering, omdømme- og rettslig risiko	Dokumentert testing på representative data

Dataforgiftning: angrepet skjer før modellen er i drift

Ved dataforgiftning manipulerer angriperen treningsdataene slik at modellen lærer noe galt (Advokatfirmaet Hjort, 2024). Det spesielle er tidspunktet: skaden er påført lenge før noen merker den, og den ser ikke ut som et innbrudd. Systemet virker, det svarer bare feil på akkurat de tilfellene angriperen bryr seg om.

For de fleste norske SMB-er er ikke egen modelltrening det aktuelle scenarioet. Det aktuelle er kunnskapsbasen: dokumentene, sidene og datakildene som mates inn i et oppslagssystem. Hvis noen kan legge inn et dokument i den kilden uten kontroll, kan de påvirke svarene systemet gir. Dette er verdt et eget punkt når dere bygger søk mot egne data, og et konkret spørsmål er: hvem kan legge til et dokument, og hvem godkjenner det?

Modellinversjon: data lekker ut gjennom svarene

Modellinversjonsangrep brukes til å rekonstruere sensitive data fra AI-systemer (Advokatfirmaet Hjort, 2024). Angriperen bryter seg ikke inn i databasen. Vedkommende stiller mange spørsmål og setter sammen svarene. Det er en lekkasje som ikke utløser noen alarm, fordi hvert enkelt spørsmål ser legitimt ut.

Motmiddelet er kjedelig og virkningsfullt: legg ikke mer data inn i systemet enn oppgaven krever, styr tilgang per bruker og ikke per system, og logg spørringene. Et AI-system som har tilgang til alt, lekker potensielt alt. Prinsippet om minste privilegium gjelder like mye for en språkmodell som for en ansatt.

Adversarial input: modellen tar feil med vilje

Adversarial-angrep lurer modeller til å gjøre feil gjennom modifisert input (Advokatfirmaet Hjort, 2024). Et dokument formatert på en bestemt måte, et bilde med små endringer, en tekst med instruksjoner skjult i innholdet. Modellen gjør akkurat det den er trent til, men på feil grunnlag.

Risikoen her følger konsekvensen, ikke teknologien. Et AI-system som foreslår et svar til en saksbehandler tåler at det tar feil av og til. Et AI-system som godkjenner, avviser eller utbetaler automatisk gjør det ikke. Regelen er enkel: jo mer irreversibel handlingen er, jo mindre autonomi bør systemet ha.

Skjevhet og black box: risikoen du ikke kan se

AI-systemer kan skape utilsiktet diskriminering hvis de trenes på data med skjevhet, og mange systemer fungerer som black boxes der det er vanskelig å identifisere sårbarheter (Advokatfirmaet Hjort, 2024). Dette er ikke bare et etisk problem. Det er en sikkerhetsutfordring, fordi du ikke kan revidere noe du ikke kan inspisere.

Konsekvensen for risikovurderingen er at uforklarlighet er en risikofaktor i seg selv. Der du ikke kan forklare hvorfor systemet svarte som det gjorde, må du kompensere med testing og etterkontroll av utfallene. Grunnleggende forståelse av hvordan modeller lærer av data hjelper her, og vi har skrevet om maskinlæring i praksis for dem som vil ha bakgrunnen.

Slik ser en oppdatert AI-risikovurdering ut i praksis

Den vanligste feilen er ikke at virksomheter vurderer AI-risiko feil. Det er at de vurderer den et annet sted enn der resten av sikkerhetsarbeidet skjer. Alura mener at risikovurdering av AI hører hjemme i det eksisterende sikkerhetsarbeidet, ikke i et separat AI-dokument ingen leser. Et eget AI-vedlegg blir lest en gang, av dem som skrev det.

Det praktiske utslaget er at du ikke starter et nytt prosjekt. Du åpner risikoregisteret dere allerede har, og legger til rader. Behandlingsprotokollen, leverandøroversikten og beredskapsplanen får nye linjer i stedet for nye søsterdokumenter.

Kartlegg hvor AI faktisk brukes, ikke hvor det er godkjent

Første steg er en ærlig kartlegging. Ikke av hvilke AI-verktøy dere har anskaffet, men av hvilke som er i bruk. Disse to listene er sjelden like. Ansatte som limer inn kundedata eller kildekode i en gratis chatbot gjør det fordi det løser problemet deres, ikke fordi de vil bryte regler. Vi har skrevet om hva som skjedde da Samsung rullet ut ChatGPT, og lærdommen er at forbud uten alternativ flytter bruken ut av syne.

En brukbar kartlegging svarer på fire ting per verktøy: hvem bruker det, hvilke data går inn, hva brukes utdataene til, og hvem er leverandøren. Det er nok til å sortere. Verktøy som bare behandler offentlig informasjon og produserer utkast til mennesker, er lavrisiko. Verktøy som behandler personopplysninger eller styrer en handling, er det ikke.

Klassifiser etter konsekvens, ikke etter teknologi

AI Act bruker en risikobasert tilnærming med fire risikonivåer for AI-systemer og forbyr ni praksiser som anses som uakseptabel risiko (EU-kommisjonen). Den logikken er verdt å låne selv om dere ikke er omfattet: risikoen følger av hva systemet gjør mot mennesker, ikke av hvilken modell som ligger under.

I praksis betyr det at du stiller ett spørsmål per bruksområde: hva skjer hvis dette systemet tar feil, og hvem merker det? Feil i et internt møtereferat er en ulempe. Feil i en kredittvurdering, en rekrutteringsscreening eller en tilgangsbeslutning er noe helt annet. Klassifiseringen skal styre hvor mye kontroll du legger på, ikke om du får lov til å bruke teknologien.

Krev leverandørens sikkerhetsdokumentasjon skriftlig

Alura mener at AI-leverandørens sikkerhetsdokumentasjon bør etterspørres skriftlig før avtalen signeres, ikke etter første hendelse. Grunnen er forhandlingsposisjon. Før signering er spørsmålet en del av en kjøpsprosess. Etter en hendelse er det en tvist, og du har allerede tapt tiden.

Minimumsspørsmålene er få og konkrete: hvor behandles og lagres data, brukes våre data til trening, hvordan varsles vi ved sikkerhetshendelse, hvilke underleverandører inngår, og hvilken dokumentasjon finnes på testing av modellen. Et svar du ikke får skriftlig, er ikke et svar. Manglende svar er i seg selv informasjon om hvor moden leverandøren er.

Fem punkter du kan legge inn i risikoregisteret denne måneden

Dette er den delen som faktisk flytter noe. Fem punkter, formulert slik at de kan limes inn i et eksisterende register uten omskriving. De er valgt fordi de dekker de vanligste hendelsesforløpene, ikke fordi de er de mest avanserte.

Nr.	Risikopunkt	Formulering i registeret	Foreslått eier	Første kontroll
1	Ukontrollert AI-bruk	Ansatte deler konfidensielle data i AI-verktøy uten avtale	Sikkerhetsansvarlig	Kartlegging av faktisk bruk
2	AI-drevet sosial manipulering	Phishing, stemme- eller videoforfalskning utløser betaling eller tilgang	Økonomiansvarlig	To-kanals verifikasjon ved endring av betalingsdata
3	Leverandørrisiko i AI-tjenester	Leverandør mangler dokumentert sikkerhet, varslingsplikt eller databehandleravtale	Innkjøpsansvarlig	Skriftlig svar på fem standardspørsmål
4	Manipulasjon av data og input	Dataforgiftning eller adversarial input gir systematisk feil svar	Systemeier	Kildekontroll på kunnskapsbasen
5	Regulatorisk etterslep	Krav i AI Act, NIS2 eller digitalsikkerhetsloven treffer uten forberedelse	Ledergruppen	Avklaring av om virksomheten er omfattet

Slik formulerer du en AI-risiko som er til å måle

En risiko som står som «AI-risiko» i registeret er ubrukelig. Den kan verken vurderes, eies eller lukkes. Formuleringen må inneholde en aktør, en handling og en konsekvens: hvem gjør hva, og hva blir utfallet. «Angriper bruker syntetisk stemme til å godkjenne endring av kontonummer hos leverandør» er noe du kan sette en kontroll på. «Deepfake» er det ikke.

Bruk samme skala som resten av registeret. Hvis dere vurderer sannsynlighet og konsekvens i fem trinn ellers, gjør det her også. Poenget er ikke presisjon i tallene, men at AI-punktene kan sammenlignes med brannrisiko og leverandørsvikt i samme oversikt. Et punkt som ikke kan sammenlignes, blir ikke prioritert.

Hvem som skal eie punktene

Fristelsen er å gi alle fem punktene til IT. Det er feil på tre av dem. Punkt 2 handler om betalingsprosesser og eies av økonomi. Punkt 3 handler om kontrakter og eies av innkjøp. Punkt 5 er en ledelsesbeslutning om hvorvidt virksomheten er omfattet av regelverk, og kan ikke delegeres nedover.

Denne fordelingen er ikke byråkrati. Den er hele poenget med å legge AI-risiko inn i det eksisterende arbeidet: kontrollene som virker, ligger i forretningsprosessene, ikke i sikkerhetsavdelingen. En IT-avdeling kan ikke innføre to-kanals verifikasjon i en betalingsprosess de ikke eier.

Regelverket som treffer deg: AI Act, NIS2 og digitalsikkerhetsloven

AI Act er det første omfattende juridiske rammeverket for AI på verdensbasis, og det trådte i kraft 1. august 2024 og ble gjeldende 2. august 2026 (EU-kommisjonen). Samtidig er nesten 40 prosent av norske private virksomheter ukjente med NIS2-direktivet (kode24, 2025). Det er et betydelig gap mellom hva som er i ferd med å gjelde og hva som er kjent.

Dato	Hva som skjer	Praktisk betydning
1. august 2024	AI Act trer i kraft	Startpunkt for opptrappingen
2. februar 2025	Forbudte praksiser og plikten til AI-kompetanse gjelder	Forbud 1 til 8 er aktive
2. august 2025	Regler for GPAI-modeller gjelder	Krav rettet mot modellleverandørene
27. juli 2026	AI Omnibus trer i kraft	Justeringer i regelverket
2. august 2026	AI Act blir gjeldende	AI Office og nasjonale myndigheter håndhever
Desember 2026	Forbud nummer ni trer i kraft	Siste av de ni forbudte praksisene
2. desember 2027	Strenge forpliktelser for høyrisikosystemer	Den mest krevende fristen for de fleste

AI Act: hva som gjelder deg, og hva som ikke gjør det

AI Act sorterer systemer i fire risikonivåer og forbyr ni praksiser som uakseptabel risiko, der forbud 1 til 8 ble effektive i februar 2025 og forbud 9 trer i kraft i desember 2026 (EU-kommisjonen). Fra 2. august 2026 er AI Office og nasjonale myndigheter ansvarlige for implementering og håndheving, og økt evalueringskapasitet i EU forventes å være operativ i 2027.

For de fleste norske SMB-er er de fleste bruksområdene ikke høyrisiko. Det betyr ikke null forpliktelser. Plikten til AI-kompetanse gjelder bredt, og hvis dere leverer inn i sektorer som kredittvurdering, rekruttering, utdanning eller kritisk infrastruktur, kan dere havne i høyrisikokategorien. Fristen som betyr mest for den gruppen er 2. desember 2027. Det høres langt unna ut. Det er det ikke, hvis dokumentasjonen ikke finnes i dag.

Digitalsikkerhetsloven og NIS2 i Norge

Digitalsikkerhetsloven er vedtatt i Norge, og NIS2-direktivet vil implementeres og omfatte flere virksomheter enn dagens regelverk (Advokatfirmaet Hjort, 2024). Retningen er entydig: flere virksomheter får dokumenterbare sikkerhetskrav, ikke færre. Siden statusen for norsk gjennomføring har flyttet seg underveis, bør du bekrefte gjeldende ikrafttredelse mot myndighetenes egne sider før du setter en dato i planen.

Det praktiske spørsmålet du må avklare denne måneden er ikke hva loven krever i detalj. Det er om dere er omfattet. Svaret avhenger av sektor, størrelse og hvem dere leverer til. Ledergruppen bør ha et skriftlig svar på det spørsmålet, ikke en antakelse.

Underleverandøreffekten treffer før loven gjør det

Selv om dere faller utenfor direkte, kommer kravene ofte via kontrakt. Når kundene deres blir omfattet, sender de kravene videre nedover i kjeden. Det er derfor de nesten fire av ti private virksomhetene som ikke kjenner NIS2 har et problem uansett omfangsvurdering (kode24, 2025).

I praksis betyr det at sikkerhetsdokumentasjon blir et salgsargument før det blir en juridisk plikt. Virksomheter som kan svare raskt og skriftlig på et sikkerhetsvedlegg i en anbudsprosess, vinner tid mot konkurrenter som må begynne å skrive. Dokumentasjon du lager nå, brukes i neste anbud.

Les også: RPA og robotisert prosessautomatisering: Slik frigjør du tid og penger i norske bedrifter. Storebrand reduserte saksbehandlingstiden med 50 %, SpareBank 1 Nord-Norge økte hastigheten med 80 % og ...

NIST-retningslinjene som frivillig arbeidsverktøy

NIST publiserte et andre utkast av retningslinjene for å håndtere misbruksrisiko for dual-use foundation models, med kommentarfrist 15. mars 2025, etter at det første offentlige utkastet kom i juli 2024 og innspill fra mer enn 70 eksperter fra industri, akademia og sivilsamfunn ble innarbeidet (NIST, 2025). Retningslinjene er frivillige. Det er både deres svakhet og deres styrke.

Alura mener at trusselbildet endrer seg raskere enn regelverket, og at virksomheter derfor bør bruke frivillige rammeverk som NIST-retningslinjene som arbeidsverktøy før et tilsyn krever det. Å vente på at en plikt inntreffer er å velge å være uforberedt i mellomtiden.

Hva retningslinjene faktisk inneholder

Kjernen er en struktur for å identifisere, måle og redusere risiko for offentlig og nasjonal sikkerhet gjennom AI-livssyklusen (NIST, 2025). Dokumentet er skrevet med modellutviklere som primærpublikum, ikke norske SMB-er. Det gjør deler av innholdet irrelevant for deg, men strukturen er direkte overførbar.

Den overførbare delen er tredelingen. Identifisering handler om å liste hva som faktisk kan gå galt, ikke hva som er sannsynlig. Måling handler om å teste før utrulling i stedet for å anta. Reduksjon handler om at hvert identifiserte scenario skal ha en navngitt kontroll. Et scenario uten kontroll er ikke håndtert, det er notert.

Slik bruker en SMB dem uten en sikkerhetsavdeling

Ikke prøv å implementere rammeverket. Bruk det som spørsmålsliste i to sammenhenger: når dere vurderer et nytt AI-verktøy, og når dere vurderer en leverandør. Tre spørsmål dekker mesteparten: hva kan dette systemet misbrukes til, hvordan har vi testet at det ikke gjør det, og hvem oppdager det hvis det skjer.

Fordelen med å bruke et anerkjent rammeverk som referanse er sporbarhet. Når et tilsyn, en forsikringsgiver eller en stor kunde spør hvordan dere vurderer AI-risiko, er svaret «vi følger strukturen i NIST-retningslinjene, tilpasset vår størrelse» langt sterkere enn «vi har tenkt på det». Frivillig i dag er ofte forventet i morgen.

Leverandørenes egne sikkerhetsrammeverk

Markedet regulerer også seg selv, i varierende grad. 12 selskaper publiserte eller oppdaterte Frontier AI Safety Frameworks i 2025, og flere AI-selskaper valgte å frigi nye modeller med ekstra sikkerhetstiltak etter at tester ikke kunne utelukke at modellene kunne hjelpe nybegynnere med å utvikle biologiske våpen (arXiv, 2026).

Dette er relevant informasjon i en anskaffelse, men ikke en garanti. Et publisert rammeverk sier at leverandøren har tenkt gjennom problemet og har noe å bli holdt ansvarlig mot. Det sier ingenting om etterlevelse. Spør om rammeverket, og spør deretter om hvordan det etterleves.

Åpen kildekode flytter ansvaret til deg

Åpne modeller gir kontroll, uavhengighet og bedre datastyring. De flytter også hele sikkerhetsansvaret over på den som kjører modellen. Rapporten illustrerer spennet med biologiske AI-verktøy: av 375 undersøkte verktøy hadde bare 3 prosent sikkerhetstiltak, mens flertallet av de høyest presterende var fullt åpen kildekode og 23 prosent av dem hadde høyt misbrukspotensial (techuk.org, 2026).

Overført til en norsk SMB betyr dette en enkel avveining. Velger dere en lukket leverandørtjeneste, kjøper dere sikkerhetsarbeid og gir fra dere kontroll. Velger dere en åpen modell i egen drift, beholder dere kontrollen og arver arbeidet. Begge deler er forsvarlig. Det som ikke er forsvarlig, er å velge åpen modell for kontrollens skyld og så ikke gjøre arbeidet.

Hva International AI Safety Report 2026 sier om testing og tilsyn

Den andre utgaven av International AI Safety Report er skrevet av et team på over 100 eksperter, med et internasjonalt ekspertpanel nominert av representanter fra over 30 land og organisasjoner, og bygger på mandatet fra AI Safety Summit i Bletchley Park i 2023 (arXiv, 2026). Rapporten gir bevisst ingen politiske anbefalinger. Den beskriver hva som er kjent, hva som er usikkert og hvor evidensen mangler.

For en norsk leder er verdien ikke i detaljene om frontmodeller. Den er i to observasjoner som endrer hvordan du bør lese leverandørenes sikkerhetsløfter.

Kapabiliteter vokser raskere enn evidensen

Rapporten slår fast at AI-kapabiliteter utvikler seg raskt, mens vitenskapelig evidens kommer langsommere (techuk.org, 2026). Ledende systemer har nådd gullmedaljenivå på oppgaver fra International Mathematical Olympiad, og rapporten advarer om at AI-systemer nå matcher eller overgår ekspertnivå på benchmarks for biologisk våpenkunnskap. På feilsøking av virologiske laboratorieprotokoller presterte OpenAIs o3-modell bedre enn 94 prosent av domeneekspertene.

Poenget for deg er ikke biovåpen. Det er tempoet. Når kapabilitet vokser raskere enn kunnskapen om hva kapabiliteten medfører, blir enhver risikovurdering ferskvare. En AI-risikovurdering som er 18 måneder gammel, beskriver et annet trusselbilde enn det du står i. Sett en fast revisjonsfrekvens, gjerne knyttet til den samme syklusen som resten av sikkerhetsarbeidet.

Testing før utrulling er blitt vanskeligere å stole på

Den mest ubehagelige observasjonen i rapporten er at pålitelig sikkerhetstesting før utrulling er blitt vanskeligere, fordi modeller kan skille mellom testmiljøer og virkelig utrulling (arXiv, 2026). Konsekvensen er alvorlig for hele bransjens kvalitetssikring: et bestått testresultat er svakere bevis enn det ser ut som.

For deg som kunde betyr dette at du ikke kan basere hele kontrollen på leverandørens forhåndstesting. Du trenger overvåking i drift: logging av hva systemet faktisk gjør, stikkprøver av utfall, og en definert terskel for når mennesker griper inn. Kontroll etter utrulling er ikke et supplement til testing, det er en nødvendig del av opplegget.

Kostnad og ressursbruk for en SMB som starter nå

Her skal vi være ærlige om noe: det finnes ikke et troverdig kronebeløp vi kan sette på dette arbeidet for en generisk norsk SMB, og vi kommer ikke til å finne på et. Kostnaden avhenger av hvor mange AI-systemer dere har, hvor modent styringssystemet er fra før, og om dere er omfattet av NIS2 eller AI Acts høyrisikokategori.

Det vi kan si noe presist om, er hvor kostnaden ligger. For de fleste SMB-er er den ikke i lisenser eller verktøy. Den er i oppmerksomhet fra folk som allerede har fulle kalendere: en leder som må ta stilling til omfangsspørsmålet, en systemeier som må kartlegge faktisk bruk, og en innkjøper som må stille fem spørsmål til hver leverandør.

Det billigste arbeidet gjøres først

Rekkefølgen avgjør kostnaden mer enn omfanget gjør. Kartlegging av faktisk AI-bruk koster lite og styrer alt annet, fordi du ikke kan sikre systemer du ikke vet finnes. Avklaring av om dere er omfattet av regelverket koster lite og avgjør ambisjonsnivået. To-kanals verifikasjon i betalingsprosesser koster nesten ingenting og dekker det hendelsesforløpet som rammer flest.

Det dyre arbeidet er teknisk herding, formell dokumentasjon og eventuell samsvarsvurdering mot høyrisikokravene. Det arbeidet bør ikke starte før du vet om du trenger det. Rekkefølgen gjør at de tre første stegene finansierer beslutningen om de neste.

Hva du ikke bør kjøpe ennå

Markedet for AI-styringsverktøy vokser raskere enn behovet hos en typisk SMB. Et dedikert plattformkjøp for AI-governance er sjelden riktig første investering når du ennå ikke vet hvilke AI-systemer du har eller om du er omfattet av kravene. Verktøy løser ikke et kartleggingsproblem.

Det samme gjelder egne AI-sikkerhetsroller og eksterne sertifiseringer. De er relevante når volumet forsvarer dem. Før det er en avklart eierskapsfordeling i eksisterende roller både billigere og mer effektivt, av samme grunn som at automatisering med robotisert prosessautomatisering gir mest når prosessen er kartlagt først.

Vanlige feil når virksomheter vurderer AI-risiko

Feilene under er ikke hypotetiske. De er mønstre som går igjen, og de har til felles at de gir en følelse av kontroll uten å endre sannsynligheten for at noe går galt.

Feilen: et eget AI-dokument ingen leser

Den vanligste feilen er å skrive en separat AI-risikoanalyse. Den blir grundig, den blir presentert en gang, og så lever den i en mappe. Imens fortsetter det ordinære risikoregisteret uten en eneste AI-post, og det er det registeret som styrer prioriteringene.

Fiks: legg AI-punktene inn i det registeret som faktisk brukes, med samme skala og samme eierskapsmodell som alt annet. Hvis noe må stå i et eget dokument, la det være vedlegget, ikke hovedsaken.

Feilen: å lese lav egenvurdert risiko som trygghet

Når 29 prosent vurderer risikoen for cyberangrep som svært liten eller liten, og de minste vurderer den lavest, er det ikke et uttrykk for at de minste er tryggere (kode24, 2025). Det er et uttrykk for at de har minst grunnlag for vurderingen.

Alura mener at lav egenvurdert risiko i seg selv er et varselsignal. Testen er enkel: be den som mener risikoen er lav om å beskrive hvordan et angrep mot dere ville sett ut i praksis. Hvis svaret er vagt, er ikke risikoen lav, den er bare uutforsket.

Feilen: å vente på at tilsynet definerer nivået

Mange venter på at nasjonale myndigheter skal konkretisere kravene før de gjør noe. Det er forståelig og dyrt. AI Act ble gjeldende i august 2026, håndhevingsapparatet er under oppbygging, og økt evalueringskapasitet i EU forventes operativ i 2027 (EU-kommisjonen). Trusselen venter ikke på den tidslinjen.

Det andre problemet med å vente er kompetanse. Virksomheter som starter nå, bygger forståelse gradvis. Virksomheter som starter når fristen er nær, kjøper konsulenttimer under tidspress. Den samme jobben koster mer når kalenderen styrer.

Ofte stilte spørsmål om AI og sikkerhetsrisiko

Spørsmålene under er de vi oftest får fra ledergrupper som er i gang med å oppdatere risikovurderingen.

Må vi forholde oss til AI Act hvis vi bare bruker en chatbot?

Sannsynligvis ja, men ikke på den tunge måten. AI Act er risikobasert med fire nivåer, og alminnelig bruk av en generell assistent til interne oppgaver havner normalt langt fra høyrisikokategorien (EU-kommisjonen). Plikten til AI-kompetanse hos dem som bruker systemene gjelder likevel bredt, og den løses med opplæring, ikke med dokumentasjonspakker.

Det som endrer bildet er hva chatboten kobles til. I det øyeblikket den behandler personopplysninger, påvirker beslutninger om mennesker eller utfører handlinger i andre systemer, skal den vurderes på nytt. Bruksområdet avgjør, ikke produktnavnet.

Er vi for små til å være et interessant mål?

Nei. Premisset forutsetter at angripere velger mål manuelt, og AI har gjort sosial manipulering både mer troverdig og mer skalerbar (kode24, 2025). Når kostnaden per forsøk faller, blir små virksomheter lønnsomme mål i volum.

I tillegg er små leverandører interessante som vei inn til større kunder. Hvis dere leverer tjenester til en stor aktør, er tilgangen deres verdt mer enn dataene deres. Størrelsen din er ikke beskyttelse, den er bare en annen angrepsvinkel.

Hvem bør eie AI-risikoen internt?

Ledergruppen eier den samlede risikoen, og enkeltpunktene fordeles til dem som eier prosessene. IT eier tekniske kontroller, økonomi eier betalingsprosessene, innkjøp eier leverandørkravene, og systemeier eier datakildene. En AI-risiko uten navngitt eier blir ikke lukket.

Det som ikke fungerer er å opprette en AI-ansvarlig uten mandat i linjen. Vedkommende ender med å skrive dokumenter om prosesser andre kontrollerer. Legg heller ansvaret der handlingsrommet allerede ligger.

Hva gjør vi hvis en ansatt allerede har delt kundedata i et AI-verktøy?

Behandle det som en sikkerhetshendelse i det eksisterende hendelsesløpet: kartlegg hva som ble delt, hvilken tjeneste det gikk til, hvilke vilkår som gjelder for den tjenesten, og om hendelsen er meldepliktig. Deretter gjør du den viktigste delen, som er å finne ut hvorfor det skjedde.

Nesten alltid er svaret at det godkjente alternativet var dårligere eller fantes ikke. Straff løser ikke det problemet, tilgang gjør det. Det var også kjernen i erfaringene fra Samsungs ChatGPT-utrulling.

Trenger vi et eget styringssystem for AI?

De færreste norske SMB-er gjør det. Behovet oppstår når dere utvikler eller leverer AI-systemer selv, eller havner i høyrisikokategorien der strenge forpliktelser gjelder fra 2. desember 2027 (EU-kommisjonen). For alle andre er utvidelse av det eksisterende styringssystemet både raskere og mer holdbart.

Bruk heller den frivillige strukturen fra NIST som referanse for hvordan dere identifiserer, måler og reduserer risiko (NIST, 2025). Det gir sporbarhet uten at dere bygger et parallelt apparat.

Oppsummering: dette avgjør du før neste ledermøte

Bildet er nokså tydelig. En minoritet av norske virksomheter ser AI som en sikkerhetsrisiko, de minste vurderer risikoen lavest, og kjennskapen til kommende krav er svak (kode24, 2025). Samtidig er kapabilitetene i verktøyene angripere bruker godt dokumentert i den internasjonale forskningslitteraturen (arXiv, 2026). Gapet mellom disse to observasjonene er hele saken.

Fire beslutninger er nok til å lukke mesteparten av gapet, og ingen av dem krever budsjett. Er vi omfattet av NIS2 eller digitalsikkerhetsloven? Ledergruppen svarer skriftlig. Hvilke AI-verktøy er faktisk i bruk hos oss? En kartlegging, ikke en anskaffelsesliste. Hvilke prosesser utløser penger eller tilgang på grunnlag av tekst, stemme eller video? De skal ha en kontroll som ikke kan forfalskes. Hva svarer AI-leverandørene våre skriftlig på sikkerhet? Spør før neste kontraktsfornyelse, ikke etter neste hendelse.

Deretter legger du de fem punktene inn i registeret dere allerede har, med eier og første kontroll per punkt. Det er ikke et prosjekt. Det er noen rader i et dokument som allerede eksisterer, og en agendapost i et møte som allerede holdes. Regelverket vil komme etter hvert, med sine frister i AI Act og sin norske gjennomføring av NIS2 (EU-kommisjonen). Arbeidet som betyr noe, gjøres uansett før det.

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

kode24 (2025). Få norske selskaper anser AI som risiko: – De har ikke forstått
EU-kommisjonen. AI Act | Shaping Europe's digital future
arXiv (2026). International AI Safety Report 2026
NIST (2025). Updated Guidelines for Managing Misuse Risk for Dual-Use Foundation Models | NIST
Advokatfirmaet Hjort (2024). Kunstig intelligens utfordrer virksomheters digitale sikkerhet
techuk.org (2026). The release of the international AI safety report 2026: navigating rapid AI advancement and emerging risks