AI-sikkerhetsrutiner for SMB når AI selv kjører angrepene

Nøkkelpunkter per 12. august 2026:

• Safety og security er to ulike problemer: safety er å unngå utilsiktet skade, security er å stå imot bevisste angrep (arXiv, 2025).
• Organisasjoner bruker i snitt 10 AI-applikasjoner i måneden, og de fleste ledere kan ikke liste dem opp uten å gjette (Check Point, 2026).
• Forretningstjenester har den høyeste andelen høyrisiko-prompts, og en merkbar del av AI-interaksjonene der har betydelig risiko for eksponering av sensitive data (Check Point, 2026).
• Bøtetaket i EU AI Act er 35 millioner euro eller 7 prosent av global årsomsetning, avhengig av hva som er høyest (AI Act).
• Langt fra alle leverandører rapporterer substansiell testing for farlige kapabiliteter (CSET, 2025).

---

AI safety og AI security er to ulike problemer

Norske SMB-er tar i bruk AI-verktøy raskere enn de skriver rutiner for dem. Det er en rasjonell prioritering på kort sikt, men den etterlater et hull: når noe går galt, mangler organisasjonen språket til å beskrive hva som faktisk gikk galt. Var det modellen som gjorde noe dumt av seg selv, eller var det noen utenfra som fikk den til å gjøre det? Svaret avgjør hvem som skal rydde opp, og med hvilke virkemidler.

Fagfeltet skiller langs en enkel akse: intensjon. AI safety er egenskapen et AI-system har til å unngå utilsiktede skadelige utfall. AI security er egenskapen til å forbli motstandsdyktig mot bevisste angrep (arXiv, 2025). Resten av denne artikkelen følger av det skillet, og av det faktum at de to henger tettere sammen enn organisasjonskartet ditt antyder.

Safety handler om skade ingen har bestilt

AI safety er praksisen med å designe og bruke AI slik at teknologien er til nytte og minimerer potensiell skade (IBM). I praksis brytes det ned i fire prinsipper: justering mot menneskelige mål, robusthet under skiftende forhold, åpenhet slik at systemet kan revideres, og ansvarlighet for utfallet (Tigera). Ingen av disse handler om en angriper. De handler om at systemet oppfører seg som forutsatt når ingen prøver å ødelegge.

De klassiske eksemplene er kjedelige og dyre: algoritmisk skjevhet i rekruttering, feilidentifikasjon i ansiktsgjenkjenning og ulykker med autonome kjøretøy (Cloud Security Alliance). For en SMB oversettes det til noe mer hverdagslig: en modell som scorer søknader systematisk skjevt, en kundeserviceassistent som gir feil prisinformasjon, en dokumentanalyse som stille slutter å fungere når malen endres. 44 prosent av respondentene i en undersøkelse fra 2024 sa at organisasjonen deres hadde opplevd negative konsekvenser av å bruke AI (IBM). Det er ikke en marginal risiko.

Security handler om noen som vil deg vondt

AI security låner rammeverket fra klassisk informasjonssikkerhet: konfidensialitet, integritet og tilgjengelighet (Cloud Security Alliance). Spørsmålet er ikke om systemet feiler av seg selv, men om noen kan få det til å feile på bestilling, og hva de får ut av det. Check Point beskriver AI-laget i seg selv som en voksende angrepsoverflate (Check Point, 2026).

Forvirringen mellom de to begrepene er ikke akademisk. Den bestemmer hvilket budsjett tiltaket havner i, hvem som får ansvaret, og hvilke tester som blir kjørt. En organisasjon som behandler AI-risiko utelukkende som IT-sikkerhet vil aldri oppdage at modellen diskriminerer. En organisasjon som behandler den utelukkende som etikk vil aldri oppdage at noen tapper den for treningsdata.

Dimensjon	AI safety	AI security
Opphav til risiko	Utilsiktet	Villet
Kjernespørsmål	Gjør systemet noe skadelig av seg selv?	Kan noen få systemet til å gjøre noe skadelig?
Typiske eksempler	Skjevhet i rekruttering, feilidentifikasjon, uforutsigbar ytelse	Prompt injection, dataforgiftning, uttrekk av treningsdata
Kjernebegreper	Justering, robusthet, åpenhet, ansvarlighet	Konfidensialitet, integritet, tilgjengelighet
Naturlig eier	Fag- og produktansvarlig	IT og sikkerhet
Konsekvens ved svikt	Feil beslutninger i stor skala	Datatap, misbruk, driftsstans

Hvorfor skillet betyr noe i praksis

Hvis de to kategoriene var uavhengige, kunne du delegert dem til hver sin avdeling og gått videre. Det er nettopp der de fleste organisasjoner bommer. Koblingen går begge veier, og den går ofte raskt.

