ms-ai-architect/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md
Kjell Tore Guttormsen ddbe4954e0 fix(ms-ai-architect): RX-REG-KB M13 artikkelnr. — 5 AI Act-siteringer rettet mot EUR-Lex [skip-docs]
Kryssmodell-review akse 3 (M13): governance-refene bar feil AI Act-artikkelnummer.
Hver rettet mot EUR-Lex CELEX:32024R1689 / AI Act Explorer (verifisert 2026-07-15):

- Art. 71 -> 49 (registreringsplikt; 71 = EU-databasen som entitet):
  conformity-assessment L177/271/320, ms-tools-mapping L234
- Art. 72 -> 73 (alvorlige hendelser = "Reporting of Serious Incidents";
  72 = post-market monitoring, beholdt der det faktisk betyr monitoring):
  ms-tools-mapping L52/247
- Art. 83 -> 3(23)/43(4) (vesentlig endring: def = 3(23), ny samsvarsvurdering = 43(4);
  83 = "Formal non-compliance"): conformity-assessment L126, transparency-notices L295
- Annex III 5(d) -> 5(c) (livs-/helseforsikring; 5(d) = noedanrop):
  fria-template L37, deployer-obligations L86
- Art. 12(2) -> 19(1) (6-mnd loggretensjon = "Automatically generated logs";
  12 = record-keeping-kapabilitet): provider-obligations L179/326

Last updated-bump 2026-02 -> 2026-07-15: ms-tools-mapping, transparency-notices.
TDD: lint section 7 (5 nye) failing foer fiks, groenn etter. Suite 830/830 exit 0.
Restanse (frist-klynge): conformity L177 "2. august 2026" staar igjen for M13-frister.

Kilder: artificialintelligenceact.eu/article/{3,19,43,49,71,72,73}/ + /annex/3/
2026-07-15 07:16:28 +02:00

221 lines
9.7 KiB
Markdown

# EU AI Act — Forpliktelser for Brukere (Deployers)
**Type:** regulatory
**Category:** Responsible AI & Governance
**Last updated:** 2026-07-15
**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(c)) | 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: Nkom, koordinerende markedstilsynsmyndighet)
### 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.