Personvern: innsyn og sletting av saksdata⚓︎

Hvorfor⚓︎

Kai lagrer avledet saksdata — kopier av saksdokumenter hentet fra Websak, uttrekte fakta, regelresultater og beslutninger — utenfor Websak, som er arkivet og system of record (kilden). For å etterleve GDPR skal Kai ikke bli et permanent skyggearkiv: data om en sak skal kunne finnes (innsyn) og slettes (sletting) på forespørsel, per sak.

Websak er alltid kilden

Sletting i Kai fjerner kun Kais avledede kopi. Originaldokumentene og saksbehandlingen forblir i Websak (arkivplikt) — Kai sletter aldri der.

Hva Kai lagrer per sak, og hvor⚓︎

Sted	Detaljer
Blob	Storage-konto `stkaiplatform{test\\|prod}`, container `saksdokumenter`. Alt for én sak ligger under prefikset `{år}/{løpenummer}/` (f.eks. `26/23982/…`), med undermapper `originaler/`, `analysis/`, `facts/`.
Postgres (database `kai`)	8 saks-avledede tabeller: `saker`, `regelresultater`, `case_document_extractions`, `polling_processed_cases`, `beslutninger`, `stadiegjennomganger`, `case_vehicle_offers`, `vurderinger`.

Øvrige tabeller — regler, workflow-definisjoner, regelgraf, virkemidler, sync-state — er konfigurasjon/oppslagsdata, ikke saksdata, og røres ikke av innsyn/sletting beskrevet her.

Innsyn (finn all data for én sak)⚓︎

Alle Postgres-tabellene nøkles på saksnummeret (tekst «år/løpenummer»), unntatt regelresultater som nøkles på sakens interne sak_id — slå opp sak_id i saker via saksnummer først.
Blob: list blober under prefikset {år}/{løpenummer}/ i containeren saksdokumenter.
Saksbehandlerflaten eksponerer også en lesevisning per sak (GET-endepunktene under /cases/{caseKey}), som kan brukes til et menneskelesbart innsyn uten å gå direkte i databasen.

Kobling til DB

Bruk kai-postgres-connect-skillen for tilkobling; ett SELECT per tabell filtrert på saksnummer / sak_id.

Sletting (slett all data for én sak)⚓︎

Per sak (foretrukket)⚓︎

Admin-endepunktet DELETE /cases/{caseKey} (krever Entra-rollen Administrator).

caseKey bruker bindestrek, ikke skråstrek

caseKey er en URL-slug — sak «26/23982» slettes med DELETE /cases/26-23982. Et skråstrek i path 404-er i Azure App Service.

Endepunktet sletter blob-prefikset og rader i alle 8 tabellene i én operasjon (blob først — idempotent på retry, gir ingen foreldreløse DB-rader ved delvis feil — deretter DB-radene i én transaksjon), og returnerer 200 med et slette-sammendrag:

JSON
{
  "saksnummer": "26/23982",
  "blobsSlettet": 12,
  "raderPerTabell": { "regelresultater": 3, "beslutninger": 5, "...": 0, "saker": 1 }
}

Ukjent sak gir 404.

Arkivér sammendraget

Lagre dette JSON-svaret som dokumentasjon på at slettingen er utført — det er svaret på et slettekrav (hvem, når, hva ble slettet).

Hele miljøet (sjelden)⚓︎

scripts/wipe-case-data.ps1 tømmer all saksdata (blob + alle 8 tabeller) i et miljø — alt-eller-ingenting. Brukes ved f.eks. §13-opprydding, ikke for enkeltsaker.

Retensjon (tidsbasert automatisk sletting) — ikke implementert ennå⚓︎

Når kommer automatisk sletting av gamle saker?

Tidsbasert retensjon besluttes sammen med jurist/arkivar og er ikke bygget i denne omgangen (AC1 i AB#21267 er utsatt). Skisse for når den bygges: en Retensjonspolicy (kompileringstids-default, jf. policy-drevet kode) pluss en TickerQ-cron i workeren som finner saker forbi fristen og kaller samme slette-mekanisme som DELETE /cases/{caseKey} bruker i dag. Den skal være report-only som default (teller/logger kandidater, sletter ingenting) til juridisk frist er bekreftet — deretter skrus håndheving på per miljø via et eksplisitt flagg.

Frem til da: sletting skjer kun manuelt, per sak eller per miljø, som beskrevet over.