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>
93 lines
5.7 KiB
Markdown
93 lines
5.7 KiB
Markdown
## EU AI Act — Vurdering: AutomatiskSaksbehandler
|
|
|
|
**Dato:** 2026-02-22
|
|
**Vurdert av:** AI Act Assessor
|
|
**Organisasjon:** Direktoratet for digital tjenesteutvikling
|
|
|
|
### 1. Risikoklassifisering
|
|
|
|
| Attributt | Verdi |
|
|
|-----------|-------|
|
|
| **Risikonivå** | Høyrisiko |
|
|
| **Annex III-kategori** | Kategori 5: Tilgang til og bruk av essensielle offentlige tjenester og ytelser |
|
|
| **GPAI-status** | Ja — basert på GPT-4o via Azure OpenAI |
|
|
| **Klassifiseringsgrunnlag** | Systemet automatiserer vurdering av helsekrav ved søknad om saksbehandling (klasse B). Direkte påvirkning på borgeres rett til saksbehandling — en essensiell offentlig tjeneste. |
|
|
| **Konfidens** | Høy |
|
|
|
|
#### Steg 1: Forbudt-sjekk (Art. 5)
|
|
Ingen forbudte praksiser identifisert. Systemet scorer ikke individer sosialt, og beslutninger kan overprøves av saksbehandler.
|
|
|
|
#### Steg 2: Annex III høyrisiko-sjekk
|
|
**Treffer kategori 5 (a):** AI-systemer som brukes av offentlige myndigheter for å vurdere berettigelse til offentlige ytelser og tjenester, inkludert tildelingsbeslutninger.
|
|
|
|
Tjenesten er en essensiell offentlig tjeneste i norsk kontekst. Automatisert vurdering av helsekrav påvirker direkte borgeres tilgang til denne tjenesten.
|
|
|
|
**Grensevurdering:** Det er ingen tvil om at dette er høyrisiko. Systemet tar beslutninger som direkte påvirker enkeltpersoners rettigheter og muligheter.
|
|
|
|
#### Steg 3: GPAI-sjekk
|
|
GPT-4o er en GPAI-modell. Microsoft er provider av grunnmodellen. Direktoratet for digital tjenesteutvikling er deployer av det tilpassede systemet. Ettersom systemet har vesentlig tilpasning (fine-tuning på norske helseattest-vurderinger), kan Direktoratet for digital tjenesteutvikling også anses som provider av det tilpassede høyrisiko-systemet.
|
|
|
|
#### Steg 4: Ikke relevant — allerede klassifisert som høyrisiko
|
|
|
|
### 2. Rolle
|
|
|
|
| Attributt | Verdi |
|
|
|-----------|-------|
|
|
| **Organisasjonens rolle** | Deployer (primært) + mulig Provider (ved vesentlig tilpasning) |
|
|
| **Begrunnelse** | Som deployer har Direktoratet for digital tjenesteutvikling alle Art. 26-27 forpliktelser. Ved fine-tuning av modellen kan organisasjonen også få provider-forpliktelser for det tilpassede systemet (Art. 25). |
|
|
| **Provider (grunnmodell)** | Microsoft (Azure OpenAI Service) |
|
|
|
|
### 3. Forpliktelser
|
|
|
|
| # | Artikkel | Krav | Status | Gap |
|
|
|---|----------|------|--------|-----|
|
|
| 1 | Art. 26(1) | Bruk i samsvar med bruksanvisning | Delvis | Bruksanvisning fra Microsoft, men ikke tilpasset norsk kontekst |
|
|
| 2 | Art. 26(2) | Menneskelig tilsyn (effektiv kontroll) | Delvis | Saksbehandler kan overprøve, men prosedyre ikke formalisert |
|
|
| 3 | Art. 26(5) | FRIA gjennomført for offentlig sektor | Ikke oppfylt | Ingen FRIA utført |
|
|
| 4 | Art. 26(6) | Loggoppbevaring minimum 6 måneder | Ikke oppfylt | Logger settes til 90 dager i Application Insights |
|
|
| 5 | Art. 27 | FRIA for offentlig myndighet-deployer | Ikke oppfylt | Obligatorisk — ikke startet |
|
|
| 6 | Art. 13 | Transparens: bruksinstruksjon tilgjengelig | Ikke oppfylt | Ingen Art. 13-dokumentasjon |
|
|
| 7 | Art. 14 | Menneskelig tilsyn: override-mekanismer | Delvis | Override mulig men ikke systematisk |
|
|
| 8 | Art. 50(1) | Informer personer om AI-bruk | Ikke oppfylt | Borgere informeres ikke om at AI vurderer helseattester |
|
|
| 9 | Art. 9 | Risikostyringssystem | Ikke oppfylt | Ingen formell risikostyring for AI-systemet |
|
|
| 10 | Art. 12 | Automatisk loggføring | Delvis | Logger finnes men retention er for kort |
|
|
|
|
### 4. Tiltaksplan
|
|
|
|
| # | Tiltak | Prioritet | Frist | Ansvarlig |
|
|
|---|--------|-----------|-------|-----------|
|
|
| T1 | Gjennomfør FRIA (Art. 27) — bruk `/architect:frimpact` | Kritisk | 2026-05-01 | Personvernombud + AI-rådgiver |
|
|
| T2 | Etabler risikostyringssystem (Art. 9) | Kritisk | 2026-06-01 | Seksjonsleder |
|
|
| T3 | Øk log retention til minimum 6 måneder (Art. 12/26) | Kritisk | 2026-04-01 | IT-drift |
|
|
| T4 | Utvikle transparensnotis til borgere (Art. 50) | Høy | 2026-05-01 | Kommunikasjonsavdeling |
|
|
| T5 | Formalisér override-prosedyre for saksbehandlere (Art. 14) | Høy | 2026-05-15 | Fagleder |
|
|
| T6 | Gjennomfør DPIA (GDPR Art. 35) — overlapper med FRIA | Høy | 2026-05-01 | Personvernombud |
|
|
| T7 | Utarbeid Art. 13 bruksinstruksjon | Middels | 2026-06-15 | AI-rådgiver |
|
|
| T8 | Forbered samsvarsvurdering (Annex IV, Art. 43) | Middels | 2026-07-01 | Kvalitetsansvarlig |
|
|
| T9 | Vurdér behov for ekstern samsvarsvurdering | Lav | 2026-07-15 | Juridisk avdeling |
|
|
|
|
### 5. Neste steg
|
|
|
|
1. **Umiddelbart:** `/architect:frimpact` — FRIA er obligatorisk og bør prioriteres høyest
|
|
2. **Innen 30 dager:** `/architect:dpia` — Personvernkonsekvensanalyse (utdyper personverndimensjonen)
|
|
3. **Innen 60 dager:** `/architect:ros` — ROS-analyse med AI Act-dimensjon (dimensjon 6)
|
|
4. **Innen 90 dager:** `/architect:conformity` — Start samsvarsvurdering
|
|
5. **Dokumentér:** `/architect:adr` — Dokumenter klassifiseringsbeslutningen
|
|
|
|
### Viktige frister
|
|
|
|
| Frist | Krav | Relevans |
|
|
|-------|------|----------|
|
|
| 2025-02-02 | Forbudte AI-praksiser (Art. 5) | Gjelder ikke |
|
|
| 2025-08-02 | Governance og sanksjoner (Art. 99) | Gjelder — governance-struktur kreves |
|
|
| 2026-08-02 | GPAI-krav + Annex III høyrisiko | **Gjelder direkte — 161 dager** |
|
|
| 2027-08-02 | Alle høyrisiko-krav (full compliance) | Gjelder — full Art. 9-27 compliance |
|
|
|
|
### Referanser
|
|
- `ai-act-classification-methodology.md` — Klassifiseringsmetodikk
|
|
- `ai-act-annex-iii-checklist.md` — Annex III kategori 5 vurdering
|
|
- `ai-act-deployer-obligations.md` — Art. 26-27 forpliktelser
|
|
- `ai-act-fria-template.md` — FRIA-mal referanse
|
|
- `ai-act-provider-obligations.md` — Art. 9-15 (ved provider-status)
|
|
- `ai-act-compliance-guide.md` — Generell veileder
|
|
- Microsoft Learn: Azure OpenAI responsible AI practices
|