Shadow AI policy: 670.000 dollar i ekstra kostnad

Nøkkelpunkter per 25. september 2026:

Shadow AI koster penger. Datainnbrudd i virksomheter med høy grad av shadow AI koster 4,63 millioner dollar i snitt, 670.000 dollar mer enn andre brudd (netwrix.com, 2026).
Datatilsynet ser økningen. Tilsynet har mottatt 30 til 40 avviksmeldinger om ukontrollert AI-bruk mellom sommeren 2025 og sommeren 2026, en merkbar økning (kode24).
Bare 20 prosent har kontroll. En av fem virksomheter styrer eller overvåker ansattes shadow AI fullt ut, og 76 prosent styrer ikke AI-agenter og tjenestekontoer (netwrix.com, 2026).
Oversikt er forutsetningen. Ringerike kommune har 2.200 ansatte og over 300 fagsystemer, og IT har ikke innsikt i alle tjenestene kommunen leverer (kode24).
Utviklerne er det nye målet. Sikkerhetsekspert Tanya Janca, med 29 års erfaring, mener utviklere må beskyttes og begrenses i AI-bruken (kode24).

Shadow AI: når ansatte bruker AI-verktøy ingen har godkjent

Shadow AI er ikke et begrep IT-avdelingen fant på for å gjøre livet surt. Det oppstår når ansatte tar i bruk AI-verktøy ingen har godkjent, slik at sensitive data flyttes ut av virksomhetens kontroll (netwrix.com, 2026). Problemet er ikke verktøyet i seg selv. Problemet er at data forlater et sted dere kan logge og havner et sted dere ikke kan logge, uten at noen har tatt en beslutning om det.

For norske virksomheter er dette allerede hverdag. Datatilsynet advarer mot at ansatte bruker personlige AI-kontoer på jobb, og mot at både AI-verktøy og AI-agenter kan få for mye tilgang (kode24). Det gjør shadow AI til et ledelsesspørsmål, ikke et teknisk vedlikeholdsspørsmål. Noen må bestemme hvilke kontoer som er lov, og den beslutningen må stå skriftlig.

Definisjonen du kan lime inn i policyen

Bruk en definisjon som er kort nok til å huskes: shadow AI er all bruk av AI-verktøy som skjer utenfor virksomhetens godkjente kontoer og avtaler. Den definisjonen dekker både gratiskontoen en selger bruker til tilbudsbrev, nettleserutvidelsen som oppsummerer møter, og skriptet en utvikler har koblet mot et API med sin egen nøkkel. Fellesnevneren er fraværet av avtale, logg og eierskap. Netwrix beskriver samme mekanisme: ikke-godkjente verktøy flytter sensitive data utenfor organisasjonens kontroll (netwrix.com, 2026).

Tre former shadow AI tar i praksis

Den første formen er personlige kontoer: ansatte logger inn med privat e-post fordi bedriften ikke har kjøpt lisens. Den andre er innebygde AI-funksjoner i verktøy dere allerede betaler for, som slås på uten at noen har vurdert hva de sender ut. Den tredje er egenbygde integrasjoner, der en nøkkel eller et sertifikat gir et AI-verktøy tilgang til systemer det aldri var ment å se. IT-sjefen i Ringerike kommune oppfordrer nettopp utviklere til å ha gode rutiner for API-nøkler og sertifikater som AI kan bli kjent med (kode24). De tre formene krever ulike tiltak, men samme policy.

Datatilsynet har mottatt 30 til 40 avviksmeldinger på ett år

Mellom sommeren 2025 og sommeren 2026 anslår Datatilsynet at det kom inn 30 til 40 avviksmeldinger om ukontrollert AI-bruk, noe tilsynet selv omtaler som en merkbar økning (kode24). Tallet er lite i absolutt forstand. Det interessante er retningen, og at meldingene handler om en kategori feil som knapt eksisterte for tre år siden.

Avviksmeldinger er dessuten et etterslepende mål. De teller tilfellene noen oppdaget, forsto og rapporterte. Bruken ingen oppdager, står ikke i statistikken.

Organisasjonen vet ikke hvordan AI brukes

