Skygge-IT og ikke-godkjente KI-verktøy ved universiteter og høyskoler: slik finner, prioriterer og godkjenner dere dem

Alle universiteter og høyskoler bruker programvare som sentral IT aldri har vurdert: gratis KI-assistenter, nettleserutvidelser, verktøy for spørreundersøkelser betalt av prosjektmidler, transkripsjonsroboter som blir med i møter. Denne guiden forklarer hvorfor det skjer, hvilken risiko det gir etter GDPR og NIS2, hvordan dere finner verktøyene med administrasjonskonsollene dere allerede har, og hvordan dere bygger en godkjenningsprosess som forskerne faktisk bruker.

Publisert 9. oktober 2026 · Kilder kontrollert 9. oktober 2026

Finnes også på: English · Svenska · Nederlands · Suomi · Dansk · Français · Español · Português

1. Hva er skygge-IT, og hva er skygge-KI?

Skygge-IT er programvare, skytjenester eller maskinvare som brukes i arbeid for institusjonen uten å ha gått gjennom den vanlige vurderingen hos IT, informasjonssikkerhet, personvern og innkjøp. Skygge-KI er den delen som gjelder KI-tjenester: chatboter, skriveassistenter, møteroboter, transkripsjon, oversettelse og litteraturverktøy. Ingen av begrepene forutsetter onde hensikter. Det meste av skygge-IT oppstår fordi noen trengte å få gjort jobben.

En forskergruppe ved University of Maryland, Baltimore County (UMBC), som studerte skygge-IT i høyere utdanning gjennom en casestudie og en spørreundersøkelse blant IT-fagfolk, beskriver det som programvare eller maskinvare i et system eller nettverk som ligger utenfor den ansvarlige IT-enhetens vanlige vurderingsprosess. Det samme arbeidet peker på mulige faktorer som øker sårbarheten for slike sikkerhetshendelser, blant annet graden av desentralisert IT og institusjonens holdning til skygge-IT.

Ved et europeisk universitet kan typiske eksempler være:

• en underviser som bruker en gratis KI-quizgenerator med en klasseliste;
• en forskergruppe som transkriberer intervjuer i en transkripsjonsapp for privatpersoner;
• en avdeling som betaler for et nettbasert verktøy for spørreundersøkelser med betalingskort;
• en app med «logg inn med Microsoft» eller «logg inn med Google» som en ansatt har gitt tilgang til e-post, kalender eller filer;
• en nettleserutvidelse som leser hver side brukeren åpner for å rette grammatikk eller oppsummere tekst;
• en KI-møteassistent som blir med i digitale møter og tar opp dem.

2. Hvorfor skygge-IT er utbredt ved universiteter

Universiteter og høyskoler er blant de mest desentraliserte organisasjonene i Europa. Det er en styrke for forskning og undervisning, og grunnen til at en sentral godkjenningsprosess alltid vil ligge etter det folk faktisk bruker.

• Akademisk frihet og lokal selvstendighet. Forskere velger egne metoder og verktøy, og fakulteter og institutter har ofte egne IT-ansatte og budsjetter.
• Innkjøp fra prosjektmidler. Forskningsprosjekter kjøper tjenester med prosjektmidler, noen ganger med betalingskort eller via personlige utlegg, som kanskje aldri når sentral innkjøpsfunksjon eller personvernombudet.
• Gratisversjoner. Mange verktøy er gratis for enkeltpersoner. Uten kjøp er det heller ikke noe innkjøpssteg, men pliktene etter GDPR følger opplysningene, ikke fakturaen.
• Nettleserutvidelser og tillegg. De installeres på sekunder, trenger ofte vide tillatelser til å lese sideinnhold og er usynlige for tradisjonelle programvareoversikter.
• OAuth-samtykke. Microsofts dokumentasjon for Entra ID sier at «all users are allowed to consent to applications for permissions that don't require administrator consent» (alle brukere som standard kan samtykke til apper for tillatelser som ikke krever administratorsamtykke). En bruker kan derfor koble en tredjepartsapp til sin egen e-postkasse uten at noen andre ser det.
• KI-assistenter. Generativ KI kom raskere enn innkjøpssyklusene. Institusjonene svarte med veiledning og egne tjenester, men forbrukerverktøyene er fortsatt bare én nettleserfane unna.
• Gjesteforskere, studenter og eksterne partnere. De tar med egne verktøy og kontoer, og samarbeid på tvers av institusjoner betyr at data flyter gjennom tjenester som ingen enkeltinstitusjon har godkjent.

