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

357 lines
15 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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