Kiloven
Kontakt

Slik strukturerer du en KI-systemfil for kunder og revisor

En KI-systemfil er en samlet, strukturert dokumentasjon for ett KI-system. Filen fungerer som virksomhetens «pakke» med all informasjon en kunde, revisor eller tilsynsmyndighet trenger for å forstå hva systemet gjør, hvordan det er vurdert, og hvem som er ansvarlig. Denne artikkelen gir deg en konkret blueprint du kan bruke som utgangspunkt.

Merk: Denne veiledningen er praktisk orientert og erstatter ikke juridisk rådgivning. Tilpass strukturen til egen virksomhet og de systemene dere faktisk bruker.

Hvorfor ha en systemfil?

For kunder

Stadig flere kunder – spesielt i offentlig sektor og større private virksomheter – krever dokumentasjon på at leverandører håndterer KI forsvarlig. En godt strukturert systemfil gjør det enkelt å svare på kundenes spørsmål uten å måtte starte fra bunnen hver gang.

For revisor og tilsyn

Tilsynsmyndigheter og revisorer forventer sporbar dokumentasjon. En systemfil viser at virksomheten har gjort bevisste valg, gjennomført vurderinger og etablert rutiner – og at alt dette er oppdatert.

For virksomheten selv

Systemfilen gir intern oversikt og gjør det enklere å:

  • Holde kontroll når ansvarlige bytter rolle.
  • Identifisere hull i dokumentasjonen.
  • Gjennomføre periodiske gjennomganger effektivt.

Overordnet struktur

Systemfilen bør organiseres i tydelige seksjoner. Nedenfor er en anbefalt struktur med ti deler. Hver del kan være et eget avsnitt i et dokument, eller en egen fane i et regneark – velg det formatet som passer virksomheten.

Del 1: Identifikasjon og metadata

Start med grunnleggende opplysninger som gjør det enkelt å identifisere systemet og filens status.

1. IDENTIFIKASJON OG METADATA
===============================

Systemnavn:           [Navn på systemet]
Intern referanse:     [Eventuelt internt ID-nummer]
Leverandør:           [Leverandørens navn]
Versjon av systemet:  [Leverandørens versjonsnummer]
Versjon av denne filen: [Filversjon, f.eks. 2.1]
Eier av systemfilen:  [Navn, rolle, avdeling]
Opprettet:            [Dato]
Sist oppdatert:       [Dato]
Neste planlagte gjennomgang: [Dato]
Status:               [Utkast / Aktiv / Under revisjon / Avviklet]

Tips: Bruk et enkelt versjonsnummer for selve filen (ikke bare for systemet). Det gjør det mulig å spore endringer i dokumentasjonen uavhengig av systemoppdateringer.

Del 2: Formål, bruk og kontekst

Beskriv hvorfor systemet brukes og hvordan det er integrert i virksomhetens prosesser.

2. FORMÅL, BRUK OG KONTEKST
=============================

Formål:
[Hva skal systemet oppnå? Hvilken forretningsverdi gir det?]

Bruksområder:
- [Bruksområde 1 – f.eks. filtrering av jobbsøknader]
- [Bruksområde 2 – f.eks. rangering av kandidater]

Brukergrupper internt:
- [Rolle/avdeling som opererer systemet]
- [Rolle/avdeling som mottar output fra systemet]

Berørte personer:
- [Hvem påvirkes av systemets output – ansatte, søkere, kunder?]

Input:
- [Hvilke data mates inn i systemet?]

Output:
- [Hva produserer systemet – anbefalinger, scorer, beslutninger?]

Grad av automatisering:
[Foreslår systemet, eller tar det beslutninger? Beskriv graden av menneskelig involvering.]

Del 3: Klassifisering

Dokumenter den risikoklassifiseringen som er gjort for systemet.

3. KLASSIFISERING
==================

Risikoklasse:         [Minimal / Begrenset / Høy]
Dato for klassifisering: [Dato]
Utført av:            [Navn, rolle]
Metode:               [Beskriv kort – f.eks. intern triage mot Annex III]

Begrunnelse:
[Forklar hvorfor systemet har denne klassifiseringen basert på faktisk bruk.
Henvis til relevante kategorier i Annex III hvis aktuelt.]

Sjekk mot forbudte praksiser:
[Bekreft at systemet ikke har funksjonalitet som er forbudt etter artikkel 5.
Beskriv kort hva som er vurdert.]

Del 4: Konsekvensvurdering

Oppsummer resultatene fra gjennomførte vurderinger, og henvis til fullstendige dokumenter.

4. KONSEKVENSVURDERING
=======================

4.1 Vurdering for grunnleggende rettigheter (FRIA)
---------------------------------------------------
Gjennomført:    [Ja / Nei / Ikke aktuelt]
Dato:           [Dato]
Utført av:      [Navn, rolle]
Hovedfunn:      [Kort oppsummering]
Fullstendig vurdering: [Filreferanse eller lenke]

4.2 Personvernkonsekvensvurdering (DPIA)
-----------------------------------------
Gjennomført:    [Ja / Nei / Ikke aktuelt]
Dato:           [Dato]
Utført av:      [Navn, rolle]
Hovedfunn:      [Kort oppsummering]
Fullstendig DPIA: [Filreferanse eller lenke]

4.3 Andre vurderinger
----------------------
[Beskriv eventuelt andre relevante vurderinger, som sikkerhetsvurderinger.]

Del 5: Leverandørdokumentasjon

Hold oversikt over dokumentasjon mottatt fra leverandøren og eventuelle mangler.

5. LEVERANDØRDOKUMENTASJON
============================

Mottatt dokumentasjon:
- [ ] Bruksanvisning (instructions for use)
- [ ] Teknisk dokumentasjon
- [ ] Leverandørens risikovurdering
- [ ] Samsvarserklæring (EU declaration of conformity)
- [ ] Informasjon om treningsdata
- [ ] Databehandleravtale

Plassering av dokumentene: [Sti eller referanse]

Manglende dokumentasjon:
[List opp dokumenter som er etterspurt men ikke mottatt, med dato for henvendelse.]

Kontaktperson hos leverandør:
[Navn, e-post, telefon]

Del 6: Menneskelig tilsyn og rutiner

Beskriv de operative rutinene rundt systemet.

6. MENNESKELIG TILSYN OG RUTINER
==================================

6.1 Tilsyn
----------
Ansvarlig for tilsyn:    [Navn, rolle]
Hvordan utføres tilsyn:  [Beskriv prosessen – f.eks. stikkprøvekontroll av output]
Frekvens:                [Daglig / Ukentlig / Ved hver bruk]
Dokumentasjon av tilsyn: [Hvor loggføres resultater?]

6.2 Informasjon til berørte
----------------------------
Hva informeres:  [Hvilken informasjon gis til berørte?]
Når:             [Tidspunkt – f.eks. i søknadsprosessens oppstart]
Hvordan:         [Kanal – e-post, nettsiden, muntlig]
Mal/eksempel:    [Referanse til informasjonstekst]

6.3 Klage og henvendelser
--------------------------
Kanal for henvendelser:  [E-post, skjema, kontaktperson]
Hvem håndterer:          [Navn, rolle]
Prosess:                 [Kort beskrivelse av behandlingsprosessen]
Svarfrist:               [Intern målsetting]

6.4 Hendelseshåndtering
-------------------------
Hva utløser rapportering: [Kriterier for å melde alvorlige hendelser]
Hvem varsles internt:     [Navn, rolle]
Ekstern rapportering:     [Til tilsynsmyndighet – beskriv prosess]

Del 7: Logger og registre

Dokumenter hvilke logger som genereres og oppbevares.

7. LOGGER OG REGISTRE
=======================

Systemlogger fra leverandør:
- Hva logges:    [Beskrivelse av loggdata]
- Lagringstid:   [Periode]
- Tilgang:       [Hvem har tilgang til loggene?]
- Format:        [Tekstfil, database, API-eksport]

Interne logger:
- Beslutningslogg:       [Ja/Nei – hvor oppbevares den?]
- Tilsynslogg:           [Ja/Nei – hvor oppbevares den?]
- Endringslogg:          [Ja/Nei – hvor oppbevares den?]
- Henvendelseslogg:      [Ja/Nei – hvor oppbevares den?]

Del 8: Medvirkning og drøfting

Dokumenter involvering av tillitsvalgte og verneombud, som er spesielt viktig i norsk arbeidsliv.

8. MEDVIRKNING OG DRØFTING
============================

Drøfting med tillitsvalgte:
- Dato:          [Dato]
- Deltakere:     [Navneliste]
- Hovedpunkter:  [Oppsummering]
- Referat:       [Referanse til dokument]

Involvering av verneombud:
- Dato:          [Dato]
- Tema:          [Hva ble diskutert?]
- Dokumentasjon: [Referanse]

