EU AI Act: hva norske SMB-er må dokumentere

Nøkkelpunkter per 20. september 2026:

Hovedreglene gjelder to år etter ikrafttredelse, sannsynligvis midten av 2026, mens enkelte krav trer i kraft ett år tidligere (Deloitte, 2025).
Høyrisiko er terskelen som koster: krav til treningsdata, rettferdighet, åpenhet, dokumentasjon, menneskelig tilsyn og sikkerhet (Deloitte, 2025).
Behandler verktøyet personopplysninger, vil det ofte kreves en DPIA før systemet tas i bruk, etter GDPR artikkel 35 (Deloitte, 2025).
Leverandørens løfte er ikke dokumentasjon. Nvidia-sjef Jensen Huang mener sikkerhet er et ingeniørproblem, ikke et juridisk (TechCrunch).
Regningen kommer i etterkant: Meta betalte 18 milliarder dollar for å avgjøre et søksmål om skader på barn fra sosiale medier (TechCrunch).

Hva EU AI Act faktisk regulerer

EU AI Act er bygget som produktregulering. Den stiller krav til hva et system gjør og hvem det påvirker, ikke til hvilken modellarkitektur som ligger under panseret. Formålet er å legge til rette for trygg, tillitsvekkende og etisk bruk av kunstig intelligens, samtidig som reglene skal fremme innovasjon og konkurranseevne i EU (Deloitte, 2025). Den doble ambisjonen forklarer hele arkitekturen: de aller fleste systemer skal kunne brukes fritt, mens et mindretall får tunge plikter.

For en norsk SMB endrer det spørsmålet. Det relevante er ikke om dere «bruker AI», men hva dere bruker AI til, og hvem som bærer konsekvensen av et dårlig resultat. Svaret på det andre spørsmålet avgjør om etterlevelse er en ettermiddags arbeid eller et prosjekt som går over kvartaler.

Den vide definisjonen er inngangsporten

Definisjonen av et AI-system i forordningen er vid, og den avgjør om regelverket i det hele tatt kommer til anvendelse (Deloitte, 2025). Det er ikke en teknisk detalj, det er porten inn. Chatboten i kundeservice, scoringsmodellen i kredittvurderingen, CV-sorteringen i rekrutteringsverktøyet og prisoptimaliseringen i nettbutikken kan alle falle innenfor, selv om ingen av dem ble kjøpt inn med ordet «AI» på fakturaen.

Bredden er bevisst. En smal, teknisk definisjon ville vært utdatert før forordningen begynte å gjelde. Ulempen for deg som skal etterleve, er at du ikke kan avfeie noe som «bare statistikk» eller «bare en regelmotor» uten å vurdere det. Vurderingen må skrives ned, også når konklusjonen er at systemet faller utenfor. En oversikt over teknologiene som faktisk inngår finnes i vår gjennomgang av AI-teknologi.

Bruken plasserer deg, ikke teknologien

Samme språkmodell kan være fullstendig ubetydelig i en sammenheng og strengt regulert i en annen. Brukt til å skrive utkast til markedstekster, er risikoen for tredjeparter minimal. Brukt til å rangere søkere til en stilling, påvirker den et menneskes tilgang til arbeid. Teknologien er lik, pliktene er det ikke.

Dette er den viktigste mentale omstillingen for ledere som er vant til å tenke på IT-innkjøp. Du kan ikke godkjenne et verktøy en gang for alle. Du godkjenner en bruk, i en kontekst, med en beskrevet arbeidsflyt rundt. Endrer bruken seg, må vurderingen tas opp igjen.

Tidslinjen fra politisk enighet til krav som gjelder

EU-parlamentet kunngjorde 8. desember 2023 at det var oppnådd foreløpig politisk enighet om AI Act, og forordningen var ventet formelt godkjent før valget til Europaparlamentet i juni 2024 (Deloitte, 2025). Selve gjennomføringen er lagt opp med forsinket virkning, slik at markedet får tid til å tilpasse seg.

Trinn	Tidspunkt	Hva det betyr for deg
Foreløpig politisk enighet i EU	8. desember 2023	Innholdet i regelverket ble kjent i hovedtrekk
Forventet formell godkjenning	Før valget til Europaparlamentet i juni 2024	Teksten låses, tolkningsarbeidet starter
Enkelte krav trer i kraft	Ett år før hovedregelen	De tidligste pliktene gjelder før resten
Regelverket begynner å gjelde	To år etter ikrafttredelse, sannsynligvis midten av 2026	Hovedtyngden av kravene er bindende

To år til anvendelse, med unntak foran

Regelverket vil begynne å gjelde to år etter ikrafttredelse, sannsynligvis midten av 2026, men enkelte krav trer i kraft ett år tidligere (Deloitte, 2025). Den trappingen er verdt å merke seg i planleggingen: det finnes ingen enkelt dato der alt slår inn samtidig.

For virksomheter som har utsatt arbeidet i påvente av «endelig avklaring», er poenget ubehagelig enkelt. Avklaringen kommer ikke før kravene. Detaljer om standarder, veiledninger og tilsynspraksis modnes parallelt med at pliktene begynner å gjelde, ikke i god tid før.

Hva tidslinjen gjør med planleggingen din

Et kartleggingsprosjekt i en SMB tar typisk noen uker i kalendertid. Å rydde i en leverandøravtale tar lengre tid, fordi motparten må svare. Å bygge intern dokumentasjon for et system som allerede er i drift, tar lengst tid, fordi beslutningene som ble tatt underveis må rekonstrueres i etterkant.

Rekkefølgen bør derfor snus i forhold til magefølelsen: kartlegg først, avklar kontrakter deretter, og skriv dokumentasjonen sist, når du vet hva som faktisk må dekkes. Å starte med å skrive policy før du vet hva dere bruker, produserer dokumenter ingen kjenner seg igjen i.

Les også: Kvante-AI og fremtidens beregningskraft: Kvantecomputing møter kunstig intelligens. Det som tar en supercomputer 10 000 år kan en kvantecomputer løse på fire minutter.

Risikoklassifisering avgjør hvor tungt kravene treffer

Regelverket sorterer AI-bruk etter hvor stor skade den kan gjøre. De mest omfattende pliktene inntrer ved bruk av systemer klassifisert som høyrisiko, med krav til blant annet treningsdata, rettferdighet, åpenhet, dokumentasjon, menneskelig tilsyn og sikkerhet (Deloitte, 2025). Under den terskelen er byrden vesentlig lettere.

Nivå	Typisk bruk i en SMB	Hva som kreves av deg
Uakseptabel risiko	Praktisk talt ingen normal forretningsbruk	Bruken er forbudt
Høy risiko	Rekruttering, kredittvurdering, tilgang til tjenester, sikkerhetskritiske funksjoner	Full dokumentasjon, menneskelig tilsyn, testing, sikkerhet
Begrenset risiko	Kundechat, innholdsgenerering mot publikum	Åpenhet: brukeren skal vite at det er AI
Minimal risiko	Interne utkast, oppsummering, kodeassistanse	Ingen særskilte plikter, men intern styring anbefales

Høyrisiko er der pliktene hoper seg opp

Listen over høyrisikokrav er ikke en meny du kan velge fra. Den henger sammen: dokumentasjon uten testing er en påstand, testing uten logging er et engangsforsøk, og menneskelig tilsyn uten mandat til å overprøve er en formalitet. Det er helheten som utgjør etterlevelsen.

Den gode nyheten for de fleste SMB-er er at høyrisikobruk er unntaket, ikke regelen. Den dårlige er at unntakene ofte ligger nettopp i HR, finans og kundetilgang, altså i funksjoner der både ledelse og ansatte har vært raske til å ta i bruk nye verktøy på egen hånd.

Leverandør eller bruker: rollen avgjør pliktene

Regelverket skiller mellom den som utvikler og tilbyr et AI-system og den som tar det i bruk. De fleste norske SMB-er er brukere. Det gir lettere plikter enn utviklerens, men ikke ingen plikter. Bruken, opplæringen, tilsynet og informasjonen til de berørte er ditt ansvar uansett hvem som har bygget modellen.