Validemics analyse Skygge-IT er også et signal. Når mange bruker det samme ikke-godkjente verktøyet, betyr det som regel at institusjonen ikke tilbyr et akseptabelt alternativ, eller at godkjenningsprosessen er for treg eller vanskelig å finne. Behandle resultatene av kartleggingen som en liste over udekkede behov, ikke bare som en liste over risikoer.

3. Risikoene: GDPR, overføringer, KI-trening, sikkerhet, universell utforming, lisenser, NIS2

Risikoen er ikke at ikke-godkjente verktøy alltid er dårligere enn godkjente. Den er at ingen har kontrollert dem, så ingen kan vise at pliktene nedenfor er oppfylt.

Pliktene som behandlingsansvarlig etter GDPR (art. 24, 28 og 32)

Når ansatte bruker et verktøy i arbeidet, er institusjonen normalt behandlingsansvarlig for behandlingen. Artikkel 24 i GDPR krever at den behandlingsansvarlige gjennomfører egnede tekniske og organisatoriske tiltak og kan påvise at behandlingen er i samsvar med forordningen. Artikkel 28 nr. 1 sier at den behandlingsansvarlige bare skal bruke databehandlere som gir tilstrekkelige garantier, og artikkel 28 nr. 3 krever en skriftlig avtale med hver databehandler. Artikkel 32 krever et sikkerhetsnivå som står i forhold til risikoen. Et gratisverktøy som er tatt i bruk ved å klikke seg gjennom en forbrukerlisens, har som regel ingen databehandleravtale med institusjonen, og en behandlingsprotokoll (art. 30) som ikke omfatter verktøyet, er ufullstendig. Vår side om personvernforordningen gjengir artiklene i sin helhet.

Den nederlandske tilsynsmyndigheten (Autoriteit Persoonsgegevens, AP) har trukket den praktiske konklusjonen for KI-chatboter. I advarselen av 6. august 2024 skrev AP: «Often, employees use the chatbots on their own initiative and contrary to the agreements made with the employer» (ansatte bruker ofte chatbotene på eget initiativ og i strid med avtalene med arbeidsgiveren). Hvis personopplysninger ble lagt inn i en slik situasjon, betyr det ifølge AP at det foreligger et brudd på personopplysningssikkerheten; der bruk av chatboter er virksomhetens retningslinje, «it is not a data breach, but often not permitted by law» (er det ikke et brudd, men ofte ikke lovlig). Brudd kan måtte meldes innen 72 timer (art. 33), i Norge til Datatilsynet. Se vår guide til håndtering av brudd ved universiteter (på engelsk).

Overføring til tredjeland

Mange gratisverktøy driftes fra land utenfor EØS. Kapittel V i GDPR (fra art. 44) tillater bare overføringer med et overføringsgrunnlag, som en beslutning om tilstrekkelig beskyttelsesnivå eller standard personvernbestemmelser. En enkeltperson som registrerer seg på en forbrukertjeneste, etablerer ikke slike grunnlag på vegne av institusjonen. Vår guide til EU-US Data Privacy Framework og verktøyet for overføringsgrunnlag forklarer alternativene.

KI-trening på opplastede data

AP advarte om at «Most companies behind the chatbots store all data entered» (de fleste selskapene bak chatbotene lagrer alle data som legges inn), ofte uten at den som legger dem inn, er klar over det. Københavns Universitet sa i mai 2024 til de ansatte at de fleste generative KI-verktøy lagrer det brukerne skriver inn og bruker det til å utvikle de underliggende modellene, og ba de ansatte bare bruke verktøyet institusjonen har lisens på. KI-senteret ved Oxford påpeker at forbrukerversjonene krever at brukerne selv følger med på leverandørens vilkår og reserverer seg mot trening. Abonnementsnivå er viktig: utdannings- og bedriftsavtaler har ofte andre vilkår for trening og lagring enn gratisversjonene. Våre faktaark om ChatGPT, Grammarly, Otter.ai, DeepSeek og Microsoft Copilot viser hva hver leverandør dokumenterer offentlig, per abonnementsnivå.

Sikkerhet

Ikke-vurderte apper med OAuth-tilgang til e-post eller filer er en angrepsvei. Microsofts egen dokumentasjon om Defender for Cloud Apps påpeker at OAuth-apper «often behave unnoticed» (ofte opererer ubemerket) samtidig som de har omfattende tilganger til data i andre apper. Nettleserutvidelser kan lese og endre sideinnhold, også på sidene til institusjonens systemer. Egenutviklede verktøy er også en risiko: casestudien fra UMBC fant typiske sårbarheter som cross-site scripting og SQL-injeksjon i et internt utviklet system for forvaltning av forskningsmidler.

Universell utforming

Offentlige universiteter og høyskoler er som hovedregel offentlige organer etter direktiv (EU) 2016/2102 om tilgjengeligheten av offentlige organers nettsteder og mobilapplikasjoner. Et verktøy som en underviser krever at alle studenter bruker, men som ingen har kontrollert for universell utforming, kan utestenge studenter med funksjonsnedsettelser. Se vår side om webtilgjengelighetsdirektivet.

Lisensbrudd

Forbrukervilkår er skrevet for enkeltpersoner. De kan begrense bruken til ikke-kommersielle eller personlige formål, gi leverandøren vide rettigheter til opplastet innhold eller forby opplasting av materiale brukeren ikke eier. Ansatte som laster opp lisensiert bibliotekinnhold, upubliserte manuskripter eller andres data, kan bryte lisensen eller forfatternes rettigheter. Universiteit Utrechts vilkår for ikke-godkjente KI-verktøy ber for eksempel de ansatte ikke laste opp opphavsrettsbeskyttet, konfidensielt eller proprietært materiale, eller opptak av intervjuer.

Krav til leverandørkjeden etter NIS2, der institusjonen er omfattet

NIS2 (direktiv (EU) 2022/2555) lar landene omfatte utdanningsinstitusjoner, «in particular where they carry out critical research activities» (særlig når de driver kritisk forskningsvirksomhet) (art. 2 nr. 5 bokstav b), og forskningsorganisasjoner kan være omfattet i egen rett. Virksomheter som er omfattet, må gjennomføre risikostyringstiltak som blant annet omfatter sikkerhet i leverandørkjeden, også sikkerhetsaspektene ved forholdet mellom virksomheten og dens direkte leverandører og tjenesteytere (art. 21 nr. 2 bokstav d), og forvaltning av eiendeler. Tjenester ingen kjenner til, kan ikke dekkes av slike tiltak. Om institusjonen er omfattet, avhenger av nasjonal gjennomføring; i Norge er NIS2 ennå ikke tatt inn i EØS-avtalen. Vår NIS2-guide for universiteter og siden om NIS2-direktivet viser status i de ulike landene.

KI-forordningen: KI-kompetanse

Etter EUs KI-forordning, slik den er endret ved forordning (EU) 2026/1744, skal idriftsettere treffe tiltak som støtter KI-kompetansen til ansatte som bruker KI-systemer (art. 4). En institusjon som ikke vet hvilke KI-systemer de ansatte bruker, vil ha vanskelig for å oppfylle denne plikten. KI-forordningen er ennå ikke tatt inn i EØS-avtalen; se KI-forordningen forklart og vår guide til KI-forordningen for universiteter (på engelsk).

4. Hva tilsynsmyndigheter og sektororganer sier

