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

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

**Last updated:** 2026-06-18
**Status:** GA

---

## Oversikt

En deployer er enhver juridisk eller fysisk person som tar et AI-system i bruk under eget ansvar (Art. 3(4)). For høyrisiko-AI-systemer gjelder Art. 26 som et eget sett deployer-forpliktelser — adskilt fra provider-kravene.

Offentlige organer er i de fleste tilfeller deployers. Forordningen gir offentlig sektor **ekstra forpliktelser** utover det som gjelder private deployers, særlig FRIA-plikten (Art. 27).

Bøter ved brudd: Opptil **15 millioner EUR eller 3 % av global omsetning** (Art. 99(4)).

---

## Art. 26: Generelle forpliktelser

### Bruk i samsvar med bruksanvisning

Deployer skal:
- Bruke systemet kun innenfor tiltenkt formål og i samsvar med provider's bruksanvisning
- Ikke modifisere systemet på måter som kan kompromittere samsvar
- Implementere tekniske og organisatoriske tiltak angitt av provider

**Praktiske implikasjoner:**
- Oppbevare og gjøre bruksanvisningen tilgjengelig for operatørene
- Etablere intern prosedyre for å lese og forstå bruksanvisningen ved anskaffelse
- Sikre at bruk utenfor tiltenkt formål er teknisk vanskeliggjort (tilgangsstyring)

### Teknisk kompetansekrav

Operatørene som bruker høyrisiko-AI skal ha tilstrekkelig kompetanse til:
- Forstå systemets kapabiliteter og begrensninger
- Fortolke output korrekt — inkludert konfidensnivåer
- Gjenkjenne situasjoner der systemet kan feile
- Utføre og begrunne override av systemets beslutning

Deployer er ansvarlig for å sikre at opplæring gjennomføres. Opplæringsplan og gjennomføring dokumenteres.

### Monitoreringsplikt

Deployer skal aktivt overvåke systemets ytelse i faktisk bruk (Art. 26(1)(d)):
- Etabler baseline for forventet ytelse
- Identifiser avvik fra baseline
- Rapporter vesentlige avvik og hendelser til provider (Art. 26(1)(d))
- Rapporter alvorlige hendelser til tilsynsmyndighet (Art. 73(3))

---

## Art. 26(5): Offentlig sektor spesifikt

Offentlige organer som deployer av høyrisiko-AI-systemer har to særskilte forpliktelser:

### FRIA-plikt

Offentlige organer **skal alltid** gjennomføre Fundamental Rights Impact Assessment (FRIA) før de tar i bruk et høyrisiko-AI-system (Art. 27(1)).

Dette gjelder uansett om:
- Systemet er kjøpt fra en kommersiell provider
- Systemet er et standardprodukt (f.eks. Microsoft AI-tjeneste)
- Systemet er kun et beslutningsstøtteverktøy

Se `ai-act-fria-template.md` for fullstendig mal og fremgangsmåte.

### 6-måneders loggoppbevaring

Offentlige organer skal oppbevare logger i minst 6 måneder (Art. 26(6)). Nasjonal lovgivning kan kreve lengre oppbevaringstid:
- Forvaltningsloven: Saker som kan påklages → oppbevaring til klagefrist utløpt + eventuelle klagesaksbehandling
- Arkivloven: Offentlig saksbehandling → typisk 10 år
- **Anbefaling:** Bruk 10 år som standard for offentlig saksbehandling som berører enkeltpersoner

---

## Art. 27: FRIA (Fundamental Rights Impact Assessment)

### Når er FRIA påkrevd?

| Deployer-type | Krav |
|---------------|------|
| Offentlig organ (stat, fylke, kommune) | ALLTID for høyrisiko-AI (Art. 27(1)) |
| Privat aktør — kredittvurdering (Annex III pkt. 5(b)) | ALLTID |
| Privat aktør — livsforsikring og helseforsikring (Annex III pkt. 5(d)) | ALLTID |
| Privat aktør — andre Annex III-kategorier | Frivillig, men anbefalt |
| Bankvirksomhet for kredittvurdering | ALLTID |

