AI-leverandører skårer i snitt 22 prosent på risikostyring

Nøkkelpunkter per 26. september 2026:

• 22 prosent er gjennomsnittsskåren når tolv AI-selskapers sikkerhetsrammeverk måles mot 65 vektede kriterier for risikostyring (safer-ai.org, 2026).
• Fristene er korte: 24 timer ved overhengende fare for død eller alvorlig skade under SB 53, og 72 timer for kritiske sikkerhetshendelser under RAISE Act (metr.org, 2026).
• Be om en safety case, definert som et strukturert argument støttet av bevis for at modellens risiko er tilstrekkelig håndtert (OpenAI).
• Illinois SB 315 krever at hver stor utvikler årlig hyrer en uavhengig tredjepart til å revidere etterlevelse, med virkning fra 1. januar 2028 (metr.org, 2026).
• EUs AI Act kan håndheves av EU AI Office fra 2. august 2026, og Code of Practice krever sporing og rapportering av alvorlige hendelser (metr.org, 2026).

---

Frontier AI safety framework: hva begrepene faktisk betyr

Når en AI-leverandør sier at de har et «safety framework», mener de sjelden det samme som du gjør. Begrepet kommer fra et lite miljø av selskaper som bygger de største modellene, og det beskriver en intern policy for hvordan selskapet vurderer og håndterer risiko underveis i utviklingen. Google DeepMind kaller sine mest kraftfulle grunnmodeller for frontier-modeller, og har bygget et eget rammeverk rundt nettopp dem (Google DeepMind). For deg som kjøper er poenget enkelt: dette er selvpublisert dokumentasjon, ikke en sertifisering du kan slå opp i et register.

Det gjør ikke dokumentene verdiløse. De er som regel det eneste stedet leverandøren skriver ned hva den faktisk tester for, hvilke terskler som utløser tiltak, og hvem internt som eier beslutningen. Alura mener publiserte sikkerhetsrammeverk er et utgangspunkt for samtalen, ikke et bevis på at risikoen er håndtert. Forskjellen mellom de to lesningene avgjør hvor mye du får ut av neste leverandørmøte.

Frontier-modeller og hvorfor ordet dukker opp i kontrakter

Et frontier-rammeverk gjelder de mest kapable modellene et selskap utvikler. Google DeepMind beskriver sitt Frontier Safety Framework som et rigorøst og proaktivt system for å holde modellene trygge, og bruker det sammen med selskapets AI-prinsipper (Google DeepMind). Rammeverket er versjonert, og har gått fra 1.0 via 2.0 og 3.0 til 3.1. Versjonsnummeret er i seg selv en nyttig opplysning: det forteller deg at innholdet endrer seg, og at dokumentet du leste i fjor ikke nødvendigvis er det som gjelder i dag.

Ordet har begynt å dukke opp i avtaletekst fordi lovgivere har tatt det i bruk. Californias SB 53 krever at store frontier-utviklere publiserer et «frontier AI framework» på nettstedet sitt, og forpliktelsene i rammeverket er juridisk bindende (metr.org, 2026). Det betyr at et dokument som tidligere var frivillig markedskommunikasjon, nå kan være en forpliktelse leverandøren kan holdes til.

Et rammeverk er en policy, ikke en sertifisering

ISO-sertifisering, revisorberetninger og SOC 2-rapporter har en ting til felles: en uavhengig part har sett på bevisene. Et frontier-rammeverk har ikke nødvendigvis vært gjennom noe slikt. Det er selskapets egen beskrivelse av hvordan selskapet mener risiko bør håndteres. Skillet mellom «vi har en policy» og «noen har verifisert at vi følger den» er den viktigste distinksjonen i hele dette temaet.

Derfor er det uavhengige laget verdt å be om eksplisitt. OpenAI har skissert prinsipper for tredjepartsvurderinger og sier selskapet forplikter seg til å støtte uavhengige vurderinger med dyp tilgang på tvers av trening, evaluering og utrulling (OpenAI). Når en leverandør beskriver hvilken tilgang en tredjepart faktisk får, har du noe konkret å vurdere. Når leverandøren bare viser til at rammeverket finnes, har du en brosjyre.

Hvorfor dette angår deg selv om du bare kjøper en API

De færreste norske SMB-er trener egne modeller. De kjøper tilgang, ofte gjennom et mellomledd, og bygger noe på toppen. Risikoen forsvinner ikke av den grunn: den flytter seg til grensesnittet mellom deg og leverandøren. Hvis leverandørens modell oppfører seg uventet i din bruk, er det du som møter kunden, tilsynet eller pressen. Hvordan du velger leverandør er derfor et forretningsvalg før det er et teknisk valg (kriterier for leverandørvalg).

