ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md

EU AI Act — Forpliktelser for Tilbydere (Providers)

Last updated: 2026-02 Status: GA Category: Responsible AI & Governance

---

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: Opptil 30 millioner EUR eller 6 % av global omsetning (Art. 99(3)).

---

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. 12(2) krever minst 6 måneder oppbevaring av logger. Lengre oppbevaring kan kreves av nasjonal lov (f.eks. forvaltningsloven for offentlig sektor i Norge: 3-10 år avhengig av sakstype).

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. 12)
Årlig:      Revisjon av risikostyringssystem (Art. 9)
Årlig:      QMS intern revisjon
Ved endring: Ny samsvarsvurdering dersom vesentlig endring (Art. 43(4))

---

For Cosmo

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: Nærings- og fiskeridepartementet koordinerer nasjonal implementering. Datatilsynet er sannsynlig tilsynsmyndighet for personverndimensjonen. Nasjonal AI-tilsynsmyndighet er under etablering (per 2026).