En logg skal svare på et spørsmål
Logging blir ofte behandlet som et teknisk krav: slå på mest mulig og lagre resten. Det skaper ikke nødvendigvis bedre kontroll. En nyttig logg er utformet for å svare på konkrete spørsmål når noe går galt: Hvilken kilde ble brukt? Hvilken regel eller instruks gjaldt? Hvilken handling ble foreslått eller utført? Hvem godkjente, avviste eller overstyrte resultatet?
Start med hendelsene som har betydning for virksomheten. For en ren skriveassistent kan det være nok å vite hvilken godkjent kilde og versjon som ble brukt. For en arbeidsflyt som endrer data eller kommuniserer med kunder, kan det være nødvendig å registrere handling, mottaker, kontrollpunkt og resultat. Omfanget bør følge konsekvensen av feil.
Unngå å lagre hele forespørsler og svar som standard dersom formålet kan nås med mindre. En referanse til dokumentet, en kategorisert feilkode eller en kontrollert oppsummering kan være nok. Rå tekst kan inneholde opplysninger brukeren aldri forventet skulle bli en varig logg. Velg derfor logginnhold ut fra undersøkelsesbehov, ikke teknisk bekvemmelighet.
Bevar sporbarhet uten å bygge et datalager av alt
Mer logging betyr også mer ansvar. Logger kan inneholde personopplysninger, forretningsinformasjon eller hele tekstgrunnlag som ikke bør kopieres. Bruk identifikatorer og referanser der det er mulig, begrens tilgang og fastsett hvor lenge informasjonen faktisk trengs. Dataminimering gjelder også sporbarhet.
Bevar sammenhengen uten å lagre alt. En presis sporlinje kan bestå av kildehenvisning, versjon av instruks eller regel, valgt modell eller tjeneste, tidspunkt, handlingstype, godkjenningsstatus og eventuelt feilutfall. Det viktige er at en ansvarlig kan rekonstruere den relevante beslutningen og skille normal bruk fra avvik.
Bestem hvem som kan lese logger, hvem som kan endre konfigurasjon og hvem som kan godkjenne sletting. En utvikler, prosesseier og personvernansvarlig trenger ikke samme tilgang. Sett oppbevaring etter formål og gjeldende krav, og test at sletting faktisk virker. En uendelig logg er ikke bedre dokumentasjon; den er en voksende forpliktelse.
Koble logging til varsling, stopp og læring
Logging må føre til handling. Definer hvilke hendelser som skal varsle en eier, sette arbeidsflyten på pause eller sende oppgaven til manuell behandling. Avtal hvordan en feil undersøkes, hvordan berørte data rettes, og hvordan læringen blir til en kontrollert endring. En logg ingen ser, er bare lagringskostnad.
KI-forordningen stiller særskilte krav til automatisk logging for bestemte høyrisikosystemer. Det betyr ikke at alle løsninger har samme lovkrav, og omfang og oppbevaring må vurderes konkret. For virksomheten er det operative målet uansett tydelig: lagre det som trengs for å forstå, forklare og stoppe—og ikke mer enn dere kan beskytte og forvalte.
Øv på ett avvik før lansering. Simuler en feil kilde, uønsket handling eller manglende godkjenning. Kan teamet finne den relevante sporlinjen, stoppe flyten, vurdere berørte resultater og gjenopprette normal drift? Hvis svaret krever leting på tvers av tilfeldige systemlogger, er beslutningsbeviset ikke ferdig utformet.
Tre hensyn før dere går videre
- Kostnad
- For mye logging øker lagring og kontrollarbeid.
- Risiko
- For lite logging gjør avvik vanskelig å undersøke.
- Kontroll
- Bestem formål, tilgang og slettetid for loggene.
Definer fem hendelser
- Velg et sannsynlig avvik.
- List hendelsene som må rekonstrueres.
- Avklar innhold, tilgang og sletting for hver logg.
Kilder og vurderingsgrunnlag
- Forordning (EU) 2024/1689 – KI-forordningen EUR-Lex · Offisiell lovtekst om blant annet KI-kompetanse, logging og menneskelig kontroll der reglene gjelder.
- Datatilsynet: Vurder personvernkonsekvensene og bygg personvern inn i løsningene Datatilsynet · Innebygd personvern, dataminimering og vurdering av personvernkonsekvenser.
- NIST AI RMF Core National Institute of Standards and Technology · Styring, kontekstkartlegging, måling og løpende risikohåndtering.
