# EU AI Act — Samsvarsvurdering og EU-samsvarserklæring **Last updated:** 2026-07-15 **Status:** GA **Category:** Responsible AI & Governance **Type:** regulatory --- ## Innhold - [Oversikt](#oversikt) - [Annex IV — 9-element sjekkliste for teknisk dokumentasjon](#annex-iv--9-element-sjekkliste-for-teknisk-dokumentasjon) - [EU-samsvarserklæring-mal (Art. 47)](#eu-samsvarserklæring-mal-art-47) - [Intern vs. ekstern samsvarsvurdering](#intern-vs-ekstern-samsvarsvurdering) - [Prosess-tidslinje: Fra design til CE-merking](#prosess-tidslinje-fra-design-til-ce-merking) - [Norsk kontekst](#norsk-kontekst) - [For Cosmo](#for-cosmo) ## Oversikt EU AI Act kapittel 5 (Art. 43–49) stiller krav om formell samsvarsvurdering (conformity assessment) for høyrisiko-AI-systemer før de kan plasseres på markedet eller tas i bruk. For de fleste systemer i Annex III kan dette gjøres internt av tilbyderen selv. Samsvarsvurderingen dokumenteres i teknisk dokumentasjon (Annex IV) og avsluttes med en EU-samsvarserklæring (Art. 47) og CE-merking (Art. 48). --- ## Annex IV — 9-element sjekkliste for teknisk dokumentasjon Annex IV spesifiserer hvilken teknisk dokumentasjon som kreves. Under følger hvert element med krav, eksempler og typiske mangler. ### Element 1: Generell beskrivelse av AI-systemet **Hva kreves:** - Formål, tiltenkt bruk og brukergrupper - Systemkategori (Annex III-referanse) - Versjonsnummer og dato - Overordnet beskrivelse av funksjonalitet **Eksempel:** > "VegvAI-Saksbehandler v2.1 er et beslutningsstøttesystem for saksbehandlere i Direktoratet for digital tjenesteutvikling (Annex III, punkt 5a). Systemet analyserer søknader om dispensasjon fra veitrafikklovgivningen og genererer et begrunnet utkast til vedtak. Endelig vedtak fattes alltid av autorisert saksbehandler." **Typiske mangler:** - Annex III-kategorien er ikke spesifisert - Brukergrupper er for vagt beskrevet ("offentlig sektor") - Systemet er ikke avgrenset mot hva det IKKE gjør --- ### Element 2: Detaljert beskrivelse av systemkomponentene og utviklingsprosessen **Hva kreves:** - Arkitekturdiagram med dataflyt - Treningsdata: opprinnelse, omfang, preprosessering - Treningsmetode og valideringsprosess - Tredjepartskomponenter (f.eks. Azure OpenAI, modell-id) - Versjonskontroll og endringshåndtering **Eksempel:** > "Systemet benytter Azure OpenAI GPT-4o (modell-id: gpt-4o-2024-08-06) via Microsoft Foundry. Treningsdata er ikke benyttet — systemet er prompt-engineered med virksomhetens egne saksmaler. Retrieval-augmented generation (RAG) er implementert mot en Azure AI Search-indeks med 12 000 dokumenter fra Lovdata og interne retningslinjer. Indeksen oppdateres månedlig." **Typiske mangler:** - Konkret modell-ID mangler (bare "GPT-4" oppgitt) - Dataflyt mellom komponenter er ikke dokumentert - Tredjeparts-leverandørens egne dokumenter er ikke vedlagt --- ### Element 3: Detaljert informasjon om monitorering, funksjonalitet og kontroll **Hva kreves:** - Monitoreringsplan for produksjonsmiljø - KPI-er og grenseverdier som utløser tiltak - Hendelseslogg og varslingsprosedyrer - Human-in-the-loop-mekanismer **Eksempel:** > "Azure Monitor overvåker responskvalitet og latens kontinuerlig. Terskler: hallusinasjonsrate > 2% utløser automatisk varsling til AI-ansvarlig. Saksbehandler vurderer alltid AI-utkast og kan avvise eller redigere. Avvisningsrate logges ukentlig og aggregeres i månedlig kvalitetsrapport." **Typiske mangler:** - KPI-er er ikke kvantifisert - Varslingsprosedyre er ikke definert (hvem varsles, innen hvilken tid?) - Human-in-the-loop er beskrevet som intensjon, ikke som teknisk implementering --- ### Element 4: Beskrivelse av systemets nøyaktighet, robusthet og cybersikkerhet **Hva kreves:** - Nøyaktighetsmetrikker (presisjon, recall, F1 o.l.) fra validering - Robusthetstesting (adversarial inputs, distribusjonsskift) - Cybersikkerhetsarkitektur og sårbarhetsanalyse - Tiltak mot prompt injection og data poisoning **Eksempel:** > "Validering på 500 historiske saker: presisjon 94%, recall 89%, F1 0,915. Adversarial testing gjennomført av intern red team (20 angrepsvektorer). Prompt injection mitigert via input sanitering og systemprompt-hardening. Modellen er ikke tilgjengelig fra internett — all trafikk går via privat Azure-endepunkt (Private Endpoint)." **Typiske mangler:** - Nøyakshetsmetrikker er ikke oppgitt eller kun beskrevet kvalitativt - Robusthetstesting er ikke dokumentert - Cybersikkerhet er referert til generelle policyer uten systemspesifikk analyse --- ### Element 5: Beskrivelse av risikostyringssystemet (Art. 9) **Hva kreves:** - Risikovurderingsprosess og -metodikk - Identifiserte risikoer med sannsynlighet og konsekvens - Risikoreduserende tiltak - Restrisiko og akseptkriterier - Prosess for løpende risikovurdering **Eksempel:** > "Risikostyring følger NS 5814:2021 og SSBs veileder for AI-risiko. Risikovurdering gjennomføres ved lansering og ved vesentlige endringer. Kritisk risiko: feilaktige vedtaksutkast som saksbehandler godkjenner uten kritisk vurdering. Tiltak: opplæringsprogram, UI-design som fremhever usikkerhetsmarkering, månedlig stikkprøvekontroll av 5% av vedtak." **Typiske mangler:** - Restrisiko er ikke akseptert av ledelsen formelt - Løpende risikovurdering er ikke planlagt (kun ved lansering) - Kobling mellom risikoregister og Art. 9-krav mangler --- ### Element 6: Beskrivelse av endringer gjennom livssyklusen **Hva kreves:** - Endringslogg med semantisk versjonering - Definisjon av vesentlig endring (substantial modification, Art. 3(23)) - Prosess for revurdering av samsvar ved endringer - Planlagt avvikling/erstatning **Eksempel:** > "Vesentlig endring er definert som: ny Annex III-kategori, ny brukergruppe, ny modell (annen leverandør), endret formål, eller nøyakshetsfall > 5 prosentpoeng. Ved vesentlig endring gjennomføres full samsvarsvurdering på nytt. Mindre endringer (prompt-justering, indeksoppdatering) loggføres i endringslogg og vurderes av AI-ansvarlig." **Typiske mangler:** - Vesentlig endring er ikke operasjonelt definert - Det finnes ingen prosess for å avgjøre om en endring er vesentlig - Endringslogg er ikke koblet til samsvarsvurderingen --- ### Element 7: Kvalitetsstyringssystem (QMS) beskrivelse **Hva kreves:** - Referanse til organisasjonens QMS - AI-spesifikke prosedyrer (Art. 17) - Kompetansekrav og opplæringsplan - Dokumentstyring **Eksempel:** > "Direktoratet for digital tjenesteutvikling følger ISO 9001:2015. AI-spesifikke tilleggsprosedyrer: DDT-AI-P01 (Anskaffelse av AI-systemer), DDT-AI-P02 (Samsvarsvurdering), DDT-AI-P03 (Incident management). AI-ansvarlig (rolle) er utpekt og har gjennomført EU AI Act Foundation-sertifisering (IAPP, 2025)." **Typiske mangler:** - QMS er referert uten AI-spesifikke prosedyrer - Kompetansekrav er ikke operasjonalisert - Dokumentstyring for AI-artefakter er ikke beskrevet --- ### Element 8: Informasjon om EU-samsvarserklæringen og CE-merking **Hva kreves:** - Referanse til EU-samsvarserklæringen (Art. 47) - CE-merking med notified body-nummer hvis eksternt vurdert - Plassering av CE-merking i brukerdokumentasjon **Eksempel:** > "EU-samsvarserklæring datert 2026-01-15, signert av daglig leder. Intern samsvarsvurdering (Annex VI) — ingen notified body involvert. CE-merking er synlig i administratorpanelet og i brukerdokumentasjon (versjon 2.1, seksjon 1.2)." **Typiske mangler:** - CE-merkingen er plassert, men ikke synlig for brukere som Art. 48 krever - Samsvarserklæringen er ikke datert eller signert av autorisert person --- ### Element 9: Registreringsinformasjon for EU-database **Hva kreves:** - Registreringsnummer fra EU-databasen (Art. 49) — registrering kreves før systemet plasseres på markedet / tas i bruk (høyrisiko-anvendelse utsatt til 2. desember 2027 via Digital Omnibus, provisorisk — avventer OJ) - Bekreftelse på at registrering er fullført - URL til offentlig oppføring **Eksempel:** > "Registrert i EU AI Act Database: EUAI-2026-NO-00142. Offentlig oppføring: https://eudatabase.ec.europa.eu/ai/NO/00142. Registrering gjennomført 2026-01-20 av AI-ansvarlig." **Typiske mangler:** - Registrering er ikke gjennomført (mange venter til siste frist) - Registreringsnummer er ikke inkludert i teknisk dokumentasjon --- ## EU-samsvarserklæring-mal (Art. 47) Følgende mal kan brukes direkte. Fyll ut alle felter merket med [KLAMME]. --- **EU-SAMSVARSERKLÆRING** *Utstedt i henhold til Europaparlamentets og Rådets forordning (EU) 2024/1689 (EU AI Act) artikkel 47* **1. Tilbyderens identifikasjon** Navn: [Organisasjonens fulle navn] Organisasjonsnummer: [NO-nummer] Adresse: [Gateadresse, postnummer, by] Kontaktperson for AI Act-henvendelser: [Navn, e-post, telefon] **2. AI-systemets identifikasjon** Systemnavn: [Navn på AI-systemet] Versjon: [Versjonsnummer, f.eks. v2.1.0] Kort beskrivelse: [2–3 setninger om formål og funksjon] Programvare-/maskinvarekomponenter: [Liste over kjernedeler] **3. Annex III-kategorisering** Dette AI-systemet faller inn under Annex III, [punkt X], underpunkt [X(x)]: [Sitat fra Annex III som er relevant] **4. Samsvarsvurderingsmetode** [ ] Intern samsvarsvurdering i henhold til Annex VI (Art. 43(2)) [ ] Ekstern samsvarsvurdering av notified body i henhold til Annex VII (Art. 43(1)) Hvis ekstern: Notified body-navn og akkrediteringsnummer: [Navn, nr.] Attestnummer: [Attestnummer fra notified body] **5. Refererte harmoniserte standarder og tekniske spesifikasjoner** [Liste over relevante standarder, f.eks.:] - ISO/IEC 42001:2023 — AI Management Systems - ISO/IEC 27001:2022 — Information Security - CEN/CENELEC [nummer] — [Harmonisert standard når tilgjengelig] - ETSI EN 303 645 — [Hvis relevant for edge-deployment] **6. Teknisk dokumentasjon** Teknisk dokumentasjon utarbeidet i henhold til Annex IV er tilgjengelig hos tilbyderen og kan fremlegges for relevante myndigheter på forespørsel. Dokumentreferanse: [Intern dokumentkode, f.eks. DDT-AI-TD-001 v2.1] **7. EU-databaseregistrering** Registreringsnummer: [EUAI-YYYY-NO-XXXXX] Registreringsdato: [ÅÅÅÅ-MM-DD] **8. Erklæring** Herved erklærer vi på eget ansvar at AI-systemet beskrevet ovenfor er i samsvar med kravene i forordning (EU) 2024/1689 (EU AI Act), særlig kapittel III avdeling 3. Sted og dato: [By], [ÅÅÅÅ-MM-DD] Signatur: ___________________________ Navn og stilling: [Navn], [Stilling — typisk daglig leder eller bemyndiget person] --- ## Intern vs. ekstern samsvarsvurdering ### Intern samsvarsvurdering (Art. 43(2), Annex VI) **Når kan det brukes:** - Alle høyrisiko-systemer i Annex III **unntatt** biometrisk fjernidentifisering i offentlige rom og systemer som faller inn under Annex I (produktsikkerhetsdirektiver) - Det vil si: de fleste systemer i offentlig sektor kan bruke intern prosedyre **Prosedyre (Annex VI):** 1. Tilbyderen utarbeider teknisk dokumentasjon (Annex IV) 2. Kvalitetsstyringssystem (Art. 17) er etablert og operativt 3. Teknisk dokumentasjon gjennomgås og godkjennes internt 4. EU-samsvarserklæring utarbeides og signeres 5. CE-merking påføres 6. Registrering i EU-database (Art. 49) **Fordeler:** Raskere, billigere, full kontroll **Risiko:** Intern bias — sørg for uavhengig intern review ### Ekstern samsvarsvurdering (Art. 43(1), Annex VII) **Når er det påkrevd:** - AI-systemer for biometrisk fjernidentifisering (Annex III, punkt 1) - Systemer under produktsikkerhetsdirektiver (Annex I) der disse direktivene krever tredjeparts sertifisering - Frivillig, hvis organisasjonen ønsker ekstra troverdighet **Prosedyre (Annex VII):** 1. Velg akkreditert notified body (liste på NANDO-portalen) 2. Lever teknisk dokumentasjon til notified body 3. Notified body gjennomfører vurdering (typisk 3–6 måneder) 4. Attestnummer utstedes 5. Tilbyderen utsteder EU-samsvarserklæring med attestnummer 6. CE-merking med notified body-nummer **Kostnad:** Typisk 50 000–300 000 NOK avhengig av systemets kompleksitet ### Beslutningstre ``` Er systemet for biometrisk fjernidentifisering? ├─ JA → Ekstern vurdering (Annex VII) PÅKREVD └─ NEI → Faller systemet under Annex I (produktsikkerhetsdirektiver)? ├─ JA → Sjekk om det relevante direktivet krever notified body └─ NEI → Intern vurdering (Annex VI) er tilstrekkelig (Frivillig ekstern vurdering kan velges for troverdighet) ``` **For norsk offentlig sektor:** Typiske systemer (saksbehandlingsstøtte, tildeling av ytelser, trafikkoptimalisering) kan bruke intern prosedyre. Det finnes per 2026-02 ingen norske akkrediterte notified bodies for AI Act — EU-baserte må benyttes for ekstern vurdering. --- ## Prosess-tidslinje: Fra design til CE-merking | Fase | Aktivitet | Typisk varighet | |------|-----------|-----------------| | 1. Klassifisering | Avgjør om systemet er høyrisiko (Annex III) | 1–2 uker | | 2. Gap-analyse | Sammenlign nåværende praksis mot Art. 9–17-krav | 2–4 uker | | 3. Risikostyring | Etablér risikovurderingsprosess og -register (Art. 9) | 4–8 uker | | 4. Data governance | Dokumentér treningsdata og datakvalitetstiltak (Art. 10) | 2–6 uker | | 5. Teknisk dokumentasjon | Skriv Annex IV-dokumentasjonen (alle 9 elementer) | 4–8 uker | | 6. QMS-tilpasning | Tilpass kvalitetsstyringssystem til Art. 17-krav | 2–4 uker | | 7. Intern review | Uavhengig intern gjennomgang av teknisk dokumentasjon | 2–3 uker | | 8. Samsvarserklæring | Utarbeid og signer EU-samsvarserklæring (Art. 47) | 1 uke | | 9. Registrering | Registrer i EU-database (Art. 49) | 1 uke | | 10. CE-merking | Påfør CE-merking i dokumentasjon og UI | 1 uke | | **Totalt (intern)** | | **3–9 måneder** | | **Totalt (ekstern)** | Legg til 3–6 måneder for notified body-prosess | **6–15 måneder** | **Kritisk sti:** Risikostyring (fase 3) og teknisk dokumentasjon (fase 5) er de mest tidkrevende fasene. Start disse tidlig. --- ## Norsk kontekst ### Tilsynsmyndighet Nkom er utpekt som koordinerende nasjonal markedstilsynsmyndighet og nasjonalt kontaktpunkt for KI-forordningen, med ansvar for at EUs regler følges opp på en enhetlig måte i Norge (formell forankring via KI-loven, ventet i kraft sensommer 2026). Tilsynsstrukturen for øvrig: - **Nkom:** Koordinerende markedstilsynsmyndighet og nasjonalt kontaktpunkt for KI-forordningen - **Datatilsynet:** Tilsynsmyndighet for AI-systemer som behandler personopplysninger - **Sektortilsyn:** Finanstilsynet (finansielle tjenester), Helsetilsynet (helse), Luftfartstilsynet (transport) for domene-spesifikke systemer - **Digdir:** Fagansvarlig for KI Norge og koordinering av offentlig sektor For offentlig sektor anbefales å holde dialog med Nkom, Datatilsynet og Digdir. ### EØS-overgangsordninger EU AI Act trådte i kraft i EU 1. august 2024 med stegvise ikrafttredelsesdatoer: - **2. februar 2025:** Forbud mot uakseptabel risiko (Art. 5) gjelder - **2. august 2025:** GPAI-krav + governance/sanksjoner (Art. 99) - **2. desember 2027:** Høyrisiko-krav (Art. 6–49), inkl. samsvarsvurdering og CE-merking — *utsatt fra 2. aug 2026 via Digital Omnibus (provisorisk, avventer OJ)* - **2. august 2028:** Høyrisiko innebygd i regulerte produkter (Annex I) EØS-innlemmelse forventes å skje med noe forsinkelse (typisk 1–2 år). Norske virksomheter som leverer tjenester i EU/EØS, må likevel etterleve EU AI Act fra ikrafttredelsesdatoene for å operere i EU-markedet. **Anbefaling:** Forbered samsvarsvurdering i god tid før fristen (2. des 2027; Digital Omnibus vedtatt, avventer OJ-publisering). Selv om Omnibus gir mer tid, anbefales tidlig forberedelse. --- ## For Cosmo Bruk dette dokumentet når: 1. **Kunden spør "hva kreves for CE-merking?"** — Gå gjennom Annex IV-elementene og identifiser gap mot kundens nåværende dokumentasjonspraksis. 2. **Kunden er usikker på intern vs. ekstern vurdering** — Bruk beslutningstreet. For de aller fleste norske offentlige systemer er intern prosedyre tilstrekkelig. 3. **Kunden trenger konkrete maler** — Bruk EU-samsvarserklærings-malen direkte. Fyll ut med kundens data. 4. **Kunden vil planlegge compliance-arbeidet** — Bruk prosess-tidslinjen. 3–9 måneder for intern vurdering er realistisk for et gjennomsnittlig system. 5. **Kunden spør om norsk tilsynsmyndighet** — Nkom er utpekt som koordinerende markedstilsynsmyndighet og nasjonalt kontaktpunkt for KI-forordningen; råd om å holde dialog med Nkom, Datatilsynet og Digdir. Vær konkret: pek på hvilke Annex IV-elementer som typisk mangler, og hjelp kunden med å prioritere arbeidet fra størst til minst risiko.