Ingen europeisk personvernmyndighet har gitt egne regler om skygge-IT ved universiteter, men flere har publisert veiledning om generativ KI som får direkte anvendelse.

De svenske nasjonale retningslinjene dekker også andre områder enn personvern, blant annet anskaffelser og arbeidsrett, noe som er en nyttig påminnelse om at arbeidet med skygge-KI ikke bare er et personvernprosjekt. For andre nasjonale myndigheter, også det norske Datatilsynet, bør dere sjekke KI-sidene deres direkte; vår guide til nordiske KI-tjenester (på engelsk) dekker fellestjenestene som de nasjonale forsknings- og utdanningsnettene tilbyr.

5. Slik finner dere skygge-IT: sju kartleggingsteknikker

Kartleggingen krever ikke et nytt produkt for å komme i gang. De fleste institusjoner har allerede dataene i identitetsplattformen, økonomisystemet og nettverkslogger. Kombiner flere kilder, fordi hver av dem bare ser en del av bildet.

Teknikk 1: gjennomgang av samtykke til OAuth-apper i Microsoft Entra ID

I Microsoft Entra ID vises alle tredjepartsapper som en bruker eller administrator har gitt tilgang, som en bedriftsapplikasjon (enterprise application) med tilhørende tillatelser. Microsofts veiledning om å gjennomgå tillatelser gitt til bedriftsapplikasjoner forklarer hvordan dere ser administratorsamtykke og brukersamtykke per app. Merk én begrensning: tillatelser som brukere har gitt, kan ikke trekkes tilbake fra fanen User consent i portalen; Microsoft viser til Microsoft Graph eller PowerShell for det.

1. Eksporter listen over bedriftsapplikasjoner med delegerte tillatelser, antall brukere som har samtykket, og utgiver.
2. Marker apper med tilgang til e-post, filer, kalendere eller katalogen, apper fra ikke-verifiserte utgivere og apper med mange brukere.
3. Endre innstillingen for brukersamtykke. Microsoft anbefaler å tillate brukersamtykke «only for applications that have been published by a verified publisher» (bare for apper fra en verifisert utgiver), og den innebygde policyen begrenser dette ytterligere til tillatelser dere har klassifisert som lav påvirkning (se Configure how users consent to applications).
4. Slå på arbeidsflyten for administratorsamtykke (admin consent workflow), slik at brukere som ikke kan samtykke selv, kan sende en forespørsel. Microsoft beskriver at forespørselen sendes på e-post til administratorer som er utpekt som godkjennere, som behandler den, og at brukeren deretter varsles. Dette blir inngangsdøren til hurtigsporet.

Endrede samtykkeinnstillinger gjelder bare fremtidige samtykker; Microsoft påpeker at eksisterende tillatelser forblir uendret, så både gjennomgangen og endringen av innstillingene er nødvendig.

Teknikk 2: tilgang for tredjepartsapper i Google Workspace

Administratorer i Google Workspace styrer tredjepartsapper under API-kontroller. Googles hjelpeside Control which apps access Google Workspace data beskriver en liste over apper som har hatt tilgang til Google-data, med antall brukere og hvilke tjenester som er etterspurt, og fire tilgangsnivåer for hver app: Trusted, Limited, Specific Google data og Blocked. Administratorer kan også bestemme hva som skjer med apper som ikke er konfigurert, begrense høyrisikotillatelser for tjenester som Gmail og Drive, og la brukere be om tilgang til en app, som da legges frem for vurdering. Utdanningsutgavene har egne innstillinger for brukere under 18 år. Google påpeker at det kan ta 24 til 48 timer før data om apptilgang vises.

Teknikk 3: logger fra felles innlogging

Påloggingslogger fra Entra ID, Google eller institusjonens egen identitetsleverandør viser hvilke tjenester folk logger inn på, også tjenester koblet til via identitetsføderasjon. SSO-logger viser bare verktøy som bruker institusjonsinnlogging, så de avslører ikke gratisverktøy som brukes med private kontoer, men sammen med OAuth-gjennomgangen viser de verktøy som brukes med institusjonens e-postadresse på leverandørens egen påloggingsside.

