Kun 29% af sikkerhedsteams kan regelmæssigt rapportere om følsomme data, som medarbejdere sender til AI-værktøjer

Denne artikel bygger på resultater fra Cloud Security Alliance’s (CSA) undersøgelsesrapport fra 2026, DLP i AI-æraen, som Jazz bestilte.

I juni og juli spurgte CSA 433 it- og sikkerhedsprofessionelle, om deres team kunne udarbejde en rapport, der viste, hvor mange gange følsomme data var blevet sendt til værktøjer med generativ AI i løbet af de seneste 30 dage. 29 procent svarede, at de regelmæssigt kunne udarbejde en sådan rapport.

Tallet ville være mindre betydningsfuldt, hvis respondenterne betragtede generativ AI som en mindre vigtig kanal. De rangerede den som den største risiko for dataeksfiltration, og 48 % placerede den blandt deres tre største risici.

Jeg leder ingeniørarbejdet i en virksomhed, der udvikler løsninger til forebyggelse af datatab, og størstedelen af mit arbejde handler om, hvor i et system der opstår spor af dataflytning, og hvorfor den tilhørende risiko opstår. Set fra den vinkel følger forskellen mellem det, teams mener, de kan se, og det, de kan dokumentere, direkte af den måde, kontrollerne for generativ AI blev designet på.

Tilliden til overblikket over generativ AI ligger langt over det, teams kan dokumentere

Lidt over halvdelen af respondenterne vurderede deres overblik over generativ AI til 4 eller 5 ud af 5. Alligevel kunne kun 29 % regelmæssigt underbygge den vurdering med en rapport, der blot tæller, hvor mange gange følsomme data blev sendt til et AI-værktøj.

Kilde: Cloud Security Alliance, DLP i AI-æraen (2026), n=433. Gengivet ud fra rapportens diagrammer på s. 22 og 23.

Håndhævelsen følger samme mønster. Kun 22 % af respondenterne blokerer følsomme data konsekvent via kanalen for generativ AI. Flytbare medier, som respondenterne rangerede som den mindst risikofyldte kanal for dataeksfiltration, har den højeste andel af konsekvent blokering med 31 %. Konsekvent blokering ses især på de kanaler, hvor værktøjerne er ældst.

Kilde: Cloud Security Alliance, DLP i AI-æraen (2026), n=433. Gengivet ud fra rapportens diagrammer på s. 23 og 26; søjlerne er skaleret til 100 %, hvor afrunding havde placeret en række på 99 % eller 101 %.

Jazz offentliggjorde også telemetridata fra sine kundemiljøer sammen med undersøgelsen. Den gennemsnitlige organisation i disse data havde 169,5 forskellige AI-værktøjer i brug, hvoraf 9,8 var godkendt. Det efterlod 94,2 % uden for listen over godkendte værktøjer.

Hvorfor forskellen opstår: En liste over værktøjer registrerer ingen hændelser

Den sædvanlige reaktion på risikoen ved generativ AI er at godkende en håndfuld AI-tjenester gennem virksomhedsaftaler og fraråde eller blokere resten. Tallet på 94,2 % viser, hvor langt den liste i praksis er bagefter. En ingeniør med en deadline bruger det værktøj, der løser dagens problem, fordi det tager flere uger at få indkøbt det godkendte værktøj.

Selv en komplet liste ville ikke kunne levere den rapport, CSA spurgte om. Dit hændelsesteam eller en revisor vil spørge til en konkret hændelse, hvor data forlod organisationen, og en liste over værktøjer indeholder ingen hændelser.

For at vise, hvad der skete ved den hændelse, skal du kende fire ting: hvilke følsomme data der var involveret, hvilket værktøj der modtog dem, hvilken konto de blev sendt via, og hvorfor personen sendte dem.

Det er på kontoniveau, at styringen af værktøjer først bryder sammen. Det samme websted bruges både til virksomhedens erhvervskonto med dens indstillinger for opbevaring og aftalevilkår og til en medarbejders gratis personlige konto, som ikke har nogen af delene. Et godkendt værktøj, der bruges via et personligt login, giver omtrent lige så lidt dokumentation som et ikke-godkendt værktøj.