Rollen kan også skifte uten at noen tar en beslutning om det. Finjusterer dere en modell på egne data, setter eget merkenavn på en tjeneste eller bruker et verktøy til noe annet enn leverandøren har angitt, kan dere gli over i en tyngre rolle. Den overgangen skjer stille, og den bør derfor være et fast punkt i endringsvurderingen.

Klassifiseringen er en beslutning, ikke en observasjon

Ingen sender deg en e-post om at systemet ditt er høyrisiko. Du må konkludere selv, med begrunnelse, og du må kunne vise hvordan du kom frem. En konklusjon uten spor er i praksis ingen konklusjon når et tilsyn eller en stor kunde spør.

Formatet trenger ikke være avansert. En side per system med formål, berørte, konklusjon, begrunnelse, dato og ansvarlig navn dekker behovet i de fleste SMB-er. Det som ikke holder, er en muntlig enighet i ledergruppen.

Fire spørsmål som avklarer om AI-verktøyet ditt er høyrisiko

Klassifiseringen kan gjøres håndterbar med fire spørsmål per verktøy. De erstatter ikke juridisk vurdering i grensetilfeller, men de sorterer ut de åpenbare tilfellene raskt og viser hvor du trenger hjelp. Bruk dem i samme rekkefølge hver gang, og skriv ned svarene.

Spørsmål	Svar som peker mot lav risiko	Svar som peker mot høy risiko
1. Hva brukes systemet til, og for hvem?	Internt arbeidsverktøy, utkast som alltid bearbeides	Beslutninger som rettes mot enkeltpersoner utenfor virksomheten
2. Påvirker utfallet rettigheter eller muligheter?	Påvirker bare arbeidsflyt og tidsbruk	Påvirker jobb, kreditt, pris, tilgang eller ytelser
3. Kan et menneske faktisk overprøve resultatet?	Ja, med tid, kompetanse og mandat	Nei, eller bare formelt uten reell mulighet
4. Behandles personopplysninger?	Nei, kun anonyme eller syntetiske data	Ja, særlig sensitive kategorier eller profilering

Spørsmål 1: hva brukes systemet til, og for hvem

Start med formålet slik det faktisk praktiseres, ikke slik det ble beskrevet ved innkjøp. Et verktøy som ble kjøpt for å «effektivisere dokumenthåndtering», kan i praksis brukes til å rangere leverandører eller forhåndssortere søknader. Beskriv bruken i en setning uten markedsføringsord. Klarer du ikke det, har du ikke kartlagt godt nok ennå.

Spørsmål 2: påvirker utfallet rettigheter eller muligheter

Dette er det spørsmålet som oftest flytter et system oppover i risikotrappen. Skillet går mellom systemer som hjelper ansatte å jobbe raskere, og systemer som avgjør noe for et annet menneske. Et prisverktøy som gir ulike kunder ulik pris basert på profilering er noe annet enn et prisverktøy som optimaliserer lagerbeholdning.

Test påstanden med et konkret scenario: hvis systemet tar feil om en enkeltperson, hva mister den personen? Er svaret «litt tid», er risikoen sannsynligvis lav. Er svaret «jobben, lånet eller tjenesten», er du i et annet regime.

Spørsmål 3: kan et menneske faktisk overprøve resultatet

Kravet om menneskelig tilsyn er en av kjernepliktene for høyrisikosystemer (Deloitte, 2025). I praksis strander mange virksomheter her, fordi tilsynet finnes på papiret, men ikke i arbeidshverdagen.

Sjekk tre ting: har personen som godkjenner nok tid til å vurdere, forstår vedkommende hva systemet baserer seg på, og har vedkommende reell myndighet til å si nei? Et godkjenningsklikk som gjentas mekanisk gjennom hele arbeidsdagen er ikke tilsyn, det er en automatisering med ekstra steg.

Spørsmål 4: behandles personopplysninger

Svarer du ja, har du utløst et parallelt regelverk. Ved behandling av personopplysninger med AI vil det ofte være nødvendig å utføre en DPIA før systemet tas i bruk, i henhold til GDPR artikkel 35 (Deloitte, 2025). Rekkefølgen er verdt å legge merke til: vurderingen skal gjøres før bruk, ikke som dokumentasjon i etterkant.

Mandag morgen: kartlegg AI-verktøyene dere allerede bruker

