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>
16 KiB
EU AI Act — Transparensnotiser og Informasjonsplikter
Last updated: 2026-07-15 Status: GA Category: Responsible AI & Governance Type: regulatory
Innhold
- Oversikt
- Art. 13: Bruksinstruksjoner for høyrisiko-systemer
- Art. 50(1): Informasjonsplikt ved AI-interaksjon
- Art. 50(2): AI-generert innhold
- Art. 50(4): Deepfakes og syntetisk innhold
- Norske maler
- Oppdateringstriggers
- For arkitekten
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:
-
Kunden spør "hva skal stå på forsiden av AI-chatboten vår?" — Bruk Mal 1 direkte og tilpass til kundens organisasjon og system.
-
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.
-
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.
-
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.
-
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.