Bare 29% av sikkerhetsteamene kan rutinemessig rapportere om sensitive data som ansatte sender til KI-verktøy

Denne artikkelen bygger på funn fra Cloud Security Alliance’s (CSA) undersøkelsesrapport fra 2026, DLP i KI-æraen, som Jazz bestilte.

I juni og juli spurte CSA 433 IT- og sikkerhetseksperter om teamet deres kunne lage en rapport som viser hvor mange ganger sensitive data ble sendt til generative KI-verktøy i løpet av de siste 30 dagene. 29 prosent svarte at de kunne lage en slik rapport rutinemessig.

Dette tallet ville vært mindre viktig hvis respondentene betraktet generativ KI som en mindre viktig kanal. De rangerte den som den største risikoen for dataeksfiltrasjon, og 48 % plasserte den blant de tre største risikoene.

Jeg leder ingeniørarbeidet i et selskap som utvikler løsninger for å forhindre datatap, og mye av arbeidet mitt handler om hvor i et system sporene etter dataoverføring finnes, og hvorfor risikoen oppstår. Fra dette perspektivet følger gapet mellom det teamene tror de kan se, og det de kan dokumentere, direkte av hvordan kontrollene for generativ KI ble utformet.

Tiltroen til innsyn i generativ KI ligger langt foran det teamene kan dokumentere

Litt over halvparten av respondentene vurderte innsynet deres i generativ KI til 4 eller 5 av 5. Likevel kunne bare 29 % rutinemessig underbygge vurderingen med en rapport som ganske enkelt teller hvor mange ganger sensitive data ble sendt til et KI-verktøy.

Kilde: Cloud Security Alliance, DLP in the AI Era (2026), n=433. Gjenskapt fra figurene på s. 22 og 23 i rapporten.

Håndhevingen følger samme mønster. Bare 22 % av respondentene blokkerer sensitiv informasjon fullstendig på kanalen for generativ KI. Flyttbare medier, som respondentene rangerte som den laveste risikoen for dataeksfiltrasjon, har den høyeste andelen fullstendig blokkering, på 31 %. Fullstendig blokkering er mest utbredt på kanalene med den eldste teknologien.

Kilde: Cloud Security Alliance, DLP in the AI Era (2026), n=433. Gjenskapt fra figurene på s. 23 og 26 i rapporten; stolpene er skalert til 100 % der avrunding ga 99 % eller 101 % for en rad.

Jazz publiserte også telemetridata fra kundenes miljøer sammen med undersøkelsen. I gjennomsnitt var 169,5 ulike KI-verktøy i bruk i organisasjonene i dette datamaterialet. Av disse var 9,8 godkjent, noe som betyr at 94,2 % ikke sto på listen over godkjente verktøy.

Hvorfor gapet oppstår: En verktøyliste registrerer ingen hendelser

Standardreaksjonen på risikoen ved generativ KI er å godkjenne en håndfull KI-tjenester gjennom virksomhetsavtaler og fraråde eller blokkere resten. Tallet 94,2 % viser hvor langt denne listen i praksis henger etter. En ingeniør med en tidsfrist bruker det verktøyet som løser dagens problem, fordi det tar flere uker å kjøpe inn det godkjente verktøyet.

Selv en fullstendig liste ville ikke gitt rapporten CSA etterspurte. Hendelsesteamet eller en revisor vil spørre om en konkret hendelse der data forlot virksomheten, og en liste over verktøy inneholder ingen hendelser.

For å vise hva som skjedde i den hendelsen, trenger du fire opplysninger: hvilke sensitive data det gjaldt, hvilket verktøy som mottok dem, hvilken konto som ble brukt, og hvorfor personen sendte dem.

Det er på kontonivå at styringen av verktøy først svikter. Det samme nettstedet brukes både til virksomhetens bedriftskonto, med innstillinger for oppbevaring og avtalebetingelser, og til en ansatts gratis personlige konto, som ikke har noen av delene. Et godkjent verktøy brukt med en personlig innlogging gir omtrent like lite dokumentasjon som et verktøy som ikke er godkjent.