Alura mener at arbeidet bør starte med en enkel kartlegging av hvilke AI-verktøy som allerede er i bruk. De fleste virksomheter undervurderer antallet. Erfaringen er konsistent: listen ledelsen har i hodet er kortere enn listen som kommer frem når man ser i regnskapet og i påloggingsloggene.

Dette er også den billigste delen av etterlevelsen. Kartlegging krever ingen juridisk spisskompetanse, bare systematikk og et par dager. Alt annet arbeid blir feil dimensjonert uten den.

Begynn i regnskapet, ikke hos IT

De fleste AI-verktøy kommer inn i virksomheten på kort, ikke gjennom innkjøpsprosesser. Gå gjennom abonnementer, korttransaksjoner og fakturaer de siste tolv månedene og marker alt som er programvare. Deretter sjekker du hvilke av de eksisterende systemene som har fått AI-funksjoner i en oppdatering, noe som skjer uten at noen signerer på nytt.

Legg til to kilder mange glemmer: funksjoner i CRM-, regnskaps- og rekrutteringssystemer som er slått på som standard, og verktøy ansatte bruker gratis i nettleseren. Et gratisverktøy er ikke utenfor regelverket fordi det er gratis.

Malen som holder: seks kolonner

Registeret trenger ikke være mer enn et regneark, men det må ha nok kolonner til at klassifiseringen kan gjøres senere uten ny runde med spørsmål. Hold det oppdatert ved en fast gjennomgang, for eksempel hvert kvartal, og la endringer i bruk være et meldepliktig punkt internt.

Kolonne	Hva du fyller inn	Hvorfor det trengs senere
Verktøy og leverandør	Navn, tjeneste, avtaletype	Grunnlag for kontraktsgjennomgang
Faktisk bruk	En setning uten markedsføringsord	Avgjør risikoklassifiseringen
Ansvarlig person	Navngitt, ikke en avdeling	Uten navn skjer ingenting
Personopplysninger	Ja, nei, hvilke kategorier	Utløser vurdering etter GDPR artikkel 35
Beslutningspåvirkning	Hvem berøres av utfallet	Skiller høyrisiko fra resten
Menneskelig kontroll	Hvem godkjenner, og med hvilket mandat	Dokumenterer tilsynet

Dokumentasjonen du selv må eie

Alura mener at etterlevelse ikke kan kjøpes inn sammen med verktøyet. Leverandørløfter er et utgangspunkt for dokumentasjon, ikke en erstatning for den. Leverandøren kan dokumentere modellen sin, men ingen utenfor virksomheten kan dokumentere hvordan dere faktisk bruker den, hvem som godkjenner hva, og hva dere gjorde da det gikk galt.

Skillet er enkelt å huske: leverandøren eier systemet, du eier bruken. Dokumentasjonen din skal beskrive bruken.

Systemregisteret er grunnmuren

Registeret fra kartleggingen er ikke et forarbeid som kan kastes. Det er selve grunnlaget som alle senere vurderinger henger på, og det er det første et tilsyn eller en stor kunde vil be om. Uten et register må hver eneste spørsmålsrunde starte fra null.

Kravene til høyrisikosystemer omfatter blant annet treningsdata, rettferdighet, åpenhet og dokumentasjon (Deloitte, 2025). Der du ikke selv har trent modellen, blir oppgaven din å innhente og oppbevare leverandørens underlag, og notere hva du ikke fikk svar på.

Formål, testing og menneskelig tilsyn

For hvert system som er i grenseland eller over, skriv ned tre ting: hva systemet skal brukes til, hvordan dere har sjekket at det fungerer for deres data, og hvem som kan stoppe det. Testingen trenger ikke være akademisk. En strukturert stikkprøve på reelle saker, med resultater notert, er mer verdt enn en referanse til leverandørens benchmark.

Beskriv tilsynet i operative termer: rolle, tidsbruk, hva vedkommende ser, og hva som skjer ved avvik. Formuleringer som «alle resultater kvalitetssikres av ansatte» er ikke etterprøvbare og vil bli utfordret.

Logg, versjoner og hendelser

