ms-ai-architect/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md

# EU AI Act — Forpliktelser for Tilbydere (Providers)
**Type:** regulatory
**Category:** Responsible AI & Governance

**Last updated:** 2026-07-15
**Status:** GA

---

## Innhold

- [Oversikt](#oversikt)
- [Art. 9: Risikostyringssystem](#art-9-risikostyringssystem)
- [Art. 10: Data Governance](#art-10-data-governance)
- [Art. 11: Teknisk Dokumentasjon](#art-11-teknisk-dokumentasjon)
- [Art. 12: Loggføring](#art-12-loggføring)
- [Art. 13: Transparens og bruksinformasjon](#art-13-transparens-og-bruksinformasjon)
- [Art. 14: Menneskelig tilsyn](#art-14-menneskelig-tilsyn)
- [Art. 15: Nøyaktighet, Robusthet og Cybersikkerhet](#art-15-nøyaktighet-robusthet-og-cybersikkerhet)
- [Art. 16-27: Kvalitetsstyringssystem (QMS)](#art-16-27-kvalitetsstyringssystem-qms)
- [Samsvarsvurdering-kalender](#samsvarsvurdering-kalender)
- [For arkitekten](#for-arkitekten)

## Oversikt

En provider er enhver juridisk eller fysisk person som utvikler et AI-system (eller får det utviklet) og markedsfører det under sitt navn eller varemerke, enten mot betaling eller gratis (Art. 3(3)). For høyrisiko-AI-systemer gjelder et omfattende sett med forpliktelser under Art. 9-27.

Bøter ved brudd (Art. 99): forbudte praksiser (Art. 5) opptil **€35 mill / 7 %** av global omsetning (Art. 99(3)); brudd på øvrige forpliktelser — inkludert provider-krav for høyrisiko (Art. 9–27) — opptil **€15 mill / 3 %** (Art. 99(4)); uriktig/villedende informasjon til myndigheter opptil **€7,5 mill / 1 %** (Art. 99(5)). For SMB-er/oppstartsselskap gjelder det laveste av beløp/prosent.

---

## Art. 9: Risikostyringssystem

### 4 kjernekomponenter

Risikostyringssystemet er en iterativ prosess gjennom hele AI-systemets livssyklus:

**Komponent 1: Identifikasjon av kjente og rimelig forutsigbare risikoer**
- Risikoidentifikasjon ved design, utvikling og faktisk bruk
- Inkludert misbruk og bruk utenfor tiltenkt formål
- Dokumenter per risikoidentifikasjonssyklus

**Komponent 2: Estimering og evaluering av risikoer**
- Kvantitativ og kvalitativ risikovurdering
- Vurder sannsynlighet og alvorlighetsgrad
- Særskilt hensyn til sårbare grupper (barn, eldre, funksjonshemmede)

**Komponent 3: Risikoreduserende tiltak**
- Tekniske tiltak (robusthetstesting, fail-safes, override-mekanismer)
- Organisatoriske tiltak (opplæring, prosedyrer, roller)
- Residualrisiko: Akseptabelt nivå dokumenteres

**Komponent 4: Informasjonsinnsamling fra post-market**
- Tilbakemeldingskanal fra deployers og sluttbrukere
- Automatisert logging fra systemer i drift (Art. 12)
- Periodisk revisjon av risikovurderingen

### Kontinuerlig oppdatering

Risikostyringssystemet skal oppdateres ved:
- Vesentlige endringer i systemet (Art. 9(2))
- Nye indikasjoner på risikoer fra post-market overvåking
- Endringer i regelverk eller standarder
- Hendelser og nestenulykker rapportert av deployers

### Sjekkliste — Art. 9 etterlevelse

- [ ] Formelt risikostyringssystem etablert og dokumentert
- [ ] Risikovurdering gjennomført for alle identifiserte bruksscenarioer
- [ ] Risikoreduserende tiltak implementert og verifisert
- [ ] Resiualrisiko akseptert og dokumentert med begrunnelse
- [ ] Procedure for oppdatering av risikovurdering ved endringer
- [ ] Ansvarsroller for risikostyring definert (risk owner)
- [ ] Integrasjon med post-market overvåking (Art. 72)
- [ ] Revisjonssyklus etablert (minst årlig for høyrisiko)

---

## Art. 10: Data Governance

### Treningsdata-krav

Høyrisiko-AI-systemer som bruker maskinlæring stiller krav til datasetthåndtering:

**Relevans og representativitet:**
- Treningsdata skal være relevante for tiltenkt formål
- Data skal dekke variasjoner i input-rom systemet forventes å møte
- Geografisk, demografisk og kontekstuell representativitet vurderes

**Bias-testing (Art. 10(2)(f)):**
- Identifiser mulige skjevheter i treningsdata
- Dokumenter bias-testingsmetodikk og resultater
- Gjennomfør disparate impact-analyse for beskyttede karakteristika
- Implementer bias-mitigering og verifiser effekt

**Datakvalitets-attributter (Art. 10(3)):**
- Nøyaktighet — data er korrekte og oppdaterte
- Fullstendighet — data dekker nødvendig omfang
- Konsistens — ingen motsigende informasjon
- Egnethet — data passer for tiltenkt formål

### Personvern og sikkerhet

- Treningsdata som inneholder personopplysninger: GDPR artikkel 5, 6, 9 gjelder
- Pseudonymisering eller anonymisering der mulig
- Oppbevaringsbegrensning: Ikke lenger enn nødvendig for treningsformålet
- Tilgangskontroll: Hvem kan se treningsdataene?

### Dokumentasjonskrav

- Data governance-policy dokumentert
- Kildeliste for treningsdata
- Bias-testingsrapport
- Data preprocessing-prosedyrer

---

## Art. 11: Teknisk Dokumentasjon

Teknisk dokumentasjon skal utarbeides **før** systemet settes på markedet og holdes oppdatert (Annex IV).

### 9 påkrevde elementer med eksempler

**Element 1: Generell systembeskrivelse**
Eksempel: "AutomatiskSaksbehandler v2.1 — AI-system for automatisk vurdering av helsekrav ved søknad om saksbehandling. Deployer: Direktoratet for digital tjenesteutvikling. Provider: [Leverandørnavn]. Tiltenkt formål: Behandling av ulike søknadskategorier."

**Element 2: Design-spesifikasjoner og utviklingsprosess**
- Systemarkitektur og komponentoversikt
- Teknologivalg og begrunnelse
- Treningsmetodikk og parametere
- Verifikasjons- og valideringsprosess

**Element 3: Overvåkings-, drifts- og kontrollsystem**
- Ytelsesmetrikker og terskelverdier
- Logging-arkitektur
- Alarmering og eskaleringsrutiner
- Override-mekanismer

**Element 4: Ytelsesstandarder og metrikker**
Eksempel: Nøyaktighet ≥ 97 % på validerte testcase, false positive rate < 2 %, false negative rate < 1 %, forklaring tilgjengelig for alle avslag.

**Element 5: Forklarlighetsmekanismer (XAI)**
- Hvilken forklaringsmetode brukes (SHAP, LIME, attention maps)?
- Forklaring tilgjengelig for deployer og sluttbruker?
- Begrensninger i forklarlighet dokumentert

**Element 6: Risikovurdering (Art. 9-referanse)**
Oppsummering av risikostyringssystemet med lenke til fullstendig risikovurderingsdokument.

**Element 7: Endringer i systemets levetid**
Endringslogg med beskrivelse av hva som er endret, av hvem, og ny validering gjennomført.

**Element 8: Samsvarsvurdering**
- Referanse til harmoniserte standarder anvendt (f.eks. ISO/IEC 42001)
- Samsvarsvurderingsrapport (intern eller tredjepart)
- CE-merkingsattest (der relevant)

**Element 9: Bruksanvisning for deployer (Art. 13)**
Fullstendig bruksanvisning inkludert betingelser, begrensninger, ytelse per undergruppe, menneskelig tilsyns-veiledning.

---

## Art. 12: Loggføring

### Automatisk logging

Høyrisiko-AI-systemer skal ha innebygd kapasitet for automatisk loggføring av hendelser gjennom systemets levetid.

**Påkrevde loggede hendelser:**
- Perioden systemet er i bruk (start/stopp)
- Referansedatabase brukt ved kontroll (der relevant)
- Input-data som medvirket til beslutning
- Identifikasjon av naturlige personer involvert i verifikasjon
- Resultater av verifikasjon
- Hendelser der operatøren overrider beslutning

### Oppbevaringsperiode

**6 måneder** — Art. 19(1) krever minst 6 måneder oppbevaring av logger. Lengre oppbevaring kan følge av norsk arkivlovgivning (arkivlova og bevaringsforskrifta) for offentlig sektor, der oppbevaringstiden fastsettes per dokumentasjonstype og kassasjon krever hjemmel eller tillatelse fra Nasjonalarkivet.

### Logg-arkitektur for Microsoft-plattformer

- **Azure AI Services:** Azure Monitor + Application Insights
- **Copilot Studio:** Conversation transcripts i Dataverse
- **Azure OpenAI:** Diagnostic Logging til Log Analytics Workspace
- **Power Automate:** Flow run history + audit log
- Alle logger eksporteres til Azure Log Analytics for sentralisert oppbevaring

---

## Art. 13: Transparens og bruksinformasjon

### Bruksinformasjon til deployer

Provider skal levere tydelig, fullstendig og forståelig bruksanvisning som minimum inneholder:

- Navn og kontaktinformasjon for provider
- Systemets egenskaper, kapabiliteter og tiltenkt formål
- Kjente risikoer ved tiltenkt bruk og rimelig forutsigbar feilbruk
- Ytelsesmetrikker inkludert nøyaktighets- og feilrater per undergruppe
- Input-data krav og betingelser for korrekt drift
- Endringer som krever ny samsvarsvurdering
- Human oversight-veiledning (Art. 14)
- Forventet levetid og vedlikeholdsintervaller

### Ytelsesgrenser — dokumentasjonskrav

Dokumenter eksplisitt:
- Ytelse på befolkningsgrupper utenfor treningsdata
- Ytelsesdegrasjon under distribusjonsskift (distribution shift)
- Kjente feilmodi og sannsynlighet
- Geografiske eller kontekstuelle begrensninger

---

## Art. 14: Menneskelig tilsyn

### Design for effektiv menneskelig kontroll

Høyrisiko-AI skal designes slik at menneskelig tilsyn er mulig og effektivt. Systemet skal:

**Forståelighet:**
- Gi forklaringer i menneskelig forståelig form
- Indikere konfidensgrad / usikkerhetsgrad
- Flagge tilfeller utenfor treningsdistribusjon

**Detekterbarhet:**
- Vise tydelig når systemet er i bruk
- Gjøre det enkelt å identifisere feil

**Override-mekanismer:**
- Teknisk mulighet for menneskelig override av alle beslutninger
- Override skal logges med begrunnelse
- Ingen systemdesign som motvirker eller vanskeliggjør override

**Eskaleringsmekanismer:**
- Definerte terskler for automatisk eskalering til menneskelig behandler
- Konfigurerbar flagging av lavkonfidens-saker
- Stoppknapp som umiddelbart suspenderer systemet

---

## Art. 15: Nøyaktighet, Robusthet og Cybersikkerhet

### Ytelsesmetrikker

Provider skal definere og opprettholde:
- Overordnet nøyaktighet på validert testdatasett
- Nøyaktighet per relevant undergruppe (alder, kjønn, geografi)
- Robusthet mot distribusjonsskift og adversarial input
- Tilgjengelighet og responstid

### Testing-regime

**Pre-deployment:**
- Validering på holdout-datasett (separat fra treningsdata)
- Adversarial robusthetstesting
- Red team-øvelse for høyrisiko-systemer
- Disparate impact-analyse

**Post-deployment:**
- Kontinuerlig ytelsesovervåking (concept drift detection)
- Periodisk re-validering (kvartalsvis eller ved vesentlige endringer)
- A/B-testing ved modelloppdateringer

### Sikkerhetsoppdateringer

- Definert policy for sikkerhetsoppdateringer (patch cadence)
- Kritiske sårbarheter: Maks 72 timers responstid
- Moderate sårbarheter: Maks 30 dager
- Kommunikasjonsplikt til deployers ved kritiske oppdateringer

---

## Art. 16-27: Kvalitetsstyringssystem (QMS)

### Komponenter

Et fullstendig QMS for høyrisiko-AI-provider inkluderer:

| Komponent | Beskrivelse |
|-----------|-------------|
| Policy og mål | AI-kvalitetspolicy, risikotoleranse, samsvarsmål |
| Organisasjon og ansvar | Roller, ansvar, fullmakter (inkl. AI Officer) |
| Kompetanse og opplæring | Opplæringsplan, kompetansekartlegging |
| Designkontroll | Krav, design, verifikasjon, validering |
| Endringshåndtering | Endringsprosedyre, impact assessment, re-samsvar |
| Leverandørkontroll | Krav til underleverandører, revisjon |
| Post-market overvåking | Plan, datainnsamling, analyse, rapportering |
| Hendelseshåndtering | Prosedyre, rapporteringsplikt (Art. 73), korreksjon |
| Intern revisjon | Revisjonsplan, funn, korrigerende tiltak |
| Ledelsesgjennomgang | Frekvens, agenda, beslutninger |

### Auditplan

- Intern revisjon: Minst én gang per år
- Tredjeparts revisjon: Obligatorisk for visse kategorier (Art. 43(1)) — typisk anneks VIII-systemer
- Scope: Alle Art. 9-27 krav
- Funn: Dokumentert med korrigerende tiltak og frist

### Korrigerende tiltak

Prosedyre for korrigerende tiltak skal dekke:
1. Identifikasjon av avvik
2. Rotårsaksanalyse
3. Tiltak og tidsplan
4. Effektivitetsverifisering
5. Dokumentasjon og lukking

---

## Samsvarsvurdering-kalender

Tidslinje for typisk høyrisiko-AI-system (start: utviklingsoppstart):

```
Måned 0:    Systemdesign — risikostyring (Art. 9) og data governance (Art. 10) starter
Måned 1-6:  Utvikling med innebygd samsvar (privacy by design, logging, forklarlighet)
Måned 7:    Teknisk dokumentasjon (Art. 11, Annex IV) — første utkast
Måned 8:    Intern samsvarsvurdering eller notifisert organ (avhengig av kategori)
Måned 9:    Samsvarserklæring (DoC) utstedt av provider (Art. 47)
Måned 9:    CE-merking påføres (Art. 48) — der relevant
Måned 9:    Registrering i EU AI Act-database (Art. 49) — offentlig tilgjengelig
Måned 10:   Lansering — deployer onboarding med bruksanvisning (Art. 13)
Løpende:    Post-market overvåking (Art. 72), hendelsesrapportering (Art. 73)
Løpende:    Logging 6-måneder minimum (Art. 19(1))
Årlig:      Revisjon av risikostyringssystem (Art. 9)
Årlig:      QMS intern revisjon
Ved endring: Ny samsvarsvurdering dersom vesentlig endring (Art. 43(4))
```

---

## For arkitekten

Bruk denne filen når brukeren er **provider** av et høyrisiko-AI-system, eller vurderer å bygge/tilpasse et AI-system som vil medføre provider-status.

**Typiske trigger-scenarioer:**
- Organisasjonen bygger et AI-system og planlegger å selge/distribuere det
- Intern IT-avdeling utvikler system på vegne av etaten (kan bli intern "provider")
- Leverandørvurdering: Hva kan du kreve av din AI-leverandør?

**Viktige avklaringsspørsmål til bruker:**
1. Er dere provider eller deployer? (se `ai-act-classification-methodology.md`)
2. Hvilken Annex III-kategori er systemet i?
3. Kreves tredjeparts samsvarsvurdering (Art. 43(1)) eller er intern tilstrekkelig?

**Kobling til andre KB-filer:**
- Klassifisering → `ai-act-classification-methodology.md`
- Deployer-perspektiv → `ai-act-deployer-obligations.md`
- FRIA → `ai-act-fria-template.md`
- ROS-analyse → `../norwegian-public-sector-governance/ros-*.md`

**Norsk kontekst:** Digitaliserings- og forvaltningsdepartementet (DFD) koordinerer nasjonal implementering (departementet som sendte KI-loven på høring). Datatilsynet er sannsynlig tilsynsmyndighet for personverndimensjonen. Nkom er utpekt som koordinerende markedstilsynsmyndighet og nasjonalt kontaktpunkt for KI-forordningen (formell forankring via KI-loven, ventet i kraft sensommer 2026).