Personvern og AI,
uten juristspråk.

GDPR (personvernforordningen) er teknologinøytral. Den bryr seg ikke om opplysningene behandles i et regneark, et CRM-system eller en språkmodell. Det avgjørende er om det skjer en behandling av personopplysninger. Behandling er nesten alt: innsamling, lagring, analyse, sammenstilling, deling og sletting.

I Norge gjelder GDPR gjennom personopplysningsloven av 2018, som gjør forordningen til norsk lov. I tillegg kommer EUs AI-forordning (AI Act), som regulerer selve AI-systemene. De to regelverkene gjelder side om side: AI Act erstatter ikke GDPR, og GDPR dekker ikke alt AI Act krever.

Definisjonen i GDPR artikkel 4 nr. 1 er vid. En opplysning er en personopplysning hvis personen er identifisert eller identifiserbar – også hvis det krever at man kobler den med andre opplysninger.

• «Kunden i Larvik som klaget på faktura nr. 1043» er en personopplysning, selv uten navn.
• Lydopptak, bilder og video av personer er personopplysninger.
• Logger med bruker-ID og IP-adresse er personopplysninger.
• Opplysninger om døde personer omfattes ikke av GDPR, men kan være beskyttet av annet regelverk (for eksempel taushetsplikt).

Tommelfingerregel for AI: hvis du limer inn en e-post, et saksnotat, en CV eller et kundeutdrag i en chatbot, behandler du nesten alltid personopplysninger.

GDPR spør: Har du lov til å behandle disse opplysningene om denne personen, til dette formålet, på denne måten? Den gir den registrerte rettigheter (innsyn, sletting, innsigelse osv.).

AI Act (forordning (EU) 2024/1689) spør: Hva slags AI-system er dette, hvor risikabelt er bruksområdet, og hvilke krav må den som lager det (tilbyder) og den som bruker det (idriftsetter) oppfylle? Den forbyr noen bruksområder, stiller strenge krav til «høyrisiko», krever åpenhet for chatbots og KI-generert innhold, og har egne regler for store grunnmodeller.

I praksis treffer de to ofte samme prosjekt. Et AI-verktøy som sorterer jobbsøkere er både høyrisiko etter AI Act og en behandling av personopplysninger etter GDPR – med krav etter begge.

Den behandlingsansvarlige avgjør hvorfor og hvordan personopplysninger behandles (GDPR art. 4 nr. 7). Den har hovedansvaret for at alt er lovlig.

En databehandler behandler opplysninger på vegne av den behandlingsansvarlige, etter instruks (art. 4 nr. 8 og art. 28). Typisk eksempel: en skyleverandør eller en API-leverandør av en språkmodell under bedriftsvilkår.

Men: Bruker leverandøren dataene til egne formål – for eksempel til å trene modellene sine eller til markedsføring – blir leverandøren selvstendig behandlingsansvarlig for den delen. Da må både dere og leverandøren ha rettslig grunnlag, og dere må vurdere om dere i det hele tatt har lov til å gi fra dere opplysningene. Det er en av hovedgrunnene til at bedriftsversjoner av AI-verktøy er tryggere enn gratisversjoner.

Etter GDPR art. 24 skal den behandlingsansvarlige kunne påvise at behandlingen er lovlig (ansvarlighetsprinsippet). Velger dere en leverandør som ikke gir tilstrekkelige garantier, er det deres ansvar (art. 28 nr. 1).

Databehandleren har egne plikter – blant annet sikkerhet, å følge instruks og å varsle om avvik – og kan bli ilagt bøter for brudd på disse. Etter art. 82 kan en registrert kreve erstatning fra både behandlingsansvarlig og databehandler, og de kan bli solidarisk ansvarlige.

Etter AI Act har tilbyderen (som lager systemet) og idriftsetteren (som bruker det) hver sine plikter. Å kjøpe et verktøy fritar dere ikke for pliktene som idriftsetter.

• Lovlighet, rettferdighet og åpenhet: Dere trenger et rettslig grunnlag, behandlingen må være rimelig, og folk skal få vite hva som skjer.
• Formålsbegrensning: Data samlet inn for ett formål kan ikke fritt brukes til noe annet – for eksempel AI-trening – uten vurdering.
• Dataminimering: Ikke bruk flere opplysninger enn nødvendig. Svært relevant for AI, der fristelsen er å «mate inn alt».
• Riktighet: Opplysningene skal være korrekte. Språkmodeller som «hallusinerer» om personer utfordrer dette direkte.
• Lagringsbegrensning: Ikke lagre lenger enn nødvendig – også prompt-logger og chathistorikk.
• Integritet og konfidensialitet: Tilstrekkelig sikkerhet.
• Ansvarlighet: Dere må kunne dokumentere at dere følger prinsippene.

Datatilsynet er tilsynsmyndighet for personopplysningsloven/GDPR. De gir veiledning, behandler klager, gjennomfører tilsyn og kan ilegge overtredelsesgebyr. Datatilsynet driver også en regulatorisk sandkasse for ansvarlig kunstig intelligens, der virksomheter kan få veiledning på konkrete prosjekter.

For AI Act har regjeringen meldt at Nasjonal kommunikasjonsmyndighet (Nkom) skal være koordinerende markedstilsynsmyndighet. Andre tilsyn – som Datatilsynet, Finanstilsynet og sektortilsyn – vil få oppgaver på sine områder. Den endelige organiseringen fastsettes i norsk lov. Sjekk gjeldende status før dere legger den til grunn.

Når du limer inn kundedata, utleverer du personopplysninger til leverandøren. Det krever at:

• virksomheten har et rettslig grunnlag for denne bruken av opplysningene,
• det finnes en databehandleravtale (eller tilsvarende vilkår) med leverandøren,
• leverandøren ikke bruker dataene til egne formål, som trening, uten at dette er vurdert og akseptert,
• eventuell overføring utenfor EU/EØS har gyldig grunnlag,
• bruken er i tråd med virksomhetens retningslinjer og eventuell taushetsplikt.

Bedriftsversjoner (for eksempel enterprise-, team- eller API-avtaler) har som regel slike vilkår. Privat- og gratisversjoner har ofte ikke det, og kan bruke innholdet til å forbedre tjenesten. Vilkårene endres jevnlig – sjekk alltid gjeldende vilkår for akkurat den versjonen dere bruker.

Typiske forskjeller (varierer mellom leverandører, sjekk vilkårene):

• Avtale: Bedriftsversjoner har vanligvis databehandleravtale (DPA). Privatversjoner har forbrukervilkår.
• Trening: Bedriftsdata brukes normalt ikke til trening som standard. I privatversjoner kan samtaler brukes til forbedring, ofte med mulighet til å reservere seg.
• Lagring: Bedriftsversjoner gir ofte styring av lagringstid og sletting.
• Tilgang: Enkel pålogging (SSO), tilgangsstyring og logger for administratorer.
• Dataplassering: Noen tilbyr lagring i EU/EØS.

Det at noe er «Pro» eller betalt, betyr ikke automatisk at det er en bedriftsavtale. En betalt privatkonto er fortsatt en privatkonto.