Det praktiske utslaget er at du trenger to ting fra leverandøren: dokumentasjon du kan lese og varslingsplikter du kan planlegge rundt. Begge deler finnes allerede, fordi regelverket krever dem av leverandøren uansett om du spør. Spørsmålet er om du får dem inn i avtalen din, eller om de blir liggende i leverandørens eget system.

Hva SaferAI måler i de 65 kriteriene

Analysemiljøet SaferAI har gått gjennom sikkerhetsrammeverkene til tolv selskaper og målt dem mot 65 vektede kriterier for risikostyring (safer-ai.org, 2026). Kriteriene handler ikke om hvor god modellen er, men om hvor disiplinert selskapet er i måten det identifiserer, måler og følger opp risiko på. Det er nettopp den disiplinen en innkjøper kan etterspørre og etterprøve.

Resultatet er ubehagelig lesning for et marked som selger tillit: gjennomsnittsselskapet skårer 22 prosent. Samtidig peker analysen på at snittet kunne vært løftet til 59 prosent hvis selskapene tok i bruk praksiser som allerede finnes hos konkurrentene (safer-ai.org, 2026). Ingen trenger å oppfinne noe nytt. De må bare kopiere hverandres beste vaner.

Gapet mellom dagens praksis og det som allerede finnes

Forskjellen mellom dagens snitt og det oppnåelige nivået er den mest handlingsrettede opplysningen i hele analysen. Den forteller deg at når en leverandør sier «dette er ikke vanlig i bransjen», er svaret ofte at det er vanlig hos noen andre. Du kan derfor be om konkrete praksiser uten å fremstå som urimelig, fordi du ber om noe en jevnaldrende aktør allerede gjør.

SaferAI trekker frem fire områder der forbedringene ligger nærmest: risikomodellering, Key Control Indicators, kontinuerlig overvåking av Key Risk Indicators og selve risikostyringen (safer-ai.org, 2026). Som eksempel nevnes at Meta utvikler risikomodeller for hvert risikodomene med publiserte trusselscenarier. Det er en praksis du kan spørre andre leverandører om de har noe tilsvarende av.

Område	Hva det betyr i praksis	Spørsmålet du stiller leverandøren
Risikomodellering	Konkrete trusselscenarier per risikodomene, ikke generelle formuleringer	Hvilke scenarier har dere skrevet ned, og er de publisert?
Key Control Indicators	Målepunkter som viser om kontrolltiltakene faktisk virker	Hvordan vet dere at et tiltak fungerer, og ikke bare at det finnes?
Overvåking av Key Risk Indicators	Kontinuerlig måling, ikke en vurdering per modellslipp	Hva overvåkes løpende etter at modellen er i produksjon?
Risikostyring	Hvem eier beslutningen når en terskel brytes	Hvem kan stanse en utrulling, og har det skjedd?

Slik leser du en skår uten å overtolke den

En skår på et rammeverk måler dokumentet, ikke virkeligheten bak det. Et selskap kan skrive et godt rammeverk og etterleve det dårlig, eller ha solide interne rutiner som aldri er skrevet ut. Bruk skåren som en sorteringsmekanisme: den forteller deg hvor du bør stille flest oppfølgingsspørsmål, ikke hvem du skal velge.

Den andre fallgruven er å behandle en lav skår som en dealbreaker. Med et bransjesnitt i dette området vil nesten alle leverandører ligge lavt, og en absolutt terskel ville tømt leverandørlisten din. Relativ sammenligning er mer nyttig enn absolutt kvalifisering. Spør hvordan leverandøren ligger an mot de nærmeste alternativene, og hva som er endret siden forrige versjon av rammeverket.

---

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

---

Safety claim og safety case: to dokumenter du kan be om

De to mest nyttige begrepene i denne diskusjonen er også de minst kjente blant norske innkjøpere. OpenAI definerer en safety claim som en spesifikk påstand om en modells kapabiliteter, atferd eller sikkerhetsmekanismer som kan vurderes mot bevis (OpenAI). En safety case er noe mer: et strukturert argument støttet av bevis for at en modells risiko er tilstrekkelig håndtert.

Forskjellen er verdt å lære seg fordi den endrer hva du kan be om. En påstand kan testes. Et argument kan gjennomgås. Begge er langt mer konkrete enn «vi tar sikkerhet på alvor», og begge er begreper leverandøren selv bruker, så du ber ikke om noe eksotisk.

Safety claim: en påstand som kan etterprøves

En god safety claim er smal nok til å kunne være feil. «Modellen avviser forespørsler i denne kategorien» er en påstand. «Modellen er trygg» er ikke. Når du ber om påstander i denne formen, tvinger du leverandøren til å binde seg til noe målbart, og du får samtidig et grunnlag for å teste i din egen kontekst.

