L’avvertimento di Akamai sulla Shadow AI mette in luce un divario nei controlli aziendali

Akamai ha lanciato un netto avvertimento: quasi la metà degli utenti aziendali accede a strumenti di AI, mentre gran parte di questa attività può sfuggire ai controlli corporate consolidati.

La constatazione è emersa da un titolo troncato su Google News che rimandava a un comunicato Akamai distribuito da GlobeNewswire. Quella voce ometteva il complemento dopo “bypasses”, lasciando incompleta l’affermazione centrale. La ricerca più ampia di Akamai, tuttavia, identifica chiaramente il conflitto mancante: l’uso produttivo dell’AI avviene sempre più al di fuori di identità gestite, account approvati e canali di sicurezza visibili.

Non si tratta semplicemente dell’ennesimo sondaggio che mostra come i lavoratori apprezzino ChatGPT. Descrive uno scontro tra la domanda dei dipendenti e il modello di controllo che le aziende hanno costruito per il software convenzionale. OpenAI, Google, Anthropic, Microsoft e centinaia di fornitori più piccoli hanno reso disponibili strumenti avanzati tramite un normale browser.

La questione della sicurezza si è quindi spostata. Le aziende non devono più soltanto decidere quali sistemi di AI approvare. Devono stabilire se informazioni sensibili raggiungano un qualsiasi modello tramite account personali, testo incollato, upload, estensioni o funzionalità integrate.

Il ribaltamento è scomodo. Le aziende hanno trascorso anni a centralizzare identità, accessi e approvvigionamento software. L’adozione dell’AI sta ora decentralizzando tutti e tre dall’interno del browser.

Il titolo indica un punto cieco delle dimensioni del browser

L’avvertimento di Akamai riguarda il percorso che i dipendenti usano per raggiungere l’AI, non semplicemente il numero di persone che la sperimentano.

Le prove disponibili provengono in parte da LayerX, la società di browser security acquisita da Akamai. LayerX raccoglie telemetria sulle attività all’interno delle applicazioni web, inclusi accessi, upload, testo incollato e passaggi tra account aziendali e personali.

La sua ricerca pubblicata ha rilevato che il 45% degli utenti aziendali accedeva all’AI generativa da endpoint corporate. ChatGPT rappresentava il 92% dell’utilizzo di AI osservato in quel dataset.

Queste cifre non significano che il 45% di tutti i dipendenti nel mondo utilizzi ChatGPT. Descrivono l’attività nelle organizzazioni e negli endpoint coperti dalla telemetria del fornitore. Questa distinzione conta nell’interpretazione di qualsiasi rapporto di una società di sicurezza.

La stessa ricerca ha individuato uno schema più rilevante. Il quaranta per cento dei file caricati negli strumenti di AI conteneva informazioni aziendali sensibili. Il ventidue per cento del testo incollato conteneva anch’esso materiale sensibile.

Queste percentuali misurano trasferimenti ispezionati, non violazioni confermate. Un upload sensibile può essere autorizzato, adeguatamente protetto e necessario per un lavoro legittimo. Può anche transitare attraverso un account personale che il datore di lavoro non può verificare.

LayerX ha riferito che il 32% dei trasferimenti di dati tra account aziendali e personali avveniva tramite piattaforme di AI. Le sue più ampie conclusioni sull’uso dell’AI collocano il browser al centro di questa esposizione.

Questo aiuta a spiegare il linguaggio troncato “bypasses” nella voce di Google News. I controlli pertinenti comprendono l’identità aziendale, il single sign-on, le regole sugli account approvati, le politiche di prevenzione della perdita di dati e la normale revisione del software.

Il single sign-on, comunemente chiamato SSO, consente a un datore di lavoro di gestire l’accesso tramite un’unica identità aziendale. Gli account personali di AI evitano questo livello di identità anche quando i dipendenti li utilizzano su dispositivi aziendali.

La governance software tradizionale presuppone che l’IT possa individuare un’applicazione, approvarla, fornire l’accesso e in seguito revocarlo. Gli strumenti di AI per i consumatori comprimono l’adozione in una visita, un login e un prompt.

Non è necessaria alcuna richiesta di installazione. Un lavoratore può aprire un chatbot, autenticarsi con un indirizzo email personale e incollare un documento cliente nel giro di pochi minuti.

L’AI integrata complica ulteriormente l’individuazione. Le funzionalità generative compaiono ormai nelle suite di produttività, negli strumenti di design, nelle piattaforme per le riunioni, nei sistemi per i clienti e nelle estensioni del browser. I dipendenti potrebbero non considerare ogni funzionalità come un servizio di AI distinto.

Akamai definisce la shadow AI come l’uso dell’AI senza la conoscenza, l’approvazione o la supervisione dei team IT, di sicurezza o compliance. Questo include più dei chatbot non autorizzati.

Uno sviluppatore potrebbe inviare codice proprietario a un assistente di programmazione personale. Un responsabile marketing potrebbe caricare una lista clienti per generare segmenti di campagna. Un manager potrebbe collegare un agente a documenti cloud senza esaminarne le autorizzazioni.

Ogni azione può sembrare normale traffico del browser. L’elemento rischioso è il contesto, inclusi l’identità dell’utente, le informazioni trasferite e la gestione contrattuale di tali informazioni da parte del fornitore.

Un firewall può vedere una connessione verso un dominio consentito. Non sa automaticamente se il dipendente ha utilizzato un account aziendale gestito o un account privato.

Questo è il cambiamento centrale alla base del rapporto. L’AI aziendale è diventata abbastanza comune che governare l’accesso soltanto in base al nome dell’applicazione non offre più una visibilità adeguata.

Perché i controlli sull’AI aziendale stanno perdendo la corsa all’adozione

I dipendenti aggirano i percorsi approvati quando l’AI per i consumatori offre un accesso più rapido, funzionalità più ampie o meno ostacoli procedurali.

La shadow AI spesso inizia con un’esigenza pratica piuttosto che con un intento malevolo. Un lavoratore deve riassumere una riunione, rivedere una proposta, esaminare codice o confrontare diversi documenti.

L’assistente approvato potrebbe non offrire il modello preferito, accettare meno tipi di file o rimanere indisponibile per quel reparto. Anche le verifiche di procurement e sicurezza possono procedere più lentamente del lavoro.

Un chatbot personale offre accesso immediato. Il dipendente vede uno strumento di produttività, mentre il team di sicurezza vede un responsabile del trattamento dei dati non esaminato.

Questo divario di incentivi spiega perché i divieti producono risultati limitati. Bloccare un servizio può reindirizzare gli utenti verso un altro fornitore, un dispositivo mobile, un profilo browser personale o una funzionalità integrata.

Una policy efficace deve affrontare il motivo per cui i dipendenti hanno scelto la strada non ufficiale. Altrimenti, l’applicazione delle regole tratta il sintomo visibile mantenendo intatta la domanda.

Le stesse linee guida di Akamai affermano che l’uso non ufficiale diminuisce quando le aziende forniscono strumenti approvati e capaci, con protezioni contrattuali, registri di audit e integrazione SSO. Il percorso sicuro deve comunque risolvere il problema dell’utente.

Il paragone storico è lo shadow IT, cresciuto quando i reparti acquistavano applicazioni cloud senza un’approvazione centralizzata. I team di sicurezza hanno infine adottato broker di accesso al cloud, individuazione delle applicazioni e procurement più flessibile.

L’AI aumenta la posta in gioco perché la transazione spesso contiene dati aziendali. Un’applicazione non autorizzata convenzionale potrebbe archiviare una nuova pianificazione di progetto. Un’interazione con un chatbot può trasmettere immediatamente codice sorgente, testo legale, registri dei clienti o una strategia non ancora pubblicata.

I sistemi generativi producono inoltre output che i lavoratori possono riutilizzare senza documentarne l’origine. Questo introduce questioni di accuratezza, proprietà intellettuale, bias e responsabilità, oltre all’esposizione dei dati.

Lo stesso servizio di AI può presentare profili di rischio diversi a seconda dell’account. Un contratto enterprise può prevedere controlli sulla conservazione, log amministrativi e restrizioni sull’addestramento dei modelli.

Un account personale potrebbe non disporre di tali protezioni. I team di sicurezza devono quindi distinguere tra identità e sessioni, non limitarsi a riconoscere il dominio di destinazione.

Questa differenza mette sotto pressione i chief information officer e i responsabili della sicurezza da direzioni opposte. Dai CIO ci si aspetta che aumentino l’adozione dell’AI, mentre i responsabili della sicurezza devono ridurre i movimenti di dati non controllati.

I leader aziendali aggiungono un’altra richiesta: produttività misurabile. Se l’ambiente ufficiale rallenta i dipendenti senza migliorare i risultati, l’uso non ufficiale diventa una risposta prevedibile.

Il conflitto emerge oltre la base clienti di Akamai. Axios ha riferito che le aziende disponevano comunemente di 67 strumenti di AI generativa in uso, con il 90% privo di licenze o approvazioni adeguate. La sua copertura della shadow AI descriveva fornitori di sicurezza in corsa per colmare il divario di visibilità.

Anche in questo caso, le misurazioni dei fornitori variano in base alla popolazione di clienti, al metodo di raccolta e alla definizione. Un’azienda può contare i domini, mentre un’altra conta applicazioni, account, utenti o singole sessioni.

La direzione è più affidabile di qualsiasi singola percentuale. I dipendenti hanno molte strade verso l’AI e gli inventari aziendali catturano costantemente soltanto una parte di tale attività.

La pressione non si ferma ai team di sicurezza. I dipartimenti legali devono stabilire quali fornitori possano trattare informazioni regolamentate o riservate.

I team privacy devono comprendere dove viaggiano prompt e file. I team di procurement devono esaminare un elenco crescente di funzionalità AI, comprese quelle aggiunte a prodotti già sotto contratto.

Anche i manager hanno bisogno di regole per l’output generato. Uno strumento approvato non rende automaticamente corretta ogni risposta e un accordo aziendale non convalida ogni decisione presa con il suo output.

Il problema del controllo ha quindi due livelli. Le aziende devono governare le informazioni che entrano nei sistemi di AI e le decisioni che ne escono.

Bloccare gli account non autorizzati affronta soltanto il primo livello. Non stabilisce quando una risposta generata richieda una revisione, quali fonti abbia utilizzato il sistema o chi resti responsabile.

Questo onere di governance più ampio spiega perché la corsa all’adozione appare sbilanciata. Un lavoratore può iniziare a usare l’AI immediatamente, mentre una struttura completa di controllo aziendale richiede la cooperazione di diversi reparti.

La vera sfida è tra AI gestita e AI utile

Il principale avversario non è Akamai contro un altro fornitore di sicurezza; è l’AI gestita contro gli strumenti che i dipendenti ritengono più utili.

Le aziende talvolta presentano sicurezza e produttività come obiettivi contrapposti. Questa impostazione incoraggia controlli rigidi, inclusi blocchi completi, allowlist ristrette e lunghe procedure di approvazione.

I dipendenti si trovano quindi davanti a una scelta semplice. Possono attendere un flusso di lavoro approvato oppure completare l’attività con un servizio consumer che conoscono.

La sfida migliore riguarda la qualità del prodotto. Un assistente gestito deve offrire capacità, contesto, velocità e affidabilità sufficienti a diventare la scelta predefinita.

Il contesto è particolarmente importante. I knowledge worker hanno bisogno che l’AI operi su documenti, conversazioni, cronologia dei progetti e materiale interno specializzato.

Questo accesso crea anche rischi. Autorizzazioni ampie possono esporre informazioni che un lavoratore non si rendeva conto di poter recuperare tramite un’interfaccia AI.

Un ambiente di conoscenza gestito dovrebbe preservare i confini di accesso esistenti. Dovrebbe inoltre mostrare quali fonti hanno supportato una risposta e mantenere il recupero delle informazioni entro il materiale autorizzato.

È qui che una knowledge base personale può ridurre la copia ad hoc tra sistemi aziendali e chatbot pubblici. L’acquisizione locale o controllata non elimina i doveri di governance, ma può ridurre i trasferimenti non necessari.

I controlli di sicurezza devono operare nel momento dell’interazione. Gli strumenti di rete restano utili, ma possono non cogliere distinzioni nascoste all’interno di sessioni browser crittografate.

I controlli a livello di browser possono identificare l’account attivo, ispezionare un upload e riconoscere un’operazione di incolla prima che le informazioni lascino l’endpoint. Possono quindi avvisare, oscurare, bloccare o registrare l’azione.

Workforce Protector di Akamai, precedentemente LayerX, riflette questo approccio. Secondo Akamai, governa il comportamento di utenti e agenti all’interno delle applicazioni invece di affidarsi soltanto al traffico perimetrale.

L’azienda ha un interesse commerciale nel definire il browser come punto critico di applicazione dei controlli. Gli acquirenti dovrebbero valutare questa affermazione insieme alle alternative di sicurezza per endpoint, rete, identità e dati.

Nessun singolo livello copre ogni percorso. Un’estensione del browser non può governare uno smartphone non gestito che non entra mai nell’ambiente aziendale.

I controlli di rete possono identificare le destinazioni, ma potrebbero non disporre di un contesto dettagliato della sessione. Gli agenti sugli endpoint possono ispezionare l’attività del dispositivo, ma potrebbero non comprendere la semantica interna di ogni applicazione.

I controlli dell’identità stabiliscono chi ha effettuato l’accesso, ma non determinano automaticamente se ogni prompt contiene informazioni riservate. La classificazione dei dati può riconoscere contenuti sensibili, ma dipende da etichette e copertura accurate.

L’architettura pratica combina questi segnali. Collega identità, stato di sicurezza del dispositivo, destinazione, tipo di account, sensibilità dei contenuti e azione richiesta.

Consideriamo un dipendente che riassume un annuncio pubblico di prodotto. Un chatbot personale presenta un rischio organizzativo limitato perché l’input è già pubblico.

Ora consideriamo lo stesso dipendente che incolla trascrizioni dell’assistenza clienti. La destinazione può rimanere identica, ma requisiti di privacy, conservazione e contrattuali modificano la decisione.

La sola ispezione dei file non rileva nemmeno i comportamenti di copia e incolla. Le misurazioni di LayerX indicano che il testo incollato costituisce un canale di esposizione significativo, anche quando i dipendenti non caricano mai un documento.

Gli agenti aggiungono un’altra dimensione. Un agente può recuperare informazioni, chiamare servizi esterni, aggiornare record e ripetere azioni senza un gesto umano separato ogni volta.

Questo trasforma la progettazione dei permessi in una questione di sicurezza operativa. Un chatbot risponde a una richiesta, mentre un agente può provocare una modifica.

Lo studio sulla sicurezza delle API di Akamai del 2026 ha coinvolto 1.840 responsabili e professionisti della sicurezza in dieci Paesi. Ha rilevato che l’80% utilizzava web application firewall, mentre solo il 35% impiegava strumenti dedicati alla sicurezza delle API.

Le API sono interfacce che consentono ai sistemi software di scambiare dati e comandi. Costituiscono il livello di connessione tra agenti, modelli, database e applicazioni aziendali.

Una sessione chatbot non autorizzata può far trapelare informazioni. Un agente con privilegi eccessivi può anche modificare un ticket, emettere un rimborso, inviare un messaggio o interrogare un sistema riservato.

L’AI gestita deve quindi competere su aspetti che vanno oltre la qualità del modello. Ha bisogno di integrazioni utili, permessi limitati, registrazione affidabile e approvazione umana per le azioni rilevanti.

Se queste protezioni rendono ogni attività gravosa, i dipendenti le eviteranno. Se scompaiono del tutto, l’organizzazione non può distinguere la comodità da un’esposizione inaccettabile.

Il design vincente rende semplici le azioni comuni a basso rischio. Riserva ulteriore frizione ai dati sensibili, alle destinazioni insolite, agli account personali e ai comandi ad alto impatto.

È una sfida di prodotto tanto quanto una sfida di policy. Le aziende non possono risolvere con la formazione interfacce che premiano sistematicamente scorciatoie non sicure.

Cosa non dimostra il titolo di Google News

Il rischio sottostante è credibile, ma il titolo troncato non dimostra in modo indipendente che quasi la metà di tutta l’attività AI aziendale aggiri i controlli.

La voce di Google News tronca l’affermazione subito dopo “aggira”. Non identifica il controllo, il periodo di misurazione, il campione, l’area geografica o il denominatore.

Queste omissioni impediscono un’interpretazione precisa. “Quasi la metà dell’uso aziendale dell’AI” potrebbe riferirsi a utenti, account, sessioni, endpoint, organizzazioni, caricamenti o a un’altra categoria misurata.

I materiali Akamai e LayerX indicizzati pubblicamente supportano diversi risultati correlati. Non rendono intercambiabili tutte le possibili interpretazioni di quella frase.

LayerX ha riferito che il 45% degli utenti aziendali accedeva a strumenti AI da endpoint aziendali. Separatamente, ha segnalato contenuti sensibili nel 40% dei file caricati e nel 22% del testo incollato.

Ha inoltre riportato un ampio uso di identità personali nei servizi software. La sua ricerca sull’identità del 2025 ha rilevato che il 40% degli accessi SaaS utilizzava credenziali personali e il 67% aggirava l’SSO.

Queste statistiche descrivono popolazioni e comportamenti diversi. Combinarle in un’unica affermazione onnicomprensiva creerebbe un numero che la ricerca non ha pubblicato.

La prima cautela riguarda quindi la disciplina del denominatore. I lettori dovrebbero chiedersi cosa sia stato conteggiato prima di considerare una percentuale come un tasso universale di adozione.

La seconda cautela riguarda la telemetria dei fornitori. I provider di sicurezza analizzano spesso l’attività di clienti che hanno già implementato i loro prodotti.

Queste organizzazioni possono differire dalle aziende prive di un monitoraggio comparabile. Settore, dimensioni, policy e profilo di rischio possono influenzare i risultati misurati.

La telemetria resta utile perché osserva il comportamento anziché basarsi solo sulla memoria. Tuttavia, non rappresenta automaticamente ogni azienda o dipendente.

I sondaggi presentano un limite diverso. I rispondenti possono fraintendere le definizioni, sottostimare attività vietate o rappresentare organizzazioni con programmi AI insolitamente maturi.

La ricerca indipendente dovrebbe quindi confrontare diverse forme di evidenza. Fonti utili includono telemetria degli endpoint, log di rete, record di identità, sondaggi sui dipendenti, rapporti sugli incidenti e informative normative.

La terza cautela riguarda la parola “aggirare”. Un accesso personale può aggirare la gestione aziendale delle identità senza aggirare ogni controllo di sicurezza.

L’endpoint potrebbe comunque eseguire software di prevenzione della perdita di dati. La rete potrebbe comunque bloccare determinate destinazioni. Il provider potrebbe comunque offrire impostazioni di privacy per i consumatori.

Al contrario, un account approvato può creare rischi anche quando passa attraverso l’SSO. Restano possibili permessi eccessivi, regole di conservazione deboli, prompt injection e output inaccurati.

Questa distinzione evita una conclusione semplicistica. Gestito non significa sicuro, e non gestito non significa violazione confermata.

Lo studio sull’AI aziendale commissionato da Akamai nel 2025 illustra la preoccupazione più ampia. Tra 400 rispondenti globali a livello di direttore, il 63% ha identificato le preoccupazioni per la sicurezza come una delle principali sfide nelle applicazioni AI.

Lo stesso studio ha rilevato che il 55% citava lacune tecnologiche o di piattaforma, mentre il 55% citava preoccupazioni di conformità normativa e regolatoria. Il quarantacinque percento temeva che le applicazioni non funzionassero come previsto.

Questi risultati mostrano che la pressione sulla governance va oltre gli account ombra. Le organizzazioni sono preoccupate per prestazioni, affidabilità, conformità e conseguenze sul brand anche all’interno di implementazioni formali.

La quarta cautela riguarda la causalità. L’AI ombra viene spesso descritta come cattiva condotta dei dipendenti, ma le prove disponibili non supportano un unico movente universale.

Alcuni dipendenti ignorano intenzionalmente le regole. Altri incontrano policy poco chiare, strumenti mancanti, approvazioni lente o funzionalità AI integrate in prodotti che l’IT ha già approvato.

Anche i leader possono creare incentivi contraddittori. Richiedono una rapida adozione dell’AI valutando al contempo i team sulla velocità, per poi imporre restrizioni che impediscono ai dipendenti di raggiungere tali obiettivi.

Un’analisi credibile deve tenere insieme entrambi gli aspetti. Gli utenti restano responsabili della gestione delle informazioni sensibili, mentre le organizzazioni restano responsabili dell’offerta di percorsi approvati e praticabili.

Anche le previsioni normative richiedono cautela. Gartner ha previsto che entro il 2030 il 40% delle aziende subirà un incidente di sicurezza o conformità legato all’AI a causa dell’uso non autorizzato di AI ombra.

Come sintetizzato nella copertura della previsione di Gartner, questa cifra riguarda incidenti previsti. Non è un conteggio attuale delle violazioni.

Le previsioni possono identificare l’esposizione, ma non confermano che una determinata organizzazione abbia perso dati. Gli acquirenti dovrebbero evitare di trasformare stime di rischio in affermazioni su attacchi già completati.

La voce incompleta del feed crea un ultimo problema editoriale. Google News è un livello di aggregazione, non l’evidenza sottostante.

Il comunicato diretto, la metodologia e il rapporto completo dovrebbero guidare la formulazione. Finché l’affermazione completa e il denominatore non sono visibili, “quasi la metà” merita attribuzione anziché essere presentato come un fatto universale consolidato.

Questo non rende la storia meno importante. Rende il divario di verifica parte della storia.

Tre segnali indicheranno se le aziende riprenderanno il controllo

La prossima fase sarà misurata dalla visibilità degli account, dal movimento dei dati sensibili e dai permessi concessi agli agenti AI.

Il primo segnale è la quota di attività AI collegata a identità aziendali gestite. Le aziende dovrebbero monitorare se, nel tempo, i dipendenti passano dagli account personali ai servizi approvati.

Una diminuzione della quota di account personali rafforzerebbe l’idea che strumenti aziendali utili possano ridurre l’AI ombra. Una quota stabile o in aumento mostrerebbe che policy e licenze non stanno modificando il comportamento.

Questa metrica dovrebbe essere segmentata per reparto e attività. Sviluppatori, marketer, analisti, team di assistenza e dirigenti utilizzano strumenti diversi e gestiscono informazioni diverse.

Una media aziendale può nascondere un’esposizione concentrata. Un piccolo gruppo può effettuare la maggior parte dei trasferimenti sensibili perché il suo lavoro coinvolge codice, record dei clienti o documenti legali.

Anche la misurazione dell’identità necessita di un denominatore chiaro. Le organizzazioni dovrebbero riportare separatamente utenti, sessioni, trasferimenti e applicazioni.

Il secondo segnale è il tasso di trasferimento di dati sensibili verso i servizi AI. Include testo incollato, caricamenti di file, inserimenti nei moduli, estensioni del browser e richieste API.

Una misura utile distingue tra tentativi bloccati e trasferimenti completati. Separa inoltre gli account aziendali approvati dalle identità personali e sconosciute.

Se i trasferimenti sensibili completati diminuiscono mentre l’uso legittimo dell’AI cresce, la governance sta migliorando. Se aumentano solo i tentativi bloccati, i dipendenti potrebbero semplicemente incontrare maggiore frizione.

I team di sicurezza dovrebbero anche esaminare dove vanno gli utenti dopo un blocco. Un avviso che reindirizza il lavoro verso un assistente approvato è più utile di uno che interrompe il flusso di lavoro.

L’obiettivo sottostante non è produrre un conteggio maggiore di violazioni delle policy. È ridurre l’esposizione non necessaria preservando al contempo il lavoro di valore.

Le organizzazioni possono sostenere questo obiettivo offrendo ai dipendenti modi controllati per cercare, riassumere e collegare i propri materiali. Un secondo cervello locale può limitare la copia ripetuta tra servizi non correlati.

Il terzo segnale è il profilo dei permessi assegnato agli agenti AI. Le aziende necessitano di un inventario che mostri quali sistemi ciascun agente può leggere, scrivere e attivare.

L’accesso in sola lettura presenta un livello di rischio. Il permesso di inviare messaggi, aggiornare record finanziari, modificare codice o approvare transazioni ne presenta un altro.

Le aziende dovrebbero monitorare riduzioni dell’accesso predefinito, periodi di autorizzazione più brevi, log a livello di azione e passaggi di approvazione per i comandi rilevanti.

È qui che la visibilità sulle API diventa decisiva. Un agente agisce spesso tramite API anche quando un utente avvia l’attività in un browser.

I team di sicurezza devono collegare l’identità umana, l’identità dell’agente, la richiesta al modello, la chiamata allo strumento e l’azione aziendale risultante. Un log scollegato per ciascun componente non può ricostruire l’intera decisione.

Il segnale rafforzerà la tesi di Akamai se le aziende scopriranno un gran numero di agenti sconosciuti o permessi eccessivi. Indebolirà la tesi se gli inventari mostreranno accessi limitati, monitorati e intenzionali.

Gli annunci di prodotto meritano meno peso dei dati operativi. I fornitori continueranno a rilasciare gateway AI, browser sicuri, firewall per modelli e sistemi di controllo degli agenti.

La domanda sostanziale è se questi prodotti cambino davvero i comportamenti. Un minore utilizzo di account sconosciuti e meno trasferimenti di dati sensibili costituirebbero prove più solide rispetto ai semplici numeri di implementazione.

I dirigenti dovrebbero inoltre monitorare la soddisfazione dei dipendenti rispetto agli strumenti approvati. Un utilizzo ridotto può indicare controlli efficaci, ma può anche segnalare che i dipendenti hanno smesso del tutto di usare un'AI utile.

Un programma maturo misura sia la sicurezza sia l'utilità. Tra gli esiti rilevanti rientrano il completamento delle attività, l'adozione, i tassi di errore, il tempo di revisione, le eccezioni alle policy e gli incidenti confermati.

La decisione che le aziende devono affrontare non è se i dipendenti useranno l'AI. Questo comportamento si è già diffuso tramite browser, suite software e ambienti di sviluppo.

La decisione è se i sistemi ufficiali diventeranno abbastanza utili da riportare quell'attività in canali visibili. I team di sicurezza non possono governare ciò che non riescono a vedere.

L'avvertimento di Akamai dovrebbe quindi spingere a una verifica diretta. Quali account AI sono attivi, quali informazioni li raggiungono e quali agenti possono agire sui sistemi aziendali?

L'affermazione troncata di Google News richiede ancora la metodologia completa prima che i lettori considerino “quasi la metà” un dato universale. Le evidenze circostanti sostengono già una conclusione più circoscritta.

L'adozione dell'AI nelle aziende ha superato i tradizionali controlli su account e applicazioni. Le organizzazioni che colmeranno questo divario renderanno più semplice il percorso approvato, strumenteranno il browser e limiteranno le autorizzazioni degli agenti.

Iniziate questo mese con un audit pratico. Misurate le sessioni AI gestite rispetto a quelle personali, individuate i trasferimenti di dati sensibili e elencate ogni agente con accesso in scrittura. Queste tre prospettive riveleranno se la governance dell'AI esiste nelle operazioni o soltanto nelle policy.