Bruk av private AI-kontoer til jobb kalles ofte «skygge-AI» (shadow AI). Problemet er at virksomheten mister kontroll: Det finnes ingen databehandleravtale, ingen styring av lagring, og innholdet kan brukes til trening.

Hvis personopplysninger havner i et privat verktøy uten grunnlag, kan det være et brudd på personopplysningssikkerheten som må vurderes for avviksmelding til Datatilsynet innen 72 timer (art. 33).

Generelle spørsmål uten persondata og uten fortrolig informasjon («forklar forskjellen på SPF og DKIM») er som regel uproblematisk – men følg alltid virksomhetens egne retningslinjer.

AI-transkribering og -oppsummering (for eksempel i Teams, Zoom eller Meet) behandler stemme, navn og alt som blir sagt – ofte også opplysninger om personer som ikke er til stede.

• Informer deltakerne før opptak starter, også eksterne.
• Rettslig grunnlag er typisk berettiget interesse. Samtykke er vanskelig i arbeidsforhold.
• Vurder møtetypen: Personalsaker, helsesaker og konfliktsaker egner seg dårlig.
• Kontroller referatet – AI kan tillegge folk ting de ikke sa.
• Sett lagringstid for opptak og transkripsjon.

Merk: Hemmelige lydopptak av samtaler man ikke selv deltar i er straffbart etter straffeloven § 205. At man deltar selv gjør det lovlig etter straffeloven, men ikke nødvendigvis i tråd med GDPR.

Bruk av AI som skrivehjelp er en av de vanligste og minst risikable bruksområdene, så lenge:

• verktøyet er godkjent og har databehandleravtale,
• du ikke limer inn sensitive opplysninger unødvendig – ofte holder det med «kunden» i stedet for navn og kundenummer,
• du leser gjennom svaret før det sendes. AI kan finne på fakta, avtalevilkår eller lovregler.

Er det en chatbot som svarer kunder automatisk, kommer i tillegg AI Act-kravet om at folk skal få vite at de snakker med en maskin (se eget spørsmål under AI Act).

Leverandører ruller ut AI-funksjoner fortløpende, ofte slått på som standard. Det kan endre risikobildet uten at noen har tatt en aktiv beslutning.

• Sjekk om databehandleravtalen dekker AI-funksjonen.
• Sjekk om det kommer nye underleverandører (for eksempel en modelleverandør).
• Sjekk om data sendes ut av EU/EØS.
• Sjekk hva AI-en får tilgang til. En assistent med tilgang til alle filer og e-poster kan avdekke dokumenter med for vide tilgangsrettigheter.

Det siste punktet er viktig: Mange virksomheter har oppdaget at AI-søk viser fram lønnslister og personalsaker som lå i delte mapper med feil tilganger. AI-en lager ikke hullet, men gjør det lett å finne.

Fritekstfelt kan inneholde navn, helseopplysninger («jeg var sykemeldt da…»), klager på ansatte og annet. Det gjør datasettet mer sensitivt enn det ser ut til.

• Vurder om formålet med analysen er forenlig med formålet undersøkelsen ble samlet inn for.
• Fjern direkte identifikatorer før analysen der det er mulig.
• Rapporter på aggregert nivå, ikke på enkeltpersoner.

Språkmodeller genererer sannsynlig tekst, ikke verifiserte fakta. Når de svarer om personer, kan de dikte opp jobbhistorikk, straffesaker eller sitater.

GDPR art. 5 nr. 1 bokstav d krever riktighet, og art. 16 gir rett til retting. Det har vært flere klager mot AI-leverandører på dette grunnlaget i Europa, blant annet en klage til det norske Datatilsynet i 2025 fra en nordmann som ChatGPT feilaktig beskrev som drapsdømt.

For dere som bruker AI: Ikke bruk AI-genererte opplysninger om personer som grunnlag for beslutninger uten å kontrollere dem mot en pålitelig kilde.

Kontrakter er noe av det folk oftest vil la AI oppsummere, sammenligne eller lete etter risiko i. Vurder tre ting før du laster opp:

• Personopplysninger: Navn, kontaktpersoner, signaturer og – i arbeidsavtaler – lønn og vilkår. Da gjelder GDPR fullt ut: godkjent verktøy og databehandleravtale.
• Konfidensialitet: Mange kontrakter har taushetsklausuler (NDA) som begrenser hvem innholdet kan deles med – også leverandører. Sjekk klausulen, og om AI-leverandøren er bundet av tilsvarende konfidensialitet i avtalen.
• Forretningshemmeligheter: Priser, rabatter, anbud og forhandlingsposisjoner. Bruk bare verktøy som ikke trener på dataene og ikke gir leverandøren rett til å bruke innholdet.

Arbeidsavtaler og kontrakter med privatpersoner er de mest sensitive. Fjern eller sladd det som ikke trengs for oppgaven. Og husk at AI kan overse eller misforstå klausuler – juridiske vurderinger må alltid kontrolleres av et menneske.

Hver behandling må ha et grunnlag i art. 6 nr. 1:

• a) Samtykke – frivillig, spesifikt, informert og utvetydig. Kan trekkes tilbake.
• b) Avtale – nødvendig for å oppfylle en avtale med den registrerte.
• c) Rettslig plikt – pålagt av lov.
• d) Vitale interesser – liv og helse, sjelden aktuelt.
• e) Allmennhetens interesse / offentlig myndighet – mest for offentlig sektor, krever supplerende rettsgrunnlag.
• f) Berettiget interesse – krever en interesseavveining.

Merk at «nødvendig» tolkes strengt. At AI gjør noe mer effektivt, betyr ikke automatisk at behandlingen er nødvendig for avtalen.

Det europeiske personvernrådet (EDPB) har gitt retningslinjer for berettiget interesse, og har i en uttalelse om AI-modeller (uttalelse 28/2024) beskrevet hvordan vurderingen gjøres for utvikling og bruk av AI.

1. Legitim interesse: Lovlig, klart formulert og reell – for eksempel å forbedre kundeservice eller avdekke svindel.
2. Nødvendighet: Kan målet nås med mindre inngripende midler, færre data eller anonymiserte data?
3. Avveining: Hva forventer personene rimelig? Hvor sensitive er dataene? Hvor mange berøres? Hvilke tiltak reduserer ulempene (pseudonymisering, reservasjonsrett, åpenhet)?

Folk har rett til å protestere mot behandling basert på berettiget interesse (art. 21), og dere må da stanse med mindre dere har tvingende grunner.

Krav til gyldig samtykke (art. 4 nr. 11 og art. 7): frivillig, spesifikt, informert, utvetydig, aktiv handling, like lett å trekke tilbake som å gi.

• I et arbeidsforhold er det skjevt maktforhold, så samtykke regnes sjelden som frivillig.
• Ved tilbaketrekking må behandlingen stanse. Er dataene brukt til å trene en modell, kan det være teknisk svært vanskelig å etterleve.
• Samtykke kan ikke «gjemmes» i generelle vilkår.

Formålsbegrensningsprinsippet sier at data samlet inn for ett formål ikke kan brukes til et uforenlig formål. Ved vurderingen av om formålene er forenlige, ser man blant annet på:

• sammenhengen mellom formålene,
• sammenhengen dataene ble samlet inn i og hva kundene kan forvente,
• hvor sensitive dataene er,
• konsekvensene for de registrerte,
• garantier som kryptering og pseudonymisering.

Eksempel: Å bruke supporthenvendelser til å trene en intern supportassistent er nærmere det opprinnelige formålet enn å bruke dem til å lage markedsføringsprofiler. Uansett må kundene informeres.

• Før du limer inn: Bytt ut navn med roller («kunde A», «saksbehandler»).
• I integrasjoner: Send bare feltene modellen faktisk trenger. Send ikke hele kundeposten hvis bare ordrelinjene er relevante.
• I AI-assistenter med tilgang til filer og e-post: Rydd i tilganger først.
• I logger: Vurder om prompter og svar må lagres, og hvor lenge.
• Ved trening: Vurder syntetiske eller anonymiserte data.

Data er anonyme når ingen – heller ikke dere – med midler som med rimelighet kan tenkes brukt, kan identifisere personene (fortalepunkt 26 i GDPR). Å fjerne navnet er sjelden nok. Kombinasjoner av postnummer, alder, yrke og datoer kan identifisere folk.

Store datamengder og AI gjør reidentifisering lettere, så anonymisering må vurderes nøye og bør etterprøves jevnlig. Selve anonymiseringen er også en behandling av personopplysninger som krever grunnlag.

Pseudonymisering (art. 4 nr. 5): Navn og identifikatorer byttes ut med koder, og nøkkelen oppbevares separat. Dette er et godt sikkerhetstiltak og reduserer risiko, men dataene er fortsatt personopplysninger for den som har – eller kan få – nøkkelen.

EU-domstolen har i 2025 (sak C-413/23 P, EDPS mot SRB) presisert at pseudonymiserte data i noen tilfeller ikke er personopplysninger for en mottaker som ikke realistisk kan reidentifisere. For avsenderen er de fortsatt personopplysninger. Dette er et nyansert område – ikke ta det som en snarvei uten konkret vurdering.

Databehandleravtalen (på engelsk Data Processing Agreement, DPA) sikrer at leverandøren bare bruker opplysningene etter deres instruks, holder dem sikre og hjelper dere å oppfylle pliktene deres. Den kan være en egen avtale eller en del av leverandørens standardvilkår.

Store AI-leverandører har standard databehandleravtaler for bedrifts- og API-kunder. Dere har sjelden mulighet til å forhandle dem, men dere har plikt til å vurdere om de er gode nok.

Avtale trengs når:

• dere bruker et AI-verktøy eller en API med personopplysninger i input,
• en AI-funksjon i et system dere bruker (CRM, e-post, kundeservice) behandler persondata,
• et konsulentselskap utvikler eller drifter en AI-løsning med tilgang til data dere er ansvarlige for.

Avtale trengs normalt ikke når dere bare bruker verktøyet uten personopplysninger. Men i praksis er det vanskelig å garantere at ingen ansatte limer inn persondata, så det tryggeste er å ha avtale for alle AI-verktøy som brukes i virksomheten.

Sjekkliste for innholdet:

• Gjenstand, varighet, art og formål med behandlingen
• Type personopplysninger og kategorier registrerte
• At leverandøren kun behandler etter dokumentert instruks
• Taushetsplikt for de som har tilgang
• Sikkerhetstiltak (art. 32)
• Vilkår for bruk av underleverandører (underdatabehandlere), med varsel og mulighet til å protestere
• Bistand ved innsynskrav og andre rettigheter
• Bistand med sikkerhet, avvik og DPIA
• Sletting eller tilbakelevering ved avtaleslutt
• Rett til revisjon og informasjon

For AI bør dere i tillegg se etter: forbud mot å bruke data til trening, lagringstid for prompter og svar, misbruksovervåking (hvem kan se innholdet og når), dataplassering og overføringsgrunnlag.

Eksempel: Dere bruker et norsk kundeservicesystem med AI-funksjon. Systemleverandøren bruker en modell fra en amerikansk AI-leverandør, som kjører på en stor skyplattform. Begge er underdatabehandlere.

Databehandleren må ha forhåndsgodkjenning fra dere (spesifikk eller generell), og ved generell godkjenning må dere varsles om endringer og få mulighet til å protestere (art. 28 nr. 2). Databehandleren må stille de samme kravene videre (art. 28 nr. 4). Be om oppdatert liste over underdatabehandlere, og følg med på varsler.

Ting å avklare i tillegg til trening:

• Lagring av prompter og svar: Hvor lenge, og kan dere styre det?
• Misbruksovervåking: Mange leverandører lagrer innhold i en periode for å oppdage misbruk, og ansatte hos leverandøren kan få tilgang i spesielle tilfeller. Finnes det unntak eller «zero data retention»-ordninger?
• Tilbakemeldinger: Gir brukere tommel opp/ned, kan innholdet behandles annerledes.
• Lokasjon: Hvor lagres og behandles dataene?
• Endringer: Hvordan varsles endringer i vilkårene?

• Avtale: Finnes databehandleravtale for den versjonen dere bruker?
• Sikkerhet: Sertifiseringer som ISO 27001 eller SOC 2-rapport, kryptering, tilgangsstyring.
• Dataflyt: Hvor behandles data, og hvem er underleverandører?
• Overføring: Er leverandøren sertifisert under EU–US Data Privacy Framework, eller brukes standardavtaler (SCC)?
• AI-spesifikt: Trening, lagring av prompter, misbruksovervåking, mulighet for sletting.
• AI Act: For høyrisikosystemer – foreligger CE-merking, bruksanvisning og dokumentasjon?
• Exit: Får dere dataene ut, og blir de slettet?

Dokumenter vurderingen. Det er dette dere må vise fram hvis Datatilsynet spør.

Som utvikler eller driftsleverandør er dere typisk databehandler. Det betyr at dere:

• skal ha databehandleravtale med kunden,
• bare kan bruke dataene etter kundens instruks – ikke til å trene egne modeller eller til andre kunder,
• må ha avtale videre med underleverandører (for eksempel AI-leverandør og skyplattform) og informere kunden om dem,
• må varsle kunden uten ugrunnet opphold ved sikkerhetsbrudd.

Bruk helst syntetiske eller anonymiserte testdata. Ekte produksjonsdata i test er en vanlig kilde til avvik.

GDPR art. 28 nr. 3 bokstav g krever sletting eller tilbakelevering. For AI-tjenester bør dere avklare:

• sletting av lagrede samtaler, filer og vektordatabaser (indekser brukt til søk i egne dokumenter),
• hva som skjer med modeller som er finjustert på deres data,
• slettefrister for sikkerhetskopier,
• bekreftelse på at sletting er gjennomført.

Overføring til land utenfor EU/EØS krever et overføringsgrunnlag:

• Adekvansbeslutning (art. 45): EU-kommisjonen har bestemt at landet har tilstrekkelig beskyttelse. For USA gjelder dette selskaper som er sertifisert under EU–US Data Privacy Framework (DPF) fra juli 2023.
• Standard personvernbestemmelser – SCC (art. 46): Avtaleklausuler fra EU-kommisjonen, kombinert med en vurdering av lovgivningen i mottakerlandet (TIA).
• Bindende virksomhetsregler (BCR) for konsern.
• Unntak (art. 49) i særlige tilfeller – ikke egnet for løpende bruk.

Sjekk om leverandøren står på DPF-listen (dataprivacyframework.gov), og for hvilke datakategorier.

I Schrems II (sak C-311/18) kom EU-domstolen til at amerikanske overvåkingslover ga for dårlig beskyttelse. Konsekvensen var at Privacy Shield falt, og at virksomheter som bruker SCC må vurdere lovgivningen i mottakerlandet og eventuelt iverksette tilleggstiltak.

EU–US Data Privacy Framework ble vedtatt i 2023 etter amerikanske lovendringer. Rammeverket ble opprettholdt av EU-domstolens underrett i 2025 (Latombe-saken), men kan bli prøvd videre. Mange virksomheter har derfor en «plan B», for eksempel SCC i tillegg, eller lagring i EU.

Lagring i EU/EØS er positivt, men sjekk:

• om tilgang fra utlandet (support, drift, misbruksovervåking) regnes som overføring – det gjør den,
• om leverandøren er underlagt lover som amerikansk CLOUD Act, som kan gi myndighetstilgang uavhengig av lagringssted,
• om alle ledd (også selve modellen) kjører i EU, eller bare lagringen.

For de fleste virksomheter er en DPF-sertifisert eller SCC-basert leverandør med EU-lagring et akseptabelt nivå. For svært sensitive data (helse, nasjonal sikkerhet, taushetsbelagt informasjon) kan det være nødvendig med strengere løsninger.

En TIA (overføringsvurdering) ser på hvilke data som overføres, hvem som har tilgang, hvilke lover myndighetene i mottakerlandet kan bruke for å kreve tilgang, og hvilke tilleggstiltak (som kryptering der leverandøren ikke har nøkkelen) som kan redusere risikoen.

Store leverandører publiserer ofte egne vurderinger som hjelp, men ansvaret for vurderingen ligger hos dere som eksportør av dataene.

Dette er et område der vilkårene endres ofte. Generelt:

• Bedrift/API: Ikke trening som standard, ifølge leverandørenes egne vilkår.
• Privat: Ofte brukt til forbedring, med en innstilling for å skru det av.
• Tilbakemeldinger: Når brukere gir tommel opp/ned eller sender inn rapporter, kan innholdet behandles særskilt.

Les vilkårene for akkurat den tjenesten og versjonen dere bruker, og sett opp en rutine for å følge med på endringer.

Trening er en egen behandling med egne krav:

• Grunnlag: Ofte berettiget interesse, med interesseavveining.
• Forenlighet: Er AI-trening noe kundene kunne forvente?
• Informasjon: Oppdater personvernerklæringen før dere starter.
• Innsigelse: Gi mulighet til å reservere seg.
• DPIA: Trening på store mengder persondata vil ofte kreve konsekvensvurdering.
• Sletting: Hvordan håndterer dere sletteforespørsler når dataene er «bakt inn» i modellen?

Et alternativ som ofte gir mye av gevinsten med mindre risiko er RAG (se eget spørsmål): Modellen henter informasjon fra en kilde dere styrer, i stedet for å trenes på den.

I uttalelse 28/2024 (desember 2024) sier EDPB at en modell bare kan anses som anonym hvis sannsynligheten for å hente ut personopplysninger fra den – direkte eller via spørsmål – er ubetydelig. Det må dokumenteres.

Det har vært ulike syn mellom tilsynsmyndigheter. Noen har ment at modellene i seg selv ikke lagrer personopplysninger slik en database gjør. Men retningen fra EDPB er at det må vurderes konkret. Er modellen utviklet ulovlig, kan det også påvirke om den kan brukes lovlig etterpå.

Med RAG lagres dokumentene i en søkbar indeks (ofte en vektordatabase). Når en bruker spør, hentes relevante tekstbiter, og modellen formulerer svaret ut fra dem.

Fordeler for personvern:

• Sletter du et dokument, forsvinner det fra svarene.
• Tilgangsstyring kan følge brukerens rettigheter.
• Lettere å vise kilde, og dermed kontrollere svaret.

Fallgruver: Indeksen er en kopi av persondata som må sikres, slettes og omfattes av avtaler. Feil tilgangsstyring kan gjøre at brukere får se innhold de ikke skal.

Innsamling av personopplysninger fra nettet er behandling. EDPB og flere nasjonale tilsyn har lagt til grunn at berettiget interesse kan være et mulig grunnlag, men med strenge krav til avveining, åpenhet, filtrering av sensitive data og respekt for reservasjoner.

Et kjent eksempel er Metas bruk av offentlige innlegg fra voksne brukere i EU/EØS til AI-trening fra 2025, der Datatilsynet informerte brukere om retten til å protestere. AI Act forbyr i tillegg ukritisk innhenting av ansiktsbilder fra internett eller overvåkingskameraer for å bygge ansiktsgjenkjenningsdatabaser.

• Sjekk personverninnstillingene i AI-tjenester og sosiale medier.
• Send innsigelse (art. 21) – selskapet må da stanse, med mindre det har tvingende berettigede grunner.
• Be om innsyn (art. 15) i hva som er registrert om deg.
• Klag til Datatilsynet hvis du ikke får svar innen en måned.

Behandling av særlige kategorier krever både et grunnlag i art. 6 og et unntak i art. 9 nr. 2 – for eksempel uttrykkelig samtykke, arbeidsrettslige forpliktelser, helsetjenester med hjemmel i lov, eller vesentlig allmenn interesse med hjemmel i lov.

Vær spesielt oppmerksom på at AI kan utlede sensitive opplysninger fra vanlige data – for eksempel helse fra kjøpshistorikk. Slike utledninger kan også regnes som særlige kategorier.

Opplysninger om straffedommer og lovovertredelser har egne regler (art. 10).

AI Act åpner for en snever adgang til å behandle særlige kategorier for å avdekke og rette skjevheter (bias) i høyrisikosystemer, med strenge vilkår (art. 10 nr. 5).

Helseopplysninger er blant de mest sensitive dataene. Generelle AI-verktøy uten særskilte avtaler og sikkerhetsvurderinger skal ikke brukes til pasientinformasjon. Helsepersonell som limer inn pasientinformasjon i et ikke-godkjent verktøy kan bryte taushetsplikten (helsepersonelloven § 21).

AI-systemer som er medisinsk utstyr reguleres i tillegg av MDR og kan være høyrisiko etter AI Act.

• Arbeidsmiljøloven kap. 9: Kontrolltiltak overfor ansatte krever saklig grunn, må ikke være uforholdsmessig belastende, og skal drøftes med tillitsvalgte så tidlig som mulig.
• Innsyn i e-post er strengt regulert i egen forskrift og er bare lov i særlige tilfeller.
• AI Act art. 5: Forbud mot AI som leser følelser hos ansatte (med unntak for medisinske og sikkerhetsmessige grunner), fra 2. februar 2025.
• AI Act vedlegg III: AI til rekruttering, forfremmelse, oppsigelse, oppgavefordeling og prestasjonsvurdering er høyrisiko. Ansattrepresentanter og berørte ansatte skal informeres før bruk (art. 26 nr. 7).

Bruk av AI til produktivitetsmåling, tastetrykkanalyse eller lignende vil i de fleste tilfeller være vanskelig å forsvare.

AI til å rekruttere, filtrere søknader og vurdere kandidater står uttrykkelig på listen over høyrisikosystemer i AI Act (vedlegg III punkt 4). Som idriftsetter må dere blant annet følge bruksanvisningen, sikre menneskelig tilsyn med kompetanse, overvåke systemet og ta vare på logger.

Etter GDPR må søkerne informeres om at AI brukes, og helt automatiserte avslag uten menneskelig vurdering vil ofte rammes av art. 22. Diskrimineringsrisiko er reell: Modeller kan lære skjevheter fra historiske ansettelser. Likestillings- og diskrimineringsloven gjelder fullt ut.

• I Norge er aldersgrensen for å samtykke selv til informasjonssamfunnstjenester 13 år (personopplysningsloven § 5).
• Profilering og markedsføring rettet mot barn bør unngås.
• AI Act forbyr AI som utnytter sårbarheter knyttet til alder for å vri atferd på en skadelig måte.
• AI i utdanning – som opptak, vurdering og overvåking ved prøver – er høyrisiko etter AI Act. Følelsesgjenkjenning i utdanningsinstitusjoner er forbudt.

Offentlig ansatte har taushetsplikt etter forvaltningsloven § 13. Advokater, revisorer, leger, psykologer og andre har egne taushetspliktregler. Det må vurderes om AI-leverandøren kan få tilgang uten at det er en ulovlig utlevering – typisk krever det at leverandøren regnes som et teknisk hjelpemiddel under tilsvarende taushetsplikt, med avtaler og sikkerhet som støtter det.

Offentlige virksomheter bør i tillegg se Digitaliseringsdirektoratets veiledning om ansvarlig bruk av KI, og vurdere arkivplikt for AI-generert saksdokumentasjon.

Art. 22 gjelder avgjørelser som utelukkende er basert på automatisert behandling, inkludert profilering, og som har rettsvirkning eller påvirker personen betydelig – for eksempel avslag på lån, forsikring, jobb eller ytelser.

Unntak finnes når avgjørelsen er nødvendig for en avtale, er tillatt ved lov, eller bygger på uttrykkelig samtykke. Selv da har personen rett til menneskelig behandling, til å uttale seg og til å bestride avgjørelsen.

EU-domstolen har slått fast (SCHUFA-saken, C-634/21, 2023) at en automatisk beregnet kredittscore kan være en «avgjørelse» etter art. 22 når den i praksis er avgjørende for utfallet – selv om et annet selskap formelt tar beslutningen.

Tilsynsmyndighetene ser på om mennesket faktisk vurderer saken. Tegn på «gummistempel»: Saksbehandleren har ikke tilgang til grunnlaget, har ikke tid, eller overstyrer nesten aldri.

AI Act art. 14 krever for høyrisikosystemer at mennesker som fører tilsyn forstår systemets begrensninger, er oppmerksomme på risikoen for å stole for mye på systemet («automatiseringsbias») og kan overstyre eller stanse det.

• GDPR art. 13–15: Rett til meningsfull informasjon om logikken, betydningen og forventede konsekvenser ved automatiserte avgjørelser. EU-domstolen har i 2025 (sak C-203/22, Dun & Bradstreet Austria) presisert at forklaringen må være forståelig og vise hvordan personens egne opplysninger ble brukt – ikke bare en generell beskrivelse eller en formel.
• AI Act art. 86: Rett til en klar og meningsfull forklaring på AI-systemets rolle i avgjørelser basert på høyrisikosystemer i vedlegg III, når avgjørelsen har rettsvirkning eller tilsvarende betydning.

Forretningshemmeligheter kan begrense hvor detaljert forklaringen må være, men kan ikke brukes til å nekte forklaring helt.

• Informasjon (art. 13–14) om hva som skjer med dataene
• Innsyn (art. 15) og kopi
• Retting (art. 16)
• Sletting (art. 17)
• Begrensning (art. 18)
• Dataportabilitet (art. 20)
• Innsigelse (art. 21)
• Automatiserte avgjørelser (art. 22)

Virksomheten skal svare innen en måned (kan forlenges med to måneder i kompliserte saker). Det er gratis.

• Lag oversikt over alle steder AI-løsningen lagrer data: chathistorikk, logger, vektordatabaser, finjusteringsdata, sikkerhetskopier.
• Bruk RAG framfor trening der det er mulig – det er lettere å slette.
• For trente modeller: Vurder filtre som hindrer at modellen gjengir bestemte opplysninger, og dokumenter hvorfor full sletting eventuelt ikke er mulig.
• Sørg for at leverandøren er forpliktet til å bistå (databehandleravtalen).

Etter GDPR art. 13–14 skal personvernerklæringen beskrive formål, rettslig grunnlag, mottakere (inkludert AI-leverandører som databehandlere eller kategorier av dem), overføring ut av EØS, lagringstid og eventuelle automatiserte avgjørelser.

AI Act art. 50 krever, fra 2. august 2026, at personer informeres når de samhandler direkte med et AI-system, med mindre det er åpenbart. Det gjelder også syntetisk innhold og deepfakes (se AI Act-delen).

Kravet står i GDPR art. 35. Datatilsynet har publisert en liste over behandlinger som alltid krever DPIA, og flere av punktene treffer AI – for eksempel bruk av innovativ teknologi, systematisk overvåking, profilering, behandling av sensitive data i stor skala og sammenstilling av datasett.

En DPIA skal inneholde:

• en systematisk beskrivelse av behandlingen og formålet,
• vurdering av nødvendighet og forholdsmessighet,
• vurdering av risiko for de registrerte,
• tiltak for å håndtere risikoen.

Er restrisikoen fortsatt høy etter tiltakene, må dere rådføre dere med Datatilsynet før dere starter (art. 36). Har dere personvernombud, skal ombudet involveres.

FRIA (Fundamental Rights Impact Assessment) kreves av offentlige organer og private som yter offentlige tjenester, samt av den som bruker høyrisiko-AI til kredittvurdering eller prising av liv- og helseforsikring. Den ser på diskriminering, rettssikkerhet, ytringsfrihet og andre rettigheter – ikke bare personvern.

AI Act sier at FRIA kan bygge på en eksisterende DPIA, så det lønner seg å gjøre dem samordnet.

• Prompt injection: Skjulte instrukser i en e-post, nettside eller et dokument får AI-en til å gjøre noe uønsket, for eksempel å sende data videre.
• Overdreven tilgang: En AI-agent med tilgang til e-post, filer og systemer kan gjøre stor skade hvis den blir manipulert. Gi minst mulig tilgang.
• Datalekkasje: Modellen gjengir innhold fra treningsdata eller andre brukeres dokumenter.
• Forgiftning: Manipulerte data i trening eller i kildene AI-en henter fra.
• Skygge-AI: Ansatte bruker ukontrollerte verktøy.

GDPR art. 32 krever et sikkerhetsnivå tilpasset risikoen. AI Act art. 15 krever robusthet og cybersikkerhet for høyrisikosystemer.

1. Stans videre spredning og dokumenter hva som skjedde.
2. Slett samtalen eller filen og kontakt leverandøren om sletting.
3. Vurder risikoen: Hvilke data, hvor mange personer, hvor sensitivt, brukes det til trening?
4. Meld til Datatilsynet innen 72 timer hvis bruddet sannsynligvis medfører risiko (art. 33).
5. Varsle de berørte hvis risikoen er høy (art. 34).
6. Før avviket i internt avvikslogg uansett – det kreves selv om det ikke meldes.

En enkel AI-policy bør dekke:

• Hvilke AI-verktøy som er godkjent, og for hva
• Hvilke data som aldri skal inn (fødselsnummer, helse, personalsaker, taushetsbelagt, kundehemmeligheter)
• Krav om kontroll av AI-generert innhold
• Merking av AI-generert innhold der det er relevant
• Hvordan nye verktøy eller funksjoner godkjennes
• Hvem man kontakter ved spørsmål eller avvik
• Opplæring – AI Act krever AI-kompetanse (se eget spørsmål)

GDPR art. 30 krever protokoll over behandlingsaktiviteter. Unntaket for virksomheter under 250 ansatte gjelder ikke hvis behandlingen ikke er sporadisk, innebærer risiko eller omfatter særlige kategorier – så i praksis må de fleste føre protokoll.

Før inn AI-leverandører som mottakere/databehandlere, og oppdater protokollen når nye AI-funksjoner tas i bruk.

Forordning (EU) 2024/1689 kalles også AI-forordningen eller KI-forordningen på norsk. Den trådte i kraft 1. august 2024 og fases inn gradvis. Den er en produktreguleringslov: Den stiller krav til AI-systemer og AI-modeller før de settes på markedet og mens de brukes, på samme måte som EU regulerer for eksempel leker og maskiner.

Den gjelder for alle som tilbyr AI-systemer i EU/EØS eller hvis AI-resultater brukes her – også selskaper utenfor EU.

EU-forordninger gjelder ikke automatisk i Norge, men må tas inn i EØS-avtalen og gjennomføres i norsk rett. Regjeringen har sendt forslag til en norsk KI-lov på høring og pekt ut Nkom som koordinerende tilsynsmyndighet.

Norske virksomheter som selger AI-løsninger til EU, eller hvis tjenester brukes i EU, er uansett berørt av forordningen direkte i EU-markedet. Og fordi Norge skal gjennomføre de samme reglene, er det lurt å forberede seg etter EU-tidslinjen.

Tidspunkt for ikrafttredelse i Norge avhenger av EØS-prosessen og Stortingets behandling – sjekk regjeringen.no og nkom.no for oppdatert status.

• 1. august 2024: Forordningen trer i kraft i EU.
• 2. februar 2025: Forbudte AI-praksiser (art. 5) og krav om AI-kompetanse (art. 4).
• 2. august 2025: Regler for generelle AI-modeller (GPAI), styringsstruktur og sanksjoner.
• 2. august 2026: De fleste øvrige regler, blant annet høyrisikosystemer i vedlegg III og åpenhetsplikter i art. 50.
• 2. august 2027: Høyrisiko-AI som er sikkerhetskomponent i produkter regulert av annet EU-regelverk (vedlegg I), og frist for GPAI-modeller som var på markedet før august 2025.

Merk: EU-kommisjonen la i november 2025 fram en «digital omnibus»-pakke med forslag om å utsette deler av høyrisikokravene, blant annet ved å knytte dem til når standarder er klare. Sjekk om endringene er vedtatt og hvilke datoer som gjelder nå. For Norge kommer i tillegg EØS-prosessen.

Definisjonen i art. 3 nr. 1 bygger på OECDs definisjon. Nøkkelen er evnen til å utlede (inference): Systemet lærer eller resonnerer seg fram til output, i motsetning til programvare som bare følger regler mennesker har skrevet.

EU-kommisjonen har gitt retningslinjer om definisjonen (februar 2025). Enkle regler («hvis beløpet er over 10 000, send til godkjenning») er ikke AI-systemer. Maskinlæringsmodeller og språkmodeller er det.

• Uakseptabel risiko – forbudt: For eksempel sosial poengscoring og følelsesgjenkjenning på arbeidsplassen.
• Høy risiko: AI i områder som rekruttering, kredittvurdering, utdanning, kritisk infrastruktur og rettsvesen. Krav til risikostyring, datakvalitet, dokumentasjon, logging, menneskelig tilsyn og nøyaktighet.
• Begrenset risiko – åpenhet: Chatbots skal si at de er AI, og syntetisk innhold og deepfakes skal merkes.
• Minimal risiko: Spamfiltre, AI i spill, de fleste interne verktøy. Ingen særlige krav utover AI-kompetanse.

De fleste AI-løsninger i vanlige bedrifter havner i begrenset eller minimal risiko.

AI Act har flere roller: tilbyder, idriftsetter, importør, distributør og produsent. Pliktene avhenger av rollen.

• Tilbyder: De tyngste pliktene – samsvarsvurdering, teknisk dokumentasjon, CE-merking for høyrisiko.
• Idriftsetter: Bruke systemet riktig, menneskelig tilsyn, informere berørte, AI-kompetanse.

Privatpersoner som bruker AI til personlige formål er ikke idriftsettere.

Art. 25 regulerer når andre enn den opprinnelige tilbyderen blir tilbyder for et høyrisikosystem. Det er særlig relevant for konsulentselskaper og programvarehus som bygger løsninger på modeller fra OpenAI, Anthropic, Google, Mistral og andre.

Eksempel: Et selskap som lager en chatbot for kunder basert på en språkmodell via API, og leverer den under eget produktnavn, er tilbyder av chatbot-systemet. Er bruksområdet begrenset risiko, er pliktene først og fremst åpenhet. Leverer dere AI til rekruttering eller kredittvurdering, blir pliktene langt tyngre.

Art. 5 forbyr fra 2. februar 2025:

• Subliminale, manipulerende eller villedende teknikker som vesentlig vrir atferd og gir betydelig skade
• Utnyttelse av sårbarhet knyttet til alder, funksjonsnedsettelse eller sosial/økonomisk situasjon
• Sosial poengscoring som gir urimelig eller uforholdsmessig negativ behandling
• Risikovurdering av at en person vil begå lovbrudd basert kun på profilering eller personlighetstrekk
• Ukritisk innhenting av ansiktsbilder fra internett eller overvåkingskameraer for ansiktsgjenkjenningsdatabaser
• Følelsesgjenkjenning på arbeidsplass og i utdanning (unntak for medisinske og sikkerhetsmessige grunner)
• Biometrisk kategorisering for å utlede rase, politisk syn, fagforeningsmedlemskap, religion, seksuell legning o.l.
• Biometrisk fjernidentifisering i sanntid på offentlige steder for politiformål, med snevre unntak

EU-kommisjonen har gitt retningslinjer med eksempler (februar 2025).

Vedlegg III-områdene:

1. Biometri (fjernidentifisering, kategorisering, følelsesgjenkjenning der det er tillatt)
2. Kritisk infrastruktur
3. Utdanning og yrkesopplæring (opptak, vurdering, overvåking ved prøver)
4. Arbeidsliv (rekruttering, forfremmelse, oppsigelse, oppgavefordeling, overvåking)
5. Tilgang til viktige private og offentlige tjenester (offentlige ytelser, kredittverdighet, prising av liv- og helseforsikring, nødmeldinger)
6. Politi og rettshåndhevelse
7. Migrasjon, asyl og grensekontroll
8. Rettspleie og demokratiske prosesser

Et system i vedlegg III er likevel ikke høyrisiko hvis det ikke utgjør vesentlig risiko – for eksempel når det bare utfører en snever prosedyreoppgave eller forbedrer resultatet av en ferdig menneskelig vurdering (art. 6 nr. 3). Men systemer som profilerer personer er alltid høyrisiko. Tilbyderen må dokumentere en slik vurdering.

Kravene står i art. 8–17 og 43–49:

• Risikostyringssystem gjennom hele livssyklusen
• Datastyring: relevante, representative og så langt mulig feilfrie trenings-, validerings- og testdata, med vurdering av skjevheter
• Teknisk dokumentasjon
• Automatisk logging av hendelser
• Åpenhet og bruksanvisning til idriftsetter
• Menneskelig tilsyn
• Nøyaktighet, robusthet og cybersikkerhet
• Kvalitetsstyringssystem
• Samsvarsvurdering, CE-merking og registrering
• Overvåking etter markedsføring og rapportering av alvorlige hendelser

Idriftsetterens plikter etter art. 26:

• Tekniske og organisatoriske tiltak for å bruke systemet i tråd med bruksanvisningen
• Menneskelig tilsyn med personer som har nødvendig kompetanse, opplæring og myndighet
• Sikre at inndata dere kontrollerer er relevante og representative
• Overvåke driften og melde fra til tilbyder og tilsyn ved risiko eller alvorlige hendelser
• Oppbevare automatisk genererte logger i minst seks måneder
• Informere ansatte og deres representanter før bruk på arbeidsplassen
• Informere personer når høyrisiko-AI brukes til avgjørelser som angår dem
• Bruke informasjonen fra tilbyderen til å gjennomføre DPIA der det kreves

Offentlige organer og noen andre må i tillegg gjennomføre FRIA (art. 27) og registrere bruken.

Art. 50 gjelder fra 2. august 2026:

• Chatbots og AI-assistenter: Tilbyderen skal utforme systemet slik at brukerne informeres om at de samhandler med AI.
• Syntetisk innhold: Tilbydere av generativ AI skal merke output maskinlesbart (for eksempel vannmerke eller metadata), slik at det kan oppdages som kunstig generert.
• Deepfakes: Idriftsetter skal opplyse om at bilde, lyd eller video er kunstig generert eller manipulert. Lettere krav for åpenbart kunstnerisk, satirisk eller fiktivt innhold.
• AI-generert tekst om saker av allmenn interesse: Skal opplyses om, med mindre teksten har vært gjennom menneskelig redaksjonell kontroll og noen har redaksjonelt ansvar.
• Følelsesgjenkjenning og biometrisk kategorisering: Personene skal informeres.

EU arbeider med en praksiskodeks for merking av AI-generert innhold.

For en vanlig bedrift som bruker AI til å skrive utkast til nettsidetekster som et menneske redigerer og står ansvarlig for, er det normalt ikke krav om merking etter AI Act. For realistiske AI-bilder av personer eller hendelser som kan oppfattes som ekte, bør dere merke.

Uavhengig av AI Act kan markedsføringsloven og god presseskikk kreve åpenhet – for eksempel ved retusjerte reklamebilder (merkeplikt for retusjert reklame med kroppsfasong i Norge).

GPAI står for «general-purpose AI». Reglene for disse modellene (kapittel V) gjelder fra 2. august 2025 og retter seg mot tilbyderne av modellene, ikke mot bedrifter som bruker dem.

Merk skillet: Modellen (for eksempel GPT eller Claude) reguleres som GPAI. Systemet som bygges på modellen (for eksempel en kundeservice-chatbot) reguleres etter risikonivået for bruksområdet.

Art. 53 krever av alle GPAI-tilbydere:

• Teknisk dokumentasjon til AI-kontoret og nasjonale tilsyn ved forespørsel
• Informasjon og dokumentasjon til tilbydere som integrerer modellen
• Policy for å overholde EUs opphavsrett, inkludert reservasjoner mot tekst- og datautvinning
• En tilstrekkelig detaljert offentlig oppsummering av treningsinnholdet etter EU-kommisjonens mal

Modeller med systemisk risiko (art. 51 og 55) – i utgangspunktet trent med mer enn 10²⁵ FLOPs – må i tillegg evaluere modellen, inkludert adversarial testing, vurdere og redusere systemiske risikoer, rapportere alvorlige hendelser og sikre god cybersikkerhet.

EU-kommisjonen publiserte en frivillig praksiskodeks for GPAI i juli 2025, som de fleste store leverandører har sluttet seg til.

Art. 4 har gjeldt i EU siden 2. februar 2025. Kompetansen skal tilpasses folks tekniske kunnskap, erfaring, utdanning og opplæring, og sammenhengen AI-en brukes i.

I praksis betyr det:

• Opplæring i hva AI kan og ikke kan – inkludert hallusinasjoner og skjevheter
• Opplæring i interne retningslinjer og personvern
• Mer inngående opplæring for dem som fører menneskelig tilsyn med høyrisikosystemer
• Dokumentasjon av hvilken opplæring som er gitt

EU-kommisjonen har publisert spørsmål og svar om art. 4. Digital omnibus-forslaget fra november 2025 foreslo å endre pliktens form – sjekk gjeldende status.

AI-kontoret ble opprettet i 2024. Det har eksklusiv kompetanse til å føre tilsyn med GPAI-modeller, mens nasjonale markedstilsynsmyndigheter fører tilsyn med AI-systemer. I tillegg finnes et europeisk KI-råd (AI Board) med representanter fra medlemslandene, et vitenskapelig panel og et rådgivende forum.

GDPR art. 83 setter rammene. Datatilsynet fastsetter beløpet etter blant annet alvorlighet, varighet, antall berørte, grad av forsett eller uaktsomhet, tiltak for å begrense skaden og tidligere brudd.

Eksempel fra AI-feltet: Det italienske datatilsynet ila i desember 2024 OpenAI et gebyr på 15 millioner euro for blant annet manglende rettslig grunnlag for trening og mangelfull informasjon. I Norge har Datatilsynet ilagt store gebyrer i andre saker, blant annet mot Grindr.

I tillegg kommer pålegg om å stanse behandling, erstatningskrav og omdømmetap – ofte dyrere enn selve gebyret.

