Same bulk replacement applied to plugin-internal KB, examples, fixtures, tests, and docs. Real organization names, persona names, internal system identifiers, and domain-specific terms replaced with fictional generic public-sector entity (DDT) and generic terminology. Scope: - okr/ — examples, governance, framework, integrations, sources - ms-ai-architect/ — KB references (engineering, governance, security, infrastructure, advisor), tests/fixtures, agents, docs - linkedin-thought-leadership/ — voice samples, network-builder, examples (genericized identifying headlines to "[your organization]") - llm-security/ — research notes, scan report Manual genericization beyond bulk replace: - okr SKILL.md "Primary user / Domain" — generic Norwegian public sector - linkedin-voice SKILL.md headline placeholder - network-builder.md headline placeholder - high-engagement-posts.md voice sample employer line + hashtag Phase 3 (factual-attribution review) remains: a few KB files attribute publicly known transport-sector docs/datasets (e.g. håndbok V440, NVDB) to the fictional DDT after bulk replace. Needs manual semantic review to either remove or restore correct citation without re-introducing affiliation references. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
15 KiB
EU AI Act — Samsvarsvurdering og EU-samsvarserklæring
Last updated: 2026-02 Status: GA Category: Responsible AI & Governance
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 Azure AI 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. 83)
- 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. 71) — obligatorisk fra 2. august 2026
- 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):
- Tilbyderen utarbeider teknisk dokumentasjon (Annex IV)
- Kvalitetsstyringssystem (Art. 17) er etablert og operativt
- Teknisk dokumentasjon gjennomgås og godkjennes internt
- EU-samsvarserklæring utarbeides og signeres
- CE-merking påføres
- Registrering i EU-database (Art. 71)
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):
- Velg akkreditert notified body (liste på NANDO-portalen)
- Lever teknisk dokumentasjon til notified body
- Notified body gjennomfører vurdering (typisk 3–6 måneder)
- Attestnummer utstedes
- Tilbyderen utsteder EU-samsvarserklæring med attestnummer
- 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. 71) | 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
Norge har ikke per 2026-02 utpekt én enkelt nasjonal tilsynsmyndighet (market surveillance authority) for EU AI Act, men EØS-tilpasningen er under arbeid. Forventet struktur:
- Datatilsynet: Primær tilsynsmyndighet for AI-systemer som behandler personopplysninger
- Sektortilsyn: Finanstilsynet (finansielle tjenester), Helsetilsynet (helse), Luftfartstilsynet (transport) for domene-spesifikke systemer
- Digdir: Koordineringsrolle for offentlig sektor
For offentlig sektor anbefales å avvente Datatilsynets veiledning og holde dialog med Digdir.
EØS-overgangsordninger
EU AI Act trer formelt i kraft i EU fra 2. august 2024 med stegvise ikrafttredelsesdatoer:
- 2. august 2025: Forbud mot uakseptabel risiko (Art. 5) gjelder
- 2. august 2026: Høyrisiko-krav (Art. 6–49), inkl. samsvarsvurdering og CE-merking
- 2. august 2027: Systemer som allerede er i drift (grandfathering-periode utløper)
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 nå, slik at CE-merking er klar til 2. august 2026.
For Cosmo
Bruk dette dokumentet når:
-
Kunden spør "hva kreves for CE-merking?" — Gå gjennom Annex IV-elementene og identifiser gap mot kundens nåværende dokumentasjonspraksis.
-
Kunden er usikker på intern vs. ekstern vurdering — Bruk beslutningstreet. For de aller fleste norske offentlige systemer er intern prosedyre tilstrekkelig.
-
Kunden trenger konkrete maler — Bruk EU-samsvarserklærings-malen direkte. Fyll ut med kundens data.
-
Kunden vil planlegge compliance-arbeidet — Bruk prosess-tidslinjen. 3–9 måneder for intern vurdering er realistisk for et gjennomsnittlig system.
-
Kunden spør om norsk tilsynsmyndighet — Forklar den uavklarte situasjonen og råd om å holde dialog med 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.