Spesialrådgiver Eirik Gulbrandsen i Datatilsynet peker på kjernen: organisasjonen vet ikke hvordan AI faktisk brukes i virksomheten (kode24). Det er en presis beskrivelse av tilstanden i de fleste SMB-er vi møter. Ledelsen har en oppfatning av hvilke verktøy som brukes, basert på hva de selv bruker. Den oppfatningen stemmer nesten aldri med det som skjer i en salgsavdeling under press før kvartalsslutt.

Hva et avvik gjør med en liten bedrift

For en bedrift med noen titalls ansatte er ikke det verste et gebyr. Det verste er timene: å rekonstruere hva som ble limt inn, hvilke kunder det gjaldt, hvilken leverandør som mottok det, og hva leverandøren gjør med data i den kontotypen. Uten logg og uten oversikt over hvilke kontoer som er i bruk, blir den rekonstruksjonen gjetting. En policy er derfor først og fremst et etterforskningsverktøy: den definerer hva som skulle skjedd, slik at avviket lar seg beskrive.

Les også: Tolv AI-agenter per bedrift endrer CRM for norske SMB-er. Organisasjoner kjorer i snitt tolv AI-agenter, og adopsjonen ventes a oke 67 prosent pa to ar.

Ringerike kommune og de 300 fagsystemene ingen har full oversikt over

Ringerike kommune har rundt 32.000 innbyggere og 2.200 ansatte, og IT-sjef Torkjell Dahl beskriver innføringen av AI som en lang og tung prosess (kode24). Kommunen opplever at AI brukes ukontrollert, blant annet med personlige kontoer. Dette er ikke en organisasjon uten IT-kompetanse. Det er en organisasjon med mange oppgaver og mange systemer.

Over 300 fagsystemer og manglende innsikt

Kommunen har over 300 fagsystemer, og IT-avdelingen har ikke innsikt i alle tjenestene kommunen leverer (kode24). Det er tallet en leder bør ta med seg inn i sitt eget selskap. Antallet systemer i en SMB er mindre, men forholdet mellom det IT vet om og det som faktisk kjører, er ofte det samme. Kommunen har hatt noen AI-relaterte hendelser, men ingen svært alvorlige, og står etter IT-sjefens kjennskap ikke bak noen av avviksmeldingene til Datatilsynet det siste året.

Lørenskog-angrepet som varsel

Saken trekker også frem hackerangrepet mot Lørenskog kommune som et varsel om sårbarheten i Kommune-Norge (kode24). Poenget for en privat virksomhet er ikke at kommuner er spesielt utsatt. Poenget er at angrep treffer organisasjoner der oversikten er fragmentert, og at AI-verktøy med brede tilganger øker antall veier inn. Jo flere integrasjoner som er satt opp av enkeltpersoner, jo vanskeligere blir det å stenge dem ned raskt.

Rammeverk med tre kategorier: godkjent, betinget og forbudt

De fleste AI-policyer feiler fordi de prøver å beskrive hvert verktøy. Verktøyene skifter raskere enn dokumentet oppdateres. Et rammeverk med tre kategorier holder lenger, fordi kategoriene er stabile selv når navnene i dem byttes ut.

Kategori	Hva det betyr	Typiske eksempler	Krav for bruk
Godkjent	Virksomhetskonto med avtale og logg	Bedriftslisens på tekst- og kodeassistent	Innlogging med jobbkonto, ingen unntak
Betinget	Tillatt til avgrensede formål	Oversettelse, research, utkast til intern tekst	Ingen personopplysninger eller kundedata inn
Forbudt	Ikke tillatt uansett formål	Personlige kontoer, ukjente nettapper, nettleserutvidelser	Krever skriftlig godkjenning fra navngitt person

Godkjent: verktøyene dere har avtale på

Godkjent-kategorien skal være kort og konkret, med navn på verktøy og hvilken konto ansatte skal bruke. Kravet for å stå her er enkelt: virksomheten har en avtale, bruken skjer med jobbkonto, og noen kan i ettertid se hva som ble gjort. Valget mellom leverandører og modelltyper er en egen øvelse som handler om datalokasjon, pris og kvalitet, og som bør tas før policyen skrives (valg av språkmodell). Policyen skal peke på resultatet av det valget, ikke gjenta begrunnelsen.

Betinget: lov, men ikke med hva som helst

Betinget-kategorien er den viktigste og den som oftest mangler. Her ligger verktøy som er nyttige, men som ikke skal se kundedata: oppsummering av offentlig tilgjengelig materiale, språkvask av intern tekst, idemyldring. Regelen knyttes til datatypen, ikke til verktøyet. Da slipper dere å oppdatere dokumentet hver gang en leverandør lanserer en ny funksjon. En ansatt som forstår skillet mellom «dette er publisert» og «dette er kundens», tar riktig beslutning også i verktøy policyen aldri har hørt om.

Forbudt: personlige kontoer og sensitive data

Forbudt-kategorien bør være smal nok til å være troverdig. Personlige kontoer på jobb hører hjemme her, og det er nettopp denne bruken Datatilsynet advarer mot (kode24). Det samme gjelder nettleserutvidelser med lesetilgang til alt du har oppe, og opplasting av personopplysninger til tjenester uten avtale. Bare 31 prosent av virksomheter kan i dag fullt ut hindre at sensitive data sendes til eksterne AI-verktøy eller personlige kontoer (netwrix.com, 2026). For alle andre er regelen det eneste som virker.

AI-policyen som får plass på en side

Alura mener en AI-policy på en side som faktisk leses, slår et omfattende regelverk ingen åpner. Et dokument på tjue sider blir skrevet for revisor og lest av ingen. Et dokument på en side kan henges opp, sendes i onboarding og siteres i et møte. Målet er ikke fullstendighet. Målet er at en ny ansatt vet hva som er lov før lunsj den første dagen.

Punkt	Spørsmålet den ansatte trenger svar på
Formål	Hvorfor har vi regler i det hele tatt?
Godkjente verktøy	Hvilke kontoer kan jeg logge inn på?
Dataregler	Hva kan jeg lime inn, og hva kan jeg ikke?
Personlige kontoer	Kan jeg bruke min egen konto på jobb?
Kontroll av resultatet	Hva må jeg sjekke før jeg bruker svaret?
Avvik	Hvem varsler jeg hvis noe har gått galt?
Nye verktøy	Hvordan får jeg godkjent noe som ikke står på lista?

Skriv regler, ikke prinsipper

«Vi skal bruke AI ansvarlig og etisk» er ikke en regel. Det er en verdi, og den gir ingen ansatt hjelp klokka to på ettermiddagen med en kundekontrakt i den ene hånden. En regel ser slik ut: «Kundedata limes kun inn i verktøy du er logget inn på med jobbkontoen din.» Testen er om setningen kan brytes. Kan den ikke brytes, er den ikke en regel, og den hører hjemme i strategien i stedet for i policyen (AI-strategi).

Hvem eier dokumentet

Policyen trenger en navngitt eier, ikke en avdeling. I en SMB uten sikkerhetsavdeling er det som regel daglig leder eller den som allerede er personvernansvarlig. Eieren har tre oppgaver: godkjenne nye verktøy, ta imot avviksmeldinger internt, og gå gjennom dokumentet kvartalsvis. Uten eier blir policyen et vedlegg som aldri oppdateres, og som fungerer dårligere enn ingen policy fordi den gir falsk trygghet.

Gjør den til en del av onboarding

En policy som sendes ut en gang på e-post, har halveringstid på omtrent en uke. Legg den inn i onboarding, i lisensutdeling og i den halvtimen dere bruker på å vise nye ansatte de godkjente verktøyene. Da kobles regelen til handlingen. Folk følger regler de fikk demonstrert, ikke regler de fikk tilsendt.

Praktisk: dette gjør du første mandag morgen

Alura mener dere bør kartlegge hvilke AI-verktøy som allerede er i bruk før policyen skrives. Uten oversikt styrer dere i blinde, og dere risikerer å forby noe halve organisasjonen er avhengig av. Kartleggingen trenger ikke være et prosjekt. Den trenger en time, tre datakilder og vilje til å høre svaret.

Periode	Oppgave	Resultat
Første uke	Spør avdelingene, sjekk utleggsrefusjoner og innlogginger	Liste over verktøy som faktisk brukes
Andre uke	Sorter listen i godkjent, betinget og forbudt	Utkast til regler basert på virkeligheten
Tredje uke	Kjøp virksomhetslisens på det folk allerede bruker	Et godkjent alternativ finnes
Fjerde uke	Send ut policyen og hold en kort gjennomgang	Dokumentert og kjent regelverk

