Plattform-fortrinn · Audit trail

Audit trail by default

Hver sjekk, hver beslutning, hver datatilgang logges med aktør, tidsstempel og begrunnelse — på tvers av alle brukere, alle agenter og alle MCP-kall. Dette er ikke et Enterprise-tillegg. Det er arkitektur-default.

6 prinsipper

Append-only

Events skrives til tenants/{t}/audit/-samlingen med Firestore security rules som hindrer sletting og oppdatering — også for tenant-admins.

Hash-kjede

Hvert event inkluderer prev_hash og hash (SHA-256 av canonical JSON). Enhver endring i et tidligere event bryter kjeden og oppdages umiddelbart.

Eksport med integrity-sjekk

Regulator kan få signert JSON-eksport med full chain-validering. Strukturen er enkel nok til at eksterne verktøy kan verifisere uten KETL-kunnskap.

Retention: minst 5 år

AMLA-kravet for finansielle aktører. Per-tenant DPA kan forlenge lagringen; forkorting er ikke mulig via produktet.

BigQuery-streaming

Parallell streaming til BigQuery for aggregert analyse. Firestore-kjeden forblir kilde til sannheten — BigQuery er en read-only projection.

Default, ikke tillegg

Audit-logg er aktivert på alle tiers fra Starter og opp — det er ikke et Enterprise-tillegg. Regulator-ready fra dag én.

Hva logges?

KETL logger alle handlinger som har forretnings- eller compliance-konsekvenser:

MCP-tool-kall (action + args + resultat-referanse)
AI-outputs (modellversjon + prompt-hash + konfidens)
Record-endringer (before/after-snapshot)
Saker: åpnet, endret, lukket (med utfall)
Bruker-handlinger: innlogging, invitasjoner, rolleendringer
Dataeksporter (format, størrelse, destinasjon)
Integrasjoner: tilkoblet/frakoblet
Innstillingsendringer
Audit-eksporter (ja — eksport av loggen logges)

Event-skjema

{
  "eventId": "7f3b9...",  // SHA-256 av event
  "tenantId": "tenant-42",
  "ts": "2026-04-20T08:16:45+02:00",
  "actor": {
    "id": "user-anna",
    "type": "user",
    "name": "Anna Hansen"
  },
  "action": "ai.output",
  "target": {
    "type": "analyse",
    "id": "analysis-42",
    "displayName": "Risikovurdering Nordlysmedia AS"
  },
  "before": null,
  "after": { "klassifisering": "middels", "score": 0.42 },
  "sourceRefs": [
    {
      "type": "brreg",
      "id": "913289933",
      "url": "https://data.brreg.no/..."
    }
  ],
  "prevHash": "a82c4...",
  "hash": "7f3b9...",
  "metadata": { "modelVersion": "claude-sonnet-4-6", "confidence": 0.91 }
}

Et regulator-scenario

Finanstilsynet ber et medlem om full sporbarhet for en PEP-beslutning tatt 14 dager tidligere. I KETL:

1. Klienten åpner /dashboard/audit, filtrerer på beslutnings-saken, eksporterer perioden som signert JSON.
2. Eksporten inneholder hele hash-kjeden fra beslutningen, inkludert Brreg-kilden, AI-outputen, menneskelig review og sak-lukkingen — hver sitt event, alle lenket med prev_hash.
3. Finanstilsynet kjører verifyChain() (egen kopi, eller via oss) og ser at integrity.valid === true.
4. Reprodusérbar kilde-til- konklusjon trace. Tid fra forespørsel til svar: typisk under 1 time.

Konkret use-case · for revisorer

Audit-trail som revisjons-dokumentasjon

Revisor må dokumentere arbeidet sitt mot ISA 230 og bevare arbeidspapirene i 10 år (Revisorloven § 8-2). KETL-audit-loggen er denne dokumentasjonen — ikke et tillegg. Tre konkrete mønstre viser hvordan revisor bruker eksport fra `/dashboard/audit`.

Finanstilsynet ber om full sporbarhet for én klient-beslutning

Revisorloven § 8-2 (oppbevaringsplikt 10 år) + ISA 230 (revisjonsdokumentasjon). Finanstilsynet kan kreve dokumentasjon for hver beslutning ved gjennomgang av revisors arbeid.

Utløst av

Finanstilsynet sender skriftlig forespørsel om dokumentasjon på beslutning X tatt for klient Y i periode Z.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = revisor-tenant AND target.id = klient-orgnr AND ts BETWEEN start AND end AND action IN ['ai.output', 'sak.closed', 'record.changed']

Inneholder:

Full hash-kjede fra beslutningen tilbake til kildedata
Hver AI-output med modellversjon, prompt-hash og konfidens
Tidsstemplet kjede av menneskelig review og sak-lukking
Brreg-/Skatt-/SAF-T-kildereferanser med stable URL

Oppfyller dokumentasjons-kravet

ISA 230.8 (innhold i dokumentasjon: arten, omfang og tidspunkt for revisjonshandlinger) + § 8-2 (oppbevaring i minst 10 år). Verifyer `integrity.valid === true` lokalt i Finanstilsynets verktøy.

ai.outputsak.closedrecord.changed

Arkivering av arbeidspapirer ved oppdrags-avslutning

ISA 230.14-15 (sluttføring av samling). Revisor må sammenstille endelig revisjonsdokumentasjon innen 60 dager etter revisjonsberetning og oppbevare i minst 5 år (Revisorloven § 8-2: 10 år i Norge).

Utløst av

Revisor markerer oppdrag som avsluttet i `/dashboard/saker` etter signert revisjonsberetning.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = revisor-tenant AND target.id = klient-orgnr AND ts <= avslutningsdato

Inneholder:

Hele audit-kjeden for klienten gjennom hele oppdraget
Innloggings-events for alle som hadde tilgang til klient-data
Eksport-events (revisor må kunne dokumentere egne eksporter)
Innstillings-endringer (terskler, regler, watchlist-endringer)

Oppfyller dokumentasjons-kravet

ISA 230.14 (sluttføring) + Revisorloven § 8-2 (10 års oppbevaring). Eksporten arkiveres i revisors document management system; KETL-loggen er kilde til sannheten.

ai.outputsak.closedrecord.changeduser.loginaudit.exportsettings.changed

Etterprøving: nær-stående-vurdering på historisk tidspunkt

ISA 550 (nær-stående parter). Hvis en konsern-tilknytning oppdages i ettertid, må revisor kunne dokumentere hva som var kjent på vurderings-tidspunktet — ikke hva som er kjent nå.

Utløst av

Internal kvalitetskontroll eller klage stiller spørsmål ved en nær-stående-vurdering gjort 12-24 mnd tidligere.

Eksport fra /dashboard/audit

Format: JSON

actor.tenant = revisor-tenant AND target.id = klient-orgnr AND ts BETWEEN vurderingstidspunkt-7d AND vurderingstidspunkt+7d

Inneholder:

`record.changed`-events viser hvilke felt i klient-record som var registrert på tidspunktet
`ai.output` med modellversjon og prompt-hash — kan re-kjøres for å verifisere reproduserbarhet
Brreg-kildereferanser med versjons-tidsstempel (point-in-time)
`sak.closed`-event med verdict og hvem som lukket saken

Oppfyller dokumentasjons-kravet

ISA 550.18 (vurdering av nær-stående-transaksjoner). KETL bevarer record-tilstand på vurderings-tidspunktet — ikke bare nåværende tilstand. Beslutningen er forsvarbar med data som faktisk var tilgjengelig da.

ai.outputrecord.changedsak.closed

Konkret use-case · for M&A-konsulenter

Audit-trail som deal-room-arkiv og dispute-grunnlag

M&A-rådgiver må dokumentere arbeidet sitt mot klient-IC, fond-LP- audit-rett og post-closing SPA-disputes. KETL-audit-loggen er denne dokumentasjonen — ikke et tillegg. Tre konkrete mønstre viser hvordan rådgiver bruker eksport fra `/dashboard/audit`.

Investerings-komité ber om sporbarhet for én anbefaling

IMAA pre-deal og deal-execution dokumentasjons-praksis. IC kan kreve etterprøvbar dokumentasjon for hver anbefaling — særlig hvis transaksjonen senere underperformer eller LP stiller spørsmål om DD-grundigheten.

Utløst av

