Skogjungelen av skygge-AI: Hvorfor godkjenning av en plattform ikke er det samme som å sikre hva som bygges på den

Virksomhetsadopsjon av AI er langt ifra friksjonsløs. Bekymringer om datakontroll, regulatorisk overholdelse og sikkerhet har fulgt hver fase av reisen. Men når organisasjoner øker operasjonene sine på store plattformer som Microsoft, Salesforce og ServiceNow, er det en økende følelse av at de hardeste styreproblemer er, i det minste delvis, blitt løst. Virksomhetsavtaler er på plass. Sikkerhetsgjennomgangene er fullført. Plattformene er godkjent.

Hva denne tilliten tenderer å overse er en annen spørsmål helt og holdent: ikke om plattformen er sikker, men hva, og hvem, bygger.

Over hele bransjen skjer en stille revolusjon når ikke-tekniske ansatte bruker virksomhets-AI-plattformer til å lage autonome agenter, automatiserte arbeidsflyter og datakoblede applikasjoner, ofte på bare minutter, uten å skrive en enkelt linje med kode. Frie fra de tradisjonelle utviklingstidslinjene og begrensningene, er disse byggerne en velsignelse for organisatorisk effisiens. Men disse verktøyene blir aldri gjennomgått av et sikkerhetsteam. I mange tilfeller vet sikkerhetsteamene ikke engang at de eksisterer.

Disse verktøyene, enten de klassifiseres som apper, agenter eller automatiseringer, er en del av et voksende problem kjent som Skygge-AI, og det representerer en av de mest betydelige endringene i virksomhetsrisiko på ett tiår, fordi truslene nå har flyttet innover.

Det opprinnelige Skygge-IT-problemet var relativt enkelt: ansatte brukte uautoriserte verktøy fra utenfor organisasjonen, og sikkerhetsjobben var å finne og blokkere dem. Skygge-AI er en annen utfordring helt og holdent. Verktøyene er inne i plattformene du godkjente. Personene som bygger dem er dine egne ansatte. Tilgangen de bruker er legitim. Og ingen av dem passerer gjennom sikkerhetsprosessene som er designet for å fange problemer før de når produksjon.

Hva gjør dette spesielt vanskelig å løse, er skalaen. De fleste sikkerhetsledere underskatter betydelig hvor mye som bygges inne i sine egne miljøer. Nylig forskning fra over 200 virksomhets-CISO-er og sikkerhetsledere fant at det gjennomsnittlige virksomhetssikkerhetsteam kan kun regne med 44% av de AI-agenter, automatiseringer og applikasjoner som forretningsbrukerne har laget. Det er ikke et gap. Det er et blindpunkt som dekker det meste av hva som kjører.

Grunden er enkel: forretningsbrukere teller nå langt flere enn profesjonelle utviklere i noen organisasjoner. De bygger konstant over hele hver avdeling, på plattformer som var designet for å gjøre bygging enkelt, og så oppmuntret av C-suiten til å bygge. Sikkerhetsteamene er orientert rundt utviklerpipeliner og kodearkiv. De var aldri designet for å overvåke dette.

Den vanligste misforståelsen er troen på at godkjenning av en plattform løser sikkerhetsproblemet. Det gjør det ikke, det flytter det bare. Når en virksomhet signerer en avtale med Microsoft, Salesforce eller UiPath, sikrer plattformleverandøren sin infrastruktur. Hva ansatte bygger på toppen av det, og hvordan de konfigurerer det, er virksomhetens ansvar helt og holdent.

Problemet er at verktøyene forretningsbrukerne lager, ser ikke ut som programvare for tradisjonelle sikkerhetssystemer. Det er ingen kode å skanne, ingen arkiv å overvåke, ingen pipeline å inspisere. En AI-agent bygget av en HR-sjef gjennom en serie med menyvalg og tekstprompter er, sett fra perspektivet til de fleste sikkerhetssystemer, usynlig.

Og likevel er disse verktøyene langt ifra ubetydelige. Forskning har funnet at over halvparten av CISO-ene bekreftet at forretningsbygde applikasjoner nå støtter kritiske forretningsprosesser og har tilgang til følsomme selskapsdata. Risikoen er reell, og oversikten har ikke holdt tritt.

Fra null til katastrofe

Bruksområdene er like diverse som de er tallrike og kommer fra nesten hver eneste avdeling, selv de som aldri ville ha forekommet for et sikkerhetsteam å holde øye på.

For eksempel bygger en markedskoordinator en kundeorientert AI-agent på en fullt godkjent plattform for å svare på produktspørsmål. På bare noen minutter er appen oppe og kjører, men som noen med ingen sikkerhetstreningsbakgrunn, går to små konfigurasjonsfeil ubemerket og lar agenten få direkte tilgang til selskapets hele database og ingen grenser for hva den kan hente ut. I produksjon ber en bruker det om å hente ut ansattinformasjon. Det gjør det. Fordi agenten også har en e-postfunksjon, ber brukeren det om å sende denne dataen til en personlig adresse. Hele sekvensen tar under sekstti sekunder. Ingen uautorisert tilgang. Ingen plattformbrudd. Ingen sikkerhetsvarsel.

Dette er ikke et sofistikert angrep. Det er det forutsigbare resultatet av en velmenende ansatt som bygger noe de ikke fullstendig forstår, på en plattform som gjorde bygging enkelt og styring valgfritt.

Styringsgapet ingen har priset inn

For de fleste organisasjoner forblir Skygge-AI-problemet abstrakt inntil noe går galt. Men forretningsrisikoen går dypere enn svikten av å svare på et brudd.

Når en forretningsbygget agent lekker følsomme data, er spørsmålet et styre vil stille ikke “hvordan skjedde miskonfigurasjonen?” Det vil være “hvordan visste ingen at verktøyet kjørte?” De vil ikke skille mellom et brudd forårsaket av en ekstern angriper og ett forårsaket av et miskonfigurert internt verktøy. Hvis personlige data ble eksponert og organisasjonen manglet oversikt over hva som kjørte, er mangelen på oversikt i seg selv ansvarlig. “En ansatt bygde det på en godkjent plattform” er ikke et forsvar, det er beskrivelsen av gapet.

Urgensen er reell, men intensjon og utførelse er ikke det samme, og for de fleste virksomhetene forblir gapet mellom dem åpent.

Svaret er ikke å begrense hvem som kan bygge. Å låse ned borgerutvikling ville ofre ekte produktivitetsgevinster og ville ikke holde i praksis. Ansatte ville finne omveier. Svaret er å bringe hva som bygges inn i syne og å styre det der risikoen faktisk oppstår: kjøretid.

Det betyr å forstå ikke bare hva agenter finnes, men hvordan de oppfører seg, hva data de får tilgang til, hva systemer de berører, og om deres handlinger holder seg innenfor grensene deres byggere mente. Det betyr å sette opp retningslinjer som opererer på organisatorisk nivå, ikke bare ved konfigurasjonspunktet. Og det betyr å komme til et sted hvor sikkerhetsteamene kan svare på de mest grunnleggende spørsmålene om hver enkelt agent i deres miljø: hvem bygde det, hva har det tilgang til, og oppfører det seg som det var ment å gjøre?

De fleste virksomhetene kan ikke svare på disse spørsmålene i dag. Organisasjonene som kommer dit først, vil være de som kan skalerer AI-adoptsjon med tillit, fordi de vil vite hva de faktisk kjører.