Versjon 1.2, 21. oktober 2026. Følger Datatilsynets veiledning om vurdering av personvernkonsekvenser (GDPR art. 35): systematisk beskrivelse, nødvendighet og proporsjonalitet, risiko for de registrertes rettigheter og friheter, tiltak, konsultasjon og dokumentasjon.
Dokumentet er skrevet av databehandleren (Schoolhub AS) som underlag. Kommunen er behandlingsansvarlig og eier DPIA-en for sin bruk (art. 35(1), jf. art. 28(3)(f) og databehandleravtalen punkt 4.3 l)). Hver kommune kopierer dokumentet, fyller ut feltene i hakeparentes, for eksempel [Kommunen fyller ut], og innhenter råd fra sitt personvernombud (art. 35(2)).
Relaterte dokumenter: ROS-analyse, databehandleravtale, underdatabehandlere, TIA, behandlingsprotokoll, sletting og lagringstid, avvikshåndtering, registrertes rettigheter, KI-forordningen.
1. Hvorfor DPIA er nødvendig
1.1 Datatilsynets liste (art. 35(4))
Datatilsynet har en liste over behandlinger der DPIA alltid skal gjennomføres. Tabellen viser punktene som er aktuelle for Målfrid, i forkortet form. Sjekk gjeldende ordlyd hos Datatilsynet.
| Punkt på lista | Treffer Målfrid? | Begrunnelse |
|---|---|---|
| Behandling av personopplysninger med innovativ teknologi, sammen med minst ett annet kriterium | Ja | Generativ KI (språkmodeller) kombinert med dokumentsøk og tale |
| Særlige kategorier eller svært personlige opplysninger i stor skala | Mulig | Dataklassen Personopplysninger (helse, omsorg, barnevern, sosial, skole) og Konfidensiell (personalsaker). Tjenesten krever ikke slike data, men kan ikke utelukke dem (kap. 2.4) |
| Behandling der formålet er å tilby en tjeneste eller utvikle produkter for kommersiell bruk | Ja (databehandlers side) | Schoolhub selger tjenesten. Ingen opplysninger brukes til produktutvikling (forbud mot trening, databehandleravtalen punkt 3.4), men kriteriet er relevant for en forsiktig vurdering |
| Systematisk monitorering av ansatte | Nei som formål, men det er en risiko | Målfrid er ikke et overvåkingsverktøy. Revisjonsloggen og bruksstatistikken kan likevel misbrukes til det (risiko D9). Tiltak i kap. 5 |
| Personopplysninger samlet inn via tredjepart, sammen med annet kriterium | Delvis | Dokumenter fra kommunens systemer og offentlige møtebøker |
| Systematisk monitorering av effektivitet og ferdigheter | Nei | Målfrid vurderer ikke ansattes effektivitet eller ferdigheter |
1.2 Kriterier fra EDPB og Artikkel 29-gruppen
To eller flere kriterier i Artikkel 29-gruppens retningslinjer (WP 248 rev.01) tilsier DPIA. Målfrid treffer: (1) ny teknologi, (2) sensitive eller svært personlige opplysninger (mulig), (3) opplysninger om sårbare registrerte (ansatte i en ulik maktposisjon, innbyggere i rollen som tjenestemottaker), (4) stor skala (hele kommunen og IKT-samarbeid med flere kommuner) og (5) sammenstilling av datasett (kunnskapsbaser fra SharePoint, arkiv og møtebøker).
1.3 Konklusjon
DPIA er påkrevd for Målfrid. Kommunen må i tillegg vurdere behandlingen opp mot sin egen virksomhet (kap. 9: hva kommunen må tilføye).
2. Systematisk beskrivelse av behandlingen
2.1 Formål
Gi ansatte i kommune og fylkeskommune en trygg KI-kollega med kilder, revisjonsspor og kobling til sak og arkiv. Målfrid brukes til å søke i og oppsummere kommunens egne dokumenter, skrive utkast (saksframlegg, brev, klarspråk, bokmål og nynorsk), lage referat fra møteopptak og svare på spørsmål mot lover, regler og interne reglement. Målfrid er ikke rettet mot innbyggerne og fatter ikke vedtak.
Kommunens egen beskrivelse av formål og bruksområder: [Kommunen fyller ut]
2.2 Roller
| Part | Rolle | Merknad |
|---|---|---|
| Kommune eller fylkeskommune | Behandlingsansvarlig | Bestemmer formål og midler, eier DPIA-en, inngår databehandleravtalen og er idriftsetter etter KI-forordningen |
| Schoolhub AS | Databehandler for tjenesten. Behandlingsansvarlig for nettstedet og egne kundekontakter | Driver plattformen etter instruks. Leverandør (provider) etter KI-forordningen |
| Underdatabehandlere | Se registeret | Scaleway SAS (hosting, Frankrike) og modellleverandører. Microsoft Azure hvis kommunen bruker det |
| IKT-samarbeid (for eksempel Nordhav IKT) | Innkjøper eller fellesskap | Ikke behandlingsansvarlig for kommunenes data og ser ikke innhold på tvers av kommuner |
| Brukere | Ansatte og folkevalgte | Registrerte og aktører |
2.3 Kategorier av registrerte
- Ansatte og andre brukere.
- Innbyggere, brukere, pasienter og elever som omtales i opplastet eller skrevet innhold.
- Ansatte og tredjepersoner i personalsaker, møter og referater.
- Deltakere i møteopptak (stemme).
Kommunens konkrete grupper og omfang: [Kommunen fyller ut]
2.4 Kategorier av personopplysninger og dataklasser
| Dataklasse | Typiske opplysninger | Art. 9/10 | Standard oppbevaring |
|---|---|---|---|
| Identitet og bruk | Navn, e-post, Entra- eller Feide-ID, gruppemedlemskap, språk, IP-adresse (kun som saltet kontrollsum), tidspunkt, handling, modell, leverandør | Nei | Se kap. 2.8 |
| Åpen | Offentlige dokumenter, møtebøker | Normalt nei | 730 dager |
| Intern | Utkast, interne notater | Normalt nei | 365 dager |
| Konfidensiell | Taushetsbelagt informasjon, personalsaker | Kan forekomme | 90 dager (eller journalført) |
| Personopplysninger | Opplysninger om enkeltpersoner i tjenesteytingen | Ja, kan forekomme | 30 dager (eller journalført) |
| Lyd og transkripsjon | Stemmeopptak og tekst | Kan forekomme | Følger dataklassen |
Tjenesten krever ikke særlige kategorier, men kan ikke utelukke at de lastes opp. Derfor velger brukeren dataklasse før første melding. Innholdsdeteksjon (fødselsnummer og D-nummer med kontrollsiffer, kontonummer, helseord, adresse og telefon) foreslår oppgradering og blokkerer i Åpen. Konfidensiell og Personopplysninger sendes bare til de strengeste leverandørene.
2.5 Dataflyt og behandlingsaktiviteter
- Brukeren logger inn mot kommunens Entra ID eller Feide. Tofaktorautentisering kontrolleres.
- Brukeren velger dataklasse og stiller spørsmål, eller laster opp dokument eller lyd.
- Tjenesten sjekker rolle, enhet og at kommunens data er skilt fra andres, og kjører innholdsdeteksjon. Deretter skriver den revisjonslogg (logg først), henter relevante kilder og sender spørsmålet til en språkmodell hos en leverandør som dataklassen tillater, via regelsjekken. Genereringen kjører som en varig jobb i bakgrunnen.
- Svar og kilder vises og lagres som samtale. Innhold i Konfidensiell og Personopplysninger er kryptert på feltnivå.
- Brukeren kan eksportere (Word, PDF eller Noark 5-pakke) med KI-merking.
- Innsyn (offentleglova): arkivadministrator og revisor kan søke i samtaler på tvers av brukere innenfor én kommune, foreslå skjerming og lage utleveringspakke.
- En oppbevaringsjobb kjører daglig og sletter eller anonymiserer etter reglene. Journalførte samtaler uten bekreftelse fra arkivet beskyttes.
- Valgfritt nettsøk er av som standard og gjelder bare Åpen og Intern.
2.6 Lagring, lokasjon og mottakere
Alle data lagres i EU/EØS hos Scaleway SAS i Frankrike. Drift ligger i regionen Paris (fr-par), og sikkerhetskopi og katastrofegjenoppretting i Amsterdam (nl-ams). Scaleway leverer database, mellomlager, fillagring, nøkkelhåndtering og hemmelighetshåndtering. Hosting er hos en europeisk leverandør uten amerikansk morselskap, så plattformen innebærer ingen tredjelandsoverføring. Risikoen ved at alt ligger hos én leverandør er vurdert i ROS-analysen (R33).
Spørsmål og kontekst sendes til en språkmodell hos en leverandør som kommunen har tillatt for dataklassen. Kommunen bestemmer hvilke dataklasser hver leverandør og modell brukes til; Schoolhub gir forvalg og opplysninger, og alle endringer logges (ADR 0013). Leverandørene er GreenPT (Nederland, behandling i Frankrike og Finland), nexos.ai og Mistral AI (forvalg Åpen og Intern) og Microsoft Azure OpenAI (EU Data Zone, forvalg Åpen og Intern). Nettsøk leveres av Staan. Mistral kan i tillegg velges per enhet for tale til tekst (Voxtral) og tekstgjenkjenning i skannede dokumenter (Mistral OCR), forvalg Åpen og Intern; Tesseract på egne maskiner er standard for tekstgjenkjenning. Tekstvektorer til kunnskapsbaser lages hos GreenPT i EU, også for Konfidensiell og Personopplysninger. Noen av modellene er åpne modeller av kinesisk opphav; de kjøres bare av GreenPT i EU eller av nexos.ai (bare Åpen og Intern), og kommunen kan slå dem av. Mottakerne står i registeret. Forbud mot trening på kundedata er krav i databehandleravtalen. Telemetri inneholder verken innhold eller personidentifikatorer. Tredjelandsvurdering: TIA.
Kommunens valg av leverandører og enheter: [Kommunen fyller ut]
2.7 Teknologi, KI og menneskelig kontroll
Språkmodeller lager utkast. Alle svar har kilder med forhåndsvisning, KI-merking og visning av modell, leverandør og region. Det finnes ingen automatiske vedtak (art. 22). Målfrid skriver ikke til kommunens fagsystemer. Det brukes ingen følelsesgjenkjenning og ingen scoring av personer. Se KI-forordningen.
2.8 Lagringstid
Se sletting og lagringstid. Revisjonsloggen oppbevares i 5 år, og avviste forespørsler i 365 dager. Daglige sikkerhetskopier oppbevares i 30 dager, og ukentlige sikkerhetskopier i 90 dager (kopi i Amsterdam). Lyd følger dataklassen.
2.9 Behandlingsgrunnlag
Tabellen er et forslag. Kommunen vurderer og fyller ut sitt eget grunnlag.
| Behandling | Forslag til grunnlag | Kommentar | Kommunens vurdering |
|---|---|---|---|
| Brukeradministrasjon, sikkerhet og revisjon | Art. 6(1)(e) (oppgave i allmennhetens interesse eller offentlig myndighet, jf. personopplysningsloven § 8 og kommuneloven). Art. 6(1)(c) for sikkerhetskrav (art. 32) | Nødvendig for forsvarlig drift | [Kommunen fyller ut] |
| Saksbehandling med KI-støtte | Art. 6(1)(e) med supplerende rettsgrunnlag i den aktuelle særloven | Kommunen vurderer fagområde for fagområde (helse, barnevern, skole) | [Kommunen fyller ut] |
| Særlige kategorier | Art. 9(2)(g) viktig allmenn interesse med lovhjemmel, 9(2)(h) for helse, 9(2)(b) i arbeidsforhold | Bare hvis kommunen bestemmer at slike data kan behandles. Ellers skal de ikke inn | [Kommunen fyller ut] |
| Møteopptak | Art. 6(1)(e). Deltakerne får informasjon før opptak | Samtykke er normalt ikke egnet i arbeidsforhold | [Kommunen fyller ut] |
| Behandling av ansattes brukerdata (logg) | Art. 6(1)(e) eller (c). Art. 88 og arbeidsmiljøloven kap. 9 for kontrolltiltak | Se mal for personvernerklæring | [Kommunen fyller ut] |
3. Nødvendighet og proporsjonalitet
| Prinsipp | Vurdering |
|---|---|
| Formålsbegrensning (art. 5(1)(b)) | Brukes til oppgaver kommunen har definert. Assistenter har definert formål og kan ikke brukes til andre uten ny godkjenning |
| Dataminimering (5(1)(c)) | Dataklasse velges før melding. Deteksjon og advarsel. Bare relevante kilder tas med. Ingen innhold i telemetri. Ingen trening. Nettsøk sjekkes for personopplysninger |
| Riktighet (5(1)(d)) | Sitater, KI-merking og menneskelig kvalitetssikring. Ingen automatiske vedtak. Feil i kilder rettes i kilden |
| Lagringsbegrensning (5(1)(e)) | Automatisk sletting per dataklasse. Reglene arves nedover i organisasjonen, kan låses og logges |
| Integritet og konfidensialitet (5(1)(f), art. 32) | Hver kommunes data er skilt fra de andres i databasen, kryptering på feltnivå, tofaktorautentisering, nøkkelhåndtering hos Scaleway, nettverkssegmentering og en revisjonslogg som bare kan utvides, med kontrollsum-kjede |
| Åpenhet (art. 12–14) | Brukeren informeres i grensesnittet om KI, modell, leverandør, region og dataklasse. Kommunen publiserer personvernerklæring (mal) |
| Rettigheter (art. 15–22) | Rutine for eksport, retting i kilde, sletting, begrensning og protest. Ingen automatiserte avgjørelser |
| Innebygd personvern (art. 25) | Strengeste leverandører som standard for Personopplysninger, kort oppbevaring, kryptering og tilgangsstyring i organisasjonen |
| Databehandler (art. 28) | Databehandleravtale basert på KS sin mal, register over underdatabehandlere og varslingsplikt innen 24 timer |
| Overføring (kap. V) | TIA |
Alternativer som er vurdert.
- At ansatte bruker forbrukerverktøy (ChatGPT og lignende) uten avtale. Det gir langt dårligere kontroll og er det reelle alternativet uten Målfrid («skygge-KI»).
- Manuell saksbehandling. Det gir ingen nye risikoer, men tapt effektivitet.
- Egen drift hos hver kommune. Det er urealistisk for de fleste.
- Bare Åpen og Intern. Det tilbys som en begrenset standardprofil for enheter som ikke vil mer.
Vurdering. Formålet er legitimt, og behandlingen er nødvendig for å nå effektiviseringsmålet, forutsatt at tiltakene er på plass. Proporsjonaliteten styres av hvilke dataklasser kommunen tillater. Starter kommunen med Åpen og Intern, er inngrepet lite. Personopplysninger bør først åpnes når forutsetningene i kap. 8 er oppfylt.
Kommunens egen vurdering av nødvendighet og proporsjonalitet: [Kommunen fyller ut]
3.1 Rettslig grunnlag og nasjonal hjemmel
Kommunen trenger rettslig grunnlag etter art. 6 og, for særlige kategorier, art. 9. For offentlig myndighet er art. 6(1)(e) hovedregelen, med nasjonalt supplerende grunnlag (art. 6(3), personopplysningsloven § 8 og særlov). Samtykke er ikke egnet i arbeidsforhold.
3.2 Taushetsplikt, innsyn og arkiv
KI-samtaler kan være saksdokumenter, organinterne dokumenter (offentleglova § 14) eller arkivverdige (lov om dokumentasjon og arkiv, LOV-2025-06-20-96, i kraft 1. januar 2026). Kommunen avgjør status og journalføringsplikt for KI-samtaler i sin arkivplan. Målfrid støtter både journalføring (Noark-eksport) og sletting. Taushetsplikten (forvaltningsloven § 13 og særlover) gjelder også når kommunen bruker en leverandør. Se databehandleravtalen punkt 4.5.
Kommunens arkivplan og status for KI-samtaler: [Kommunen fyller ut]
4. Risikovurdering for de registrertes rettigheter og friheter
Skalaen er den samme som i ROS-analysen: sannsynlighet 1–5 × konsekvens 1–5. Skår på 6 eller lavere er grønne, 8–12 er gule, og 15 eller høyere er røde. Konsekvensen vurderes for de registrerte, ikke for Schoolhub. ROS-nummer står i parentes.
4.1 Overordnede risikoer
| # | Risiko for de registrerte | Kilde (ROS) | Før tiltak | Etter tiltak |
|---|---|---|---|---|
| D1 | Uautorisert tilgang til taushetsbelagte eller sensitive opplysninger (stjålet konto, lekkasje mellom kommuner, innsider) | R01, R08, R10 | Høy (16) | Middels (8) |
| D2 | Opplysninger sendt til leverandør uten tilstrekkelig avtale eller lokasjon, eller brukt til trening | R02, R03, R04 | Høy (15) | Middels (8–10) |
| D3 | Feil eller diskriminerende innhold i beslutningsunderlag (hallusinasjon, skjevhet) påvirker enkeltpersoner | R06 | Høy (16) | Middels (9) |
| D4 | Manglende åpenhet: de registrerte vet ikke at KI er brukt | R26 | Middels (9) | Lav (4) |
| D5 | Opplysninger beholdes for lenge, eller slettes før arkivplikten er oppfylt | R15 | Middels (12) | Lav (6) |
| D6 | Opptak av møter uten at deltakerne er informert | R17 | Middels (9) | Lav (6) |
| D7 | Misbruk av innsynsmodulen (overvåking, uriktig utlevering) | R16 | Middels (10) | Lav (5) |
| D8 | Skjulte instruksjoner i dokumenter eller nettsider (prompt injection) fører til utlevering av data fra andre kilder | R05 | Høy (16) | Middels (8) |
| D9 | Overvåking av ansatte via bruksstatistikk og revisjonslogg | R27 | Middels (9) | Lav (6) |
4.2 KI-spesifikke risikoer
| # | Risiko | Beskrivelse | Før | Etter | Hovedtiltak (kap. 5) |
|---|---|---|---|---|---|
| D10 | Hallusinasjon | Modellen finner på fakta, lovhenvisninger eller opplysninger om personer. Det kan gi feil grunnlag i en sak som rammer en innbygger eller ansatt | 16 | 9 | Kilder med forhåndsvisning, «kvalitetssikret av», opplæring, ingen vedtak |
| D11 | Skjevhet og diskriminering | Modellen gjentar skjevheter (kjønn, etnisitet, funksjonsnedsettelse, alder, dialekt) i utkast til vurderinger eller tekst om enkeltpersoner | 12 | 8 | Vurdering og rangering av personer er blokkert i assistentgodkjenningen. Evaluering og opplæring |
| D12 | Kvalitet på bokmål og nynorsk | Dårligere kvalitet på nynorsk (eller samisk og dialekt) gir feil eller språklig forskjellsbehandling av nynorskbrukere. Transkripsjon kan feile på dialekt | 12 | 6 | Modellvalg og evaluering per språk (bokmål og nynorsk) før aktivering, NB-Whisper for norsk tale, gjennomgang av nynorsk |
| D13 | Overdreven tillit til svaret | Brukere stoler for mye på svaret, og saksbehandleren vedtar uten å sjekke | 16 | 9 | Utkast-ramme, sitater, merking, opplæring (KI-forordningen art. 4 og 14), kommunens rutine |
| D14 | Lekkasje mellom kommuner | Data fra én kommune vises for en annen (feil i skillet mellom kommunenes data, delt mellomlager eller delt søkeindeks) | 15 | 5 | Kommunenes data er skilt i databasen. Innloggingen i databasen gir ikke tilgang på tvers. Automatiske tester av skillet ved hver endring. Mellomlager skilt per kommune |
| D15 | Modellleverandørs tilgang og bruk | Leverandøren lagrer, leser (misbruksovervåking) eller trener på spørsmålene. Underleverandører og myndighetstilgang | 15 | 8–10 | Databehandleravtale, innstilling hos leverandøren som hindrer lagring, leverandør etter dataklasse, TIA, tilgang først etter avtale |
| D16 | Uønskede slutninger og profilering | Modellen kobler sammen opplysninger og trekker slutninger om enkeltpersoner ut over formålet, og setter sammen et bilde av en person på tvers av dokumenter | 9 | 6 | Ingen scoring eller profilering som formål. Søk følger brukerens rettigheter. Assistentgodkjenning |
| D17 | Feil transkripsjon og feil taler | Referatet tilskriver utsagn til feil person | 9 | 6 | Menneskelig godkjenning av referat. Talere vises som «Taler n», ikke med navn |
| D18 | «Slett» oppfattes som sletting | Brukeren «sletter» en samtale som bare skjules. Fysisk sletting skjer først i oppbevaringsjobben | 9 | 6 | Beskrevet i rutinen. Fysisk sletting på instruks fra kommunen |
4.3 Særlig om D9: overvåking av ansatte
Revisjonsloggen (hvem gjorde hva, når, med hvilken modell) kan misbrukes til å følge enkeltansatte. Tiltak:
- Bare arkivadministrator, revisor og administrator for enheten har tilgang, og alle oppslag blir revidert.
- Statistikken for administratorer er samlet per enhet med en minstegrense for gruppestørrelse, og ikke per bruker.
- Loggen brukes til sikkerhet, innsyn, arkiv og KI-forordningens krav om logg. Den brukes ikke til å vurdere ansattes arbeidsinnsats.
- Bruk av logg i personalsaker er et kontrolltiltak etter arbeidsmiljøloven kap. 9. Det krever saklig grunn, drøfting med tillitsvalgte og informasjon (§ 9-1 og § 9-2). Se mal for personvernerklæring.
Avtale med tillitsvalgte om bruk av logg: [Kommunen fyller ut]
5. Tiltak for å håndtere risikoen
| Risiko | Tekniske tiltak | Organisatoriske tiltak |
|---|---|---|
| D1 | Hver kommunes data er skilt i databasen. Databasen gir ikke tilgang på tvers. Tofaktorautentisering, og sikkerhetsnøkkel eller Windows Hello der dataklassen krever det. Ny pålogging etter 8 timer for Personopplysninger. Kryptering på feltnivå med nøkkel i Scaleway Key Manager. Lukket privat nettverk der alt er stengt med mindre det er åpnet. Kontrollsum-kjede i revisjonsloggen | Minste privilegium. Tidsbegrenset tilgang via Scaleway IAM. Taushetserklæring. Tilgangsgjennomgang hvert kvartal |
| D2 | Regelsjekk før hver melding sendes til en modell. Leverandør kan låses per enhet. Innholdsdeteksjon. Utgående nettverk er bare åpent mot godkjente adresser. Tilgang til leverandør først etter databehandleravtale | Databehandleravtale med alle. Register. Årlig leverandørgjennomgang |
| D3, D10, D13 | Sitater med forhåndsvisning. KI-merking i grensesnittet og i eksport. Feltet «kvalitetssikret av». Visning av modell og region | Opplæring. Menneskelig kontroll per assistent (KI-forordningen). Ingen automatiske vedtak |
| D11, D12 | Modellvalg per språk. Assistentgodkjenningen blokkerer vurdering og rangering av personer | Evaluering på bokmål og nynorsk før aktivering. Gjennomgang av nynorsk. Kanal for klager og tilbakemeldinger |
| D4 | Synlig KI-merking, synlig modell og leverandør, informasjonstekst på bokmål og nynorsk | Kommunens personvernerklæring oppdateres |
| D5, D18 | Daglig oppbevaringsjobb. Frist på hver samtale. Bekreftelse fra arkivet | Arkivplan per kommune. Stikkprøver. Rutine for fysisk sletting |
| D6, D17 | Opplasting krever bekreftelse på at deltakerne er informert. Lyd slettes. Talere vises som «Taler n» | Mal for varsel i møteinnkalling. Møteleder godkjenner referatet |
| D7 | Egen rolle. Alle oppslag logges. Forslag til skjerming må godkjennes. Kontrollsum på utleveringspakken | Prosedyre for innsynskrav. Juridisk vurdering ved utlevering |
| D8 | Verktøy med minste privilegium. Ingen verktøy som skriver til kommunens systemer. Kilder behandles som data, ikke som instruks. Vern mot at nettsøk eller nedlasting brukes til å nå interne adresser | Hendelsesprosedyre |
| D9 | Samlet statistikk. Minstegrense. Ingen rangering av brukere | Drøfting med tillitsvalgte. Regler for bruk av logg |
| D14 | Se D1. Mellomlager skilt per kommune | Regelmessige tester av skillet |
| D15 | Innstilling hos leverandøren som hindrer lagring. Leverandør etter dataklasse. Reserveleverandør bare med samme eller strengere regler. Region logges for hvert kall | Krav til leverandørene, TIA og årlig gjennomgang |
| D16 | Ingen personregistre på tvers av brukere. Søk følger brukerens tilgang | Formålsbegrensning i assistentgodkjenningen |
Brudd håndteres etter avvikshåndtering. Sikkerhetstiltakene er beskrevet i informasjonssikkerhetspolicy.
Tilleggstiltak og lokale risikoer hos kommunen (fagsystemer, tilgangsstyring): [Kommunen fyller ut]
6. Restrisiko
Med tiltakene vurderes restrisikoen som middels for D1, D2, D3, D8, D10, D13 og D15, og som lav for de øvrige. Ingen risiko er høy etter tiltak, forutsatt at forutsetningene i kap. 8 er oppfylt.
Kommunens samlede vurdering av restrisiko: [Kommunen fyller ut]
7. Forhåndsdrøfting med Datatilsynet (art. 36)
Forhåndsdrøfting kreves når DPIA-en viser høy risiko som den behandlingsansvarlige ikke kan redusere med egne tiltak (art. 36(1)). Vurderingen for Målfrid:
- For Åpen og Intern er forhåndsdrøfting ikke nødvendig.
- For Konfidensiell og Personopplysninger er forhåndsdrøfting ikke nødvendig dersom forutsetningene i kap. 8 er oppfylt og restrisikoen er middels.
- Kommunen bør vurdere forhåndsdrøfting hvis den (a) skal bruke Personopplysninger i stor skala for sårbare grupper (barnevern, psykisk helse) og (b) ikke får tilfredsstillende databehandleravtale og TIA for en leverandør. Da sendes DPIA-en og informasjonen etter art. 36(3) til Datatilsynet, som svarer innen åtte uker (kan forlenges med seks).
Avgjørelsen tilhører kommunen, og personvernombudets råd innhentes og dokumenteres. Datatilsynets veiledning: «Når skal det gjennomføres forhåndsdrøftelse med Datatilsynet?».
Kommunens beslutning om art. 36: [Kommunen fyller ut]
8. Forutsetninger før bruk av Konfidensiell og Personopplysninger
- Databehandleravtale med alle underdatabehandlere, med EU/EØS-prosessering og forbud mot trening.
- Krav til tofaktorautentisering og betinget tilgang er kontrollert i kommunens Entra-miljø.
- Pilotbrukerne har fått opplæring (dataklasser, kvalitetssikring, overdreven tillit til svaret).
- Kommunen har oppdatert personvernerklæringen (mal) og behandlingsoversikten, og har avtalt rutiner for innsyn og avvik.
- Kommunen har drøftet logg og brukerdata med tillitsvalgte og verneombud (arbeidsmiljøloven kap. 9 og hovedavtalen).
- Kommunens egne tilføyelser i denne DPIA-en (kap. 9) er ferdige.
Kommunens bekreftelse av forutsetningene: [Kommunen fyller ut]
9. Involvering og hva kommunen må tilføye
| Hvem | Hvordan | Kommunens notat |
|---|---|---|
| Personvernombud hos kommunen | Gir råd i DPIA-en (art. 35(2)). Uttalelsen dokumenteres | [Kommunen fyller ut] |
| Registrerte eller deres representanter | Tillitsvalgte og verneombud. Brukerundersøkelse (art. 35(9)) | [Kommunen fyller ut] |
| IKT- og sikkerhetsansvarlig | Gjennomgår ROS-analysen og tiltakene | [Kommunen fyller ut] |
| Arkivar | Journalføring, sletting, Noark-eksport og status for KI-samtaler | [Kommunen fyller ut] |
| Databehandler (Schoolhub) | Utarbeider underlaget og varsler om endringer | Løpende |
Kommunen fyller ut i sin kopi:
- rettslig grunnlag per fagområde (kap. 2.9)
- hvilke enheter og dataklasser som tillates
- hvilke leverandører som slås på
- avtale med tillitsvalgte om logg
- konkrete grupper av registrerte og omfang
- lokale risikoer (fagsystemer, tilgangsstyring)
- personvernombudets uttalelse og beslutning om art. 36
10. Godkjenning og revisjon
| Rolle | Navn | Dato | Signatur |
|---|---|---|---|
| Behandlingsansvarlig (kommune) | [Navn] | [Dato] | [Signatur] |
| Personvernombud (uttalelse) | [Navn] | [Dato] | [Signatur] |
| Databehandler (Schoolhub AS) | [Navn] | [Dato] | [Signatur] |
DPIA-en revurderes ved ny leverandør, ny dataklasse eller datakilde (for eksempel skriving til arkiv, Outlook eller Teams), endring i KI-forordningens risikoklasse, hendelser av betydning og minst årlig.
Versjon 1.2, 21. oktober 2026.
Kilder
- Datatilsynet, vurdering av personvernkonsekvenser: https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/vurdering-av-personvernkonsekvenser/
- Datatilsynet, når må man gjennomføre en DPIA (liste over behandlinger): https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/vurdering-av-personvernkonsekvenser/nar-ma-man-gjennomfore-en-vurdering-av-personvernkonsekvenser/
- Datatilsynet, hvordan gjennomføre en DPIA: https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/vurdering-av-personvernkonsekvenser/hvordan-gjennomfore-en-dpia/
- Datatilsynet, risiko og risikovurdering: https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/vurdering-av-personvernkonsekvenser/risikovurdering/
- Datatilsynet, forhåndsdrøftelse: https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/vurdering-av-personvernkonsekvenser/nar-skal-det-gjennomfores-forhandsdroftelse-med-datatilsynet/
- GDPR art. 35–36: https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Artikkel 29-gruppen, WP 248 rev.01 (DPIA-retningslinjer, godkjent av EDPB): https://ec.europa.eu/newsroom/article29/items/611236
- KI-forordningen (EU) 2024/1689: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Arbeidsmiljøloven kap. 9: https://lovdata.no/dokument/NL/lov/2005-06-17-62