Kartlegg før du regulerer

Spør avdelingsvis, ikke i plenum, og gjør det tydelig at ingen får kjeft. Det du leter etter er verktøynavn, hva de brukes til og hvilken konto folk logger inn med. Suppler med utleggsrefusjoner på småbeløp og en gjennomgang av hvilke tredjepartsapper som har fått tilgang til e-post og fillager. Datatilsynets poeng, at organisasjonen ikke vet hvordan AI brukes, er nettopp det denne øvelsen fjerner (kode24).

Gi folk et godkjent alternativ

Alura mener rene forbud fungerer dårlig. Ansatte som ikke får et godkjent verktøy, tyr til personlige kontoer, og da er dere tilbake der dere startet, bare uten innsyn. Lisensen koster mindre enn den første granskingen etter et avvik. Kartleggingen forteller dere hvilke verktøy som faktisk gir verdi, og det er de dere skal kjøpe. Et forbud uten alternativ er en instruks om å skjule bruken bedre.

Markedstallene for 2026: bare 20 prosent styrer shadow AI fullt ut

Hvis du trenger tall til ledermøtet, er dette settet som gjør jobben. Bare 20 prosent av organisasjoner overvåker eller styrer ansattes bruk av shadow AI fullt ut (netwrix.com, 2026). Fire av fem har altså en delvis løsning eller ingen løsning. Det er ikke en unnskyldning, men det er en nyttig kalibrering: dere er ikke etter alle andre, dere er sammen med dem.

Måling	Andel
Overvåker eller styrer ansattes shadow AI fullt ut	20 %
Har full innsikt i hvilke sensitive data som går inn i AI-verktøy	21 %
Kan fullt ut hindre at sensitive data sendes til eksterne AI-verktøy	31 %
Kjører agentisk AI som henter data på vegne av mennesker	41 %
Styrer ikke ikke-menneskelige identiteter fullt ut	76 %
Vurderer seg som fullt klare for AI	11 %

Innsyn og sperrer mangler samtidig

Bare 21 prosent har full innsikt i hvilke sensitive data som flyter inn i AI-verktøy, modeller og kopiloter, og bare 31 prosent kan hindre at slike data sendes ut (netwrix.com, 2026). Kombinasjonen er det egentlige problemet. Den som verken ser hva som går ut eller kan stoppe det, har ingen kontroll å rapportere på. For en SMB er tiltaket her prosaisk: færre verktøy, tydeligere kontoer, og en regel om at kundedata bare håndteres i godkjent kategori.

Et lite mindretall regner seg som klare

Bare 11 prosent vurderer seg selv som fullt klare for AI, med håndhevede retningslinjer og kontinuerlig overvåking på plass, mens 58 prosent rapporterer at flere identiteter nå har tilgang til bedriftsdata (netwrix.com, 2026). Tilgangen vokser altså raskere enn styringen. Det er en tilstand som løser seg på en av to måter: enten strammer dere inn selv, eller så blir det strammet inn for dere etter en hendelse.

Les også: Shadow AI-innbrudd koster 4,63 millioner dollar i snitt. 40 prosent av virksomhetene har allerede hatt en AI-relatert personvernhendelse, og bare 43 prosent har en ...

Kostnaden: 670.000 dollar ekstra når shadow AI får løpe fritt

Datainnbrudd i virksomheter med høye nivåer av shadow AI koster 4,63 millioner dollar i snitt, og det er 670.000 dollar mer enn brudd i virksomheter med lite eller ingen shadow AI (netwrix.com, 2026). Merkostnaden er det interessante tallet, ikke totalen. Den isolerer hva mangelen på styring koster når uhellet først er ute, og det er nettopp den summen en policy skal redusere. Vi har sett nærmere på hvordan dette tallet er satt sammen i en egen gjennomgang av kostnaden ved shadow AI.

Situasjon	Tall
Snittkostnad ved datainnbrudd med høy grad av shadow AI	4,63 millioner dollar
Merkostnad mot brudd med lite eller ingen shadow AI	670.000 dollar
Bruddrate der AI økte antall identiteter med datatilgang betydelig	43 %
Bruddrate der AI ikke endret tilgangsmønstrene	11 %

43 prosent mot 11 prosent i bruddrate

Organisasjoner der AI betydelig økte antall identiteter med datatilgang, hadde en bruddrate på 43 prosent. Der AI ikke endret tilgangsmønstrene, var raten 11 prosent (netwrix.com, 2026). Det er nesten fire ganger forskjell, og variabelen er ikke hvor avansert AI-bruken er. Variabelen er hvor mange nye identiteter som fikk tilgang til data uten at noen holdt oversikt. Tilgangsvekst er risikodriveren, ikke AI i seg selv.

Hva tallene faktisk betyr for et norsk selskap

Snittkostnaden er hentet fra et internasjonalt materiale dominert av store virksomheter, og et norsk selskap med femti ansatte kommer ikke i nærheten av den summen. Bruk derfor tallene som forholdstall, ikke som prislapp. Forskjellen mellom de to bruddratene gjelder uansett størrelse, og det samme gjør mekanismen bak merkostnaden: ukjente verktøy gir lengre tid til å oppdage, dårligere grunnlag til å avgrense og mer arbeid med å varsle. Det er timene som skalerer ned til norsk størrelse, ikke millionene.

AI-agenter og tjenestekontoer: identitetene ingen følger med på

41 prosent av organisasjoner kjører allerede agentisk AI som henter data på vegne av mennesker, mens 76 prosent ikke fullt ut styrer eller overvåker ikke-menneskelige identiteter, inkludert AI-agenter og tjenestekontoer (netwrix.com, 2026). Gapet mellom de to tallene er der neste generasjon avvik oppstår. En agent jobber døgnet rundt, har ofte bredere tilgang enn personen den hjelper, og slutter aldri.

Datatilsynet advarer i samme retning: både AI-verktøy og AI-agenter kan få for mye tilgang (kode24). Utviklingen går raskt i salgs- og kundesystemer, der agenter nå utfører oppgaver på tvers av verktøy (AI-agenter i CRM).

Agenten er en identitet, ikke et verktøy

Alura mener AI-agenter og tjenestekontoer må håndteres som identiteter med tilgangsstyring, ikke som vanlige verktøy. Det betyr at en agent skal ha et navn, en menneskelig eier, en definert tilgang og en utløpsdato på nøklene sine, på samme måte som en ansatt har en rolle og en sluttdato. Behandler dere agenten som programvare, havner den utenfor tilgangsgjennomgangen. Behandler dere den som en identitet, kommer den automatisk med.

Et agentregister på fem kolonner

Felt i agentregisteret	Hvorfor det står der
Navn og formål	Gjør det mulig å vurdere om agenten fortsatt trengs
Menneskelig eier	Noen må svare når agenten gjør noe uventet
Systemer den har tilgang til	Viser spredningen hvis en nøkkel lekker
Nøkler og utløpsdato	Hindrer tilganger som lever evig
Logg	Uten logg finnes ingen etterforskning

Registeret trenger ikke være et system. Et regneark holder så lenge noen eier det og går gjennom det kvartalsvis. Det viktigste er at ingen agent settes i drift uten en linje i arket, og at linjen fjernes når agenten slås av.

Reguleringen henter ikke inn forspranget

Agentene er i bruk før regelverket har rukket å definere dem, og det gapet må dekkes internt inntil videre (personlige AI-agenter). For en SMB betyr det at interne regler er det eneste som gjelder akkurat nå. Den som venter på at regelverket skal si hva en agent er, driver i mellomtiden uten styring.

Markedsobs: dette advarer sikkerhetsmiljøet om nå

På Sikkerhetsfestivalen i Lillehammer samlet 90 norske sikkerhetsledere, eksperter, rådgivere og toppledere seg om det de bekymrer seg mest for: AI og tredjepartsrisiko (kode24). Det er et nyttig signal for en leder som skal prioritere. Bekymringen handler ikke om at AI skal ta over. Den handler om leddene rundt AI-bruken: leverandører, tilganger og folk med nøkler.

Utviklerne er det nye målet, ifølge Tanya Janca

Sikkerhetsekspert Tanya Janca, med 29 års erfaring innen teknologi, sikkerhet og utvikling, mener det nå er programvareutviklerne som trenger beskyttelse, i motsetning til tidligere da ledere og systemadministratorer var hovedmålet (kode24). Hun er bekymret for at en enkelt kompromittert utvikler åpner flere deler av leveransekjeden samtidig. Konklusjonen hennes er upopulær og tydelig: utviklere må begrenses, og de trenger trening i trygg AI-bruk. Janca listet også opp ti usikre utviklervaner under festivalen.

Tre tips: hemmeligheter, tilgang og input

Jancas tre råd er enkle nok til å stå i en policy: ikke lekk hemmeligheter, sørg for autentisering og autorisering, og valider all input (kode24). Hun er samtidig bekymret for at AI brukes mer og mer, men ikke klokt, og frykter at folk ikke sjekker at resultatet er trygt før det settes i produksjon. Kontroll av AI-generert kode er et policypunkt, ikke en smakssak. Janca oppfordrer for øvrig til å bruke AI til å granske egen kode.

Fra dommedagsdebatt til tirsdagsrutiner

Den offentlige AI-debatten trekker samtidig mot det eksistensielle. Professor Yoshua Bengio sammenligner AI med kjernefysiske våpen og frykter modeller som kan hacke seg inn i selskaper over hele verden, mens professor Emily M. Bender beskylder AI-selskapene for å bruke katastrofescenarioer til å avlede oppmerksomheten fra reelle problemer (Digi.no). Norske eksperter avviser en dystopisk Terminator-framtid, men advarer mot autonome systemer ute av kontroll (Digi.no, 2026).

Kristin Skogen Lund mener ingen politikere klarer å henge med på utviklingen og kaller den veldig uoversiktlig, mens teknologisjef Arne Rinnan i Kongsberg Gruppen sier han ikke er bekymret for AI-dommedag, men at utviklingen må følges nøye (E24). På politisk nivå tas det til orde for internasjonalt AI-sikkerhetssamarbeid etter modell av Ikke-spredningsavtalen fra 1968 (Digi.no). Ingen av disse debattene hjelper deg på tirsdag. Det som hjelper, er å vite hvilke kontoer de ansatte dine logger inn med.

Vanlige feil norske SMB-er gjør når de lager AI-regler

Feilene går igjen, og de er sjelden tekniske. De handler om rekkefølge, presisjonsnivå og hvem som eier dokumentet etterpå. Her er de tre som koster mest.

Forbud uten godkjent alternativ

Den vanligste feilen er å stenge alt og kalle det kontroll. Resultatet er at bruken flytter til private kontoer og private enheter, der dere verken ser den eller kan dokumentere den. Da har dere byttet en synlig risiko mot en usynlig. Datatilsynet advarer nettopp mot personlige AI-kontoer på jobb (kode24), og et forbud uten lisens i andre enden er den sikreste måten å produsere dem på.

Policy skrevet før kartleggingen

Den nest vanligste feilen er å skrive reglene i et møterom, uten å vite hva folk faktisk bruker. Da regulerer dere verktøyene ledelsen kjenner til, og ikke de som håndterer kundedata i praksis. Ringerike kommunes erfaring, over 300 fagsystemer og manglende innsikt i alle tjenestene, er den samme dynamikken i større skala (kode24). Kartleggingen er ikke forarbeid til policyen. Den er halve policyen.

Regler for verktøy i stedet for data

Den tredje feilen er lister over godkjente verktøynavn uten et eneste ord om hvilke data som kan gå inn i dem. Listen er utdatert innen et kvartal, og den gir ingen veiledning når en ansatt møter noe nytt. Skriv reglene om datatyper først, og la verktøylisten være et vedlegg som oppdateres uten at hoveddokumentet må revideres. En fjerde variant av samme feil er å glemme agentene helt, selv om tre av fire virksomheter allerede mangler styring på ikke-menneskelige identiteter (netwrix.com, 2026).

Spørsmål og svar om shadow AI, personvern og avviksmeldinger

Spørsmålene under er de vi får oftest fra ledere som skal skrive sin første AI-policy.

Må vi melde avvik hvis en ansatt limte kundedata inn i et AI-verktøy?

Vurderingen gjøres i hvert enkelt tilfelle, og den bør gjøres av den som eier personvernansvaret hos dere. Det vi vet, er at slike saker faktisk meldes: Datatilsynet anslår 30 til 40 avviksmeldinger om ukontrollert AI-bruk mellom sommeren 2025 og sommeren 2026 (kode24). Forberedelsen er viktigere enn vurderingen: uten logg over hvilke kontoer som brukes, klarer dere ikke å beskrive hva som skjedde.

