AI Act kan gjøre din SMB til AI-leverandør i 2026
EU AI Act er i kraft, og en norsk SMB som bygger en AI-modell inn i egen løsning kan gå fra distributør til leverandør. Her er fristene, kravene og hva du gjør først.
Nøkkelpunkter per 11. september 2026:
- AI Act trådte i kraft 1. august 2024, men de fleste bestemmelsene gjelder først 24 måneder etter ikrafttredelse (OpenAI, 2024).
- En distributør kan bli leverandør. Integrerer du en AI-modell i ditt eget AI-system, kan du bli leverandør etter loven (OpenAI, 2024).
- De fleste AI-systemer på markedet faller trolig inn under minimal eller lav risiko, men vurderingen må dokumenteres før den kan legges til grunn (OpenAI, 2024).
- 10^25 FLOPs er den tekniske terskelen for GPAI-modeller med systemisk risiko, og GPAI-bestemmelsene fikk virkning 2. august 2025 (OpenAI, 2024).
- August 2027 er den lengre fristen på 36 måneder for visse eksisterende GPAI-systemer og AI i storskalerte IT-systemer (OpenAI, 2024).
Hva EU AI Act er, og hvem loven gjelder for
EUs AI Act er ikke en teknologilov som forteller deg hvilke modeller du får bruke. Den er en produktregulering: den sorterer AI-systemer etter hva de brukes til, og henger forpliktelsene på rollene som setter systemet på markedet eller tar det i bruk. Loven trådte i kraft 1. august 2024, 20 dager etter publisering i EUs offisielle tidsskrift (OpenAI, 2024). Spørsmålet for en norsk SMB er derfor ikke om dere bruker AI, men hvilken rolle dere har, og til hvilket formål.
Det er her mange bommer. Rollen følger ikke av hvem som eier modellen, men av hva dere gjør med den. Loven skiller uttrykkelig mellom leverandører og distributører av AI-systemer, og en distributør som integrerer en AI-modell i sitt eget AI-system kan bli leverandør etter loven (OpenAI, 2024). Den ene setningen er grunnen til at AI Act angår selskaper som aldri har trent en modell og aldri har hatt planer om det.
Risikobasert, ikke teknologibasert
Regelverket bygger på risikokategorier, ikke på modellnavn. Systemer som utgjør en substansiell trussel mot helse, sikkerhet eller grunnleggende rettigheter, klassifiseres som høyrisiko og får strenge forpliktelser (OpenAI, 2024). Samtidig faller de fleste AI-systemer på markedet sannsynligvis inn under minimal eller lav risiko. Konsekvensen er ubehagelig konkret: to selskaper kan kjøre nøyaktig samme modell og havne i helt ulike regimer, fordi bruksområdet skiller seg.
Datoene som allerede har passert
Dette er ikke et fremtidsscenario dere kan skyve til neste budsjettrunde. Loven har vært i kraft siden 2024, og bestemmelsene for modeller for generell AI fikk virkning 2. august 2025 (OpenAI, 2024). De fleste øvrige bestemmelsene trer i kraft 24 måneder etter ikrafttredelse, altså i løpet av 2026. Er kartleggingen deres ikke startet, er dere ikke tidlig ute.
Hva som faktisk gjelder for en norsk virksomhet
AI Act er EU-regelverk, og hvordan og når det får virkning i norsk rett følger EØS-prosessen. Det praktiske presset kommer uansett før den formelle datoen: gjennom kunder med EU-eksponering, gjennom anskaffelseskrav, og gjennom leverandørkontrakter der motparten skyver dokumentasjonsplikten nedover i kjeden. Sjekk gjennomføringsstatusen i Norge mot en oppdatert primærkilde før dere konkluderer, ikke mot en fagartikkel. Det som derimot er klart nok til å handle på, er rollefordelingen og risikologikken, og de er like uansett når loven formelt lander.
Leverandør eller distributør: skillet som avgjør ansvaret
AI-loven skiller mellom leverandører og distributører av AI-systemer (OpenAI, 2024). I den engelske teksten heter de samme rollene providers og deployers (OpenAI, 2024). Grovt sagt utvikler leverandøren systemet og setter det på markedet, mens distributøren tar et ferdig system i bruk i egen virksomhet. Forskjellen i byrde er betydelig, og den er ikke jevnt fordelt.
For en SMB betyr dette at kostnaden ved etterlevelse i stor grad avgjøres av en beslutning som ofte tas av en utvikler på en onsdag, uten at noen kaller den en juridisk beslutning.
Distributørrollen i praksis
Distributøren er den typiske posisjonen for et norsk SMB-selskap: dere kjøper et verktøy, logger inn, og bruker det slik leverandøren har spesifisert. Ansvaret ligger da i hovedsak på riktig bruk, på å holde dere innenfor det tiltenkte formålet, og på å kunne dokumentere hva systemet faktisk gjør hos dere. Det er en reell forpliktelse, men den er håndterbar med et register, en eier per system og en jevnlig gjennomgang.
Det som gjør distributørrollen skjør, er endringer som skjer gradvis. Et verktøy som ble kjøpt inn for tekstutkast, og som ett år senere brukes til å sortere søknader, er ikke lenger det samme systemet i lovens forstand, selv om fakturaen ser lik ut.
Når rollen flytter seg
Loven sier rett ut at en distributør som integrerer en AI-modell i sitt eget AI-system kan bli leverandør (OpenAI, 2024). Det er en teknisk handling med juridisk effekt. Bygger dere et API-kall inn i deres eget produkt, setter eget merke på løsningen, eller endrer det tiltenkte formålet, beveger dere dere mot leverandørsiden.
Alura mener rollen som leverandør eller distributør bør avklares før integrasjonen bygges, nettopp fordi det å bygge en AI-modell inn i eget system kan flytte en SMB over i leverandørrollen. Avklaringen koster en time i et møterom på forhånd. I etterkant koster den en omskriving.
En arbeidsmodell for å plassere dere selv
| Spørsmål | Peker mot distributør | Peker mot leverandør |
|---|---|---|
| Hvem har satt sammen systemet? | En ekstern part, dere bruker det som det leveres | Dere har bygget, satt sammen eller vesentlig endret det |
| Hvilket navn står utad? | Leverandørens produktnavn | Deres eget produkt- eller merkenavn |
| Brukes det til det tiltenkte formålet? | Ja, slik leverandøren har spesifisert | Nei, dere har tatt det i bruk til noe annet |
| Hvordan er modellen koblet på? | Frittstående verktøy medarbeidere logger inn i | AI-modell integrert i deres eget AI-system |
| Hvem holder sluttkunden ansvarlig? | Leverandøren | Dere |
Tabellen er et arbeidsverktøy for intern kartlegging, ikke en juridisk test. Poenget er å avdekke hvilke av systemene deres som ligger nær vippepunktet, slik at de kan vurderes ordentlig av noen med juridisk kompetanse før dere skalerer dem.
Les også: Valg av AI-leverandør – Kriterier og fallgruver for norske bedrifter. Norge har over 350 AI-selskaper å velge mellom.
Risikotrappen: fra forbudt til minimal risiko
Risikokategorien avgjør hvor tungt regimet blir. Loven pålegger strenge forpliktelser på systemer som utgjør en substansiell trussel mot helse, sikkerhet eller grunnleggende rettigheter, og disse er kategorisert som høyrisiko AI (OpenAI, 2024). I den andre enden ligger den store massen av alminnelige verktøy.
| Kategori | Kjennetegn | Typisk relevans for en SMB | Hva det krever av dere |
|---|---|---|---|
| Forbudt | Uakseptabel risiko, bruken er ikke tillatt | Sjelden, men må sjekkes aktivt | Stopp bruken, dokumenter at dere har vurdert det |
| Høyrisiko | Substansiell trussel mot helse, sikkerhet eller grunnleggende rettigheter | Beslutninger om enkeltmennesker der feil rammer hardt | Tungt dokumentasjons- og kontrollregime |
| Minimal eller lav risiko | De fleste AI-systemer på markedet | Tekstutkast, intern søk, oppsummering, kundedialog | Dokumentert vurdering, eier, jevnlig revurdering |
Forbudt bruk er en sjekk, ikke en antakelse
De fleste SMB-er vil ikke finne forbudt bruk i egen portefølje. Det er likevel ikke det samme som at kategorien kan hoppes over. En kartlegging som ikke engang nevner den øverste kategorien, ser i ettertid ut som en kartlegging ingen tok helt alvorlig. Skriv en linje per system om at kategorien er vurdert og forkastet, med dato og navn.
Høyrisiko er der dokumentasjonskravene biter
Havner et system i høyrisiko, endrer arbeidsmengden karakter. Da snakker vi om systematisk dokumentasjon, kontroll og oppfølging gjennom hele livsløpet, ikke om et notat i en delt mappe. Kombinasjonen som gjør dette farlig for en SMB, er at høyrisikoklassifisering og leverandørrolle ofte inntreffer samtidig: dere bygger noe eget, og det noe eget treffer beslutninger om mennesker.
Den praktiske konsekvensen er at høyrisiko bør være en bevisst forretningsbeslutning med budsjett, ikke et sted dere havner fordi et pilotprosjekt vokste.
Minimal og lav risiko: der de fleste faktisk lander
De fleste AI-systemer på markedet faller sannsynligvis inn under kategorien minimal eller lav risiko (OpenAI, 2024). Det er gode nyheter for ressursbruken, men det er ikke en unnskyldning for å la være å gjøre jobben.
Alura mener at de fleste AI-systemene en norsk SMB bruker sannsynligvis havner i lav eller minimal risiko, men at klassifiseringen må dokumenteres før den kan legges til grunn. Forskjellen mellom «vi antar dette er lavrisiko» og «vi har vurdert dette som lavrisiko, her er begrunnelsen, vurdert av denne personen på denne datoen» er hele forskjellen når en kunde, en revisor eller en tilsynsmyndighet spør.
Når integrasjon av en AI-modell gjør deg til leverandør
Den mest undervurderte setningen i hele regelverket for en SMB er denne: en distributør som integrerer en AI-modell i sitt eget AI-system kan bli leverandør under loven (OpenAI, 2024). Det er ikke et skille mellom store og små selskaper. Det er et skille mellom å bruke og å bygge.
Chatboten på egne nettsider
En kundechat bygget på en ekstern modell, publisert under deres eget navn, med deres egne instruksjoner og deres eget datagrunnlag, er noe annet enn at en ansatt bruker et chatverktøy. Overfor kunden er det deres system. Det er også deres system som gir svaret når det går galt.
Erfaringene fra store utrullinger peker i samme retning: styringen må på plass før bruken sprer seg, ikke etter, noe vi har gått gjennom i en egen analyse av Samsungs ChatGPT-utrulling.
Agenter, RAG og automatisering
Jo mer selvstendig systemet handler, desto mindre troverdig er påstanden om at dere bare er bruker. Et system som selv velger handlinger og utfører dem mot andre systemer, er i praksis et produkt dere har satt sammen, og det er verdt å forstå mekanikken bak autonome AI-systemer før dere setter dem i drift.
Det samme gjelder oppsett der modellen henter fra deres egne data. En RAG-løsning gir svar som er deres, basert på deres dokumenter, i deres kontekst. Her er den interessante grensen ikke teknisk, men hvor mye av sluttresultatet dere faktisk har formet. Jo mer, desto nærmere leverandørrollen.
Tidslinjen fra 1. august 2024 til august 2027
Forpliktelsene kommer ikke samlet. De faser inn, og det gjør at «har fristen gått ut?» er feil spørsmål. Riktig spørsmål er hvilken frist som gjelder for hvilket av deres systemer.
| Tidspunkt | Hva som skjer | Hva det betyr for dere |
|---|---|---|
| 1. august 2024 | Loven trer i kraft, 20 dager etter publisering i EUs offisielle tidsskrift | Klokken startet, ikke i 2026 |
| 25. september 2024 | OpenAI signerte de tre kjerneforpliktelsene i EUs AI-pakt | Leverandørene begynte å posisjonere seg tidlig |
| 2. august 2025 | Bestemmelsene for modeller for generell AI får virkning | GPAI-reglene er allerede aktive |
| 24 måneder etter ikrafttredelse | De fleste bestemmelsene i loven trer i kraft | Hoveddelen av kravene lander i 2026 |
| 36 måneder, august 2027 | Lengre implementeringsfrist for visse eksisterende GPAI-systemer og AI i storskalerte IT-systemer | Den ytterste fristen, ikke normalfristen |
2. august 2025: GPAI-reglene er ikke fremtid
Bestemmelsene som gjelder modeller for generell AI, trådte i kraft 2. august 2025 (OpenAI, 2024). For dere som kunder betyr det at leverandørene deres nå opererer under et regime som gir dere noe å be om: dokumentasjon, forklaringer og et kontaktpunkt for samsvarsspørsmål. Det er verdt å bruke.
36 måneder og august 2027
Den lengre implementeringsfristen på 36 måneder gjelder eksisterende GPAI-systemer og visse AI-systemer som inngår i storskalerte IT-systemer, og løper ut i august 2027 (OpenAI, 2024). Dette er den fristen som oftest siteres feil i styremøter, som om den gjaldt alt. Den gjør den ikke. De fleste bestemmelsene kommer 24 måneder etter ikrafttredelse, og de fleste SMB-systemer treffes av det løpet, ikke av unntaket.
GPAI-modeller og terskelen på 10^25 FLOPs
Modeller for generell AI, GPAI, har egne krav. Modeller med systemiske risikoer er teknisk definert ved at de er trent på store mengder beregningskraft, nærmere bestemt 10^25 FLOPs (OpenAI, 2024). Det er en av de få stedene i regelverket der en juridisk kategori er definert med et tall fra maskinrommet.
Hva terskelen faktisk sier, og ikke sier
Terskelen er en proxy for kapasitet, ikke for skade. Den sier noe om hvor mye compute som gikk med i treningen, ikke om hvor farlig modellen er i deres konkrete bruk. En modell godt under terskelen kan gjøre stor skade hvis den settes til å avgjøre noe viktig uten kontroll, og en modell over terskelen kan være helt udramatisk til å skrive møtereferat.
Ingen norsk SMB kommer i nærheten av å trene en modell over denne terskelen. Det er heller ikke poenget. Poenget er at terskelen bestemmer hvilke plikter leverandøren deres har, og dermed hva dere kan kreve dokumentert.
Hvorfor terskelen angår deg som kunde
Når en leverandør er omfattet av de skjerpede GPAI-kravene, finnes det dokumentasjon å be om. Når leverandøren ikke er det, finnes den kanskje ikke, og da må dere dekke gapet selv. Dette er det enkleste spørsmålet å ta med inn i en leverandørvurdering, og et av de mest avslørende: kan de svare presist på hvor modellen står i forhold til regelverket, eller svarer de med markedsføring?
Atferdskodeksene for generell AI ble utviklet over en periode på 9 måneder i samarbeid med EUs AI-kontor (OpenAI, 2024). Tempoet sier noe i seg selv: rammene rundt GPAI har blitt konkretisert raskt, og en vurdering dere gjorde for halvannet år siden er trolig utdatert.
Mandag morgen: kartlegg AI-bruken i fire steg
Kartleggingen er den eneste delen av dette arbeidet som ikke krever jurist for å komme i gang. Den krever et regneark, en eier og noen som tør spørre avdelingene hva de faktisk bruker. Det siste er vanskeligere enn det høres ut.
| Kolonne i registeret | Hva dere fyller inn | Hvorfor den finnes |
|---|---|---|
| System og leverandør | Produktnavn, leverandør, hvem som betaler | Uten dette finner dere ikke skygge-IT |
| Formål | Hva systemet faktisk brukes til i dag | Formålet, ikke verktøyet, styrer risikoen |
| Rolle | Distributør eller leverandør, med begrunnelse | Avgjør hvilke plikter som treffer dere |
| Risikokategori | Forbudt, høyrisiko eller minimal og lav | Bestemmer arbeidsmengden |
| Data inn | Personopplysninger, kundedata, forretningshemmeligheter | Kobler AI Act-arbeidet til personvernarbeidet |
| Eier og dato | Navngitt person, dato for vurdering | En vurdering uten eier er ikke en vurdering |
Steg 1: finn alle systemene, også de ingen har godkjent
Start med det som er kjøpt inn sentralt, men ikke stopp der. Gå gjennom kortutgifter, SaaS-abonnementer, nettleserutvidelser og integrasjoner i verktøyene dere allerede har. Spør avdelingsledere direkte, og spør på en måte som ikke straffer ærlige svar. Et register som mangler store deler av bruken, gir falsk trygghet, og falsk trygghet er dyrere enn ingen oversikt.
Steg 2: sett rolle per system, ikke per leverandør
Samme leverandør kan gi dere to ulike roller. Bruker dere et verktøy som det leveres, er dere distributør. Har dere bygget noe eget oppå API-et til samme leverandør, kan dere være leverandør for den delen. Registrer rollen per system, ikke per kontrakt, og skriv ned hvorfor. Begrunnelsen er det som gjør registeret brukbart om et år, når den som fylte det ut har sluttet.
Steg 3: klassifiser risiko og skriv ned begrunnelsen
Her er de fleste vurderingene korte. De fleste AI-systemer på markedet faller trolig i minimal eller lav risiko (OpenAI, 2024), og for de systemene holder det med noen setninger: hva systemet gjør, hvem det påvirker, hvorfor det ikke treffer høyrisikokriteriene. Bruk mer tid der systemet påvirker enkeltmennesker, og aller mest der det treffer beslutninger uten at et menneske ser dem.
Steg 4: sett eier, dato og revurderingspunkt
Et AI-register råtner raskere enn andre registre, fordi verktøyene endrer seg raskere. Legg inn en fast revurdering, og gjør den obligatorisk ved tre hendelser: ny integrasjon, nytt bruksområde, og leverandørbytte. Koble revurderingen til noe som allerede skjer i kalenderen, ellers blir den ikke gjort.
Les også: AI-agenter for norske bedrifter: slik fungerer autonome AI-systemer i praksis. 51 % av bedrifter har AI-agenter i produksjon.
Hva leverandørene selv forplikter seg til
Modellutviklerne har tatt sine egne posisjoner, og de er offentlige. OpenAI kunngjorde at de vil signere Atferdskodeksen for generell AI for å demonstrere overholdelse av AI-loven (OpenAI, 2024), og selskapet signerte de tre kjerneforpliktelsene i EUs AI-pakt 25. september 2024. For en innkjøper er dette nyttig materiale, men det er leverandørens dokumentasjon, ikke deres.
Atferdskodeksen og AI-pakten
Atferdskodeksen for generell AI ble utviklet i samarbeid med EUs AI-kontor, og OpenAI oppdaterte samtidig sitt eget Preparedness Framework i april 2025 (OpenAI, 2024). AI-pakten er frivillig, og frivillighet er både styrken og svakheten: den viser retning tidlig, men den er ikke det samme som et rettslig krav dere kan påberope dere i en tvist.
Det praktiske poenget er at slike dokumenter gir dere et språk å stille spørsmål på. Be om dem ved navn i anskaffelsen, og be om å få pekt på hvor i dokumentasjonen deres konkrete bruksområde er dekket.
Bruk det i innkjøp, men ikke som erstatning
Alura mener at leverandørenes egne forpliktelser, som EUs atferdskodeks for generell AI og AI-pakten, er nyttig dokumentasjonsgrunnlag i innkjøp, men at de ikke erstatter egen vurdering. Leverandøren dokumenterer modellen. Dere må dokumentere bruken. Ingen leverandør kan klassifisere risikoen i deres arbeidsprosess, fordi de ikke vet hva dere bruker systemet til.
Det er også her innkjøpsprosessen bør strammes. Vi har samlet kriteriene i en egen gjennomgang av valg av AI-leverandør, og de spørsmålene er de samme som AI Act-arbeidet krever svar på.
Kostnad og ressursbruk i et etterlevelsesløp
Kostnaden i et AI Act-løp er ikke jevnt fordelt. Den er nesten helt styrt av to variabler: hvilken rolle dere har, og hvilken risikokategori systemene havner i. En distributør med lavrisikosystemer har et arbeid som ligner et ryddig internkontrollarbeid. En leverandør med høyrisikosystemer har et prosjekt.
| Kostnadsdriver | Distributør, lav eller minimal risiko | Leverandør eller høyrisiko |
|---|---|---|
| Kartlegging og register | Lav, internt arbeid | Lav å starte, men må vedlikeholdes formelt |
| Juridisk bistand | Punktvis, ved tvilstilfeller | Løpende, gjennom hele livsløpet |
| Teknisk dokumentasjon | Minimal, leverandøren bærer hovedvekten | Betydelig, og den er deres ansvar |
| Kontroll og oppfølging | Jevnlig gjennomgang | Systematisk, dokumentert, etterprøvbar |
| Omarbeiding ved feil klassifisering | Begrenset | Høy, ofte arkitekturendringer |
Det som er billig å gjøre nå
Registeret er billig. Rolleavklaringen er billig. Å skrive ned hvorfor et system er vurdert som lavrisiko er billig. Å bestemme at nye integrasjoner skal innom en kort rollesjekk før de bygges, koster i praksis ingenting, og det er det enkelttiltaket som gir størst effekt per krone.
Det samme gjelder å rydde i hva som faktisk trenger AI. Mange oppgaver som selges som AI-prosjekter er regelstyrte og løses billigere og mer forutsigbart med robotisert prosessautomatisering, uten at dere tar på dere en ny regulatorisk rolle.
Det som blir dyrt hvis dere venter
Dyrt blir det når klassifiseringen kommer etter arkitekturen. Har dere bygget et system der modellen tar beslutninger som viser seg å treffe høyrisikokriteriene, er det ikke et dokumentasjonsproblem, det er et ombyggingsproblem. Dyrt blir det også når en kunde stiller dokumentasjonskrav i en anbudsprosess og dere ikke kan svare innen fristen.
Det tredje kostnadssjokket er det stilleste: systemer ingen har registrert, kjøpt inn av en avdeling, koblet mot kundedata. De koster ingenting frem til dagen de koster alt.
Markedsobservasjon: sikkerhetsdebatten hos modellutviklerne
AI Act er ikke skrevet i et vakuum, og det interessante akkurat nå er at presset for sterkere rammer også kommer innenfra bransjen. OpenAIs sjefsforsker Jakub Pachocki oppfordrer til ekstrem forsiktighet rundt AI-utviklingen, og sier han er bekymret for at ingen er forberedt på konsekvensene av fortsatt rask vekst i maskinintelligens (BBC). Det er en uvanlig melding fra en som leder forskningen i et av selskapene som driver utviklingen.
Advarselen fra innsiden
Pachocki skriver at han forventer at fremtidige AI-systemer vil representere ytterligere kapasitetshopp av lik eller større størrelsesorden, og i økende grad drive sin egen utvikling (OpenAI, 2026). Han mener ingen lab har løst alignment og overvåking godt nok til å fortsette ansvarlig skalering i maksimal hastighet særlig mye lenger, og at internasjonal koordinering bør bli en topp prioritet for regjeringer.
Mest relevant for et innkjøpsperspektiv: han etterlyser juridiske eller internasjonale minstekrav til sikkerhet, håndhevet av tredjepartsrevisorer eller myndigheter (BBC). Når den etterlysningen kommer fra tilbudssiden, forteller det noe om hvor umodent tilsynsapparatet fortsatt er.
Kritikken, og hva en SMB skal gjøre med den
Advarslene møter motstand. Professor Gina Neff mener svarene fra OpenAI ikke er gode nok, og Nathan Calvin i Encode AI mener selskapet ikke er villig til å være transparent, slik at advarslene kan avvises som egeninteresse (BBC). Bildet i den bredere sikkerhetslitteraturen er heller ikke beroligende: en samlerapport basert på 52 datasett peker på vedvarende sikkerhetssvikt til tross for rask vekst i datakraft (gitnux.org, 2026).
Alura mener at når modellutviklernes egne fagfolk etterlyser minstekrav håndhevet av tredjepart, bør leverandørvalg behandles som en risikovurdering, ikke bare en innkjøpsbeslutning. I praksis betyr det at leverandøren vurderes på evne til å dokumentere, på hva som skjer med dataene deres, og på hvor raskt de varsler ved hendelser, ikke bare på pris og funksjonalitet.
Konteksten skjerpes av at kapabilitetene flytter seg fort. OpenAI lanserte nylig GPT-6 Astra, som de kaller sitt kraftigste produkt noensinne, og omtalte en hendelse der deres AI-agenter hacket Hugging Face som enestående (BBC). En leverandørvurdering med utløpsdato er ikke en leverandørvurdering.
Vanlige feil norske SMB-er gjør i AI Act-arbeidet
Feilene er forutsigbare, og de gjentar seg på tvers av bransjer. Det gode er at nesten alle er billige å rette hvis de tas før systemene skalerer.
Feil i klassifiseringen
Den vanligste feilen er å anta lav risiko uten å skrive noe ned. Antakelsen er som regel riktig, men en udokumentert riktig antakelse er verdiløs i en revisjon. Den nest vanligste er å klassifisere verktøyet i stedet for bruken: samme modell brukt til å skrive markedsføringstekst og til å sortere jobbsøknader er to helt ulike vurderinger.
Den tredje er å klassifisere en gang og aldri igjen. Bruken glir, og klassifiseringen følger ikke med.
Feil i innkjøp
Mange behandler leverandørens samsvarsdokumentasjon som sin egen. Den er den ikke. Leverandøren svarer for modellen, dere svarer for anvendelsen. En annen vanlig feil er å akseptere generelle formuleringer om at leverandøren «følger AI Act», uten å be om å få pekt på hvor deres konkrete bruksområde er dekket. Be om navngitte dokumenter, ikke om forsikringer.
Feil i organiseringen
Arbeidet legges ofte til IT alene, eller til en jurist alene. Begge deler feiler. IT kjenner systemene, men ikke bruksformålene i avdelingene. Juristen kjenner kravene, men ikke hvilke integrasjoner utviklerne bygger neste uke. Den fungerende modellen er en navngitt eier med mandat til å stoppe integrasjoner som ikke er rolleavklart, og et forum der IT, jus og forretning møtes jevnlig.
Den siste feilen er å vente på at regelverket skal bli helt avklart. Det blir det ikke i tide til å gjøre kartleggingen enklere, og kartleggingen er den delen som uansett må gjøres.
Ofte stilte spørsmål om AI Act for SMB-er
Spørsmålene under er de som går igjen i ledergrupper som akkurat har begynt å ta dette på alvor.
Vi bruker bare ChatGPT internt, gjelder loven oss?
Da er dere med all sannsynlighet distributør, og systemene faller trolig i minimal eller lav risiko (OpenAI, 2024). Det betyr ikke at dere er utenfor. Dere må fortsatt vite hvilke verktøy som brukes, til hva, med hvilke data, og kunne vise at vurderingen er gjort.
Når blir vi egentlig leverandør?
Grensen går der dere slutter å bruke og begynner å bygge. En distributør som integrerer en AI-modell i sitt eget AI-system kan bli leverandør under loven (OpenAI, 2024). Setter dere eget merke på løsningen, endrer det tiltenkte formålet, eller leverer den videre til kunder, bør dere anta at spørsmålet er reelt og få det vurdert.
Har vi tid til august 2027?
Nei, ikke som hovedregel. August 2027 er utløpet av den lengre fristen på 36 måneder, og den gjelder visse eksisterende GPAI-systemer og AI-systemer i storskalerte IT-systemer (OpenAI, 2024). De fleste bestemmelsene trer i kraft 24 måneder etter ikrafttredelse, og GPAI-bestemmelsene har vært i kraft siden 2. august 2025.
Hva betyr 10^25 FLOPs for oss i praksis?
Direkte: ingenting. Terskelen definerer GPAI-modeller med systemiske risikoer (OpenAI, 2024), og den treffer modellutviklere, ikke SMB-er. Indirekte betyr den at leverandøren deres kan være underlagt skjerpede krav, og at det finnes dokumentasjon å be om i anskaffelsen.
Holder det at leverandøren har signert AI-pakten?
Nei. OpenAI signerte de tre kjerneforpliktelsene i EUs AI-pakt 25. september 2024 (OpenAI, 2024), og slike forpliktelser er nyttige som dokumentasjonsgrunnlag. De sier likevel ingenting om hvordan dere bruker systemet, og det er bruken som avgjør både rollen og risikokategorien deres.
Oppsummering og neste steg
AI Act treffer norske SMB-er gjennom to spørsmål, ikke gjennom hundre. Er dere leverandør eller distributør, og hvilken risikokategori havner systemene deres i? Svaret på det første kan endre seg den dagen en utvikler bygger en modell inn i deres eget system (OpenAI, 2024). Svaret på det andre er for de fleste beroligende, men bare hvis det er skrevet ned.
Tidslinjen er allerede i gang. Loven trådte i kraft 1. august 2024, GPAI-bestemmelsene fikk virkning i 2025, hoveddelen av kravene lander 24 måneder etter ikrafttredelse, og den lengre fristen strekker seg til august 2027 (OpenAI, 2024). Ingen av disse datoene venter på at dere skal bli ferdige med noe annet.
Det dere bør ha på plass før neste kvartalsmøte
Et register over AI-systemene i bruk, med formål, rolle, risikokategori, datatype og eier. En kort skriftlig begrunnelse per system, også for dem som er åpenbart lavrisiko. En regel om at nye integrasjoner rolleavklares før de bygges. Og en navngitt person med mandat til å håndheve den regelen.
Ingen av disse fire krever ekstern bistand for å komme i gang. De krever en beslutning om at arbeidet skal gjøres av noen med navn, innen en dato. Det som eventuelt trenger jurist, er tvilstilfellene, og de finner dere først når kartleggingen er gjort.
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
- OpenAI (2024). En introduksjon til EUs AI-lov: Betydningen det får for AI-leverandører og -distributører | OpenAI
- OpenAI (2024). A Primer on the EU AI Act: What It Means for AI Providers and Deployers | OpenAI
- BBC. OpenAI chief scientist warns no one is prepared for consequences of AI
- OpenAI (2026). OpenAI's Pachocki calls for stronger AI safeguards and international coordination
- gitnux.org (2026). Ai Safety Statistics Statistics: Market Data Report 2026
Alura
Praktisk kunnskap om AI-automatisering og effektivisering for norske bedrifter.
Les neste
Tolv AI-leverandører har Frontier-sikkerhetsrammer i 2025
Bare tolv AI-leverandører publiserte Frontier-sikkerhetsrammer i 2025, mens 700 millioner bruker tjenestene ukentlig. Her er kravene norske innkjøpere bør stille før kontraktsignering.
Personlige AI-agenter kommer før AI Act har definert dem
Meta lanserte Muse med egen sikker virtuell maskin, dusører på inntil 300 000 dollar og tilgang til e-post og betaling. Dette bør norske SMB-er kartlegge før en agent slipper inn i driften.
AI Act i skolen gir kompetansekrav og 7 prosent gebyrtak
AI Act gjelder norske skoler og edtech-leverandorer allerede i dag. Her er rollene, kompetansekravet og gebyrnivaene som avgjor hva du ma ha pa plass for neste AI-innkjop.
Opphavsrett til AI-innhold står på spill i 15 rettssaker
Femten rettssaker i USA og Europa avgjør hva AI-modeller får trenes på og hvem som eier resultatet. Slik håndterer norske SMB-er risikoen mens dommene faller.