### Innhold i FRIA

FRIA skal minimum inneholde:
1. Beskrivelse av deployers bruksprosess
2. Tidsperiode og geografisk område for bruken
3. Kategorier av berørte personer
4. Spesifikke risikoer for grunnleggende rettigheter
5. Tiltak for å håndtere risikoene

### Gjennomføring

- **Tidspunkt:** Før systemet tas i bruk (Art. 27(1))
- **Ansvarlig:** Deployer (ikke provider)
- **Involvering:** Personvernombud (DPO) bør involveres
- **Kobling til DPIA:** Der GDPR DPIA også kreves, kan de gjennomføres samlet
- **Notifikasjon:** Resultater sendes til tilsynsmyndighet (Art. 27(4))

Se fullstendig mal i `ai-act-fria-template.md`.

---

## Operasjonelle krav

### Logghåndtering

- **Minimum:** 6 måneder (Art. 26(6)) — for offentlig sektor typisk 10 år per arkivlov
- **Scope:** Alle avgjørelser systemet har bidratt til, inkludert override-hendelser
- **Format:** Maskinlesbart format som muliggjør revisjon og ettersyn
- **Tilgang:** Tilgjengelig for tilsynsmyndighet på forespørsel
- **Beskyttelse:** Loggen skal sikres mot manipulasjon og uautorisert sletting

**Azure-implementering:**
- Azure Log Analytics Workspace med retention policy satt til 3650 dager (10 år)
- Immutable storage for revisjonslogger (Write Once Read Many)
- RBAC-styrt tilgang: Kun revisor og tilsynsmyndighet kan eksportere

### Hendelsesrapportering til tilsynsmyndighet

**Hva skal rapporteres (Art. 73(3)):**
- Alvorlige hendelser — definert som hendelse som har ført til eller med rimelighet kan ha ført til:
  - Død eller alvorlig personskade
  - Alvorlig og uopprettelig skade på eiendom eller miljø
  - Alvorlig brudd på grunnleggende rettigheter

**Rapporteringsfrister:**
- Umiddelbart alvorlige hendelser: 15 dager (Art. 73(4))
- Alvorlig risiko uten konkret hendelse: Uten ugrunnet opphold

**Rapporteringskanal:** Nasjonal markedsovervåkingsmyndighet (i Norge: under etablering per 2026)

### Informasjonsplikt til berørte personer

For individuelle avgjørelser som involverer høyrisiko-AI (Art. 86):
- Informere om at AI-systemet er brukt
- Forklare relevante aspekter ved beslutningsprosessen
- Retten til menneskelig gjennomgang der relevant
- Innen rimelig tid etter forespørsel

**Kombinasjon med GDPR Art. 22:** Dersom beslutningen er fullt automatisert (ingen menneskelig involvering) gjelder GDPR Art. 22 — rett til menneskelig vurdering er da absolutt.

### Samarbeid med tilsynsmyndighet

Deployer plikter å:
- Gi tilsynsmyndighet tilgang til logger på forespørsel
- Bistå ved markedsovervåkingsundersøkelser
- Stille til møter og gi forklaringer
- Ikke hindre tilsynsmyndighetens arbeid

---

## Anskaffelses-due-diligence

Sjekkliste for innkjøp av AI-systemer — bruk ved anskaffelse av høyrisiko-AI:

**Leverandørdokumentasjon (13 punkter):**