Det er vanskeligere å fastslå formålet, men det avgjør om noe gikk galt. En finansanalytiker som limer inn en inntektsmodell i en chatbot for å rette en feil i en formel, gjør jobben sin. Den samme handlingen fra en person som leverte oppsigelsen sin på fredag, bør føre til en helt annen samtale. Forskjellen ligger i konteksten rundt personen, som aldri vises i datainnholdet.

Kontrollene som brukes, ser hver sin del

Undersøkelsen fant ingen dominerende metode for å kontrollere sensitive data som sendes til KI-verktøy. Nettverksbasert blokkering av KI-domener, innholdskontroll i nettleseren og retningslinjer for akseptabel bruk alene fikk hver mellom 21 % og 23 %, mens KI-plattformer for virksomheter med innebygd DLP fikk 10 %.

Hver av disse kontrollene er utformet for ett enkelt kontrollpunkt. En domeneblokkering tillater eller stanser en tilkobling og registrerer hvilket nettsted den gikk til. En nettleserutvidelse ser hva som skrives inn i nettleseren, men fanger ikke opp noe som sendes fra en skrivebordsapp, en kodeassistent i et kodeverktøy eller et kommandolinjeverktøy. Innebygd DLP i en KI-plattform for virksomheter ser hva som sendes inn i den plattformen. Hver av disse løsningene velger ett sted å se etter data og håper at det er der dataene går.

Det ene kontrollpunktet forklarer også tallene for håndheving. Hvis en kontroll ikke kan skille mellom en bedriftskonto og en personlig konto, eller mellom en rutinemessig innliming og en risikabel en, må den blokkere begge eller ingen av dem. Fullstendig blokkering stanser dermed legitimt arbeid sammen med den risikable typen aktivitet. På spørsmål om hovedgrunnen til at de ikke hadde gått over til mer aktiv blokkering, svarte 46 % av respondentene at de fryktet å forstyrre arbeidsflytene i virksomheten, mens 39 % oppga manglende tillit til nøyaktigheten i DLP.

Forbehold det er verdt å ha i mente

Undersøkelsestallene er selvrapporterte, og undersøkelsen sammenlignet ikke vurderingene av synligheten med den faktiske dekningen. Respondentene er i stor grad fra Amerika (80 %) og fra organisasjoner med færre enn 5 000 ansatte (67 %), så resultatene gjelder kanskje ikke like godt for store globale virksomheter. Telemetridataene kommer fra organisasjoner som selv valgte å ta i bruk denne typen synlighet, noe som kan føre til en overvekt av organisasjoner som allerede er bekymret for ukontrollert spredning av KI-bruk.

Godkjente verktøy og agenter vil gjøre listen enda mindre pålitelig

Når godkjente SaaS-produkter legger til KI-assistenter, har spørsmålet om hvilket verktøy som mottok dataene ofte to svar: applikasjonen den ansatte åpnet, og KI-modellleverandøren bak den. KI-agenter gjør dette enda mer komplisert. Når en agent henter en fil og sender den et sted på vegne av en ansatt, ligger ansvaret for hvem som gjorde det, og hvorfor, nå delvis hos programvaren. Som det hevdes i en nylig Unite.AI-artikkel om prompt-injeksjon i agenter i produksjon, kan en agent styres av innholdet den leser. Derfor kan ikke agentens egen beskrivelse av hva den gjorde, stå som bevis på hensikten.

En test du kan gjennomføre denne måneden

Ta utgangspunkt i de siste 30 dagene, og velg det mest sensitive dataelementet du mener ble sendt til et KI-verktøy. Sjekk deretter om teamet ditt kan finne fram følgende uten å sette det sammen manuelt:

• Hva dataene besto av, og hvor de kom fra
• Hvilket verktøy som mottok dem, også verktøy som ikke står på listen over godkjente verktøy
• Om de ble sendt via en bedriftskonto eller en personlig konto
• Hva personen arbeidet med da vedkommende sendte dem

Hvis dere raskt finner svar på de to første spørsmålene, men må intervjue den ansatte for å få svar på de to siste, omfatter styringen deres verktøylisten, men svært lite av dataene.