Avtale (hvis aktuelt):
[Referanse til eventuell avtale med fagforening eller tillitsvalgte.]

AMU-behandling (hvis aktuelt):
[Dato og referanse til behandling i arbeidsmiljøutvalget.]

Del 9: Versjonering og endringslogg

Sporbarhet er avgjørende for revisorer. Bruk en enkel tabell som viser hva som er endret, når og av hvem.

9. VERSJONERING OG ENDRINGSLOGG
=================================

Filversjon | Dato       | Endring                            | Utført av
-----------|------------|------------------------------------|-----------
1.0        | [Dato]     | Førsteversjon opprettet            | [Navn]
1.1        | [Dato]     | Oppdatert etter leverandørendring  | [Navn]
2.0        | [Dato]     | Årlig gjennomgang, ny FRIA         | [Navn]

Tips om versjonering:

  • Bruk heltall (1.0, 2.0) for årlige gjennomganger eller vesentlige endringer.
  • Bruk desimaler (1.1, 1.2) for mindre oppdateringer.
  • Aldri slett gamle versjoner – arkiver dem slik at historikken er intakt.

Del 10: Vedlegg og referanser

List opp alle tilknyttede dokumenter samlet, slik at en revisor raskt kan se hva som finnes.

10. VEDLEGG OG REFERANSER
===========================

Nr  | Dokument                          | Plassering
----|-----------------------------------|----------------------------
V1  | Bruksanvisning fra leverandør     | [Sti eller lenke]
V2  | Konsekvensvurdering (FRIA)        | [Sti eller lenke]
V3  | DPIA                              | [Sti eller lenke]
V4  | Drøftingsreferat                  | [Sti eller lenke]
V5  | Informasjonstekst til berørte     | [Sti eller lenke]
V6  | Databehandleravtale               | [Sti eller lenke]
V7  | Samsvarserklæring                 | [Sti eller lenke]

Eksport: gjøre filen klar for kunder og revisorer

Kunder og revisorer har ulike behov. Her er noen praktiske grep for eksport.

For kunder

Kunder trenger typisk et sammendrag, ikke hele filen. Lag en eksportversjon som inneholder:

  • Del 1 (identifikasjon) – uten interne referanser.
  • Del 2 (formål og bruk) – forenklet.
  • Del 3 (klassifisering) – med begrunnelse.
  • Del 5 (leverandørdokumentasjon) – bekreftelse på at dokumentasjon foreligger.
  • Del 6 (rutiner) – spesielt informasjonsplikt og klagemekanisme.

For revisorer

Revisorer trenger full tilgang. Sørg for at:

  • Alle vedlegg er tilgjengelige og oppdaterte.
  • Endringsloggen er komplett.
  • Versjonshistorikken er intakt.
  • Signaturer og godkjenninger er på plass.

Eksportformat

Velg et format som passer mottakeren:

  • PDF – for formell deling med kunder og tilsynsmyndigheter. Lås dokumentet for redigering.
  • Regneark – praktisk for intern bruk og oppdatering.
  • Dokumentstyringssystem – best for virksomheter som allerede bruker slike systemer (SharePoint, Confluence osv.).

Ansvar: hvem gjør hva?

Tydelig ansvarsdeling er nøkkelen til en systemfil som faktisk holdes oppdatert.

RolleAnsvar
SystemeierHovedansvar for filen. Sørger for at den er oppdatert og komplett.
FagansvarligBidrar med operativ innsikt om bruk og tilsyn.
PersonvernombudBidrar til DPIA og personvernrelaterte deler.
IT/sikkerhetsansvarligBidrar med informasjon om logger, integrasjoner og sikkerhet.
TillitsvalgteMedvirker i drøfting og gjennomgang.

Sjekkliste: er systemfilen komplett?

Bruk denne sjekklisten ved opprettelse og ved periodisk gjennomgang:

  • Identifikasjon og metadata er fylt ut, inkludert filversjon
  • Formål, bruk og berørte grupper er beskrevet
  • Klassifisering er gjennomført med begrunnelse
  • Konsekvensvurdering(er) er gjennomført der det kreves
  • Leverandørdokumentasjon er innhentet og plassert
  • Rutiner for tilsyn, informasjon og klage er beskrevet
  • Logger og registre er dokumentert
  • Medvirkning er dokumentert
  • Endringsloggen er oppdatert
  • Vedleggslisten er komplett og alle filer er tilgjengelige
  • Neste gjennomgangsdato er satt

Videre lesning

Sist oppdatert

2026-02-02