- [ ] **1. CE-merking verifisering** — Bekreftet CE-merking for det aktuelle AI-systemet? (gjelder fra 2. des 2027, utsatt via Omnibus — provisorisk)
- [ ] **2. Samsvarserklæring (DoC)** — Provider har utstedt samsvarserklæring (Art. 47)?
- [ ] **3. Bruksanvisning kvalitet** — Bruksanvisning (Art. 13) dekker alle påkrevde elementer? (se provider-obligations.md)
- [ ] **4. Teknisk dokumentasjon** — Provider kan levere Annex IV-dokumentasjon på forespørsel?
- [ ] **5. Provider-kontaktinformasjon** — Tydelig kontaktpunkt for samsvarsspørsmål og hendelsesrapportering?
- [ ] **6. EU-databaseregistrering** — System registrert i EU AI Act-databasen (Art. 49)?
- [ ] **7. Risikovurdering** — Provider har risikovurdering (Art. 9) tilgjengelig for innsyn?
- [ ] **8. Bias-testing** — Provider kan dokumentere bias-testingsresultater?
- [ ] **9. Post-market overvåking** — Provider har etablert post-market plan og rapporterer til deployer?
- [ ] **10. Hendelseshistorikk** — Kjente alvorlige hendelser med systemet i andre deployments?
- [ ] **11. Oppdateringspolicy** — Provider's policy for sikkerhetsoppdateringer og funksjonelle oppdateringer?
- [ ] **12. Avslutningstjenester** — Hva skjer med logger og data ved avslutning av avtalen?
- [ ] **13. Kontrakt** — Avtalen regulerer deployer's rettigheter til å gjennomføre FRIA, logghåndtering og tilsynssamarbeid?

---

## Ansvarsfordeling provider/deployer

Matrise som viser fordeling av ansvar for 10 nøkkelområder:

| Ansvarsområde | Provider | Deployer | Delt |
|---------------|----------|----------|------|
| Risikostyringssystem (Art. 9) | Primær | Operasjonell | Ja |
| Data governance treningsdata (Art. 10) | Fullt ansvar | Ikke relevant | Nei |
| Teknisk dokumentasjon (Art. 11) | Utarbeider | Mottar og oppbevarer | Nei |
| Logging-kapasitet (Art. 12) | Design | Aktivering og oppbevaring | Ja |
| Bruksanvisning (Art. 13) | Leverer | Implementerer og distribuerer | Nei |
| Menneskelig tilsyns-design (Art. 14) | Design | Implementering og opplæring | Ja |
| Nøyaktighet og robusthet (Art. 15) | Primær | Monitorering i drift | Ja |
| FRIA (Art. 27) | Ikke direkte | Gjennomfører | Nei |
| Registrering EU-database (Art. 49) | Registrerer system | Registrerer bruk (offentlig sektor) | Ja |
| Hendelsesrapportering (Art. 73) | Alvorlige hendelser til marked | Alvorlige hendelser til tilsyn | Begge |

---

## For Cosmo

Bruk denne filen når brukeren er **deployer** av et høyrisiko-AI-system — typisk en offentlig etat, fylkeskommune eller kommune som kjøper og implementerer et AI-system.

**Typiske trigger-scenarioer:**
- "Vi vurderer å kjøpe [AI-produkt] — hva må vi gjøre?"
- "Vi har fått en klage på en AI-beslutning — hva er våre forpliktelser?"
- "Tilsynsmyndigheten ber om innsyn i logger — hva gjelder?"

**Viktige avklaringsspørsmål:**
1. Er systemet klassifisert som høyrisiko (Annex III)?
2. Er deployer et offentlig organ → FRIA obligatorisk
3. Er avgjørelsene fullt automatiserte → GDPR Art. 22 i tillegg

**Kobling til andre KB-filer:**
- Klassifisering → `ai-act-classification-methodology.md`
- FRIA gjennomføring → `ai-act-fria-template.md`
- Provider-krav for leverandørvurdering → `ai-act-provider-obligations.md`
- DPIA kobling → `../norwegian-public-sector-governance/`

**Norsk kontekst:** Direktoratet for digital tjenesteutvikling, Skatteetaten og kommuner er typisk deployers. Innkjøp gjennom Statens standardavtaler (SSA) — spesielt SSA-D (driftsavtale) bør suppleres med AI Act-spesifikke vedlegg fra 2026.