ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.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

16 KiB
Raw Blame History

EU AI Act — Transparensnotiser og Informasjonsplikter

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


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, Vegdirektoratet. Kontakt: ai-support@ddt.no"
b Systemets egenskaper og ytelse Nøyaktighetsmetrikker, kjente begrensninger, sannsynlige feilmønstre "Systemet har 94% presisjon på standardsaker. Sjeldne dispensasjonstyper håndteres dårligere."
c Tiltenkt formål Spesifikk brukskontekst systemet er designet og validert for "Beslutningsstøtte for saksbehandlere ved søknader om dispensasjon fra veitrafikkloven §X"
d Systemnivå av nøyaktighet Kvantitative mål, konfidensintervaller, ytelse på ulike undergrupper "F1-score: 0,915 på valideringsett (500 historiske saker, 20232024)"
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 (20262029). Kvartalsvis modellgjennomgang. Feilmelding: ai-incident@ddt.no"
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 Azure AI 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, ddt.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. 83)

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 Cosmo

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.