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>
280 lines
13 KiB
Markdown
280 lines
13 KiB
Markdown
# EU AI Act — Systematisk Klassifiseringsmetodikk
|
|
|
|
Last updated: 2026-02
|
|
Status: GA
|
|
Category: Responsible AI & Governance
|
|
|
|
---
|
|
|
|
## Oversikt
|
|
|
|
EU AI Act (Forordning 2024/1689) bruker en risikobasert tilnærming med fire nivåer: forbudt, høy risiko, begrenset risiko og minimal risiko. Korrekt klassifisering er avgjørende — feil klassifisering kan medføre bøter på opptil 35 millioner EUR eller 7 % av global omsetning (Art. 99).
|
|
|
|
Denne metodikken gir en systematisk, steg-for-steg fremgangsmåte for å klassifisere AI-systemer.
|
|
|
|
---
|
|
|
|
## 4-stegs systematisk metodikk
|
|
|
|
### Steg 1: Forbudt-sjekk (Art. 5)
|
|
|
|
Disse praksisene er totalforbudt i EU. Vurder alle før videre analyse.
|
|
|
|
**8 forbudte praksiser og vurderingsspørsmål:**
|
|
|
|
| # | Forbudt praksis | Vurderingsspørsmål |
|
|
|---|-----------------|-------------------|
|
|
| 1 | Subliminal manipulering under bevissthetsnivå (Art. 5(1)(a)) | Påvirker systemet atferd uten at brukeren er bevisst det? |
|
|
| 2 | Utnyttelse av sårbare grupper (Art. 5(1)(b)) | Retter systemet seg mot barn, eldre eller funksjonshemmede på skadelig måte? |
|
|
| 3 | Sosial scoring av enkeltpersoner av offentlige myndigheter (Art. 5(1)(c)) | Scorer systemet borgere på tvers av kontekster for å gi fordeler/ulemper? |
|
|
| 4 | Sanntids biometrisk fjernidentifikasjon i offentlig rom (Art. 5(1)(d)) | Identifiserer systemet personer i sanntid via biometri på offentlige steder? |
|
|
| 5 | Retrospektiv biometrisk identifikasjon uten lovhjemmel (Art. 5(1)(e)) | Brukes systemet til å søke i biometriske databaser post-hoc uten særskilt hjemmel? |
|
|
| 6 | Emosjonell inferens på arbeidsplassen og i utdanning (Art. 5(1)(f)) | Analyserer systemet emosjoner hos ansatte eller elever? |
|
|
| 7 | Biometrisk kategorisering basert på sensitiv informasjon (Art. 5(1)(g)) | Utleder systemet politisk syn, seksuell orientering eller religion fra biometri? |
|
|
| 8 | AI-systemer som muliggjør kriminalitetspredikering basert på profiling (Art. 5(1)(h)) | Brukes systemet til å forutsi kriminalitet basert på personlighetstrekk? |
|
|
|
|
**Beslutning Steg 1:**
|
|
- Én eller flere = JA → **FORBUDT.** Systemet kan ikke implementeres i EU. Stopp her.
|
|
- Alle = NEI → Gå til Steg 2.
|
|
|
|
> **Merk for offentlig sektor:** Sanntids biometrisk identifikasjon har svært begrensede unntak (Art. 5(2)-(3)) for terror, savnet barn og alvorlig kriminalitet — krever forhåndstillatelse fra domstol og nasjonal tilsynsmyndighet.
|
|
|
|
---
|
|
|
|
### Steg 2: Annex III høyrisiko-sjekk
|
|
|
|
Annex III lister 8 kategorier av høyrisiko-AI. Sjekk om systemet faller inn under én eller flere.
|
|
|
|
**Kategori 1: Kritisk infrastruktur**
|
|
- Styring av trafikk, vann, gass, varme, elektrisitet
|
|
- Vurderingsspørsmål: Er systemet i en kritisk infrastruktursektor og kan påvirke drift, sikkerhet eller kontinuitet?
|
|
- Beslutning: JA → HØYRISIKO (Annex III, pkt. 2)
|
|
|
|
**Kategori 2: Utdanning og yrkesopplæring**
|
|
- AI som avgjør adgang til utdanning eller tildeler karakterer
|
|
- Vurderingsspørsmål: Påvirker systemet opptak, karakterer eller eksamensgjennomføring på bindende måte?
|
|
- Beslutning: JA → HØYRISIKO (Annex III, pkt. 3)
|
|
|
|
**Kategori 3: Sysselsetting og personalforvaltning**
|
|
- Rekruttering, CV-screening, jobbformikling, forfremmelse, oppsigelse
|
|
- Vurderingsspørsmål: Brukes systemet til å ta eller støtte avgjørelser om ansettelse eller arbeidsforhold?
|
|
- Beslutning: JA → HØYRISIKO (Annex III, pkt. 4)
|
|
|
|
**Kategori 4: Viktige private og offentlige tjenester**
|
|
- Kredittvurdering, sosiale ytelser, helsetjenester, nødtjenester
|
|
- Vurderingsspørsmål: Påvirker systemet tilgang til kreditt, sosiale ytelser, helsetjenester eller nødetater?
|
|
- Beslutning: JA → HØYRISIKO (Annex III, pkt. 5)
|
|
|
|
**Kategori 5: Rettshåndhevelse**
|
|
- Individuell risikovurdering, polygrafanalyse, kriminalitetspredikering
|
|
- Vurderingsspørsmål: Brukes systemet av politiet eller påtalemyndigheten til å vurdere enkeltpersoner?
|
|
- Beslutning: JA → HØYRISIKO (Annex III, pkt. 6)
|
|
|
|
**Kategori 6: Migrasjons- og grensekontroll**
|
|
- Risikovurdering av asylsøkere, visumsøknader, grensepassering
|
|
- Vurderingsspørsmål: Brukes systemet i forbindelse med asyl, visum, grensekontroll eller migrasjon?
|
|
- Beslutning: JA → HØYRISIKO (Annex III, pkt. 7)
|
|
|
|
**Kategori 7: Rettsvesen og demokratiske prosesser**
|
|
- AI som assisterer domstoler, påvirker valg eller tolker lover
|
|
- Vurderingsspørsmål: Brukes systemet av domstoler eller til å påvirke demokratiske prosesser?
|
|
- Beslutning: JA → HØYRISIKO (Annex III, pkt. 8)
|
|
|
|
**Kategori 8: Biometrisk identifikasjon og kategorisering**
|
|
- Fjernidentifikasjon (ikke sanntids), kategorisering basert på biometri
|
|
- Vurderingsspørsmål: Identifiserer eller kategoriserer systemet personer basert på biometriske data (ikke dekket av Art. 5)?
|
|
- Beslutning: JA → HØYRISIKO (Annex III, pkt. 1)
|
|
|
|
**Beslutning Steg 2:**
|
|
- Én eller flere = JA → **HØYRISIKO.** Fullt regelverk Art. 9-27 gjelder. Gå til rolle-bestemmelse.
|
|
- Alle = NEI → Gå til Steg 3.
|
|
|
|
> **Unntak:** Art. 6(3) — sikkerhetsprosedyrer, QA-testing og forskning/utvikling er unntatt Annex III-krav selv om de ellers ville kvalifisert.
|
|
|
|
---
|
|
|
|
### Steg 3: GPAI-sjekk (General Purpose AI)
|
|
|
|
GPAI-reglene (Art. 51-56) gjelder providers av grunnmodeller uavhengig av risikonivå.
|
|
|
|
**Er systemet basert på en generell AI-modell?**
|
|
|
|
Vurderingsspørsmål:
|
|
- Er systemet trent på store datamengder med generell brukbarhet?
|
|
- Kan systemet brukes til et bredt spekter av ulike oppgaver?
|
|
- Er systemet en modell som brukes som grunnlag for andre systemer (foundation model)?
|
|
|
|
**Kriterier for GPAI med systemisk risiko (Art. 51):**
|
|
|
|
| Kriterium | Terskel |
|
|
|-----------|---------|
|
|
| Treningsberegning | > 10²⁵ FLOP |
|
|
| Vurdert av EU-kommisjonen | Som systemisk risikomodell |
|
|
| Eksempler pr. 2025 | GPT-4, Claude 3, Gemini Ultra |
|
|
|
|
**Forpliktelser for GPAI-providers:**
|
|
- Standard GPAI (Art. 53): Teknisk dokumentasjon, opphavsrettspolicy, treningsdata-oversikt
|
|
- GPAI med systemisk risiko (Art. 55): Modelevaluering, adversarial testing, incidenrapportering, cybersikkerhet
|
|
|
|
**Beslutning Steg 3:**
|
|
- Provider av GPAI-modell → **GPAI-regler** gjelder i tillegg til eventuelle høyrisiko-krav
|
|
- Deployer av GPAI → Bruk provider-utstedt dokumentasjon, vurder systemet som helhet
|
|
- Ikke GPAI → Gå til Steg 4
|
|
|
|
---
|
|
|
|
### Steg 4: Begrenset/Minimal klassifisering
|
|
|
|
Systemer som ikke er forbudt eller høyrisiko kan falle i én av to kategorier:
|
|
|
|
**Begrenset risiko — transparenskrav (Art. 50):**
|
|
|
|
| Systemtype | Krav |
|
|
|------------|------|
|
|
| Chatbots og conversational AI | Informere bruker om at de snakker med AI |
|
|
| Deepfake-lyd og -video | Merke innhold som AI-generert |
|
|
| Emosjonell gjenkjenning (tillatt kontekst) | Informere berørte personer |
|
|
| Biometrisk kategorisering (tillatt) | Informere berørte personer |
|
|
|
|
Vurderingsspørsmål: Interagerer systemet direkte med mennesker, genererer syntetisk innhold, eller analyserer emosjoner/biometri i tillatt kontekst?
|
|
- JA → **BEGRENSET RISIKO.** Transparenskrav Art. 50 gjelder.
|
|
- NEI → **MINIMAL RISIKO.** Ingen bindende krav, men beste praksis anbefales.
|
|
|
|
---
|
|
|
|
## Rolle-bestemmelse: Provider vs. Deployer
|
|
|
|
Forpliktelsene varierer vesentlig avhengig av rolle (Art. 3(3)-(4)).
|
|
|
|
| Ansvarsområde | Provider | Deployer |
|
|
|---------------|----------|----------|
|
|
| Samsvarsvurdering | Fullt ansvar (Art. 43) | Ikke direkte ansvar |
|
|
| CE-merking | Påkrevd (Art. 48) | Ikke relevant |
|
|
| Teknisk dokumentasjon (Art. 11) | Fullt ansvar | Motta og oppbevare |
|
|
| Risikostyringssystem (Art. 9) | Påkrevd | Operasjonelt tilsyn |
|
|
| Logging (Art. 12) | System-design | 6-måneders oppbevaring |
|
|
| FRIA (Art. 27) | Ikke direkte | Påkrevd for offentlig sektor |
|
|
| Registrering EU-database (Art. 49) | Påkrevd | Påkrevd for offentlig sektor |
|
|
| Hendelsesrapportering (Art. 73) | Alvorlige hendelser | Rapportere til provider |
|
|
| Markedsovervåking | Ikke direkte | Via tilsynsmyndighet |
|
|
|
|
**Grensetilfeller for offentlig sektor:**
|
|
|
|
Offentlig sektor er typisk **deployer** — de kjøper og tar i bruk AI-systemer. Men virksomheten kan bli **provider** hvis:
|
|
1. De tilpasser et eksisterende AI-system vesentlig (art. 25(1)(b)) — f.eks. fine-tuner en modell på egne data
|
|
2. De setter navn på systemet og markedsfører det utad (Art. 25(1)(a))
|
|
3. De integrerer et high-risk AI-system som endrer opprinnelig tiltenkt formål vesentlig
|
|
|
|
Direktoratet for digital tjenesteutvikling eksempel: Kjøper Microsoft Copilot Studio → **Deployer**. Bygger eget prediksjonsverktøy basert på Azure OpenAI med tilpasset sikkerhetsdomenetrening → vurder om → **Provider**.
|
|
|
|
---
|
|
|
|
## Transport-sektoreksempler
|
|
|
|
### Eksempel 1: FartsPrediksjonsagent (Direktoratet for digital tjenesteutvikling)
|
|
- Formål: Predikerer trafikkflyt og anbefaler fartsgrenser på variabelt oppsatte skilt
|
|
- Steg 1: Ingen forbudte praksiser → NEI
|
|
- Steg 2: Kritisk infrastruktur (Annex III, pkt. 2)? Påvirker trafikksikkerhet → JA, men kun dersom det tar **bindende** beslutninger. Dersom det kun er et beslutningsstøtteverktøy med menneskelig godkjenning → vurder Art. 6(2) unntak
|
|
- Klassifisering: **Minimal risiko** (beslutningsstøtte) eller **Høyrisiko** (autonomt bindende)
|
|
|
|
### Eksempel 2: AutomatiskSaksbehandler for saksbehandlingvurdering
|
|
- Formål: Vurderer automatisk om en søker oppfyller helsekrav for saksbehandling
|
|
- Steg 1: NEI til alle forbudte praksiser
|
|
- Steg 2: Kategori 4 (viktige offentlige tjenester) → JA, tilgang til offentlig tjeneste
|
|
- Klassifisering: **HØYRISIKO** (Annex III, pkt. 5)
|
|
- Rolle: Direktoratet for digital tjenesteutvikling = **Deployer**
|
|
- Krav: FRIA (Art. 27), logging 6 mnd, samsvarsvurdering fra provider
|
|
|
|
### Eksempel 3: Trafikkstyringsagent
|
|
- Formål: Autonom styring av trafikklys i tunneler og på motorveier
|
|
- Steg 1: NEI
|
|
- Steg 2: Kategori 1 (kritisk infrastruktur) — styring av trafikksystemer → JA
|
|
- Klassifisering: **HØYRISIKO** (Annex III, pkt. 2)
|
|
- Særlige krav: Robusthet, menneskelig override (Art. 14), kontinuerlig overvåking
|
|
|
|
---
|
|
|
|
## Grensevurderinger
|
|
|
|
Disse tilfellene er hyppige og krever nøye analyse:
|
|
|
|
**Tilfelle A: Chatbot med begrenset autonomi**
|
|
Et chatsystem som svarer på spørsmål om sosiale ytelser (NAV-lignende). Er det Annex III kategori 4?
|
|
- Kun informasjon → **Begrenset risiko** (transparens Art. 50)
|
|
- Avgjør tilgang til ytelse → **Høyrisiko**
|
|
- Anbefaling: Dokumenter tydelig at systemet ikke tar avgjørelser, kun informerer
|
|
|
|
**Tilfelle B: HR-screening med menneskelig godkjenning**
|
|
AI rangerer CV-er, HR-leder tar endelig beslutning.
|
|
- Art. 6(3)(b) unntaker ikke nødvendigvis dette — systemet påvirker fremdeles utfall
|
|
- Anbefaling: Klassifiser som **Høyrisiko** dersom rangeringen er avgjørende i praksis
|
|
|
|
**Tilfelle C: Intern analyseverktøy for planlegging**
|
|
Kommunen bruker AI til å analysere demografidata for arealplanlegging — ingen individuelle beslutninger.
|
|
- Ikke Annex III
|
|
- Klassifisering: **Minimal risiko**
|
|
|
|
**Tilfelle D: Prediktiv politimodell**
|
|
System som identifiserer geografiske "hotspot"-områder uten å peke ut enkeltpersoner.
|
|
- Potensielt forbudt (Art. 5(1)(d)-(e)) eller Annex III kategori 5/6
|
|
- Anbefaling: Konsultér Datatilsynet og Nasjonal tilsynsmyndighet for AI (Nkom som kandidat) FØR implementering
|
|
|
|
**Generell anbefaling for grensetilfeller:** Kontakt Datatilsynet (personvern-aspektet) og fremtidig Nasjonal AI-tilsynsmyndighet. Dokumenter klassifiseringsargumentasjonen uansett utfall.
|
|
|
|
---
|
|
|
|
## Beslutningsflytdiagram
|
|
|
|
```
|
|
START: Nytt AI-system til vurdering
|
|
|
|
|
v
|
|
+-------------------------+
|
|
| STEG 1: Forbudt-sjekk |
|
|
| Art. 5 — 8 praksiser |
|
|
+-------------------------+
|
|
| |
|
|
JA NEI
|
|
| |
|
|
v v
|
|
FORBUDT STEG 2: Annex III
|
|
(STOPP) Høyrisiko-sjekk
|
|
| |
|
|
JA NEI
|
|
| |
|
|
v v
|
|
HØYRISIKO STEG 3: GPAI-sjekk
|
|
(Art. 9-27) | |
|
|
| JA NEI
|
|
| | |
|
|
v v v
|
|
Rolle- GPAI-regler STEG 4: Begrenset
|
|
bestemmelse (Art.51-56) /Minimal sjekk
|
|
Provider/ | |
|
|
Deployer JA NEI
|
|
| |
|
|
v v
|
|
BEGRENSET MINIMAL
|
|
RISIKO RISIKO
|
|
(Art. 50) (beste praksis)
|
|
```
|
|
|
|
---
|
|
|
|
## For Cosmo
|
|
|
|
Bruk denne filen når brukeren trenger å klassifisere et AI-system under EU AI Act.
|
|
|
|
**Fremgangsmåte:**
|
|
1. Gå gjennom steg 1-4 systematisk — hopp ikke over steg
|
|
2. Still vurderingsspørsmålene eksplisitt for brukerens system
|
|
3. Dokumenter hvert steg i klassifiseringsrapporten (anbefalt vedlegg til FRIA)
|
|
4. Bruk transport-sektoreksemplene som analogi når Direktoratet for digital tjenesteutvikling er deployer
|
|
5. Flagg grensetilfeller og anbefal konsultasjon med tilsynsmyndighet
|
|
|
|
**Kobling til andre KB-filer:**
|
|
- Høyrisiko-klassifisering → `ai-act-provider-obligations.md` (provider) eller `ai-act-deployer-obligations.md` (deployer)
|
|
- FRIA påkrevd → `ai-act-fria-template.md`
|
|
- Offentlig sektor governance → `../norwegian-public-sector-governance/`
|
|
|
|
**Viktig presisering:** Per februar 2026 er forbudte praksiser (Art. 5) i kraft. Høyrisiko-krav (Art. 9-27) gjelder fra august 2026. GPAI-krav fra august 2025. Transparenskrav (Art. 50) fra august 2026.
|