# 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).