Norske arbeidsgivere oppfordres til å ta KI i bruk. Den 2. oktober kunngjorde regjeringen og hovedorganisasjonene i arbeidslivet en avtale om ansvarlig innføring av KI. Produktivitet, medbestemmelse og kompetanse står sentralt. For en bedrift som vurderer OpenAI, Anthropic, Codex eller Claude Code, gjenstår et konkret spørsmål: Hva skal verktøyene få lese, og hva skal de få gjøre?
GDPR inneholder ikke noe generelt forbud mot å bruke disse tjenestene. Samtidig gjør ikke et bedriftsabonnement all bruk lovlig. Etter min vurdering bør ledelsen godkjenne en avgrenset arbeidsoppgave, opplysningene den krever og handlingene agenten får utføre. En generell godkjenning av en leverandør er for upresis.
Bedriften trenger ikke vente på KI-loven
I oppdateringen 4. august opplyste regjeringen at ambisjonen var å fremme den norske KI-loven for Stortinget våren 2027, etter en ny høring høsten 2026. Dette er en plan for lovarbeidet, ikke en vedtatt dato for ikrafttredelse. Regjeringen understreker samtidig at personvernreglene og annet eksisterende regelverk allerede gjelder for KI. Sjekk status for norsk gjennomføring før oppstart. Virksomhet rettet mot EU kan også kreve en egen vurdering av KI-forordningens geografiske virkeområde.
Artikkelen handler om vanlige interne arbeidsoppgaver i næringslivet. Helse, finans, offentlig forvaltning og sikkerhetssensitive aktiviteter kan være underlagt tilleggskrav. Dette er en praktisk analyse for ledere, ikke en juridisk godkjenning av en bestemt løsning.
Dette ville jeg tillatt i en første innføring
Forslagene under er rammer for en intern policy, ikke lovbestemte unntak. Opplysningene, avtalene og tilgangene må vurderes i hvert tilfelle.
- Et fornuftig sted å begynne: utkast basert på offentlig informasjon, søk i godkjente interne veiledninger uten personalsaker og utvikling av tester med syntetiske data. Vurder konfidensialitet og immaterielle rettigheter også når materialet ikke inneholder personopplysninger.
- Tillat etter en dokumentert vurdering: oppsummering av kundehenvendelser, søk i tilgangsbegrensede dokumenter eller kodearbeid i et privat kodelager. Begrens personopplysningene, viderefør brukerens tilgangsrettigheter og avklar leverandørvilkår og dataoverføring først.
- Hold utenfor første runde: ubegrenset tilgang til innbokser, masseeksport av kundedata, personal- og helseopplysninger, selvstendige betalinger, destruktive endringer i produksjon og automatiserte ansettelses- eller kredittavgjørelser. Noe av dette kan være lovlig på bestemte vilkår, men krever en egen beslutningsprosess.
«Intern» beskriver hvem løsningen er til for. Det betyr ikke at behandlingen skjer innenfor bedriften. Kartlegg hva som sendes ut gjennom modellforespørsler, integrasjoner, søk, telemetri, brukerstøtte og logger.
GDPR: Seks spørsmål før dere kobler til reelle opplysninger
1. Hva er formålet, og hvilket behandlingsgrunnlag dekker det?
Datatilsynet krever behandlingsgrunnlag for hvert formål. «Vi vil bruke KI» sier for lite om arbeidet. «Lage et svarutkast til kundens spørsmål om levering» gir vurderingen et konkret utgangspunkt.
For en privat bedrift kan berettiget interesse være aktuelt. Da må interessen være reell, behandlingen nødvendig og avveiningen mot den enkeltes rettigheter falle ut i bedriftens favør. Vurder om formålet kan oppnås på en mindre inngripende måte. Et eksisterende kundeforhold rettferdiggjør ikke automatisk enhver ny analyse. Samtykke fra ansatte er som hovedregel lite egnet på grunn av maktubalansen. En samtykkeboks bør ikke være fundamentet for innføringen.
2. Kan vi bruke færre opplysninger?
Følg prinsippene om formålsbegrensning, dataminimering og lagringsbegrensning. Fjern identifikatorer og unødvendige vedlegg før en kundehenvendelse sendes til modellen. Å erstatte et navn med et kundenummer er normalt pseudonymisering, ikke anonymisering. Helseopplysninger og andre særlige kategorier krever et vilkår etter artikkel 9 i tillegg til behandlingsgrunnlag etter artikkel 6. Se GDPR artikkel 5, 6 og 9 og fortalepunkt 26.
3. Hvem behandler opplysningene, og hva sier avtalen?
Når bedriften bestemmer formålet, er den normalt behandlingsansvarlig. Behandler leverandøren personopplysninger på bedriftens vegne, krever artikkel 28 en databehandleravtale. Undersøk instrukser, underleverandører, sletting, sikkerhet, bistand ved rettighetskrav og håndtering av personvernbrudd. Kartlegg eventuelle egne formål hos leverandøren. Ikke anta at all aktivitet skjer på deres vegne. En signert avtale gir ikke i seg selv behandlingsgrunnlag. Se GDPR artikkel 4 og 28.
4. Overføres noe ut av EØS?
Datatilsynet opplyser at adekvansbeslutningen for USA fortsatt gjelder. Den kan brukes ved overføring til virksomheter som omfattes av Data Privacy Framework-listen. Kontroller riktig mottaker og hva sertifiseringen dekker. En amerikansk adresse er verken en tillatelse eller et forbud i seg selv.
Der adekvans ikke dekker overføringen, må dere vurdere et annet gyldig grunnlag, for eksempel standard personvernbestemmelser, med vurdering av mottakerlandets regelverk og nødvendige tilleggstiltak. Kartlegg også videreoverføring og fjerntilgang. Lagring i EU dokumenterer ikke at all modellbehandling, brukerstøtte og logging skjer i EØS. Ha en alternativ løsning hvis overføringsgrunnlaget endres.
5. Forstår folk bruken, og kan de utøve rettighetene sine?
Forklar behandlingen, formålene og mottakerne i relevant personverninformasjon. Sørg for at innsyn, retting og sletting kan håndteres i lagrede samtaler, dokumentkopier og logger, med de unntakene regelverket åpner for. Fastsett lagringstider og test slettingen. Dette følger praktisk av GDPR artikkel 12–17 og 25.
6. Kreves en DPIA eller en annen juridisk vurdering?
En vurdering av personvernkonsekvenser, ofte kalt DPIA, er påkrevd når behandlingen sannsynligvis vil medføre høy risiko for enkeltpersoner. Ny teknologi er et moment, ikke et automatisk unntak eller alene en automatisk utløsende faktor. Dokumenter vurderingen og rådfør dere med personvernombudet hvis dere har et. Dersom høy risiko ikke kan reduseres tilstrekkelig, kreves forhåndsdrøfting med tilsynsmyndigheten. Artikkel 22 begrenser dessuten helautomatiske avgjørelser med rettsvirkning eller tilsvarende betydelig virkning, med bestemte unntak og garantier. En medarbeider som bare godkjenner maskinens forslag mekanisk, gir ikke reell menneskelig kontroll. Se artikkel 22, 35 og 36.
OpenAI og Anthropic: Undersøk tjenesten dere faktisk kjøper
OpenAIs API-dokumentasjon sier at API-data som standard ikke brukes til trening uten at kunden velger å dele dem. Dokumentasjonen skiller dette fra lagring for misbruksovervåking, lagret applikasjonstilstand og vilkår og funksjonsbegrensninger for null datalagring og regionale kontroller. «Brukes ikke til trening» betyr ikke «ingenting lagres». Ikke anta at API-kontrollene automatisk gjelder et ChatGPT- eller Codex-abonnement.
Anthropic skiller mellom kommersiell bruk og forbrukerbruk av Claude Code. Under kommersielle vilkår brukes ikke kode og instrukser til trening av generative modeller med mindre kunden velger å bidra med data. Forbrukerkontoer har andre innstillinger. Lokal kjøring sender fortsatt data til modelltjenesten. Lokale samtalelogger og innsendinger til brukerstøtte må også vurderes.
Jeg ville bedt innkjøpsansvarlig dokumentere abonnementet, avtaleparten, driftsløsningen, modellfunksjonene, unntak fra lagringstidene og listen over underleverandører. Deretter bør IT kontrollere innstillingene med en testkonto. En skyleverandør som mellomledd eller en EU-region endrer bare vurderingen i den grad avtalen og dataflyten faktisk endres.
Slik ville jeg satt opp Codex, Claude Code og interne agenter
En kodeagent trenger to separate avklaringer: tillatelse til å sende materiale fra kodelageret til tjenesten og tillatelse til å utføre kommandoer. En sandkasse kan begrense handlinger samtidig som modellen behandler kode eksternt. Både Codex og Claude Code dokumenterer tilgangskontroll og sandkasser. Standardinnstillinger og hvilke handlinger som omfattes, varierer mellom miljøer.
Jeg ville startet med et eget utviklingsmiljø, et avgrenset kodelager, syntetiske testdata og kortlivede tilgangsnøkler. Hold produksjonshemmeligheter og kopier av kundedatabaser utenfor. La agenten foreslå endringer i en egen gren og kjøre tester. Krev uavhengig kodegjennomgang, sikkerhetskontroll og beskyttet godkjenning før endringene settes i produksjon. Test at forbudte filoppslag, nettverksforespørsler og endringer i produksjon faktisk blir blokkert.
For en egen intern agent ville jeg lagt en tjeneste bedriften kontrollerer, mellom modellen og fagsystemene. Den skal autentisere medarbeideren, hente bare autoriserte opplysninger, begrense det som sendes til modellen og kontrollere hver foreslåtte handling på serversiden. Modellen kan be om å «oppdatere denne saken». Tjenesten avgjør om brukeren har lov, og hvilke felter som kan endres. Unngå å gi modellen en gjenbrukbar administratornøkkel.
E-poster, nettsider og filer i kodelageret kan inneholde ondsinnede instrukser, kjent som prompt injection. Behandle dem som upålitelig innhold. En instruks i et dokument skal ikke gi rett til å eksportere data eller overføre penger. Vurder tilkoblede verktøy, inkludert MCP-servere, som ekstra programvare og datamottakere. Logg beslutninger og handlinger med begrenset tilgang, sett grenser for forbruk og kjøring, og test hvordan løsningen stoppes og gjenopprettes. Dette er mine anbefalte tiltak; den konkrete utformingen må følge arbeidsoppgaven.
Involver de ansatte før løsningen overvåker dem
En assistent som hjelper med å skrive en rapport, er noe annet enn et system som rangerer den som skriver. Hvis agentlogger eller produktivitetsmålinger brukes som kontrolltiltak, stiller arbeidsmiljøloven kapittel 9 krav om saklig grunn og forholdsmessighet, tidlig drøfting med tillitsvalgte, informasjon til berørte ansatte og jevnlig evaluering. Vurder også relevante krav til medvirkning og tariffavtaler. Ikke gjør sikkerhetslogger om til prestasjonsmålinger uten en egen vurdering.
Risikoen ved å la være må også vurderes
Min vurdering er at full stans kan la manuelle feil, treg kundebehandling og etterslep i sikkerhetsarbeidet fortsette. Den kan også bidra til at medarbeidere bruker private verktøy utenfor godkjente rutiner. Dette er mulige konsekvenser som bør undersøkes, ikke dokumentasjon på at enhver KI-investering lønner seg. Automatisering kan samtidig gi mer kontrollarbeid, nye sårbarheter, leverandøravhengighet og egne kostnader.
Sammenlign en avgrenset pilot med dagens arbeidsmåte og et enklere alternativ uten KI. Mål ferdig utført arbeid, kvalitet, kontrolltid, hendelser og samlet kostnad. Hvis et tenkt team sparer 30 timer i måneden, men bruker 12 timer på kontroll og retting, er gevinsten 18 timer før driftskostnader. Det er frigjort kapasitet. Verdien avhenger av hva teamet bruker den til.
Jeg ville gitt den første måneden en konkret rekkefølge: Velg én ansvarlig og én oppgave. Avklar data og avtaler. Test i et isolert miljø. Vurder deretter en begrenset pilot med reelle opplysninger først når nødvendige tiltak er på plass. Stopp ved uautorisert tilgang, vesentlige feil eller manglende sporbarhet. Utvid bruken når resultatene viser en reell gevinst.
Et nyttig ledervedtak er presist: Dette teamet kan bruke denne tjenesten til denne oppgaven, med disse opplysningene og tilgangene, under denne personens ansvar. For eksempler på vurdering av gevinster og feil, les KI i mellomstore bedrifter: Hva virker, og hva går galt?.
Kilder og avgrensning
Kildene ble gjennomgått 11. oktober 2026 og er lenket ved de aktuelle påstandene. Regjeringens kunngjøringer beskriver politikk og planer for lovarbeid. GDPR og myndighetenes veiledning underbygger regelverksdelen. Leverandørdokumentasjonen beskriver produktfunksjoner, ikke en norsk godkjenning av etterlevelse. Forslagene til innføring og vurderingen av forretningsrisiko er min analyse. Kontroller regelverksstatus og den valgte tjenesten før innføring.