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
SSH key fingerprint:
SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q
77 changed files with 363 additions and 368 deletions
|
|
@ -248,27 +248,27 @@
|
|||
"reports": {
|
||||
"classify": {
|
||||
"input": {},
|
||||
"raw_markdown": "# EU AI Act — Klassifisering: Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nBeskrivelse: AI-system som identifiserer objekter som krever oppfølging via sensordata + objektregister\n\n## Risikonivå\n\nRisk-level: høy\n\n## Rolle\n\nRolle: Provider og Deployer (utvikler internt + drifter selv)\n\n## Begrunnelse\n\nReasoning: Systemet brukes av offentlig myndighet for håndheving av lov, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for håndtering. Dette plasserer systemet under Annex III, punkt 6 (rettshåndhevelse) og krever full høyrisiko-compliance per Art. 6(2).\n\n## Forpliktelser\n\n- Risk management system per Art. 9\n- Data governance og -kvalitet per Art. 10\n- Teknisk dokumentasjon per Art. 11\n- Logging og sporbarhet per Art. 12\n- Transparens overfor deployer per Art. 13\n- Menneskelig oversikt per Art. 14\n- Robusthet, sikkerhet og nøyaktighet per Art. 15\n- FRIA (Fundamental Rights Impact Assessment) per Art. 27 — obligatorisk for offentlig sektor\n- Registrering i EU-database per Art. 49\n- Conformity assessment per Art. 43\n\n## Frist\n\nFull compliance innen 2027-12-02 (Annex III høyrisiko full compliance, utsatt fra 2026-08-02).\n"
|
||||
"raw_markdown": "# EU AI Act — Klassifisering: Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nBeskrivelse: Innbyggerchatbot som svarer på henvendelser og forhåndsvurderer søknader om kommunal bostøtte via vedleggstolkning + oppslag i fagsystemet\n\n## Risikonivå\n\nRisk-level: høy\n\n## Rolle\n\nRolle: Provider og Deployer (utvikler internt + drifter selv)\n\n## Begrunnelse\n\nReasoning: Systemet brukes av offentlig myndighet til å vurdere om innbyggere har rett til en offentlig ytelse, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for saksbehandlingen. Dette plasserer systemet under Annex III, punkt 5(a) (tilgang til offentlige ytelser og tjenester) og krever full høyrisiko-compliance per Art. 6(2).\n\n## Forpliktelser\n\n- Risk management system per Art. 9\n- Data governance og -kvalitet per Art. 10\n- Teknisk dokumentasjon per Art. 11\n- Logging og sporbarhet per Art. 12\n- Transparens overfor deployer per Art. 13\n- Menneskelig oversikt per Art. 14\n- Robusthet, sikkerhet og nøyaktighet per Art. 15\n- FRIA (Fundamental Rights Impact Assessment) per Art. 27 — obligatorisk for offentlig sektor\n- Registrering i EU-database per Art. 49\n- Conformity assessment per Art. 43\n\n## Frist\n\nFull compliance innen 2027-12-02 (Annex III høyrisiko full compliance, utsatt fra 2026-08-02).\n"
|
||||
},
|
||||
"requirements": {
|
||||
"input": {},
|
||||
"raw_markdown": "# EU AI Act — Krav for høyrisiko provider+deployer\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nKlassifisering: høy risiko, rolle Provider+Deployer\n\n## Krav\n\n| Krav | Status | Kilde |\n|------|--------|-------|\n| Risk Management System etablert og dokumentert | partial | Art. 9 |\n| Treningsdata-governance med kvalitetssjekker | met | Art. 10 |\n| Teknisk dokumentasjon (Annex IV) komplett | partial | Art. 11 |\n| Automatisk logging av hendelser implementert | met | Art. 12 |\n| Transparens-instruksjoner for deployer skrevet | missing | Art. 13 |\n| Human-in-the-loop på alle sanksjonsavgjørelser | met | Art. 14 |\n| Nøyaktighetsmål med stratifisert testing | partial | Art. 15 |\n| Cybersikkerhetstiltak verifisert (NSM Grunnprinsipper) | met | Art. 15 |\n| FRIA gjennomført før idriftsettelse | missing | Art. 27 |\n| Registrering i EU-database planlagt | missing | Art. 49 |\n| Conformity assessment per Annex VI gjennomført | missing | Art. 43 |\n| CE-merking utført før markedsføring | missing | Art. 48 |\n| Post-market monitoring system etablert | partial | Art. 72 |\n| Avviksrapportering til myndigheter rutinert | partial | Art. 73 |\n\n## Sammendrag\n\n- 4 krav er møtt (met)\n- 4 krav er delvis møtt (partial)\n- 6 krav mangler implementering (missing)\n\nPrioritering: FRIA og transparens-instruksjoner må adresseres før idriftsettelse 2027-12-02.\n"
|
||||
"raw_markdown": "# EU AI Act — Krav for høyrisiko provider+deployer\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nKlassifisering: høy risiko, rolle Provider+Deployer\n\n## Krav\n\n| Krav | Status | Kilde |\n|------|--------|-------|\n| Risk Management System etablert og dokumentert | partial | Art. 9 |\n| Treningsdata-governance med kvalitetssjekker | met | Art. 10 |\n| Teknisk dokumentasjon (Annex IV) komplett | partial | Art. 11 |\n| Automatisk logging av hendelser implementert | met | Art. 12 |\n| Transparens-instruksjoner for deployer skrevet | missing | Art. 13 |\n| Human-in-the-loop på alle vedtak om avslag | met | Art. 14 |\n| Nøyaktighetsmål med stratifisert testing | partial | Art. 15 |\n| Cybersikkerhetstiltak verifisert (NSM Grunnprinsipper) | met | Art. 15 |\n| FRIA gjennomført før idriftsettelse | missing | Art. 27 |\n| Registrering i EU-database planlagt | missing | Art. 49 |\n| Conformity assessment per Annex VI gjennomført | missing | Art. 43 |\n| CE-merking utført før markedsføring | missing | Art. 48 |\n| Post-market monitoring system etablert | partial | Art. 72 |\n| Avviksrapportering til myndigheter rutinert | partial | Art. 73 |\n\n## Sammendrag\n\n- 4 krav er møtt (met)\n- 4 krav er delvis møtt (partial)\n- 6 krav mangler implementering (missing)\n\nPrioritering: FRIA og transparens-instruksjoner må adresseres før idriftsettelse 2027-12-02.\n"
|
||||
},
|
||||
"transparency": {
|
||||
"input": {},
|
||||
"raw_markdown": "# Transparensnotis — Acme Kunde-chatbot\n\nTittel: Informasjon om automatisert operasjonell analyse (Art. 13 og Art. 50)\n\n## Hva systemet gjør\n\nAcme Kommune bruker et AI-system som leser av objekt-ID (Acme Kunde-chatbot — automatisert klassifisering) fra sensordata langs produksjonsmiljøet. Systemet identifiserer objekter som har overtrådt terskelverdi gjennom å beregne gjennomsnittlig respons mellom to datapunkt.\n\n## Hvilke data som behandles\n\nBehandlede data inkluderer objekt-ID, tidsstempel, datapunkt, objektklasse og oppslag i Acme Kommune objektregister. Personlig identifiserbar informasjon kobles ikke til oppføring uten saksbehandler eksplisitte godkjenning.\n\n## Hvordan beslutninger tas\n\nSystemet er beslutningsstøtte, ikke -taker. Hver flagged hendelse går til menneskelig saksbehandler som tar endelig avgjørelse om gebyr eller anmeldelse. AI-output inkluderer konfidensgrad og forklaring av hvorfor saken ble flagget.\n\n## Dine rettigheter\n\nSom registrert har du rett til innsyn (GDPR Art. 15), retting (Art. 16), sletting (Art. 17 — med begrensninger ved lovhjemmel), og å klage til Datatilsynet. Du kan også be om manuell vurdering uten AI-bistand per GDPR Art. 22.\n\n## Kontakt\n\nPersonvernombud: pvo@Acme.no\nTilsyn: Datatilsynet — postkasse@datatilsynet.no\nEU AI Act-tilsyn: under etablering (Digitaliseringsdirektoratet er forventet)\n"
|
||||
"raw_markdown": "# Transparensnotis — Acme Kunde-chatbot\n\nTittel: Informasjon om automatisert forhåndsvurdering av søknader (Art. 13 og Art. 50)\n\n## Hva systemet gjør\n\nAcme Kommune bruker et AI-system (Acme Kunde-chatbot) som svarer på spørsmål om kommunale tjenester og leser vedlegg du laster opp med en søknad om bostøtte. Systemet vurderer om søknaden er komplett, og om inntekt og boutgifter ser ut til å ligge innenfor vilkårene.\n\n## Hvilke data som behandles\n\nBehandlede data inkluderer det du skriver i chatten, opplastede vedlegg, saksnummer, tidsstempel og oppslag i Acme Kommunes fagsystem for bostøtte. Samtalen kobles ikke til søknaden din uten at du samtykker til det i chatten.\n\n## Hvordan beslutninger tas\n\nSystemet er beslutningsstøtte, ikke -taker. Hver flaggede søknad går til en menneskelig saksbehandler som fatter vedtaket. AI-output inkluderer konfidensgrad og forklaring av hvorfor saken ble flagget.\n\n## Dine rettigheter\n\nSom registrert har du rett til innsyn (GDPR Art. 15), retting (Art. 16), sletting (Art. 17 — med begrensninger ved lovhjemmel), og å klage til Datatilsynet. Du kan også be om manuell vurdering uten AI-bistand per GDPR Art. 22.\n\n## Kontakt\n\nPersonvernombud: pvo@Acme.no\nTilsyn: Datatilsynet — postkasse@datatilsynet.no\nEU AI Act-tilsyn: under etablering (Digitaliseringsdirektoratet er forventet)\n"
|
||||
},
|
||||
"frimpact": {
|
||||
"input": {},
|
||||
"raw_markdown": "# FRIA (Fundamental Rights Impact Assessment) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nHjemmel: EU AI Act Art. 27 (obligatorisk for offentlig sektor)\n\n## Vurderte rettigheter\n\n| Rettighet | Impact | Tiltak |\n|-----------|--------|--------|\n| Menneskeverd | 1 | Ingen reduksjon — saksbehandler tar endelig avgjørelse, ikke AI |\n| Rett til frihet og sikkerhet | 1 | Ingen frihetsberøvelse direkte fra AI; politi/domstol er reell beslutter |\n| Respekt for privatliv | 4 | Massiv overvåking via veikameraer — kompenseres med strenge oppbevaringsregler (90 dager), formålsbegrensning, og minimering av kobling til objektregister |\n| Personvern | 4 | DPIA gjennomført; Datatilsynet konsultert; rettslig grunnlag i interne retningslinjer §13 — likevel høy impact pga skala |\n| Ikke-diskriminering | 3 | Algoritmisk bias-testing på objekt-ID fra utenlandske registre (lavere Acme Kunde-chatbot-nøyaktighet) — kvartalsvis review |\n| Ytringsfrihet og informasjonsfrihet | 0 | Ikke berørt |\n| Forsamlingsfrihet | 0 | Ikke berørt |\n| Religionsfrihet | 0 | Ikke berørt |\n| Eiendomsrett | 2 | Gebyr/sanksjoner berører eiendomsrett — kompenseres med klagemulighet og rettslig prøving |\n| Rett til effektivt rettsmiddel | 2 | Klageadgang sikret; menneskelig review garantert; AI-forklaring tilgjengelig for klager |\n| Barns rettigheter | 1 | Lav direkte påvirkning; barn er sjelden registrerte førere |\n| Eldres rettigheter | 2 | Eldre kan ha vanskeligere for å klage digitalt — papir-klage må fortsatt være tilgjengelig |\n\n## Konklusjon\n\nTre rettigheter har høy impact (3-4): privatliv, personvern og ikke-diskriminering. Tiltakene reduserer reell risiko, men FRIA må re-evalueres årlig per Art. 27(2).\n"
|
||||
"raw_markdown": "# FRIA (Fundamental Rights Impact Assessment) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nHjemmel: EU AI Act Art. 27 (obligatorisk for offentlig sektor)\n\n## Vurderte rettigheter\n\n| Rettighet | Impact | Tiltak |\n|-----------|--------|--------|\n| Menneskeverd | 1 | Ingen reduksjon — saksbehandler tar endelig avgjørelse, ikke AI |\n| Rett til frihet og sikkerhet | 0 | Ikke berørt — systemet vurderer bare søknader om en økonomisk ytelse |\n| Respekt for privatliv | 4 | Samtaler og vedlegg inneholder ofte helse-, familie- og økonomiopplysninger som innbyggere oppgir fritt — kompenseres med strenge oppbevaringsregler (90 dager for samtalelogger), formålsbegrensning, og minimering av kobling til fagsystemet |\n| Personvern | 4 | DPIA gjennomført; Datatilsynet konsultert; rettslig grunnlag i interne retningslinjer §13 — likevel høy impact pga skala |\n| Ikke-diskriminering | 3 | Algoritmisk bias-testing på henvendelser og vedlegg på andre språk enn norsk (lavere tolkningsnøyaktighet) — kvartalsvis review |\n| Ytringsfrihet og informasjonsfrihet | 0 | Ikke berørt |\n| Forsamlingsfrihet | 0 | Ikke berørt |\n| Religionsfrihet | 0 | Ikke berørt |\n| Rett til sosial sikring | 2 | Feilaktig forhåndsvurdering kan forsinke en ytelse — kompenseres med at saksbehandler vurderer hver søknad, og med klagemulighet |\n| Rett til effektivt rettsmiddel | 2 | Klageadgang sikret; menneskelig review garantert; AI-forklaring tilgjengelig for klager |\n| Barns rettigheter | 1 | Lav direkte påvirkning; barn søker ikke selv, men bor i husstander som søker |\n| Eldres rettigheter | 2 | Eldre kan ha vanskeligere for å klage digitalt — papir-klage må fortsatt være tilgjengelig |\n\n## Konklusjon\n\nTre rettigheter har høy impact (3-4): privatliv, personvern og ikke-diskriminering. Tiltakene reduserer reell risiko, men FRIA må re-evalueres årlig per Art. 27(2).\n"
|
||||
},
|
||||
"conformity": {
|
||||
"input": {},
|
||||
"raw_markdown": "# Samsvarsvurdering (Art. 43) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsprosedyre: Annex VI (intern kontroll)\n\n## Sjekkliste\n\n| Krav | Status | Bevis |\n|------|--------|-------|\n| Risk Management System dokumentert | bestått | RMS-rapport v2.1 (2026-04-15) |\n| Treningsdata-governance med kvalitetskriterier | bestått | Data-governance handbook §4.2 |\n| Teknisk dokumentasjon Annex IV komplett | betinget | Mangler ytelsesmål per stratum |\n| Logging av hendelser implementert | bestått | OpenTelemetry-spans i Azure Monitor |\n| Transparens-instruksjoner skrevet | avvist | Skal leveres innen 2026-09-01 |\n| Menneskelig oversikt på saksbehandler | bestått | Workflow-design godkjent av juridisk |\n| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per objekt-ID-region |\n| Robusthet under adversarielle forhold | betinget | Test-suite mangler skitne plater og natt-scenarier |\n| Cybersikkerhetstiltak per Art. 15 | bestått | NSM Grunnprinsipper-vurdering bestått |\n| Conformity assessment underskrevet | avvist | Avhengig av FRIA-resultat |\n| EU declaration of conformity utstedt | avvist | Avhenger av Art. 47 |\n| CE-merking påført | avvist | Markedsplassering ikke aktuell (intern bruk) — vurder om Art. 48 gjelder |\n\n## Frister\n\n| Dato | Milepæl | Status |\n|------|---------|--------|\n| 2026-08-02 | Transparens (Art. 50) | upcoming |\n| 2026-09-01 | Transparens-instruksjoner ferdigstilt | upcoming |\n| 2027-02-01 | FRIA og DPIA-revisjon | upcoming |\n| 2027-12-02 | Full Annex III høyrisiko-compliance (utsatt fra 2026-08-02) | upcoming |\n\n## Konklusjon\n\n5 av 12 krav er fullt møtt; 4 er delvis møtt; 3 mangler implementering. Critical path: transparens-instruksjoner (Art. 13) blokkerer conformity declaration.\n"
|
||||
"raw_markdown": "# Samsvarsvurdering (Art. 43) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsprosedyre: Annex VI (intern kontroll)\n\n## Sjekkliste\n\n| Krav | Status | Bevis |\n|------|--------|-------|\n| Risk Management System dokumentert | bestått | RMS-rapport v2.1 (2026-04-15) |\n| Treningsdata-governance med kvalitetskriterier | bestått | Data-governance handbook §4.2 |\n| Teknisk dokumentasjon Annex IV komplett | betinget | Mangler ytelsesmål per stratum |\n| Logging av hendelser implementert | bestått | OpenTelemetry-spans i Azure Monitor |\n| Transparens-instruksjoner skrevet | avvist | Skal leveres innen 2026-09-01 |\n| Menneskelig oversikt på saksbehandler | bestått | Workflow-design godkjent av juridisk |\n| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per språkgruppe |\n| Robusthet under adversarielle forhold | betinget | Test-suite mangler skannede, skjeve og håndskrevne vedlegg |\n| Cybersikkerhetstiltak per Art. 15 | bestått | NSM Grunnprinsipper-vurdering bestått |\n| Conformity assessment underskrevet | avvist | Avhengig av FRIA-resultat |\n| EU declaration of conformity utstedt | avvist | Avhenger av Art. 47 |\n| CE-merking påført | avvist | Markedsplassering ikke aktuell (intern bruk) — vurder om Art. 48 gjelder |\n\n## Frister\n\n| Dato | Milepæl | Status |\n|------|---------|--------|\n| 2026-08-02 | Transparens (Art. 50) | upcoming |\n| 2026-09-01 | Transparens-instruksjoner ferdigstilt | upcoming |\n| 2027-02-01 | FRIA og DPIA-revisjon | upcoming |\n| 2027-12-02 | Full Annex III høyrisiko-compliance (utsatt fra 2026-08-02) | upcoming |\n\n## Konklusjon\n\n5 av 12 krav er fullt møtt; 4 er delvis møtt; 3 mangler implementering. Critical path: transparens-instruksjoner (Art. 13) blokkerer conformity declaration.\n"
|
||||
},
|
||||
"dpia": {
|
||||
"input": {},
|
||||
"raw_markdown": "# DPIA / PVK — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: Datatilsynets veileder + ISO/IEC 29134\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Feilaktig objekt-ID-tolkning fører til urettmessig sanksjon | 3 | 4 | 12 | medium |\n| Massiv lokasjonsdata-lekkasje fra objektregister | 2 | 5 | 10 | medium |\n| AI-forklaring viser sensitiv kontekst om eier | 3 | 3 | 9 | medium |\n| Stratifisert bias mot utenlandske objekt-ID | 4 | 3 | 12 | medium |\n| Fysisk angrep på sensordata skaper deteksjonshull | 2 | 2 | 4 | low |\n| Insider-misbruk for sporing av enkeltpersoner | 2 | 5 | 10 | medium |\n| Auto-flagging utløser kjedereaksjon ved system-feil | 1 | 5 | 5 | low |\n| Subject Access Request (GDPR Art. 15) ignoreres | 3 | 3 | 9 | medium |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-001 | Feilaktig OCR av objekt-ID | high | Konfidensgrad-cutoff på 0.95; saksbehandler-review under cutoff |\n| T-002 | Lokasjonsdata-lekkasje | critical | Pseudonymisering ved lagring; HSM-backed nøkler i Azure Key Vault |\n| T-003 | Kontekst-eksponering i AI-forklaring | high | Filter på sensitive felt; kontekst kun til autorisert saksbehandler |\n| T-004 | Bias mot utenlandske registre | high | Kvartalsvis stratifisert testing; juster modell ved >5% avvik |\n| T-005 | Insider-misbruk | critical | Audit-logging på alle oppslag; SIEM-deteksjon av unormale mønstre |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-001 | Cutoff-konfidensgrad implementert | done | Tech Lead |\n| M-002 | Pseudonymisering pilotert | in-progress | Sikkerhetsarkitekt |\n| M-003 | Bias-test-pipeline etablert | planned | Data Scientist |\n| M-004 | Audit-logging utrullet | done | Drift |\n| M-005 | SIEM-regler kalibrert | in-progress | SOC |\n\n## Konklusjon\n\nRestrisiko: 4×3 → 2×2\n\nRestrisiko etter tiltak: medium-lav. DPIA godkjent av Datatilsynet 2026-04-22.\n"
|
||||
"raw_markdown": "# DPIA / PVK — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: Datatilsynets veileder + ISO/IEC 29134\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Feilaktig vedleggstolkning fører til urettmessig avslag | 3 | 4 | 12 | medium |\n| Massiv lekkasje av økonomiopplysninger fra fagsystemet | 2 | 5 | 10 | medium |\n| AI-forklaring viser sensitiv kontekst om søker | 3 | 3 | 9 | medium |\n| Stratifisert bias mot henvendelser på andre språk | 4 | 3 | 12 | medium |\n| Manipulerte vedlegg skaper vurderingshull | 2 | 2 | 4 | low |\n| Insider-misbruk for oppslag på enkeltpersoner | 2 | 5 | 10 | medium |\n| Auto-flagging utløser kjedereaksjon ved system-feil | 1 | 5 | 5 | low |\n| Subject Access Request (GDPR Art. 15) ignoreres | 3 | 3 | 9 | medium |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-001 | Feilaktig OCR av vedlegg | high | Konfidensgrad-cutoff på 0.95; saksbehandler-review under cutoff |\n| T-002 | Lekkasje av økonomiopplysninger | critical | Pseudonymisering ved lagring; HSM-backed nøkler i Azure Key Vault |\n| T-003 | Kontekst-eksponering i AI-forklaring | high | Filter på sensitive felt; kontekst kun til autorisert saksbehandler |\n| T-004 | Bias mot henvendelser på andre språk | high | Kvartalsvis stratifisert testing; juster modell ved >5% avvik |\n| T-005 | Insider-misbruk | critical | Audit-logging på alle oppslag; SIEM-deteksjon av unormale mønstre |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-001 | Cutoff-konfidensgrad implementert | done | Tech Lead |\n| M-002 | Pseudonymisering pilotert | in-progress | Sikkerhetsarkitekt |\n| M-003 | Bias-test-pipeline etablert | planned | Data Scientist |\n| M-004 | Audit-logging utrullet | done | Drift |\n| M-005 | SIEM-regler kalibrert | in-progress | SOC |\n\n## Konklusjon\n\nRestrisiko: 4×3 → 2×2\n\nRestrisiko etter tiltak: medium-lav. DPIA godkjent av Datatilsynet 2026-04-22.\n"
|
||||
},
|
||||
"security": {
|
||||
"input": {},
|
||||
|
|
@ -276,23 +276,23 @@
|
|||
},
|
||||
"ros": {
|
||||
"input": {},
|
||||
"raw_markdown": "# ROS-analyse — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Modell-drift som degraderer nøyaktighet | 4 | 3 | 12 | medium |\n| Treningsdata-bias mot småbiler eller MC | 3 | 3 | 9 | medium |\n| Adversarielle plate-design unngår OCR | 2 | 4 | 8 | medium |\n| API-utilgjengelighet i kritisk periode | 2 | 4 | 8 | medium |\n| Klage-saksbehandling overbelastet ved skalering | 4 | 3 | 12 | medium |\n| Datatap pga manglende georedundans | 1 | 5 | 5 | low |\n| Misbruk av AI-forklaring som bevis | 3 | 4 | 12 | medium |\n| Kjedevirkning ved feil i objektregister | 2 | 5 | 10 | medium |\n\n## Radar-akser (7 dimensjoner)\n\n| Akse | Score (1-5) |\n|------|-------------|\n| Tilgjengelighet | 4 |\n| Konfidensialitet | 4 |\n| Integritet | 4 |\n| Sporbarhet | 5 |\n| Pålitelighet | 3 |\n| Robusthet | 3 |\n| Etterlevelse | 4 |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-101 | Modell-drift over tid | high | Månedlig retraining-pipeline; alarm ved >2% nøyaktighetsfall |\n| T-102 | Bias mot småbiler/MC | high | Stratifisert evaluering ved hver release |\n| T-103 | Adversarielle plate-design | medium | Robusthetstest mot kjente angreps-mønstre |\n| T-104 | API-utilgjengelighet | medium | Multi-region failover med RTO 1t |\n| T-105 | Saksbehandlings-overbelastning | high | Automatisk batching + prioriteringsregler |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-101 | Retraining-pipeline etablert | done | MLOps |\n| M-102 | Stratifisert evalueringssett bygget | in-progress | Data Scientist |\n| M-103 | Robusthetstest planlagt | planned | Sikkerhetsarkitekt |\n| M-104 | Multi-region failover testet | done | Drift |\n| M-105 | Batching-logikk implementert | in-progress | Tech Lead |\n\n## Top-risikoer\n\n| ID | Trussel | Score | Severity |\n|----|---------|-------|----------|\n| T-101 | Modell-drift over tid | 12 | high |\n| T-105 | Saksbehandlings-overbelastning | 12 | high |\n| T-107 | Misbruk av AI-forklaring som bevis | 12 | high |\n| T-108 | Kjedevirkning ved feil i objektregister | 10 | high |\n| T-103 | Bias mot småbiler/MC | 9 | medium |\n\nRestrisiko: 4×3 → 2×2\n\n## Anbefaling\n\nROS godkjent av seksjonsleder 2026-04-25 forutsatt at M-103 (robusthetstest) ferdigstilles innen 2026-06-15. Re-evaluering ved hver modell-release eller ved endring i sak-volum > 20%.\n\n## Konklusjon\n\nRestrisiko etter tiltak: medium. ROS godkjent av seksjonsleder 2026-04-25.\n"
|
||||
"raw_markdown": "# ROS-analyse — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Modell-drift som degraderer nøyaktighet | 4 | 3 | 12 | medium |\n| Treningsdata-bias mot nynorsk og andre språk | 3 | 3 | 9 | medium |\n| Manipulerte vedlegg unngår OCR-kontroll | 2 | 4 | 8 | medium |\n| API-utilgjengelighet i kritisk periode | 2 | 4 | 8 | medium |\n| Klage-saksbehandling overbelastet ved skalering | 4 | 3 | 12 | medium |\n| Datatap pga manglende georedundans | 1 | 5 | 5 | low |\n| Misbruk av AI-forklaring som vedtaksbegrunnelse | 3 | 4 | 12 | medium |\n| Kjedevirkning ved feil i fagsystemet | 2 | 5 | 10 | medium |\n\n## Radar-akser (7 dimensjoner)\n\n| Akse | Score (1-5) |\n|------|-------------|\n| Tilgjengelighet | 4 |\n| Konfidensialitet | 4 |\n| Integritet | 4 |\n| Sporbarhet | 5 |\n| Pålitelighet | 3 |\n| Robusthet | 3 |\n| Etterlevelse | 4 |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-101 | Modell-drift over tid | high | Månedlig retraining-pipeline; alarm ved >2% nøyaktighetsfall |\n| T-102 | Bias mot nynorsk og andre språk | high | Stratifisert evaluering ved hver release |\n| T-103 | Manipulerte vedlegg | medium | Robusthetstest mot kjente angreps-mønstre |\n| T-104 | API-utilgjengelighet | medium | Multi-region failover med RTO 1t |\n| T-105 | Saksbehandlings-overbelastning | high | Automatisk batching + prioriteringsregler |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-101 | Retraining-pipeline etablert | done | MLOps |\n| M-102 | Stratifisert evalueringssett bygget | in-progress | Data Scientist |\n| M-103 | Robusthetstest planlagt | planned | Sikkerhetsarkitekt |\n| M-104 | Multi-region failover testet | done | Drift |\n| M-105 | Batching-logikk implementert | in-progress | Tech Lead |\n\n## Top-risikoer\n\n| ID | Trussel | Score | Severity |\n|----|---------|-------|----------|\n| T-101 | Modell-drift over tid | 12 | high |\n| T-105 | Saksbehandlings-overbelastning | 12 | high |\n| T-107 | Misbruk av AI-forklaring som vedtaksbegrunnelse | 12 | high |\n| T-108 | Kjedevirkning ved feil i fagsystemet | 10 | high |\n| T-103 | Bias mot nynorsk og andre språk | 9 | medium |\n\nRestrisiko: 4×3 → 2×2\n\n## Anbefaling\n\nROS godkjent av seksjonsleder 2026-04-25 forutsatt at M-103 (robusthetstest) ferdigstilles innen 2026-06-15. Re-evaluering ved hver modell-release eller ved endring i sak-volum > 20%.\n\n## Konklusjon\n\nRestrisiko etter tiltak: medium. ROS godkjent av seksjonsleder 2026-04-25.\n"
|
||||
},
|
||||
"review": {
|
||||
"input": {},
|
||||
"raw_markdown": "# Arkitekturgjennomgang — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\nReviewers: AI-arkitekt, sikkerhetsarkitekt, Datatilsynet\n\n## Funn\n\n| ID | Severity | Status | Lokasjon | Anbefaling |\n|----|----------|--------|----------|------------|\n| F-01 | critical | remove | Authentication layer | Tilgang til AI-forklaringer mangler attribute-based access control — alle saksbehandler ser alle saker. Implementer ABAC basert på sak-tildeling. |\n| F-02 | high | review | Data pipeline | Treningsdata oppdateres månedlig, men ingen formell drift-deteksjon. Etabler statistisk drift-monitoring i Azure Monitor. |\n| F-03 | high | review | Model serving | Modellen serves fra en enkelt regional endpoint uten failover. Replikér til en sekundær region for RTO < 1t. |\n| F-04 | high | review | Logging | Audit-logg lagres 30 dager — under arkivlovens krav for sak-relevant info. Endre retensjon til 7 år for sak-knyttede oppslag. |\n| F-05 | medium | keep | Cost management | Ingen budsjettalarmer på Azure AI Services — prediction-kostnaden kan øke med 4× ved belastnings-topper uten varsel. |\n| F-06 | medium | review | Compliance | FRIA-rapport ikke vedlikeholdt etter modell-endring 2026-03-12. Re-evaluering trengs. |\n| F-07 | medium | keep | UX | saksbehandler-grensesnitt viser ikke konfidensgrad tydelig nok — risiko for over-trust på AI-output. |\n| F-08 | low | suppressed | Documentation | README mangler oppdatert arkitekturdiagram (siste fra 2025-11). |\n| F-09 | low | suppressed | Testing | Manglende E2E-test for utenlandske objekt-ID. |\n\n## Sammendrag\n\nCritical (1): ABAC mangler — må fikses før idriftsettelse.\nHigh (3): Drift-deteksjon, failover, logg-retensjon — må fikses innen 6 mnd.\nMedium (3): Budsjett, FRIA-revisjon, UX-konfidens — bør fikses innen 12 mnd.\nLow (2): Dokumentasjon, testing — opportunity-quality.\n\n## Anbefaling\n\nIdriftsettelse anbefales IKKE før F-01 er løst. F-02 til F-04 må adresseres innen 2026-09-01 for å holde 2027-12-02-fristen.\n"
|
||||
"raw_markdown": "# Arkitekturgjennomgang — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\nReviewers: AI-arkitekt, sikkerhetsarkitekt, Datatilsynet\n\n## Funn\n\n| ID | Severity | Status | Lokasjon | Anbefaling |\n|----|----------|--------|----------|------------|\n| F-01 | critical | remove | Authentication layer | Tilgang til AI-forklaringer mangler attribute-based access control — alle saksbehandler ser alle saker. Implementer ABAC basert på sak-tildeling. |\n| F-02 | high | review | Data pipeline | Treningsdata oppdateres månedlig, men ingen formell drift-deteksjon. Etabler statistisk drift-monitoring i Azure Monitor. |\n| F-03 | high | review | Model serving | Modellen serves fra en enkelt regional endpoint uten failover. Replikér til en sekundær region for RTO < 1t. |\n| F-04 | high | review | Logging | Audit-logg lagres 30 dager — under arkivlovens krav for sak-relevant info. Endre retensjon til 7 år for sak-knyttede oppslag. |\n| F-05 | medium | keep | Cost management | Ingen budsjettalarmer på Azure AI Services — prediction-kostnaden kan øke med 4× ved belastnings-topper uten varsel. |\n| F-06 | medium | review | Compliance | FRIA-rapport ikke vedlikeholdt etter modell-endring 2026-03-12. Re-evaluering trengs. |\n| F-07 | medium | keep | UX | saksbehandler-grensesnitt viser ikke konfidensgrad tydelig nok — risiko for over-trust på AI-output. |\n| F-08 | low | suppressed | Documentation | README mangler oppdatert arkitekturdiagram (siste fra 2025-11). |\n| F-09 | low | suppressed | Testing | Manglende E2E-test for henvendelser på andre språk. |\n\n## Sammendrag\n\nCritical (1): ABAC mangler — må fikses før idriftsettelse.\nHigh (3): Drift-deteksjon, failover, logg-retensjon — må fikses innen 6 mnd.\nMedium (3): Budsjett, FRIA-revisjon, UX-konfidens — bør fikses innen 12 mnd.\nLow (2): Dokumentasjon, testing — opportunity-quality.\n\n## Anbefaling\n\nIdriftsettelse anbefales IKKE før F-01 er løst. F-02 til F-04 må adresseres innen 2026-09-01 for å holde 2027-12-02-fristen.\n"
|
||||
},
|
||||
"cost": {
|
||||
"input": {},
|
||||
"raw_markdown": "# Kostnadsestimat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPeriode: 12 måneder fra produksjonssetting\nValuta: NOK\n\n## Distribusjon (P10/P50/P90)\n\n| Persentil | Månedlig (NOK) | Årlig (NOK) |\n|-----------|----------------|-------------|\n| P10 | 78 000 | 936 000 |\n| P50 | 142 000 | 1 704 000 |\n| P90 | 285 000 | 3 420 000 |\n\n## Månedlig fordeling (P50)\n\n| Komponent | Kostnad (NOK/mnd) |\n|-----------|-------------------|\n| Azure AI Services (OCR + classification) | 64 000 |\n| Azure OpenAI (forklaringsmodell) | 28 000 |\n| Azure AI Search (indeks for objektregister) | 12 000 |\n| Storage (blob + cosmos for audit) | 8 500 |\n| Compute (Container Apps for orchestration) | 11 000 |\n| Networking (Private Endpoints + egress) | 5 200 |\n| Monitoring (Sentinel + Log Analytics) | 9 800 |\n| Backup og DR | 3 500 |\n\n## TCO-tabell (3 år)\n\n| År | Capex | Opex | Total | Akkumulert |\n|----|-------|------|-------|------------|\n| År 1 | 850 000 | 1 704 000 | 2 554 000 | 2 554 000 |\n| År 2 | 120 000 | 1 875 000 | 1 995 000 | 4 549 000 |\n| År 3 | 80 000 | 2 060 000 | 2 140 000 | 6 689 000 |\n\n## Kostnadsdrivere\n\n- Datavolum: ~12 millioner Acme Kunde-chatbot-deteksjoner/mnd\n- Forklaring-prompt-tokens: ~250 tokens per flagged hendelse\n- Reservert kapasitet for 99.9% SLA\n\n## Konfidensgradering\n\nP50 er beregnet med 95% konfidens basert på 6 måneder pilot-data. P90 inkluderer 2× volum-skalering ved fullnasjonal utrulling. P10 forutsetter optimaliserte prompt-cache (>40% hit-rate).\n\n## Anbefaling\n\nBruk P50 som budsjettlinje. Sett alarm på 1.4× P50 (≈ 200 000/mnd) for tidlig varsling.\n"
|
||||
"raw_markdown": "# Kostnadsestimat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPeriode: 12 måneder fra produksjonssetting\nValuta: NOK\n\n## Distribusjon (P10/P50/P90)\n\n| Persentil | Månedlig (NOK) | Årlig (NOK) |\n|-----------|----------------|-------------|\n| P10 | 78 000 | 936 000 |\n| P50 | 142 000 | 1 704 000 |\n| P90 | 285 000 | 3 420 000 |\n\n## Månedlig fordeling (P50)\n\n| Komponent | Kostnad (NOK/mnd) |\n|-----------|-------------------|\n| Azure AI Services (OCR + classification) | 64 000 |\n| Azure OpenAI (forklaringsmodell) | 28 000 |\n| Azure AI Search (indeks for regelverk og tjenesteinformasjon) | 12 000 |\n| Storage (blob + cosmos for audit) | 8 500 |\n| Compute (Container Apps for orchestration) | 11 000 |\n| Networking (Private Endpoints + egress) | 5 200 |\n| Monitoring (Sentinel + Log Analytics) | 9 800 |\n| Backup og DR | 3 500 |\n\n## TCO-tabell (3 år)\n\n| År | Capex | Opex | Total | Akkumulert |\n|----|-------|------|-------|------------|\n| År 1 | 850 000 | 1 704 000 | 2 554 000 | 2 554 000 |\n| År 2 | 120 000 | 1 875 000 | 1 995 000 | 4 549 000 |\n| År 3 | 80 000 | 2 060 000 | 2 140 000 | 6 689 000 |\n\n## Kostnadsdrivere\n\n- Datavolum: ~1,2 millioner chatbot-meldinger og vedlegg/mnd\n- Forklaring-prompt-tokens: ~250 tokens per flaggede søknad\n- Reservert kapasitet for 99.9% SLA\n\n## Konfidensgradering\n\nP50 er beregnet med 95% konfidens basert på 6 måneder pilot-data. P90 inkluderer 2× volum-skalering ved utvidelse til flere tjenesteområder. P10 forutsetter optimaliserte prompt-cache (>40% hit-rate).\n\n## Anbefaling\n\nBruk P50 som budsjettlinje. Sett alarm på 1.4× P50 (≈ 200 000/mnd) for tidlig varsling.\n"
|
||||
},
|
||||
"license": {
|
||||
"input": {},
|
||||
"raw_markdown": "# Lisens-kapabilitetsmatrise — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\n\n## Matrise\n\n| Kapabilitet | M365 E3 | M365 E5 | Copilot for M365 | Copilot Studio | Azure AI Foundry |\n|-------------|---------|---------|------------------|----------------|------------------|\n| OCR av objekt-ID | missing | missing | missing | conditional | available |\n| Custom modell-trening | missing | missing | missing | missing | available |\n| Audit-logging på AI-input | missing | available | available | available | available |\n| Customer-managed keys | missing | available | conditional | conditional | available |\n| Private Endpoints | missing | available | missing | conditional | available |\n| saksbehandler-co-pilot UI | missing | missing | available | available | conditional |\n| Norsk språkstøtte i prompts | available | available | available | available | available |\n| Compliance-pakke for leverandøren | missing | available | conditional | conditional | available |\n| Real-time inference (<100ms) | missing | missing | missing | missing | available |\n| Batch-inference for nattlige jobber | missing | missing | missing | missing | available |\n\n## Status-betydning\n\n- available: Inkludert i lisensen, klar til bruk\n- cost: Tilgjengelig som tillegg, krever separat fakturering\n- conditional: Kan brukes med begrensninger eller add-on\n- missing: Ikke tilgjengelig på dette lisensnivået\n\n## Sammendrag\n\nAzure AI Foundry er eneste lisens som dekker alle kjernekapabiliteter. Copilot Studio passer for saksbehandler-UI men kan ikke håndtere OCR/custom modeller alene. Hybrid: Foundry (kjerne) + Copilot Studio (UI) gir best dekning.\n\n## Anbefaling\n\nBruk Azure AI Foundry for AI-tjenester (OCR, klassifisering, forklaring). Hold M365 E5 på saksbehandler-arbeidsstasjoner for audit-logging og compliance-pakke. Vurder Copilot Studio i fase 2 for saksbehandler-co-pilot.\n"
|
||||
"raw_markdown": "# Lisens-kapabilitetsmatrise — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\n\n## Matrise\n\n| Kapabilitet | M365 E3 | M365 E5 | Copilot for M365 | Copilot Studio | Azure AI Foundry |\n|-------------|---------|---------|------------------|----------------|------------------|\n| OCR av vedlegg | missing | missing | missing | conditional | available |\n| Custom modell-trening | missing | missing | missing | missing | available |\n| Audit-logging på AI-input | missing | available | available | available | available |\n| Customer-managed keys | missing | available | conditional | conditional | available |\n| Private Endpoints | missing | available | missing | conditional | available |\n| saksbehandler-co-pilot UI | missing | missing | available | available | conditional |\n| Norsk språkstøtte i prompts | available | available | available | available | available |\n| Compliance-pakke for leverandøren | missing | available | conditional | conditional | available |\n| Real-time inference (<100ms) | missing | missing | missing | missing | available |\n| Batch-inference for nattlige jobber | missing | missing | missing | missing | available |\n\n## Status-betydning\n\n- available: Inkludert i lisensen, klar til bruk\n- cost: Tilgjengelig som tillegg, krever separat fakturering\n- conditional: Kan brukes med begrensninger eller add-on\n- missing: Ikke tilgjengelig på dette lisensnivået\n\n## Sammendrag\n\nAzure AI Foundry er eneste lisens som dekker alle kjernekapabiliteter. Copilot Studio passer for saksbehandler-UI men kan ikke håndtere OCR/custom modeller alene. Hybrid: Foundry (kjerne) + Copilot Studio (UI) gir best dekning.\n\n## Anbefaling\n\nBruk Azure AI Foundry for AI-tjenester (OCR, klassifisering, forklaring). Hold M365 E5 på saksbehandler-arbeidsstasjoner for audit-logging og compliance-pakke. Vurder Copilot Studio i fase 2 for saksbehandler-co-pilot.\n"
|
||||
},
|
||||
"migrate": {
|
||||
"input": {},
|
||||
"raw_markdown": "# Migrasjonsplan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nFra: On-prem OCR + manuell klassifisering\nTil: Azure AI Foundry + saksbehandler-co-pilot\n\n## Faser\n\n### Fase 1 — Foundry-fundament (uker 1-6)\n\nVarighet: 6 uker\nStatus: done\n\nMilepæler:\n- Hub + projects opprettet i West Europe\n- Network isolation: Private Endpoints + Vnet integration\n- Identity: Entra ID-integrasjon med PIM\n- Logging: OpenTelemetry → Sentinel pipeline\n\nSuksesskriterier:\n- Pilot OCR-modell deployert med <100ms latency P95\n- Audit-logg fanger 100% av inferences\n- Sikkerhetsarkitekt godkjenner foundation-design\n\n### Fase 2 — Modell-trening og baseline (uker 7-14)\n\nVarighet: 8 uker\nStatus: done\n\nMilepæler:\n- Treningsdata kuratert (200k norske objekt-ID, stratifisert)\n- Custom modell trent på Azure ML\n- Baseline-nøyaktighet etablert (mål: ≥96% F1)\n- Bias-evaluering på utenlandske registre fullført\n\nSuksesskriterier:\n- F1 ≥ 96% overall, ≥ 92% per objekter-segment\n- Drift-deteksjon kalibrert med terskel\n- ROS-revisjon godkjent\n\n### Fase 3 — saksbehandler-co-pilot (uker 15-22)\n\nVarighet: 8 uker\nStatus: active\n\nMilepæler:\n- Forklaringsmodell (GPT-4 Turbo) integrert via Foundry\n- saksbehandler-UI bygget (Copilot Studio + Power Platform)\n- Workflow: AI flagger → saksbehandler reviewer → klar for sanksjon\n- Brukertest med 12 saksbehandler fra ulike regioner\n\nSuksesskriterier:\n- Saksbehandlingstid -40% vs baseline\n- saksbehandler-tillit >7/10 i post-pilot survey\n- Ingen kritiske UX-feil\n\n### Fase 4 — Compliance og produksjonssetting (uker 23-28)\n\nVarighet: 6 uker\nStatus: planned\n\nMilepæler:\n- FRIA gjennomført og godkjent\n- Conformity assessment ferdigstilt per Annex VI\n- DPIA oppdatert med nye operasjonelle data\n- Produksjonssetting til 3 piloter (Oslo, Bergen, Trondheim)\n\nSuksesskriterier:\n- Personvernombud signerer DPIA\n- Ingen open critical-funn fra arkitekturgjennomgang\n- Stabil 99.9% uptime i 30 dager pilot\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom modell underyter mot 96% mål | medium | high | Backup-strategi: bruk Azure AI Vision OCR som fallback |\n| saksbehandler-motstand mot AI | medium | medium | Tidlig involvering; transparent forklaring; opt-out på enkelt-saker |\n| FRIA blokkerer fase 4 | low | high | Pre-FRIA-kjøring i fase 2 for tidlig varsling |\n| Cost-overrun ved skalering | medium | medium | Reserved capacity-binding etter fase 3 |\n\n## Total varighet\n\n28 uker (~7 måneder). Avhengighet: Foundry-fundament må være ferdig før modell-trening starter.\n"
|
||||
"raw_markdown": "# Migrasjonsplan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nFra: On-prem OCR + manuell klassifisering\nTil: Azure AI Foundry + saksbehandler-co-pilot\n\n## Faser\n\n### Fase 1 — Foundry-fundament (uker 1-6)\n\nVarighet: 6 uker\nStatus: done\n\nMilepæler:\n- Hub + projects opprettet i West Europe\n- Network isolation: Private Endpoints + Vnet integration\n- Identity: Entra ID-integrasjon med PIM\n- Logging: OpenTelemetry → Sentinel pipeline\n\nSuksesskriterier:\n- Pilot OCR-modell deployert med <100ms latency P95\n- Audit-logg fanger 100% av inferences\n- Sikkerhetsarkitekt godkjenner foundation-design\n\n### Fase 2 — Modell-trening og baseline (uker 7-14)\n\nVarighet: 8 uker\nStatus: done\n\nMilepæler:\n- Treningsdata kuratert (200k anonymiserte vedlegg, stratifisert på dokumenttype og språk)\n- Custom modell trent på Azure ML\n- Baseline-nøyaktighet etablert (mål: ≥96% F1)\n- Bias-evaluering på henvendelser og vedlegg på andre språk fullført\n\nSuksesskriterier:\n- F1 ≥ 96% overall, ≥ 92% per dokumenttype\n- Drift-deteksjon kalibrert med terskel\n- ROS-revisjon godkjent\n\n### Fase 3 — saksbehandler-co-pilot (uker 15-22)\n\nVarighet: 8 uker\nStatus: active\n\nMilepæler:\n- Forklaringsmodell (GPT-4 Turbo) integrert via Foundry\n- saksbehandler-UI bygget (Copilot Studio + Power Platform)\n- Workflow: AI flagger → saksbehandler reviewer → klar for vedtak\n- Brukertest med 12 saksbehandlere fra ulike tjenesteområder\n\nSuksesskriterier:\n- Saksbehandlingstid -40% vs baseline\n- saksbehandler-tillit >7/10 i post-pilot survey\n- Ingen kritiske UX-feil\n\n### Fase 4 — Compliance og produksjonssetting (uker 23-28)\n\nVarighet: 6 uker\nStatus: planned\n\nMilepæler:\n- FRIA gjennomført og godkjent\n- Conformity assessment ferdigstilt per Annex VI\n- DPIA oppdatert med nye operasjonelle data\n- Produksjonssetting i 3 pilotbydeler\n\nSuksesskriterier:\n- Personvernombud signerer DPIA\n- Ingen open critical-funn fra arkitekturgjennomgang\n- Stabil 99.9% uptime i 30 dager pilot\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom modell underyter mot 96% mål | medium | high | Backup-strategi: bruk Azure AI Vision OCR som fallback |\n| saksbehandler-motstand mot AI | medium | medium | Tidlig involvering; transparent forklaring; opt-out på enkelt-saker |\n| FRIA blokkerer fase 4 | low | high | Pre-FRIA-kjøring i fase 2 for tidlig varsling |\n| Cost-overrun ved skalering | medium | medium | Reserved capacity-binding etter fase 3 |\n\n## Total varighet\n\n28 uker (~7 måneder). Avhengighet: Foundry-fundament må være ferdig før modell-trening starter.\n"
|
||||
},
|
||||
"adr": {
|
||||
"input": {},
|
||||
|
|
@ -300,15 +300,15 @@
|
|||
},
|
||||
"summary": {
|
||||
"input": {},
|
||||
"raw_markdown": "# Beslutningsnotat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nDato: 2026-04-30\nTil: Direktør for Digital og IT\nFra: AI-teamet\n\n## Verdict\n\nVerdict: warning\nSub: Pilot anbefalt med betingelser\n\n## Rationale\n\nArkitekturen er teknisk solid og økonomisk forsvarlig (P50 NOK 1.7M/år), men compliance-arbeidet ligger 6 måneder bak ideell tidslinje. Pilot kan starte etter at FRIA og transparens-instruksjoner er ferdigstilt; full produksjonssetting krever lukking av alle critical funn fra arkitekturgjennomgang.\n\n## Key Metrics\n\n| Metric | Verdi | Mål |\n|--------|-------|-----|\n| Compliance-dekning | 33% (4/12 fullt møtt) | 100% innen 2027-12-02 |\n| Sikkerhetsscore | 22/30 (73%) | ≥27/30 (90%) |\n| TCO 3 år | NOK 6.7M | ≤ NOK 7M |\n| Saksbehandlingstid (pilot) | -32% (estimert) | -40% |\n| ROS-restrisiko | medium | low-medium |\n\n## Next Steps\n\n- Lukk F-01 (ABAC) innen 2026-06-15\n- Gjennomfør FRIA innen 2026-07-15 (Art. 27-frist)\n- Produksjonsdokumentere transparens-instruksjoner innen 2026-09-01\n- Pilot 3 regioner (Oslo, Bergen, Trondheim) Q4 2026\n- Full utrulling Q2 2027\n\n## Restrisiko\n\nEtter foreslåtte tiltak: medium. Hovedeksponering: bias mot utenlandske objekt-ID krever løpende monitoring.\n\n## Anbefaling\n\nGodkjenn pilot-fase med tydelig stage-gate til full produksjonssetting. Avstem med Datatilsynet før fase 4.\n"
|
||||
"raw_markdown": "# Beslutningsnotat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nDato: 2026-04-30\nTil: Direktør for Digital og IT\nFra: AI-teamet\n\n## Verdict\n\nVerdict: warning\nSub: Pilot anbefalt med betingelser\n\n## Rationale\n\nArkitekturen er teknisk solid og økonomisk forsvarlig (P50 NOK 1.7M/år), men compliance-arbeidet ligger 6 måneder bak ideell tidslinje. Pilot kan starte etter at FRIA og transparens-instruksjoner er ferdigstilt; full produksjonssetting krever lukking av alle critical funn fra arkitekturgjennomgang.\n\n## Key Metrics\n\n| Metric | Verdi | Mål |\n|--------|-------|-----|\n| Compliance-dekning | 33% (4/12 fullt møtt) | 100% innen 2027-12-02 |\n| Sikkerhetsscore | 22/30 (73%) | ≥27/30 (90%) |\n| TCO 3 år | NOK 6.7M | ≤ NOK 7M |\n| Saksbehandlingstid (pilot) | -32% (estimert) | -40% |\n| ROS-restrisiko | medium | low-medium |\n\n## Next Steps\n\n- Lukk F-01 (ABAC) innen 2026-06-15\n- Gjennomfør FRIA innen 2026-07-15 (Art. 27-frist)\n- Produksjonsdokumentere transparens-instruksjoner innen 2026-09-01\n- Pilot i 3 bydeler Q4 2026\n- Full utrulling Q2 2027\n\n## Restrisiko\n\nEtter foreslåtte tiltak: medium. Hovedeksponering: bias mot henvendelser på andre språk enn norsk krever løpende monitoring.\n\n## Anbefaling\n\nGodkjenn pilot-fase med tydelig stage-gate til full produksjonssetting. Avstem med Datatilsynet før fase 4.\n"
|
||||
},
|
||||
"poc": {
|
||||
"input": {},
|
||||
"raw_markdown": "# POC-plan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPOC-mål: Validere at Azure AI Foundry kan dekke OCR + forklaring + audit innen tids- og kostbudsjett\n\n## Faser\n\n### Fase 1 — Foundation (uker 1-2)\n\nVarighet: 2 uker\nStatus: done\n\nMilepæler:\n- Foundry hub + project i West Europe\n- Identity og networking konfigurert\n- Sample-data uploadet (10k anonymiserte objekt-ID)\n\nSuksesskriterier:\n- Inferens-endpoint nåbart fra dev-Vnet via Private Endpoint\n- Audit-logg fanger første test-inferens\n- Cost-monitor viser daglig forbruk i Azure portal\n\n### Fase 2 — OCR-modell (uker 3-5)\n\nVarighet: 3 uker\nStatus: active\n\nMilepæler:\n- Pre-trent Azure AI Vision OCR pilotert\n- Custom fine-tune på 10k objekt-ID\n- Sammenligning av accuracy/latency mellom de to\n\nSuksesskriterier:\n- F1 ≥ 92% på pilot-sett (lavere mål enn produksjon, akseptabelt for POC)\n- Latency P95 < 200ms\n- Inference-cost ≤ NOK 0.04 per kall\n\n### Fase 3 — Forklarings-loop (uker 6-7)\n\nVarighet: 2 uker\nStatus: planned\n\nMilepæler:\n- GPT-4 Turbo via Foundry integrert\n- Prompt-template for forklaring av flagged sak\n- saksbehandler-mock UI (en enkel webside) prøvd ut med 3 brukere\n\nSuksesskriterier:\n- Forklaring referer til konfidens og kontekst korrekt i 95% av tilfellene\n- saksbehandler-feedback kvalitativt positiv (\"forståelig, men trenger justering\")\n- Prompt-tokens under 250 i snitt per sak\n\n### Fase 4 — Compliance-pre-check (uke 8)\n\nVarighet: 1 uke\nStatus: planned\n\nMilepæler:\n- Audit-logg mot EU AI Act Art. 12-krav\n- Customer-managed keys verifisert\n- Pre-DPIA-sjekk gjort med Datatilsynet\n\nSuksesskriterier:\n- Audit-logg dekker 100% av inferences med tidsstempel + bruker\n- Personvernombud signer pre-DPIA-utkast\n- Ingen åpenbare GDPR-blokkere\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom OCR-modell underyter pre-trent | medium | medium | Aksepter pre-trent for POC; planlegg custom for full prod |\n| Foundry-quota i West Europe utilstrekkelig | low | medium | Reserver kapasitet før POC starter |\n| saksbehandler-recruitment forsinker fase 3 | medium | low | Bruk interne ressurser i AI-teamet som mock |\n| Audit-logg-format ikke kompatibelt med Sentinel | low | medium | Test integrasjon i fase 1 |\n\n## POC-Verdict: BETINGET\n\nPilot-fase 1 fullført med F1=0.94 og inference-cost 0.038 NOK/kall (under budsjett). Fase 2 pågår — sammenligning av custom fine-tune mot pre-trent OCR i progress. Forklarings-loop og compliance-pre-check planlagt for siste halvdel.\n\n## Total varighet\n\n8 uker. Beslutningskriterium for full prosjektgodkjenning: alle 4 fasers suksesskriterier møtt.\n"
|
||||
"raw_markdown": "# POC-plan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPOC-mål: Validere at Azure AI Foundry kan dekke OCR + forklaring + audit innen tids- og kostbudsjett\n\n## Faser\n\n### Fase 1 — Foundation (uker 1-2)\n\nVarighet: 2 uker\nStatus: done\n\nMilepæler:\n- Foundry hub + project i West Europe\n- Identity og networking konfigurert\n- Sample-data uploadet (10k anonymiserte vedlegg)\n\nSuksesskriterier:\n- Inferens-endpoint nåbart fra dev-Vnet via Private Endpoint\n- Audit-logg fanger første test-inferens\n- Cost-monitor viser daglig forbruk i Azure portal\n\n### Fase 2 — OCR-modell (uker 3-5)\n\nVarighet: 3 uker\nStatus: active\n\nMilepæler:\n- Pre-trent Azure AI Vision OCR pilotert\n- Custom fine-tune på 10k vedlegg\n- Sammenligning av accuracy/latency mellom de to\n\nSuksesskriterier:\n- F1 ≥ 92% på pilot-sett (lavere mål enn produksjon, akseptabelt for POC)\n- Latency P95 < 200ms\n- Inference-cost ≤ NOK 0.04 per kall\n\n### Fase 3 — Forklarings-loop (uker 6-7)\n\nVarighet: 2 uker\nStatus: planned\n\nMilepæler:\n- GPT-4 Turbo via Foundry integrert\n- Prompt-template for forklaring av flagged sak\n- saksbehandler-mock UI (en enkel webside) prøvd ut med 3 brukere\n\nSuksesskriterier:\n- Forklaring referer til konfidens og kontekst korrekt i 95% av tilfellene\n- saksbehandler-feedback kvalitativt positiv (\"forståelig, men trenger justering\")\n- Prompt-tokens under 250 i snitt per sak\n\n### Fase 4 — Compliance-pre-check (uke 8)\n\nVarighet: 1 uke\nStatus: planned\n\nMilepæler:\n- Audit-logg mot EU AI Act Art. 12-krav\n- Customer-managed keys verifisert\n- Pre-DPIA-sjekk gjort med Datatilsynet\n\nSuksesskriterier:\n- Audit-logg dekker 100% av inferences med tidsstempel + bruker\n- Personvernombud signer pre-DPIA-utkast\n- Ingen åpenbare GDPR-blokkere\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom OCR-modell underyter pre-trent | medium | medium | Aksepter pre-trent for POC; planlegg custom for full prod |\n| Foundry-quota i West Europe utilstrekkelig | low | medium | Reserver kapasitet før POC starter |\n| saksbehandler-recruitment forsinker fase 3 | medium | low | Bruk interne ressurser i AI-teamet som mock |\n| Audit-logg-format ikke kompatibelt med Sentinel | low | medium | Test integrasjon i fase 1 |\n\n## POC-Verdict: BETINGET\n\nPilot-fase 1 fullført med F1=0.94 og inference-cost 0.038 NOK/kall (under budsjett). Fase 2 pågår — sammenligning av custom fine-tune mot pre-trent OCR i progress. Forklarings-loop og compliance-pre-check planlagt for siste halvdel.\n\n## Total varighet\n\n8 uker. Beslutningskriterium for full prosjektgodkjenning: alle 4 fasers suksesskriterier møtt.\n"
|
||||
},
|
||||
"utredning": {
|
||||
"input": {},
|
||||
"raw_markdown": "# AI-arkitekturutredning — Acme Kunde-chatbot for Acme Kommune\n\n## 1. Bakgrunn og formål\n\nAcme Kommune har siden 2018 driftet en on-prem Acme Kunde-chatbot-løsning for operasjonell analyse på tvers av leverandørens tjenesteportefølje. Løsningen er basert på et OCR-bibliotek fra 2017 og leveres som et lukket system uten mulighet for retrening eller forbedring av modell. Saksbehandlingen er manuell og tar i snitt 14 minutter per sak. Et internt AI-team utreder modernisering til en skybasert AI-plattform som støtter custom modell-trening, audit-logging på inferens-nivå, og saksbehandler-co-pilot.\n\n## 2. Mandat\n\nUtredningen skal:\n- Anbefale teknologivalg blant Azure AI Foundry, Azure ML+AKS, AWS SageMaker og on-prem GPU-cluster\n- Vurdere compliance-status mot EU AI Act, GDPR, sikkerhetsloven og arkivloven\n- Estimere TCO over 3 år\n- Identifisere risiko og foreslå mitigerende tiltak\n- Definere KPI-er for produksjonssetting\n\n## 3. Metode\n\nUtredningen kombinerer:\n- Kvalitativ analyse av compliance-krav per relevante lover og forskrifter\n- Kvantitativ TCO-analyse basert på 12 millioner Acme Kunde-chatbot-deteksjoner/mnd\n- Risikoanalyse per NS 5814 og DPIA per Datatilsynets veileder\n- Markedsundersøkelse av tilgjengelige plattformer fra Azure, AWS og GCP\n\n## 4. Funn\n\n### 4.1 Compliance\n\nEU AI Act klassifiserer systemet som høyrisiko (Annex III, punkt 6 — rettshåndhevelse). Acme Kommune er Provider og Deployer, hvilket trigger alle krav i Art. 9-15 + Art. 27 (FRIA) + Art. 49 (registrering).\n\n### 4.2 Teknologivalg\n\nAzure AI Foundry er anbefalt primær plattform fordi:\n- Full compliance-pakke for leverandøren\n- Customer-managed keys og Customer Lockbox tilgjengelig\n- Custom modell-trening via integrert Azure ML\n- Norsk dataresidens (West Europe + EU Data Boundary)\n\n### 4.3 TCO\n\n3-års TCO estimert til NOK 6.7M (P50). Hovedkostnad: Azure AI Services (38%) + Azure OpenAI (16%).\n\n### 4.4 Risiko\n\nHovedrisiko: bias mot utenlandske objekt-ID, modell-drift over tid, og manglende ABAC-implementering på saksbehandler-tilgang. Alle har konkrete tiltak.\n\n## 5. Konklusjon\n\nAnbefalt: gjennomfør 8-ukers POC før formell prosjektoppstart. Ved vellykket POC, full implementering over 28 uker mot produksjonssetting Q2 2027.\n\n## 6. Anbefaling\n\nGodkjenn POC-budsjett på NOK 1.2M og forenkle prosjekt-mandat for fase 1-4 ved positiv POC-evaluering.\n\n## 7. Referanser\n\n- EU AI Act 2024/1689\n- GDPR 2016/679\n- Sikkerhetsloven (LOV-2018-06-01-24)\n- Arkivloven (LOV-1992-12-04-126)\n- NS 5814:2008 — Krav til risikovurderinger\n- Datatilsynets veileder for AI og personvern (2024)\n"
|
||||
"raw_markdown": "# AI-arkitekturutredning — Acme Kunde-chatbot for Acme Kommune\n\n## 1. Bakgrunn og formål\n\nAcme Kommune har siden 2018 driftet en on-prem Acme Kunde-chatbot-løsning for forhåndsvurdering av søknader på tvers av kommunens tjenesteportefølje. Løsningen er basert på et OCR-bibliotek fra 2017 og leveres som et lukket system uten mulighet for retrening eller forbedring av modell. Saksbehandlingen er manuell og tar i snitt 14 minutter per sak. Et internt AI-team utreder modernisering til en skybasert AI-plattform som støtter custom modell-trening, audit-logging på inferens-nivå, og saksbehandler-co-pilot.\n\n## 2. Mandat\n\nUtredningen skal:\n- Anbefale teknologivalg blant Azure AI Foundry, Azure ML+AKS, AWS SageMaker og on-prem GPU-cluster\n- Vurdere compliance-status mot EU AI Act, GDPR, sikkerhetsloven og arkivloven\n- Estimere TCO over 3 år\n- Identifisere risiko og foreslå mitigerende tiltak\n- Definere KPI-er for produksjonssetting\n\n## 3. Metode\n\nUtredningen kombinerer:\n- Kvalitativ analyse av compliance-krav per relevante lover og forskrifter\n- Kvantitativ TCO-analyse basert på 1,2 millioner chatbot-meldinger og vedlegg/mnd\n- Risikoanalyse per NS 5814 og DPIA per Datatilsynets veileder\n- Markedsundersøkelse av tilgjengelige plattformer fra Azure, AWS og GCP\n\n## 4. Funn\n\n### 4.1 Compliance\n\nEU AI Act klassifiserer systemet som høyrisiko (Annex III, punkt 5(a) — tilgang til offentlige ytelser). Acme Kommune er Provider og Deployer, hvilket trigger alle krav i Art. 9-15 + Art. 27 (FRIA) + Art. 49 (registrering).\n\n### 4.2 Teknologivalg\n\nAzure AI Foundry er anbefalt primær plattform fordi:\n- Full compliance-pakke for leverandøren\n- Customer-managed keys og Customer Lockbox tilgjengelig\n- Custom modell-trening via integrert Azure ML\n- Norsk dataresidens (West Europe + EU Data Boundary)\n\n### 4.3 TCO\n\n3-års TCO estimert til NOK 6.7M (P50). Hovedkostnad: Azure AI Services (38%) + Azure OpenAI (16%).\n\n### 4.4 Risiko\n\nHovedrisiko: bias mot henvendelser på andre språk enn norsk, modell-drift over tid, og manglende ABAC-implementering på saksbehandler-tilgang. Alle har konkrete tiltak.\n\n## 5. Konklusjon\n\nAnbefalt: gjennomfør 8-ukers POC før formell prosjektoppstart. Ved vellykket POC, full implementering over 28 uker mot produksjonssetting Q2 2027.\n\n## 6. Anbefaling\n\nGodkjenn POC-budsjett på NOK 1.2M og forenkle prosjekt-mandat for fase 1-4 ved positiv POC-evaluering.\n\n## 7. Referanser\n\n- EU AI Act 2024/1689\n- GDPR 2016/679\n- Sikkerhetsloven (LOV-2018-06-01-24)\n- Arkivloven (LOV-1992-12-04-126)\n- NS 5814:2008 — Krav til risikovurderinger\n- Datatilsynets veileder for AI og personvern (2024)\n"
|
||||
},
|
||||
"compare": {
|
||||
"input": {},
|
||||
|
|
@ -5617,7 +5617,7 @@
|
|||
sub: 'Hvem er dere?',
|
||||
fields: [
|
||||
{ id: 'name', label: 'Virksomhetsnavn', type: 'text', required: true,
|
||||
placeholder: 'f.eks. Bærum kommune, Statens vegvesen, Helse Sør-Øst RHF' },
|
||||
placeholder: 'f.eks. Bærum kommune, Eksempeldirektoratet, Helse Sør-Øst RHF' },
|
||||
{ id: 'description', label: 'Kort beskrivelse', type: 'textarea',
|
||||
placeholder: 'Hva gjør virksomheten? F.eks. "Kommune med 8 000 ansatte, ansvar for skole, helse og byggesak."' },
|
||||
{ id: 'sector', label: 'Sektor', type: 'select', required: true,
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 718 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 717 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 718 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 718 KiB |
|
|
@ -1,7 +1,7 @@
|
|||
# EU AI Act — Klassifisering: Acme Kunde-chatbot
|
||||
|
||||
System: Acme Kunde-chatbot (Acme Kommune)
|
||||
Beskrivelse: AI-system som identifiserer objekter som krever oppfølging via sensordata + objektregister
|
||||
Beskrivelse: Innbyggerchatbot som svarer på henvendelser og forhåndsvurderer søknader om kommunal bostøtte via vedleggstolkning + oppslag i fagsystemet
|
||||
|
||||
## Risikonivå
|
||||
|
||||
|
|
@ -13,7 +13,7 @@ Rolle: Provider og Deployer (utvikler internt + drifter selv)
|
|||
|
||||
## Begrunnelse
|
||||
|
||||
Reasoning: Systemet brukes av offentlig myndighet for håndheving av lov, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for håndtering. Dette plasserer systemet under Annex III, punkt 6 (rettshåndhevelse) og krever full høyrisiko-compliance per Art. 6(2).
|
||||
Reasoning: Systemet brukes av offentlig myndighet til å vurdere om innbyggere har rett til en offentlig ytelse, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for saksbehandlingen. Dette plasserer systemet under Annex III, punkt 5(a) (tilgang til offentlige ytelser og tjenester) og krever full høyrisiko-compliance per Art. 6(2).
|
||||
|
||||
## Forpliktelser
|
||||
|
||||
|
|
|
|||
|
|
@ -13,8 +13,8 @@ Vurderingsprosedyre: Annex VI (intern kontroll)
|
|||
| Logging av hendelser implementert | bestått | OpenTelemetry-spans i Azure Monitor |
|
||||
| Transparens-instruksjoner skrevet | avvist | Skal leveres innen 2026-09-01 |
|
||||
| Menneskelig oversikt på saksbehandler | bestått | Workflow-design godkjent av juridisk |
|
||||
| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per objekt-ID-region |
|
||||
| Robusthet under adversarielle forhold | betinget | Test-suite mangler skitne plater og natt-scenarier |
|
||||
| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per språkgruppe |
|
||||
| Robusthet under adversarielle forhold | betinget | Test-suite mangler skannede, skjeve og håndskrevne vedlegg |
|
||||
| Cybersikkerhetstiltak per Art. 15 | bestått | NSM Grunnprinsipper-vurdering bestått |
|
||||
| Conformity assessment underskrevet | avvist | Avhengig av FRIA-resultat |
|
||||
| EU declaration of conformity utstedt | avvist | Avhenger av Art. 47 |
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Valuta: NOK
|
|||
|-----------|-------------------|
|
||||
| Azure AI Services (OCR + classification) | 64 000 |
|
||||
| Azure OpenAI (forklaringsmodell) | 28 000 |
|
||||
| Azure AI Search (indeks for objektregister) | 12 000 |
|
||||
| Azure AI Search (indeks for regelverk og tjenesteinformasjon) | 12 000 |
|
||||
| Storage (blob + cosmos for audit) | 8 500 |
|
||||
| Compute (Container Apps for orchestration) | 11 000 |
|
||||
| Networking (Private Endpoints + egress) | 5 200 |
|
||||
|
|
@ -35,13 +35,13 @@ Valuta: NOK
|
|||
|
||||
## Kostnadsdrivere
|
||||
|
||||
- Datavolum: ~12 millioner Acme Kunde-chatbot-deteksjoner/mnd
|
||||
- Forklaring-prompt-tokens: ~250 tokens per flagged hendelse
|
||||
- Datavolum: ~1,2 millioner chatbot-meldinger og vedlegg/mnd
|
||||
- Forklaring-prompt-tokens: ~250 tokens per flaggede søknad
|
||||
- Reservert kapasitet for 99.9% SLA
|
||||
|
||||
## Konfidensgradering
|
||||
|
||||
P50 er beregnet med 95% konfidens basert på 6 måneder pilot-data. P90 inkluderer 2× volum-skalering ved fullnasjonal utrulling. P10 forutsetter optimaliserte prompt-cache (>40% hit-rate).
|
||||
P50 er beregnet med 95% konfidens basert på 6 måneder pilot-data. P90 inkluderer 2× volum-skalering ved utvidelse til flere tjenesteområder. P10 forutsetter optimaliserte prompt-cache (>40% hit-rate).
|
||||
|
||||
## Anbefaling
|
||||
|
||||
|
|
|
|||
|
|
@ -7,12 +7,12 @@ Metodikk: Datatilsynets veileder + ISO/IEC 29134
|
|||
|
||||
| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |
|
||||
|---------|---------------|------------|-------|------|
|
||||
| Feilaktig objekt-ID-tolkning fører til urettmessig sanksjon | 3 | 4 | 12 | medium |
|
||||
| Massiv lokasjonsdata-lekkasje fra objektregister | 2 | 5 | 10 | medium |
|
||||
| AI-forklaring viser sensitiv kontekst om eier | 3 | 3 | 9 | medium |
|
||||
| Stratifisert bias mot utenlandske objekt-ID | 4 | 3 | 12 | medium |
|
||||
| Fysisk angrep på sensordata skaper deteksjonshull | 2 | 2 | 4 | low |
|
||||
| Insider-misbruk for sporing av enkeltpersoner | 2 | 5 | 10 | medium |
|
||||
| Feilaktig vedleggstolkning fører til urettmessig avslag | 3 | 4 | 12 | medium |
|
||||
| Massiv lekkasje av økonomiopplysninger fra fagsystemet | 2 | 5 | 10 | medium |
|
||||
| AI-forklaring viser sensitiv kontekst om søker | 3 | 3 | 9 | medium |
|
||||
| Stratifisert bias mot henvendelser på andre språk | 4 | 3 | 12 | medium |
|
||||
| Manipulerte vedlegg skaper vurderingshull | 2 | 2 | 4 | low |
|
||||
| Insider-misbruk for oppslag på enkeltpersoner | 2 | 5 | 10 | medium |
|
||||
| Auto-flagging utløser kjedereaksjon ved system-feil | 1 | 5 | 5 | low |
|
||||
| Subject Access Request (GDPR Art. 15) ignoreres | 3 | 3 | 9 | medium |
|
||||
|
||||
|
|
@ -20,10 +20,10 @@ Metodikk: Datatilsynets veileder + ISO/IEC 29134
|
|||
|
||||
| ID | Beskrivelse | Severity | Tiltak |
|
||||
|----|-------------|----------|--------|
|
||||
| T-001 | Feilaktig OCR av objekt-ID | high | Konfidensgrad-cutoff på 0.95; saksbehandler-review under cutoff |
|
||||
| T-002 | Lokasjonsdata-lekkasje | critical | Pseudonymisering ved lagring; HSM-backed nøkler i Azure Key Vault |
|
||||
| T-001 | Feilaktig OCR av vedlegg | high | Konfidensgrad-cutoff på 0.95; saksbehandler-review under cutoff |
|
||||
| T-002 | Lekkasje av økonomiopplysninger | critical | Pseudonymisering ved lagring; HSM-backed nøkler i Azure Key Vault |
|
||||
| T-003 | Kontekst-eksponering i AI-forklaring | high | Filter på sensitive felt; kontekst kun til autorisert saksbehandler |
|
||||
| T-004 | Bias mot utenlandske registre | high | Kvartalsvis stratifisert testing; juster modell ved >5% avvik |
|
||||
| T-004 | Bias mot henvendelser på andre språk | high | Kvartalsvis stratifisert testing; juster modell ved >5% avvik |
|
||||
| T-005 | Insider-misbruk | critical | Audit-logging på alle oppslag; SIEM-deteksjon av unormale mønstre |
|
||||
|
||||
## Tiltak
|
||||
|
|
|
|||
|
|
@ -8,16 +8,16 @@ Hjemmel: EU AI Act Art. 27 (obligatorisk for offentlig sektor)
|
|||
| Rettighet | Impact | Tiltak |
|
||||
|-----------|--------|--------|
|
||||
| Menneskeverd | 1 | Ingen reduksjon — saksbehandler tar endelig avgjørelse, ikke AI |
|
||||
| Rett til frihet og sikkerhet | 1 | Ingen frihetsberøvelse direkte fra AI; politi/domstol er reell beslutter |
|
||||
| Respekt for privatliv | 4 | Massiv overvåking via veikameraer — kompenseres med strenge oppbevaringsregler (90 dager), formålsbegrensning, og minimering av kobling til objektregister |
|
||||
| Rett til frihet og sikkerhet | 0 | Ikke berørt — systemet vurderer bare søknader om en økonomisk ytelse |
|
||||
| Respekt for privatliv | 4 | Samtaler og vedlegg inneholder ofte helse-, familie- og økonomiopplysninger som innbyggere oppgir fritt — kompenseres med strenge oppbevaringsregler (90 dager for samtalelogger), formålsbegrensning, og minimering av kobling til fagsystemet |
|
||||
| Personvern | 4 | DPIA gjennomført; Datatilsynet konsultert; rettslig grunnlag i interne retningslinjer §13 — likevel høy impact pga skala |
|
||||
| Ikke-diskriminering | 3 | Algoritmisk bias-testing på objekt-ID fra utenlandske registre (lavere Acme Kunde-chatbot-nøyaktighet) — kvartalsvis review |
|
||||
| Ikke-diskriminering | 3 | Algoritmisk bias-testing på henvendelser og vedlegg på andre språk enn norsk (lavere tolkningsnøyaktighet) — kvartalsvis review |
|
||||
| Ytringsfrihet og informasjonsfrihet | 0 | Ikke berørt |
|
||||
| Forsamlingsfrihet | 0 | Ikke berørt |
|
||||
| Religionsfrihet | 0 | Ikke berørt |
|
||||
| Eiendomsrett | 2 | Gebyr/sanksjoner berører eiendomsrett — kompenseres med klagemulighet og rettslig prøving |
|
||||
| Rett til sosial sikring | 2 | Feilaktig forhåndsvurdering kan forsinke en ytelse — kompenseres med at saksbehandler vurderer hver søknad, og med klagemulighet |
|
||||
| Rett til effektivt rettsmiddel | 2 | Klageadgang sikret; menneskelig review garantert; AI-forklaring tilgjengelig for klager |
|
||||
| Barns rettigheter | 1 | Lav direkte påvirkning; barn er sjelden registrerte førere |
|
||||
| Barns rettigheter | 1 | Lav direkte påvirkning; barn søker ikke selv, men bor i husstander som søker |
|
||||
| Eldres rettigheter | 2 | Eldre kan ha vanskeligere for å klage digitalt — papir-klage må fortsatt være tilgjengelig |
|
||||
|
||||
## Konklusjon
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Vurderingsdato: 2026-04-30
|
|||
|
||||
| Kapabilitet | M365 E3 | M365 E5 | Copilot for M365 | Copilot Studio | Azure AI Foundry |
|
||||
|-------------|---------|---------|------------------|----------------|------------------|
|
||||
| OCR av objekt-ID | missing | missing | missing | conditional | available |
|
||||
| OCR av vedlegg | missing | missing | missing | conditional | available |
|
||||
| Custom modell-trening | missing | missing | missing | missing | available |
|
||||
| Audit-logging på AI-input | missing | available | available | available | available |
|
||||
| Customer-managed keys | missing | available | conditional | conditional | available |
|
||||
|
|
|
|||
|
|
@ -28,13 +28,13 @@ Varighet: 8 uker
|
|||
Status: done
|
||||
|
||||
Milepæler:
|
||||
- Treningsdata kuratert (200k norske objekt-ID, stratifisert)
|
||||
- Treningsdata kuratert (200k anonymiserte vedlegg, stratifisert på dokumenttype og språk)
|
||||
- Custom modell trent på Azure ML
|
||||
- Baseline-nøyaktighet etablert (mål: ≥96% F1)
|
||||
- Bias-evaluering på utenlandske registre fullført
|
||||
- Bias-evaluering på henvendelser og vedlegg på andre språk fullført
|
||||
|
||||
Suksesskriterier:
|
||||
- F1 ≥ 96% overall, ≥ 92% per objekter-segment
|
||||
- F1 ≥ 96% overall, ≥ 92% per dokumenttype
|
||||
- Drift-deteksjon kalibrert med terskel
|
||||
- ROS-revisjon godkjent
|
||||
|
||||
|
|
@ -46,8 +46,8 @@ Status: active
|
|||
Milepæler:
|
||||
- Forklaringsmodell (GPT-4 Turbo) integrert via Foundry
|
||||
- saksbehandler-UI bygget (Copilot Studio + Power Platform)
|
||||
- Workflow: AI flagger → saksbehandler reviewer → klar for sanksjon
|
||||
- Brukertest med 12 saksbehandler fra ulike regioner
|
||||
- Workflow: AI flagger → saksbehandler reviewer → klar for vedtak
|
||||
- Brukertest med 12 saksbehandlere fra ulike tjenesteområder
|
||||
|
||||
Suksesskriterier:
|
||||
- Saksbehandlingstid -40% vs baseline
|
||||
|
|
@ -63,7 +63,7 @@ Milepæler:
|
|||
- FRIA gjennomført og godkjent
|
||||
- Conformity assessment ferdigstilt per Annex VI
|
||||
- DPIA oppdatert med nye operasjonelle data
|
||||
- Produksjonssetting til 3 piloter (Oslo, Bergen, Trondheim)
|
||||
- Produksjonssetting i 3 pilotbydeler
|
||||
|
||||
Suksesskriterier:
|
||||
- Personvernombud signerer DPIA
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Status: done
|
|||
Milepæler:
|
||||
- Foundry hub + project i West Europe
|
||||
- Identity og networking konfigurert
|
||||
- Sample-data uploadet (10k anonymiserte objekt-ID)
|
||||
- Sample-data uploadet (10k anonymiserte vedlegg)
|
||||
|
||||
Suksesskriterier:
|
||||
- Inferens-endpoint nåbart fra dev-Vnet via Private Endpoint
|
||||
|
|
@ -27,7 +27,7 @@ Status: active
|
|||
|
||||
Milepæler:
|
||||
- Pre-trent Azure AI Vision OCR pilotert
|
||||
- Custom fine-tune på 10k objekt-ID
|
||||
- Custom fine-tune på 10k vedlegg
|
||||
- Sammenligning av accuracy/latency mellom de to
|
||||
|
||||
Suksesskriterier:
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Klassifisering: høy risiko, rolle Provider+Deployer
|
|||
| Teknisk dokumentasjon (Annex IV) komplett | partial | Art. 11 |
|
||||
| Automatisk logging av hendelser implementert | met | Art. 12 |
|
||||
| Transparens-instruksjoner for deployer skrevet | missing | Art. 13 |
|
||||
| Human-in-the-loop på alle sanksjonsavgjørelser | met | Art. 14 |
|
||||
| Human-in-the-loop på alle vedtak om avslag | met | Art. 14 |
|
||||
| Nøyaktighetsmål med stratifisert testing | partial | Art. 15 |
|
||||
| Cybersikkerhetstiltak verifisert (NSM Grunnprinsipper) | met | Art. 15 |
|
||||
| FRIA gjennomført før idriftsettelse | missing | Art. 27 |
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Reviewers: AI-arkitekt, sikkerhetsarkitekt, Datatilsynet
|
|||
| F-06 | medium | review | Compliance | FRIA-rapport ikke vedlikeholdt etter modell-endring 2026-03-12. Re-evaluering trengs. |
|
||||
| F-07 | medium | keep | UX | saksbehandler-grensesnitt viser ikke konfidensgrad tydelig nok — risiko for over-trust på AI-output. |
|
||||
| F-08 | low | suppressed | Documentation | README mangler oppdatert arkitekturdiagram (siste fra 2025-11). |
|
||||
| F-09 | low | suppressed | Testing | Manglende E2E-test for utenlandske objekt-ID. |
|
||||
| F-09 | low | suppressed | Testing | Manglende E2E-test for henvendelser på andre språk. |
|
||||
|
||||
## Sammendrag
|
||||
|
||||
|
|
|
|||
|
|
@ -8,13 +8,13 @@ Metodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek
|
|||
| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |
|
||||
|---------|---------------|------------|-------|------|
|
||||
| Modell-drift som degraderer nøyaktighet | 4 | 3 | 12 | medium |
|
||||
| Treningsdata-bias mot småbiler eller MC | 3 | 3 | 9 | medium |
|
||||
| Adversarielle plate-design unngår OCR | 2 | 4 | 8 | medium |
|
||||
| Treningsdata-bias mot nynorsk og andre språk | 3 | 3 | 9 | medium |
|
||||
| Manipulerte vedlegg unngår OCR-kontroll | 2 | 4 | 8 | medium |
|
||||
| API-utilgjengelighet i kritisk periode | 2 | 4 | 8 | medium |
|
||||
| Klage-saksbehandling overbelastet ved skalering | 4 | 3 | 12 | medium |
|
||||
| Datatap pga manglende georedundans | 1 | 5 | 5 | low |
|
||||
| Misbruk av AI-forklaring som bevis | 3 | 4 | 12 | medium |
|
||||
| Kjedevirkning ved feil i objektregister | 2 | 5 | 10 | medium |
|
||||
| Misbruk av AI-forklaring som vedtaksbegrunnelse | 3 | 4 | 12 | medium |
|
||||
| Kjedevirkning ved feil i fagsystemet | 2 | 5 | 10 | medium |
|
||||
|
||||
## Radar-akser (7 dimensjoner)
|
||||
|
||||
|
|
@ -33,8 +33,8 @@ Metodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek
|
|||
| ID | Beskrivelse | Severity | Tiltak |
|
||||
|----|-------------|----------|--------|
|
||||
| T-101 | Modell-drift over tid | high | Månedlig retraining-pipeline; alarm ved >2% nøyaktighetsfall |
|
||||
| T-102 | Bias mot småbiler/MC | high | Stratifisert evaluering ved hver release |
|
||||
| T-103 | Adversarielle plate-design | medium | Robusthetstest mot kjente angreps-mønstre |
|
||||
| T-102 | Bias mot nynorsk og andre språk | high | Stratifisert evaluering ved hver release |
|
||||
| T-103 | Manipulerte vedlegg | medium | Robusthetstest mot kjente angreps-mønstre |
|
||||
| T-104 | API-utilgjengelighet | medium | Multi-region failover med RTO 1t |
|
||||
| T-105 | Saksbehandlings-overbelastning | high | Automatisk batching + prioriteringsregler |
|
||||
|
||||
|
|
@ -54,9 +54,9 @@ Metodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek
|
|||
|----|---------|-------|----------|
|
||||
| T-101 | Modell-drift over tid | 12 | high |
|
||||
| T-105 | Saksbehandlings-overbelastning | 12 | high |
|
||||
| T-107 | Misbruk av AI-forklaring som bevis | 12 | high |
|
||||
| T-108 | Kjedevirkning ved feil i objektregister | 10 | high |
|
||||
| T-103 | Bias mot småbiler/MC | 9 | medium |
|
||||
| T-107 | Misbruk av AI-forklaring som vedtaksbegrunnelse | 12 | high |
|
||||
| T-108 | Kjedevirkning ved feil i fagsystemet | 10 | high |
|
||||
| T-103 | Bias mot nynorsk og andre språk | 9 | medium |
|
||||
|
||||
Restrisiko: 4×3 → 2×2
|
||||
|
||||
|
|
|
|||
|
|
@ -29,12 +29,12 @@ Arkitekturen er teknisk solid og økonomisk forsvarlig (P50 NOK 1.7M/år), men c
|
|||
- Lukk F-01 (ABAC) innen 2026-06-15
|
||||
- Gjennomfør FRIA innen 2026-07-15 (Art. 27-frist)
|
||||
- Produksjonsdokumentere transparens-instruksjoner innen 2026-09-01
|
||||
- Pilot 3 regioner (Oslo, Bergen, Trondheim) Q4 2026
|
||||
- Pilot i 3 bydeler Q4 2026
|
||||
- Full utrulling Q2 2027
|
||||
|
||||
## Restrisiko
|
||||
|
||||
Etter foreslåtte tiltak: medium. Hovedeksponering: bias mot utenlandske objekt-ID krever løpende monitoring.
|
||||
Etter foreslåtte tiltak: medium. Hovedeksponering: bias mot henvendelser på andre språk enn norsk krever løpende monitoring.
|
||||
|
||||
## Anbefaling
|
||||
|
||||
|
|
|
|||
|
|
@ -1,18 +1,18 @@
|
|||
# Transparensnotis — Acme Kunde-chatbot
|
||||
|
||||
Tittel: Informasjon om automatisert operasjonell analyse (Art. 13 og Art. 50)
|
||||
Tittel: Informasjon om automatisert forhåndsvurdering av søknader (Art. 13 og Art. 50)
|
||||
|
||||
## Hva systemet gjør
|
||||
|
||||
Acme Kommune bruker et AI-system som leser av objekt-ID (Acme Kunde-chatbot — automatisert klassifisering) fra sensordata langs produksjonsmiljøet. Systemet identifiserer objekter som har overtrådt terskelverdi gjennom å beregne gjennomsnittlig respons mellom to datapunkt.
|
||||
Acme Kommune bruker et AI-system (Acme Kunde-chatbot) som svarer på spørsmål om kommunale tjenester og leser vedlegg du laster opp med en søknad om bostøtte. Systemet vurderer om søknaden er komplett, og om inntekt og boutgifter ser ut til å ligge innenfor vilkårene.
|
||||
|
||||
## Hvilke data som behandles
|
||||
|
||||
Behandlede data inkluderer objekt-ID, tidsstempel, datapunkt, objektklasse og oppslag i Acme Kommune objektregister. Personlig identifiserbar informasjon kobles ikke til oppføring uten saksbehandler eksplisitte godkjenning.
|
||||
Behandlede data inkluderer det du skriver i chatten, opplastede vedlegg, saksnummer, tidsstempel og oppslag i Acme Kommunes fagsystem for bostøtte. Samtalen kobles ikke til søknaden din uten at du samtykker til det i chatten.
|
||||
|
||||
## Hvordan beslutninger tas
|
||||
|
||||
Systemet er beslutningsstøtte, ikke -taker. Hver flagged hendelse går til menneskelig saksbehandler som tar endelig avgjørelse om gebyr eller anmeldelse. AI-output inkluderer konfidensgrad og forklaring av hvorfor saken ble flagget.
|
||||
Systemet er beslutningsstøtte, ikke -taker. Hver flaggede søknad går til en menneskelig saksbehandler som fatter vedtaket. AI-output inkluderer konfidensgrad og forklaring av hvorfor saken ble flagget.
|
||||
|
||||
## Dine rettigheter
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## 1. Bakgrunn og formål
|
||||
|
||||
Acme Kommune har siden 2018 driftet en on-prem Acme Kunde-chatbot-løsning for operasjonell analyse på tvers av leverandørens tjenesteportefølje. Løsningen er basert på et OCR-bibliotek fra 2017 og leveres som et lukket system uten mulighet for retrening eller forbedring av modell. Saksbehandlingen er manuell og tar i snitt 14 minutter per sak. Et internt AI-team utreder modernisering til en skybasert AI-plattform som støtter custom modell-trening, audit-logging på inferens-nivå, og saksbehandler-co-pilot.
|
||||
Acme Kommune har siden 2018 driftet en on-prem Acme Kunde-chatbot-løsning for forhåndsvurdering av søknader på tvers av kommunens tjenesteportefølje. Løsningen er basert på et OCR-bibliotek fra 2017 og leveres som et lukket system uten mulighet for retrening eller forbedring av modell. Saksbehandlingen er manuell og tar i snitt 14 minutter per sak. Et internt AI-team utreder modernisering til en skybasert AI-plattform som støtter custom modell-trening, audit-logging på inferens-nivå, og saksbehandler-co-pilot.
|
||||
|
||||
## 2. Mandat
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ Utredningen skal:
|
|||
|
||||
Utredningen kombinerer:
|
||||
- Kvalitativ analyse av compliance-krav per relevante lover og forskrifter
|
||||
- Kvantitativ TCO-analyse basert på 12 millioner Acme Kunde-chatbot-deteksjoner/mnd
|
||||
- Kvantitativ TCO-analyse basert på 1,2 millioner chatbot-meldinger og vedlegg/mnd
|
||||
- Risikoanalyse per NS 5814 og DPIA per Datatilsynets veileder
|
||||
- Markedsundersøkelse av tilgjengelige plattformer fra Azure, AWS og GCP
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ Utredningen kombinerer:
|
|||
|
||||
### 4.1 Compliance
|
||||
|
||||
EU AI Act klassifiserer systemet som høyrisiko (Annex III, punkt 6 — rettshåndhevelse). Acme Kommune er Provider og Deployer, hvilket trigger alle krav i Art. 9-15 + Art. 27 (FRIA) + Art. 49 (registrering).
|
||||
EU AI Act klassifiserer systemet som høyrisiko (Annex III, punkt 5(a) — tilgang til offentlige ytelser). Acme Kommune er Provider og Deployer, hvilket trigger alle krav i Art. 9-15 + Art. 27 (FRIA) + Art. 49 (registrering).
|
||||
|
||||
### 4.2 Teknologivalg
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ Azure AI Foundry er anbefalt primær plattform fordi:
|
|||
|
||||
### 4.4 Risiko
|
||||
|
||||
Hovedrisiko: bias mot utenlandske objekt-ID, modell-drift over tid, og manglende ABAC-implementering på saksbehandler-tilgang. Alle har konkrete tiltak.
|
||||
Hovedrisiko: bias mot henvendelser på andre språk enn norsk, modell-drift over tid, og manglende ABAC-implementering på saksbehandler-tilgang. Alle har konkrete tiltak.
|
||||
|
||||
## 5. Konklusjon
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue