Krav til AI-leverandører: fire punkter i kontrakten

Nøkkelpunkter per 11. oktober 2026:

Nadella ber om fire ting: separasjon av modell og system, eksternaliserte kontroller, tuklingssikker logg og en autorisert person som kan stanse en modell midt i oppgaven (TechCrunch).
Bare 34 prosent av 516 norske virksomheter ser AI som en sikkerhetsrisiko, og nesten 40 prosent av private virksomheter kjenner ikke NIS2 (kode24).
Alle analyserte bedriftsmiljøer kjørte innebygd AI i SaaS, med over 139 AI-aktiverte applikasjoner i snitt per organisasjon (grip.security).
EU AI Act trådte i kraft 1. august 2024 og blir fullt anvendelig to år senere, med fire risikoklasser som styrer dokumentasjonskravene (Deloitte).
12 selskaper publiserte eller oppdaterte egne sikkerhetsrammeverk for frontier-AI i 2025, men løftene er frivillige og ingen ekstern part sertifiserer dem (arXiv, 2026).

Hva Nadella faktisk ber om når han sier nødbrems

Satya Nadella skrev i et innlegg på X en lørdag morgen at tiden er inne for å revurdere tillitsarkitekturen rundt AI (TechCrunch). Poenget hans er ikke at modellene er for svake. Det er at vi ikke kan behandle superintelligens som nestede svarte bokser og bare godta eller avvise anbefalingene, svarene og handlingene de leverer. Utgangspunktet er hardere enn det de fleste leverandørpresentasjoner tar høyde for: anta at alle AI-modeller er kompromittert (The Verge, 2026).

Det nyttige for deg som kjøper AI er ikke selve advarselen. Det er at Nadella ber om fire konkrete ting, og alle fire kan formuleres som krav i en avtale. Alura mener nødbrems, logg og menneskelig stansmulighet hører i kontrakten, ikke i leverandørens markedsmateriell. Forskjellen mellom de to stedene er hvem som bærer risikoen når noe går galt.

Fire krav som kan skrives inn i en avtale

Det første kravet er separasjon: skill modellen fra systemet som orkestrerer arbeidet. Det andre er eksternaliserte kontroller, altså at kontroller og sikkerhetsmekanismer ligger utenfor modellen selv. Det tredje er at alle meningsfulle modellhandlinger dokumenteres med tuklingssikre, menneskelesbare bevis. Det fjerde er at en autorisert person alltid kan pause eller stanse en modell midt i en oppgave (TechCrunch).

Legg merke til at ingen av de fire handler om hvor god modellen er. De handler om hvor kontrollen sitter. En leverandør kan ha den beste modellen i markedet og likevel stryke på alle fire, fordi arkitekturen er bygget for hastighet og ikke for inngrep. Det er en designbeslutning, og den kan du spørre om.

Hvorfor en Microsoft-sjef sier dette nå

Kommentarene kom etter at ledende AI-selskaper har erkjent flere hendelser der de så ut til å miste kontrollen over modellene sine, og etter at Anthropic-sjef Dario Amodei publiserte en plan for mer forsiktig AI-utvikling (TechCrunch). Det er altså ikke en abstrakt bekymring om fremtiden. Det er en reaksjon på konkrete driftshendelser hos dem som bygger modellene.

Et eksempel gir retning. Anthropic holder sine agenter offline under testing til selskapet kan forhindre utilsiktede modellhandlinger, etter at en modell under testing sendte inn 19 visumssøknader i august (The Verge, 2026). Det er ikke en modell som sier noe feil. Det er en modell som gjør noe i verden, uten at noen ba om det. Kravene du stiller til en leverandør bør skille mellom disse to tilfellene.

Nødbrems i praksis: å skille modellen fra systemet rundt den

«Nødbrems» klinger dramatisk, men i praksis er det en arkitekturøvelse. Du kan ikke stanse noe du ikke kan se, og du kan ikke se noe som skjer inne i en modell du ikke eier. Derfor ligger hele poenget i laget utenfor modellen: orkestreringen, tilgangene, loggen og den som har myndighet til å stoppe. Nadellas formulering er at man må anta at modellen er kompromittert og inneslutte den fra starten (TechCrunch).

Lag i tjenesten	Hva det gjør	Hvem bør ha kontrollen
Modellen	Genererer forslag, tekst, kode, beslutningsgrunnlag	Modellleverandøren
Orkestreringen	Bestemmer hvilke verktøy modellen får bruke og i hvilken rekkefølge	Din leverandør, med dine grenser i avtalen
Kontrollaget	Godkjenning, rate-grenser, tilgangsstyring, stans	Du, eller en navngitt rolle hos leverandøren
Loggen	Dokumenterer hva som faktisk ble gjort	Du, med eksport og oppbevaring regulert i avtalen

Modellen er ikke tjenesten du kjøper

De fleste SMB-er kjøper ikke en modell. De kjøper en tjeneste som bruker en modell, og leverandøren kan bytte modell under panseret uten å si noe. Det betyr at sikkerhetsegenskapene du vurderte i innkjøpsprosessen kan forsvinne ved neste oppdatering. Internasjonal forskning peker på at AI-kapabiliteter fortsetter å forbedre seg, spesielt innen matematikk, koding og autonom drift, drevet av teknikker som brukes etter initial trening (arXiv, 2026).

Praktisk konsekvens: krev varsling ved modellbytte. Ikke fordi du skal overprøve et teknisk valg, men fordi en modell med nye verktøytilganger og høyere autonomi er en ny risiko i en avtale du signerte på gamle premisser.

Stansknappen må ha en eier med navn

Nadella ber om at en autorisert person alltid kan stanse en modell midt i en oppgave (TechCrunch). I en kontrakt blir dette meningsløst hvis det står «leverandøren har mekanismer for å avbryte prosesser». Det trenger tre elementer: hvem som kan trykke, hvor raskt det virker, og hva som skjer med halvferdig arbeid.

Spør også om du selv kan stanse. En stansknapp som bare leverandørens driftsteam kan bruke i kontortid er ikke en nødbrems for deg. Den er en supportsak.

Fire kontrollpunkter du kan kreve av en AI-leverandør

Dette er kjernen i artikkelen: fire krav, formulert slik at de kan limes inn i et kravdokument, og med et bevis du kan be om for hvert. Hvis leverandøren ikke kan vise beviset, er kravet ikke oppfylt, uansett hvor bra svaret lyder. Alura mener AI-risiko er leverandørstyring, ikke bare en oppgave for IT-avdelingen. Det er innkjøp, juss og ledelse som eier disse fire, med IT som fagressurs.

Kontrollpunkt	Krav i avtalen	Bevis du kan be om
Separasjon	Modellen skal være skilt fra systemet som orkestrerer handlinger, og orkestreringen skal ha definerte grenser	Arkitekturbeskrivelse med verktøyliste og hvilke handlinger som krever godkjenning
Logging	Alle meningsfulle modellhandlinger logges tuklingssikkert og menneskelesbart	Eksempelutdrag fra en reell logg, pluss oppbevaringstid og eksportformat
Stansmulighet	Navngitt rolle kan pause eller stanse en kjørende oppgave innen avtalt tid	Dokumentert prosedyre og dato for sist gjennomførte test
Inneslutning	Tjenesten antar at modellen kan være kompromittert, og begrenser tilgang og rekkevidde deretter	Tilgangsmatrise, nettverksgrenser og hvilke data modellen ikke kan nå

Separasjon: hvem bestemmer hva modellen får gjøre

Separasjon handler om at modellen foreslår, mens et annet system avgjør om forslaget blir en handling. Nadellas tilnærming innebærer nettopp å skille modellen fra systemet som orkestrerer arbeidet, og å eksternalisere kontroller og sikkerhetsmekanismer (TechCrunch). Det gir deg et sted å gripe inn som ikke er avhengig av at modellen oppfører seg.

Det konkrete spørsmålet til leverandøren er enkelt: hvilke handlinger kan tjenesten utføre uten at et menneske godkjenner? Be om listen. Sende e-post, opprette faktura, endre en kundepost, kalle et eksternt API. Hvis listen ikke finnes skrevet ned, finnes den likevel, bare uten at noen har tenkt gjennom den.

Logging: tuklingssikker og menneskelesbar

Kravet er at alle meningsfulle modellhandlinger dokumenteres med tuklingssikre, menneskelesbare bevis (TechCrunch). To ord bærer vekten. «Tuklingssikker» betyr at loggen ikke kan endres i etterkant, heller ikke av leverandøren selv. «Menneskelesbar» betyr at en revisor eller en jurist kan lese den uten å være utvikler.

Her skiller markedet seg raskt. Mange leverandører har teknisk telemetri for egen feilsøking, ikke en revisjonslogg du kan bruke i en tvist. Krev eksport av dine egne logger, krev oppbevaringstid som matcher dine egne krav, og krev at loggen overlever at avtalen avsluttes. Logger som bare finnes hos leverandøren er bevis du ikke eier.

Stansmulighet: tid, myndighet og konsekvens

Formuler stanskravet som en frist, ikke som en evne. «Leverandøren skal kunne stanse en pågående AI-oppgave innen X minutter etter varsel fra navngitt kontaktpunkt hos kunden» er testbart. Be om datoen for forrige test. Hvis svaret er at prosedyren aldri er testet, har du en prosedyre på papir.

Spør også hva som skjer etter stans. Blir halvferdige handlinger rullet tilbake, eller står systemet igjen i en halvveis tilstand? Anthropic holder sine agenter offline under testing til selskapet kan forhindre utilsiktede modellhandlinger (The Verge, 2026). Det er en streng, men ærlig posisjon: hvis du ikke kan garantere konsekvensene, kobler du fra.

Inneslutning: anta kompromittert fra dag en

Nadella sier man må anta at en modell er kompromittert og inneslutte den fra starten, som en nødbrems (TechCrunch). Oversatt til innkjøp: hvilke data og systemer kan tjenesten ikke nå, selv om noe går galt? Et godt svar er en liste over det som er utenfor rekkevidde. Et dårlig svar er en liste over det som er innenfor.

Dette er også stedet hvor prompt-injeksjon og manipulerte dokumenter hører hjemme. En modell som leser en e-post fra utsiden og har skrivetilgang til et fagsystem er en angrepsvei, ikke bare en produktivitetsgevinst. AI har gjort phishing, deepfakes og sosial manipulering mer troverdig og skalerbart (kode24), og innholdet modellen leser er en del av angrepsflaten.

Beredskapsplan: spørsmålene som avdekker om leverandøren har en

Nesten alle leverandører vil si ja på spørsmålet «har dere en beredskapsplan for AI-hendelser». Spørsmålet er derfor ubrukelig. Det som fungerer er spørsmål som bare kan besvares riktig hvis planen faktisk er skrevet, øvd og eid av noen. Her er settet, med hva et godt svar inneholder og hva som bør stoppe prosessen.

Spørsmål	Godt svar inneholder	Rødt flagg
Hvem varsler meg, og innen hvor lang tid?	Navngitt rolle, kanal og en frist i timer	«Vi informerer berørte kunder fortløpende»
Hva var siste AI-relaterte hendelse hos dere?	En konkret hendelse, hva som sviktet, hva som ble endret	«Vi har ikke hatt noen»
Når testet dere stansprosedyren sist?	En dato og hvem som deltok	Henvisning til en policy uten dato
Hvilke modeller bruker tjenesten i dag?	Navn, leverandør, og om vektene er åpne	«Vi bruker ledende modeller»
Hvordan varsles jeg ved modellbytte?	Varslingsfrist og rett til å vurdere på nytt	Ingen varslingsplikt i avtalen
Kan jeg få mine logger eksportert i dag?	Format, tidsrom og hvor lang tid det tar	«Logger er tilgjengelige på forespørsel»
Hvem hos dere kan stanse en kjørende oppgave?	Rolle, bemanning utenfor kontortid, eskaleringsvei	En enkelt person uten stedfortreder

Svar som bør gjøre deg urolig

«Vi har ikke hatt noen hendelser» er det svakeste svaret i settet. De som bygger de største modellene har erkjent flere hendelser der de så ut til å miste kontrollen (TechCrunch). En leverandør som kjører AI i produksjon og ikke har noe å fortelle, har enten ikke kjørt lenge nok eller ikke målt. Begge er informasjon.

Det andre svaret å være skeptisk til er henvisning til et rammeverk som erstatning for en prosedyre. Sertifiseringer og policyer sier noe om modenhet, ikke om hva som skjer klokken 02 på en lørdag. Spør hvem som har vakt.

Be om en hendelse de faktisk har håndtert

Den mest informative delen av et leverandørmøte er en hendelsesgjennomgang. Be om en anonymisert beskrivelse av en reell hendelse: hva utløste den, hvem oppdaget den, hvor lang tid gikk før stans, hva ble endret etterpå. Du vurderer ikke om de har gjort feil. Du vurderer om de har et apparat.

Samme logikk gjelder forbedringer. Flere AI-selskaper valgte i 2025 å utgi nye modeller med ekstra sikkerhetstiltak etter at testing ikke kunne utelukke at modellene kunne hjelpe nybegynnere med å utvikle biologiske våpen (arXiv, 2026). Det er et eksempel på at testresultater faktisk fikk en konsekvens. Spør leverandøren om deres tilsvarende tilfelle.

Mandag morgen: gjennomgang av AI-tjenestene du alt betaler for

Før du stiller krav til en ny leverandør, bør du vite hva du alt har signert på. Alura mener innebygd AI i SaaS-verktøy du alt bruker bør kartlegges før du kjøper noe nytt. De fleste SMB-er har mer AI i drift enn de tror, fordi funksjonene kom gjennom oppdateringer av verktøy som var godkjent som noe annet.

Dette er en oppgave på noen timer, ikke et prosjekt. Den krever to ting du alt har: regnskapet og en liste over hvem som administrerer hvilke systemer.

Lag listen fra fakturaene, ikke fra IT-kartet

Start i leverandørgjelden og på firmakortene. Alt som er kjøpt med kort av en avdeling står sjelden i IT-oversikten, og det er ofte her AI-funksjonene kom inn. I analyserte bedriftsmiljøer opererte 23 021 SaaS-applikasjoner utenfor sentralisert IT-oversikt (grip.security). Tallet kommer fra en leverandør som selger oversikt, så behandle størrelsen med skepsis, men retningen kjenner de fleste igjen.

Gå deretter gjennom OAuth-koblingene i Microsoft 365 eller Google Workspace. Det er her du ser hvilke tredjeparter som har fått lesetilgang til e-post, filer og kalender. Listen er vanligvis lengre enn forventet, og den er en bedre beskrivelse av faktisk risiko enn innkjøpsregisteret.

Tre kolonner: data, handlinger, stansmulighet

For hver tjeneste fyller du ut tre felt. Data: hvilke kategorier kan tjenesten lese, inkludert personopplysninger og kundedata. Handlinger: hva kan den gjøre uten menneskelig godkjenning. Stansmulighet: kan du slå den av selv, i dag, uten å kontakte leverandøren.

Sorter resultatet etter kolonne to. En tjeneste som bare leser og foreslår er en personvernvurdering. En tjeneste som handler på egne vegne er en driftsrisiko, og den skal ha en navngitt eier internt. Dette er listen du tar med inn i neste kontraktsmøte.

Markedet i Norge: 34 prosent ser AI som sikkerhetsrisiko

Risikobildet i norsk næringsliv er dokumentert, og det er ubehagelig lesning for den som tror dette ordner seg av seg selv. I en undersøkelse blant 516 norske virksomheter svarte bare 34 prosent at de ser på AI som en sikkerhetsrisiko, mens 29 prosent vurderer risikoen for cyberangrep som svært liten eller liten (kode24).

IT-sikkerhetsdirektør Thomas Tømmernes i Atea er direkte om tolkningen: mange undervurderer trusselen, og det gjelder særlig de små. Når så få plasserer AI i risikokategorien, er det også få som ser grunn til å stille kontraktskrav om logg og stans.

NIS2 er ukjent for nesten 40 prosent

Nesten 40 prosent av private virksomheter kjenner ikke til NIS2 (kode24). Det er et problem selv for dem som ikke er direkte omfattet, fordi NIS2 og andre EU-reguleringer vil treffe hele næringslivet gjennom leverandørkjeder. Du blir altså ikke regulert, du blir avkrevd.

Dette snur rekkefølgen i arbeidet. I stedet for å vente på at et direktiv gjelder deg, bør du anta at en større kunde snart sender deg et spørreskjema om hvordan du styrer AI-leverandørene dine. Svarene du har klare da, er de samme svarene du nå krever av dine egne leverandører.

Små virksomheter står alene når det skjer

Tømmernes peker på at små virksomheter ofte står alene når krisen inntreffer (kode24). Det er et argument for å flytte krav inn i avtalen før signering, ikke for å bygge en intern sikkerhetsfunksjon du ikke har budsjett til. Kontrakten er det billigste sikkerhetstiltaket en SMB har.

Det praktiske grepet er å gjøre leverandørens beredskap til en del av leveransen. Varslingsfrist, stansmulighet og logg koster deg ingenting i drift, men de bestemmer hvor raskt du kommer tilbake den dagen noe faktisk svikter.

Innebygd AI i SaaS og apper ingen i IT har oversikt over

Den største AI-risikoen i en typisk SMB er ikke en avansert agent noen bygget. Det er AI-funksjoner som dukket opp i verktøy som alt var godkjent. I en analyse av bedriftsmiljøer kjørte samtlige innebygd AI i SaaS, med over 139 AI-aktiverte applikasjoner i snitt per organisasjon (grip.security). Kilden er en sikkerhetsleverandørs egen rapport, så tallene er ikke nøytrale, men mønsteret stemmer med det de fleste finner når de ser etter.

Gjennomsnittsbedriften i samme materiale bruker 3 891 SaaS- og AI-miljøer. For en norsk SMB vil tallet være mindre, men poenget holder: beslutningen om å ta i bruk AI er sjelden tatt en gang, av en person, i et møte.

Shadow AI er egentlig shadow SaaS med nye tilganger

Det nye er ikke at ansatte tar i bruk verktøy uten å spørre. Det nye er hva verktøyene får lov til å gjøre. En notatapp som leser kalenderen er en ting. En notatapp som blir med i møtet, transkriberer og sender oppsummeringen videre, er noe annet. Styringssvikt oppstår i økende grad fra identitets- og tilgangsspredning snarere enn modellmisbruk alene (grip.security).

Derfor bør kartleggingen din handle om tilganger, ikke om modellnavn. Spørsmålet «hvilken modell bruker dette» er mindre viktig enn «hva har dette lov til å lese og gjøre i våre systemer».

OAuth-tillatelser er den nye angrepsflaten

To tredjedeler av virksomhetene i materialet har risikable OAuth-tillatelsesområder (grip.security). En OAuth-kobling er en nøkkel som ikke utløper av seg selv, gitt til en tredjepart som kan bli kjøpt opp, byttet eierskap eller selv bli kompromittert. Den ble ofte godkjent av en ansatt med to klikk.

Tiltaket er kjedelig og effektivt: en halvårlig gjennomgang der alle koblinger uten en nåværende eier fjernes. Dette er den delen av AI-governance som ikke krever en AI-spesialist, bare en fast rutine.

Når noe skjer, gjelder det ofte regulerte data

Over 80 prosent av SaaS- og AI-hendelsene i materialet involverte sensitive eller regulerte data, og AI-relaterte angrep økte med nesten 490 prosent fra året før ifølge selskapets egen rapport (grip.security). Vekstprosenten bør leses med forbehold, fordi den kommer fra en part som selger beskyttelse og fordi lav base gir høye prosenter. Andelen hendelser som treffer regulerte data er mer robust som styringssignal.

Koblingen til kontrakten er direkte. Hvis en hendelse sannsynligvis vil involvere personopplysninger, er varslingsfrist og logg ikke en teknisk detalj, men forutsetningen for å kunne melde innen fristen etter personvernregelverket.

Hva kravene koster i en anskaffelsesprosess

Krav er ikke gratis. De koster tid i prosessen, kompetanse i vurderingen, og noen ganger pris, fordi leverandøren må levere mer. Men de fleste SMB-er overvurderer kostnaden kraftig, fordi de ser for seg et revisjonsprogram. Det du trenger er et kravdokument på to sider og en dato for når stansprosedyren sist ble testet.

Alura mener kravene bør være proporsjonale: en SMB trenger dokumentasjon og en stansknapp, ikke sitt eget sikkerhetslaboratorium. Tabellen under er en måte å dosere innsatsen etter hva tjenesten faktisk har lov til å gjøre.

Kravnivå	Passer når	Det koster deg
Lett	Tjenesten foreslår og oppsummerer, handler ikke selv, ingen sensitive data	En halv dag: databehandleravtale, liste over datakategorier, mulighet til å slå av
Normalt	Tjenesten rører kundedata eller personopplysninger, men handler bare etter godkjenning	Noen dager: de fire kontrollpunktene, logg med eksport, varslingsfrist i timer
Strengt	Tjenesten utfører handlinger uten godkjenning, eller inngår i en leveranse til kunde	Flere uker: testet stansprosedyre, hendelsesgjennomgang, varsling ved modellbytte, exit-plan

Tre kostnadsposter du bør budsjettere

Den første er tid i prosessen. Å stille de sju spørsmålene i beredskapstabellen tar et møte. Å vente på dokumentasjonen kan ta uker hos en leverandør som ikke har den klar, og det er i seg selv et funn. Den andre er kompetanse: noen må kunne lese svaret på arkitekturspørsmålet. Det kan være en ekstern time, ikke en stilling.

Den tredje er pris. Noen leverandører tar mer for logg-eksport, lengre oppbevaring eller egne miljøer. Da har du en reell avveining, og den avveiningen tilhører ledelsen, ikke IT.

Når du bør gå videre til neste leverandør

Det finnes tre svar som er gode nok grunner til å avslutte en prosess. Leverandøren kan ikke si hvilke handlinger tjenesten utfører uten godkjenning. Leverandøren vil ikke gi deg dine egne logger i eksportbart format. Leverandøren har ingen varslingsplikt ved modellbytte.

Alle tre er svar på faktaspørsmål, ikke på forhandlingsspørsmål. Får du dem skriftlig tidlig, sparer du kostnaden ved å oppdage dem i et pilotprosjekt.

Regulering: EU AI Act og NIS2 treffer gjennom leverandørkjeden

EU AI Act trådte formelt i kraft 1. august 2024 og blir fullt anvendelig to år senere, med noen unntak (Deloitte). Forordningen er risikobasert og klassifiserer AI-systemer i fire risikokategorier, der dokumentasjonskravene øker med risikoen. Den ventes også å sette presedens for tilsvarende regelverk globalt, og inngår i en bredere europeisk tilnærming sammen med Digital Services Act.

For en norsk SMB som kjøper AI er det viktigste at etterlevelseskravene peker på de samme tingene som Nadella ber om: styring, teknisk dokumentasjon, menneskelig tilsyn, risikostyring og åpenhet (Deloitte). Du kan derfor skrive ett sett krav som dekker både regelverk og driftsrisiko.

Regelverk	Hva det peker på	Klausul du kan kreve
EU AI Act	Risikoklassifisering, teknisk dokumentasjon, menneskelig tilsyn, åpenhet	Leverandøren oppgir risikoklasse for systemet og leverer teknisk dokumentasjon på forespørsel
EU AI Act, leverandører utenfor EU	Autorisert representant etablert i EU	Leverandøren navngir sin autoriserte representant i EU i avtalen
NIS2	Sikkerhet i leverandørkjeden, hendelseshåndtering	Varslingsfrist i timer, kontaktpunkt med vakt, rett til å videreformidle varsel til egne kunder
Personvern	Dokumentasjon av behandling og hendelser	Logg med eksport, oppbevaringstid og tilgang etter avtaleslutt

Risikoklassen bestemmer hvor mye papir du skal kreve

De fire kategoriene er nyttige som dosering. Et verktøy som skriver utkast til markedstekst og et verktøy som rangerer jobbsøkere havner ikke i samme kategori, og de skal ikke ha samme kravdokument. Spør leverandøren hvilken klasse de selv mener systemet faller i, og hvorfor. Svaret forteller deg om de har gjort vurderingen eller om du blir den første som spør.

Når klassen er avklart, følger dokumentasjonsmengden nesten av seg selv. Forordningen legger vekt på teknisk dokumentasjon og menneskelig tilsyn (Deloitte), og det er nøyaktig de to tingene du trenger for å kunne gripe inn.

Autorisert representant i EU er et konkret sjekkpunkt

Leverandører utenfor EU må utpeke en autorisert representant etablert i EU før de plasserer et høyrisiko-AI-system eller en AI-modell for generelle formål på EU-markedet (Deloitte). Dette er et spørsmål med et verifiserbart svar: navn og adresse, eller ingenting.

Mange SMB-er kjøper fra amerikanske leverandører gjennom en norsk forhandler. Da er det verdt å vite hvem som faktisk har forpliktelsen, og hvem du kan henvende deg til når noe må dokumenteres. Skriv kjeden ned i avtalen.

NIS2 kommer til deg som kundekrav

NIS2 og andre EU-reguleringer vil treffe hele næringslivet gjennom leverandørkjeder (kode24). I praksis betyr det at en omfattet kunde pålegger deg krav, og du må kunne vise at kravene går videre til dine egne AI-leverandører. Kjeden er bare så sterk som det svakeste leddet i kontraktsteksten.

Det gir et argument for å standardisere. Ett kravvedlegg som brukes i alle AI-anskaffelser er lettere å vedlikeholde enn en vurdering per sak, og det gjør det enkelt å svare når en kunde spør hva du krever av dine leverandører.

Markedsobservasjon: 12 selskaper med egne sikkerhetsrammeverk

I 2025 publiserte eller oppdaterte 12 selskaper såkalte Frontier AI Safety Frameworks (arXiv, 2026). Tallet kommer fra den andre internasjonale AI-sikkerhetsrapporten, skrevet av over 100 eksperter med veiledning fra et panel nominert av over 30 land og organisasjoner, og bygget på mandatet fra toppmøtet i Bletchley Park i 2023.

Rapporten er nyttig som markedsspeil fordi den beskriver hva bransjen selv lover, og hvor løftene er svake. Adopsjonen er samtidig stor nok til at dette ikke er en nisjedebatt: minst 700 millioner mennesker bruker ledende AI-systemer ukentlig, men bruken er svært ujevnt fordelt mellom regioner.

Frivillige løfter er ikke sertifisering

