feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command
Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
commit
baa2d0220b
488 changed files with 213221 additions and 0 deletions
|
|
@ -0,0 +1,357 @@
|
|||
# EU AI Act — Samsvarsvurdering og EU-samsvarserklæring
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Responsible AI & Governance
|
||||
|
||||
---
|
||||
|
||||
## Oversikt
|
||||
|
||||
EU AI Act kapittel 5 (Art. 43–49) stiller krav om formell samsvarsvurdering (conformity assessment) for høyrisiko-AI-systemer før de kan plasseres på markedet eller tas i bruk. For de fleste systemer i Annex III kan dette gjøres internt av tilbyderen selv. Samsvarsvurderingen dokumenteres i teknisk dokumentasjon (Annex IV) og avsluttes med en EU-samsvarserklæring (Art. 47) og CE-merking (Art. 48).
|
||||
|
||||
---
|
||||
|
||||
## Annex IV — 9-element sjekkliste for teknisk dokumentasjon
|
||||
|
||||
Annex IV spesifiserer hvilken teknisk dokumentasjon som kreves. Under følger hvert element med krav, eksempler og typiske mangler.
|
||||
|
||||
### Element 1: Generell beskrivelse av AI-systemet
|
||||
|
||||
**Hva kreves:**
|
||||
- Formål, tiltenkt bruk og brukergrupper
|
||||
- Systemkategori (Annex III-referanse)
|
||||
- Versjonsnummer og dato
|
||||
- Overordnet beskrivelse av funksjonalitet
|
||||
|
||||
**Eksempel:**
|
||||
> "VegvAI-Saksbehandler v2.1 er et beslutningsstøttesystem for saksbehandlere i Statens vegvesen (Annex III, punkt 5a). Systemet analyserer søknader om dispensasjon fra veitrafikklovgivningen og genererer et begrunnet utkast til vedtak. Endelig vedtak fattes alltid av autorisert saksbehandler."
|
||||
|
||||
**Typiske mangler:**
|
||||
- Annex III-kategorien er ikke spesifisert
|
||||
- Brukergrupper er for vagt beskrevet ("offentlig sektor")
|
||||
- Systemet er ikke avgrenset mot hva det IKKE gjør
|
||||
|
||||
---
|
||||
|
||||
### Element 2: Detaljert beskrivelse av systemkomponentene og utviklingsprosessen
|
||||
|
||||
**Hva kreves:**
|
||||
- Arkitekturdiagram med dataflyt
|
||||
- Treningsdata: opprinnelse, omfang, preprosessering
|
||||
- Treningsmetode og valideringsprosess
|
||||
- Tredjepartskomponenter (f.eks. Azure OpenAI, modell-id)
|
||||
- Versjonskontroll og endringshåndtering
|
||||
|
||||
**Eksempel:**
|
||||
> "Systemet benytter Azure OpenAI GPT-4o (modell-id: gpt-4o-2024-08-06) via Azure AI Foundry. Treningsdata er ikke benyttet — systemet er prompt-engineered med virksomhetens egne saksmaler. Retrieval-augmented generation (RAG) er implementert mot en Azure AI Search-indeks med 12 000 dokumenter fra Lovdata og interne retningslinjer. Indeksen oppdateres månedlig."
|
||||
|
||||
**Typiske mangler:**
|
||||
- Konkret modell-ID mangler (bare "GPT-4" oppgitt)
|
||||
- Dataflyt mellom komponenter er ikke dokumentert
|
||||
- Tredjeparts-leverandørens egne dokumenter er ikke vedlagt
|
||||
|
||||
---
|
||||
|
||||
### Element 3: Detaljert informasjon om monitorering, funksjonalitet og kontroll
|
||||
|
||||
**Hva kreves:**
|
||||
- Monitoreringsplan for produksjonsmiljø
|
||||
- KPI-er og grenseverdier som utløser tiltak
|
||||
- Hendelseslogg og varslingsprosedyrer
|
||||
- Human-in-the-loop-mekanismer
|
||||
|
||||
**Eksempel:**
|
||||
> "Azure Monitor overvåker responskvalitet og latens kontinuerlig. Terskler: hallusinasjonsrate > 2% utløser automatisk varsling til AI-ansvarlig. Saksbehandler vurderer alltid AI-utkast og kan avvise eller redigere. Avvisningsrate logges ukentlig og aggregeres i månedlig kvalitetsrapport."
|
||||
|
||||
**Typiske mangler:**
|
||||
- KPI-er er ikke kvantifisert
|
||||
- Varslingsprosedyre er ikke definert (hvem varsles, innen hvilken tid?)
|
||||
- Human-in-the-loop er beskrevet som intensjon, ikke som teknisk implementering
|
||||
|
||||
---
|
||||
|
||||
### Element 4: Beskrivelse av systemets nøyaktighet, robusthet og cybersikkerhet
|
||||
|
||||
**Hva kreves:**
|
||||
- Nøyaktighetsmetrikker (presisjon, recall, F1 o.l.) fra validering
|
||||
- Robusthetstesting (adversarial inputs, distribusjonsskift)
|
||||
- Cybersikkerhetsarkitektur og sårbarhetsanalyse
|
||||
- Tiltak mot prompt injection og data poisoning
|
||||
|
||||
**Eksempel:**
|
||||
> "Validering på 500 historiske saker: presisjon 94%, recall 89%, F1 0,915. Adversarial testing gjennomført av intern red team (20 angrepsvektorer). Prompt injection mitigert via input sanitering og systemprompt-hardening. Modellen er ikke tilgjengelig fra internett — all trafikk går via privat Azure-endepunkt (Private Endpoint)."
|
||||
|
||||
**Typiske mangler:**
|
||||
- Nøyakshetsmetrikker er ikke oppgitt eller kun beskrevet kvalitativt
|
||||
- Robusthetstesting er ikke dokumentert
|
||||
- Cybersikkerhet er referert til generelle policyer uten systemspesifikk analyse
|
||||
|
||||
---
|
||||
|
||||
### Element 5: Beskrivelse av risikostyringssystemet (Art. 9)
|
||||
|
||||
**Hva kreves:**
|
||||
- Risikovurderingsprosess og -metodikk
|
||||
- Identifiserte risikoer med sannsynlighet og konsekvens
|
||||
- Risikoreduserende tiltak
|
||||
- Restrisiko og akseptkriterier
|
||||
- Prosess for løpende risikovurdering
|
||||
|
||||
**Eksempel:**
|
||||
> "Risikostyring følger NS 5814:2021 og SSBs veileder for AI-risiko. Risikovurdering gjennomføres ved lansering og ved vesentlige endringer. Kritisk risiko: feilaktige vedtaksutkast som saksbehandler godkjenner uten kritisk vurdering. Tiltak: opplæringsprogram, UI-design som fremhever usikkerhetsmarkering, månedlig stikkprøvekontroll av 5% av vedtak."
|
||||
|
||||
**Typiske mangler:**
|
||||
- Restrisiko er ikke akseptert av ledelsen formelt
|
||||
- Løpende risikovurdering er ikke planlagt (kun ved lansering)
|
||||
- Kobling mellom risikoregister og Art. 9-krav mangler
|
||||
|
||||
---
|
||||
|
||||
### Element 6: Beskrivelse av endringer gjennom livssyklusen
|
||||
|
||||
**Hva kreves:**
|
||||
- Endringslogg med semantisk versjonering
|
||||
- Definisjon av vesentlig endring (substantial modification, Art. 83)
|
||||
- Prosess for revurdering av samsvar ved endringer
|
||||
- Planlagt avvikling/erstatning
|
||||
|
||||
**Eksempel:**
|
||||
> "Vesentlig endring er definert som: ny Annex III-kategori, ny brukergruppe, ny modell (annen leverandør), endret formål, eller nøyakshetsfall > 5 prosentpoeng. Ved vesentlig endring gjennomføres full samsvarsvurdering på nytt. Mindre endringer (prompt-justering, indeksoppdatering) loggføres i endringslogg og vurderes av AI-ansvarlig."
|
||||
|
||||
**Typiske mangler:**
|
||||
- Vesentlig endring er ikke operasjonelt definert
|
||||
- Det finnes ingen prosess for å avgjøre om en endring er vesentlig
|
||||
- Endringslogg er ikke koblet til samsvarsvurderingen
|
||||
|
||||
---
|
||||
|
||||
### Element 7: Kvalitetsstyringssystem (QMS) beskrivelse
|
||||
|
||||
**Hva kreves:**
|
||||
- Referanse til organisasjonens QMS
|
||||
- AI-spesifikke prosedyrer (Art. 17)
|
||||
- Kompetansekrav og opplæringsplan
|
||||
- Dokumentstyring
|
||||
|
||||
**Eksempel:**
|
||||
> "Statens vegvesen følger ISO 9001:2015. AI-spesifikke tilleggsprosedyrer: SVV-AI-P01 (Anskaffelse av AI-systemer), SVV-AI-P02 (Samsvarsvurdering), SVV-AI-P03 (Incident management). AI-ansvarlig (rolle) er utpekt og har gjennomført EU AI Act Foundation-sertifisering (IAPP, 2025)."
|
||||
|
||||
**Typiske mangler:**
|
||||
- QMS er referert uten AI-spesifikke prosedyrer
|
||||
- Kompetansekrav er ikke operasjonalisert
|
||||
- Dokumentstyring for AI-artefakter er ikke beskrevet
|
||||
|
||||
---
|
||||
|
||||
### Element 8: Informasjon om EU-samsvarserklæringen og CE-merking
|
||||
|
||||
**Hva kreves:**
|
||||
- Referanse til EU-samsvarserklæringen (Art. 47)
|
||||
- CE-merking med notified body-nummer hvis eksternt vurdert
|
||||
- Plassering av CE-merking i brukerdokumentasjon
|
||||
|
||||
**Eksempel:**
|
||||
> "EU-samsvarserklæring datert 2026-01-15, signert av daglig leder. Intern samsvarsvurdering (Annex VI) — ingen notified body involvert. CE-merking er synlig i administratorpanelet og i brukerdokumentasjon (versjon 2.1, seksjon 1.2)."
|
||||
|
||||
**Typiske mangler:**
|
||||
- CE-merkingen er plassert, men ikke synlig for brukere som Art. 48 krever
|
||||
- Samsvarserklæringen er ikke datert eller signert av autorisert person
|
||||
|
||||
---
|
||||
|
||||
### Element 9: Registreringsinformasjon for EU-database
|
||||
|
||||
**Hva kreves:**
|
||||
- Registreringsnummer fra EU-databasen (Art. 71) — obligatorisk fra 2. august 2026
|
||||
- Bekreftelse på at registrering er fullført
|
||||
- URL til offentlig oppføring
|
||||
|
||||
**Eksempel:**
|
||||
> "Registrert i EU AI Act Database: EUAI-2026-NO-00142. Offentlig oppføring: https://eudatabase.ec.europa.eu/ai/NO/00142. Registrering gjennomført 2026-01-20 av AI-ansvarlig."
|
||||
|
||||
**Typiske mangler:**
|
||||
- Registrering er ikke gjennomført (mange venter til siste frist)
|
||||
- Registreringsnummer er ikke inkludert i teknisk dokumentasjon
|
||||
|
||||
---
|
||||
|
||||
## EU-samsvarserklæring-mal (Art. 47)
|
||||
|
||||
Følgende mal kan brukes direkte. Fyll ut alle felter merket med [KLAMME].
|
||||
|
||||
---
|
||||
|
||||
**EU-SAMSVARSERKLÆRING**
|
||||
|
||||
*Utstedt i henhold til Europaparlamentets og Rådets forordning (EU) 2024/1689 (EU AI Act) artikkel 47*
|
||||
|
||||
**1. Tilbyderens identifikasjon**
|
||||
|
||||
Navn: [Organisasjonens fulle navn]
|
||||
Organisasjonsnummer: [NO-nummer]
|
||||
Adresse: [Gateadresse, postnummer, by]
|
||||
Kontaktperson for AI Act-henvendelser: [Navn, e-post, telefon]
|
||||
|
||||
**2. AI-systemets identifikasjon**
|
||||
|
||||
Systemnavn: [Navn på AI-systemet]
|
||||
Versjon: [Versjonsnummer, f.eks. v2.1.0]
|
||||
Kort beskrivelse: [2–3 setninger om formål og funksjon]
|
||||
Programvare-/maskinvarekomponenter: [Liste over kjernedeler]
|
||||
|
||||
**3. Annex III-kategorisering**
|
||||
|
||||
Dette AI-systemet faller inn under Annex III, [punkt X], underpunkt [X(x)]:
|
||||
[Sitat fra Annex III som er relevant]
|
||||
|
||||
**4. Samsvarsvurderingsmetode**
|
||||
|
||||
[ ] Intern samsvarsvurdering i henhold til Annex VI (Art. 43(2))
|
||||
[ ] Ekstern samsvarsvurdering av notified body i henhold til Annex VII (Art. 43(1))
|
||||
|
||||
Hvis ekstern: Notified body-navn og akkrediteringsnummer: [Navn, nr.]
|
||||
Attestnummer: [Attestnummer fra notified body]
|
||||
|
||||
**5. Refererte harmoniserte standarder og tekniske spesifikasjoner**
|
||||
|
||||
[Liste over relevante standarder, f.eks.:]
|
||||
- ISO/IEC 42001:2023 — AI Management Systems
|
||||
- ISO/IEC 27001:2022 — Information Security
|
||||
- CEN/CENELEC [nummer] — [Harmonisert standard når tilgjengelig]
|
||||
- ETSI EN 303 645 — [Hvis relevant for edge-deployment]
|
||||
|
||||
**6. Teknisk dokumentasjon**
|
||||
|
||||
Teknisk dokumentasjon utarbeidet i henhold til Annex IV er tilgjengelig hos tilbyderen og kan fremlegges for relevante myndigheter på forespørsel.
|
||||
Dokumentreferanse: [Intern dokumentkode, f.eks. SVV-AI-TD-001 v2.1]
|
||||
|
||||
**7. EU-databaseregistrering**
|
||||
|
||||
Registreringsnummer: [EUAI-YYYY-NO-XXXXX]
|
||||
Registreringsdato: [ÅÅÅÅ-MM-DD]
|
||||
|
||||
**8. Erklæring**
|
||||
|
||||
Herved erklærer vi på eget ansvar at AI-systemet beskrevet ovenfor er i samsvar med kravene i forordning (EU) 2024/1689 (EU AI Act), særlig kapittel III avdeling 3.
|
||||
|
||||
Sted og dato: [By], [ÅÅÅÅ-MM-DD]
|
||||
|
||||
Signatur: ___________________________
|
||||
|
||||
Navn og stilling: [Navn], [Stilling — typisk daglig leder eller bemyndiget person]
|
||||
|
||||
---
|
||||
|
||||
## Intern vs. ekstern samsvarsvurdering
|
||||
|
||||
### Intern samsvarsvurdering (Art. 43(2), Annex VI)
|
||||
|
||||
**Når kan det brukes:**
|
||||
- Alle høyrisiko-systemer i Annex III **unntatt** biometrisk fjernidentifisering i offentlige rom og systemer som faller inn under Annex I (produktsikkerhetsdirektiver)
|
||||
- Det vil si: de fleste systemer i offentlig sektor kan bruke intern prosedyre
|
||||
|
||||
**Prosedyre (Annex VI):**
|
||||
1. Tilbyderen utarbeider teknisk dokumentasjon (Annex IV)
|
||||
2. Kvalitetsstyringssystem (Art. 17) er etablert og operativt
|
||||
3. Teknisk dokumentasjon gjennomgås og godkjennes internt
|
||||
4. EU-samsvarserklæring utarbeides og signeres
|
||||
5. CE-merking påføres
|
||||
6. Registrering i EU-database (Art. 71)
|
||||
|
||||
**Fordeler:** Raskere, billigere, full kontroll
|
||||
**Risiko:** Intern bias — sørg for uavhengig intern review
|
||||
|
||||
### Ekstern samsvarsvurdering (Art. 43(1), Annex VII)
|
||||
|
||||
**Når er det påkrevd:**
|
||||
- AI-systemer for biometrisk fjernidentifisering (Annex III, punkt 1)
|
||||
- Systemer under produktsikkerhetsdirektiver (Annex I) der disse direktivene krever tredjeparts sertifisering
|
||||
- Frivillig, hvis organisasjonen ønsker ekstra troverdighet
|
||||
|
||||
**Prosedyre (Annex VII):**
|
||||
1. Velg akkreditert notified body (liste på NANDO-portalen)
|
||||
2. Lever teknisk dokumentasjon til notified body
|
||||
3. Notified body gjennomfører vurdering (typisk 3–6 måneder)
|
||||
4. Attestnummer utstedes
|
||||
5. Tilbyderen utsteder EU-samsvarserklæring med attestnummer
|
||||
6. CE-merking med notified body-nummer
|
||||
|
||||
**Kostnad:** Typisk 50 000–300 000 NOK avhengig av systemets kompleksitet
|
||||
|
||||
### Beslutningstre
|
||||
|
||||
```
|
||||
Er systemet for biometrisk fjernidentifisering?
|
||||
├─ JA → Ekstern vurdering (Annex VII) PÅKREVD
|
||||
└─ NEI → Faller systemet under Annex I (produktsikkerhetsdirektiver)?
|
||||
├─ JA → Sjekk om det relevante direktivet krever notified body
|
||||
└─ NEI → Intern vurdering (Annex VI) er tilstrekkelig
|
||||
(Frivillig ekstern vurdering kan velges for troverdighet)
|
||||
```
|
||||
|
||||
**For norsk offentlig sektor:** Typiske systemer (saksbehandlingsstøtte, tildeling av ytelser, trafikkoptimalisering) kan bruke intern prosedyre. Det finnes per 2026-02 ingen norske akkrediterte notified bodies for AI Act — EU-baserte må benyttes for ekstern vurdering.
|
||||
|
||||
---
|
||||
|
||||
## Prosess-tidslinje: Fra design til CE-merking
|
||||
|
||||
| Fase | Aktivitet | Typisk varighet |
|
||||
|------|-----------|-----------------|
|
||||
| 1. Klassifisering | Avgjør om systemet er høyrisiko (Annex III) | 1–2 uker |
|
||||
| 2. Gap-analyse | Sammenlign nåværende praksis mot Art. 9–17-krav | 2–4 uker |
|
||||
| 3. Risikostyring | Etablér risikovurderingsprosess og -register (Art. 9) | 4–8 uker |
|
||||
| 4. Data governance | Dokumentér treningsdata og datakvalitetstiltak (Art. 10) | 2–6 uker |
|
||||
| 5. Teknisk dokumentasjon | Skriv Annex IV-dokumentasjonen (alle 9 elementer) | 4–8 uker |
|
||||
| 6. QMS-tilpasning | Tilpass kvalitetsstyringssystem til Art. 17-krav | 2–4 uker |
|
||||
| 7. Intern review | Uavhengig intern gjennomgang av teknisk dokumentasjon | 2–3 uker |
|
||||
| 8. Samsvarserklæring | Utarbeid og signer EU-samsvarserklæring (Art. 47) | 1 uke |
|
||||
| 9. Registrering | Registrer i EU-database (Art. 71) | 1 uke |
|
||||
| 10. CE-merking | Påfør CE-merking i dokumentasjon og UI | 1 uke |
|
||||
| **Totalt (intern)** | | **3–9 måneder** |
|
||||
| **Totalt (ekstern)** | Legg til 3–6 måneder for notified body-prosess | **6–15 måneder** |
|
||||
|
||||
**Kritisk sti:** Risikostyring (fase 3) og teknisk dokumentasjon (fase 5) er de mest tidkrevende fasene. Start disse tidlig.
|
||||
|
||||
---
|
||||
|
||||
## Norsk kontekst
|
||||
|
||||
### Tilsynsmyndighet
|
||||
|
||||
Norge har ikke per 2026-02 utpekt én enkelt nasjonal tilsynsmyndighet (market surveillance authority) for EU AI Act, men EØS-tilpasningen er under arbeid. Forventet struktur:
|
||||
|
||||
- **Datatilsynet:** Primær tilsynsmyndighet for AI-systemer som behandler personopplysninger
|
||||
- **Sektortilsyn:** Finanstilsynet (finansielle tjenester), Helsetilsynet (helse), Luftfartstilsynet (transport) for domene-spesifikke systemer
|
||||
- **Digdir:** Koordineringsrolle for offentlig sektor
|
||||
|
||||
For offentlig sektor anbefales å avvente Datatilsynets veiledning og holde dialog med Digdir.
|
||||
|
||||
### EØS-overgangsordninger
|
||||
|
||||
EU AI Act trer formelt i kraft i EU fra 2. august 2024 med stegvise ikrafttredelsesdatoer:
|
||||
- **2. august 2025:** Forbud mot uakseptabel risiko (Art. 5) gjelder
|
||||
- **2. august 2026:** Høyrisiko-krav (Art. 6–49), inkl. samsvarsvurdering og CE-merking
|
||||
- **2. august 2027:** Systemer som allerede er i drift (grandfathering-periode utløper)
|
||||
|
||||
EØS-innlemmelse forventes å skje med noe forsinkelse (typisk 1–2 år). Norske virksomheter som leverer tjenester i EU/EØS, må likevel etterleve EU AI Act fra ikrafttredelsesdatoene for å operere i EU-markedet.
|
||||
|
||||
**Anbefaling:** Forbered samsvarsvurdering nå, slik at CE-merking er klar til 2. august 2026.
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
Bruk dette dokumentet når:
|
||||
|
||||
1. **Kunden spør "hva kreves for CE-merking?"** — Gå gjennom Annex IV-elementene og identifiser gap mot kundens nåværende dokumentasjonspraksis.
|
||||
|
||||
2. **Kunden er usikker på intern vs. ekstern vurdering** — Bruk beslutningstreet. For de aller fleste norske offentlige systemer er intern prosedyre tilstrekkelig.
|
||||
|
||||
3. **Kunden trenger konkrete maler** — Bruk EU-samsvarserklærings-malen direkte. Fyll ut med kundens data.
|
||||
|
||||
4. **Kunden vil planlegge compliance-arbeidet** — Bruk prosess-tidslinjen. 3–9 måneder for intern vurdering er realistisk for et gjennomsnittlig system.
|
||||
|
||||
5. **Kunden spør om norsk tilsynsmyndighet** — Forklar den uavklarte situasjonen og råd om å holde dialog med Datatilsynet og Digdir.
|
||||
|
||||
Vær konkret: pek på hvilke Annex IV-elementer som typisk mangler, og hjelp kunden med å prioritere arbeidet fra størst til minst risiko.
|
||||
Loading…
Add table
Add a link
Reference in a new issue