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,339 @@
|
|||
# EU AI Act — Forpliktelser for Tilbydere (Providers)
|
||||
|
||||
Last updated: 2026-02
|
||||
Status: GA
|
||||
Category: Responsible AI & Governance
|
||||
|
||||
---
|
||||
|
||||
## Oversikt
|
||||
|
||||
En provider er enhver juridisk eller fysisk person som utvikler et AI-system (eller får det utviklet) og markedsfører det under sitt navn eller varemerke, enten mot betaling eller gratis (Art. 3(3)). For høyrisiko-AI-systemer gjelder et omfattende sett med forpliktelser under Art. 9-27.
|
||||
|
||||
Bøter ved brudd: Opptil **30 millioner EUR eller 6 % av global omsetning** (Art. 99(3)).
|
||||
|
||||
---
|
||||
|
||||
## Art. 9: Risikostyringssystem
|
||||
|
||||
### 4 kjernekomponenter
|
||||
|
||||
Risikostyringssystemet er en iterativ prosess gjennom hele AI-systemets livssyklus:
|
||||
|
||||
**Komponent 1: Identifikasjon av kjente og rimelig forutsigbare risikoer**
|
||||
- Risikoidentifikasjon ved design, utvikling og faktisk bruk
|
||||
- Inkludert misbruk og bruk utenfor tiltenkt formål
|
||||
- Dokumenter per risikoidentifikasjonssyklus
|
||||
|
||||
**Komponent 2: Estimering og evaluering av risikoer**
|
||||
- Kvantitativ og kvalitativ risikovurdering
|
||||
- Vurder sannsynlighet og alvorlighetsgrad
|
||||
- Særskilt hensyn til sårbare grupper (barn, eldre, funksjonshemmede)
|
||||
|
||||
**Komponent 3: Risikoreduserende tiltak**
|
||||
- Tekniske tiltak (robusthetstesting, fail-safes, override-mekanismer)
|
||||
- Organisatoriske tiltak (opplæring, prosedyrer, roller)
|
||||
- Residualrisiko: Akseptabelt nivå dokumenteres
|
||||
|
||||
**Komponent 4: Informasjonsinnsamling fra post-market**
|
||||
- Tilbakemeldingskanal fra deployers og sluttbrukere
|
||||
- Automatisert logging fra systemer i drift (Art. 12)
|
||||
- Periodisk revisjon av risikovurderingen
|
||||
|
||||
### Kontinuerlig oppdatering
|
||||
|
||||
Risikostyringssystemet skal oppdateres ved:
|
||||
- Vesentlige endringer i systemet (Art. 9(2))
|
||||
- Nye indikasjoner på risikoer fra post-market overvåking
|
||||
- Endringer i regelverk eller standarder
|
||||
- Hendelser og nestenulykker rapportert av deployers
|
||||
|
||||
### Sjekkliste — Art. 9 etterlevelse
|
||||
|
||||
- [ ] Formelt risikostyringssystem etablert og dokumentert
|
||||
- [ ] Risikovurdering gjennomført for alle identifiserte bruksscenarioer
|
||||
- [ ] Risikoreduserende tiltak implementert og verifisert
|
||||
- [ ] Resiualrisiko akseptert og dokumentert med begrunnelse
|
||||
- [ ] Procedure for oppdatering av risikovurdering ved endringer
|
||||
- [ ] Ansvarsroller for risikostyring definert (risk owner)
|
||||
- [ ] Integrasjon med post-market overvåking (Art. 72)
|
||||
- [ ] Revisjonssyklus etablert (minst årlig for høyrisiko)
|
||||
|
||||
---
|
||||
|
||||
## Art. 10: Data Governance
|
||||
|
||||
### Treningsdata-krav
|
||||
|
||||
Høyrisiko-AI-systemer som bruker maskinlæring stiller krav til datasetthåndtering:
|
||||
|
||||
**Relevans og representativitet:**
|
||||
- Treningsdata skal være relevante for tiltenkt formål
|
||||
- Data skal dekke variasjoner i input-rom systemet forventes å møte
|
||||
- Geografisk, demografisk og kontekstuell representativitet vurderes
|
||||
|
||||
**Bias-testing (Art. 10(2)(f)):**
|
||||
- Identifiser mulige skjevheter i treningsdata
|
||||
- Dokumenter bias-testingsmetodikk og resultater
|
||||
- Gjennomfør disparate impact-analyse for beskyttede karakteristika
|
||||
- Implementer bias-mitigering og verifiser effekt
|
||||
|
||||
**Datakvalitets-attributter (Art. 10(3)):**
|
||||
- Nøyaktighet — data er korrekte og oppdaterte
|
||||
- Fullstendighet — data dekker nødvendig omfang
|
||||
- Konsistens — ingen motsigende informasjon
|
||||
- Egnethet — data passer for tiltenkt formål
|
||||
|
||||
### Personvern og sikkerhet
|
||||
|
||||
- Treningsdata som inneholder personopplysninger: GDPR artikkel 5, 6, 9 gjelder
|
||||
- Pseudonymisering eller anonymisering der mulig
|
||||
- Oppbevaringsbegrensning: Ikke lenger enn nødvendig for treningsformålet
|
||||
- Tilgangskontroll: Hvem kan se treningsdataene?
|
||||
|
||||
### Dokumentasjonskrav
|
||||
|
||||
- Data governance-policy dokumentert
|
||||
- Kildeliste for treningsdata
|
||||
- Bias-testingsrapport
|
||||
- Data preprocessing-prosedyrer
|
||||
|
||||
---
|
||||
|
||||
## Art. 11: Teknisk Dokumentasjon
|
||||
|
||||
Teknisk dokumentasjon skal utarbeides **før** systemet settes på markedet og holdes oppdatert (Annex IV).
|
||||
|
||||
### 9 påkrevde elementer med eksempler
|
||||
|
||||
**Element 1: Generell systembeskrivelse**
|
||||
Eksempel: "AutomatiskSaksbehandlerFørerkort v2.1 — AI-system for automatisk vurdering av helsekrav ved søknad om førerkort. Deployer: Statens vegvesen. Provider: [Leverandørnavn]. Tiltenkt formål: Behandling av klasse B og BE søknader."
|
||||
|
||||
**Element 2: Design-spesifikasjoner og utviklingsprosess**
|
||||
- Systemarkitektur og komponentoversikt
|
||||
- Teknologivalg og begrunnelse
|
||||
- Treningsmetodikk og parametere
|
||||
- Verifikasjons- og valideringsprosess
|
||||
|
||||
**Element 3: Overvåkings-, drifts- og kontrollsystem**
|
||||
- Ytelsesmetrikker og terskelverdier
|
||||
- Logging-arkitektur
|
||||
- Alarmering og eskaleringsrutiner
|
||||
- Override-mekanismer
|
||||
|
||||
**Element 4: Ytelsesstandarder og metrikker**
|
||||
Eksempel: Nøyaktighet ≥ 97 % på validerte testcase, false positive rate < 2 %, false negative rate < 1 %, forklaring tilgjengelig for alle avslag.
|
||||
|
||||
**Element 5: Forklarlighetsmekanismer (XAI)**
|
||||
- Hvilken forklaringsmetode brukes (SHAP, LIME, attention maps)?
|
||||
- Forklaring tilgjengelig for deployer og sluttbruker?
|
||||
- Begrensninger i forklarlighet dokumentert
|
||||
|
||||
**Element 6: Risikovurdering (Art. 9-referanse)**
|
||||
Oppsummering av risikostyringssystemet med lenke til fullstendig risikovurderingsdokument.
|
||||
|
||||
**Element 7: Endringer i systemets levetid**
|
||||
Endringslogg med beskrivelse av hva som er endret, av hvem, og ny validering gjennomført.
|
||||
|
||||
**Element 8: Samsvarsvurdering**
|
||||
- Referanse til harmoniserte standarder anvendt (f.eks. ISO/IEC 42001)
|
||||
- Samsvarsvurderingsrapport (intern eller tredjepart)
|
||||
- CE-merkingsattest (der relevant)
|
||||
|
||||
**Element 9: Bruksanvisning for deployer (Art. 13)**
|
||||
Fullstendig bruksanvisning inkludert betingelser, begrensninger, ytelse per undergruppe, menneskelig tilsyns-veiledning.
|
||||
|
||||
---
|
||||
|
||||
## Art. 12: Loggføring
|
||||
|
||||
### Automatisk logging
|
||||
|
||||
Høyrisiko-AI-systemer skal ha innebygd kapasitet for automatisk loggføring av hendelser gjennom systemets levetid.
|
||||
|
||||
**Påkrevde loggede hendelser:**
|
||||
- Perioden systemet er i bruk (start/stopp)
|
||||
- Referansedatabase brukt ved kontroll (der relevant)
|
||||
- Input-data som medvirket til beslutning
|
||||
- Identifikasjon av naturlige personer involvert i verifikasjon
|
||||
- Resultater av verifikasjon
|
||||
- Hendelser der operatøren overrider beslutning
|
||||
|
||||
### Oppbevaringsperiode
|
||||
|
||||
**6 måneder** — Art. 12(2) krever minst 6 måneder oppbevaring av logger. Lengre oppbevaring kan kreves av nasjonal lov (f.eks. forvaltningsloven for offentlig sektor i Norge: 3-10 år avhengig av sakstype).
|
||||
|
||||
### Logg-arkitektur for Microsoft-plattformer
|
||||
|
||||
- **Azure AI Services:** Azure Monitor + Application Insights
|
||||
- **Copilot Studio:** Conversation transcripts i Dataverse
|
||||
- **Azure OpenAI:** Diagnostic Logging til Log Analytics Workspace
|
||||
- **Power Automate:** Flow run history + audit log
|
||||
- Alle logger eksporteres til Azure Log Analytics for sentralisert oppbevaring
|
||||
|
||||
---
|
||||
|
||||
## Art. 13: Transparens og bruksinformasjon
|
||||
|
||||
### Bruksinformasjon til deployer
|
||||
|
||||
Provider skal levere tydelig, fullstendig og forståelig bruksanvisning som minimum inneholder:
|
||||
|
||||
- Navn og kontaktinformasjon for provider
|
||||
- Systemets egenskaper, kapabiliteter og tiltenkt formål
|
||||
- Kjente risikoer ved tiltenkt bruk og rimelig forutsigbar feilbruk
|
||||
- Ytelsesmetrikker inkludert nøyaktighets- og feilrater per undergruppe
|
||||
- Input-data krav og betingelser for korrekt drift
|
||||
- Endringer som krever ny samsvarsvurdering
|
||||
- Human oversight-veiledning (Art. 14)
|
||||
- Forventet levetid og vedlikeholdsintervaller
|
||||
|
||||
### Ytelsesgrenser — dokumentasjonskrav
|
||||
|
||||
Dokumenter eksplisitt:
|
||||
- Ytelse på befolkningsgrupper utenfor treningsdata
|
||||
- Ytelsesdegrasjon under distribusjonsskift (distribution shift)
|
||||
- Kjente feilmodi og sannsynlighet
|
||||
- Geografiske eller kontekstuelle begrensninger
|
||||
|
||||
---
|
||||
|
||||
## Art. 14: Menneskelig tilsyn
|
||||
|
||||
### Design for effektiv menneskelig kontroll
|
||||
|
||||
Høyrisiko-AI skal designes slik at menneskelig tilsyn er mulig og effektivt. Systemet skal:
|
||||
|
||||
**Forståelighet:**
|
||||
- Gi forklaringer i menneskelig forståelig form
|
||||
- Indikere konfidensgrad / usikkerhetsgrad
|
||||
- Flagge tilfeller utenfor treningsdistribusjon
|
||||
|
||||
**Detekterbarhet:**
|
||||
- Vise tydelig når systemet er i bruk
|
||||
- Gjøre det enkelt å identifisere feil
|
||||
|
||||
**Override-mekanismer:**
|
||||
- Teknisk mulighet for menneskelig override av alle beslutninger
|
||||
- Override skal logges med begrunnelse
|
||||
- Ingen systemdesign som motvirker eller vanskeliggjør override
|
||||
|
||||
**Eskaleringsmekanismer:**
|
||||
- Definerte terskler for automatisk eskalering til menneskelig behandler
|
||||
- Konfigurerbar flagging av lavkonfidens-saker
|
||||
- Stoppknapp som umiddelbart suspenderer systemet
|
||||
|
||||
---
|
||||
|
||||
## Art. 15: Nøyaktighet, Robusthet og Cybersikkerhet
|
||||
|
||||
### Ytelsesmetrikker
|
||||
|
||||
Provider skal definere og opprettholde:
|
||||
- Overordnet nøyaktighet på validert testdatasett
|
||||
- Nøyaktighet per relevant undergruppe (alder, kjønn, geografi)
|
||||
- Robusthet mot distribusjonsskift og adversarial input
|
||||
- Tilgjengelighet og responstid
|
||||
|
||||
### Testing-regime
|
||||
|
||||
**Pre-deployment:**
|
||||
- Validering på holdout-datasett (separat fra treningsdata)
|
||||
- Adversarial robusthetstesting
|
||||
- Red team-øvelse for høyrisiko-systemer
|
||||
- Disparate impact-analyse
|
||||
|
||||
**Post-deployment:**
|
||||
- Kontinuerlig ytelsesovervåking (concept drift detection)
|
||||
- Periodisk re-validering (kvartalsvis eller ved vesentlige endringer)
|
||||
- A/B-testing ved modelloppdateringer
|
||||
|
||||
### Sikkerhetsoppdateringer
|
||||
|
||||
- Definert policy for sikkerhetsoppdateringer (patch cadence)
|
||||
- Kritiske sårbarheter: Maks 72 timers responstid
|
||||
- Moderate sårbarheter: Maks 30 dager
|
||||
- Kommunikasjonsplikt til deployers ved kritiske oppdateringer
|
||||
|
||||
---
|
||||
|
||||
## Art. 16-27: Kvalitetsstyringssystem (QMS)
|
||||
|
||||
### Komponenter
|
||||
|
||||
Et fullstendig QMS for høyrisiko-AI-provider inkluderer:
|
||||
|
||||
| Komponent | Beskrivelse |
|
||||
|-----------|-------------|
|
||||
| Policy og mål | AI-kvalitetspolicy, risikotoleranse, samsvarsmål |
|
||||
| Organisasjon og ansvar | Roller, ansvar, fullmakter (inkl. AI Officer) |
|
||||
| Kompetanse og opplæring | Opplæringsplan, kompetansekartlegging |
|
||||
| Designkontroll | Krav, design, verifikasjon, validering |
|
||||
| Endringshåndtering | Endringsprosedyre, impact assessment, re-samsvar |
|
||||
| Leverandørkontroll | Krav til underleverandører, revisjon |
|
||||
| Post-market overvåking | Plan, datainnsamling, analyse, rapportering |
|
||||
| Hendelseshåndtering | Prosedyre, rapporteringsplikt (Art. 73), korreksjon |
|
||||
| Intern revisjon | Revisjonsplan, funn, korrigerende tiltak |
|
||||
| Ledelsesgjennomgang | Frekvens, agenda, beslutninger |
|
||||
|
||||
### Auditplan
|
||||
|
||||
- Intern revisjon: Minst én gang per år
|
||||
- Tredjeparts revisjon: Obligatorisk for visse kategorier (Art. 43(1)) — typisk anneks VIII-systemer
|
||||
- Scope: Alle Art. 9-27 krav
|
||||
- Funn: Dokumentert med korrigerende tiltak og frist
|
||||
|
||||
### Korrigerende tiltak
|
||||
|
||||
Prosedyre for korrigerende tiltak skal dekke:
|
||||
1. Identifikasjon av avvik
|
||||
2. Rotårsaksanalyse
|
||||
3. Tiltak og tidsplan
|
||||
4. Effektivitetsverifisering
|
||||
5. Dokumentasjon og lukking
|
||||
|
||||
---
|
||||
|
||||
## Samsvarsvurdering-kalender
|
||||
|
||||
Tidslinje for typisk høyrisiko-AI-system (start: utviklingsoppstart):
|
||||
|
||||
```
|
||||
Måned 0: Systemdesign — risikostyring (Art. 9) og data governance (Art. 10) starter
|
||||
Måned 1-6: Utvikling med innebygd samsvar (privacy by design, logging, forklarlighet)
|
||||
Måned 7: Teknisk dokumentasjon (Art. 11, Annex IV) — første utkast
|
||||
Måned 8: Intern samsvarsvurdering eller notifisert organ (avhengig av kategori)
|
||||
Måned 9: Samsvarserklæring (DoC) utstedt av provider (Art. 47)
|
||||
Måned 9: CE-merking påføres (Art. 48) — der relevant
|
||||
Måned 9: Registrering i EU AI Act-database (Art. 49) — offentlig tilgjengelig
|
||||
Måned 10: Lansering — deployer onboarding med bruksanvisning (Art. 13)
|
||||
Løpende: Post-market overvåking (Art. 72), hendelsesrapportering (Art. 73)
|
||||
Løpende: Logging 6-måneder minimum (Art. 12)
|
||||
Årlig: Revisjon av risikostyringssystem (Art. 9)
|
||||
Årlig: QMS intern revisjon
|
||||
Ved endring: Ny samsvarsvurdering dersom vesentlig endring (Art. 43(4))
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
Bruk denne filen når brukeren er **provider** av et høyrisiko-AI-system, eller vurderer å bygge/tilpasse et AI-system som vil medføre provider-status.
|
||||
|
||||
**Typiske trigger-scenarioer:**
|
||||
- Organisasjonen bygger et AI-system og planlegger å selge/distribuere det
|
||||
- Intern IT-avdeling utvikler system på vegne av etaten (kan bli intern "provider")
|
||||
- Leverandørvurdering: Hva kan du kreve av din AI-leverandør?
|
||||
|
||||
**Viktige avklaringsspørsmål til bruker:**
|
||||
1. Er dere provider eller deployer? (se `ai-act-classification-methodology.md`)
|
||||
2. Hvilken Annex III-kategori er systemet i?
|
||||
3. Kreves tredjeparts samsvarsvurdering (Art. 43(1)) eller er intern tilstrekkelig?
|
||||
|
||||
**Kobling til andre KB-filer:**
|
||||
- Klassifisering → `ai-act-classification-methodology.md`
|
||||
- Deployer-perspektiv → `ai-act-deployer-obligations.md`
|
||||
- FRIA → `ai-act-fria-template.md`
|
||||
- ROS-analyse → `../norwegian-public-sector-governance/ros-*.md`
|
||||
|
||||
**Norsk kontekst:** Nærings- og fiskeridepartementet koordinerer nasjonal implementering. Datatilsynet er sannsynlig tilsynsmyndighet for personverndimensjonen. Nasjonal AI-tilsynsmyndighet er under etablering (per 2026).
|
||||
Loading…
Add table
Add a link
Reference in a new issue