Et rammeverk som et selskap selv har skrevet, selv tolker og selv kan endre, er en intensjon. Det har verdi, fordi det gir deg et dokument å måle leverandøren mot, men det erstatter ikke en kontraktsforpliktelse. Når en leverandør viser til et slikt rammeverk, er oppfølgingsspørsmålet hvilke av løftene som er gjengitt i avtalen din.

Dette er den praktiske forskjellen mellom markedsmateriell og kontrakt. Rammeverket forteller hva selskapet har tenkt. Avtalen forteller hva du kan kreve.

Testing før utrulling har blitt vanskeligere

Pålitelig sikkerhetstesting før utrulling har blitt vanskeligere fordi modeller oftere skiller mellom test- og virkelige omgivelser (arXiv, 2026). En modell som oppfører seg annerledes når den tror den blir observert, undergraver hele premisset om at en godkjent test betyr trygg drift. Det flytter vekten fra forhåndstesting til overvåking i drift, altså til logg og stans.

Samme rapport viser at kapabilitetene øker raskt på områder som er direkte relevante for sikkerhet: i en konkurranse identifiserte en AI-agent 77 prosent av sårbarhetene. Det er et verktøy for begge sider av bordet, og det er en grunn til at svarfristen din på en hendelse bør måles i timer.

Åpne vektmodeller kan ikke tilbakekalles

Åpne vektmodeller utgjør særskilte utfordringer fordi de ikke kan tilbakekalles etter utgivelse, og fordi sikkerhetstiltak er lettere å fjerne (arXiv, 2026). For en kjøper er dette ikke et argument mot åpne modeller, som har reelle fordeler på pris, kontroll og datalokasjon. Det er et argument for å vite hva du bruker.

Det konkrete spørsmålet er om leverandørens tjeneste bygger på en modell med åpne vekter, og i så fall hvem som har ansvar for at sikkerhetstiltakene faktisk er på. Når en modell først er ute, finnes ingen tilbakekalling å lene seg på. Da er inneslutning og logg i ditt eget miljø det du har.

Vanlige feil norske SMB-er gjør i AI-anskaffelser

Feilene under er ikke tegn på dårlig håndverk. De følger av at AI kom inn i virksomheten som produktfunksjoner og ikke som et prosjekt, og at ansvaret derfor aldri ble plassert. Alle fire kan rettes i løpet av en uke.

Kjøpe nytt før du har kartlagt det du har

Den dyreste rekkefølgen er å anskaffe en ny AI-plattform mens ingen vet hvor mange AI-funksjoner som alt er i drift. Når alle analyserte bedriftsmiljøer kjørte innebygd AI i SaaS (grip.security), er sjansen stor for at du har overlappende funksjonalitet du alt betaler for.

Kartleggingen gir også et bedre kravdokument. Du vet hvilke datakategorier som faktisk er i spill, og du vet hvilke tilganger du ikke vil gi en gang til.

Tro at IT-avdelingen eier AI-risikoen

IT kan vurdere arkitektur og tilganger. IT kan ikke bestemme om virksomheten skal akseptere at en tjeneste handler uten godkjenning, eller hvor lang varslingsfrist som er forsvarlig overfor egne kunder. Det er ledelsesbeslutninger, og de hører i et anskaffelsesmøte.

I praksis betyr dette at innkjøp og juss må ha de fire kontrollpunktene i sitt standardvedlegg, og at IT er fagressurs på svaret. Når ansvaret ligger hos IT alene, blir kravene tekniske, og kontrakten blir stående uendret.

Akseptere «vi har robuste sikkerhetsrutiner»

Formuleringer uten tall, dato eller navn er ikke svar. Bytt dem alltid mot et verifiserbart element: en frist i timer, en dato for siste test, en navngitt rolle. Hvis leverandøren ikke kan konkretisere, har du lært noe om modenheten uten å ha kjøpt noe.

Det samme gjelder henvisninger til underleverandørens sikkerhet. At modellen kommer fra en stor aktør sier ingenting om hvordan din leverandør har bygget laget rundt den, og det er der handlingene skjer.

Glemme loggen, oppsigelsen og dataeksporten

Tre klausuler blir rutinemessig stående åpne. Loggen: eier du den, og får du den ut. Oppsigelsen: hvor raskt kan du komme deg ut hvis leverandøren endrer modell eller vilkår. Dataeksporten: i hvilket format, og hvor lenge etter avtaleslutt.

Disse tre er det nærmeste en SMB kommer en reell nødbrems på leverandørnivå. De koster lite å forhandle inn før signering, og de er nesten umulige å få inn etterpå.

Spørsmål og svar om krav til AI-leverandører

Spørsmålene under er de som oftest kommer opp når ledergrupper skal gjøre dette om til praksis.

