AI Act-programvare kan organisere oversikt, vurderinger og dokumentasjon av KI-systemer. For en norsk virksomhet må valg av verktøy bygge på konkrete roller og bruksområder, samtidig som EU-frister holdes adskilt fra norsk gjennomføring. Her brukes etterprøvbare anskaffelseskriterier uten udokumenterte leverandørrangeringer eller markedspriser.
Oppdatert EU-tidslinje og separat norsk vurdering
EU-kommisjonens oversikt, kontrollert 8. september 2026, oppgir at KI-omnibus trådte i kraft 27. juli 2026. For høyrisikobruk i bestemte følsomme områder etter vedlegg III er datoen 2. desember 2027. For høyrisikosystemer integrert i regulerte produkter er datoen 2. august 2028. Generell anvendelse og relevante åpenhetskrav fra 2. august 2026 må ikke blandes sammen med disse overgangsreglene.
Forbudte praksiser og KI-kompetanse fikk anvendelse i EU 2. februar 2025, og GPAI-regler samt deler av styringsreglene 2. august 2025. Kontroller konkret bestemmelse, rolle og særskilte overgangsregler for hvert system; ett årstall dekker ikke hele regelverket.
KI Norges veiledning om norsk gjennomføring forklarer EØS-relevans og arbeidet med norsk KI-lov. EU-datoene er ikke i seg selv dokumentasjon på norsk ikrafttredelse. Før dere legger en innenlandsk plikt eller frist til grunn, kontroller vedtatt norsk lov, ikrafttredelse og EØS-innlemmelse. Norske aktører kan dessuten måtte vurdere forordningens territorielle virkeområde ved aktivitet rettet mot EU, uavhengig av tidspunktet for norsk gjennomføring.
GDPR gjelder allerede etter personopplysningsloven innenfor sitt virkeområde. Vurder behandlingsgrunnlag, rettigheter, artikkel 22 og behovet for DPIA separat; bruk av KI medfører ikke automatisk at alle vilkårene i disse bestemmelsene er oppfylt.
For virksomheter som allerede fører behandlingsprotokoll og gjennomfører personvernkonsekvensvurderinger, er ikke KI-forordningen fremmed. Mange av kravene – risikovurdering, dokumentasjon, datagrunnlagets kvalitet, åpenhet – er beslektet med GDPR. Et godt AI Act-verktøy bygger derfor videre på personvernarbeidet framfor å starte på nytt.
Status for KI-forordningen i Norge
For behandling av personopplysninger gjelder GDPR i Norge gjennom personopplysningsloven. Datatilsynet er en sentral aktør i KI-tilsynet, blant annet gjennom sin regulatoriske sandkasse for kunstig intelligens.
Risikoklassene i KI-forordningen
| Risikoklasse | Eksempler | Krav |
|---|---|---|
| Uakseptabel risiko | Sosial skår, manipulerende systemer | Forbudt |
| Høy risiko | KI i rekruttering, kredittvurdering, kritisk infrastruktur | Streng dokumentasjon, risikostyring, menneskelig tilsyn |
| Begrenset risiko | Chatboter, generert innhold | Åpenhetsplikt |
| Minimal risiko | Spamfiltre, spill | Ingen særkrav |
Hva må AI Act-programvare dekke?
Et godt verktøy bør hjelpe virksomheten å: føre et register over KI-systemene som brukes eller utvikles; klassifisere hvert system etter risiko; dokumentere høyrisikosystemer med teknisk dokumentasjon, datagrunnlag og risikostyring; sikre menneskelig tilsyn og åpenhet; og koble KI-styringen til personvernkonsekvensvurderinger der KI behandler personopplysninger.
Hvordan velge AI Act-verktøy for en norsk virksomhet
Start med å kartlegge KI-systemene virksomheten faktisk bruker – inkludert innkjøpte verktøy som rekrutteringssystemer, kredittscoring og generativ KI. Klassifiser hvert system etter risiko. Omfang og plikter må vurderes ut fra de konkrete systemene og bruksområdene.
De trinnvise fristene i KI-forordningen
Et godt verktøy hjelper virksomheten å holde oversikt over at KI-forordningen innføres i etapper, ikke på én dato:
Datatilsynets rolle i KI-tilsynet
I Norge er Datatilsynet en sentral aktør i tilsynet med KI som behandler personopplysninger. Tilsynet driver blant annet en regulatorisk sandkasse for kunstig intelligens, der virksomheter kan utvikle KI-løsninger i dialog med myndigheten. Det er et signal om at Datatilsynet både veileder og kontrollerer på KI-feltet. For virksomheter som utvikler høyrisiko-KI som behandler personopplysninger, er det derfor klokt å bygge KI-styringen på det eksisterende personvernarbeidet framfor å behandle KI-forordningen som et isolert regelverk. Se guiden til Datatilsynet for mer om myndighetens arbeidsform.
Spørsmål å stille AI Act-leverandøren
Før du velger verktøy, be leverandøren svare på: Kan verktøyet føre et register over KI-systemene og klassifisere dem etter risiko? Kobler det høyrisiko-KI til personvernkonsekvensvurdering og behandlingsprotokoll der KI behandler personopplysninger? Dekker det dokumentasjonskravene for høyrisikosystemer? Ligger data innenfor EØS med norsk utdata? Og lar det seg samordne med det bredere samsvarsarbeidet? Svarene skiller de plattformene som faktisk letter KI-styringen fra dem som bare tilbyr en tom mal.
Trenger en vanlig virksomhet AI Act-programvare?
Behovet avhenger av systemer, roller og dokumentasjonsmengde. En liten portefølje kan håndteres med enklere rutiner dersom ansvar, oppdatering og nødvendig bevisføring faktisk fungerer. Et kjøp må begrunnes i oppgaver som skal løses.
Hva regnes som et høyrisiko-KI-system?
KI-forordningen definerer høyrisikosystemer blant annet som KI brukt i rekruttering, kredittvurdering, utdanning, kritisk infrastruktur og enkelte offentlige tjenester. Slike systemer utløser strenge krav til risikostyring, datagrunnlag, teknisk dokumentasjon, menneskelig tilsyn og logging. Et innkjøpt rekrutteringsverktøy med KI kan altså gjøre en helt vanlig virksomhet til bruker av et høyrisikosystem.
Overlapper KI-forordningen med GDPR?
Ja, tungt. Der KI behandler personopplysninger, gjelder GDPR fullt ut i tillegg til KI-forordningen. Artikkel 22 og 35 har egne vilkår som må vurderes separat fra KI-klassifiseringen. Felles dokumentreferanser kan redusere dobbeltarbeid, men garanterer ikke konsistente eller riktige konklusjoner.
Anskaffelsesprøve med et konkret eksempel
Bruk et hypotetisk system og syntetiske data når dere vurderer et styringsverktøy. En tenkt virksomhet ønsker å innføre KI som sorterer søknader. Først registreres hva systemet skal gjøre, hvem som leverer det, hvem som bruker resultatet og hvilke personer som kan påvirkes. Eksemplet er et utgangspunkt for vurdering, ikke en konklusjon om klassifisering av alle rekrutteringsverktøy.
Be leverandøren vise hvordan en ansvarlig person undersøker regelverket, noterer manglende opplysninger og begrunner klassifiseringen. Et automatisk forslag må kunne overprøves og forklares. Systemet skal ikke skjule usikkerhet bak et grønt symbol. Dersom bruken endres fra praktisk sortering til en beslutning med vesentlig virkning for en person, må relevante vurderinger kunne tas opp igjen.
La deretter en annen bruker overta saken. Kan vedkommende finne kildene, se forutsetningene og forstå hvem som besluttet hva? En tidslinje med bare navn og dato kan være utilstrekkelig dersom selve begrunnelsen mangler. Kontroller også om tidligere versjoner kan skilles fra gjeldende beslutning. Uten denne forskjellen kan et gammelt svar bli brukt som godkjenning for et nytt formål.
Arbeidskrav som kan kontrolleres
| Oppgave | Dokumentasjon i demonstrasjonen |
|---|---|
| Kartlegging | System, formål, rolle, eier og bruksområde |
| Regelvurdering | Konkrete kriterier, kilder og begrunnet beslutning |
| Åpne spørsmål | Navngitt ansvarlig og tydelig mangel på dokumentasjon |
| Endring | Ny versjon med vurdering av hvilke tidligere forutsetninger som endres |
| Personvern | Kobling til behandling og separat vurdering av GDPR-vilkår |
| Tilgang | Roller for lesing, redigering og faglig beslutning |
| Eksport | Lesbart innhold med vedlegg og nødvendig historikk |
| Avslutning | Tilbakelevering, sletting og stenging av forbindelser |
Noter for hvert punkt hvilken versjon og lisens leverandøren viste. En funksjon som bare finnes i en annen pakke, er ikke nødvendigvis del av tilbudet. Fremtidig utvikling må beskrives som en plan. Hvis funksjonen er nødvendig for deres planlagte prosess, må anskaffelsen ta høyde for at den ennå ikke kan brukes.
Sammenlign kostnader med likt omfang
Be om skriftlige tilbud med samme antall systemer, brukere, vurderinger og integrasjoner. Skill lisens fra innføring, migrering, opplæring og støtte. Avklar om eksport, tilgang til historikk og avslutning medfører egne kostnader. Uten et likt omfang kan en tilsynelatende billigere løsning dekke vesentlig færre av oppgavene virksomheten trenger.
Ta også med internt arbeid. Fagmiljøene må beskrive systemet, fremskaffe opplysninger og vurdere bruken selv om programvaren organiserer dokumentene. Ikke presenter en hypotetisk intern beregning som en markedspris. I denne artikkelen er ingen konkrete pristilbud innhentet, og det gis derfor ingen påstand om et normalt norsk prisnivå eller at én kategori alltid er rimeligst.
Leverandørens dokumentasjon og deres egne plikter
Et produkt kan komme med tekniske beskrivelser, instruksjoner og vurderinger. Undersøk hvilke av disse som gjelder den kjøpte versjonen og det planlagte formålet. Leverandørens klassifisering kan være relevant, men virksomheten må forstå sitt eget ansvar og sin egen bruk. En endret konfigurasjon eller et nytt bruksområde kan gjøre tidligere forutsetninger utilstrekkelige.
Skille mellom modell, system og den faktiske organisatoriske anvendelsen er særlig viktig. En generell modell kan inngå i flere systemer med ulike formål. Dokumentasjonen for modellen alene forklarer ikke nødvendigvis konsekvensene av en beslutningsprosess der systemet brukes. Lag derfor egne referanser og ansvar for de delene dere faktisk vurderer.
Personopplysninger i styringsplattformen
Også et verktøy for etterlevelse kan behandle personopplysninger: navn på ansatte, hendelsesbeskrivelser, vurderinger og vedlegg. Undersøk leverandørrolle, databehandleravtale, supporttilgang og eventuelle overføringer. Et europeisk datasenter sier ikke alene hvem som kan lese innholdet. Kartlegg de konkrete mottakerne og vurder nødvendige garantier.
Bruk syntetisk materiale i pilotfasen når funksjonen kan vurderes uten ekte personopplysninger. Ikke last opp komplette søknader for å se hvordan en rapportsmal ser ut. Hvis faktiske opplysninger er nødvendige, må formål, grunnlag, tilgang og sletting være avklart. Kontroller at testfiler og eksportkopier ikke blir liggende etter at demonstrasjonen er over.
Godkjenning med dokumenterte grenser
Skriv hva som er vurdert, hva som er observert og hva som fortsatt mangler. En bestått anskaffelsesprøve viser funksjonen i det undersøkte omfanget; den beviser ikke generell etterlevelse av KI-forordningen eller GDPR. Den behandlingsansvarlige og andre relevante aktører beholder sine plikter. Programvaren kan støtte prosessen, men kan ikke ta over all faglig beslutning.
Etter innføring følger dere ett reelt, avgrenset system gjennom registrering, vurdering og endring. Kontroller at ansvarlige mottar oppgaver, at beslutningene er forståelige og at nødvendige opplysninger kan eksporteres. Ved endringer i lovgrunnlag, norsk gjennomføring eller den faktiske bruken vurderes hvilke dokumenter som må oppdateres. Hold EU-tidslinjen og dokumentert norsk status som separate opplysninger.
Knytt arbeidet til behandlingsprotokollen, DPIA-vurderingen, databehandleravtalen, overføring til tredjeland og planen for avslutning av databehandler. Disse prosessene gir ulike dokumentasjonsgrunnlag og må vurderes etter sine egne vilkår.