ms-ai-architect/skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md
Kjell Tore Guttormsen 544934dc57
refactor(examples): replace sector-specific example material with generic, fictitious examples
Reference files, test fixtures, the playground demo project and one design
document now use generic, fictitious examples (buildings, energy, water,
grants, municipal services). The playground demo (17 fixtures plus the
embedded demo state) tells one consistent story: a municipal customer
chatbot that pre-screens housing-benefit applications, classified under
Annex III point 5(a). The embedded demo copies were edited in place rather
than regenerated, because they already carry newer AI Act dates than the
fixture files.

Legal text is unchanged. Test semantics are unchanged. Four dark-theme
onboarding screenshots with outdated placeholder text are removed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-23 14:03:53 +02:00

16 KiB
Raw Blame History

EU AI Act — Transparensnotiser og Informasjonsplikter

Last updated: 2026-07-15 Status: GA Category: Responsible AI & Governance Type: regulatory


Innhold

Oversikt

EU AI Act stiller krav om transparens på to nivåer: detaljerte bruksinstruksjoner for høyrisiko-systemer (Art. 13), og kortfattede transparensnotiser ved direkte brukerinteraksjon (Art. 50). Norske offentlige virksomheter må oppfylle begge — og i tillegg forvaltningsloven § 11 om veiledningsplikt og § 25 om begrunnelsesplikt. Dette dokumentet gir operative maler og retningslinjer tilpasset norsk kontekst.


Art. 13: Bruksinstruksjoner for høyrisiko-systemer

Påkrevd informasjon (Art. 13(3)) — 11 punkter

Art. 13(3) spesifiserer hva bruksinstruksjoner for høyrisiko-AI-systemer skal inneholde:

Nr. Punkt Hva som kreves Eksempel
a Identitet og kontaktinformasjon Tilbyderens navn, adresse og kontaktpunkt for henvendelser om systemet "Levert av Direktoratet for digital tjenesteutvikling, avdeling for tilskuddsforvaltning. Kontakt: ai-support@ddt.example"
b Systemets egenskaper og ytelse Nøyaktighetsmetrikker, kjente begrensninger, sannsynlige feilmønstre "Systemet har 94% presisjon på standardsaker. Sjeldne søknadstyper håndteres dårligere."
c Tiltenkt formål Spesifikk brukskontekst systemet er designet og validert for "Beslutningsstøtte for saksbehandlere ved søknader om tilskudd etter tilskuddsordningens forskrift §X"
d Systemnivå av nøyaktighet Kvantitative mål, konfidensintervaller, ytelse på ulike undergrupper "F1-score: 0,915 på valideringsett (500 historiske saker, 2023–2024)"
e Forventede brukere Hvem systemet er designet for (kompetanse, rolle, opplæringskrav) "Autoriserte saksbehandlere med gjennomført e-læring (DDT-AI-L01, 2 timer)"
f Forhåndsbehandlet inndata Spesifikasjoner for inndata systemet forventer "Søknadsskjema PDF. Bilder: maks 10 MB, JPEG/PNG. Ikke støttet: håndskrevne dokumenter"
g Mål og begrensninger Hva systemet er designet for å oppnå og kjente begrensninger "Genererer vedtaksutkast — erstatter ikke juridisk vurdering. Bør ikke brukes alene for saker med > 500 000 NOK konsekvens"
h Kjente og forutsigbare bivirkninger Risikosituasjoner som kan oppstå ved tiltenkt bruk "Kan overrepresentere avslag for søkere fra bestemte regioner (bias-kartlagt, se vedlegg B)"
i Human-in-the-loop Grad av menneskelig tilsyn som kreves og beskrivelse av mekanismer "Saksbehandler må aktivt godkjenne hvert vedtaksutkast. Systemet kan ikke sende vedtak automatisk."
j Forventede levetid og vedlikehold Planlagt levetid, oppdateringsfrekvens, prosedyre for å melde feil "Levetid: 3 år (2026–2029). Kvartalsvis modellgjennomgang. Feilmelding: ai-incident@ddt.example"
k Datakvalitetskrav Egenskaper ved inndata som påvirker ytelsen "Søknadsdokumenter må være maskinlesbare PDF-er. Skannet tekst (OCR-konvertert) reduserer nøyaktighet med ca. 8%"

Mal for bruksinstruksjon-dokument

Nedenfor er et strukturert mal-dokument som dekker alle 11 Art. 13(3)-punkter:


BRUKSINSTRUKSJON FOR [SYSTEMNAVN] Høyrisiko AI-system — Annex III, punkt [X] Versjon [X.X] | Dato: [ÅÅÅÅ-MM-DD]

1. Om systemet og tilbyder (Art. 13(3)(a)) [Systemnavn] er levert av [Organisasjon], [Adresse]. Kontakt for spørsmål: [e-post] | [telefon] Teknisk support: [e-post] | [saksbehandlingstid]

2. Hva systemet gjør og dets ytelse (Art. 13(3)(b) og (d)) [Systemnavn] [beskrivelse av funksjon]. Systemet er validert på [datagrunnlag] med følgende resultater:

  • Presisjon: [X]%
  • Recall: [X]%
  • F1-score: [X]
  • Ytelse på undergrupper: [beskrivelse av eventuelle forskjeller]

3. Tiltenkt formål og brukskontekst (Art. 13(3)(c)) Systemet er designet for: [konkret brukskontekst] Systemet er IKKE designet for: [liste over utenfor-scope-bruk]

4. Hvem kan bruke systemet (Art. 13(3)(e)) Systemet er forbeholdt: [rolle/kompetansekrav] Påkrevd opplæring: [navn på opplæring, varighet, leverandør]

5. Krav til inndata (Art. 13(3)(f) og (k)) Støttede formater: [liste] Krav til kvalitet: [beskrivelse] Inndata som ikke støttes: [liste]

6. Mål og begrensninger (Art. 13(3)(g)) Systemet er designet for å: [mål] Kjente begrensninger:

  • [Begrensning 1]
  • [Begrensning 2]

7. Kjente bivirkninger og risikoer (Art. 13(3)(h)) [Beskrivelse av kjente bias, feilmønstre og risikoer] Tiltak: [beskrivelse av risikoreduserende tiltak]

8. Menneskelig tilsyn (Art. 13(3)(i)) Påkrevd human oversight: [beskrivelse] Teknisk mekanisme: [beskrivelse av HITL-implementering] Brukeren kan ALLTID: [liste over rettigheter — avvise, redigere, eskalere]

9. Levetid og vedlikehold (Art. 13(3)(j)) Planlagt levetid: [periode] Oppdateringsfrekvens: [frekvens] Slik melder du feil: [prosedyre, kontaktinformasjon] Prosedyre ved vesentlig endring: [beskrivelse]


Tilgjengelighetskrav

Bruksinstruksjoner skal:

  • Være tilgjengelig digitalt (ikke bare i papirformat)
  • Skrives på et klart og forståelig språk (klarspråk)
  • Være oppdatert ved enhver vesentlig systemendring
  • For systemer brukt av offentligheten: tilgjengelig på norsk bokmål (og nynorsk ved behov)
  • Følge universell utforming (WCAG 2.1 AA) der systemet er tilgjengelig for borgere

Art. 50(1): Informasjonsplikt ved AI-interaksjon

Art. 50(1) krever at personer som interagerer direkte med et AI-system skal informeres om at de kommuniserer med kunstig intelligens, med mindre dette er åpenbart fra konteksten.

Krav

  • Informasjonen skal gis før eller ved starten av interaksjonen
  • Informasjonen skal være klar og tydelig
  • Informasjonen skal vedvare — ikke bare vises én gang og forsvinne

Unntak

  • Åpenbart for brukeren: Hvis konteksten gjør det klart at brukeren kommuniserer med AI (f.eks. en tydelig "AI Chatbot"-banner i et klart merket chat-vindu)
  • Rettshåndhevelse: Systemer brukt av politiet kan unntas hvis notis vil kompromittere etterforskning
  • Nasjonal sikkerhet: Unntak for sikkerhetstjenester

Norsk mal: Standard AI-interaksjon-notis

Kort versjon (for chat-grensesnitt, anbefalt):

"Du kommuniserer med et AI-system. [Systemnavn] er en kunstig intelligens-tjeneste fra [Organisasjon]. AI-tjenesten kan gjøre feil — vennligst verifiser viktig informasjon."

Utvidet versjon (for skjemaer, vedtakssystemer):

"Dette systemet bruker kunstig intelligens til å [kort beskrivelse av funksjon]. AI-systemet er levert av [Organisasjon] og er et hjelpemiddel for [rolle]. Endelig avgjørelse treffes alltid av [rolle/menneske]. Du har rett til å be om menneskelig behandling av din sak."

Plassering:

  • Synlig for bruker uten å måtte scrolle (above the fold)
  • Ikke skjult bak lenke eller i fotnote
  • Kontrastforhold ≥ 4,5:1 (WCAG 2.1 AA)

Art. 50(2): AI-generert innhold

Art. 50(2) krever at AI-generert tekst, bilde, lyd og video som ikke er åpenbart syntetisk, merkes som AI-generert.

