refactor(examples): replace sector-specific example material with generic, fictitious examples
Reference files, test fixtures, the playground demo project and one design document now use generic, fictitious examples (buildings, energy, water, grants, municipal services). The playground demo (17 fixtures plus the embedded demo state) tells one consistent story: a municipal customer chatbot that pre-screens housing-benefit applications, classified under Annex III point 5(a). The embedded demo copies were edited in place rather than regenerated, because they already carry newer AI Act dates than the fixture files. Legal text is unchanged. Test semantics are unchanged. Four dark-theme onboarding screenshots with outdated placeholder text are removed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
parent
ced0c5f46d
commit
544934dc57
77 changed files with 363 additions and 368 deletions
|
|
@ -37,8 +37,8 @@ Systematisk metodikk for klassifisering i fire steg:
|
|||
3. Høyrisiko-sjekk via Annex III (8 kategorier) og Annex I (produktsikkerhet)
|
||||
4. Begrenset/minimal risiko (default)
|
||||
|
||||
For hvert steg: beslutningspunkter, terskelverdier, DDT-eksempler.
|
||||
Inkluder: Annex III full liste på norsk med presiseringer for transport/infrastruktur-sektoren.
|
||||
For hvert steg: beslutningspunkter, terskelverdier, eksempler fra offentlig sektor.
|
||||
Inkluder: Annex III full liste på norsk med presiseringer for offentlig forvaltning.
|
||||
|
||||
#### 1b. `ai-act-provider-obligations.md`
|
||||
Forpliktelser for **tilbydere** (organisasjoner som utvikler/tilpasser AI-systemer):
|
||||
|
|
@ -51,7 +51,7 @@ Forpliktelser for **tilbydere** (organisasjoner som utvikler/tilpasser AI-system
|
|||
- Art. 15: Nøyaktighet, robusthet, cybersikkerhet
|
||||
- Art. 16–27: Kvalitetsstyring, samsvarsvurdering, CE-merking (relevant ved anskaffelse)
|
||||
|
||||
DDT-kontekst: Direktoratet for digital tjenesteutvikling er typisk **deployer**, ikke provider. Men ved intern utvikling på topp av Azure AI/Copilot Studio: provider-rolle.
|
||||
Offentlig kontekst: en typisk offentlig virksomhet er **deployer**, ikke provider. Men ved intern utvikling på topp av Azure AI/Copilot Studio: provider-rolle.
|
||||
|
||||
#### 1c. `ai-act-deployer-obligations.md`
|
||||
Forpliktelser for **deployere** (organisasjoner som tar i bruk AI-systemer):
|
||||
|
|
@ -63,7 +63,7 @@ Forpliktelser for **deployere** (organisasjoner som tar i bruk AI-systemer):
|
|||
- Informasjon til berørte parter
|
||||
- FRIA-plikt for offentlig sektor (Art. 27)
|
||||
|
||||
DDT som deployer: Copilot Studio-agenter, Azure AI Foundry-løsninger, M365 Copilot.
|
||||
Offentlig virksomhet som deployer: Copilot Studio-agenter, Azure AI Foundry-løsninger, M365 Copilot.
|
||||
|
||||
#### 1d. `ai-act-fria-template.md`
|
||||
Fundamental Rights Impact Assessment – **obligatorisk for offentlig sektor** (Art. 27).
|
||||
|
|
@ -98,7 +98,7 @@ Mal for transparensnotiser per Art. 13 og 52:
|
|||
- Art. 52(3): Deepfake-merking
|
||||
- Art. 50: GPAI-modeller – krav til maskinlesbar metadata
|
||||
|
||||
DDT-eksempler: Chatbot på ddt.no, AI i saksbehandling.
|
||||
Eksempler: Chatbot på virksomhetens nettsted, AI i saksbehandling.
|
||||
|
||||
#### 1g. `ai-act-microsoft-tools-mapping.md`
|
||||
Kartlegging av Microsoft-verktøy mot AI Act-krav:
|
||||
|
|
@ -148,7 +148,7 @@ tools:
|
|||
**Hjemmel:** Annex III, kategori X – [beskrivelse]
|
||||
|
||||
## Rolle
|
||||
**DDT som:** [Provider / Deployer / Begge]
|
||||
**Virksomheten som:** [Provider / Deployer / Begge]
|
||||
|
||||
## Forpliktelser
|
||||
### Umiddelbart (innen 2026-08-02)
|
||||
|
|
@ -269,7 +269,7 @@ Legg til i review-sjekklisten:
|
|||
```
|
||||
EU AI Act Conformity Check (kjøres automatisk hvis systemet er AI-basert):
|
||||
□ Er systemet klassifisert mot Annex III?
|
||||
□ Er DDTs rolle (provider/deployer) avklart?
|
||||
□ Er virksomhetens rolle (provider/deployer) avklart?
|
||||
□ Er teknisk dokumentasjon (Annex IV) påbegynt?
|
||||
□ Er Art. 14 menneskelig tilsyn implementert i arkitekturen?
|
||||
□ Er logging (Art. 12/26) designet inn – ikke ettermontering?
|
||||
|
|
@ -394,15 +394,15 @@ I eksport-formater (steg 5) – legg til AI Act-output alternativ:
|
|||
### STEG 8: Opprett tester
|
||||
|
||||
#### 8a. `tests/fixtures/ai-act/fixture.md`
|
||||
Test-case: Fiktivt AI-system hos DDT
|
||||
Test-case: Fiktivt AI-system hos Acme Kommune
|
||||
|
||||
```markdown
|
||||
# Test-system: FartsPrediksjonsagent
|
||||
Formål: Predikere trafikkfart på E6 ved hjelp av historisk og sanntids-data
|
||||
# Test-system: Energiprognoseagent
|
||||
Formål: Predikere energiforbruk i kommunale formålsbygg ved hjelp av historisk og sanntids-data
|
||||
Teknologi: Azure Machine Learning, python-modell, REST API
|
||||
Brukere: Intern trafikkovervåking, ingen direkte borgerinteraksjon
|
||||
Data: GPS-data fra biler, kameraer, sensorer (anonymisert)
|
||||
Sektor: Transport og infrastruktur
|
||||
Brukere: Interne energirådgivere, ingen direkte borgerinteraksjon
|
||||
Data: Måledata fra energimålere og bygningssensorer (ingen persondata)
|
||||
Sektor: Energi og eiendom
|
||||
```
|
||||
|
||||
Forventet output: Klassifisert som "Begrenset/Minimal" (ikke Annex III, ikke direkte borgerimpakt)
|
||||
|
|
@ -412,10 +412,10 @@ Test-case: Høyrisiko-system
|
|||
|
||||
```markdown
|
||||
# Test-system: AutomatiskSaksbehandler
|
||||
Formål: Automatisk vurdering av dispensasjonssøknader (kjøretillatelser)
|
||||
Formål: Automatisk vurdering av søknader om tilskudd
|
||||
Teknologi: Azure OpenAI GPT-4, Copilot Studio
|
||||
Brukere: Borgere sender søknad, AI gir innstilling til saksbehandler
|
||||
Data: Persondata, helseopplysninger (ved dispensasjon)
|
||||
Data: Persondata, inntektsopplysninger
|
||||
Sektor: Offentlig forvaltning
|
||||
```
|
||||
|
||||
|
|
@ -478,11 +478,11 @@ Verifiser at alle eksisterende tester fortsatt passerer.
|
|||
|
||||
1. **Sekvens er uforanderlig**: AI Act → DPIA → ROS. Aldri omgå dette.
|
||||
|
||||
2. **DDT er typisk deployer**, ikke provider. Men ved intern utvikling (Copilot Studio-agenter bygget internt): provider-rolle. Agenten skal avklare dette eksplisitt.
|
||||
2. **En offentlig virksomhet er typisk deployer**, ikke provider. Men ved intern utvikling (Copilot Studio-agenter bygget internt): provider-rolle. Agenten skal avklare dette eksplisitt.
|
||||
|
||||
3. **FRIA er obligatorisk for offentlig sektor** ved høyrisiko-systemer. Ikke valgfritt.
|
||||
|
||||
4. **Fristen 2026-08-02 er 162 dager unna** (per 2026-02-22). DDT må ha klassifisert alle høyrisiko-systemer og ha GPAI-compliance på plass innen da.
|
||||
4. **Fristen 2026-08-02 er 162 dager unna** (per 2026-02-22). Virksomheten må ha klassifisert alle høyrisiko-systemer og ha GPAI-compliance på plass innen da.
|
||||
|
||||
5. **Ikke overskriv eksisterende KB-filer**: `ai-act-compliance-guide.md` og `ai-act-annex-iii-checklist.md` er komplette. Referer til dem, ikke erstatt dem.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue