Vurdering av personvernkonsekvenser (DPIA) for Målfrid

Versjon 1.1, 5. november 2026.

Vurderingen 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.

Schoolhub AS (databehandler) har skrevet dokumentet 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 lager sin egen kopi, 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.

1.2 Kriterier fra EDPB og Artikkel 29-gruppen

Etter Artikkel 29-gruppens retningslinjer (WP 248 rev.01) tilsier to eller flere kriterier en DPIA. Målfrid oppfyller disse:

1. Ny teknologi.
2. Sensitive eller svært personlige opplysninger (mulig).
3. Opplysninger om sårbare registrerte: ansatte i et ujevnt maktforhold, og innbyggere som mottar tjenester.
4. Stor skala: hele kommunen, og IKT-samarbeid med flere kommuner.
5. Sammenstilling av datasett: kunnskapsbaser fra SharePoint, arkiv og møteprotokoller.

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

Målfrid er en KI-assistent for ansatte i kommuner og fylkeskommuner, med kilder, revisjonslogg og kobling til sak og arkiv. Ansatte bruker den til å søke i og oppsummere kommunens egne dokumenter, skrive utkast (saksframlegg, brev, klarspråk, bokmål og nynorsk), lage referat fra møter og svare på spørsmål om lover, forskrifter 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

2.3 Kategorier av registrerte

• Ansatte og andre brukere.
• Innbyggere, brukere, pasienter og elever som omtales i innhold som lastes opp eller skrives.
• Ansatte og tredjepersoner i personalsaker, møter og referater.
• Personer som omtales i poster i verktøy som kommunen har laget i byggeren, for eksempel avsendere av høringsinnspill, parter i saker og folkevalgte i vedtak.
• Deltakere i møter som tas opp eller transkriberes (stemme).

Kommunens konkrete grupper og omfang: [Kommunen fyller ut]

2.4 Kategorier av personopplysninger og dataklasser

Dataklassene er kommunens egne. Kommunen definerer dem som en liste der hver klasse har disse egenskapene: rekkefølge (strengere eller mindre streng), om klassen er ment for personopplysninger, hva innholdsdeteksjonen gjør (tillater, advarer, avviser eller flytter samtalen til en høyere klasse), krav til tofaktor og ny innlogging, lagringstid og handling ved utløp, om innholdet er søkbart, og hvilke funksjoner som kan brukes (for eksempel tale, nettsøk og deling med andre kommuner). En ny kommune får en startmal med fire klasser (tabellen under) eller en mal med én klasse. Kommunen kan endre, gi nye navn, slå sammen, slette og legge til klasser (opptil 12). Enheter under kommunen kan ikke definere egne klasser, men kan velge standardklasse og skjule klasser. Plattformen setter ingen minstekrav til tofaktor, ny innlogging, lagringstid, leverandører eller deling. Det er kommunens valg som behandlingsansvarlig, og hver endring logges. Denne DPIA-en beskriver startmalen. En kommune som endrer malen, vurderer sitt eget oppsett i sin kopi av DPIA-en (kap. 9). Målfrid viser et sammendrag av oppsettet som kommunen kan bruke i egen dokumentasjon.

Startmalen, som kommunen kan endre:

Kommunen setter fristene for sine klasser, høyst 3650 dager.

Tjenesten krever ikke særlige kategorier, men kan ikke hindre at de lastes opp. Derfor velger brukeren dataklasse før første melding (velgeren vises ikke når brukeren bare kan velge én klasse). Innholdsdeteksjon (fødselsnummer og D-nummer med kontrollsiffer, kontonummer, helseord, adresse og telefonnummer) gjør det klassen er satt opp til. Hva startmalen gjør i hver klasse, står i tabellen i kap. 2.4. Flytter deteksjonen samtalen til en høyere klasse, skjer det på samme måte som når brukeren hever klassen selv, før meldingen lagres eller sendes til en modell. Innhold i en klasse sendes bare til leverandører og modeller som kommunen har valgt for klassen. En leverandør eller modell som ikke er valgt, avvises.

2.5 Dataflyt og behandlingsaktiviteter

1. Brukeren logger inn med kommunens Entra ID eller Feide. Tjenesten kontrollerer at innloggingen brukte tofaktorautentisering når kommunen krever det (standard). Klassens krav, for eksempel sikkerhetsnøkkel eller Windows Hello, kontrolleres når klassen brukes. Kommunen kan velge et oppsett uten tofaktor, se D26.
2. Brukeren velger dataklasse og stiller et spørsmål, eller laster opp et dokument eller et opptak.
3. Tjenesten sjekker rolle og enhet, holder kommunens data adskilt fra andres og kjører innholdsdeteksjon. Deretter skriver den i revisjonsloggen (logg først), henter relevante kilder og sender spørsmålet gjennom regelsjekken til en språkmodell som dataklassen tillater. Svaret lages i en jobb i bakgrunnen som tåler omstart.
4. Svar og kilder vises og lagres som en samtale. Alt innhold er kryptert, uansett dataklasse, med en nøkkel som er egen for kommunen (kap. 2.10).
5. Brukeren kan eksportere til Word, PDF eller Noark 5-pakke, med KI-merking.
6. Innsyn etter offentleglova: arkivadministrator og revisor kan søke i samtaler på tvers av brukere innenfor én kommune, foreslå skjerming og lage en utleveringspakke.
7. En oppbevaringsjobb kjører daglig og sletter eller anonymiserer etter reglene. Journalførte samtaler som arkivet ikke har bekreftet mottak av, slettes ikke.
8. Nettsøk (GreenPT) er av som standard. Når kommunen slår det på, kan det bare brukes i klasser der nettsøk er en tillatt funksjon (i startmalen klassene uten taushetsbelagt innhold og personopplysninger).
9. Byggeren og verktøy: en ansatt beskriver en oppgave i byggeren og får en assistent, en flyt, en visning eller et verktøy. Et verktøy lagrer poster (for eksempel innspill) i samlinger, kjører flyter over dem og viser resultatet i en visning. Hver post har en dataklasse. Innholdet er kryptert, og bare felt som kan telles og filtreres (valg, tall, datoer, henvisninger) ligger i klartekst. Før et modellkall kan navn og direkte identifikatorer skjules (pseudonymisering). Byggeren kan skrive små funksjoner som kjører i en sandkasse uten nettverk, database og hemmeligheter. En kjøring over poster behandler opptil 2 000 poster, og hver post lagres for seg.

2.6 Lagring, lokasjon og mottakere

Alle data lagres i EU/EØS hos Scaleway SAS, et fransk selskap. Driften ligger i regionen Paris (fr-par), og sikkerhetskopi og katastrofegjenoppretting i Amsterdam (nl-ams). Scaleway leverer database, mellomlager, fillagring, nøkkelforvaltning, hemmelighetsforvaltning og utsending av e-post. Scaleway har ikke amerikansk morselskap, så hostingen innebærer ingen overføring til tredjeland. 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 en startmal og opplysninger om leverandørene, og alle endringer logges. Startmalen er:

Nettsøk og henting av nettsider leveres av GreenPT. Mistral AI er eneste leverandør av tale til tekst (Voxtral, se under) og kan slås på for tekstgjenkjenning av skannede dokumenter (Mistral OCR). Tekstgjenkjenning skjer ellers med Tesseract på våre egne maskiner. Tekstvektorer til kunnskapsbaser lages hos GreenPT i EU, også for klassene for taushetsbelagt innhold og personopplysninger. Vektorene lagres ukryptert (kap. 2.10). Opplesing av tekst skjer med Microsoft Azure AI Speech. Den er av i startmalen til kommunen slår den på og velger klassene.

Noen modeller er åpne modeller av kinesisk opphav. De kjøres bare av GreenPT og Mistral AI i EU, og kommunen kan slå dem av. Mottakerne står i registeret. Forbud mot trening på kundedata er et krav i databehandleravtalen. Telemetri inneholder verken innhold eller personidentifikatorer. Overføring til tredjeland er vurdert i TIA.