Krav til merking

  • Merket på en maskinlesbar måte (metadata)
  • Merket på en synlig måte for sluttbrukere
  • Gjelder for: tekst, bilder, lyd, video, syntetiske multimodale kombinasjoner
  • Unntak: innhold som er åpenbart kunstig (animasjon, klar karikatyr)

Teknisk implementering for Microsoft-plattformen

Azure AI Content Safety — Watermarking:

  • Støtter digitalt vannmerke for bilder generert med Azure OpenAI DALL-E
  • C2PA (Coalition for Content Provenance and Authenticity) metadata-standard
  • Konfigurerbart via Microsoft Foundry

Tekstmerking:

  • Ikke automatisk støttet per 2026-02 for ren tekst
  • Implementér via systemprompt: be modellen inkludere merkingsinstruksjoner, eller legg til merking i output-lag

Anbefalt norsk merkingstekst for AI-generert innhold:

"Dette innholdet er generert av kunstig intelligens ([Systemnavn], [Organisasjon], [Dato])."


Art. 50(4): Deepfakes og syntetisk innhold

Art. 50(4) krever merking av syntetiske bilde-, lyd- og videoopptak av virkelige personer (deepfakes), med unntak for satire og kunstverk som er tydelig merket som fiksjon.

Relevans for offentlig sektor

  • Syntetisk tale (text-to-speech) basert på virkelige stemmer: merkeplikt
  • AI-genererte ansikter av virkelige personer i informasjonsmateriell: merkeplikt
  • Anonymiserte videoopptak der ansikter er syntetisk erstattet: vurder merkeplikt
  • Rene tekst-avatar-chatboter uten foto: ikke deepfake, ikke merkeplikt etter Art. 50(4) (men Art. 50(1) gjelder)

Norske maler

Mal 1: Borgermøtende chatbot-notis

Kontekst: Offentlig chatbot på nav.no, skatteetaten.no o.l.

Anbefalt plassering: Øverst i chat-vinduet, alltid synlig

┌─────────────────────────────────────────────────────────────────┐
│ ℹ️  Du snakker med en AI-assistent                              │
│ [Assistentnavn] er en kunstig intelligens fra [Etat].           │
│ Assistenten kan gjøre feil. For bindende svar, kontakt oss:     │
│ [telefonnummer] | [e-post]                                      │
└─────────────────────────────────────────────────────────────────┘

Alternativ kortversjon (inline):

"Hei! Jeg er [Navn], en AI-assistent fra [Etat]. Jeg kan gjøre feil — ta kontakt med oss direkte for bindende svar."


Mal 2: Vedtaksstøtte-notis (for saksbehandler)

Kontekst: Intern saksbehandlerflate der AI hjelper med vedtaksutkast

Plassering: Øverst på siden, alltid synlig; gjentatt som synlig merking på AI-generert utkast

┌─────────────────────────────────────────────────────────────────┐
│ AI-ASSISTERT SAKSBEHANDLING                                     │
│ Innholdet nedenfor er generert av [Systemnavn] (AI-system).     │
│ Du er ansvarlig for å vurdere, korrigere og godkjenne utkastet. │
│ Vedtaket sendes ikke automatisk.                                │
└─────────────────────────────────────────────────────────────────┘

Merking av selve AI-utkastet:

"--- AI-UTKAST ([Systemnavn], [Dato] [Klokkeslett]) --- Gjennomgå og godkjenn før sending."


Mal 3: AI-generert innhold-notis (for publikasjon)

Kontekst: Artikler, rapporter, informasjonsmateriell der AI har vært benyttet i produksjonen

Plassering: Tydelig synlig, f.eks. i fotnote eller som innledende merknad

Denne teksten er utarbeidet med støtte fra kunstig intelligens
([Verktøynavn]). Innholdet er gjennomgått og godkjent av [Navn/
rolle] i [Organisasjon], [Dato]. [Organisasjon] er ansvarlig for
innholdet.

Mal 4: Intern bruk-notis

Kontekst: AI-verktøy som kun brukes internt av ansatte, ikke av borgere

Plassering: Onboarding-materiale, systemets velkomstside, periodisk påminnelse

INTERN AI-BRUK — VIKTIG INFORMASJON

Du benytter et AI-verktøy ([Systemnavn]) i ditt arbeid. Husk:
• AI kan gjøre feil — bruk kritisk vurdering
• Ikke del personopplysninger eller sensitive data i AI-tjenester
  uten at dette er klarert av [IT-avdeling/personvernombud]
• Du er ansvarlig for faglig innhold du produserer med AI-støtte
• Spørsmål: [kontaktpunkt for AI-bruk i organisasjonen]

Behandlingsgrunnlag for AI-bruk: [Referanse til intern policy]

Oppdateringstriggers

Transparensnotiser og bruksinstruksjoner skal oppdateres ved følgende hendelser. Sett opp en intern prosedyre for å sikre at notisene holdes à jour.

