Innsikt · 1. mai 2026 · 9 min
EU AI Act i Norge: hva må gjøres før 2. august 2026.
EU AI Act trådte i kraft 1. august 2024. Etappevis implementering: 2. februar 2025 (forbud mot uakseptabel-risiko-systemer), 2. august 2025 (general purpose AI-regler), 2. august 2026 (full Annex III — high-risk-systemer), 2. august 2027 (resten av Annex I — sikkerhetskomponenter). Norge er bundet via EØS, og loven er forventet implementert i norsk rett gjennom Digitaliseringsdirektoratet og relevante tilsyn (Datatilsynet, Forbrukertilsynet, Finanstilsynet).
Med 13 uker igjen til 2. august 2026 er det fortsatt tid til å bli klare — men ikke til å starte fra null. Denne artikkelen er en konkret leseliste: hva må fikses, hva kan vente, og hva er feilforståelser jeg ser gjentatte ganger hos norske buyer-team.
1. Klassifiser systemet før du gjør noe annet
Den vanligste feilen er å hoppe rett til Article 9-15 og begynne å skrive dokumenter. Det er prematurt. Klassifiseringen avgjør om dere i det hele tatt er i scope for high-risk-regimet.
Hovedkategoriene under Annex III:
- Annex III(1) — biometrisk identifisering, ikke remote.
- Annex III(2) — kritisk infrastruktur (vei, vann, gass, strøm).
- Annex III(3) — utdanning og opplæring (admission, evaluering).
- Annex III(4) — ansettelse og HR (rekruttering, performance, oppsigelse).
- Annex III(5) — tilgang til offentlige tjenester og ytelser, kredittscoring, livsforsikring og helseforsikring-prising.
- Annex III(6) — politi/rettsvesen-bruk.
- Annex III(7) — migrasjon, asyl, grensekontroll.
- Annex III(8) — administrasjon av rettferdighet og demokratiske prosesser.
Praktisk konsekvens for nordisk B2B: kredittscoring (DNB, SpareBank1), rekruttering (HR-tech selskaper), forsikringspris (Storebrand, Gjensidige), offentlig saksbehandling (kommuner som tar i bruk AI), og healthtech er de vanligste high-risk-treffene. AI som hjelper salg, marketing, eller produktivitet faller som regel utenfor Annex III, men kan ha transparency-krav under Article 50.
Begynn med en klassifiseringsmemo. Dette er en kort skriftlig vurdering (typisk 3–5 sider) som dokumenterer hvilken kategori systemet faller i, med begrunnelse for hver delvurdering. Den memoen er det som driver alt det andre arbeidet — eller fritar dere fra det.
2. Hva betyr Article 9–15 i praksis?
Article 9–15 er kjernekravene for high-risk-systemer. Hver av dem er egentlig ikke vanskelig — men de må til sammen utgjøre et koherent kvalitetsregime. Her er en kort oversettelse av hver:
Article 9 — Risk management system
Et kontinuerlig regime, ikke ett dokument. Identifiser risikoer, evaluer dem, mitiger dem, oppdater prosessen når systemet eller bruksmiljøet endres. Krever at det er en eier, og at det skjer iterativt — ikke bare ved release.
Article 10 — Data governance
Datasett-statistikk, datalineage, dokumenterte bias-tester, og en plan for å fikse skjevheter dere finner. Også: rettighetskjeder for dataene (ble samtykke gitt? Var det lovlig grunnlag?).
Article 11 — Teknisk dokumentasjon
System architecture, training methodology, performance metrics, og en oversikt over alle endringer fra første versjon. Dette er den «tunge» bunken — kan være 30–80 sider for et reelt system.
Article 12 — Logging
Automatisk logging av inputs, outputs, og beslutninger på en måte som kan rekonstruere en gitt avgjørelse i ettertid. Immutable. Retention definert. Mange selskaper har applikasjons-logger, men ikke AI-spesifikk logging — det er en gap som må dekkes.
Article 13 — Transparency
Sluttbruker skal få vite at de samhandler med AI, hva systemets capabilities og begrensninger er, og hvordan output skal tolkes. Kombineres ofte med Article 50 sin bredere transparency-plikt.
Article 14 — Human oversight
En operatør skal kunne gripe inn, korrigere, eller overstyre. Det operative grensesnittet må være designet for dette — ikke bare en «approve all»-knapp.
Article 15 — Accuracy and robustness
Benchmark og degradation-monitoring. Hva er akseptert ytelsesnivå? Hvordan oppdager dere drift? Hvordan håndteres adversarial input?
3. Hva kan vente, og hva må gjøres nå
Med 13 uker igjen er prioriteringen pragmatisk: det som krever systemendringer må starte denne uken; det som er dokumentasjons-arbeid kan kjøres i juni og juli.
| Krav | Type | Når må det starte? |
|---|---|---|
| Klassifisering (Annex III) | Vurdering | Denne uken |
| Article 9 risk management system | Prosess | Mai |
| Article 10 data governance | Prosess + dok. | Mai |
| Article 12 logging | System-endring | Mai |
| Article 14 human oversight | System + UI | Mai/juni |
| Article 11 teknisk dokumentasjon | Dokumentasjon | Juni |
| Article 13 transparency-artefakter | Dokumentasjon + UI | Juni |
| Article 15 accuracy & robustness | Test + dok. | Juni/juli |
| Post-market monitoring plan | Plan | Juli |
| Conformity assessment | Selvattest / NB | Juli |
Article 12 (logging) er det som ofte krever mest reell systemendring og derfor må starte først. Article 14 (human oversight) kan kreve UI-endringer. De andre er stort sett strukturert beskrivelse av eksisterende systemer og prosesser — men det er fortsatt mye arbeid.
4. Feilforståelser jeg ser ofte
«Vi bruker GPT, så vendor er ansvarlig»
Nei. EU AI Act skiller mellom provider (den som leverer modellen som markedsført AI-system) og deployer (den som bruker den). Hvis dere setter opp et AI-system som bruker GPT under panseret, er dere typisk provider for det sammensatte systemet og må oppfylle Article 9-15. OpenAI dekker noen biter av det dere kan bygge på, men ikke hele bunken.
«Vi venter til august nærmer seg»
Da er det allerede for sent. Article 9 er en kontinuerlig prosess som må ha vært operativ over tid for å være troverdig. Article 12 logging krever historisk data — dere kan ikke bare snu bryteren 1. august og påstå at logging har vært på plass.
«Vi er bare en SaaS, ikke en AI-leverandør»
Hvis SaaS-en deres tar AI-drevne beslutninger som kvalifiserer under Annex III, så er dere AI-leverandør i loven sin forstand. Det er bruksområdet, ikke produktet, som klassifiserer.
«ISO 42001 erstatter EU AI Act-arbeidet»
Nei, men det hjelper. ISO 42001 er et governance-rammeverk; EU AI Act er substansielle krav. Hvis dere bruker ISO 42001 som strukturen for Article 9, kan mye gjenbrukes — men dere må fortsatt oppfylle de spesifikke EU AI Act-kravene i artikkelene.
5. Hva er en realistisk tidslinje?
For et selskap som starter nå (1. mai 2026) på et enkelt Annex III-system er en 4–6 ukers konformitets-sprint realistisk hvis det er én eier, én tech lead, og én juridisk-/compliance-side som er villig til å jobbe parallelt. Det er det Eksponent leverer som SKU A.
Større selskaper med flere systemer trenger lengre tid og en sentralisert AI governance-funksjon — ofte 3–6 måneder for en første runde. Da bør arbeidet ha startet allerede i januar/februar; det er fortsatt mulig å rekke 2. august, men marginen er tynn.
Vil dere se hvor dere står?
Vi har bygget en gratis selvvurdering som kjører 8 spørsmål gjennom en mini-versjon av klassifisering + dekningsanalyse. Resultatet vises umiddelbart, ingen e-post-gating.
Ta gratis EU AI Act-vurdering →
Skrevet av Eksponent. Denne artikkelen er generell informasjon og er ikke juridisk rådgivning. Konkrete tilfeller bør vurderes av kvalifisert jurist eller compliance-rådgiver.