Et angrep som ender som en safety-hendelse

Sikkerhetssvikt kan direkte forårsake safety-hendelser (arXiv, 2025). Tenk deg at noen manipulerer datagrunnlaget en prismodell trener på. Angrepet er security. Utfallet, at bedriften i månedsvis priser feil mot en kundegruppe, ser ut som en ren fagfeil. Ingen i IT vil se den, fordi ingen systemer er nede. Ingen i faglinjen vil mistenke angrep, fordi tallene bare ser rare ut.

Dette er hovedgrunnen til at hendelseshåndtering for AI må starte med et bredere spørsmål enn «er vi hacket». Det riktige første spørsmålet er «gjør systemet noe annet enn det skal, og vet vi hvorfor». Årsaken avklares etterpå.

En safety-svakhet som blir en åpning

Motsatt vei: iboende safety-svakheter kan bli utnyttbare sikkerhetsrisikoer (arXiv, 2025). En modell som er litt for hjelpsom, litt for villig til å følge instruksjoner i tekst den leser, er en safety-egenskap. Den samme egenskapen er inngangsporten for indirekte prompt injection. Du kan ikke sikre deg mot det andre uten å forstå det første.

Den praktiske konsekvensen for en SMB er beskjeden i innsats og stor i effekt: samme hendelseskanal, samme risikoregister og samme månedlige gjennomgang. Ikke to spor som møtes en gang i året.

---

Les også: Anthropic former AI-sikkerhet og norske bedrifter må svare. Anthropic bygger frontier-modeller og definerer sikkerhetsstandarden samtidig.

---

Ett risikoregister for både safety og security

Forskningslitteraturen som skiller de to begrepene ender likevel med samme anbefaling: et samlet rammeverk for risikostyring som integrerer safety og security (arXiv, 2025). Alura mener det samme, og av en praktisk grunn: to separate spor produserer to ufullstendige bilder som ingen sammenstiller før det smeller.

For en bedrift med 20 til 200 ansatte trenger dette ikke være tungt. Et regneark med disiplin slår et rammeverk uten eierskap.

Hva registeret faktisk må inneholde

Registeret skal svare på fire ting per AI-bruk: hva kan gå galt, hvor sannsynlig er det, hva koster det, og hvem oppdager det først. Legg merke til det siste feltet. Det er det som skiller et levende register fra et dokument som ble skrevet en gang.

Felt	Hva det skal svare på	Vanlig fallgruve
Bruksområde	Hvilken beslutning eller oppgave AI-en påvirker	Beskrives som «effektivisering» uten konkret oppgave
Risikotype	Safety, security, eller begge	Alt merkes «security» fordi IT eier arket
Datakategori	Hva slags data som går inn og ut	Personopplysninger antas bort
Deteksjon	Hvem eller hva som oppdager avvik, og hvor raskt	Feltet står tomt
Eier	Navngitt person, ikke avdeling	«IT» eller «ledelsen»
Gjennomgått	Dato for siste reelle vurdering	Årlig i teorien, aldri i praksis

Sikkerhet som fortrinn, ikke som skjema

Alura mener sikkerhet og robusthet bør behandles som et strategisk fortrinn, ikke bare en compliance-oppgave (Alura). Argumentet er ikke moralsk. En bedrift som kan dokumentere hvordan AI-verktøyene brukes, hvilke data som går hvor, og hva som skjer når noe feiler, vinner anbud der konkurrenten må be om utsettelse. Innkjøpere i offentlig sektor og større private kunder spør allerede.

Robusthet er evnen et AI-system har til å opprettholde pålitelig ytelse når forholdene endrer seg (Alura). Det er en driftsegenskap, ikke en attest. Den bygges av rutiner, ikke av innkjøp.

For å plassere dere selv før dere begynner: en enkel modenhetsvurdering gir et bedre utgangspunkt enn å kopiere et rammeverk fra et konsern med egen sikkerhetsavdeling.

Første steg er å telle AI-appene dere faktisk bruker

Alura mener at første steg for de fleste SMB-er er å kartlegge hvilke AI-verktøy som faktisk er i bruk, før nye verktøy kjøpes inn. Det høres trivielt ut helt til man gjør det.

Organisasjoner bruker i gjennomsnitt 10 AI-applikasjoner hver måned (Check Point, 2026). Nesten ingen ledere kan liste opp ti uten å gjette. Differansen mellom det du tror er i bruk og det som er i bruk er hele risikobildet ditt.

Skygge-AI er normalen, ikke unntaket

Ansatte tar i bruk AI-verktøy fordi de løser en reell friksjon samme dag. Godkjenningsprosessen tar seks uker. Regnestykket er enkelt for den enkelte, og dårlig for bedriften. Resultatet er at sensitive data havner i tjenester ingen har vurdert, under vilkår ingen har lest.