AI-systemer endrer seg uten at du gjør noe. Leverandøren bytter modell, justerer standardinnstillinger eller endrer hvordan data behandles. Hvis du ikke noterer når noe endret seg, kan du heller ikke forklare hvorfor resultatene ble annerledes i mars enn i januar.

Dokument	Hvem eier det	Oppdateres når
Systemregister	Virksomheten	Fast, for eksempel hvert kvartal
Risikovurdering per system	Virksomheten	Ved ny bruk eller endret formål
DPIA etter artikkel 35	Virksomheten	Før systemet tas i bruk
Teknisk modelldokumentasjon	Leverandøren, innhentet av deg	Ved versjonsbytte
Beskrivelse av menneskelig tilsyn	Virksomheten	Ved endring i rolle eller arbeidsflyt
Avviks- og hendelseslogg	Virksomheten	Løpende

Alura mener at når AI behandler personopplysninger, hører AI Act-arbeidet og GDPR-arbeidet sammen og bør gjøres i samme prosess. Virksomheter som kjører dem som to separate prosjekter, ender med to dokumentsamlinger som beskriver det samme systemet på hver sin måte, og som motsier hverandre ved første revisjon.

Overlappet er ikke tilfeldig. Begge regelverk stiller spørsmål om formål, om hvem som berøres, om hvilke data som brukes, og om hvilke tiltak som reduserer risiko. Det er de samme spørsmålene, stilt av to hjemler.

Når DPIA utløses

Ved behandling av personopplysninger med AI vil det ofte være nødvendig å utføre en DPIA før systemet tas i bruk, i henhold til GDPR artikkel 35 (Deloitte, 2025). For mange SMB-er er dette den første konkrete plikten som slår inn, fordi den utløses av dagens bruk, ikke av fremtidige datoer.

En DPIA er heller ikke en formalitet som lages ferdig og legges bort. Endrer dere formål, datakilder eller leverandør, må den oppdateres. Det er en av grunnene til at hendelses- og versjonsloggen fra forrige kapittel gjør dobbel nytte.

Artikkel 32 og 24: sikkerhet og ansvar

Kravene til sikker behandling av personopplysninger følger av GDPR artikkel 32 og 24 (Deloitte, 2025). Når data sendes til en AI-tjeneste, er spørsmålene de vanlige: hvor lagres de, hvem har tilgang, hvor lenge beholdes de, og brukes de til å trene modeller videre.

Det siste punktet er det som oftest overrasker. Standardinnstillinger i selvbetjeningsabonnementer kan skille seg vesentlig fra det som gjelder i en forhandlet virksomhetsavtale. Sjekk hvilken avtale dere faktisk har, ikke hvilken leverandøren markedsfører.

En prosess, ikke to spor

Praktisk løsning: lag en felles vurderingsmal der de fire klassifiseringsspørsmålene og DPIA-punktene står i samme dokument, per system. Da gjøres intervjuet med fagavdelingen en gang, og konklusjonene blir konsistente.

Spørsmål i vurderingen	AI Act	GDPR
Hva er formålet med bruken	Avgjør risikoklasse	Krav om formålsbegrensning
Hvem berøres av utfallet	Grunnlag for høyrisikovurdering	Grunnlag for DPIA etter artikkel 35
Hvilke data brukes	Krav til treningsdata og åpenhet	Lovlig grunnlag og dataminimering
Hvordan sikres systemet	Krav til sikkerhet	Artikkel 32 og 24
Hvem kan gripe inn	Menneskelig tilsyn	Rettigheter ved automatiserte avgjørelser

Les også: AI i utdanning: slik forandrer kunstig intelligens norsk skole og høyere utdanning. Slik forandrer AI undervisning og læring i Norge.

Hva etterlevelse koster, og hva unnlatelse har kostet andre

Den vanligste feilvurderingen i budsjettering av AI-etterlevelse er å lete etter en lisens som løser det. Det finnes verktøy som hjelper med registre og maler, men hovedkostnaden er interne timer: kartlegging, intervjuer med fagavdelinger, beslutninger om hva dere skal slutte med, og tiden det tar å få svar fra leverandører.

