ms-ai-architect/skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md
Kjell Tore Guttormsen 781d98f62f chore(privacy): scrub real-org references from plugin internals (phase 2)
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>
2026-05-03 04:28:15 +02:00

15 KiB
Raw Blame History

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. 4349) 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: [23 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. 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):

  1. Velg akkreditert notified body (liste på NANDO-portalen)
  2. Lever teknisk dokumentasjon til notified body
  3. Notified body gjennomfører vurdering (typisk 36 måneder)
  4. Attestnummer utstedes
  5. Tilbyderen utsteder EU-samsvarserklæring med attestnummer
  6. CE-merking med notified body-nummer

Kostnad: Typisk 50 000300 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) 12 uker
2. Gap-analyse Sammenlign nåværende praksis mot Art. 917-krav 24 uker
3. Risikostyring Etablér risikovurderingsprosess og -register (Art. 9) 48 uker
4. Data governance Dokumentér treningsdata og datakvalitetstiltak (Art. 10) 26 uker
5. Teknisk dokumentasjon Skriv Annex IV-dokumentasjonen (alle 9 elementer) 48 uker
6. QMS-tilpasning Tilpass kvalitetsstyringssystem til Art. 17-krav 24 uker
7. Intern review Uavhengig intern gjennomgang av teknisk dokumentasjon 23 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) 39 måneder
Totalt (ekstern) Legg til 36 måneder for notified body-prosess 615 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. 649), 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 12 å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:

  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. 39 måneder for intern vurdering er realistisk for et gjennomsnittlig system.

  5. 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.