Teknikk 4: data om utlegg og betalingskort

Be økonomiavdelingen om et årlig uttrekk av korttransaksjoner og utleggsrefusjoner med forhandlernavn som ser ut som programvareabonnementer. Grupper etter leverandør og koststed. Dette er ofte den eneste måten å finne betalte tjenester kjøpt med prosjektmidler på. Det viser også hvem dere bør snakke med, fordi hver transaksjon har en navngitt kortinnehaver eller utleggsgiver.

Teknikk 5: DNS, proxy og CASB

Aggregerte DNS- eller proxylogger viser hvilke skytjenester som nås fra campusnettet. En cloud access security broker (CASB) legger til en katalog og risikovurderinger. Microsoft beskriver at Defender for Cloud Apps bruker nettverkstrafikk og en appkatalog til å identifisere apper i bruk, og vurderer appene den finner, opp mot «more than 90 risk indicators» (mer enn 90 risikoindikatorer). Andre CASB-produkter fungerer på lignende måter. Universitetsnett er åpne, og mange arbeider utenfor campus, så behandle dette som et utvalg, ikke en fullstendig oversikt.

Nettverks- og logganalyse er i seg selv behandling av personopplysninger om ansatte og studenter. Bruk aggregerte data der det er mulig, begrens tilgangen, fastsett en lagringstid, informer de ansatte i personvernerklæringen, og involver personvernombudet og, der det er relevant, de tillitsvalgte før dere starter. Vårt verktøy for DPIA-screening hjelper dere å avgjøre om selve overvåkingen krever DPIA.

Teknikk 6: spør folk

En kort spørreundersøkelse, anonym som utgangspunkt, til institutter og forskergrupper finner ofte verktøy ingen logg vil vise: skrivebordsprogramvare, verktøy brukt på private enheter og tjenester eksterne partnere bruker i et prosjekt. Still tre spørsmål: hvilke verktøy bruker dere i undervisning, forskning og administrasjon som ikke står på listen over godkjente verktøy; hvilke opplysninger legges inn i dem; og hva trenger dere fra institusjonen for å slutte å bruke dem? Gjenta undersøkelsen hvert år.

Teknikk 7: styring av nettleserutvidelser

På administrerte enheter kan nettleserpolicyer vise og styre utvidelser. Microsofts veiledning om å styre utvidelser i Microsoft Edge med gruppepolicyer beskriver ExtensionInstallBlocklist og ExtensionInstallAllowlist (blokker alle med «*» og tillat deretter oppførte utvidelser), ExtensionSettings for å blokkere utvidelser som ber om bestemte tillatelser, og runtime_blocked_hosts for å hindre utvidelser i å lese eller endre bestemte nettsteder, for eksempel studentsystemet. Legges en installert utvidelse til på blokkeringslisten, deaktiveres den uten å avinstalleres. Chrome har tilsvarende policyer.

Validemics analyse Et fornuftig første steg er ikke å blokkere alle utvidelser, noe som ville forstyrre forskning og undervisning, men å bruke runtime_blocked_hosts til å holde utvidelser unna systemene med de mest sensitive opplysningene (studentsystem, HR, økonomi, plattformer for helseforskning), og å bygge en tillatelsesliste ut fra hva kartleggingen viser at faktisk brukes.

Vurderer du en leverandør akkurat nå? Validemic går gjennom leverandørens dokumenter opp mot GDPR og KI-forordningen og oppgir kilde for hver vurdering. Prøv demomiljøet

6. En prioriteringsmodell etter data og integrasjon

Når dere har en liste, må dere bestemme hvor vurderingsinnsatsen skal brukes. To spørsmål gjør det meste av jobben: hva er de mest sensitive opplysningene verktøyet vil berøre, og hvor dypt integreres det med institusjonens systemer? Bruk institusjonens eksisterende informasjonsklassifisering der dere har en (mange institusjoner bruker tre eller fire klasser, for eksempel åpen, intern, fortrolig og strengt fortrolig eller «rød»).

