ms-ai-architect/skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md
Kjell Tore Guttormsen baa2d0220b feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command
Add /ultraresearch-local for structured research combining local codebase
analysis with external knowledge via parallel agent swarms. Produces research
briefs with triangulation, confidence ratings, and source quality assessment.

New command: /ultraresearch-local with modes --quick, --local, --external, --fg.
New agents: research-orchestrator (opus), docs-researcher, community-researcher,
security-researcher, contrarian-researcher, gemini-bridge (all sonnet).
New template: research-brief-template.md.

Integration: --research flag in /ultraplan-local accepts pre-built research
briefs (up to 3), enriches the interview and exploration phases. Planning
orchestrator cross-references brief findings during synthesis.

Design principle: Context Engineering — right information to right agent at
right time. Research briefs are structured artifacts in the pipeline:
ultraresearch → brief → ultraplan --research → plan → ultraexecute.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-08 08:58:35 +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. 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 Statens vegvesen (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:

"Statens vegvesen følger ISO 9001:2015. AI-spesifikke tilleggsprosedyrer: SVV-AI-P01 (Anskaffelse av AI-systemer), SVV-AI-P02 (Samsvarsvurdering), SVV-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. SVV-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 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. 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:

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