Kan vi bare forby AI-verktøy helt?

Dere kan, men det holder sjelden. Erfaringen vår er at forbud uten et godkjent alternativ flytter bruken til personlige kontoer, og det er den kategorien Datatilsynet advarer mot. Et smalt og godt begrunnet forbud på de mest sensitive datatypene virker bedre enn et bredt forbud alle omgår.

Hvem bør eie AI-policyen i en bedrift uten sikkerhetsavdeling?

En navngitt person i ledelsen, gjerne den som allerede håndterer personvern. Eierskapet handler om tre konkrete oppgaver: godkjenne nye verktøy, ta imot interne varsler og oppdatere dokumentet kvartalsvis. Legger dere det på «IT» som avdeling, blir det ingens jobb den uken det haster.

Hvor ofte må policyen oppdateres?

Kvartalsvis er en fornuftig rytme, og gjennomgangen tar en halvtime hvis verktøylisten ligger som vedlegg. Se samtidig over agentregisteret. Med 41 prosent av organisasjoner som allerede kjører agentisk AI mot egne data (netwrix.com, 2026), er det her endringene kommer raskest.

Hva med utviklerne våre, som bruker AI i koden?

De trenger egne punkter. Tanya Janca mener utviklere er blitt et mål for ondsinnede aktører, og at de derfor må begrenses og trenes i trygg AI-bruk (kode24). Konkret handler det om rutiner for API-nøkler og sertifikater som AI-verktøy kan få kjennskap til, og om at AI-generert kode kontrolleres før produksjon. Ingen hemmeligheter i prompten er regelen som er lettest å huske.

Oppsummering: fra ukontrollert bruk til dokumentert kontroll

Shadow AI er ikke et tegn på illojale ansatte. Det er et tegn på at verktøyene ble gode før virksomheten rakk å bestemme seg. Tallene sier det samme fra to kanter: bare en av fem virksomheter styrer ansattes shadow AI fullt ut, og bruddraten er nesten fire ganger høyere der AI har økt antall identiteter med datatilgang (netwrix.com, 2026). Kontrollen finnes altså ikke som standardtilstand. Den må skrives ned.

Dette gjør du denne uken

Kartlegg hva som faktisk brukes, sorter det i godkjent, betinget og forbudt, kjøp lisens på det folk er avhengige av, og skriv policyen på en side med en navngitt eier. Legg agentene i et eget register med menneskelig eier og utløpsdato på nøklene. Fire skritt, fire uker, og dere har gått fra antakelse til oversikt.

Dette måler du om tre måneder

Tre spørsmål avgjør om policyen virker. Vet dere hvilke AI-verktøy som er i bruk, uten å måtte spørre? Finnes det en godkjent lisens for hver oppgave folk faktisk løser med AI? Kan dere navngi eieren av hver agent som har tilgang til bedriftsdata? Tre ja betyr at dere er i det mindretallet som har dokumentert kontroll. Ett nei forteller nøyaktig hvor neste avvik kommer fra.

I Alura kombinerer vi teknisk AI-kompetanse med praktisk forståelse for GDPR, EU AI Act og Datatilsynets forventninger. Vi hjelper norske virksomheter å bygge AI som tåler en revisjon, uten å bremse innovasjonen.

Bestill en compliance-vurdering: vi kartlegger dine AI-systemer mot gjeldende og kommende krav, og leverer en handlingsplan som faktisk er gjennomførbar. Uforpliktende.

Kilder

netwrix.com. 12 Shadow AI security risks to monitor in 2026
kode24. Datatilsynet advarer mot personlige KI-kontoer på jobb
kode24. Datatilsynet advarer mot ukontrollert KI-bruk i norske kommuner
Digi.no. KI-forskere advarer: – KI er som kjernefysiske våpen
Digi.no. Norske KI-eksperter: Ikke Terminator-frykt, men autonome systemer ute av kontroll
E24. Norske næringslivsledere advarer om AI-utviklingen: – Klart bekymringsfullt
Digi.no. Norge bør ta initiativ til å stoppe ondsinnet KI