Skuggjungeln för AI: Varför godkännande av en plattform inte är samma sak som att säkra vad som byggs på den

Företagsanvändning av AI är långt ifrån friktionsfri. Bekymmer om datakontroll, regelefterlevnad och säkerhet har följt varje skede av resan. Men när organisationer ökar sin verksamhet på stora plattformar som Microsoft, Salesforce och ServiceNow, finns en växande känsla av att de svåraste styrningsfrågorna, åtminstone delvis, hanteras. Företagsavtal är på plats. Säkerhetsgranskningar har slutförts. Plattformarna är godkända.

Vad den här tillförseln tenderar att förbise är en annan fråga helt och hållet: inte om plattformen är säker, utan vad och vem som bygger.

Över branscher sker en tyst revolution när icke-tekniska anställda använder företags-AI-plattformar för att skapa autonoma agenter, automatiserade arbetsflöden och dataanslutna applikationer, ofta på några minuter, utan att skriva en enda rad kod. Fri från de traditionella utvecklingstiderna och begränsningarna, är dessa byggare en välsignelse för organisatorisk effektivitet. Men dessa verktyg granskas aldrig av ett säkerhetsteam. I många fall vet säkerhetsteamen inte ens att de existerar.

Dessa verktyg, oavsett om de klassificeras som appar, agenter eller automatiseringar, är en del av ett växande problem som kallas Skugg-AI, och det representerar en av de mest betydande förändringarna i företagsrisk under ett decennium, av den enkla anledningen att hoten nu har flyttat inåt.

Det ursprungliga Skugg-IT-problemet var relativt enkelt: anställda använde obehöriga verktyg från utanför organisationen, och säkerhetsarbetet var att hitta och blockera dem. Skugg-AI är en annan utmaning helt och hållet. Verktygen finns inom de plattformar du godkänt. De som bygger dem är dina egna anställda. Åtkomsten de använder är legitim. Och ingen av det passerar genom säkerhetsprocesserna som är utformade för att upptäcka problem innan de når produktion.

Vad som gör detta särskilt svårt att hantera är skalan. De flesta säkerhetsledare underskattar betydligt hur mycket som byggs inom deras egna miljöer. Nylig forskning från över 200 företags-CISO:er och säkerhetsledare fann att den genomsnittliga företagssäkerhetsteamet kan redovisa endast 44% av de AI-agenter, automatiseringar och applikationer som deras affärsanvändare har skapat. Det är inte ett gap. Det är en blind fläck som täcker den stora majoriteten av vad som körs.

Anledningen är enkel: affärsanvändare överträffar nu professionella utvecklare med så mycket som 10 till 1 i vissa organisationer. De bygger konstant över alla avdelningar, på plattformar som var utformade för att göra byggandet enkelt, och sedan uppmuntras av C-sviten att bygga. Säkerhetsteam är inriktade på utvecklarledningar och kodarkiv. De var aldrig utformade för att övervaka detta.

Den vanligaste missuppfattningen är tron att godkännande av en plattform löser säkerhetsproblemet. Det gör det inte, det flyttar det bara. När ett företag undertecknar ett avtal med Microsoft, Salesforce eller UiPath, säkrar plattformsleverantören sin infrastruktur. Vad anställda bygger ovanpå det, och hur de konfigurerar det, är företagets ansvar helt och hållet.

Problemet är att de verktyg som affärsanvändare skapar inte ser ut som programvara för traditionella säkerhetssystem. Det finns ingen kod att skanna, inget arkiv att övervaka, ingen pipeline att inspektera. En AI-agent byggd av en HR-chef genom en serie menyer och textpromptar är, ur perspektivet på de flesta säkerhetsverktyg, osynlig.

Och ändå är dessa verktyg långt ifrån triviala. Forskning har visat att mer än hälften av CISO:erna bekräftade att affärsbyggda applikationer nu stöder affärskritiska processer och har åtkomst till känsliga företagsdata. Insatserna är verkliga, och övervakningen har inte hunnit med.

Från noll till katastrof

Användningsfallen är lika varierade som de är talrika och kommer från praktiskt taget alla avdelningar, även de som aldrig skulle ha förekommit för ett säkerhetsteam att hålla ett öga på.

Till exempel bygger en marknadskoordinator en kundorienterad AI-agent på en fullt sanktionerad plattform för att besvara produktspecifika frågor. På några minuter är appen igång, men som någon med ingen säkerhetsutbildning, går två små konfigurationsfel obemärkt förbi och lämnar agenten med direktåtkomst till företagets hela databas och inga gränser för vad den kan hämta. I produktionen ber en användare det att hämta anställdas register. Det gör det. Eftersom agenten också har en e-postfunktion, instruerar användaren det att skicka den data till en personlig adress. Hela sekvensen tar under sextio sekunder. Inga obehöriga åtkomster. Inga plattformsbrott. Inga säkerhetsvarningar.

Detta är inte en sofistikerad attack. Det är det förutsägbara resultatet av en välmenande anställd som bygger något de inte fullständigt förstår, på en plattform som gjorde byggandet enkelt och styrning valfritt.

Styrningsgapet som ingen har prissatt in

För de flesta organisationer förblir Skugg-AI-problemet abstrakt tills något går fel. Men affärsrisken går djupare än brottsrespons.

När en affärsbyggd agent läcker känslig data, är frågan som en styrelse kommer att ställa inte “hur blev konfigurationsfelet till?” Det kommer att vara “hur visste ingen att verktyget kördes?” De kommer inte att skilja mellan ett brott orsakat av en extern angripare och ett orsakat av ett misskonfigurerat internt verktyg. Om personuppgifter avslöjades och organisationen saknade insyn i vad som kördes, är avsaknaden av övervakning i sig själv ansvar. “En anställd byggde det på en godkänd plattform” är inte ett försvar, det är beskrivningen av gapet.

Brådskan är verklig, men avsikt och genomförande är inte samma sak, och för de flesta företagen förblir gapet mellan dem öppet.

Svaret är inte att begränsa vem som kan bygga. Att låsa fast medborgarutveckling skulle offra äkta produktivitetsvinster och skulle i praktiken inte hållas. Anställda skulle hitta alternativ. Svaret är att bringa vad som byggs inom synhåll och att styra det vid den punkt där risken faktiskt uppstår: körning.

Det betyder att förstå inte bara vilka agenter som existerar, utan hur de beter sig, vilken data de har åtkomst till, vilka system de berör och om deras handlingar stannar inom de gränser deras byggare avsåg. Det betyder att ställa upp räcken som fungerar på organisationsnivå, inte bara vid konfigurationspunkten. Och det betyder att komma till en punkt där säkerhetsteam kan besvara de mest grundläggande frågorna om varje agent i deras miljö: vem byggde det, vad har det åtkomst till och beter det sig som det var tänkt att?

De flesta företag kan inte besvara dessa frågor idag. De organisationer som kommer dit först kommer att vara de som kan skala AI-användning med tillförsikt, eftersom de kommer att veta vad de faktiskt kör.