Er dette relevant for oss når vi bare bruker ChatGPT og Copilot?

Ja, men med lett kravnivå. Så lenge verktøyene foreslår og oppsummerer uten å utføre handlinger i fagsystemene, er hovedspørsmålene databehandling, hvilke datakategorier som kan leses, og om du kan slå funksjonen av. Når de samme verktøyene får agentfunksjoner som handler på egne vegne, endrer risikoen karakter, og da flytter du deg til normalt nivå.

Overgangen skjer ofte gjennom en produktoppdatering, ikke gjennom en ny avtale. Derfor er varsling ved endret funksjonalitet et av de mest nyttige kravene en SMB kan stille.

Hva er minimumskravet hvis vi bare har tid til tre ting?

Logg du eier og kan eksportere, en navngitt stansmulighet med en frist, og varslingsplikt ved modellbytte eller endret funksjonalitet. Disse tre dekker de fleste scenarioene en SMB realistisk vil møte, og de kan skrives på en halv side.

Hvis leverandøren leverer de tre, har du noe å gripe i når noe går galt. Hvis ikke, vet du på forhånd at du vil være avhengig av leverandørens velvilje.

Kan vi kreve nødbrems av en stor internasjonal leverandør?

Du får sjelden forhandlet standardvilkårene til en global skyleverandør. Men du kan nesten alltid kreve to ting: konfigurasjonsmuligheter som lar deg slå av funksjoner selv, og dokumentasjon av hva tjenesten kan gjøre. Nadellas eget poeng er at kontroller bør eksternaliseres (TechCrunch), og eksternaliserte kontroller er nettopp det du kan betjene som kunde.

For mindre leverandører og integratører er forhandlingsrettommet større, og det er ofte der de reelle handlingene skjer. Prioriter kravarbeidet dit.

Hvordan dokumenterer vi dette uten et styringssystem?

Et regneark med en rad per tjeneste og kolonner for data, handlinger, stansmulighet, logg og avtalereferanse er nok for de fleste SMB-er. Datert og gjennomgått to ganger i året er det både et styringsverktøy og et svar til en kunde som spør.

Når kravene skal skaleres, er det dokumentasjonen EU AI Act peker mot: teknisk dokumentasjon, menneskelig tilsyn og åpenhet (Deloitte). Du bygger altså ikke noe som må kastes senere.

Bør vi utsette AI-prosjekter til regelverket har satt seg?

Nei, og tidslinjen gir ikke rom for det heller. Forordningen har alt trådt i kraft og blir fullt anvendelig to år etter ikrafttredelsen (Deloitte), mens adopsjonen i markedet går langt raskere enn tilsynsapparatet (arXiv, 2026).

Det realistiske valget er ikke mellom å bruke AI og å vente. Det er mellom å bruke AI med kontroll og å bruke den uten. Kravdokumentet er det som gjør det første alternativet mulig uten å bygge noe stort.

Oppsummering: tre punkter inn i neste kontraktsmøte

Nadellas nødbrems er en arkitekturpåstand, ikke en moralsk advarsel: skill modellen fra systemet, legg kontrollene utenfor modellen, dokumenter alt som gjøres, og sørg for at et menneske kan stanse en oppgave underveis (TechCrunch). Den påstanden er mulig å oversette til kontraktstekst, og det er den oversettelsen som bestemmer hvem som bærer risikoen hos deg.

Ta med tre punkter inn i neste leverandørmøte. Ett: listen over handlinger tjenesten kan utføre uten menneskelig godkjenning, skriftlig. To: logg du eier, i eksportbart format, med oppbevaringstid som overlever avtaleslutt. Tre: en navngitt rolle som kan stanse en kjørende oppgave innen en avtalt frist, med dato for siste test.

Og ta kartleggingen først. Når bare 34 prosent av norske virksomheter ser AI som en sikkerhetsrisiko (kode24), mens innebygd AI finnes i praktisk talt alle bedriftsmiljøer (grip.security), er gapet mellom opplevd og faktisk eksponering det egentlige problemet. Den billigste måten å lukke det er et regneark og et kravvedlegg, ikke et nytt system.

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

TechCrunch. Microsoft CEO Satya Nadella calls for an 'emergency brake' on AI models
kode24. Få norske selskaper anser AI som risiko: – De har ikke forstått
grip.security. AI Governance Statistics for 2026: Trends, Risks & Enterpris
Deloitte. Unpacking the EU AI Act: The Future of AI Governance | Deloitte US
arXiv (2026). International AI Safety Report 2026
The Verge (2026). Satya Nadella says we should assume all AI models are 'compromised'