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>
220 lines
9.6 KiB
Markdown
220 lines
9.6 KiB
Markdown
# EU AI Act — Forpliktelser for Brukere (Deployers)
|
|
|
|
Last updated: 2026-02
|
|
Status: GA
|
|
Category: Responsible AI & Governance
|
|
|
|
---
|
|
|
|
## 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 august 2026)
|
|
- [ ] **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.
|