ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md
Kjell Tore Guttormsen 9ea5a2e6c6 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

9.6 KiB

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.