Forbud fungerer dårlig som eneste virkemiddel, blant annet fordi de flytter bruken til privat utstyr der du mister all innsyn. Samsung-saken er verdt å lese nettopp fordi den viser hvor raskt en velmenende ansatt kan skape et problem som ikke lar seg reversere.

En kartlegging som tar en uke

Fremgangsmåten er lite glamorøs. Hent uttrekk fra nettverksloggene eller nettleseradministrasjonen på hvilke AI-domener som besøkes. Gå gjennom fakturaer og kortutlegg for abonnementer under 500 kroner måneden, som er der de fleste verktøy gjemmer seg. Spør hvert team direkte, uten sanksjonstrussel, hva de bruker og til hva. Sjekk hvilke AI-funksjoner som allerede er slått på i systemene dere har fra før, siden mange leverandører har aktivert dem uten særlig varsel.

Det siste punktet overraskes folk oftest av. En stor del av AI-bruken i en SMB i 2026 er ikke innkjøpt som AI. Den kom som en oppdatering i et CRM, et e-postsystem eller et regnskapsprogram.

Hva kartleggingen skal ende i

Sluttproduktet er en liste med nok kolonner til å ta beslutninger, og ikke flere. Hvis arket krever mer enn en time å oppdatere per kvartal, blir det ikke oppdatert.

Verktøy	Hvem bruker det	Datatype inn	Status	Eier
Generell chat-assistent	Alle avdelinger	Utkast, interne notater	Godkjent, med dataregler	Navngitt leder
Møtereferat-tjeneste	Salg, ledelse	Lyd fra kundemøter	Under vurdering	Salgssjef
Kodeassistent	Utvikling	Kildekode	Godkjent, egen instans	Teknisk leder
AI i CRM	Salg	Kundeopplysninger	Aktivert av leverandør, ikke vurdert	Ingen
Bildegenerering	Marked	Ingen sensitive data	Godkjent	Markedssjef

Den fjerde raden i tabellen over er den viktigste. «Aktivert av leverandør, ikke vurdert» er den vanligste statusen i en ærlig kartlegging, og den som kostet minst å oppdage nå.

Datasøl gjennom GenAI er den nærmeste risikoen

For de fleste norske SMB-er er ikke det mest sannsynlige AI-problemet et sofistikert angrep. Det er en ansatt som limer inn feil dokument i feil verktøy. Check Point beskriver datasøl gjennom GenAI som en vedvarende og voksende risiko (Check Point, 2026), og det er den risikoen som treffer raskest, oftest og med minst forvarsel.

Hvor stort problemet faktisk er

Forretningstjenester er bransjen med høyest andel høyrisiko-prompts i GenAI-bruk, og en merkbar del av AI-interaksjonene der har betydelig risiko for eksponering av sensitive data (Check Point, 2026). Regn selv på hvor mange AI-forespørsler en avdeling på ti personer sender i løpet av en arbeidsdag, og hvor mange av dem som da havner i risikokategorien.

Andelen høyrisiko-prompts har steget i løpet av det siste året (Check Point, 2026). Retningen er tydeligere enn nivået: bruken modnes, og med den øker mengden sensitivt materiale som legges inn.

Hva som faktisk lekker

Det er sjelden passord. Det er kontraktsutkast som limes inn for oppsummering, kundelister som limes inn for segmentering, kildekode som limes inn for feilsøking, og personalsaker som limes inn for formulering. Alle fire er rasjonelle handlinger fra en ansatt som prøver å gjøre jobben raskere.

Skaden avhenger av hva tjenesten gjør videre med innholdet, om det brukes til trening, hvor lenge det lagres og hvem som kan hentes inn i en rettsprosess. Det er nettopp derfor kartleggingen kommer først: du kan ikke vurdere vilkår for tjenester du ikke vet at brukes.

Fire tiltak som demper det raskt

Ett godkjent verktøy med bedriftsvilkår fjerner mesteparten av problemet, fordi de fleste ansatte bruker det som er lett tilgjengelig og lovlig. En dataklassifisering på tre nivåer holder: fritt, internt, aldri. Ansatte husker tre kategorier, ikke sju. Konkrete eksempler i opplæringen virker bedre enn prinsipper, fordi «ikke lim inn kundeavtaler» er handlingsbart mens «utvis aktsomhet» ikke er det.

Det fjerde tiltaket er det som oftest hoppes over: en trygg kanal for å melde fra om at man har limt inn noe man ikke burde. Uten den får du aldri vite om hendelsene, og da kan du heller ikke begrense dem.

Trusselbildet i 2026 når AI går fra hjelpemiddel til angrepsoperatør

Frem til nylig var AI et effektiviseringsverktøy for angripere: bedre phishing-tekster, raskere rekognosering. Check Point beskriver et skifte fra utviklingshjelp til aktiv angrepsoperatør (Check Point, 2026). Forskjellen er at kapasitet ikke lenger er begrensningen.

Malware som bygges ferdig, ikke bare foreslått

AI bygger nå distribusjonsklare malware og angrepssuiter (Check Point, 2026). Et konkret eksempel er VoidLink, et kommando- og kontroll-rammeverk på 88 000 linjer produsert av en enkelt utvikler med AI-assistanse. Volumet er poenget: den slags produksjon krevde tidligere et team.

Deteksjoner av lengre ondsinnede nyttelaster økte omtrent femdobbelt mellom mars og mai 2026, og de utgjorde da en liten, men målbar andel av observerte prompts (Check Point, 2026). Andelen høres beskjeden ut. Den er ikke beskjeden når grunnmengden er alle prompts.

Et modent kriminelt marked, og identitet som ikke lenger holder

Angripere foretrekker kommersielle modeller og misbruker agentisk arkitektur fremfor å bygge egne modeller, og det har vokst frem et modent kriminelt verktøymarked for AI (Check Point, 2026). Konsekvensen for en SMB er at angrepskvaliteten ikke lenger korrelerer med angriperens kompetanse. Du kan bli truffet av noe godt laget av noen som ikke kan lage det selv.

Den delen som treffer norske bedrifter hardest på kort sikt: virtuell identitet er ikke lenger et pålitelig tillitsanker (Check Point, 2026). Stemme, video og skrivestil kan produseres troverdig nok. Rutiner som hviler på gjenkjennelse, som «jeg hørte at det var daglig leder på telefonen», er ikke lenger rutiner. Betalingsgodkjenning må hvile på noe som ikke kan syntetiseres: et separat system, en kjent kanal, en fast beløpsgrense.

Angrepstypene å kjenne igjen

Du trenger ikke være sikkerhetsekspert for å ha nytte av å kjenne fem angrepsmønstre. Du trenger dem for å stille de riktige spørsmålene til leverandøren, og for å vite hva du skal se etter når noe oppfører seg rart. Tallene i tabellen under er hentet fra en gjennomgang av 109 statistikker fra 34 primærkilder (worldmetrics, 2026).

Angrepstype	Hva som skjer	Dokumentert omfang	Første mottiltak
Prompt injection	Instruksjoner smugles inn i tekst modellen leser	Indirekte injection er økende	Begrens hva agenten har lov til å gjøre
Adversarielle input	Bittesmå endringer i inndata gir feil svar	75 prosent av ML-modeller er sårbare	Menneskelig kontroll på kritiske utfall
Dataforgiftning	Treningsdata manipuleres for å plante bakdør	45 prosent av produksjonsmodeller berørt	Kjenn opphavet til modell og data
Uttrekk av treningsdata	Modellen gjengir det den har memorert	59 prosent lekket sensitiv treningsdata i revisjoner	Ikke tren på ufiltrerte kundedata
Forsyningskjede	Ondsinnede pakker og modeller hentes inn	56 prosent forekomst i ML-pakker på PyPI	Lås avhengigheter, skann artefakter

Prompt injection, direkte og indirekte

Direkte prompt injection er brukeren som prøver å overtale modellen til å bryte reglene sine. Indirekte prompt injection er mer alvorlig: instruksjonene ligger i innholdet modellen leser, i en nettside, et vedlegg eller en e-post, og brukeren ser dem aldri. Check Point melder at indirekte prompt injection er økende (Check Point, 2026).

Rollebaserte jailbreaks mot GPT-4 har hatt 61 prosent suksessrate i dokumenterte tester av overdreven handlingsfrihet (worldmetrics, 2026). Problemet er strukturelt og ikke løst av bedre modeller alene, slik vår tidligere gjennomgang av prompt injection viser i praksis. Den praktiske regelen er streng: en AI-agent som både leser upålitelig innhold og har rettigheter til å handle, er en risiko uansett hvor god modellen er.

Adversarielle input og hvor lite som skal til

75 prosent av maskinlæringsmodeller er sårbare for motstridende angrep, der bittesmå endringer i inndata er nok til å utløse feilklassifisering (worldmetrics, 2026). I 2023 lyktes motstridende eksempler i å lure 92 prosent av testede synsmodeller med forstyrrelser usynlige for mennesker, og black-box-angrep har oppnådd over 95 prosent suksessrate mot 50 eller flere kommersielle AI-API-er.

Skalaen er verdt å feste seg ved: forskjellen mellom et vanlig bilde og et adversarielt bilde kan være så liten som 0,0078 i maksimal pikselforskjell, mens modellen klassifiserer de to som helt forskjellige ting med 99 prosent sikkerhet (Alura). For en SMB betyr det at automatisk bildegjenkjenning i kvalitetskontroll, adgang eller dokumentflyt trenger en menneskelig kontroll på utfallene som koster mest å ta feil av.