Tidene er planleggingsmål, ikke rettslige krav. Legg til to justeringer. KI-funksjoner som genererer innhold om personer, vurderer studenter eller gir anbefalinger, flytter et verktøy ett nivå opp, fordi rolleavklaring, bruk til trening og stilling etter KI-forordningen må kontrolleres. Et verktøy som mange allerede bruker, flyttes frem i køen, fordi eksponeringen allerede finnes.

7. En godkjenningsprosess med hurtigspor

Hurtigsporet finnes for å gjøre den godkjente veien raskere enn den ikke-godkjente for de fleste søknader. Det virker bare hvis det er lett å finne, krever lite og gir svar raskt.

1. Én inngangsdør. Ett kort skjema, lenket fra IT-tjenesteportalen, sidene med KI-veiledning og meldingen i arbeidsflyten for administratorsamtykke. Til sammenligning tar Universiteit Utrechts spørreskjema for KI-verktøy omtrent 30 minutter å fylle ut.
2. Sjekk om svaret allerede finnes. Før vurderingen starter, sjekk de tre listene. Er verktøyet allerede godkjent, eller passer et godkjent alternativ, svar samme dag.
3. Prioriter. Bruk matrisen for data og integrasjon. Registrer nivå og begrunnelse.
4. Samle inn dokumentasjon fra leverandøren én gang. For nivå 1 holder det som regel med offentlige vilkår, personvernerklæring og innstillinger. For nivå 2 og høyere, be leverandøren om databehandleravtale, liste over underdatabehandlere, overføringsgrunnlag og sikkerhetsdokumentasjon. Vårt gratis verktøy for spørreskjema til leverandører lager et spørreskjema tilpasset nivået.
5. Beslutt med vilkår. De fleste utfall i hurtigsporet er «godkjent med vilkår»: bare institusjonsinnlogging, trening slått av, ingen personopplysninger ut over brukerkontoer, bare et bestemt emne eller prosjekt, ny vurdering om 12 måneder.
6. Publiser resultatet. Før verktøyet opp på riktig liste, slik at neste person får svar med en gang. Oppdater behandlingsprotokollen (se vår mal for behandlingsprotokoll).
7. Følg opp. Vilkårene er ikke bedre enn leverandørens vilkår. Følg med på endringer i underdatabehandlere og vilkår, og vurder på nytt når leverandøren legger til KI-funksjoner. Vårt gratis verktøy for varsler om underdatabehandlere kan hjelpe.

Avklar hvem som beslutter. I Utrecht betaler fakultetet som bruker et godkjent verktøy, for det, som regel ved å kjøpe direkte fra leverandøren. I Cambridge er lisensierte GenAI-verktøy ut over de sentrale ikke forbudt, men «must be procured in accordance with any applicable procurement policy or process» (må anskaffes i tråd med gjeldende innkjøpsregler og -prosesser), og instituttet bærer risikoen. Begge modellene fungerer hvis de er skrevet ned.

8. Godkjent, godkjent med vilkår, ikke godkjent

Listene er det mest synlige resultatet av prosessen og det viktigste virkemiddelet for å endre atferd. Universiteit Utrecht bruker nøyaktig tre utfall for KI-verktøy i undervisningen: godkjent, godkjent med vilkår og ikke godkjent. Godkjente verktøy kan brukes etter sine vilkår og vilkårene knyttet til godkjenningen.

Hold listen over ikke-godkjente verktøy kort og saklig. En lang liste over forbudte verktøy inviterer folk til å lete etter det neste som ikke står der. En kort liste med tydelige alternativer virker bedre. For et bilde av hva andre institusjoner godkjenner, se KI-verktøy godkjent ved europeiske universiteter, og for formuleringer i retningslinjer, vår mal for KI-retningslinjer ved universiteter (begge på engelsk).

9. Slik gjør europeiske universiteter det