Klient-IC eller fond-LP ber om dokumentasjon på rådgivers anbefaling X for target Y i sourcing- eller DD-perioden.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = radgiver-tenant AND target.id = target-orgnr AND ts BETWEEN start AND end AND action IN ['ai.output', 'case.close', 'record.update']

Inneholder:

Full hash-kjede fra anbefalingen tilbake til kildedata
Hver AI-output med modellversjon, prompt-hash og konfidens på beslutnings-tidspunktet
Tidsstemplet kjede av lead-rådgivers review og IC-memo-signering
Brreg-/SSB-/Doffin-kildereferanser med stable URL og versjons-tidsstempel

Oppfyller dokumentasjons-/audit-kravet

IMAA dokumentasjons-prinsipp + LP-DDQ-audit-rett. Verifyer `integrity.valid === true` lokalt i IC-medlems eller LP-revisors verktøy. Beslutningen er etterprøvbar uten å spørre rådgiver om noe som helst.

ai.outputcase.closerecord.update

Deal-room-arkiv ved closing — alle DD- og forhandlings-events

IMAA execution-fase og standard SPA-praksis. Etter signing er deal-room-loggen bevis-grunnlag hvis selger eller kjøper senere fremsetter krav om informasjons-asymmetri, late disclosure eller breach of representations.

Utløst av

Closing-administrator markerer dealen som signert i `/dashboard/saker`; deal-room arkiveres som vedlegg til SPA.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = radgiver-tenant AND target.id = target-orgnr AND ts <= closing-dato

Inneholder:

Hele audit-kjeden for targetet gjennom hele DD- og forhandlings-perioden
Innloggings-events for alle som hadde tilgang til deal-data (Chinese-walls-bevis)
Eksport-events (rådgiver må kunne dokumentere egne eksporter til klient/IC/fond)
Innstillings-endringer (watchlist-terskler endret under exclusivity, brukerroller endret post-signing)

Oppfyller dokumentasjons-/audit-kravet

IMAA execution-fase + SPA-warranty om informasjons-asymmetri. Eksporten arkiveres i rådgivers document management system og hos klient/selger som bilag til SPA; KETL-loggen er kilde til sannheten.

ai.outputcase.closerecord.updateuser.loginaudit.exportsettings.change

SPA-dispute 18 mnd post-closing — point-in-time DD-grunnlag

IMAA value capture og post-close monitoring. Hvis selger fremsetter dispute (typisk earn-out, indemnification eller breach of warranty) må rådgiver kunne dokumentere hva som faktisk var kjent på DD- eller signing-tidspunktet — ikke hva som er kjent nå.

Utløst av

Klient mottar dispute-varsel fra selger eller motpart 12–24 mnd post-closing om DD-konklusjon eller earn-out-beregning.

Eksport fra /dashboard/audit

Format: JSON

actor.tenant = radgiver-tenant AND target.id = target-orgnr AND ts BETWEEN dd-tidspunkt-7d AND closing-dato+7d

Inneholder:

`record.update`-events viser hvilke felt i target-record som var registrert på DD-tidspunktet
`ai.output` med modellversjon og prompt-hash — kan re-kjøres for å verifisere reproduserbarhet av DD-konklusjon
Brreg-kildereferanser med versjons-tidsstempel (point-in-time)
`case.close`-event med verdict og hvem som lukket DD-saken og med hvilken konklusjon

Oppfyller dokumentasjons-/audit-kravet

IMAA point-in-time dokumentasjons-prinsipp. KETL bevarer record-tilstand på vurderings-tidspunktet — ikke bare nåværende tilstand. Dispute-forsvar er forsvarbart med data som faktisk var tilgjengelig da rådgiver konkluderte.

ai.outputrecord.updatecase.close

Konkret use-case · for undersøkende journalister

Audit-trail som metoderapport-arkiv — kildevernet bevart by design

Redaksjon må dokumentere arbeidet sitt mot PFU-klagebehandling, potensielle æreskrenkelse-søksmål og post-publiserings-overlevering. KETL-audit-loggen er denne dokumentasjonen — ikke et tillegg. Tre konkrete mønstre viser hvordan redaksjon bruker eksport fra `/dashboard/audit` uten å eksponere kildevern (menneskelig kilde-kommunikasjon har aldri vært inne i systemet).

PFU-klage 8 uker post-publisering — point-in-time faktagrunnlag

Vær Varsom-plakaten 4.13 (retting av feil) og PFU-saksbehandlings-regler. Hvis omtalt part fremsetter PFU-klage må redaksjon kunne dokumentere hva som faktisk var kjent på publiserings-tidspunktet — ikke hva som er kjent nå. Klagefristen er 12 uker; redaksjon må kunne re-konstruere kildegrunnlaget for hver påstand i artikkelen.

Utløst av

Redaksjon mottar PFU-klage på publisert artikkel innen 12 uker etter publisering. Klagen henviser typisk til konkret påstand som omtalt part hevder er feil eller uriktig framstilt.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = redaksjon-tenant AND target.id = omtalt-orgnr AND ts BETWEEN research-start AND publiserings-dato AND action IN ['ai.output', 'record.update', 'data.access']

Inneholder:

Full hash-kjede fra publisert påstand tilbake til offentlig kilde
Hver AI-output med modellversjon, prompt-hash og konfidens på vurderings-tidspunktet
Tidsstemplet kjede av journalistens og redaktørens review og signering
Brreg-/SSB-/Kartverket-kildereferanser med stable URL og versjons-tidsstempel
EKSPLISITT: ingen referanse til menneskelige kilder eller kommunikasjon med dem

Oppfyller dokumentasjons-/audit-kravet

VVP 4.13 + PFU-saksbehandlings-regler. Verifyer `integrity.valid === true` lokalt i PFU-sekretariatets eller redaksjonens verktøy. Faktagrunnlaget kan etterprøves uten å eksponere kildevern; det redaksjon påstod på publiserings-tidspunktet er forankret i offentlige registre med dokumentert tidsstempel.

ai.outputrecord.updatedata.access

Subpoena-respons — eksport som bevarer kildevernet

Straffeprosessloven § 125 (kildevern) og Tvisteloven § 22-11. Hvis retten gir pålegg om utlevering av redaksjonelt arbeids-materiale kan redaksjon eksportere KUN aksess til offentlige kilder fra KETL-loggen — menneskelig kilde-kommunikasjon har aldri vært inne i systemet og kan ikke avsløres via metadata. Dette er en bevisst designkonsekvens: KETL logger bare offentlig data-aksess, ikke menneskelige kildeforhold.

Utløst av

Redaksjon mottar rettslig pålegg om utlevering av loggdata for konkret gravesak (typisk forfølger som forsøker å spore kilde gjennom journalistens metadata).

Eksport fra /dashboard/audit

Format: JSON

actor.tenant = redaksjon-tenant AND target.id = omtalt-orgnr AND ts BETWEEN start AND end AND action IN ['data.access', 'mcp.call']

Inneholder:

Aksess-events mot offentlige kilder (Brreg, SSB, Kartverket, Konkursregisteret)
MCP-kall-events mot publiserte tools (offentlig API-overflate)
EKSPLISITT EKSKLUDERT: ingen referanse til menneskelige kilder fordi de aldri har vært i systemet
Audit-eksport-events (transparens om at eksporten skjedde og hvem som utførte den)
Tidstempel på hver aksess slik at retten kan vurdere aktsomhet, men kan ikke utlede kilde-identitet

Oppfyller dokumentasjons-/audit-kravet

Straffeprosessloven § 125 + Tvisteloven § 22-11 + Redaktørplakatens kildevern-prinsipp. KETL-arkitekturen bevarer kildevernet by design — det er ikke et tillegg som kan brytes. Hvis retten ber om kildeinformasjon, finnes den ikke i loggen.

data.accessmcp.callaudit.export

Redaksjons-overlevering — gravesak overtas av ny journalist

Redaktørplakaten og redaksjonell aktsomhets-praksis. Når en pågående gravesak må overleveres (sykdom, jobb-bytte, etterforsknings-utvidelse) må mottakende journalist kunne fortsette uten å miste sporet — og redaktør må kunne se hva som er gjort før overtagelse for å vurdere ansvar og tids-kontinuitet.

Utløst av

Redaktør markerer gravesak for overlevering i `/dashboard/saker`; arkivet pakkes som overleverings-pakke til mottakende journalist.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = redaksjon-tenant AND target.id = omtalt-orgnr AND ts <= overlevrings-dato

Inneholder:

Hele audit-kjeden for gravesaken gjennom hele forskningsperioden
AI-outputs med modellversjon og prompt-hash slik at ny journalist kan re-kjøre vurderinger
Record-update-events viser hvilke fakta som er bekreftet og hvilke som fortsatt er hypoteser
Innstillings-endringer (watchlist-terskler, tilgangstyper) slik at ny journalist arver samme overvåking
EKSPLISITT EKSKLUDERT: kilde-kontakt-informasjon overleveres separat (utenfor KETL) i tråd med kildevern-praksis

Oppfyller dokumentasjons-/audit-kravet

Redaktørplakatens kontinuitets-prinsipp + redaksjonell aktsomhets-praksis. Overleveringen sikrer at gravesakens kvalitet ikke faller ved personell-bytte; samtidig bevares skillet mellom systemets logg (offentlige fakta) og kildevernet (utenfor systemet).

ai.outputrecord.updatesettings.changeaudit.export

Konkret use-case · for AI-startups

SOC2/ISO/GDPR-bevisgrunn uten å bygge eget audit-system

Enterprise-kunder krever SOC2 CC7.2-bevisgrunn fra leverandører. Startup-en skipper å bygge: eget audit-API, eget tamper-evident event-store, eget IR-/forensics-loggsystem, eget Drata/Vanta- integrasjons-lag. Ketl audit-kjeden er forensics-grade fra dag én og kan eksporteres som JSON for kundens revisor, for IR- rapport innenfor GDPR art. 33-fristen, og for startup-ens egen kvartalsvise SOC2 Type II-eksport.

Kundens revisor ber om audit-eksport (SOC2 CC7.2)

SOC2 CC7.2 (system anomalies are detected and corrected) + ISO 27001 A.12.4 (logging og monitorering) + GDPR art. 30 (records of processing activities). Når enterprise-kunden av startup-en gjennomgår sin egen SOC2-audit, må kunden kunne dokumentere at deres SaaS-leverandører har audit-logging på plass. Startup-en kan eksportere Ketl audit-kjede direkte til kundens revisor uten å bygge eget audit-API.

Utløst av

Enterprise-kundens revisor ber om dokumentasjon på audit-logging hos startup-en (typisk under SOC2-renewal eller ISO 27001-resertifisering).

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = startup-kunde-tenant AND ts BETWEEN audit-periode-start AND audit-periode-end AND action IN ['data.access', 'data.export', 'record.update', 'user.role-change', 'settings.change']

Inneholder:

Tamper-evident hash-kjede fra periode-start til periode-end
Alle data-access-events for kundens orgnr med actor-identitet og tidsstempel
Settings-change-events (watchlist-terskler, rolle-tildelinger) som påvirket kundens data
Data-export-events som dokumenterer hvem som tok kundens data ut av systemet
User-role-change-events for å oppfylle SoD (separation of duties) krav

Hva startup-en skipper å bygge

SOC2 CC7.2 + ISO 27001 A.12.4 + GDPR art. 30. Verifyer `integrity.valid === true` i kundens revisor sitt verktøy. Startup-en skipper å bygge: eget audit-API, eget audit-eksport-format, eget retention-system, eget SoD-bevisgrunnlag. Kundens revisor får standardisert JSON som lett kan parses av populære audit-verktøy (Drata, Vanta, Secureframe).

data.accessdata.exportrecord.updateuser.role-changesettings.change

Sikkerhetshendelse — IR/forensics-rekonstruksjon

NIST CSF DE.AE-3 (event data are collected and correlated from multiple sources) + GDPR art. 33 (notification of personal data breach). Hvis startup-en oppdager mistenkelig tilgang (lekkasje, ulovlig API-bruk, kompromittert API-nøkkel), må de re-konstruere hvem som aksesserte hva i hvilken tidsperiode for å forstå skopen. Ketl audit-kjeden er denne forensics-loggen — startup-en skipper å bygge eget security-event-correlation-system.

Utløst av

Startup-ens on-call team mottar varsel om mistenkelig tilgang (anomaly-deteksjon, kompromittert API-nøkkel, kunde-rapport om lekkasje).

Eksport fra /dashboard/audit

Format: JSON

actor.type = 'api-key' AND actor.id = kompromittert-key-id AND ts BETWEEN incident-start AND incident-end

Inneholder:

Alle handlinger med kompromittert API-nøkkel (data.access, mcp.call, data.export)
Hash-kjede-verifikasjon at loggen ikke er tamperet etter angrep (kritisk for IR-rapport)
Korrelasjon mot hvilke tenants ble berørt (bevis for GDPR art. 33-varslings-omfang)
Tidsstemplet kjede av når API-nøkkelen ble suspended (response-tid for IR-rapport)

Hva startup-en skipper å bygge

NIST CSF DE.AE-3 + GDPR art. 33 (72-timers brudd-varsling). Startup-en skipper å bygge: eget IR-loggsystem, eget tamper-evident event-store, eget multi-tenant correlations-lag, eget breach-notification-bevisgrunnlag. Audit-kjeden er forensics-grade fra dag én; startup-en kan levere strukturert IR-rapport innenfor 72-timers fristen uten å rekonstruere noe fra application-logger.

data.accessdata.exportmcp.callaudit.export

SOC2 Type II — bevisgrunn for tilgangs- og endringskontroll

SOC2 Type II Trust Service Criteria CC6.1 (logical and physical access controls) + CC6.6 (transmits and disposes of confidential information) + CC8.1 (manages changes to infrastructure). Når startup-en selv går gjennom SOC2 Type II-audit må de levere kontinuerlig bevisgrunn for 6-12 måneders periode. Ketl audit-kjeden dekker tilgangs-, endrings- og data-handling-kontroller — startup-en skipper å bygge eget compliance-loggsystem fra scratch.

Utløst av

Startup-ens compliance-team forbereder kvartalsvis SOC2-eksport for ekstern revisor (typisk Drata / Vanta / Secureframe via API-integrasjon).

Eksport fra /dashboard/audit

Format: JSON + PDF

tenantId = startup-egen-tenant AND ts BETWEEN periode-start AND periode-end AND action IN ['user.login', 'user.role-change', 'user.invite', 'settings.change', 'integration.connect', 'audit.export']

Inneholder:

Hele audit-kjeden for startup-ens egen tenant i 90-dagers vinduer (kvartalsvis)
User-login-events for at-rest tilgangs-kontroll-bevis (CC6.1)
User-role-change-events for SoD-/least-privilege-bevis (CC6.1)
Integration.connect/disconnect-events for tredjeparts-tilgangs-bevis (CC6.6)
Settings.change-events for change-management-bevis (CC8.1)
Audit.export-events for å vise at compliance-rapportering selv er logget (CC7.2)

Hva startup-en skipper å bygge

SOC2 Type II CC6.1 + CC6.6 + CC7.2 + CC8.1. Startup-en skipper å bygge: eget multi-criteria audit-system, eget tilgangs-kontroll-loggsystem, eget change-management-loggsystem, eget kontinuerlig compliance-eksport-API. Ketl-loggen er allerede SOC2-grade (append-only, hash-kjede, signed eksport); kvartalsvis eksport kan automatiseres mot Drata/Vanta-API uten ekstra arbeid.

user.loginuser.role-changeuser.invitesettings.changeintegration.connectaudit.export

Konkret use-case · for kommunal saksbehandler

Innsynsbegjæring, klagebehandling og kontrollutvalg — sammenstilt på timer

Offentleglova § 9 (sammenstilling) krever at kommunen kan levere sammenstilt dokumentasjon innen 5 arbeidsdager. Forvaltningsloven § 28 (klagerett) og § 33 (klage-instansens kompetanse) krever point-in-time-grunnlag for vedtaks-etterprøving. Kommuneloven § 23-2 (kontrollutvalg) og § 25-1 (internkontroll) krever revisor-eksport for forvaltningsrevisjon. Hvert mønster her er forsvarlig mot fylkesmann/statsforvalter, pressens innsyns-begjæringer og kommunal revisjon.

Innsynsbegjæring etter Offentleglova § 9 — sammenstilt respons innen 5 dager

Offentleglova § 9 (rett til sammenstilling — den som krever innsyn kan kreve at opplysninger sammenstilles fra ulike kilder) og § 32 (klagebehandling — vedtak om avslag kan påklages). Kommunen må kunne levere sammenstilt dokumentasjon innen 5 arbeidsdager (saksbehandlings-frist) uten å måtte gjøre om hele saks-utredningen — særlig viktig når presse eller interesseorganisasjoner ber om innsyn i leverandør-oppfølging eller tilskuddsforvaltning.

Utløst av

Presse, organisasjon eller borger sender innsynsbegjæring via eInnsyn eller per e-post om sak X (typisk leverandør Y for periode Z, eller tilskuddsforvaltning for kategori Æ).

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = kommune-tenant AND target.id = sak-id OR target.id = leverandor-orgnr AND ts BETWEEN start AND end

Inneholder:

Full hash-kjede for sak-/leverandør-oppfølgingen i den begjærte perioden
Hver AI-output med modellversjon, prompt-hash og konfidens på beslutnings-tidspunktet
Tidsstemplet kjede av saksbehandlers review og vedtaks-signering
Brreg-/Skatteetaten-/Doffin-kildereferanser med stabil URL og versjons-tidsstempel
Personvern-redigerings-spor (hvilke felt er sladdet etter Offentleglova § 13 jf. Forvaltningsloven § 13)

Hvordan eksporten oppfyller kravet

Offentleglova § 9 sammenstillings-rett + § 30 saksbehandlings-frist. PDF-rapport eksponeres i eInnsyn med personvern-redigerte felt; JSON-pakka går til arkiv for evt. klagebehandling. Verifyer `integrity.valid === true` lokalt slik at klage-instans (statsforvalter) kan kontrollere at sammenstillingen er forsvarlig.

ai.outputcase.closerecord.updatedata.accessaudit.export

Klagebehandling — statsforvalter etterprøver vedtaks-grunnlaget

Forvaltningsloven § 28 (klagerett) og § 33 (klage-instansens kompetanse — klage-instansen kan prøve alle sider av saken). Når part klager på vedtak må kommunen kunne dokumentere hva som faktisk var grunnlaget på vedtaks-tidspunktet — ikke en oppdatert versjon. Statsforvalter (klage-instans) kan etterprøve både faktum, lovanvendelse og forvaltnings-skjønn, og krever point-in-time-grunnlag.

Utløst av

Part eller statsforvalter ber om dokumentasjon på saksbehandlingen for vedtak X om motpart Y i perioden mellom søknad og vedtak.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = kommune-tenant AND target.id = sak-id AND ts BETWEEN soknads-dato-14d AND vedtaks-dato+14d

Inneholder:

`record.update`-events viser hvilke felt i motparts-record som var registrert på vedtaks-tidspunktet (Brreg-snapshot, Skatteetaten-status, sanksjons-screening)
`ai.output` med modellversjon og prompt-hash — kan re-kjøres for å verifisere reproduserbarhet av vedtaks-grunnlaget
Brreg-/Skatteetaten-kildereferanser med versjons-tidsstempel (point-in-time)
`case.close`-event med verdict og hvem som signerte vedtaket og med hvilken begrunnelse
Forhåndsvarsel-spor (`settings.change` / `data.export` av forhåndsvarsel-utsendelse iht. Forvaltningsloven § 16)

Hvordan eksporten oppfyller kravet

Forvaltningsloven § 33 klage-instansens kompetanse. KETL bevarer record-tilstand på vedtaks-tidspunktet — ikke bare nåværende tilstand. Klagebehandlingen er forsvarbar med data som faktisk var tilgjengelig da saksbehandler konkluderte. Statsforvalter kan etterkontrollere både utredningsplikten (§ 17) og begrunnelsen (§ 25).

ai.outputrecord.updatecase.closesettings.change

Kontrollutvalg-gjennomgang — internkontroll-bevis for revisor-utvalget

Kommuneloven 2020 § 23-2 (kontrollutvalgets oppgaver — påse at kommunens internkontroll fungerer) og § 25-1 (internkontroll — kommunedirektøren skal påse at administrasjonen drives i samsvar med lov og forskrift). Kontrollutvalget kan kreve dokumentasjon på at kommunens internkontroll-systemer fanger og behandler hendelser i samsvar med rutinene — ofte i forbindelse med kommunens årsregnskaps-revisjon eller særskilt forvaltningsrevisjon.

Utløst av

Kontrollutvalget eller kommunal revisjon ber om dokumentasjon på at internkontroll-systemet håndterte event-typene X (typisk leverandør-konkurs, eierskifte, sanksjons-treff) i samsvar med kommunens rutiner i perioden Y.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = kommune-tenant AND action IN ['case.open', 'case.close', 'ai.output'] AND ts BETWEEN ar-start AND ar-slutt

Inneholder:

Aggregert oversikt: antall saker per event-type, gjennomsnitts-reaksjonstid, andel innen SLA
Hver `case.open`-event med trigger-event-id og første-vurdering (AI-triage)
Hver `case.close`-event med verdict, ansvarlig saksbehandler, og hvor lang tid det tok fra trigger til lukking
Eksport-events (revisor må kunne dokumentere at kommunen har levert audit-eksport til kontrollutvalg minst en gang per år)
Innstillings-endringer (regler/terskler endret i perioden — dokumenter at endringene er begrunnet og dokumentert)

Hvordan eksporten oppfyller kravet

Kommuneloven § 23-2 og § 25-1 + Forskrift om kontrollutvalg og revisjon § 4. Eksporten arkiveres i kontrollutvalgets sakshåndteringssystem og hos kommunal revisjon som bilag til forvaltningsrevisjons-rapport eller årsrevisjon; KETL-loggen er kilde til sannheten for at saksbehandling skjedde i samsvar med fastsatt internkontroll.

ai.outputcase.opencase.closerecord.updateaudit.exportsettings.change

Konkret use-case · for eiendomsmegler og proptech

RfE-reklamasjon, oppdrags-arkiv og boliglån-tilsynsbevis — point-in-time-grunnlag

Eiendomsmeglingsloven § 3-7 krever oppdrags-arkivering; Bokføringsloven § 13 krever 10 års bevaring for meglerselskap. Avhendingsloven § 4-12 gir kjøper opp til 5 års reklamasjons- frist; Reklamasjonsnemnda for eiendomsmeglings-tjenester (RfE) behandler klager mot megler. Finanstilsynets rundskriv 7/2014 krever løpende LTV-overvåking i boliglån-portefølje. Hvert mønster her er forsvarlig mot RfE, tilsyn og forsikrings- saksbehandling — point-in-time-grunnlag på prospekt-/ overdragelses-/utstedelses-tidspunktet.

RfE-reklamasjon — kjøper hevder opplysningssvikt etter overdragelse

Eiendomsmeglingsloven § 6-3 (god meglerskikk) og Avhendingsloven § 3-7 / § 4-12 (selgers opplysningsplikt + mangler). Reklamasjonsnemnda for eiendomsmeglings-tjenester (RfE) behandler klager mot megler innenfor relativ frist på typisk 12-24 mnd etter overtakelse. Megler må kunne dokumentere hva som var kjent og kommunisert til kjøper på prospekt-/overdragelses-tidspunktet — ikke retrospektiv tilstand.

Utløst av

Kjøper sender klage til RfE eller direkte til megler om opplysningssvikt eller mangler oppdaget post-overtagelse for eiendom X (matrikkel-id) i meglers tidligere oppdrag Y.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = megler-tenant AND target.id = matrikkel-id OR target.id = oppdrag-id AND ts BETWEEN prospekt-dato-30d AND overdragelses-dato+30d

Inneholder:

Full hash-kjede fra prospekt-publisering til overdragelse for eiendommen
Hver AI-output med modellversjon, prompt-hash og konfidens på prospekt-tidspunktet
Tidsstemplet kjede av meglers gjennomgang og prospekt-signering
Kartverket-/Brreg-kildereferanser med stabil URL og versjons-tidsstempel (point-in-time-grunnlag)
Eksport-events (megler må kunne dokumentere hvilke versjoner av prospekt og takst som ble distribuert til kjøper og når)

Hvordan eksporten oppfyller kravet

Eiendomsmeglingsloven § 6-3 jf. avhendings-lova § 3-7. PDF-rapport går til megler-faglig leder for vurdering av RfE-svar; JSON-pakka går til evt. forsikrings-saksbehandling. Verifyer `integrity.valid === true` lokalt slik at RfE eller motpartens advokat kan kontrollere at fremstillingen er forsvarlig.

ai.outputcase.closerecord.updatedata.export

Oppdrags-arkiv ved avslutning — Bokføringsloven § 13 (10 års bevaring)

Eiendomsmeglingsloven § 3-7 (megler-foretak plikter å oppbevare dokumenter) og Bokføringsloven § 13 (regnskapsmessig bevaringsplikt 10 år). Etter at megleroppdrag avsluttes (vellykket transaksjon eller oppsigelse) må megler-foretaket arkivere komplett dokumentasjon på alle vesentlige steg.

Utløst av

Saksbehandler markerer oppdraget som avsluttet i `/dashboard/saker`; oppdraget skal arkiveres som komplett pakke for 10-års bevaring.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = megler-tenant AND target.id = oppdrag-id AND ts <= oppdrags-avslutnings-dato

Inneholder:

Hele audit-kjeden for oppdraget gjennom hele varigheten (prospekt-publisering til overdragelse + post-transaksjons-oppfølging)
Innloggings-events for alle som hadde tilgang til oppdrags-data (kapasitets-/sensitivitets-spor)
Eksport-events (megler må kunne dokumentere egne eksporter til kjøper, selger, lender og motpartens advokat)
Innstillings-endringer (oppdrags-detaljer endret under transaksjon, brukerroller endret post-overdragelse)

Hvordan eksporten oppfyller kravet

Eiendomsmeglingsloven § 3-7 + Bokføringsloven § 13. Eksporten arkiveres i meglers permanente oppdrags-arkiv; KETL-loggen er kilde til sannheten for hva som faktisk skjedde i oppdraget. Tåler både Finanstilsynets tilsyns-gjennomgang og evt. domstols-bevisbyrde.

ai.outputcase.closerecord.updateuser.loginaudit.exportsettings.change

Boliglån-tilsynsbevis — Finanstilsynets rundskriv 7/2014 LTV-overvåking

Finanstilsynets rundskriv 7/2014 (boliglån) krever at lender løpende dokumenterer LTV-overvåking gjennom lånets levetid. Ved tilsyns-gjennomgang må lender kunne dokumentere at hver materiell LTV-bevegelse er fanget, vurdert og behandlet iht. internkontroll-rutiner.

Utløst av

Finanstilsynet varsler tilsyns-besøk eller kreditt-team gjennomfører kvartalsvis intern revisjon av boliglån-portefølje-håndtering for periode X.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = lender-tenant AND action IN ['ai.output', 'case.open', 'case.close'] AND ts BETWEEN periode-start AND periode-slutt

Inneholder:

Aggregert oversikt: antall LTV-flagg per periode, gjennomsnittlig reaksjons-tid, andel innen SLA
Hver `case.open`-event med trigger-event-id og første LTV-vurdering (AI-triage)
Hver `case.close`-event med verdict, ansvarlig kreditt-team-medlem, og hva som ble gjort med lånet (varsel/omforhandling/lukket som ikke-material)
Eksport-events (kreditt-team må kunne dokumentere at LTV-rapport har blitt levert til intern revisjon minst kvartalsvis)
Kartverket-kildereferanser med versjons-tidsstempel — LTV-beregningen er sporbar mot ekstern autoritativ kilde

Hvordan eksporten oppfyller kravet

Finanstilsynets rundskriv 7/2014 + boliglån-forskriften. Eksporten arkiveres i lender sin tilsyns-arkiv og kan presenteres til Finanstilsynet eller intern revisjon som bevis for kontinuerlig LTV-overvåking; KETL-loggen er kilde til sannheten for at internkontroll-systemet håndterte LTV-bevegelser i samsvar med fastsatte rutiner.

ai.outputcase.opencase.closerecord.updateaudit.export

Konkret use-case · for bank-/fintech-compliance

Finanstilsynet-tilsyn, Økokrim MT-rapport og intern revisor — 5 års bevaring

Hvitvaskingsloven § 25 + EU AMLA art. 25 krever 5 års dokumentasjons-plikt for kundetiltak. Finanstilsynet kan kreve tilsyns-bevis kvartalsvis eller ved varslet tilsyns-besøk. Økokrim mottar MT-rapport ved mistenkelig transaksjon — krever bevisgrunn for hvorfor compliance vurderte transaksjonen som mistenkelig. Intern revisor gjennomfører kvartalsvis KYB-/AML- rutine-gjennomgang. Hvert mønster her er forsvarlig mot Finanstilsynet, Økokrim og intern revisor.

Finanstilsynet-tilsyn — KYB-/AML-rutinebevis innen tilsyns-frist

Finanstilsynets rundskriv 8/2019 (KYB hvitvasking) + Hvitvaskingsloven § 25 (rapporteringsplikt) + EU AMLA art. 25 (5 års dokumentasjons-plikt). Ved tilsyns-besøk eller skriftlig forespørsel må compliance-team kunne dokumentere hvordan KYB-/AML-rutinene har vært gjennomført for periode X — fra kunde-onboarding til løpende oppfølging til evt. skjerpede tiltak.

Utløst av

Finanstilsynet varsler tilsyns-besøk eller sender skriftlig informasjons-forespørsel om KYB-/AML-praksis for periode X (typisk kvartal eller halvår).

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = bank-tenant AND action IN ['ai.output', 'case.open', 'case.close', 'record.update'] AND ts BETWEEN periode-start AND periode-slutt

Inneholder:

Aggregert oversikt: antall kunder onboarded, sanksjons-flagg behandlet, PEP-status-endringer, skjerpede tiltak iverksatt, MT-rapporter sendt
Hver `case.open`-event med trigger-event-id og første-vurdering (AI-triage)
Hver `case.close`-event med verdict, ansvarlig saksbehandler, og hvor lang tid det tok fra trigger til lukking
Eksport-events (compliance-team må kunne dokumentere at periodiske rapporter har blitt levert til Finanstilsynet og intern revisor minst kvartalsvis)
Innstillings-endringer (KYB-/AML-policy oppdatert i perioden — dokumenter at endringene er begrunnet og signert av compliance-leder)

Hvordan eksporten oppfyller kravet

Finanstilsynets rundskriv 8/2019 + Hvitvaskingsloven § 25 + EU AMLA art. 25. PDF-rapport leveres til Finanstilsynet med personvern-redigerte felt; JSON-pakka går til intern revisor for verifikasjon. Verifyer `integrity.valid === true` lokalt slik at Finanstilsynet kan kontrollere at rapporteringen er forsvarlig.

ai.outputcase.opencase.closerecord.updateaudit.export

Økokrim MT-rapport — bevisgrunn for mistenkelig transaksjon

Hvitvaskingsloven § 25 (rapporteringsplikt om mistenkelig transaksjon til Økokrim). MT-rapport må være forankret i konkret beslutnings-grunnlag som dokumenterer hvorfor compliance vurderte transaksjonen som mistenkelig og hva som ble gjort for å verifisere mistanken før rapportering.

Utløst av

Compliance-leder treffer beslutning om å sende MT-rapport til Økokrim om kunde X eller transaksjon Y. Beslutnings-grunnlaget må arkiveres som vedlegg til rapporten.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = bank-tenant AND target.id = kunde-orgnr AND ts BETWEEN onboarding-dato AND mt-rapport-dato

Inneholder:

Hele audit-kjeden for kundeforholdet fra onboarding til MT-rapport-tidspunktet
Hver AI-output med modellversjon, prompt-hash og konfidens — kan re-kjøres for å verifisere reproduserbarhet av mistanke-grunnlaget
Tidsstemplet kjede av compliance-leders signering av skjerpede tiltak før MT-rapport
Sanksjons-/PEP-screening-resultater med kilde-/tidsstempel — viser at vurderingen var basert på oppdaterte lister
Brreg-/transaksjons-data med versjons-tidsstempel (point-in-time-grunnlag for mistanken)

Hvordan eksporten oppfyller kravet

Hvitvaskingsloven § 25 + EU AMLA art. 29 (forklarings-plikt for skjerpede tiltak). Eksporten arkiveres som vedlegg til MT-rapport hos Økokrim; intern kopi bevares minst 5 år iht. AMLA art. 25. Bevarer point-in-time-grunnlaget slik at Økokrim kan etterkontrollere mistankens forsvarlighet uten å gjøre om hele saks-undersøkelsen.

ai.outputcase.closerecord.updatedata.export

Intern revisor — kvartalsvis KYB-/AML-rutine-gjennomgang

Finanstilsynets rundskriv 8/2019 + intern revisors mandat. Intern revisor gjennomfører periodiske gjennomganger av compliance-funksjonen for å sikre at KYB-/AML-rutinene fungerer iht. policy og at compliance-team håndterer hendelser innen interne SLA.

Utløst av

Intern revisor varsler kvartalsvis KYB-/AML-rutine-gjennomgang for periode X (typisk Q1/Q2/Q3/Q4).

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = bank-tenant AND action IN ['case.open', 'case.close', 'ai.output'] AND ts BETWEEN kvartal-start AND kvartal-slutt

Inneholder:

Aggregert SLA-oversikt: gjennomsnitts-reaksjonstid fra trigger til case.open, fra case.open til case.close per priority-nivå
Liste over saker som overskred SLA — med eskalerings-spor
Liste over saker som ble lukket auto vs. saker som krevde compliance-leder-signering
Trend-analyse: er det økning/reduksjon i sanksjons-flagg, PEP-status-endringer eller skjerpede tiltak vs. tidligere kvartal
Eksport-events (compliance-team må kunne dokumentere at kvartalsvise eksporter har blitt levert til intern revisor)

Hvordan eksporten oppfyller kravet

Finanstilsynets rundskriv 8/2019 + intern revisors mandat + bankens egen KYB-/AML-policy. Eksporten arkiveres i intern revisors sak-system som bilag til kvartalsvis revisor-rapport til bankens styre eller revisjonsutvalg.

ai.outputcase.opencase.closerecord.updateaudit.exportsettings.change

Konkret use-case · for aktuar og forsikring

Tilsynsbevis og IFRS 17-revisor-eksport

Aktuar må dokumentere arbeidet sitt mot Finanstilsynet, ansvarshavende-aktuar-funksjonen og ekstern IFRS 17-revisor. KETL-audit-loggen er denne dokumentasjonen — ikke et tillegg. Tre konkrete mønstre viser hvordan aktuar bruker eksport fra `/dashboard/audit` for tilsynssvar, revisjon av onerous- reklassifisering og operational-risk-rekonstruksjon.

Finanstilsynet ber om dokumentasjon på risiko-vurdering

Forsikringsvirksomhetsloven § 14-2 (Finanstilsynets adgang til opplysninger) og Solvency II Pillar 3 art. 51-55 (Supervisory reporting). Når Finanstilsynet etterspør dokumentasjon på en konkret risiko-vurdering (f.eks. ORSA-konklusjon eller onerous-reklassifisering) må aktuar kunne reprodusere beslutnings-grunnlaget point-in-time.

Utløst av

Finanstilsynet ber om dokumentasjon på risiko-vurdering X for portefølje Y i tilsynsperiode Z (typisk under årlig tilsyn eller ved ekstraordinær henvendelse).

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = forsikrings-tenant AND target.id = portefolje-orgnr AND ts BETWEEN tilsyns-periode-start AND tilsyns-periode-end AND action IN ['ai.output', 'case.close', 'record.update']

Inneholder:

Full hash-kjede fra risiko-vurderingen tilbake til kildedata
Hver AI-output med modellversjon, prompt-hash og konfidens på vurderings-tidspunktet
Tidsstemplet kjede av ansvarshavende aktuars review og signering
Brreg-/SSB-/Kartverket-kildereferanser med stable URL og versjons-tidsstempel
case.close-events for å vise hvordan event-driven trigger ble håndtert (jf. Solvency II Pillar 2)

Oppfyller dokumentasjons-/tilsyns-kravet

Forsikringsvirksomhetsloven § 14-2 + Solvency II Pillar 3. Verifyer `integrity.valid === true` lokalt i Finanstilsynets verktøy. Risiko-vurderingen er etterprøvbar uten å spørre aktuar om noe som helst — Finanstilsynet kan re-konstruere hvilke data aktuar hadde tilgang til på vurderings-tidspunktet.

ai.outputcase.closerecord.update

IFRS 17-revisor reviderer onerous-reklassifisering

IFRS 17 art. 17.16 + ISA 540 (Revisjon av estimater med betydelig usikkerhet) + IAA Application Standard 1. Ekstern revisor må kunne reprodusere hver onerous-reklassifisering og loss recognition-justering — særlig i revisjon av forsikrings-tekniske avsetninger som er en hovedrisiko i forsikrings-revisjon.

Utløst av

Ekstern IFRS 17-revisor ber om dokumentasjon på onerous-reklassifisering for kontrakt-gruppe X i regnskapsperiode Y (typisk under årsregnskaps-revisjon).

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = forsikrings-tenant AND target.id = kontrakt-gruppe-id AND ts <= regnskaps-periode-end AND action IN ['ai.output', 'record.update', 'case.close', 'data.export']

Inneholder:

Hele audit-kjeden for kontrakt-gruppen gjennom hele regnskapsperioden
AI-output for IFRS 17 LRA-trigger med modellversjon og prompt-hash for reproduserbarhet
Record-updates som viser baseline-endringer (combined ratio, sesong-justering)
case.close-events for onerous-reklassifisering med ansvarshavende aktuars signatur og override-notater
data.export-events for å dokumentere hvilke data ble brukt i kvartalsvise IFRS 17-rapporter

Oppfyller dokumentasjons-/tilsyns-kravet

IFRS 17 art. 17.16 + ISA 540 + Finanstilsynets rundskriv om actuarial reserving. Verifyer `integrity.valid === true` lokalt i revisors verktøy. Eksporten arkiveres i revisors permanente arkiv som vedlegg til IFRS 17-arbeidspapir.

ai.outputrecord.updatecase.closedata.export

Operational risk — sikkerhetshendelse-konsekvensvurdering

Solvency II art. 101 (operational risk capital requirement) + Finanstilsynets rundskriv 6/2018 om operasjonell risiko + GDPR art. 33. Hvis sikkerhetshendelse påvirker portefølje-data (uautorisert tilgang, datalekkasje, integritet-svikt), må aktuar kunne rekonstruere hva som var kjent før hendelsen for å vurdere ORSA-konsekvens og evt. notice til Finanstilsynet.

Utløst av

Sikkerhetsteam rapporterer hendelse som påvirker portefølje-data; aktuar må vurdere om hendelsen har ORSA-konsekvens og om Solvency II SCR for operasjonell risiko må re-kalibreres.

Eksport fra /dashboard/audit

Format: JSON

actor.tenant = forsikrings-tenant AND ts BETWEEN incident-start-72t AND incident-end AND action IN ['data.access', 'data.export', 'user.role-change', 'settings.change']

Inneholder:

Aksess-events mot portefølje-data 72 timer før hendelsen (for forensics-rekonstruksjon)
Settings-change-events for å dokumentere om risiko-terskler ble endret i incident-perioden
User-role-change-events for å dokumentere SoD-/least-privilege-status
Data-export-events for å dokumentere om portefølje-data ble eksportert i mistenkelig vindu
Hash-kjede-verifikasjon at audit-loggen ikke er tamperet etter hendelsen

Oppfyller dokumentasjons-/tilsyns-kravet

Solvency II art. 101 + GDPR art. 33 (72-timers brudd-varsling). Operational risk-rekonstruksjonen er ORSA-grunnlag for SCR-re-kalibrering; samtidig er den GDPR-forensics-grunnlag for brudd-varsling. Aktuar kan dokumentere hendelse-omfang til både Finanstilsynet og Datatilsynet uten å bygge eget forensics-loggsystem.

data.accessdata.exportuser.role-changesettings.change

Konkret use-case · for forretningsjuridisk advokat

Klient-utlevering, tvist-bevis og etisk utvalg — 10 års bevaring

Advokatforeningens retningslinjer krever 10 års bevaring av oppdrags-arkiv. Tvisteloven kap. 21 krever at bevis-fremleggelse opptil 5 år etter sak-avslutning kan presenteres med kilde og uendret innhold. Domstolloven § 224 setter taushetsplikt mot tredjepart (men ikke mot klient ved utlevering). Etisk utvalg gjennomfører kvartalsvis interessekonflikt-revisjon. Hvert mønster her er forsvarlig mot Advokatforeningens tilsyn, domstol og firmaets etiske utvalg.

Klient-utlevering — full oppdrags-historikk på forespørsel