Forgiftning og bakdører i modeller

45 prosent av AI-modeller i produksjon er forgiftet med bakdør-triggere under trening, og for føderert læring har dataforgiftning gitt 30 til 50 prosent nedgang i nøyaktighet i 80 prosent av testede oppsett (worldmetrics, 2026). Terskelen er lav: forskere plantet en trojaner i en bildeklassifiserer ved å endre bare 300 av 3 millioner treningsbilder (Wikipedia).

De fleste SMB-er trener ikke egne modeller, og det er en fordel. Men mange finjusterer, og mange henter ferdige modeller fra åpne repositorier. Da arver du leverandørkjedens risiko: 42 prosent av Hugging Face-modeller bruker sårbare oppstrømsavhengigheter, og ondsinnede MLflow-artefakter på offentlige repositorier økte med 29 prosent i 2024 (worldmetrics, 2026).

Lekkasje fra modellen og fra oppsettet

Modeller husker mer enn de burde. 72 prosent av finjusterte GPT-modeller gjengir personopplysninger fra treningsdata på oppfordring, og medlemskapsinferens har opptil 95 prosent suksessrate mot overparametriserte språkmodeller (worldmetrics, 2026). Hvis du finjusterer på kundedata, må du anta at deler av dem kan hentes ut igjen.

Den kjedeligste kategorien er også den vanligste: feilkonfigurasjon. 76 prosent av språkmodeller på offentlige endepunkter uten rate limiting er eksponert, og i 2023 ble 49 prosent av tilgangskontroller omgått via feilkonfigurert IAM i SageMaker (worldmetrics, 2026). Dette er ikke AI-problemer. Det er skyproblemer i AI-drakt, og de løses med de samme rutinene du allerede burde ha.

---

Les også: AI-modenhet i norske bedrifter: Hvor står din bedrift på skalaen?. Hvor moden er din bedrift på AI?

---

Sikkerhet er en livssyklus-oppgave, ikke en portvakt

Alura mener sikkerhet er en livssyklus-oppgave, fordi tester før utrulling ikke pålitelig forutsier ytelse i den virkelige verden (Alura). Det er ikke en marginal presisering. Det river bort grunnlaget for den vanligste modellen: en grundig godkjenning i starten, deretter stillhet.

Bevisdilemmaet

International AI Safety Report ledes av Turing-prisvinner Yoshua Bengio, er skrevet av over 100 uavhengige eksperter og er støttet av over 30 land og internasjonale organisasjoner (International AI Safety Report). 2026-utgaven er den andre i rekken. Den første kom i 2025, skrevet av 96 eksperter og bestilt av 30 nasjoner og FN (Wikipedia).

Rapporten peker på et bevisdilemma: landskapet endrer seg raskt, mens dokumentasjon på risiko og virkningen av tiltak kommer sakte. Pre-deployment-tester er ikke pålitelige for å forutsi hva som skjer i den virkelige verden (Hadfield, 2026). Konsekvensen for en SMB er ikke lammelse. Den er at overvåking etter utrulling må ha samme prioritet som godkjenning før.

Menneskene degraderes også

Den mest urovekkende funnet i denne kategorien handler ikke om modellen. International AI Safety Report 2026 omtaler en studie der legers evne til å oppdage svulster under koloskopi ble svakere etter flere måneder med AI-assistanse (Alura). Systemet fungerte. Menneskene rundt det endret seg.

Dette har direkte overføringsverdi til en SMB som setter AI inn i kvalitetskontroll, saksbehandling eller kundedialog. Hvis kontrollmekanismen din er «en erfaren medarbeider ser over», må du regne med at den mekanismen svekkes over tid nettopp fordi AI-en stort sett har rett. Stikkprøver må derfor være systematiske og ikke basert på magefølelse.

En driftsrytme som faktisk holder

OECD trekker den logiske konsekvensen: sikkerhet er en livssyklus-oppgave (Alura). Oversatt til en kalender for en bedrift med begrenset kapasitet: ukentlig gjennomgang av avvik og feilmeldinger, månedlig gjennomgang av risikoregisteret med de navngitte eierne, kvartalsvis oppdatering av verktøykartleggingen, og en årlig gjennomgang av leverandørvilkår og databehandleravtaler.

Legg til to utløsere som overstyrer kalenderen: leverandøren bytter modell, og dere endrer hva systemet får lov til å gjøre. Begge nullstiller antakelsene testene hvilte på. En modelloppdatering du ikke ba om er en endring i produksjon, uansett hva leverandøren kaller den.

Datoene og bøtenivåene i EU AI Act