Sidene nedenfor viser de viktigste byggesteinene i praksis: et institusjonelt alternativ, regler for data knyttet til klassifisering, en uttalelse om ikke-godkjente verktøy og en vei for å be om vurdering. De ble kontrollert 9. oktober 2026.

Validemics analyse Mønsteret er det samme på tvers av land: tilby et godt institusjonelt alternativ først, knytt regler for data til den eksisterende klassifiseringen, og si tydelig hva som ikke er tillatt. Det som sjeldnest publiseres, er veien for å be om vurdering av alt annet. Utrecht er et godt eksempel på en institusjon som publiserer veien, spørreskjemaet og de mulige utfallene.

10. Dialog med forskere og undervisere

Det meste av skygge-IT skapes av folk som prøver å gjøre jobben sin godt. Kommunikasjon som behandler dem som problemet, driver gjerne bruken lenger ut av syne. Noen prinsipper hjelper:

• Start med alternativet. «Bruk GPT UiO, UU AI-Chat eller Aalto AI Assistant til dette» er mer nyttig enn «ikke bruk ChatGPT». Hver oppføring på listen over ikke-godkjente verktøy bør nevne et alternativ.
• Knytt reglene til data, ikke merkenavn. APs råd er at virksomheter bør gjøre det klart for de ansatte hvilke opplysninger de kan og ikke kan legge inn. Regler knyttet til dataklasser gjelder fortsatt når nye verktøy dukker opp.
• Tilby en gjennomgang uten skyld. Inviter institutter til å melde fra om verktøy de allerede bruker, og vurder dem uten konsekvenser for dem som meldte. Kartleggingsdata er langt mer nyttige når folk samarbeider.
• Svar raskt. Publiser en måltid for beslutninger i hurtigsporet, og rapporter mot den.
• Forklar begrunnelsen i én setning. «Gratisversjonen bruker det du skriver inn til trening og har ingen databehandleravtale» blir forstått; «ikke i samsvar med regelverket» gjør det ikke.
• Bruk eksisterende kanaler. Forskningsstøtte, biblioteket, sentre for undervisning og læring og IT-ansatte på fakultetene har akademikernes tillit. Orienter dem først.
• Koble til forskningsprosessene. Spør om verktøy i datahåndteringsplanen og i forskningsetiske søknader, slik at verktøyene vurderes før datainnsamlingen, ikke etterpå.

Opplæring støtter også plikten etter KI-forordningen til å treffe tiltak for KI-kompetanse. Vår guide GDPR og KI-verktøy i forskning (på engelsk) er skrevet for forskere og kan deles direkte.

11. Måltall som viser fremgang

Velg et lite antall måltall som dere kan hente fra systemer dere allerede har. Rapporter utviklingen, ikke enkelttall.

12. En plan for 90 dager

Planen forutsetter et lite team med tid fra IT-sikkerhet, personvernombudet og innkjøp. Tilpass omfanget til institusjonens størrelse.

Etter 90 dager blir arbeidet rutine: søknadsskjemaet mater hurtigsporet, kartleggingen kjøres månedlig, og listene gjennomgås minst årlig. Å trekke tilbake eksisterende samtykker og flytte brukere bort fra verktøy som ikke er godkjent, tar lengre tid og bør skje når et alternativ er på plass.

Kilder