Trigger 1: Modellbytte

Hva som utløser: Bytte av underliggende AI-modell (ny modell-ID, ny leverandør)

Hva som må oppdateres:

  • Bruksinstruksjon: nøyaktighetsmetrikker (element 2 og 4), komponentbeskrivelse (element 2)
  • Transparensnotis: dersom systemnavn eller leverandørangivelse endres
  • EU-samsvarserklæring: ny versjon kreves ved vesentlig modellbytte
  • Teknisk dokumentasjon: modell-ID, treningsdata (hvis ny modell har annen treningshistorikk)

Frist: Oppdatert notis skal være på plass før ny modell tas i produksjon


Trigger 2: Vesentlig funksjonsendring

Hva som utløser: Systemet kan nå gjøre noe det ikke kunne før, eller et eksisterende trekk er fjernet eller vesentlig endret

Eksempler:

  • Ny input-modalitet (f.eks. systemet kan nå behandle bilder i tillegg til tekst)
  • Ny output-type (f.eks. systemet kan nå generere PDF-utkast, ikke bare tekst)
  • Endret human-in-the-loop-struktur (f.eks. godkjenningstrinn fjernet eller lagt til)

Hva som må oppdateres:

  • Bruksinstruksjon: berørte Art. 13(3)-punkter
  • Transparensnotis: hvis funksjonsbeskrivelsen endres
  • Samsvarsvurdering: revurderes om endringen er "vesentlig" (Art. 43(4))

Trigger 3: Endret formål

Hva som utløser: Systemet brukes til noe annet enn det opprinnelig var tiltenkt

Eksempler:

  • Systemet som opprinnelig støttet interne saksbehandlere, gjøres tilgjengelig for borgere
  • Systemet brukes i ny sakstype som ikke er validert

Hva som må oppdateres:

  • Full ny samsvarsvurdering (endret formål kan endre Annex III-klassifisering)
  • Ny bruksinstruksjon tilpasset ny brukergruppe
  • Ny transparensnotis
  • Ny Art. 13-vurdering for ny brukergruppe

OBS: Endret formål kan kreve ny personvernvurdering (DPIA) etter GDPR Art. 35.


Trigger 4: Ny datakilde

Hva som utløser: Systemet får tilgang til nye data (ny database, ny indeks, ny API)

Eksempler:

  • RAG-indeksen utvides med en ny kategori dokumenter
  • Systemet kobles mot et nytt fagsystem
  • Ny treningsdata-runde gjennomføres

Hva som må oppdateres:

  • Bruksinstruksjon: inndata-beskrivelse (Art. 13(3)(f)), datakvalitetskrav (Art. 13(3)(k))
  • Teknisk dokumentasjon: element 2 (systemkomponenter)
  • DPIA: revurderes om ny datakilde introduserer nye personopplysninger

Trigger 5: Ytelsesfall

Hva som utløser: Monitorering viser at systemets nøyaktighet har falt vesentlig (typisk > 5 prosentpoeng)

Hva som må oppdateres:

  • Bruksinstruksjon: oppdaterte nøyaktighetsmetrikker
  • Transparensnotis: kan det være nødvendig å styrke advarselen?
  • Vurder om systemet skal settes i nedetid inntil årsak er identifisert

For arkitekten

Bruk dette dokumentet når:

  1. Kunden spør "hva skal stå på forsiden av AI-chatboten vår?" — Bruk Mal 1 direkte og tilpass til kundens organisasjon og system.

  2. Kunden utvikler et vedtaksstøttesystem — Bruk Mal 2 og forklar kravet om tydelig merking av AI-utkast, samt Art. 13(3)(i) om human-in-the-loop.

  3. Kunden spør om Art. 13-bruksinstruksjon — Gå gjennom alle 11 punkter, bruk tabellen, og hjelp kunden med å identifisere gap mot nåværende dokumentasjon.

  4. Kunden er usikker på oppdateringstriggers — Bruk trigger-seksjonen og anbefal at kunden etablerer en intern prosedyre (f.eks. change management-sjekkliste) der oppdatering av transparensnotiser er et fast trinn ved systemendringer.

  5. Kunden publiserer AI-generert innhold — Anbefal Mal 3 og forklar Art. 50(2)-kravet om maskinlesbar merking. Påpek at C2PA-standarden er fremvoksende beste praksis.

Husk: Forvaltningsloven stiller tilleggskrav som går lenger enn EU AI Act — f.eks. begrunnelsesplikt (§ 25) og innsynsrett (§ 18). Transparensnotisene er en nødvendig start, men ikke tilstrekkelig for full forvaltningsrettslig etterlevelse.