EU AI Act trådte i kraft 2. august 2024 og gjelder direkte i hele EU, med en risikobasert tilnærming og fire risikokategorier (DETE). Kategoriene er uakseptabel, høy, begrenset og minimal risiko (AI Act). Regelverket innføres trinnvis over 36 måneder.

For norske bedrifter er det viktigste å avklare hvilken kategori dere faller i, og i hvilken rolle. De fleste SMB-er er ikke leverandører av høyrisikosystemer. Men mange er brukere av systemer som blir regulert, og noen leverer inn i verdikjeder der kravene sildrer nedover som kontraktskrav lenge før tilsyn banker på.

Tidslinjen som gjelder

Dato	Hva som trer i kraft	Hva det betyr for en SMB
August 2024	Forordningen trer i kraft	Klokken starter, ingen umiddelbare plikter
Februar 2025	Forbud mot uakseptabel risiko	Sjekk at ingen bruk faller i forbudt kategori
August 2025	Regler for GPAI-modeller	Leverandørkravene begynner å prege vilkårene dere får
August 2026	Hoveddelen av reglene håndheves, inkludert Annex III-høyrisiko	Dokumentasjon og tilsynsfullmakter blir reelle
August 2027	Produktrelaterte høyrisikosystemer	Relevant for de som leverer AI i fysiske produkter

Datoene er hentet fra irske myndigheters gjennomgang (DETE) og en samsvarsoversikt fra Nemko (Nemko Digital). Merk at tilsynsmyndighetene får utvidede fullmakter fra 2. august 2026. Et EU AI Act Service Desk ble lansert 8. oktober 2025 for spørsmål om etterlevelse, og en Digital Omnibus ble foreslått 19. november 2025 med mål om å redusere etterlevelseskostnader. Det siste er verdt å følge med på, men ikke å basere en utsettelse på.

Tersklene og Code of Practice

EU publiserte en Code of Practice for generell AI i juli 2025 for å hjelpe leverandører med etterlevelse. Den er frivillig, men gir en presumsjon om samsvar som insentiv (CSET, 2025). Sikkerhetskapitlet er det mest omfattende av de tre og krever at leverandører vurderer fire spesifiserte risikoer: CBRN, tap av kontroll, cyberoffensiv kapasitet og skadelig manipulasjon.

Tersklene er tekniske, men nyttige å kjenne: 10^23 i treningsberegning for å regnes som en GPAI-modell, og 10^25 for å regnes som en modell med systemisk risiko (CSET, 2025). Terskelen på 10^25 FLOPs kan justeres etter hvert som teknologien utvikler seg, og kodeksen ble utviklet med innspill fra over tusen interessenter (AI Frontiers). Ingen SMB i Norge trener modeller i den størrelsesordenen. Poenget er at kravene som stilles til leverandørene deres former hva dere selv får se av dokumentasjon.

AI Act henviser til etablert praksis for cybersikkerhet uten å gi en detaljert implementeringsramme, og ISO/IEC 42001 er rammeverket som er tilpasset styring av AI (BSI). For en SMB er full sertifisering sjelden riktig førstevalg. Å bruke strukturen som sjekkliste er nesten alltid nyttig.

Bøtenivåene setter prislappen på å la være

Type brudd	Maksbot	Andel av global omsetning
Brudd på forbudene i artikkel 5	35 millioner euro	7 prosent
Andre operatørplikter	15 millioner euro	3 prosent
Uriktig eller villedende informasjon	7,5 millioner euro	Laveste av de tre satsene

Det høyeste av kronebeløp og omsetningsandel gjelder (AI Act). Håndhevingen kombinerer nasjonale myndigheter med et nytt europeisk AI-styre (Nemko Digital). For en norsk SMB er sannsynligheten for en maksbot lav. Den relevante kostnaden er en annen: tapte anbud, forsinkede leveranser til kunder som krever dokumentasjon, og ryddearbeid som må gjøres uansett, bare dyrere og under tidspress.

Til sammenligning kan tjenesteleverandører under kinesisk lov ilegges opptil 50 millioner RMB eller 5 prosent av omsetningen (Alura). Retningen er den samme i flere jurisdiksjoner, og det gjør det vanskelig å argumentere for at dette er en forbigående EU-øvelse.

Markedsobservasjon: leverandørene rapporterer svært ulikt

Når du kjøper AI, kjøper du også leverandørens sikkerhetsarbeid. Da er det ubehagelig relevant hvor lite av det som er synlig utenfra.

Testing for farlige kapabiliteter dokumenteres sjelden

Langt fra alle gjennomgåtte selskaper rapporterer substansiell testing for farlige kapabiliteter, og offentlig innsyn i leverandørenes prosesser er begrenset (CSET, 2025). Code of Practice krever at leverandører definerer akseptable risikonivåer på forhånd og ikke justerer dem fleksibelt underveis, noe som i seg selv er en innstramming mot dagens praksis.