Kostnaden er dessuten svært ujevnt fordelt mellom virksomheter. To selskaper med samme omsetning kan ha helt ulik regning, avhengig av om de har høyrisikobruk i HR eller kreditt, eller bare interne produktivitetsverktøy.

Tre nivåer av innsats

Nivå en er virksomheter uten høyrisikobruk: kartlegging, en kort intern retningslinje, åpenhet der kunder møter AI, og en fast gjennomgang. Dette er dager, ikke måneder. Nivå to har ett eller to systemer i grenseland: da kommer DPIA, leverandørdialog og en dokumentert tilsynsordning i tillegg.

Nivå tre er virksomheter med klar høyrisikobruk. Her må dokumentasjon, testing, logging og tilsyn settes i system og holdes ved like, og arbeidet blir en driftsoppgave med navngitt eier. Vurderingen av hvilket nivå dere er på, følger direkte av kartleggingen. Det er nok en grunn til å gjøre den først.

Prisen på å ta det sent

Kostnaden ved å utsette er sjelden en bot i første omgang. Den er at en stor kunde stiller krav i en anbudsrunde og dere ikke kan svare, eller at et system må tas ut av drift midt i en travel periode fordi ingen kan dokumentere hvordan det brukes.

Fra det bredere teknologimarkedet finnes det harde påminnelser om hva etterlatt risiko kan koste. Meta betalte 18 milliarder dollar for å avgjøre et søksmål om skader på barn fra sosiale medier (TechCrunch). Det er ikke en AI Act-bot, og beløpet er ikke overførbart til en norsk SMB, men det illustrerer prisforskjellen mellom å håndtere risiko i forkant og i etterkant.

Leverandørdebatten: sikkerhet som ingeniørproblem

Når leverandøren din sier at sikkerhet er ivaretatt, er det verdt å vite hvilken tankegang utsagnet springer ut av. Nvidia-sjef Jensen Huang mener at sikkerhet er et ingeniørproblem, ikke et juridisk problem, og at AI er programvare og maskinvare bygget av mennesker som derfor kan kontrolleres med eksisterende lover (TechCrunch).

Argumentet hans går videre: markedskreftene er tilstrekkelige til å hindre utgivelse av usikre produkter, og nye lover er ikke nødvendige. Selskaper bør vente med å lansere til produktene er trygge, og markedet legger allerede press på dette (TechCrunch).

Motargumentet: produkter feiler også når viljen er god

Innvendingen er empirisk, ikke ideologisk. Selv velmenende selskaper sender ut feilvare, og CrowdStrike-hendelsen i 2024 med blåskjermer og kansellerte flyvninger er eksempelet som går igjen (TechCrunch). AI har dessuten allerede forårsaket skade, inkludert en modell som hacket Hugging Face og søksmål etter selvmord.

Huang mener at innovasjon, hastighet og trygge produkter ikke er et motsetningsforhold, og at man kan ha begge deler samtidig (TechCrunch). Det kan godt stemme på produktnivå. Det er bare ikke et svar på spørsmålet om hvem som bærer risikoen når det likevel svikter hos en kunde.

Hva dette betyr for kontrakten din

Et sikkerhetsløfte fra leverandøren er en påstand om produktet. Det du trenger, er dokumentasjon du kan legge frem om din bruk. Be konkret om tre ting: teknisk underlag om modellen og begrensningene dens, skriftlig svar på om data brukes til videre trening, og varsling ved vesentlige modellendringer.

Skriv ned hva du ikke får svar på. Et notat om at leverandøren ikke kunne bekrefte treningsdatagrunnlaget er i seg selv dokumentasjon av at dere har spurt, og det er grunnlag for å vurdere risikoen deretter.

Selvregulering, grunnmodeller og åpen kildekode

Alura mener at reguleringsdebatten mellom selvregulering og lovkrav ikke er avgjort internasjonalt, men at det for norske virksomheter er EU-sporet som gjelder i praksis. Uenigheten er reell, den pågår fortsatt, og den er verdt å kjenne fordi den forklarer hvorfor deler av regelverket er formulert som det er.

Den forklarer også hvorfor du ikke bør vente på at støvet legger seg. Forhandlingsposisjoner endrer seg, men planleggingshorisonten din gjør det ikke.

Frankrike, Tyskland og Italia ville ha selvregulering