1. Forordning (EU) 2016/679 (GDPR), artikkel 24, 28, 30, 32, 33 og 44 (hentet 9. oktober 2026).
2. Direktiv (EU) 2022/2555 (NIS2), artikkel 2 nr. 5 og artikkel 21 (hentet 9. oktober 2026).
3. Forordning (EU) 2024/1689 (KI-forordningen), artikkel 4, og forordning (EU) 2026/1744 (Digital Omnibus on AI) (hentet 9. oktober 2026).
4. Direktiv (EU) 2016/2102 om tilgjengeligheten av offentlige organers nettsteder og mobilapplikasjoner (hentet 9. oktober 2026).
5. Autoriteit Persoonsgegevens: Caution: use of AI chatbot may lead to data breaches, 6. august 2024 (hentet 9. oktober 2026).
6. IMY: GDPR vid användning av generativ AI, IMY-2024-9162, 5. februar 2025 (hentet 9. oktober 2026).
7. IMY: National guidelines for generative AI in public administration are launched (hentet 9. oktober 2026).
8. CNIL: IA, la CNIL finalise ses recommandations sur le développement des systèmes d'IA, 22. juli 2025 (hentet 9. oktober 2026).
9. Jisc: Generative AI, a primer, oppdatert 1. februar 2024 (hentet 9. oktober 2026).
10. Microsoft Learn: Configure the admin consent workflow (hentet 9. oktober 2026).
11. Microsoft Learn: Configure how users consent to applications (hentet 9. oktober 2026).
12. Microsoft Learn: Review permissions granted to enterprise applications (hentet 9. oktober 2026).
13. Google Workspace Admin Help: Control which apps access Google Workspace data (hentet 9. oktober 2026).
14. Microsoft Learn: Overview of Microsoft Defender for Cloud Apps (hentet 9. oktober 2026).
15. Microsoft Learn: Use group policies to manage Microsoft Edge extensions (hentet 9. oktober 2026).
16. UMBC Cyber Defense Lab: Shadow IT in Higher Education: Survey and Case Study for Cybersecurity, 2021 (hentet 9. oktober 2026).
17. Trinity College: Higher Education Community Vendor Assessment Toolkit (HECVAT) (hentet 9. oktober 2026).
18. Universiteit Utrecht: Allow-listing process for AI tools (hentet 9. oktober 2026).
19. Universiteit Utrecht: Conditions of use of AI tools by teachers and educational support staff (hentet 9. oktober 2026).
20. Universiteit Utrecht: AI platforms at UU (hentet 9. oktober 2026).
21. University of Oxford AI Competency Centre: GenAI tool features (hentet 9. oktober 2026).
22. University of Cambridge: Data protection guidance on AI (hentet 9. oktober 2026).
23. University of Edinburgh: Generative AI guidance for staff (hentet 9. oktober 2026).
24. University of St Andrews: Approved AI software (hentet 9. oktober 2026).
25. University of Reading: Generative AI and AI meeting assistants (hentet 9. oktober 2026).
26. Helsingfors universitet: Generative artificial intelligence at the University (hentet 9. oktober 2026).
27. Aalto-universitetet: Aalto AI Assistant (hentet 9. oktober 2026).
28. Universiteit van Amsterdam: UvA AI Chat (hentet 9. oktober 2026).
29. Uppsala universitet: AI tool for students (hentet 9. oktober 2026).
30. KTH: AI services (hentet 9. oktober 2026).
31. Universitetet i Oslo: GPT UiO and red data (hentet 9. oktober 2026).
32. Københavns Universitet: Three guidelines and a new tool for using AI, 8. mai 2024 (hentet 9. oktober 2026).
33. Aarhus Universitet: Microsoft 365 for students (hentet 9. oktober 2026).

Om denne siden

Kildene er kontrollert 9. oktober 2026. Vi har lest administratordokumentasjonen fra Microsoft og Google, sidene til personvernmyndighetene og universitetssidene som er oppført ovenfor; EU-rettsaktene er sitert fra versjonene i Den europeiske unions tidende. Engelske sitater er gjengitt i original med vår norske oversettelse i parentes; oversettelsene er ikke ordrette sitater. Universitetssider endres ofte, så sjekk gjeldende versjon før dere bygger på en detalj. Der vi gir vår egen tolkning, er den merket som Validemics analyse. Tidene i prioriteringsdelen er planleggingsmål, ikke rettslige krav. Siden er generell informasjon, ikke juridisk rådgivning; nasjonal rett, avtaler med de tillitsvalgte og institusjonens egne retningslinjer kan gi tilleggskrav, særlig når det gjelder kontroll med ansattes bruk av IT. Ser du en feil eller vil foreslå et annet eksempel fra et universitet, ta kontakt med oss, så retter vi det.