Skuggan AI-djungeln: Varför godkännande av en plattform inte är detsamma 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 skalar upp sina verksamheter 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 branscherna pågår 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å bara 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öretagsrisker på ett decennium, just för 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 dem 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 det genomsnittliga företagssäkerhetsteamet kan stå för 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 numera överträffar 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å utvecklarpipeliner och kodrepository. 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 (MSFT ), Salesforce (CRM ) eller UiPath (PATH ), 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, ingen repository 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 tillsynen 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 svara på produktspecifika frågor. På bara 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ällningsrekord. 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 valfri.

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 löper djupare än brottssvar.

När en affärsbyggd agent läcker känslig data, är frågan en styrelse kommer att ställa inte “hur blev konfigurationsfelet till?” utan “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 bristen på tillsyn 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 ned medborgarutveckling skulle offra verkliga produktivitetsvinster och, i praktiken, inte skulle hålla. Anställda skulle hitta alternativa lösningar. 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 kommer åt, vilka system de berör och om deras åtgärder förblir inom de gränser deras byggare avsåg. Det betyder att sätta upp räcken som fungerar på organisationsnivå, inte bara vid konfigurationspunkten. Och det betyder att komma till en plats där säkerhetsteam kan svara på 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 göra?

De flesta företag kan inte svara på 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.