Formålet er sværere at fastslå, og det afgør, om noget gik galt. En finansanalytiker, der indsætter en omsætningsmodel i en chatbot for at rette en formel, der ikke virker, passer sit arbejde. Den samme handling fra en person, der afleverede sin opsigelse fredag, kræver en helt anden samtale. Forskellen mellem dem ligger i konteksten omkring personen, som aldrig fremgår af selve dataindholdet.

De kontroller, der bruges, ser hver især kun ét sted

Undersøgelsen fandt ingen dominerende tilgang til at kontrollere følsomme data, der sendes til AI-værktøjer. Blokering af AI-domæner på netværksniveau, indholdskontrol i browseren og politikker for acceptabel brug alene fik hver især mellem 21 % og 23 %, mens virksomheders AI-platforme med indbygget DLP fik 10 %.

Hver af disse kontroller er designet omkring ét enkelt kontrolpunkt. En domæneblokering tillader eller stopper en forbindelse og registrerer, hvilket websted forbindelsen gik til. En browserudvidelse kan se, hvad der skrives i den pågældende browser, men overser alt, der sendes fra en computerapp, en kodeassistent i et kodeprogram eller et kommandolinjeværktøj. En virksomheds-AI-platforms indbyggede DLP kan se, hvad der sendes ind på platformen. Alle disse løsninger vælger ét sted at holde øje med og håber, at det er dér, dataene sendes hen.

Det ene kontrolpunkt forklarer også tallene for håndhævelse. Hvis en kontrol ikke kan skelne mellem en virksomhedskonto og en personlig konto eller mellem en rutinemæssig indsættelse og en risikabel en, er den nødt til at blokere begge dele eller ingen af dem. Konsekvent blokering standser dermed også legitimt arbejde sammen med den risikable aktivitet. På spørgsmålet om den vigtigste grund til, at de ikke har indført mere aktiv blokering, svarede 46 % af respondenterne, at de frygtede at forstyrre arbejdsgangene, mens 39 % henviste til utilstrækkelig tillid til DLP’s nøjagtighed.

Forbehold, der er værd at have in mente

Undersøgelsens tal er selvrapporterede, og undersøgelsen sammenholdt ikke vurderingerne af synligheden med den faktiske dækning. Respondenterne kom især fra Amerika (80 %) og fra organisationer med færre end 5.000 medarbejdere (67 %), så resultaterne gælder muligvis ikke på samme måde for store globale virksomheder. Telemetridataene stammer fra organisationer, der selv valgte at indføre denne type synlighed, hvilket kan betyde, at de i højere grad allerede var bekymrede over den ukontrollerede udbredelse af AI.

Godkendte værktøjer og agenter vil gøre listen endnu mindre retvisende

Når godkendte SaaS-produkter tilføjer AI-assistenter, er der ofte to svar på spørgsmålet om, hvilket værktøj der modtog dataene: den applikation, medarbejderen åbnede, og udbyderen af AI-modellen bag den. AI-agenter gør det endnu mere kompliceret. Når en agent henter en fil og sender den et sted hen på en medarbejders vegne, ligger ansvaret for hvem og hvorfor nu delvist hos softwaren. Som en nylig artikel fra Unite.AI om promptinjektion i agenter i produktion påpeger, kan en agent påvirkes af det indhold, den læser, så dens egen redegørelse for, hvad den gjorde, ikke kan træde i stedet for dokumentation for formålet.

En test, du kan gennemføre denne måned

Se på de seneste 30 dage, og vælg det mest følsomme dataelement, som du mener er nået frem til et AI-værktøj. Undersøg derefter, om dit team kan fremlægge følgende uden at skulle udarbejde det manuelt:

• Hvad dataene bestod af, og hvor de kom fra
• Hvilket værktøj der modtog dem, herunder værktøjer uden for jeres godkendte liste
• Om dataene blev sendt via en firmakonto eller en personlig konto
• Hvad personen arbejdede på, da vedkommende sendte dem

Hvis de to første spørgsmål hurtigt kan besvares, mens de to sidste kræver, at medarbejderen bliver interviewet, omfatter jeres styring værktøjslisten, men meget lidt af jeres data.