Samtidig går utviklingen riktig vei på ett punkt: antall selskaper som publiserer Frontier AI Safety Frameworks har mer enn doblet seg siden 2025-rapporten (International AI Safety Report), med 12 selskaper som publiserte eller oppdaterte slike rammeverk i 2025 (Alura). Publisert rammeverk er ikke det samme som verifisert etterlevelse, og det er nettopp derfor uavhengige verifikasjonsorganisasjoner diskuteres som neste steg (Hadfield, 2026).

Bare 3 prosent av teknisk AI-forskning retter seg mot å gjøre AI tryggere (IBM). Det er kontekst verdt å ha med når en leverandør sier at sikkerhet er høyeste prioritet. Vi har sett nærmere på hvordan enkelte aktører posisjonerer seg på dette i en gjennomgang av Anthropics tilnærming.

Spørsmålene som avslører mest i en anskaffelse

Fem spørsmål gir mer informasjon enn en hel due diligence-mal. Hva skjer med dataene våre, konkret, og hvor lenge lagres de? Trenes modeller på innholdet vårt, og kan vi reservere oss? Hvordan varsles vi når dere bytter eller oppdaterer modellen bak tjenesten? Hva har dere testet for, og kan vi se dokumentasjonen? Hvem er teknisk kontaktpunkt ved en hendelse, og hva er responstiden?

Svarene betyr mindre enn måten de gis på. En leverandør som svarer presist på tre av fem og sier «det vet vi ikke» på to, er som regel tryggere enn en som svarer glatt på alle fem. Uklarhet rundt modellbytte er det tydeligste faresignalet, fordi det er der endringene i praksis skjer uten at du merker det.

Vanlige feil når SMB-er skal sikre AI-bruken

Feilene under er gjengangere, og de har det til felles at de føles som fremdrift mens de pågår.

Feilene som handler om organisering

Å kjøpe før man teller. Et nytt AI-verktøy anskaffes for å «få kontroll», mens de ti verktøyene som allerede er i bruk fortsatt ikke er kartlagt. Resultatet er elleve verktøy og samme oversikt som før. Å dele safety og security i to spor. IT eier sikkerhet, faglinjen eier kvalitet, og hendelser som krysser grensen faller mellom dem.

Å skrive en policy ingen leser. Et fire siders dokument om ansvarlig AI-bruk er en compliance-artefakt, ikke en rutine. Tre konkrete regler som alle husker slår det hver gang. Å ikke navngi en eier. Risikoregistre med «IT» eller «ledelsen» i eierkolonnen oppdateres aldri, fordi ingen konkret person våkner med ansvaret.

Feilene som handler om teknikk og drift

Å gi agenten for brede rettigheter. En assistent som både leser innkommende e-post og kan sende ut eller endre data, kombinerer upålitelig input med handlingsevne. Det er den farligste enkeltkonfigurasjonen i AI-drift akkurat nå. Å teste en gang og anse saken som avgjort. Tester før utrulling forutsier ikke pålitelig ytelse i virkeligheten, og en modelloppdatering hos leverandøren nullstiller forutsetningene.

Å behandle skyhygiene som løst. Endepunkter uten rate limiting og feilkonfigurert tilgangsstyring er fortsatt blant de vanligste inngangene, og de har lite med AI å gjøre (worldmetrics, 2026). Å stole på gjenkjennelse. Godkjenningsrutiner som hviler på at man kjenner igjen stemmen eller ansiktet, er utdaterte når virtuell identitet ikke lenger er et pålitelig tillitsanker.

En siste feil fortjener egen omtale: å automatisere en prosess som ikke var kontrollert fra før. AI forsterker det som allerede finnes, også rotet. Prinsippet fra tradisjonell prosessautomatisering gjelder også her, bare med mindre forutsigbare utfall.

Ofte stilte spørsmål om AI-sikkerhetsrutiner

Spørsmålene under er de vi oftest møter fra ledere i bedrifter mellom 20 og 200 ansatte.

Er dette relevant for oss når vi bare bruker en chat-assistent?

Ja, og sannsynligvis mer enn du tror. Datasøl gjennom GenAI er en vedvarende og voksende risiko, og den utløses av vanlig bruk og ikke av avanserte oppsett (Check Point, 2026). Dessuten bruker organisasjoner i snitt langt flere AI-applikasjoner enn de tror. «Bare en chat-assistent» er som regel en antakelse, ikke et funn.

Må vi følge EU AI Act når vi er i Norge?

Forordningen gjelder leverandører, utviklere og distributører av AI-systemer som gjøres tilgjengelig på EU-markedet (BSI). Selv der plikten ikke treffer direkte, treffer den indirekte gjennom kunder, leverandører og kontraktskrav. De fleste norske SMB-er vil møte kravene som spørsmål i en anbudsprosess lenge før de møter dem som tilsyn.

