Kjell Tore Guttormsen
3a73eeafdc
Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:
1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
`Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
132 bokføres til R13b/R14.
Tre korreksjoner av premisser som sto i ordren og STATE:
«ca 320 produkt» -> 451 (case-sensitivt nett manglet 327 lowercase
TOC-ankre + 99 identifikatorer; sann nevner 1 638)
«169 headinger» -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
internt inkonsistent med sin egen topp-variant (204)
«417 matcher ingen
populasjon» -> 417 er cosmo-headinger utenfor kodefences; briefens
nevner var reell hele tiden
Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.
TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.
Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.
Verifisering (alle 7 kriterier fra ordren):
G1 persona på heading-linjer 401 -> 0
G2 døde fragmentlenker 1 -> 1 (pre-eksisterende, unntatt)
G3 produkt-forekomster 451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
de 3 kun-produkt-filene byte-identiske
nettet validert begge veier injisert persona feller G1; genitiv feller G1;
produkt-heading og de 3 filene passerer
hele diffen 802 heading-linjer + 654 TOC-linjer, ANNET = 0
linjeantall 728 lagt til = 728 slettet
suite 1120/1120 (1097 + 23 nye)
validate-plugin 250 PASS / 0 FAIL
stikkprøve 10 filer, alle 5 skills, inkl. de 3 mest
produkt-tunge (26/20/19) — kun heading+TOC
Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
12 KiB
FRIA-mal — Fundamental Rights Impact Assessment (Art. 27)
Type: template Category: Responsible AI & Governance
Last updated: 2026-07-15 Status: GA
Innhold
- Oversikt og hjemmel
- Når må FRIA gjennomføres?
- FRIA-mal — 7 seksjoner
- Eksempel: FRIA for AutomatiskSaksbehandler (Direktoratet for digital tjenesteutvikling)
- For arkitekten
Oversikt og hjemmel
Fundamental Rights Impact Assessment (FRIA) er påkrevd etter EU AI Act Art. 27 for:
- Offentlige organer som deployer av høyrisiko-AI-systemer (alltid)
- Private aktører som deployer i kredittvurdering og forsikring (alltid)
- Andre deployers av Annex III-systemer (anbefalt)
FRIA er en selvstendig vurdering fra deployer — ikke det samme som provider's samsvarsvurdering (Art. 43). FRIA kan gjennomføres samlet med GDPR DPIA der begge er påkrevd.
Notifikasjon: Resultater fra FRIA skal sendes til tilsynsmyndigheten (Art. 27(4)).
Når må FRIA gjennomføres?
Obligatorisk
- Offentlige organer som deployer av høyrisiko-AI = ALLTID (Art. 27(1)) — dette inkluderer statlige etater, fylkeskommuner, kommuner og offentlige foretak
- Bankvirksomhet for kredittvurdering = ALLTID (Annex III pkt. 5(b))
- Livsforsikring og helseforsikring = ALLTID (Annex III pkt. 5(c))
- Private deployers som oppfyller Art. 27-kriteriene — bl.a. stor skala behandling av personopplysninger
Frivillig men sterkt anbefalt
- Private deployers av andre Annex III-kategorier
- Deployers som ønsker å dokumentere ansvarlig AI-praksis
- Deployers som eksponerer systemet mot sårbare grupper
Tidspunkt
FRIA gjennomføres før systemet tas i bruk. Ved vesentlige endringer i bruken, systemet eller konteksten skal FRIA oppdateres.
FRIA-mal — 7 seksjoner
Seksjon 1: Systembeskrivelse
| Felt | Innhold |
|---|---|
| Systemnavn | [Offisielt navn på AI-systemet] |
| Versjon | [Versjonsnummer] |
| Tiltenkt formål (deployer) | [Beskriv hvordan deployer bruker systemet — ikke bare provider's tiltenkte formål] |
| Deployer | [Organisasjonsnavn, organisasjonsnummer] |
| Provider | [Leverandørnavn og kontaktinformasjon] |
| Risikoklassifisering | [Høyrisiko — Annex III, kategori X] |
| Klassifiseringsdato | [DD.MM.ÅÅÅÅ] |
| FRIA-versjon | [1.0, 1.1 osv.] |
| FRIA-dato | [DD.MM.ÅÅÅÅ] |
| Gyldig til | [DD.MM.ÅÅÅÅ — eller "løpende med årlig revisjon"] |
| Geografisk scope | [Norge / Nordland fylke / Oslo kommune osv.] |
| Tidsperiode | [Fra dato — til dato, eller "løpende"] |
| Beslutningstype | [Fullt automatisert / Beslutningsstøtte med menneskelig godkjenning] |
| Volum | [Estimert antall beslutninger per år] |
Prosessbeskrivelse: [Beskriv konkret hvordan AI-systemet brukes i saksbehandlingsprosessen. Hvem legger inn input? Hva er output? Hvem tar endelig beslutning? Hvilke alternativer til AI-systemet finnes?]
Seksjon 2: Berørte grupper
Identifiser alle grupper som direkte eller indirekte berøres av AI-systemets beslutninger.
| Gruppe | Antall berørte (estimat) | Sårbarhet | Kontaktpunkt / representasjon |
|---|---|---|---|
| [Gruppe 1 — f.eks. "Søkere om førerrett klasse B"] | [Antall/år] | Lav / Middels / Høy | [Interesseorganisasjon, brukerrepresentant] |
| [Gruppe 2 — f.eks. "Eldre søkere (over 70 år)"] | [Antall/år] | Høy | [Råd for eldre, brukerombud] |
| [Gruppe 3 — f.eks. "Søkere med funksjonsnedsettelse"] | [Antall/år] | Høy | [FFO, brukerombud] |
| [Gruppe 4 — f.eks. "Nyankomne innvandrere"] | [Antall/år] | Middels | [NOAS, integreringsorganisasjoner] |
| [Gruppe 5] |
Vurdering av sårbarhetsnivå:
- Lav: Ressurssterke, kan enkelt klage og alternative kanaler finnes
- Middels: Begrenset tilgang til ressurser, men ikke særlig sårbare
- Høy: Barn, eldre, funksjonshemmede, minoriteter, eller i akutt behov for tjenesten
Seksjon 3: Rettighetsmatrise
Vurder påvirkning på 12 grunnleggende rettigheter fra EU-charteret. Skala: Ingen / Lav / Middels / Høy / Kritisk.
| # | Grunnleggende rettighet (EU Charter) | Vurdering | Begrunnelse |
|---|---|---|---|
| 1 | Menneskelig verdighet (Art. 1) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
| 2 | Frihet og personlig sikkerhet (Art. 6) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
| 3 | Beskyttelse av personopplysninger (Art. 8) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
| 4 | Ikke-diskriminering (Art. 21) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
| 5 | Likestilling mellom kvinner og menn (Art. 23) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
| 6 | Forbrukerrettigheter (Art. 38) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
| 7 | Retten til rettferdig rettergang (Art. 47) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
| 8 | Barns rettigheter (Art. 24) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
| 9 | Funksjonshemmedes rettigheter og integrering (Art. 26) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
| 10 | Miljøvern og bærekraftig utvikling (Art. 37) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
| 11 | Rett til sosial sikkerhet og sosial støtte (Art. 34) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
| 12 | Tilgang til helsetjenester (Art. 35) | [Ingen/Lav/Middels/Høy/Kritisk] | [Kort begrunnelse] |
Vurderingsskala:
- Ingen: Systemet berører ikke denne rettigheten
- Lav: Marginal påvirkning, enkelt avhjulpet
- Middels: Merkbar påvirkning, krever tiltak
- Høy: Vesentlig påvirkning på en identifisert gruppe, krever sterke tiltak
- Kritisk: Potensielt brudd på rettigheten — vurder om systemet kan tas i bruk
Seksjon 4: Konsekvensanalyse
For hver rettighet med middels eller høyere vurdering i seksjon 3, gjennomfør utvidet analyse:
Rettighet [X]: [Navn på rettighet]
Vurdering: [Middels / Høy / Kritisk]
Berørte grupper: [Fra seksjon 2]
Beskrivelse av risiko: [Beskriv konkret hvordan AI-systemet kan påvirke denne rettigheten. Gi eksempler på scenarioer der rettigheten kan krenkes. Vurder både direkte og indirekte påvirkning.]
Sannsynlighet for negativ påvirkning: [Lav / Middels / Høy]
Eksisterende mitigeringstiltak: [Beskriv tiltak som allerede er implementert av provider eller deployer for å redusere risikoen.]
Ytterligere tiltak (deployer implementerer):
| Tiltak | Ansvarlig | Frist | Status |
|---|---|---|---|
| [Tiltak 1] | [Navn/rolle] | [DD.MM.ÅÅÅÅ] | [Planlagt/Implementert] |
| [Tiltak 2] | [Navn/rolle] | [DD.MM.ÅÅÅÅ] | [Planlagt/Implementert] |
Restrisiko etter tiltak: [Lav / Middels / Høy]
Akseptert av: [Navn, rolle, dato]
[Gjenta for hver rettighet med middels+ vurdering]
Seksjon 5: Tilsynsmyndighets-notifikasjon
I henhold til Art. 27(4) skal resultater fra FRIA sendes til nasjonal tilsynsmyndighet.
| Felt | Innhold |
|---|---|
| Tilsynsmyndighet | [Nkom — koordinerende markedstilsynsmyndighet og nasjonalt kontaktpunkt for KI-forordningen; Datatilsynet for personverndimensjonen] |
| Notifikasjonsform | [Elektronisk innlevering / Brev / Tilgjengeliggjøring på nettsted] |
| Notifikasjonsdato | [DD.MM.ÅÅÅÅ] |
| Referansenummer | [Tilsynsmyndighetens saksnummer der tilgjengelig] |
| Offentliggjøring | [Ja / Nei — FRIA-sammendrag tilgjengelig offentlig?] |
Merk: Det norske regelverket for notifikasjonsprosedyre er under utvikling (per februar 2026). Deployer bør følge Datatilsynets veiledning og fremtidig AI-tilsynsmyndighets instrukser.
Seksjon 6: Godkjenning
Alle tre roller skal godkjenne FRIA før systemet tas i bruk.
| Rolle | Navn | Tittel | Dato | Signatur |
|---|---|---|---|---|
| Systemansvarlig | [Navn] | [Tittel] | [DD.MM.ÅÅÅÅ] | ____________ |
| Personvernombud (DPO) | [Navn] | Personvernombud | [DD.MM.ÅÅÅÅ] | ____________ |
| Leder / Direktør | [Navn] | [Tittel] | [DD.MM.ÅÅÅÅ] | ____________ |
Neste revisjonsdato: [DD.MM.ÅÅÅÅ] — Anbefalt: Minst én gang per år, eller ved vesentlige endringer i systemet, bruken eller regelverket.
Revisjonsoversikt:
| Versjon | Dato | Endring | Godkjent av |
|---|---|---|---|
| 1.0 | [DD.MM.ÅÅÅÅ] | Initiell FRIA | [Navn] |
| 1.1 | [DD.MM.ÅÅÅÅ] | [Beskrivelse av endring] | [Navn] |
Seksjon 7: Vedlegg
Lenker til relaterte dokumenter som bør arkiveres sammen med FRIA:
| Dokument | Referanse / Lenke | Versjon | Dato |
|---|---|---|---|
| Samsvarserklæring (DoC) fra provider | [Dokumentreferanse] | [Versjon] | [Dato] |
| DPIA / PVK | [Dokumentreferanse] | [Versjon] | [Dato] |
| ROS-analyse | [Dokumentreferanse] | [Versjon] | [Dato] |
| Klassifiseringsrapport (Annex III) | [Dokumentreferanse] | [Versjon] | [Dato] |
| Provider's tekniske dokumentasjon (Annex IV) | [Dokumentreferanse / lenke] | [Versjon] | [Dato] |
| Bruksanvisning fra provider (Art. 13) | [Dokumentreferanse] | [Versjon] | [Dato] |
| Opplæringsplan for operatører | [Dokumentreferanse] | [Versjon] | [Dato] |
| Log retention policy | [Dokumentreferanse] | [Versjon] | [Dato] |
Eksempel: FRIA for AutomatiskSaksbehandler (Direktoratet for digital tjenesteutvikling)
Illustrativt eksempel for å vise utfylt mal:
Seksjon 1 (utdrag):
- Systemnavn: AutomatiskSaksbehandler v2.0
- Provider: [Leverandørnavn]
- Klassifisering: Høyrisiko — Annex III, kategori 5 (viktige offentlige tjenester)
- Beslutningstype: Beslutningsstøtte — AI anbefaler, saksbehandler godkjenner
- Volum: Ca. 150 000 søknader/år
Seksjon 3 (utdrag — høyeste risikoer):
- Ikke-diskriminering (Art. 21): Høy — Risiko for ulik behandling av søkere med funksjonsnedsettelse dersom treningsdata underrepresenterer denne gruppen
- Rettferdig rettergang (Art. 47): Middels — Søker har klagerett, men forklaring fra AI-system kan være utilstrekkelig uten aktiv tilrettelegging
Seksjon 4 (utdrag):
- Tiltak for Art. 21: Bias-testingsrapport fra provider gjennomgått. Internkontroll ved kvartalsvis stikkprøvekontroll av avslag mot søkerprofil. Saksbehandler-opplæring i å overridere ved usikkerhet.
- Tiltak for Art. 47: Standardisert klageveiledning som alltid vedlegges avslag. Forpliktelse om at saksbehandler skriver begrunnelse i klartekst (ikke kun AI-output).
For arkitekten
Bruk denne filen som arbeidsmal når bruker (typisk offentlig etat) skal gjennomføre FRIA for et høyrisiko-AI-system.
Typiske trigger-scenarioer:
- "Vi skal ta i bruk [AI-system] og trenger hjelp med FRIA"
- "Tilsynsmyndigheten ber oss dokumentere rettighetsvurdering"
- "Vi skal anskaffes nytt AI-system — hva må vi gjøre?"
Fremgangsmåte:
- Fyll ut seksjon 1 (systembeskrivelse) basert på brukerens input
- Identifiser berørte grupper (seksjon 2) — spør om det er sårbare grupper
- Gå gjennom rettighetsmatrisen (seksjon 3) systematisk — alle 12 rettigheter
- For middels+ rettigheter: Dypdykk i konsekvensanalyse (seksjon 4)
- Sjekk om DPIA også kreves (samordne)
- Minn om godkjenningsprosessen (seksjon 6) og tilsynsnotifikasjon (seksjon 5)
Kobling til andre KB-filer:
- Klassifisering →
ai-act-classification-methodology.md - Deployer-kontekst →
ai-act-deployer-obligations.md - ROS-analyse →
../norwegian-public-sector-governance/ros-*.md - Norsk offentlig sektor governance →
../norwegian-public-sector-governance/
Norsk kontekst: Per februar 2026 er det ingen etablert nasjonal AI-tilsynsmyndighet i Norge. Datatilsynet håndterer personverndimensjonen. Anbefal alltid å kontakte Datatilsynet for veiledning og følge deres oppdaterte retningslinjer.