OpenAI peker ut fire prioriterte områder for dypere tredjepartsvurdering, blant dem uavhengig vurdering av sikkerhetspåstander og av sikkerhetsmekanismer (OpenAI). Selskapet oppgir også at det er i samtaler med flere tredjeparter om forslag som samsvarer med disse områdene. Det gir deg en konkret formulering til møtet: hvilke av leverandørens påstander har vært gjennom ekstern vurdering, og hvilke er kun internt vurdert?

Safety case: argumentet og bevisene

En safety case samler påstandene, bevisene og resonnementet som knytter dem sammen. Den tilsvarer det du kjenner fra andre regulerte bransjer, der man ikke bare viser frem en test, men forklarer hvorfor testene til sammen dekker risikobildet. For en kjøper er det mest nyttige elementet ikke konklusjonen, men forutsetningene: hva antar leverandøren om hvordan modellen brukes?

Hvis dine forutsetninger avviker fra leverandørens, gjelder ikke argumentet i din setting. En modell vurdert for generell chat er ikke automatisk vurdert for saksbehandling mot personopplysninger eller for et internt oppslagsverk over egne dokumenter (RAG på egne data). Sjekk forutsetningene først, konklusjonen etterpå.

	Safety claim	Safety case
Hva det er	Spesifikk påstand om kapabilitet, atferd eller sikkerhetsmekanisme	Strukturert argument støttet av bevis for at risikoen er håndtert
Kan vurderes mot	Bevis og tester	Helheten av bevis, forutsetninger og resonnement
Slik bruker du det	Test påstanden i din egen kontekst	Sjekk om forutsetningene matcher din bruk
Rødt flagg	Påstander som ikke kan være feil	Ingen dokumenterte forutsetninger om bruksområde

Rammeverk for innkjøp: fire spørsmål før du signerer

De fleste norske SMB-er oppdager dokumentasjonsbehovet etter at avtalen er signert, gjerne når en kunde eller revisor spør. Da er forhandlingsstyrken borte. Alura mener dokumentasjon på risikostyring bør være et innkjøpskrav, ikke et tillegg du ber om etterpå. Kravet koster ingenting å stille før signering og er nesten umulig å presse gjennom etterpå.

Fire spørsmål dekker det meste av behovet. De er formulert slik at de kan besvares skriftlig, og slik at et unnvikende svar er like informativt som et godt svar.

Hvilken dokumentasjon finnes, og hvor ofte oppdateres den

Be om rammeverket, versjonsnummeret og datoen. Versjonering er ikke pedanteri: Google DeepMind har publisert flere generasjoner av sitt Frontier Safety Framework, fra 1.0 til 3.1 (Google DeepMind). Hvis leverandøren ikke kan si hvilken versjon som gjaldt da din avtale ble inngått, vet de heller ikke hva de har lovet deg.

Spør deretter hvem som eier dokumentet internt og hva som utløser en revisjon. Et rammeverk som bare oppdateres ved modellslipp er svakere enn et som oppdateres når risikobildet endres. Svaret skal være et navn og en prosess, ikke en avdeling.

Har noen uavhengig vurdert påstandene

Dette er spørsmålet som skiller policy fra praksis. OpenAI beskriver at tredjeparter kan få dyp tilgang på tvers av trening, evaluering og utrulling, og trekker frem uavhengig vurdering av kapabilitetsevalueringer og håndtering av misalignment-hendelser som prioriterte områder (OpenAI). Når du spør, spør du altså om noe leverandørsiden selv har definert.

Er svaret nei, er ikke det nødvendigvis diskvalifiserende for en mindre leverandør. Men da skal det stå i risikovurderingen din, og du bør vite hvilke egne kontroller som kompenserer. Et dokumentert nei er bedre enn et vagt ja.

Hvordan varsles du ved en hendelse

Leverandøren har allerede rapporteringsplikter oppover mot myndigheter. EUs Code of Practice krever at signatarer sporer, dokumenterer og rapporterer alvorlige hendelser til European AI Office (metr.org, 2026). Det du må avklare, er om noe av dette også går nedover til deg som kunde, og hvor raskt.

Formuler kravet som en frist, ikke som en intensjon. «Uten ugrunnet opphold» betyr i praksis at ingen har tenkt gjennom det. En konkret frist tvinger frem en intern rutine hos leverandøren og gir deg noe å måle mot senere.

Hva skjer ved modellendring eller avvikling

Modeller byttes ut, deprekeres og oppdateres under samme produktnavn. Endringen kan påvirke både kvalitet og risikoprofil i din løsning, og den skjer ofte uten at noen hos deg blir spurt. Be om varslingsfrist ved vesentlige modellendringer og om en definert overgangsperiode ved avvikling.

Dette er også stedet å avklare datahåndtering ved avslutning. Erfaringene fra store utrullinger viser at det er bruken internt, ikke teknologien, som skaper de første hendelsene (Samsungs utrulling). Et exit-punkt i avtalen er billigere å skrive enn å forhandle under press.

Spørsmål	Det du ber om	Rødt flagg i svaret
Dokumentasjon	Rammeverk med versjon, dato og intern eier	Lenke til en generell nettside uten versjon
Uavhengig vurdering	Hvem, hvilken tilgang, hvilke påstander	«Vi har interne prosesser for dette»
Hendelsesvarsling	Frist i timer eller dager, definert mottaker hos deg	«Uten ugrunnet opphold»
Modellendring	Varslingsfrist og overgangsperiode	Ensidig endringsrett uten varsling

Praktisk: dette tar du opp i neste leverandørmøte

Et leverandørmøte om sikkerhet går ofte galt på samme måte: selgeren beskriver produktets sikkerhetsfunksjoner, kjøperen nikker, og ingen snakker om risikostyring. Løsningen er å sende spørsmålene skriftlig på forhånd, slik at den som svarer må hente inn noen som faktisk vet.

Agendaen som får frem svarene

Start med dokumentene: hvilket rammeverk gjelder, hvilken versjon, og hva er endret siden forrige. Gå deretter til påstandene: hvilke safety claims gjelder for produktet du kjøper, og hvilke av dem er vurdert av noen utenfor selskapet (OpenAI). Avslutt med fristene: hva varsles du om, av hvem, og innen hvor lang tid.

Ta med en person fra fagsiden og en som eier kontrakten. Når begge sitter i rommet, blir det vanskeligere å skyve ubehagelige svar til «det tar vi i implementeringen». Skriv ned svarene underveis og send dem tilbake samme dag som et referat leverandøren kan korrigere.

Fra referat til kontraktstekst

Et godt møte har null juridisk verdi. Alura mener krav bør stå i kontrakten med frister, ikke i en e-postutveksling. Konverter hvert svar du fikk til en setning i avtalen eller i et bilag: dokumentasjon som skal leveres, varslingsfrist som skal gjelde, og hva som skjer hvis fristen brytes.

Hold bilaget kort. Fire til fem punkter som faktisk følges opp er mer verdt enn et tosifret antall krav som ingen leser igjen. Sett en dato for neste gjennomgang, gjerne knyttet til kontraktsfornyelsen, slik at dokumentasjonen oppdateres i takt med leverandørens egne versjoner.

Markedet: tolv selskaper har publisert egne sikkerhetsrammeverk

Tolv selskaper har publisert Frontier AI Safety Frameworks (safer-ai.org, 2026). Det er et lite og oversiktlig marked, og det betyr at du som kjøper kan lese deg opp på de reelle alternativene i løpet av noen timer. Det er sjelden tilfellet i andre deler av innkjøpsporteføljen din.

Drivkraften bak publiseringen er delvis regulatorisk. EUs AI Act og den frivillige Code of Practice oppfordrer signatarer til å utvikle rammeverk for sikkerhet og sikring, og bestemmelsene for generelle AI-modeller trådte i kraft i august 2026 (safer-ai.org, 2026). Dokumentene finnes altså ikke først og fremst fordi kundene har krevd dem.

Hva rammeverkene har til felles

De fleste beskriver terskler for kapabilitet, evalueringer som utløses ved disse tersklene, og tiltak som settes inn hvis en terskel brytes. Google DeepMind beskriver at frontier-modeller gjennomgår rigorøse evalueringer for sikkerhet, pålitelighet og hjelpsomhet, og at rammeverket brukes sammen med selskapets AI-prinsipper (Google DeepMind). Strukturen er gjenkjennelig på tvers av leverandører.

Det de sjeldnere har til felles, er målepunktene. Analysen peker på at kontinuerlig overvåking av risikoindikatorer og indikatorer for om kontrollene virker, er blant de svakeste områdene i bransjen (safer-ai.org, 2026). Det er der du finner den største forskjellen mellom et modent og et umodent dokument.

Hvorfor forskjellen mellom leverandørene er ditt problem

Når modenheten varierer, varierer også hvor mye egen kontroll du må bygge. En leverandør med publiserte trusselscenarier per risikodomene, slik Meta beskrives å ha, gir deg et grunnlag for din egen risikovurdering. En leverandør uten gir deg en tom side du må fylle selv (safer-ai.org, 2026).

I praksis betyr det at valg av leverandør flytter kostnader mellom deres side og din. Det er en legitim avveining, men den bør tas bevisst og prises inn, ikke oppdages i etterkant. Flere norske virksomheter har allerede begynt å stille disse spørsmålene i sine egne innkjøp (AI-sikkerhet for norske bedrifter).

Kostnad og tidsbruk når en tredjepart skal vurdere leverandøren

Uavhengig vurdering høres dyrt ut, og for en SMB er det sjelden aktuelt å bestille en egen. Det du derimot kan gjøre, er å bruke vurderinger som allerede finnes, og å kalibrere forventningene til hvor lang tid slikt arbeid tar. OpenAI oppgir at noen vurderinger tar uker mens andre tar flere måneder (OpenAI). Det er tidsskalaen du planlegger etter, ikke dager.

Tiden en vurdering faktisk tar

Tidsbruken drives av tilgangen. En vurdering som bare leser offentlig dokumentasjon går raskt og sier lite. En vurdering med dyp tilgang på tvers av trening, evaluering og utrulling tar lengre tid og sier mer (OpenAI). Når du leser en rapport, er det første spørsmålet ditt derfor hvilken tilgang vurdereren hadde.

Lovgiver har begynt å sette klokke på deler av dette. Under Illinois SB 315 skal et sammendrag og en redigert revisjonsrapport publiseres innen 30 dager, mens den uredigerte rapporten skal oppbevares i fem år (metr.org, 2026). For deg betyr det at det over tid vil finnes offentlige revisjonssammendrag du kan lese gratis.

Den interne regningen du faktisk betaler

For en SMB ligger hovedkostnaden i egen tid: å lese dokumentasjonen, formulere kravene, forhandle dem inn og følge dem opp ved fornyelse. Det er timer fra den som eier kontrakten, fra fagansvarlig og i noen tilfeller fra jurist. Den kostnaden er reell, men den er også engangs for første avtale og gjenbrukbar for de neste.

Prisbildet for eksterne vurderinger er ikke offentlig og varierer for mye til at et tall gir mening her. Den nyttige økonomiske betraktningen er en annen: kostnaden ved å hente dokumentasjon før signering er lav, kostnaden ved å hente den under en hendelse er høy. Automatisering av rutinearbeid rundt oppfølging kan dempe den løpende belastningen (prosessautomatisering).

Aktivitet	Hvem gjør jobben	Tidsbilde	Når det lønner seg
Lese leverandørens rammeverk	Fagansvarlig	Før første møte	Alltid, uansett avtalestørrelse
Formulere krav til avtalen	Kontraktseier	Før signering	Alltid, kostnaden er marginal
Lese offentlige revisjonssammendrag	Fagansvarlig	Ved fornyelse	Når leverandøren er omfattet av revisjonskrav
Bestille egen ekstern vurdering	Ekstern part	Uker til flere måneder	Kun ved kritisk bruk eller regulatorisk krav

---

Les også: Valg av AI-leverandør – Kriterier og fallgruver for norske bedrifter. Norge har over 350 AI-selskaper å velge mellom.

---

Regulering: EUs AI Act, SB 53, RAISE Act og SB 315

Fire regelverk former hva leverandøren din må ha på plass. De gjelder utviklerne, ikke deg, men de bestemmer hvilken dokumentasjon som eksisterer og dermed hva du kan be om. METR har samlet forpliktelsene i et referansedokument for laboratorieansatte og understreker at det ikke erstatter den offisielle lovteksten (metr.org, 2026).

Regelverk	Sentral dato	Terskel	Mest relevante krav for en kjøper
EUs AI Act	2. august 2025 for etterlevelse, 2. august 2026 for håndheving	10^25 FLOPs	Hendelsesrapportering til European AI Office, dokumentasjon i fem år
California SB 53	1. januar 2026	10^26 FLOPs, strengere over 500 millioner dollar i årsinntekt	Publisert rammeverk som er juridisk bindende, varslerbeskyttelse
New York RAISE Act	1. januar 2027	Frontier-utviklere	Rapportering av kritiske hendelser innen 72 timer
Illinois SB 315	1. januar 2027, rammeverk og revisjon fra 1. januar 2028	Store utviklere	Årlig uavhengig revisjon av etterlevelse

EUs AI Act og Code of Practice

AI Act treffer modeller over en treningsterskel på 10^25 FLOPs. Selskaper måtte etterleve regelverket fra 2. august 2025, og EU AI Office kan håndheve det fra 2. august 2026 (metr.org, 2026). Begge datoene er passert, og håndhevingsfasen er i gang.