Advokatforeningens retningslinjer for klient-utlevering (klient har rett til full innsyn i egne oppdrags-dokumenter) og Domstolloven § 224 (taushetsplikt mot tredjepart, ikke mot klient selv). Når klient ber om utlevering — typisk ved bytte av advokatfirma eller ved klage-vurdering — må firmaet kunne levere komplett oppdrags-arkiv innen rimelig frist.

Utløst av

Klient ber skriftlig om utlevering av komplett oppdrags-arkiv for oppdrag X, typisk ved bytte av advokatfirma eller klage-vurdering.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = advokatfirma-tenant AND target.id = oppdrag-id AND ts BETWEEN oppdrags-start AND oppdrags-avslutning

Inneholder:

Hele audit-kjeden for oppdraget — fra konflikt-test og KYB-onboarding til avslutning
Hver AI-output med modellversjon, prompt-hash og konfidens — gir klient mulighet til å verifisere AI-grunnlaget for rådgivningen
Tidsstemplet kjede av ansvarlig advokats signering av materielle vurderinger
Brreg-/Kartverket-/Lovdata-kildereferanser med stabil URL og versjons-tidsstempel
Eksport-events (advokat må kunne dokumentere hvilke dokumenter som ble distribuert til klient og motpart i oppdrags-perioden)

Hvordan eksporten oppfyller kravet

Advokatforeningens retningslinjer for klient-utlevering. PDF-rapport leveres til klient med personvern-redigerte felt (om motpart-data); JSON-pakka går til ny advokatfirma hvis aktuelt. Verifyer `integrity.valid === true` lokalt slik at klient kan kontrollere at utleveringen er komplett.

ai.outputcase.closerecord.updatedata.export

Tvist-bevis-fremleggelse — Tvisteloven kap. 21 point-in-time-grunnlag

Tvisteloven kap. 21 (bevisførsel — bevis må kunne fremlegges med kilde og uendret innhold) og Tvisteloven § 21-4 (taushetsplikt og bevis-fritak). Hvis et oppdrag senere går til tvist (typisk klient mot motpart eller firmaet mot klient) må advokat kunne fremlegge bevis-grunnlaget på den faktiske beslutnings-tidspunktet — ikke retrospektiv tilstand.

Utløst av

Sak går til tvist (typisk 12-36 mnd post-oppdrag) der motpart krever fremleggelse av advokats arbeids-grunnlag, eller klient bestrider firmaets rådgivning.

Eksport fra /dashboard/audit

Format: JSON

actor.tenant = advokatfirma-tenant AND target.id = oppdrag-id AND ts BETWEEN beslutnings-dato-30d AND beslutnings-dato+30d

Inneholder:

`record.update`-events viser hvilke felt i klient-/motpart-record som var registrert på beslutnings-tidspunktet (Brreg-snapshot, Lovdata-referanser, dokumenter)
`ai.output` med modellversjon og prompt-hash — kan re-kjøres for å verifisere reproduserbarhet av rådgivnings-grunnlaget
Brreg-/Kartverket-/Lovdata-kildereferanser med versjons-tidsstempel (point-in-time)
`case.close`-event med verdict og hvem som lukket DD-/saksfase-vurderingen og med hvilken konklusjon
Innloggings-events (Chinese-walls-bevis hvis konflikt er tema i tvisten)

Hvordan eksporten oppfyller kravet

Tvisteloven kap. 21 point-in-time-prinsipp. KETL bevarer record-tilstand på beslutnings-tidspunktet — ikke bare nåværende tilstand. Bevis-fremleggelse er forsvarbar med data som faktisk var tilgjengelig da advokat konkluderte. Domstolen kan etterkontrollere både utredningsgrunnlag og rettsanvendelse.

ai.outputrecord.updatecase.closeuser.logindata.export

Etisk utvalg — kvartalsvis interessekonflikt-revisjon

Advokatforeningens etiske regler kap. 3 (interessekonflikt) og firmaets interne kontroll-rutiner. Etisk utvalg gjennomfører periodiske gjennomganger for å sikre at interessekonflikt-test er gjennomført forsvarlig og at firmaets oppdrags-portefølje ikke inneholder skjulte konflikter.

Utløst av

Etisk utvalg eller compliance-funksjon varsler kvartalsvis interessekonflikt-revisjon for periode X (typisk Q1/Q2/Q3/Q4).

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = advokatfirma-tenant AND action IN ['case.open', 'case.close', 'ai.output'] AND ts BETWEEN kvartal-start AND kvartal-slutt

Inneholder:

Aggregert oversikt: antall nye oppdrag i kvartalet, antall konflikt-tester gjennomført, antall flagg utløst, antall oppdrag firmaet trakk seg fra
Hver `case.open`-event med trigger-event-id og første konflikt-vurdering (AI-triage)
Hver `case.close`-event med verdict, ansvarlig partner, og hvor lang tid det tok fra trigger til lukking
Trend-analyse: er det økning/reduksjon i konflikt-flagg vs. tidligere kvartal
Eksport-events (firmaet må kunne dokumentere at kvartalsvise eksporter har blitt levert til etisk utvalg)

Hvordan eksporten oppfyller kravet

Advokatforeningens etiske regler kap. 3 + firmaets interne kontroll-rutiner. Eksporten arkiveres i etisk utvalgs sak-system som bilag til kvartalsvis rapport til styret eller partner-rådet. Tjener også som dokumentasjon ved Advokatforeningens tilsyns-gjennomgang.

ai.outputcase.opencase.closerecord.updateaudit.exportsettings.change

Konkret use-case · for forsker og akademia

Replikasjons-studie, fagfellerevisjon og langtids-bevaring — FAIR-arkiv

FAIR-prinsippene (Findable, Accessible, Interoperable, Reusable) + replikerbarhetsprinsippet + Universitets- og høyskoleloven § 1-5 (formidlings-plikt) krever lang bevarings-horisont. Norske finansiører (Plan S) krever open access. Replikasjons- studier kan referere via DOI uten å kontakte original-forsker. Hvert mønster her er forsvarlig for replikasjons-studier, fagfellevurderings-revisjon og langtids-arkivering på Dataverse/ NIRD/Sikt (typisk 10+ år).

Replikasjons-studie — full prosjekt-arkiv på forespørsel

Replikerbarhetsprinsippet i empirisk forskning + FAIR-prinsippene (Reusable). Replikasjons-studier (samme metode, samme datagrunnlag, ny analyse) krever at originalt prosjekts datagrunnlag kan reproduseres punkt-for-punkt. Universitets- og høyskoleloven § 1-5 (formidlings-plikt) tilsier at forsker bør stille datagrunnlag til rådighet.

Utløst av

Ekstern forsker, replikasjons-prosjekt eller fagfellevurderer ber om utlevering av komplett datagrunnlag for publisert artikkel X.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = forsknings-tenant AND target.id = prosjekt-id AND ts BETWEEN prosjekt-start AND publiserings-dato

Inneholder:

Hele audit-kjeden for prosjektet fra oppstart til publisering
Hver AI-output med modellversjon, prompt-hash og konfidens — for AI-assisterte analyser
Tidsstemplet kjede av forskers signering av metode-valg
Brreg-/SSB-/Kartverket-/Lovdata-kildereferanser med stabil URI og versjons-tidsstempel — kritisk for replikerbarhet
Eksport-events (forsker må kunne dokumentere hvilke datasett som ble levert til Dataverse/NIRD/Sikt)

Hvordan eksporten oppfyller kravet

Replikerbarhetsprinsippet + FAIR-prinsippene (Reusable). PDF-rapport leveres til ekstern forsker; JSON-pakka deles via Dataverse/NIRD/Sikt med samme DOI som original-artikkelen. Verifyer `integrity.valid === true` lokalt slik at replikasjons-studie kan kontrollere autentisitet.

ai.outputrecord.updatedata.export

Fagfellerevisjon — metode-grunnlag for tidsskrift-redaktør

Fagfellevurderings-prosess + NESH-retningslinjer for forskningsdata. Tidsskrift-redaktør eller fagfellevurderer kan kreve dokumentasjon på datagrunnlaget — særlig hvis Round 2-/Round 3-kommentarer reiser tvil om datakilde-versjoner eller analyse-replikerbarhet.

Utløst av

Tidsskrift-redaktør eller fagfellevurderer ber om metode-grunnlag (datakilde-versjoner, AI-bidrags-dokumentasjon, analyse-historikk) for innsendt manuskript.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = forsknings-tenant AND target.id = prosjekt-id AND action IN ['ai.output', 'record.update', 'case.close']

Inneholder:

Komplett liste over datakilder med versjons-tidsstempler (Brreg, SSB-tabell-versjoner, Lovdata-paragraf-versjoner)
AI-bidrags-dokumentasjon: hvilke AI-modeller ble brukt for hva, og med hvilken konfidens (mange tidsskrifter krever nå AI-disclosure)
Tidsstemplet kjede av forskers signering av sensitivitets-analyser og metode-valg
Eventuelle data-kvalitet-flagg som ble vurdert og avvist (med begrunnelse) — viser robust metode
Versions-historikk som dokumenterer at datagrunnlaget var konsistent gjennom analyse-fasen

Hvordan eksporten oppfyller kravet

Fagfellevurderings-standarder + NESH-retningslinjer for AI-disclosure. Eksporten leveres til tidsskrift-redaktør som vedlegg til revisjons-runde-svar; bevares også internt for evt. senere replikasjons-spørsmål.

ai.outputcase.closerecord.updateaudit.export

Forskningsdata-arkivar — langtids-bevaring på Dataverse/NIRD/Sikt

FAIR-prinsippene (Findable via DOI, Accessible åpen lisens) + Universitets- og høyskoleloven § 1-5 (formidlings-plikt). Etter publisering må forskningsdata bevares på langtids-arkiv (typisk 10+ år) — i Norge via Dataverse, NIRD eller Sikt. Arkiv-leveransen må være komplett og selvdokumenterende.

Utløst av

Forsker eller forskningsdata-arkivar ved UB initierer langtids-bevaring av prosjekt på Dataverse/NIRD/Sikt etter publisering.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = forsknings-tenant AND target.id = prosjekt-id AND ts <= publiserings-dato

Inneholder:

Hele audit-kjeden for prosjektet — fra oppstart via analyse til publisering
Datakilde-snapshots på publiserings-tidspunktet med stable URI-er (Brreg, SSB-versjoner)
Endelig analyse-kode (referanse til Git-commit + tag for publisering)
Anonymiserings-dokumentasjon hvis GDPR-relevant data (art. 89 forskning-unntak)
FAIR-metadata-blokk klar for Dataverse/NIRD-opplasting (DOI, lisens, sitering-format)

Hvordan eksporten oppfyller kravet

FAIR-prinsippene + Universitets- og høyskoleloven § 1-5 + Plan S (open access). Arkiv-pakka legges på Dataverse/NIRD/Sikt med DOI; bevares minst 10 år. Replikasjons-studier kan referere via DOI uten å kontakte original-forsker.

ai.outputrecord.updatecase.closeaudit.exportsettings.change

Konkret use-case · for PE-/VC-fond

AIFMD-tilsyn, LP-DDQ-svar og LPA clawback — 10+ års bevaring

AIFMD-tilsyns-krav + ILPA Reporting Standards krever 10+ års bevarings-horisont. Limited Partnership Agreement (LPA) waterfall- og clawback-mekanismer kan trigge tvist-vurdering ved fond- likvidasjon. Hvert mønster her er forsvarlig mot Finanstilsynet, LP-tilsyn og fond-likvidator — point-in-time-grunnlag på beslutnings-tidspunktet.

Finanstilsynets AIFMD-tilsyn — fond-rutinebevis innen tilsyns-frist

AIFMD (Alternative Investment Fund Managers Directive) tilsyns-krav + Finanstilsynets praksis for kapitalforvaltere. Ved tilsyns-besøk eller skriftlig forespørsel må fondet kunne dokumentere hvordan investerings- og porteføljedrifts-rutinene har vært gjennomført — fra IC-vedtak til kvartalsvis LP-rapportering til evt. exit.

Utløst av

Finanstilsynet varsler AIFMD-tilsyns-besøk eller sender skriftlig informasjons-forespørsel om fondets DD-/IC-/porteføljedrifts-praksis.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = fond-tenant AND action IN ['ai.output', 'case.open', 'case.close', 'record.update'] AND ts BETWEEN periode-start AND periode-slutt

Inneholder:

Aggregert oversikt: antall IC-vedtak, antall impairment-flagg behandlet, antall LP-rapporter sendt, antall exit-er
Hver `case.open`-event med trigger-event-id og første-vurdering (AI-triage)
Hver `case.close`-event med verdict, ansvarlig partner, og reaksjons-tid
Eksport-events (fondet må kunne dokumentere kvartalsvise LP-rapporter og evt. SFDR-rapportering)
Innstillings-endringer (investerings-mandat eller LPA-vilkår oppdatert — dokumenter at endringene er godkjent av styret)

Hvordan eksporten oppfyller kravet

AIFMD-tilsyns-krav + Finanstilsynets praksis. PDF-rapport leveres til Finanstilsynet med personvern-redigerte felt; JSON-pakka går til intern revisor for verifikasjon. Verifyer `integrity.valid === true` lokalt slik at Finanstilsynet kan kontrollere at rapporteringen er forsvarlig.

ai.outputcase.opencase.closerecord.updateaudit.export

LP-DDQ-svar — Limited Partner due diligence questionnaire

ILPA Reporting Standards + LP-DDQ-praksis (Standard Industry-DDQ fra ILPA). LP-er kan kreve detaljert dokumentasjon på fondets investerings-prosess, porteføljedrift og rapportering — typisk årlig eller ved fund-of-funds re-up. Svar må være konsistent med ILPA Reporting Standards og fondets historiske LP-rapporter.

Utløst av

LP eller fund-of-funds sender DDQ til fondet — typisk årlig eller før re-up-vedtak. Eller intern compliance gjennomfører kvartalsvis ILPA-konformitets-revisjon.

Eksport fra /dashboard/audit

Format: JSON + PDF

actor.tenant = fond-tenant AND target.id IN [portefolje-orgnrs] AND action IN ['ai.output', 'record.update', 'case.close']

Inneholder:

Komplett liste over porteføljebedrifter med IC-vedtak-dato, kost, fair value (kvartalsvis), realised vs. unrealised
Material change-historikk per porteføljebedrift med tidspunkt for IFRS 9-vurderinger
ESG-/CSRD-rapporterings-historikk for SFDR-konformitet
Audit trail av kvartalsvise LP-rapporter med signaturer fra managing partner
Eksport-events (fondet må kunne dokumentere historisk LP-DDQ-svar for sammenligning)

Hvordan eksporten oppfyller kravet

ILPA Reporting Standards + LP-DDQ-konformitet. Eksporten leveres til LP som DDQ-svar med ILPA-standard-format; bevares også internt for evt. senere LP-tilsyn eller fond-likvidasjon (10+ år).

ai.outputcase.closerecord.updatedata.export

LPA clawback-bevis — point-in-time fond-history for tvist-håndtering

Limited Partnership Agreement (LPA) waterfall + clawback-mekanismer. Hvis fondet senere får clawback-claim fra LP (typisk ved fond-likvidasjon hvis early-stage carry-allocations viste seg å være for høye), må fondet kunne dokumentere fair value-vurderinger og waterfall-beregninger på beslutnings-tidspunktet — ikke retrospektiv tilstand.

Utløst av

LP eller fond-likvidator initierer clawback-vurdering — typisk ved fond-likvidasjon eller hvis early-stage carry-allocations bestrides ved LP-fond-likvidasjon.

Eksport fra /dashboard/audit

Format: JSON

actor.tenant = fond-tenant AND target.id IN [portefolje-orgnrs] AND ts BETWEEN fond-vintage AND likvidasjon-dato

Inneholder:

`record.update`-events viser hvilke fair value-vurderinger var registrert på hvert kvartal av fondets levetid
`ai.output` med modellversjon og prompt-hash — kan re-kjøres for å verifisere reproducerbarhet av impairment-vurderinger
Tidsstemplet kjede av carry-allocation-beregninger med waterfall-modell-versjoner
`case.close`-event med verdict for hver impairment-/exit-vurdering
Innstillings-endringer (LPA-vilkår eller waterfall-modell oppdatert — kritisk for å vise hvilken versjon som var aktiv på beslutnings-tidspunktet)

Hvordan eksporten oppfyller kravet

LPA point-in-time-prinsipp + ILPA Standards for clawback-evaluering. KETL bevarer record-tilstand på vurderings-tidspunktet — ikke bare nåværende tilstand. Clawback-tvist er forsvarbar med data som faktisk var tilgjengelig da fondet beregnet carry.

ai.outputrecord.updatecase.closesettings.change