Leader di pensiero

L’AI ombra è un fallimento di progettazione, non un problema di persone

Aggiungi Unite.AI alle tue fonti preferite su Google

Voglio che tu ricordi una frase da questo articolo. Se dimentichi tutto il resto, ricorda questo: l’AI ombra è il risultato diretto di rendere il percorso sicuro il percorso lento.

Questo non è un’opinione controversa. È un modello che ho osservato per venticinque anni in ogni dominio di sicurezza – dall’IT ombra al BYOD alla sprawl cloud. E adesso sta succedendo di nuovo con l’AI, ma più velocemente e con poste in gioco più elevate.

Il divario che dovrebbe tenerti sveglio di notte

L’Indice delle tendenze del lavoro di Microsoft e LinkedIn del 2024 ha fornito numeri concreti su qualcosa che la maggior parte dei leader della sicurezza già sentiva nel loro intuito: il 75% dei lavoratori della conoscenza utilizza strumenti di AI sul lavoro, e il 78% di loro li porta con sé. Questo non è sperimentazione. È una forza lavoro che ha deciso di non aspettare che l’IT si aggiornasse.

Ecco la parte che fa male: la governance non sta tenendo il passo. Un sondaggio Checkmarx del 2025 ha scoperto che solo il 18% delle organizzazioni ha politiche di governance che coprono la generazione di codice assistita da AI – nonostante la maggior parte delle squadre di ingegneria già utilizzino questi strumenti quotidianamente. Se il divario è così ampio per il codice, immagina come appaia per ogni altro flusso di lavoro alimentato da AI che le tue squadre stanno eseguendo. L’adozione non aspetta la governance. La sta superando.

Le tue persone non stanno agendo in modo avventato. Stanno agendo in modo razionale. Hanno trovato uno strumento che li rende più veloci, e il percorso ufficiale per utilizzarlo in modo sicuro prevede l’installazione di Python, la creazione di progetti GCP, la generazione di account di servizio, il download di credenziali JSON sui loro laptop e la configurazione di server MCP locali. Storia vera. Risultato: la persona ha rinunciato tre passi dopo.

Il modello di fallimento che continuo a vedere

Voglio rendere il modello concreto. Ho osservato variazioni di questo in decine di organizzazioni.

Un direttore marketing legge un post del blog: collega un assistente AI a un server MCP di Google Analytics, esegui qualsiasi rapporto SEO in pochi secondi. Sembra grande. Vuole farlo.

Quindi inizia percorso non gestito. Installa le dipendenze. Crea un progetto cloud. Genera un account di servizio. Scarica un file di credenziali sul suo laptop. Configura l’integrazione localmente.

Rinuncia. Tre passi dopo. Troppa frizione. Strumento sbagliato per la persona sbagliata.

Ora ascolta cosa sto dicendo. Il problema non è il direttore marketing. È intelligente. È motivato. È esattamente il tipo di persona che vuoi che adotti strumenti di AI. Il problema è che il percorso sicuro era più lento del percorso insicuro.

Questo è il modello di fallimento di ogni programma di accesso legacy che abbia mai visto. Quando il percorso gestito è più difficile del percorso non gestito, le persone troveranno il percorso non gestito. Ogni volta. E scoprirete tutto ciò al momento della violazione, non prima.

I cinque sepolcri

Ho visto organizzazioni cercare di risolvere questo problema in cinque modi diversi prima di arrivare a ciò che funziona veramente. Ogni approccio è fallito per la stessa ragione di base: ha aggiunto frizione senza aggiungere velocità.

Il primo tentativo è stato quello di lasciare che ogni squadra scegliesse il proprio strumento di AI. Il risultato è stato quattordici abbonamenti sovrapposti e zero traccia di audit. Avete democratizzato l’adozione e centralizzato nulla.

Il secondo tentativo è stato quello di mettere tutto dietro l’SSO. L’SSO risolve l’accesso. L’SSO non risolve l’azione. Una volta che l’agente è autenticato, il tuo livello SSO è cieco a ciò che fa dopo.

Il terzo tentativo è stato quello di condividere un account di servizio tra gli agenti. Un incidente dopo, avete zero attribuzione. Non potete dire quale agente abbia fatto cosa quando qualcosa va storto.

Il quarto tentativo è stato quello di scrivere una politica di AI e metterla sul wiki. Ho visto un’organizzazione trascorrere sei settimane a creare una politica di utilizzo accettabile di AI, circolarla a tutti e scoprire tre mesi dopo che meno di un terzo dei dipendenti aveva aperto il documento. Nessuno legge i documenti. Le persone leggono i valori predefiniti. Qualsiasi cosa sia facile è ciò che viene fatto – e una pagina wiki non è mai ciò che è facile.

Il quinto tentativo è stato quello di istituire un consiglio di revisione centralizzato per ogni progetto di AI. Pensate di essere responsabili. State creando un collo di bottiglia. Entro un quarto, le squadre stanno aggirando voi – e avete creato esattamente il problema di AI ombra che stavate cercando di prevenire.

Ogni uno di questi sepolcri ha la stessa epigrafe: credenziali sparse sui laptop, nessuna traccia di audit e molte dita incrociate.

L’inversione che funziona veramente

La soluzione non è aggiungere più frizione. È un’inversione.

La sicurezza tradizionale costruisce frizione per prevenire comportamenti negativi. Gli utenti aggirano la frizione. L’AI ombra appare. Scoprite tutto ciò al momento della violazione.

Invertite la situazione. Fate in modo che il percorso fornito sia più veloce del percorso non gestito.

Che aspetto ha questo nella pratica? Quella stessa direttrice marketing – invece di lottare con Python e account di servizio – richiede l’accesso a Google Analytics all’interno del suo assistente di AI. La richiesta colpisce un motore di politiche. Basso rischio, strumento noto, utente noto – approvato automaticamente. La credenziale è archiviata, limitata e a vita breve. Non tocca mai il suo laptop. Ogni query è registrata. Sta eseguendo rapporti in meno di un minuto.

Stessa persona. Stesso risultato che voleva. Una frazione del tempo. Traccia di audit completa. Incentivo diverso. Risultato diverso.

Questo è come appare la gestione dell’accesso di AI quando è costruita correttamente. Il percorso più veloce diventa il percorso più sicuro. L’incentivo per aggirare l’IT scompare – non perché avete applicato la conformità in modo più rigido, ma perché avete reso la conformità più facile dell’alternativa. Quando il vostro percorso gestito è veramente più veloce del percorso non gestito, l’AI ombra inizia a risolvere se stessa.

Misurare ciò che conta

Ecco la metrica che non scompare mai: il percorso gestito è più veloce del percorso non gestito? Nel momento in cui il percorso non gestito è più veloce del percorso gestito, l’AI ombra ritorna e ricominciate da capo.

Non è una misurazione una tantum. È un segnale continuo. Ogni volta che aggiungete un passo, una revisione, un’approvazione – chiedetevi se avete appena reso il percorso ombra più attraente.

Il self-service non è una funzionalità di produttività. È una funzionalità di sicurezza. Quella linea inverte il modo in cui la maggior parte dei team di sicurezza pensa alla gestione dell’accesso, ed è il più importante riassetto che posso offrire. La frizione crea rischio – ogni singola volta.

Se volete un comportamento, fatelo il valore predefinito. Se non volete un comportamento, fatelo più difficile dell’alternativa. Costruite per quel principio, e la maggior parte del vostro problema di AI ombra si risolve da sola.

Kevin Paige è un leader della sicurezza con oltre 30 anni di esperienza in campo militare, Salesforce, MuleSoft, Flexport e ConductorOne. Scrive di governance dell'identità nell'era dell'AI agente.