Hva er forskjellen på safety og security i praksis for oss?

Safety er spørsmålet om systemet gjør noe skadelig av seg selv. Security er spørsmålet om noen kan få det til å gjøre noe skadelig. Skillet ligger i intensjon (arXiv, 2025). I praksis trenger dere begge svarene i samme dokument, fordi feil i den ene kategorien blir til hendelser i den andre.

Hvor mye tid krever dette per måned?

For en bedrift med under 100 ansatte og et moderat antall AI-verktøy er en realistisk ramme noen timer i måneden til gjennomgang av avvik og register, pluss en større kvartalsvis oppdatering. Kartleggingen i starten er den tyngste jobben. Etter den er det vedlikehold, forutsatt at eierne er navngitt.

Bør vi forby ansatte å bruke AI-verktøy vi ikke har godkjent?

Et forbud uten et godt godkjent alternativ flytter bruken til privat utstyr, der du mister all innsyn og all logging. Kombinasjonen som fungerer er et lett tilgjengelig godkjent verktøy, tre tydelige dataregler og en trygg meldekanal for feil. Kontroll oppnås gjennom at det godkjente valget er det enkleste valget.

Oppsummering og neste steg

Det som skiller bedrifter som håndterer AI-risiko godt fra de som ikke gjør det, er sjelden budsjettet. Det er om noen faktisk vet hva som er i bruk, og om noen ser etter når det endrer seg.

De fire tingene som betyr mest

For det første: skill mellom utilsiktet skade og villet angrep i språket, men samle dem i ett risikoregister. For det andre: tell AI-verktøyene før dere kjøper flere, og regn med å bli overrasket. For det tredje: behandle datasøl gjennom GenAI som den nærmeste risikoen, fordi den er hyppigst og billigst å dempe. For det fjerde: sett opp overvåking etter utrulling, siden tester på forhånd ikke forutsier virkeligheten.

Legg merke til at ingen av de fire krever nye verktøy. Tre av dem krever en navngitt person og en fast kalenderoppføring.

Slik ser de første tretti dagene ut

Uke 1: kartlegg AI-bruken gjennom logger, fakturaer og direkte spørsmål til hvert team. Uke 2: klassifiser data i tre nivåer og bestem hvilket verktøy som er det godkjente førstevalget. Uke 3: opprett risikoregisteret med navngitte eiere og fyll det med det dere fant i uke 1. Uke 4: gå gjennom leverandørvilkårene for de tre viktigste verktøyene, og avklar spesielt hva som skjer ved modellbytte.

Etter tretti dager har dere ikke løst AI-sikkerhet. Dere har noe mer nyttig: en presis oversikt over hva som faktisk er i bruk, hvem som eier hva, og hvilke to eller tre risikoer som er verdt å bruke penger på. Det er utgangspunktet alle senere beslutninger hviler på, og det er også det EU-kravene og kundenes spørreskjemaer i praksis ber om.

I Alura bygger vi AI-infrastruktur for norske virksomheter, fra dataplattformer til agentiske systemer i produksjon. Vi er ikke en SaaS-leverandør. Vi er håndverkere som setter sammen byggesteinene som faktisk fungerer for din situasjon.

Bestill en arkitektur-samtale: vi går gjennom din nåværende infrastruktur, identifiserer integrasjonspunkter, og foreslår en pragmatisk vei videre. Uforpliktende, 45 minutter.

Kilder

• arxiv.org. AI Safety vs. AI Security: Demystifying the Distinction and Boundaries
• research.checkpoint.com. AI Security Report 2026 - Check Point Research
• en.wikipedia.org. Artificial Intelligence Act
• cset.georgetown.edu. AI Safety under the EU AI Code of Practice — A New Global Standard?
• ibm.com. What Is AI Safety? | IBM
• tigera.io. Understanding AI Safety: Principles, Frameworks, and Best ...
• cloudsecurityalliance.org. AI Safety vs. AI Security: Navigating the Differences
• alura.no. AI-sikkerhet gir SMB-er forsprang før EU-kravene treffer | Alura
• worldmetrics.org. Ai Security: 2026 Verified Stats
• en.wikipedia.org. AI safety - Wikipedia
• internationalaisafetyreport.org. International AI Safety Report
• linkedin.com. 2026 AI Safety Report Highlights Thin Scientific Foundation ...
• enterprise.gov.ie. EU AI Act - DETE
• digital.nemko.com. EU AI Act Regulation: Key Rules & Compliance Guide | Nemko Digital
• ai-frontiers.org. How the EU's Code of Practice Advances AI Safety | AI Frontiers
• bsigroup.com. The EU AI Act and its interactions with Cybersecurity Legislation | BSI