Tale til tekst. Mistral AI transkriberer lyd (Voxtral). Målfrid kjører ingen egne talemodeller. I startmalen er tale tillatt i alle klasser. Kommunen bestemmer selv hvilke dataklasser tale brukes for (provider_data_classes, nøkkel mistral/speech), og hvilke funksjoner (opplasting, levende referat, diktering, sakskontekst) som er på for hver klasse (egenskapen features i klassen). Tale i klassene for taushetsbelagt innhold og personopplysninger er altså på i startmalen, og kommunen bør vurdere det i denne DPIA-en.

Mistrals dokumentasjon nevner ikke norsk. Kommunen bør derfor måle hvor godt Voxtral transkriberer bokmål og nynorsk med egne opptak før talefunksjonene tas i bruk, og sjekke hvordan ordlisten (context_bias) virker på norsk.

Levende referat og diktering lagrer ikke lyd. Lyden strømmes til Mistral og kastes fortløpende hos oss. Bare teksten fra levende referat lagres, kryptert, og diktering lagrer ikke teksten heller. Ved opplasting av et opptak lagres lydfilen hos oss til transkripsjonen er ferdig, og følger deretter dataklassen. Ordlisten som sendes med lyden, bygges av navn og fagord fra sakslisten, medlemmer i enheten og titler på valgte kunnskapsbaser (høyst 100 enkeltord), og kommunen kan slå av kildene (speech_bias_sources). Ved opplastede opptak skiller modellen talere. I levende referat skiller modellen ikke talere, og referenten setter talernavn.

Kommunens valg av leverandører og enheter: [Kommunen fyller ut]

2.7 Teknologi, KI og menneskelig kontroll

Språkmodeller lager utkast. Svar har kilder med forhåndsvisning, og hver setning i et svar med kilder sjekkes mot kildeutdragene. Svar er merket som KI-generert og viser modell, leverandør og region. Det fattes ingen automatiske vedtak (art. 22). Målfrid skriver ikke til kommunens fagsystemer. Tilkoblinger til e-post og andre Microsoft-tjenester er av til kommunen slår dem på, og sending av e-post fra en flyt krever et godkjenningstrinn. Det brukes ingen følelsesgjenkjenning og ingen scoring av personer. Se KI-forordningen.

Verktøy laget i byggeren følger de samme reglene. Det modellen fyller ut i en post, er et forslag: en person kan rette hvert felt, og det en person har satt, overskrives aldri av en kjøring. Sitater godtas bare når de står ordrett i kilden. Lav sikkerhet i et svar sender posten til en gjennomgangskø. Handlinger i en visning (rette, slå sammen, arkivere) sjekkes på tjeneren mot rollen til den som ser visningen, og logges før de utføres. Kjøringer over poster kan ikke sende noe ut av verktøyet uten et godkjenningstrinn. Å ta et verktøy i bruk krever ikke godkjenning fra en annen person, men handlingen logges med navn.

2.8 Lagringstid

Se sletting og lagringstid. Revisjonsloggen oppbevares i 5 år, og logg over avviste forespørsler i 365 dager. Alle sikkerhetskopier (daglige kopier av databasen, ukentlige krypterte kopier og kopier av fillagringen i Amsterdam) slettes etter 30 dager, så slettet innhold er borte senest 30 dager etter sletting i de aktive systemene. Modellens arbeidsnotater og verktøyresultater i en samtale slettes etter 30 dager. Lyd følger dataklassen.

2.9 Behandlingsgrunnlag

Tabellen er et forslag. Kommunen vurderer og fyller ut sitt eget grunnlag.

2.10 Kryptering, nøkler og søk

Alt innhold er kryptert, uansett dataklasse: meldinger, titler, kilder, tekst og originalfiler i kunnskapsbaser, filer, utkast, e-post, transkripsjoner, saker i innsyn og høringer, inndata og resultater i flytkjøringer, kommentarer og lagrede eksporter. Krypteringen er AES-256-GCM. Hver kommune har en egen datanøkkel og en egen søkenøkkel. Nøklene er pakket med én nøkkelkrypteringsnøkkel i Scaleway Secret Manager, som bare API og bakgrunnsjobbene har tilgang til, og de pakkede nøklene ligger i databasen. Innhold som eies av en enhet over kommunene (for eksempel en kunnskapsbase i et IKT-samarbeid), har sin egen nøkkel. En kryptert verdi som kopieres til en annen kommunes rad, kan ikke dekrypteres der. En lekket databasekopi eller fillagring avslører derfor ikke innhold, bare konfigurasjon, metadata, vektorer og søkehasher (under). Nøkler per kommune begrenser hva én lekket nøkkel avslører, og gjør sletting av en kommunes nøkler endelig. De er ikke en tilgangsgrense: skillet mellom kommuner ligger i radnivåsikkerheten i databasen og tilgangsstyringen i API-et.

Ikke kryptert, med vilje: konfigurasjon (navn og beskrivelser av enheter, assistenter, kunnskapsbaser, flyter og visninger, og selve definisjonene), metadata som trengs for spørringer (id-er, status, tidspunkt, antall, klassenøkler) og vektorer. Revisjonsloggen inneholder id-er, antall og handlingsmetadata, ikke filnavn, titler eller tekst. Kommunen kan la byggeren avvise utkast med personopplysninger i konfigurasjonen (flows_draft_block_pii).

Kjente lekkasjer, som kommunen tar med i sin vurdering:

• Vektorer lagres ukryptert, slik at vektorsøk kan kjøre i databasen. En vektor kan delvis avsløre teksten den er laget av. Den som får tak i databasen uten nøklene, kan ikke lese innholdet, men kan i noen grad slutte seg til hva det handler om.
• Søkehasher. For klasser kommunen har gjort søkbare, lagrer Målfrid HMAC(søkenøkkel, ord) for stammen til hvert ord (bokmål og nynorsk) og for begynnelsen av ordet (3 til 10 tegn), slik at et søk på «barnevern» finner «barnevernstjenesten». Like ord hos samme kommune gir like hasher, og antallet hasher per rad er synlig. Det viser mønstre (hvilke rader som deler ord og ordbegynnelser, og omtrent hvor lange tekstene er), men ikke ordene. Derfor er søkbarhet et valg per klasse. I startmalen er klassene for taushetsbelagt innhold og personopplysninger ikke søkbare. Hashene skrives sammen med innholdet og slettes når innholdet slettes eller anonymiseres, og når en samtale flyttes til en klasse som ikke er søkbar.

Søk og tilgang. Søket bruker samme tilgangsregler som resten av tjenesten. Krever en klasse sterkere innlogging, kreves den før et utdrag vises, og oppslag i beskyttede treff logges som når en samtale åpnes. Uten søkbarhet bruker kunnskapsbaser bare vektorsøk.

Nøkler og sletting. Ved avslutning slettes kommunens nøkler etter at eksporten er levert og før radene fjernes. Nøklene er aldri en del av eksporten. Innhold i sikkerhetskopier blir uleselig når alle kopier som inneholder de pakkede nøklene, er utløpt (30 dager). Gjenopprettes en sikkerhetskopi, gjennomføres fullførte avslutninger på nytt før miljøet tar imot trafikk. Tap av nøkkelkrypteringsnøkkelen gir tap av alt innhold for alle kommuner, se D24. Innhold kan ikke leses med databaseverktøy. Support bruker API-et eller et eget verktøy som dekrypterer én verdi med kommunens nøkkel og logger bruken.

3. Nødvendighet og proporsjonalitet

Alternativer som er vurdert.

1. 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»).
2. Manuell saksbehandling. Det gir ingen nye risikoer, men arbeidet tar lengre tid.
3. Egen drift hos hver kommune. Det er urealistisk for de fleste.
4. Bare klasser uten taushetsbelagt innhold og personopplysninger, eller malen med én klasse. Kommunen kan velge det for enheter som ikke vil bruke mer.

