La Giungla AI dell’Ombra: Perché Approvare una Piattaforma non è lo Stesso che Proteggere ciò che è Costruito su di Essa

L’adozione di AI aziendale è ben lontana dall’essere priva di attriti. Le preoccupazioni relative al controllo dei dati, alla conformità normativa e alla sicurezza hanno accompagnato ogni fase del percorso. Tuttavia, mentre le organizzazioni aumentano le loro operazioni su piattaforme importanti come Microsoft, Salesforce e ServiceNow, c’è una crescente sensazione che le più difficili domande di governance siano, almeno in parte, state affrontate. Gli accordi aziendali sono in vigore. Le verifiche di sicurezza sono state completate. Le piattaforme sono state approvate.

Quella che questa fiducia tende a trascurare è una domanda completamente diversa: non se la piattaforma sia sicura, ma cosa e chi stia costruendo.

In tutti i settori, una rivoluzione silenziosa è in corso mentre i dipendenti non tecnici utilizzano piattaforme di intelligenza artificiale aziendale per creare agenti autonomi, flussi di lavoro automatizzati e applicazioni collegate ai dati, spesso in pochi minuti, senza scrivere una sola riga di codice. Liberi dai tradizionali tempi di sviluppo e dalle restrizioni, questi costruttori sono un vantaggio per l’efficienza organizzativa. Tuttavia, questi strumenti non vengono mai esaminati da un team di sicurezza. In molti casi, i team di sicurezza non sono nemmeno a conoscenza della loro esistenza.

Questi strumenti, classificati come app, agenti o automazioni, fanno parte di un problema crescente noto come Shadow AI, e rappresenta uno dei più significativi spostamenti del rischio aziendale in un decennio, per la semplice ragione che le minacce si sono ora spostate all’interno.

Il problema originale di Shadow IT era relativamente semplice: i dipendenti utilizzavano strumenti non autorizzati dall’esterno dell’organizzazione, e il lavoro della sicurezza era quello di trovarli e bloccarli. Shadow AI è una sfida completamente diversa. Gli strumenti sono all’interno delle piattaforme che avete approvato. Le persone che li costruiscono sono i vostri stessi dipendenti. L’accesso che stanno utilizzando è legittimo. E nulla di tutto ciò passa attraverso i processi di sicurezza progettati per catturare i problemi prima che raggiungano la produzione.

Ciò che rende questo particolarmente difficile da affrontare è la scala. La maggior parte dei leader della sicurezza sottostima notevolmente quanto viene costruito all’interno del proprio ambiente. Recentemente, una ricerca condotta su oltre 200 CISO e leader della sicurezza aziendale ha scoperto che il team di sicurezza aziendale medio può rendere conto solo del 44% degli agenti AI, delle automazioni e delle applicazioni create dagli utenti aziendali. Questo non è un gap, è un punto cieco che copre la maggior parte di ciò che viene eseguito.

Il motivo è semplice: gli utenti aziendali superano i developer professionisti di circa 10 a 1 in alcune organizzazioni. Stanno costantemente costruendo in ogni dipartimento, su piattaforme progettate per rendere facile la costruzione, e poi incoraggiati dalla dirigenza a costruire. I team di sicurezza sono orientati verso le pipeline dei developer e i repository di codice. Non sono stati progettati per monitorare questo.

Il più comune malinteso è la convinzione che approvare una piattaforma risolva il problema di sicurezza. Non è così, si sposta solo. Quando un’azienda firma un accordo con Microsoft, Salesforce o UiPath, il fornitore di piattaforma protegge la propria infrastruttura. Ciò che gli dipendenti costruiscono sopra di essa, e come la configurano, è interamente responsabilità dell’azienda.

Il problema è che gli strumenti creati dagli utenti aziendali non sembrano software ai sistemi di sicurezza tradizionali. Non c’è codice da scansionare, non c’è repository da monitorare, non c’è pipeline da ispezionare. Un agente AI costruito da un responsabile delle risorse umane attraverso una serie di menu e prompt di testo è, dalla prospettiva della maggior parte degli strumenti di sicurezza, invisibile.