Code of Practice er frivillig, men signatarer påtar seg konkrete plikter: spore, dokumentere og rapportere alvorlige hendelser til European AI Office, og oppbevare dokumentasjon i fem år. Om leverandøren din er signatar er et spørsmål med et enkelt ja eller nei, og svaret sier mye om hvilken dokumentasjon som finnes.

California SB 53

SB 53 trådte i kraft 1. januar 2026 og gjelder utviklere som har trent eller begynt å trene minst en modell med 10^26 FLOPs, med strengere krav for «store» utviklere med brutto årsinntekt over 500 millioner dollar (metr.org, 2026). Terskelen gjør at loven treffer et lite antall selskaper, men det er sannsynligvis selskaper du allerede bruker.

To elementer er direkte nyttige for en kjøper. Det ene er at det publiserte rammeverket er juridisk bindende. Det andre er varslerbeskyttelsen, som gjelder California-ansatte med ansvar for risikovurdering eller risikostyring, og alle California-ansatte som rapporterer manglende etterlevelse. Loven gir dessuten hjemmel for bot, og boten ilegges per brudd, ikke som en samlet reaksjon (metr.org, 2026).

New York RAISE Act og Illinois SB 315

RAISE Act trer i kraft 1. januar 2027 og krever raskere hendelsesrapportering enn SB 53: 72 timer mot 15 dager (metr.org, 2026). Når frister strammes inn i ett regelverk, ender leverandørene ofte med å legge seg på det strengeste kravet internt. Det er en fordel for deg.

Illinois SB 315 trer i kraft samme dato, mens rammeverks- og revisjonskravene gjelder fra 1. januar 2028. Den mest interessante bestemmelsen for innkjøpere er at hver stor utvikler årlig må hyre en uavhengig tredjepart til å revidere etterlevelsen av lovens rammeverkskrav. Det er første gang uavhengig revisjon går fra frivillig praksis til lovkrav.

Hva dette betyr for en norsk kjøper

Ingen av de amerikanske delstatslovene gjelder deg. De gjelder leverandøren din, og de produserer dokumentasjon du kan be om å få se. Alura mener norske SMB-er bør spørre etter uavhengig vurdering og hendelsesrapportering, fordi det er dette regelverket selv legger vekt på. Du låner da lovgivers prioritering i stedet for å finne opp dine egne kriterier.

Praktisk formulering til møtet: er dere omfattet av SB 53, av RAISE Act eller av SB 315, og hvilke av pliktene gjelder allerede i dag? Svaret plasserer leverandøren på et tidsspor du kan planlegge etter, og det avslører raskt om den du snakker med kjenner sitt eget regelverk.

Hendelsesrapportering: fristene som allerede binder leverandøren

Hendelsesfrister er den mest konkrete delen av hele regelverkslandskapet, og den enkleste å speile inn i din egen avtale. Fristene varierer med alvorlighetsgrad og regelverk, fra timer til uker (metr.org, 2026).

Hendelsestype	Frist	Regelverk
Overhengende fare for død eller alvorlig skade	24 timer	SB 53
Visse kritiske sikkerhetshendelser	15 dager	SB 53
Kritiske sikkerhetshendelser	72 timer	RAISE Act og SB 315
Alvorlig forstyrrelse av kritisk infrastruktur	2 dager	Code of Practice
Alvorlig cybersikkerhetsbrudd	5 dager	Code of Practice
Dødsfall	10 dager	Code of Practice
Alvorlig skade på helse, rettigheter, eiendom eller miljø	15 dager	Code of Practice

Oppfølging etter første varsel

Rapportering stopper ikke ved første melding. Under Code of Practice skal uavklarte hendelser følges opp med mellomrapporter hver fjerde uke, og endelig rapport skal foreligge innen 60 dager etter at hendelsen er løst (metr.org, 2026). Det er en rytme du kan gjenbruke i din egen beredskapsplan.

Dokumentasjonen skal dessuten oppbevares i fem år. Det er en detalj verdt å notere seg, fordi den betyr at leverandøren har materiale om en hendelse lenge etter at den er glemt hos deg. Hvis du senere må forklare hendelsen til en kunde eller et tilsyn, finnes grunnlaget fortsatt.

Slik kobler du fristene til din egen beredskap

Speil de relevante fristene i avtalen med en definert mottaker hos deg, ikke en generisk postkasse. Et varsel som havner i en ubetjent innboks i en helg er teknisk oppfylt og praktisk verdiløst. Navngi rollen, ikke personen, så overlever ordningen at noen bytter jobb.

Deretter bestemmer du hva du selv gjør innen samme tidsvindu. Hvem varsler kunder, hvem vurderer om tjenesten skal stanses, og hvem eier beslutningen? Fristen er leverandørens, responsen er din. Den koblingen er hele poenget med å hente fristene inn i avtalen.