Vurdering. Formålet er legitimt, og behandlingen er nødvendig for å nå målet om mer effektiv saksbehandling, forutsatt at tiltakene er på plass. Hvor stort inngrepet er, avhenger av hvilke dataklasser kommunen tillater. Begynner kommunen med klasser uten taushetsbelagt innhold og personopplysninger, er inngrepet lite. Klasser for taushetsbelagt innhold og personopplysninger bør ikke tas i bruk fø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 supplerende nasjonalt 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 i arkivplanen om KI-samtaler skal journalføres. Målfrid støtter både journalføring (Noark 5-pakke) 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 ganget med konsekvens 1–5. Skår på 6 eller lavere er grønn, 8–12 er gul, og 15 eller høyere er rød. Konsekvensen vurderes for de registrerte, ikke for Schoolhub. ROS-nummer står i kolonnen «Kilde».

4.1 Overordnede risikoer

4.2 Risikoer knyttet til KI

4.3 Særlig om D9: overvåking av ansatte

Revisjonsloggen viser hvem som gjorde hva, når og med hvilken modell. Den kan misbrukes til å følge enkeltansatte. Tiltak:

• Bare revisor og administrator for enheten har tilgang til revisjonsloggen, og alle oppslag logges.
• Bruksstatistikken for administratorer er samlet per enhet og viser ikke enkeltbrukere.
• Loggen brukes til sikkerhet, innsyn, arkiv og KI-forordningens krav om logging. Den brukes ikke til å vurdere ansattes arbeidsinnsats.
• Bruk av loggen 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

Brudd håndteres etter avvikshåndtering. Sikkerhetstiltakene er beskrevet i informasjonssikkerhetspolicyen.

Tilleggstiltak og lokale risikoer hos kommunen (fagsystemer, tilgangsstyring): [Kommunen fyller ut]

6. Restrisiko

Med tiltakene er restrisikoen middels for D1, D2, D3, D8, D10, D13, D15, D19, D25, D26 og D27, og lav for de andre. For D25 og D26 avhenger restrisikoen av kommunens eget oppsett. 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 klasser uten taushetsbelagt innhold og personopplysninger er forhåndsdrøfting ikke nødvendig.
• For klasser for taushetsbelagt innhold og personopplysninger er forhåndsdrøfting ikke nødvendig når forutsetningene i kap. 8 er oppfylt og restrisikoen er middels.
• Kommunen bør vurdere forhåndsdrøfting hvis den (a) skal bruke klasser med personopplysninger i stor skala for sårbare grupper (barnevern, psykisk helse) og (b) ikke får en 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. Fristen kan forlenges med seks uker.

Kommunen avgjør, og personvernombudets råd innhentes og dokumenteres. Se 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 klasser for taushetsbelagt innhold og personopplysninger

Forutsetningene gjelder klassene for taushetsbelagt innhold og personopplysninger, både i startmalen og når kommunen har definert egne klasser.

1. Databehandleravtale med alle underdatabehandlere som får disse dataklassene, med behandling i EU/EØS og forbud mot trening.
2. Krav til tofaktorautentisering og betinget tilgang er kontrollert i kommunens Entra-miljø, og klassene krever sikkerhetsnøkkel eller Windows Hello.
3. Brukerne som skal i gang først, har fått opplæring (dataklasser, kvalitetssikring, overdreven tillit til svaret).
4. Kommunen har oppdatert personvernerklæringen (mal) og protokollen over behandlingsaktiviteter, og har avtalt rutiner for innsyn og avvik.
5. Kommunen har drøftet logg og brukerdata med tillitsvalgte og verneombud (arbeidsmiljøloven kap. 9 og hovedavtalen).
6. 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

Kommunen fyller ut i sin kopi:

• rettslig grunnlag per fagområde (kap. 2.9)
• hvilke enheter som tillates, og hvilke dataklasser kommunen bruker: startmalen uendret, malen med én klasse eller et eget oppsett. Et eget oppsett (klasser, tofaktor og ny innlogging, lagringstid, søkbarhet, leverandører per klasse, deling med andre kommuner) vurderer kommunen selv, med risikoene D23 til D26
• hvilke leverandører som slås på, og for hvilke dataklasser
• 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 ny vurdering

DPIA-en vurderes på nytt ved ny leverandør, ny dataklasse eller ny datakilde (for eksempel skriving til arkiv, Outlook eller Teams), endret risikoklasse etter KI-forordningen, hendelser av betydning og minst én gang i året.

Versjon 1.1, 5. november 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