Eppure, questi strumenti sono ben lontani dall’essere banali. La ricerca ha scoperto che più della metà dei CISO ha confermato che le applicazioni costruite dagli utenti aziendali supportano ora processi aziendali critici e hanno accesso a dati aziendali sensibili. Le poste in gioco sono reali e la supervisione non ha ancora colmato il gap.

Da Zero al Disastro

I casi d’uso sono tanto diversi quanto numerosi e provengono virtualmente da ogni dipartimento, anche da quelli che non sarebbero mai stati presi in considerazione da un team di sicurezza.

Ad esempio, un coordinatore di marketing costruisce un agente AI rivolto ai clienti su una piattaforma completamente autorizzata per rispondere alle domande sui prodotti. In pochi minuti, l’app è attiva e in funzione, ma poiché non ha alcuna formazione sulla sicurezza, due piccoli errori di configurazione passano inosservati e lasciano l’agente con accesso diretto all’intero database aziendale e senza limiti su ciò che può recuperare. In produzione, un utente gli chiede di estrarre i record dei dipendenti. Lo fa. Poiché l’agente ha anche una capacità di posta elettronica, l’utente gli chiede di inviare quei dati a un indirizzo personale. L’intera sequenza dura meno di sessanta secondi. Nessun accesso non autorizzato. Nessuna violazione della piattaforma. Nessun allarme di sicurezza.

Questo non è un attacco sofisticato. È il risultato prevedibile di un dipendente ben intenzionato che costruisce qualcosa che non comprende appieno, su una piattaforma che rende facile la costruzione e la governance facoltativa.

Il Divario di Governance che Nessuno Ha Valutato

Per la maggior parte delle organizzazioni, il problema Shadow AI rimane astratto fino a quando qualcosa va storto. Tuttavia, il rischio aziendale va ben oltre la risposta a una violazione.

Quando un agente costruito dall’azienda perde dati sensibili, la domanda che il consiglio di amministrazione porrà non sarà “come è successa la miconfigurazione?” Sarà “come è possibile che nessuno sapesse che lo strumento era in esecuzione?” Non distingueranno tra una violazione causata da un attaccante esterno e una causata da uno strumento interno mal configurato. Se i dati personali sono stati esposti e l’organizzazione non aveva visibilità su ciò che stava eseguendo, l’assenza di supervisione è di per sé una responsabilità. “Un dipendente l’ha costruito su una piattaforma approvata” non è una difesa, è la descrizione del divario.

L’urgenza è reale, ma l’intenzione e l’esecuzione non sono la stessa cosa, e per la maggior parte delle aziende, il gap tra loro rimane ampio.

La risposta non è limitare chi può costruire. Bloccare lo sviluppo dei cittadini sacrificherebbe genuine conquiste di produttività e, nella pratica, non funzionerebbe. I dipendenti troverebbero soluzioni alternative. La risposta è portare ciò che viene costruito alla vista e governarlo nel punto in cui il rischio emerge effettivamente: il runtime.

Ciò significa comprendere non solo quali agenti esistono, ma come si comportano, quali dati accedono, quali sistemi toccano e se le loro azioni rimangono entro i limiti previsti dai loro costruttori. Ciò significa stabilire limiti che operano a livello organizzativo, non solo al punto di configurazione. E significa raggiungere un punto in cui i team di sicurezza possano rispondere alle domande più basilari su qualsiasi agente nel loro ambiente: chi l’ha costruito, a cosa ha accesso e si comporta come previsto?

La maggior parte delle aziende non può rispondere a queste domande oggi. Le organizzazioni che ci arriveranno per prime saranno quelle che potranno scalare l’adozione di AI con fiducia, perché sapranno cosa stanno effettivamente eseguendo.