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

EU AI Act — Forpliktelser for Tilbydere (Providers)

Type: regulatory Category: Responsible AI & Governance

Last updated: 2026-07-15 Status: GA

---

Innhold

• Oversikt
• Art. 9: Risikostyringssystem
• Art. 10: Data Governance
• Art. 11: Teknisk Dokumentasjon
• Art. 12: Loggføring
• Art. 13: Transparens og bruksinformasjon
• Art. 14: Menneskelig tilsyn
• Art. 15: Nøyaktighet, Robusthet og Cybersikkerhet
• Art. 16-27: Kvalitetsstyringssystem (QMS)
• Samsvarsvurdering-kalender
• For arkitekten

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 (Art. 99): forbudte praksiser (Art. 5) opptil €35 mill / 7 % av global omsetning (Art. 99(3)); brudd på øvrige forpliktelser — inkludert provider-krav for høyrisiko (Art. 9–27) — opptil €15 mill / 3 % (Art. 99(4)); uriktig/villedende informasjon til myndigheter opptil €7,5 mill / 1 % (Art. 99(5)). For SMB-er/oppstartsselskap gjelder det laveste av beløp/prosent.

---

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. 19(1) krever minst 6 måneder oppbevaring av logger. Lengre oppbevaring kan følge av norsk arkivlovgivning (arkivlova og bevaringsforskrifta) for offentlig sektor, der oppbevaringstiden fastsettes per dokumentasjonstype og kassasjon krever hjemmel eller tillatelse fra Nasjonalarkivet.

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

---

For arkitekten

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: Digitaliserings- og forvaltningsdepartementet (DFD) koordinerer nasjonal implementering (departementet som sendte KI-loven på høring). Datatilsynet er sannsynlig tilsynsmyndighet for personverndimensjonen. Nkom er utpekt som koordinerende markedstilsynsmyndighet og nasjonalt kontaktpunkt for KI-forordningen (formell forankring via KI-loven, ventet i kraft sensommer 2026).