Markedsobservasjon: standarder uten lisens og forhåndsgodkjenning

Parallelt med lovgivningen pågår en debatt om hvordan globale standarder bør utformes. OpenAI argumenterer for at internasjonale standarder for sikkerhet og sikring i frontier-utvikling kan være like viktige som alignment-forskning for å styre utviklingen, og mener USA bør lede arbeidet (OpenAI, 2026). Selskapet foreslår å bruke det fremvoksende nettverket av AI-sikkerhetsinstitutter til å legge til rette for standardutvikling.

Hva posisjonen faktisk sier

Det mest presise punktet i forslaget er en avgrensning: standardene skal ikke være lisenser eller obligatorisk forhåndsgodkjenning av AI-modeller (OpenAI, 2026). Det er en vesentlig forskjell fra hvordan legemidler eller fly reguleres, der ingen får slippe produktet før en myndighet har sagt ja.

OpenAI peker også på økende autonomi og rekursiv selvforbedring som drivkraften bak behovet, og sier at fullt autonom RSI ikke skjer i dag og ikke bør etterstrebes før det kan gjøres trygt. Posisjonen er publisert av en part med tydelige interesser, og bør leses som markedets stemme i en pågående politisk prosess, ikke som en nøytral analyse.

Hva det betyr for deg som kjøper

Uten forhåndsgodkjenning finnes det ingen myndighet som har kvalitetssikret modellen før den kom på markedet. Kontrollen skjer i etterkant, gjennom rapportering, revisjon og sanksjoner. Konsekvensen er at innkjøpsleddet blir en reell kontrollmekanisme, ikke bare en pris- og funksjonsforhandling.

Praktisk betyr det at du ikke bør vente på en merkeordning som gjør jobben for deg. Den kommer ikke med det første, og forslagene fra bransjen selv peker eksplisitt bort fra den modellen. Kravene du stiller i avtalen er det nærmeste du kommer en forhåndskontroll.

Vanlige feil norske SMB-er gjør i AI-innkjøp

Feilene går igjen på tvers av bransjer og avtalestørrelser. De handler sjelden om manglende teknisk kompetanse, og nesten alltid om rekkefølge: dokumentasjonen etterspørres etter at beslutningen er tatt.

Å forveksle produktsikkerhet med risikostyring

Kryptering, tilgangsstyring og datalagring i EU er viktige, men de svarer på et annet spørsmål enn risikostyring. Risikostyring handler om hvordan leverandøren identifiserer og følger opp risiko i selve modellen over tid, målt gjennom indikatorer og terskler (safer-ai.org, 2026). En leverandør kan gjøre det første utmerket og det andre dårlig.

Sjekklisten din bør derfor ha to kolonner. Den ene dekker det klassiske sikkerhetsbildet, den andre dekker modell- og leverandørrisiko. Hvis begge behandles i samme punkt, forsvinner som regel det siste.

Å ta rammeverket som bevis

Et publisert rammeverk viser at selskapet har tenkt på problemet. Det viser ikke at praksisen følger dokumentet. Gjennomsnittsnivået i bransjen målt mot 65 kriterier er lavt, og variasjonen mellom selskapene er stor nok til at «de har et rammeverk» ikke skiller mellom alternativer (safer-ai.org, 2026).

Spør derfor alltid det ene oppfølgingsspørsmålet: hvem utenfor selskapet har sett på dette? Svaret er enten et navn, en rapport og en dato, eller det er ingenting.

Å la kravene bli liggende i e-post

Selgeren lover, kjøperen noterer, og ingenting havner i avtalen. Når leverandøren senere bytter kontaktperson, forsvinner løftet med personen. En setning i et bilag overlever både utskiftninger og oppkjøp.

Det samme gjelder fristene. En frist uten konsekvens er en anbefaling. Skriv inn hva som skjer hvis varslingsfristen brytes, om det så bare er en rett til å kreve møte innen en gitt tid. Konsekvens er det som skiller et krav fra en intensjon.

Ofte stilte spørsmål om dokumentasjonskrav til AI-leverandører

Spørsmålene under er de som oftest kommer opp når norske virksomheter begynner å stille krav til AI-leverandører for første gang.

Kan jeg kreve en safety case fra en liten norsk leverandør?

Ikke i den formen begrepet har hos de største utviklerne. En liten leverandør som bygger på en tredjepartsmodell har sjelden grunnlag for å lage et strukturert argument om modellens risiko. Det du kan kreve, er at de opplyser hvilken underleverandør og hvilken modell de bruker, og at de videreformidler underleverandørens dokumentasjon og varsler.

Da flytter kravet seg dit det hører hjemme. Din leverandør blir ansvarlig for kjeden, ikke for å produsere dokumentasjon de ikke har forutsetning for å skrive.

Hva gjør jeg hvis leverandøren ikke har publisert noe rammeverk?

Bare tolv selskaper har publisert slike rammeverk, så fravær er normen, ikke unntaket (safer-ai.org, 2026). Spør i stedet hvilken modell de bygger på, og les rammeverket til den som faktisk har laget modellen.

Deretter dekker du gapet med egne kontroller: hva logges, hva mennesker godkjenner, og hvilke bruksområder som er utelukket. Det er raskere å innføre enn å vente på at en liten leverandør skal bygge et rammeverk.

Er AI Act relevant for oss når vi bare er kunde?

Forpliktelsene for generelle AI-modeller treffer utviklerne, med en treningsterskel på 10^25 FLOPs, og EU AI Office har kunnet håndheve dem siden 2. august 2026 (metr.org, 2026). Som kunde er du ikke pliktsubjekt for denne delen.

Relevansen er likevel praktisk: regelverket produserer dokumentasjon og rapporteringsrutiner hos leverandøren, og det er dette du kan be om innsyn i. Hvordan ditt eget bruksområde klassifiseres under AI Act er et separat spørsmål du bør avklare med jurist.

Hvor lenge oppbevares dokumentasjonen om en hendelse?

Under Code of Practice er oppbevaringskravet fem år, og det samme gjelder den uredigerte revisjonsrapporten under Illinois SB 315 (metr.org, 2026). Materialet finnes altså lenge etter at saken er ute av nyhetsbildet.

For deg betyr det at du kan be om utdrag i ettertid, for eksempel når en kunde stiller spørsmål ved en tjeneste du leverte for et par år siden. Avtalefest gjerne at du har rett til å be om slik dokumentasjon i oppbevaringsperioden.

Hva er forskjellen på en revisjon og en evaluering?

En evaluering tester modellens kapabiliteter og atferd. En revisjon kontrollerer om selskapet følger sitt eget rammeverk og regelverkets krav. SB 315 krever det siste: en årlig uavhengig tredjepart som reviderer etterlevelse av lovens rammeverkskrav (metr.org, 2026).

Begge har verdi, men de svarer på ulike spørsmål. Evaluering sier noe om produktet du kjøper. Revisjon sier noe om organisasjonen du kjøper det fra.

Oppsummering og neste steg

Hovedbildet er at bransjen selv dokumenterer sin risikostyring svakt, at snittet på 22 prosent mot 65 kriterier kunne vært vesentlig høyere med praksiser som allerede finnes, og at lovgivningen nå skyver de samme kravene fra frivillighet til plikt (safer-ai.org, 2026). Som kjøper står du i en bedre posisjon enn du tror: dokumentene finnes, fristene er definerte, og markedet er lite nok til å overskue.

Det som mangler hos de fleste norske SMB-er, er at kravene stilles på riktig tidspunkt. Før signering koster de en e-post. Etter signering koster de en forhandling.

Sjekklisten til neste leverandørmøte

Be om rammeverket med versjon og dato. Be om hvilke safety claims som gjelder produktet, og hvilke som er vurdert eksternt (OpenAI). Spør om leverandøren er omfattet av SB 53, RAISE Act, SB 315 eller EUs Code of Practice, og hvilke plikter som gjelder i dag. Avklar varslingsfrist ved hendelse, med navngitt mottakerrolle hos deg. Avklar varslingsfrist ved vesentlig modellendring eller avvikling.

Fem punkter er nok til første møte. Skriv referat samme dag, send det til leverandøren for bekreftelse, og flytt de punktene som ble besvart konkret inn i avtaleteksten med frister. De som ikke ble besvart, noterer du som åpen risiko i din egen vurdering, og tar dem opp igjen ved fornyelse.

I Alura kombinerer vi teknisk AI-kompetanse med praktisk forståelse for GDPR, EU AI Act og Datatilsynets forventninger. Vi hjelper norske virksomheter å bygge AI som tåler en revisjon, uten å bremse innovasjonen.

Bestill en compliance-vurdering: vi kartlegger dine AI-systemer mot gjeldende og kommende krav, og leverer en handlingsplan som faktisk er gjennomførbar. Uforpliktende.

Kilder

• safer-ai.org (2026). Emerging Best Practices for Frontier AI Safety Frameworks – SaferAI
• metr.org (2026). Frontier AI safety regulations: A reference for lab staff - METR
• OpenAI. OpenAI outlines principles for third-party AI safety assessments
• Google DeepMind. Frontier safety at Google DeepMind — Google DeepMind
• OpenAI (2026). OpenAI Calls for Shared Global AI Standards