EU-forhandlingene sto stille etter at EU-parlamentarikere forlot et møte i protest mot at Frankrike, Tyskland og Italia inngikk en mer formell avtale om selvregulering av grunnmodeller (silicon.co.uk). En EU-parlamentariker kalte avtalen mellom de tre landene en krigserklæring.

Parlamentet ønsket regulering av grunnmodeller i tillegg til mindre kraftige AI-systemer, og Brando Benifei mente at man ikke kan stole på frivillige avtaler (silicon.co.uk). Striden handlet altså ikke om hvorvidt AI skal reguleres, men om hvor i kjeden ansvaret skal ligge.

Uroen i OpenAI ga forhandlingene hastverk

Sam Altmans avgang fra OpenAI ga fornyet hastverk i EUs forhandlinger om regulering av grunnmodeller, og Alexandra van Huffelen mente hendelsene understreket behovet for regulering (silicon.co.uk). Argumentet var enkelt: hvis styringen i et av verdens ledende AI-selskaper kan bli ustabil over en helg, er frivillighet et tynt fundament.

Interessene i debatten er heller ikke skjult. Mark Zuckerberg har argumentert mot for restriktive reguleringer, mens Sam Altman har uttrykt skepsis til EU-lovgivning som kan klassifisere OpenAI som et høyrisikosystem (tapestry.vc, 2023). Marc Andreessen mener store AI-selskaper bør få bygge så raskt og aggressivt de kan, men ikke få oppnå regulatorisk fangst.

Åpen kildekode: regulering ved bruk eller ved utgivelse

Alex Engler har argumentert for at EUs forslag om å regulere open source-modeller vil skape juridisk ansvar som undergraver utviklingen, og konsentrere makten over AI hos de store teknologiselskapene (VentureBeat). Han er for AI-regulering, men mener regulering ved bruk er bedre enn ved utgivelse, og vil unnta selve handlingen å publisere en modell som open source.

Emily Bender påpeker på sin side at de eneste som kan dokumentere treningsdata grundig, er de som samler dem inn (VentureBeat). For deg som bruker en åpen modell er konsekvensen konkret: dokumentasjonen om datagrunnlaget finnes kanskje ikke i det hele tatt, og da må risikovurderingen din ta høyde for det i stedet for å anta at noen andre har gjort jobben.

Vanlige feil når SMB-er stoler på leverandørens løfter

Feilene under går igjen på tvers av bransjer, og de har det til felles at de føles fornuftige i øyeblikket. De koster først når noen utenfra stiller spørsmål: en kunde i en anbudsrunde, en revisor, en tillitsvalgt eller et tilsyn.

Ingen av dem krever juridisk spisskompetanse å unngå. De krever at noen har ansvaret og at arbeidet starter før fristen er nær.

Å ta markedsføringspåstander som dokumentasjon

«Vi er klare for EU AI Act» på en leverandørs nettside er en salgspåstand, ikke et etterlevelsesbevis. Den sier ingenting om hvordan dere bruker verktøyet, hvem som godkjenner utfallet eller hvilke data som sendes inn.

Be om det tekniske underlaget skriftlig, arkiver det sammen med systemregisteret, og noter datoen. Dokumentasjon som bare finnes som en påstand i et salgsmøte, finnes ikke.

Å kartlegge bare det IT har kjøpt inn

Kartlegginger som begynner og slutter i IT-avdelingens systemoversikt, treffer sjelden mer enn halve bildet. AI-funksjoner kommer også inn gjennom oppdateringer i eksisterende systemer og gjennom verktøy ansatte tar i bruk selv fordi de gjør jobben lettere.

Løsningen er ikke forbud i første omgang, men synlighet. Spør avdelingsvis hva folk faktisk bruker, gjør det uten sanksjonstrussel, og aksepter at listen blir lengre enn ventet. Bakgrunnsstoff til en slik intern runde finnes i vår komplette guide.

Å skille AI-arbeidet fra personvernarbeidet

To prosjekter, to maler, to eiere og to sett konklusjoner om samme system er en forutsigbar kilde til rot. Når DPIA-en sier ett formål og AI-vurderingen sier et annet, er begge svekket.