Art. 99:

• Forbudte praksiser (art. 5): Opptil 35 mill. euro eller 7 % av global årlig omsetning, det som er høyest.
• Andre plikter (blant annet tilbydere, idriftsettere og åpenhet): Opptil 15 mill. euro eller 3 %.
• Uriktige, ufullstendige eller villedende opplysninger til tilsyn: Opptil 7,5 mill. euro eller 1 %.

For små og mellomstore bedrifter gjelder det laveste av beløpet og prosentsatsen. GPAI-tilbydere kan få gebyr fra EU-kommisjonen på opptil 15 mill. euro eller 3 % (art. 101). Nivået i Norge fastsettes i norsk lov.

Eksempel: Et rekrutteringsverktøy uten menneskelig tilsyn og uten rettslig grunnlag kan bryte både AI Act (plikter for høyrisiko) og GDPR (art. 6 og 22). Ved utmåling skal det tas hensyn til andre reaksjoner for samme forhold, og prinsippet om forbud mot dobbeltstraff kan sette grenser. Dette er et område der praksis ennå er i utvikling.

Et kjent eksempel fra Canada (Air Canada, 2024): Flyselskapet ble holdt ansvarlig for at chatboten ga feil informasjon om billettregler. Argumentet om at chatboten var «en egen enhet» ble avvist.

I EU gjelder et nytt produktansvarsdirektiv (2024) som eksplisitt omfatter programvare og AI, og som skal gjennomføres innen desember 2026. Det vil gjøre det lettere for skadelidte å få erstatning fra produsenter. Det tidligere forslaget til et eget AI-ansvarsdirektiv ble trukket av EU-kommisjonen i 2025.

1. Kartlegg: Hvilke AI-verktøy og AI-funksjoner er i bruk – offisielt og uoffisielt?
2. Klassifiser: Hvilket risikonivå etter AI Act? Behandles personopplysninger?
3. Velg verktøy: Bedriftsavtaler med databehandleravtale, ingen trening på data, EU-lagring der det trengs.
4. Retningslinjer: Hva er lov, hva er ikke lov, hvem spør man.
5. Opplæring: AI-kompetanse er et lovkrav.
6. Dokumenter: Behandlingsprotokoll, leverandørvurdering, interesseavveininger, DPIA ved behov.
7. Informer: Oppdater personvernerklæringen.
8. Følg opp: Nye funksjoner, nye vilkår, ny regulering.

En enkel huskeregel: Hvis du ikke ville sendt det på e-post til en ukjent ekstern mottaker, skal det ikke inn i et AI-verktøy uten at det er godkjent for nettopp slike data.

• Fødselsnummer og D-nummer
• Helse, diagnoser, sykefravær
• Personalsaker, advarsler, oppsigelser, lønn
• Straffbare forhold
• Passord, API-nøkler, tilgangstokener
• Taushetsbelagt informasjon
• Forretningshemmeligheter, anbud, kontrakter under forhandling
• Store eksporter fra CRM eller kundedatabaser

• Innebygd personvern (art. 25): Tenk personvern fra første skisse, ikke etter lansering.
• Minst mulig data og kortest mulig lagring
• Pseudonymisering før data sendes til modellen
• Tilgangsstyring som følger brukerens rettigheter
• Mennesker i løkka for alt som får betydning for enkeltpersoner
• Testing for skjevheter og feil
• Åpenhet – fortell hva AI brukes til
• Vurder lokale eller europeiske modeller for særlig sensitive data

• Datatilsynet: veiledere om kunstig intelligens, DPIA, interesseavveining og den regulatoriske KI-sandkassen
• Nkom: informasjon om tilsyn med AI Act i Norge
• Digdir: veiledning for offentlig sektor om ansvarlig bruk av KI
• EDPB: retningslinjer og uttalelser, blant annet uttalelse 28/2024 om AI-modeller
• EU-kommisjonen / AI Office: retningslinjer, praksiskodekser og spørsmål og svar om AI Act
• Lovtekst: personopplysningsloven og GDPR på lovdata.no, AI Act (forordning (EU) 2024/1689) på eur-lex.europa.eu

Verktøyene finnes i flere former:

• Åpen kildekode: Microsoft Presidio er et kjent bibliotek for å oppdage og maskere personopplysninger. Det kan utvides med egne regler, for eksempel for norske fødselsnumre og organisasjonsnumre.
• Kommersielle tjenester: Flere leverandører tilbyr PII-gjenkjenning og sladding som tjeneste eller som en «gateway» mellom brukerne og AI-modellen.
• Datalekkasjevern (DLP): Verktøy som Microsoft Purview kan oppdage og stoppe sensitive opplysninger før de havner i AI-tjenester, basert på regler virksomheten setter.
• AI-gateway med reversibel pseudonymisering: En mellomtjeneste bytter «Kari Nordmann» med «PERSON_1» før teksten sendes, og bytter tilbake i svaret. Brukeren merker lite, men modellen ser aldri navnet.
• Lokale modeller: For de mest sensitive dataene kan en modell som kjører på egne servere eller i egen sky være et alternativ – da forlater dataene ikke virksomheten.

Begrensninger du må kjenne til:

• Automatisk gjenkjenning bommer av og til – særlig på norske navn, stedsnavn og indirekte opplysninger som «den nye regnskapssjefen i Larvik».
• Pseudonymiserte data er fortsatt personopplysninger for den som har nøkkelen, så GDPR gjelder fortsatt – men risikoen er langt lavere.
• Forretningshemmeligheter og taushetsbelagt innhold er ikke personopplysninger, og fanges ofte ikke av slike verktøy.

Anonymisering er derfor et godt ekstra lag, ikke en erstatning for godkjente verktøy med databehandleravtale.

Erfaringen fra mange virksomheter er at strenge forbud ikke stopper AI-bruk – de flytter den til private kontoer der virksomheten mister all kontroll. Det motsatte fungerer bedre:

• Ett godkjent verktøy til alle: En bedriftsavtale med databehandleravtale, ingen trening på data og gjerne lagring i EU. Da er det meste av daglig bruk – også med en del persondata – innenfor.
• Trafikklys i stedet for lange regler: Grønt (fritt fram: generelle spørsmål, egne tekster, offentlig info), gult (greit i godkjent verktøy: kundedialog, kontrakter, interne dokumenter), rødt (bare med særskilt løsning: helse, personalsaker, fødselsnummer, taushetsbelagt).
• Teknikk der risikoen er høyest: Sladding eller pseudonymisering, DLP-regler og eventuelt lokale modeller for det røde.
• Opplæring framfor kontroll: AI-kompetanse er uansett et lovkrav, og folk som forstår risikoen tar bedre valg enn en regelbok kan.
• Godkjenn nye bruksområder raskt: En enkel vurdering på dager, ikke måneder.

Målet er ikke minst mulig AI, men AI-bruk dere har oversikt over og kan forsvare.

Kravet står i GDPR art. 37. Mange private virksomheter har ikke plikt, men har likevel en person med ansvar for personvern. Ved AI-prosjekter med persondata er det klokt å involvere personvernkompetanse tidlig – internt eller eksternt.