Kjør det som en prosess med et felles systemregister i bunn. Da stilles spørsmålene til fagavdelingen en gang, og dokumentene peker på hverandre i stedet for å konkurrere.

Ofte stilte spørsmål om EU AI Act

Spørsmålene under er de som oftest dukker opp i ledergrupper i norske SMB-er når temaet settes på agendaen første gang. Svarene er korte med vilje: de skal gi retning, ikke erstatte en konkret vurdering av deres egne systemer.

Gjelder EU AI Act for norske virksomheter?

I praksis er EU-sporet det som gjelder for norske virksomheter, og det er også Aluras posisjon. Kravene kommer til dere på to måter: gjennom regelverket selv, og gjennom kunder, eiere og partnere i EU som stiller kravene videre i sine avtaler. At et norsk advokatfirma gir norske virksomheter konkrete forberedelsesråd, sier sitt om relevansen (Deloitte, 2025).

Når må vi være klare?

Regelverket begynner å gjelde to år etter ikrafttredelse, sannsynligvis midten av 2026, mens enkelte krav trer i kraft ett år tidligere (Deloitte, 2025). Den delen av arbeidet som handler om personopplysninger har uansett ingen utsatt frist, fordi GDPR gjelder for bruken dere har i dag.

Er en chatbot eller skriveassistent høyrisiko?

Som regel ikke, så lenge den brukes til interne utkast eller til kundedialog der et menneske håndterer det som har konsekvenser. Det som flytter slike verktøy oppover, er når utfallet begynner å avgjøre noe for enkeltpersoner, for eksempel hvem som får svar, pris eller tilgang. Møter kunder en chatbot, gjelder uansett kravet om at de skal vite at de snakker med AI.

Holder det at leverandøren sier de etterlever regelverket?

Nei. Alura mener leverandørløfter er et utgangspunkt for dokumentasjon, ikke en erstatning for den. Leverandøren kan dokumentere modellen, men ikke deres formål, deres data, deres godkjenningsrutine eller deres avvikshåndtering. Det må dere eie selv, og det er den delen et tilsyn eller en storkunde faktisk etterspør.

Må vi gjøre en DPIA i tillegg til AI-vurderingen?

Behandler AI-verktøyet personopplysninger, vil det ofte være nødvendig med en DPIA før systemet tas i bruk etter GDPR artikkel 35 (Deloitte, 2025). Gjør den i samme prosess som AI-vurderingen. Spørsmålene overlapper i stor grad, og to separate løp gir motstridende dokumenter.

Oppsummering: de neste ukene

EU AI Act er ikke et teknologiprosjekt. Det er en styringsoppgave der de tyngste kravene rammer et mindretall av systemene, og der de fleste norske SMB-er vil lande på en håndterbar innsats. Forutsetningen er at de vet hva de bruker. Det er derfor kartleggingen er første steg og ikke et forarbeid.

Rekkefølgen som fungerer: kartlegg verktøyene i bruk, still de fire spørsmålene per verktøy, gjør DPIA der personopplysninger er involvert, hent inn leverandørunderlaget skriftlig, og beskriv det menneskelige tilsynet i operative termer. Sett en navngitt eier på registeret og en fast gjennomgang i kalenderen. Uten eier forvitrer arbeidet mellom kvartalene.

Debatten om selvregulering mot lovkrav vil fortsette internasjonalt, med sterke stemmer på begge sider og betydelige kommersielle interesser i spill (tapestry.vc, 2023). For en norsk virksomhet er den debatten interessant, men ikke styrende. Det som styrer, er hva dere kan dokumentere den dagen noen spør. For en bredere innføring i teknologien bak beslutningene, se gjennomgangen av hva AI er.

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

Deloitte (2025). EU AI Act: Hva må du vite og hvordan kan du forberede deg? | Deloitte Norge
TechCrunch. Nvidia's Jensen Huang: We don't need AI regulation — leave safety to us
silicon.co.uk. Sam Altman Ouster Adds Fuel To EU AI Regulation Debate
tapestry.vc (2023). Navigating the AI Regulation Debate
VentureBeat. EU AI Act's possible open-source regulation sparks Twitter debate | VentureBeat