L'implementazione dell'IA in Malesia sta superando la sicurezza delle identità, avverte ManageEngine

ManageEngine ha lanciato un severo avvertimento attraverso un report di Google News: la Malesia sta distribuendo agenti IA più rapidamente di quanto le aziende riescano a proteggere le proprie identità digitali.

La preoccupazione non riguarda soltanto l'adozione di software poco familiare da parte delle aziende. Ogni agente, flusso di lavoro automatizzato e integrazione macchina richiede credenziali che garantiscano accesso a dati e sistemi aziendali. Queste credenziali possono restare attive molto tempo dopo la conclusione di un progetto.

La Malesia ha già definito quadri normativi nazionali per la cybersicurezza, la privacy e l'IA responsabile. Il conflitto ora si colloca tra questi progressi normativi e la gestione quotidiana degli accessi aziendali. Le organizzazioni possono rispettare principi di governance di alto livello e al contempo concedere a un agente IA privilegi amministrativi permanenti.

Questo divario rende la vicenda più di un'altra storia sull'adozione dell'IA. Solleva una domanda pratica per ogni impresa malese: chi, o che cosa, è attualmente autorizzato ad agire all'interno della sua rete?

Cosa cambia realmente l'avvertimento di ManageEngine

L'avvertimento sposta la governance aziendale dell'IA da una discussione sul rischio dei modelli a un problema di controllo delle identità.

L'originale report sulla sicurezza delle identità è stato pubblicato da Tech Wire Asia il 3 agosto 2026. Si è concentrato su una debolezza facile da trascurare durante una rapida implementazione dell'IA.

Un agente IA non entra nella rete aziendale come un algoritmo astratto. Normalmente riceve un account di servizio, un token, un certificato, una chiave API o un'altra credenziale macchina. Tale identità determina quali applicazioni, record e azioni l'agente può raggiungere.

Jay Reddy di ManageEngine ha dichiarato alla pubblicazione che gli sviluppatori spesso trattano gli agenti autonomi come integrazioni applicative convenzionali. I team possono assegnare permessi amministrativi permanenti o account di servizio con privilegi estesi per evitare ritardi nell'integrazione.

Questa scorciatoia può consentire a un progetto pilota di procedere. Ma crea anche accessi persistenti che non riflettono l'evoluzione del compito dell'agente, del suo livello di rischio o del contesto operativo.

Un agente autonomo differisce da un'integrazione statica perché può pianificare passaggi, richiamare diversi strumenti e rispondere a input variabili. Una credenziale progettata per una singola connessione prevedibile può diventare pericolosa se collegata a software che esegue azioni diverse.

La ricerca di ManageEngine sulla sicurezza delle identità colloca questo problema all'interno di un cambiamento molto più ampio. Le identità non umane includono account di servizio, certificati, bot, workload, segreti applicativi e agenti IA. Stanno diventando la categoria di identità dominante in molti ambienti aziendali.

ManageEngine afferma che nelle organizzazioni intervistate le identità macchina superano comunemente gli utenti umani di oltre 100 a uno. Alcuni settori si stanno avvicinando a un rapporto di 500 a uno.

Queste cifre provengono dal sondaggio di ManageEngine, non da un censimento esclusivamente malese. Non dovrebbero essere interpretate come un rapporto misurato in ogni azienda malese.

La conclusione più ampia resta importante. Un'impresa con diverse migliaia di dipendenti può comunque avere centinaia di migliaia di credenziali macchina distribuite tra servizi cloud, applicazioni interne e piattaforme di automazione.

ManageEngine ha inoltre rilevato che solo il 12% delle organizzazioni intervistate disponeva di una gestione completa e automatizzata del ciclo di vita delle identità macchina. Il restante 88% si affidava a processi manuali o improvvisati, che faticano a funzionare su scala macchina.

La gestione del ciclo di vita comprende la creazione, la modifica, il monitoraggio e il ritiro di un'identità. Dovrebbe rimuovere l'accesso quando un'applicazione viene dismessa, un agente cambia ruolo o una credenziale non è più necessaria.

Senza questo processo, un progetto pilota abbandonato può lasciare dietro di sé un account orfano. L'applicazione può sparire dal dashboard del progetto mentre il suo token di accesso rimane valido.

Il problema va oltre le credenziali dimenticate. Un agente IA attivo può ereditare più accessi di quanti ne richieda il suo compito, soprattutto quando i team di implementazione privilegiano la velocità.

Il principio del privilegio minimo consiste nel concedere soltanto gli accessi necessari per una funzione definita. Diventa più difficile da applicare quando un agente deve completare più passaggi tra email, archivi documentali, record dei clienti e database interni.

Un titolo di Google News sulla “sicurezza delle identità” può quindi sembrare più circoscritto della questione sottostante. L'avvertimento riguarda gli acquisti, lo sviluppo software, la governance dei dati, l'architettura cloud e la risposta agli incidenti.

Il cambiamento immediato è concettuale. Le aziende devono smettere di trattare gli agenti IA solo come prodotti da approvare e iniziare a trattarli come identità da governare.

Perché Google News sta evidenziando il rischio proprio ora

Le ambizioni nazionali della Malesia sull'IA stanno entrando in una fase operativa, mentre molti programmi di gestione delle identità riflettono ancora un modello di sicurezza incentrato sulle persone.

La Malesia non si avvicina all'IA senza un quadro normativo. Il Paese ha pubblicato le sue Linee guida nazionali sulla governance e l'etica dell'IA il 20 settembre 2024.

Le linee guida stabiliscono sette principi che coprono equità, affidabilità, privacy, sicurezza, trasparenza, responsabilità, inclusione e beneficio umano. Si applicano all'intero ciclo di vita dei sistemi IA.

Il National AI Office della Malesia descrive tali linee guida come volontarie. Le sue più recenti risorse sulla governance dell'IA intendono aiutare le organizzazioni a tradurre i principi in pratiche operative.

Il governo sta inoltre sviluppando il National AI Action Plan 2026–2030 nell'ambito della sua direzione AI Nation 2030. Si prevede che il piano affronti adozione, infrastrutture, talenti, governance e partecipazione industriale.

Ciò crea slancio sia per le organizzazioni pubbliche sia per quelle private. I consigli di amministrazione vogliono implementazioni utili, i dipartimenti vogliono guadagni di produttività e i team tecnici subiscono pressioni per portare i progetti pilota in produzione.

Tuttavia, la governance dell'IA a livello normativo e la governance operativa delle identità risolvono parti diverse del problema.

Un quadro etico può richiedere responsabilità, privacy e sicurezza. Non rileva automaticamente una chiave API non documentata né revoca l'accesso di un agente al termine di un progetto pilota.

Il National AI Office della Malesia riconosce indirettamente questa distinzione. Le sue linee guida coprono implementazione, monitoraggio e dismissione, non solo lo sviluppo dei modelli.

Questa prospettiva sul ciclo di vita è essenziale. Un agente può soddisfare i criteri di approvazione iniziali di un'organizzazione e diventare in seguito rischioso perché cambiano i suoi permessi, gli strumenti collegati o le istruzioni operative.

La Malesia dispone inoltre di norme vincolanti sulla cybersicurezza in ambiti specifici. Il Cyber Security Act è stato pubblicato nella gazzetta ufficiale il 26 giugno 2024 ed è entrato in vigore il 26 agosto 2024.

La legge stabilisce obblighi relativi alla National Critical Information Infrastructure, nota come NCII. Affronta inoltre gli incidenti informatici, le responsabilità settoriali e le licenze per alcuni fornitori di servizi di cybersicurezza.

La legge rafforza la struttura nazionale di cybersicurezza della Malesia. Tuttavia, non elimina la necessità per ogni impresa di mantenere inventari interni accurati e controlli di accesso.

Anche gli obblighi in materia di privacy si stanno inasprendo. Le modifiche al PDPA della Malesia hanno introdotto cambiamenti che includono la notifica delle violazioni e responsabilità in materia di protezione dei dati.

Queste regole aumentano le conseguenze di una debole governance delle credenziali. Un agente con accessi eccessivi può trasformare un singolo token compromesso in un'esposizione attraverso diversi sistemi di dati.

La pressione che ne deriva ricade anzitutto sui responsabili della sicurezza informatica, sui team delle identità, sugli amministratori cloud e sui proprietari delle applicazioni. Devono supportare implementazioni più rapide senza perdere visibilità.

Raggiunge anche i consigli di amministrazione. I dirigenti senior non possono supervisionare il rischio dell'IA se l'organizzazione non riesce a elencare i propri agenti, i loro responsabili, le loro credenziali e le azioni loro consentite.

L'attuale orientamento normativo della Malesia incoraggia un'adozione responsabile, ma gran parte delle sue linee guida dedicate all'IA rimane non vincolante. Le aziende mantengono la responsabilità di tradurre principi generali in controlli tecnici.

Ecco perché questa storia emerge ora. L'adozione dell'IA ha superato le dimostrazioni isolate, mentre l'architettura di sicurezza alla base di molte implementazioni non è avanzata allo stesso ritmo.

I commenti di ManageEngine sulla governance dell'IA descrivono l'IA sia come fonte di crescita delle identità sia come potenziale aiuto per i team di sicurezza. Questo duplice ruolo complica la risposta.

Le organizzazioni vogliono che l'IA rilevi comportamenti rischiosi, esamini gli accessi e riduca il lavoro manuale. Allo stesso tempo, ogni componente IA difensivo può introdurre ulteriori credenziali e integrazioni che richiedono governance.

Questo ciclo può produrre strumenti di sicurezza che ampliano proprio il patrimonio di identità che dovrebbero controllare. Consolidamento e automazione diventano necessari, ma richiedono anche un'implementazione accurata.

La vera pressione, dunque, non è rallentare ogni progetto IA. È fare in modo che i controlli delle identità operino alla velocità e alla scala di tali progetti.

Agenti IA contro la sicurezza delle identità incentrata sulle persone

Il conflitto centrale delle aziende malesi è tra la velocità di implementazione dell'IA e un'architettura delle identità costruita attorno ai dipendenti e alle applicazioni prevedibili.

La gestione tradizionale delle identità e degli accessi inizia con eventi umani riconoscibili. Una persona entra in un'azienda, cambia ruolo, richiede accesso e alla fine la lascia.

Questi eventi possono attivare flussi di lavoro che coinvolgono risorse umane, responsabili e amministratori IT. La titolarità è di solito visibile, anche quando l'esecuzione è imperfetta.

Le identità macchina non seguono questo schema. Uno sviluppatore può creare più account di servizio durante un singolo progetto, mentre le piattaforme cloud generano credenziali attraverso processi di infrastruttura automatizzati.

Gli agenti IA aggiungono un ulteriore livello. Un singolo agente può ricevere accesso a un modello linguistico, documenti interni, un sistema di ticketing, record dei clienti e strumenti di comunicazione.

Il suo ruolo può anche cambiare senza un trasferimento formale. Nuove istruzioni o integrazioni possono ampliare la sua autorità effettiva anche quando il suo account originario resta invariato.

Per questo un semplice elenco di account utente non è più sufficiente. I team di sicurezza devono comprendere le relazioni tra agenti, credenziali, strumenti, dati, responsabili e comportamento effettivo.

L'Identity Security Outlook 2026 di ManageEngine ha rilevato un significativo divario di percezione. Secondo i suoi risultati del sondaggio, l'80% dei dirigenti senior riteneva che gli account macchina inattivi fossero monitorati.

Appena la metà dei professionisti ha confermato tale fiducia. La differenza suggerisce che i dirigenti possono credere che un controllo esista anche quando i team in prima linea riscontrano una copertura incompleta.

Lo stesso studio ha rilevato che nove organizzazioni intervistate su dieci stavano sperimentando o utilizzando l'IA nella gestione delle identità e degli accessi. Solo il 7% ha segnalato un'implementazione a livello dell'intera organizzazione.

Questo divario è importante perché progetti pilota limitati non dimostrano che la sicurezza assistita dall'IA funzioni su directory legacy, piattaforme cloud e migliaia di account macchina.

Anche le aspettative dei dirigenti superavano la fiducia operativa. ManageEngine ha riportato che il 68% degli intervistati C-suite era ottimista sull'IA per la modellazione e l'analisi del rischio delle identità.

Solo il 27% dei manager considerava pratico tale utilizzo. Il sondaggio non dimostra che uno dei due gruppi abbia ragione, ma mette in luce un problema di implementazione che la sola approvazione del budget non può risolvere.

La ricerca di ManageEngine sulla sicurezza delle identità indica inoltre un consolidamento delle piattaforme. Più dell'80% dei responsabili della sicurezza intervistati stava consolidando strumenti di identità frammentati in piattaforme unificate.

Il consolidamento può ridurre i punti ciechi quando sistemi separati gestiscono l'accesso della forza lavoro, gli account privilegiati, i diritti cloud, i certificati e i segreti applicativi. Può inoltre offrire un livello di policy condiviso.

Tuttavia, l'acquisto di una piattaforma unificata non crea automaticamente un inventario accurato delle identità. Le organizzazioni devono comunque identificare i responsabili, definire comportamenti accettabili e connettere ogni ambiente pertinente.

Questo è il principale antagonista della vicenda: una rapida adozione dell'AI contrapposta a operazioni di gestione delle identità incentrate sulle persone.

Il conflitto non è ManageEngine contro un altro fornitore. Microsoft, CyberArk, Okta, SailPoint e i provider cloud affrontano tutti parti del crescente problema delle identità attraverso prodotti diversi.

Gli approcci variano, ma la direzione del settore è simile. I programmi di gestione delle identità si stanno estendendo dall'autenticazione dei dipendenti all'accesso dei workload, alle credenziali macchina e all'autorizzazione continua.

L'autorizzazione continua significa che le decisioni di accesso possono essere rivalutate al cambiare del contesto. Un sistema potrebbe considerare l'azione richiesta, la sensibilità dei dati, il comportamento delle credenziali e il rischio corrente.

Questo approccio è più adatto al software autonomo rispetto a un'autorizzazione permanente assegnata una sola volta. Un agente che elabora fatture a mezzogiorno non ha necessariamente bisogno dello stesso accesso quando è inattivo a mezzanotte.

Le credenziali a breve durata offrono un'altra risposta. Scadono rapidamente e possono limitare il valore di un segreto rubato.

L'accesso just-in-time concede privilegi più elevati solo quando un'attività specifica li richiede. Riduce l'accesso permanente disponibile agli aggressori o agli agenti malfunzionanti.

Questi controlli non sono nuovi. La sfida consiste nell'applicarli con coerenza a workflow AI creati rapidamente, senza trasformare la revisione della sicurezza in un collo di bottiglia inutilizzabile.

Un agente aziendale reale può riassumere documenti interni, redigere una risposta e aggiornare un sistema cliente. Ogni azione può attraversare un diverso confine di sicurezza.

Se l'agente riceve un unico e ampio account di servizio, gli investigatori potrebbero faticare a stabilire quale azione provenga dall'agente, da uno sviluppatore o da un'altra applicazione che condivide quell'identità.

Identità dedicate e registri dettagliati migliorano l'attribuzione. Aumentano però anche il numero totale di identità che i team devono gestire.

Questo compromesso spiega perché i processi manuali di gestione delle identità collassano su larga scala. Una migliore responsabilizzazione crea più oggetti da monitorare, mentre un minor numero di account condivisi può significare molte più credenziali individuali.

Le imprese hanno bisogno dell'automazione, ma l'automazione deve seguire policy verificate. Altrimenti, può replicare autorizzazioni eccessive più rapidamente di quanto potrebbe mai fare un amministratore umano.

Cosa non dimostra l'affermazione di ManageEngine sulla governance dell'AI

L'avvertimento individua un rischio strutturale credibile, ma non dimostra che le imprese malesi condividano un unico e uniforme fallimento della sicurezza.

La cifra più appariscente è il possibile rapporto di 500 a uno tra identità non umane e umane. I lettori dovrebbero trattarla con cautela.

ManageEngine afferma che alcuni settori analizzati si avvicinano a tale rapporto. L'azienda non sostiene che ogni organizzazione malese abbia misurato lo stesso livello.

L'articolo di Tech Wire Asia applica risultati globali sulle identità al contesto di adozione della Malesia. Aggiunge un'intervista regionale informata, ma non è un audit nazionale delle credenziali malesi.

Questa distinzione conta perché i settori dispongono di infrastrutture tecnologiche molto diverse. Un provider cloud, una banca, un produttore, un ospedale e un piccolo rivenditore non creeranno identità macchina allo stesso ritmo.

Anche le definizioni possono modificare il conteggio. Alcuni studi includono certificati, chiavi, workload, bot, account di servizio e identità applicative come oggetti distinti.

Altri si concentrano sugli account in grado di autenticarsi direttamente. Confrontare i rapporti senza allineare le definizioni può esagerare le differenze apparenti.

ManageEngine vende anche prodotti per identità e sicurezza. La sua ricerca può comunque offrire prove utili, ma la sua posizione commerciale dovrebbe rimanere visibile.

Le conclusioni più solide derivano da risultati coerenti con un'architettura osservabile. Gli agenti AI necessitano di credenziali, i privilegi permanenti aumentano l'esposizione e gli account abbandonati creano rischi.

La conclusione più debole sarebbe che un rapporto specifico descriva la Malesia nel suo insieme. Le prove disponibili non supportano tale affermazione.

Le raccomandazioni di ManageEngine per la governance dell'AI favoriscono inoltre il consolidamento. Una piattaforma unificata può ridurre la frammentazione, ma la centralizzazione introduce un proprio rischio di concentrazione.

Se un unico piano di controllo delle identità è configurato in modo errato o viene compromesso, l'impatto può diffondersi ampiamente. Le organizzazioni hanno bisogno di resilienza, separazione dei compiti e logging indipendente attorno ai sistemi centralizzati.

L'analisi delle identità assistita dall'AI presenta un'altra incertezza. Un algoritmo può segnalare modelli di accesso insoliti, ma può anche produrre falsi positivi o non rilevare comportamenti simili all'automazione legittima.

I team di sicurezza devono capire quali decisioni siano consultive e quali attivino un'applicazione automatica. Bloccare un agente critico sulla base di un segnale debole può interrompere le operazioni.

Al contrario, consentire a un sistema AI di approvare accessi senza revisione umana può ricreare lo stesso problema dei privilegi eccessivi sotto una nuova etichetta.

Esiste inoltre un confine di governance tra un agente AI e il modello che lo supporta. Gli strumenti e le credenziali dell'agente determinano ciò che può fare, mentre il modello influenza il modo in cui sceglie le azioni.

Un'azienda potrebbe effettuare test sul modello ma trascurare l'ambito delle credenziali. Un'altra potrebbe limitare i permessi senza monitorare istruzioni non sicure o input manipolati.

La prompt injection illustra questa sovrapposizione. Si verifica quando contenuti dannosi tentano di reindirizzare il comportamento di un sistema AI attraverso istruzioni nascoste nei dati che elabora.

Un agente con accesso in sola lettura può esporre informazioni dopo una prompt injection. Un agente con privilegi eccessivi può anche modificare record, inviare messaggi o richiamare strumenti amministrativi.

La governance delle identità non può prevenire ogni attacco di prompt injection. Può limitarne i danni restringendo ciò che l'agente compromesso è autorizzato a fare.

Questo rende il privilegio minimo una misura di contenimento, non la prova di una sicurezza AI completa. Restano necessari valutazione del modello, controlli sui dati, monitoraggio e risposta agli incidenti.

Le linee guida volontarie della Malesia sull'AI presentano limiti simili. Offrono a consigli di amministrazione e team un vocabolario comune, ma le organizzazioni devono tradurlo in policy tecniche applicabili.

Le leggi del Paese sulla cybersicurezza e sulla privacy creano obblighi più solidi nei rispettivi ambiti. Tuttavia, la conformità dopo una violazione non sostituisce la prevenzione di accessi non necessari.

Le imprese dovrebbero inoltre resistere a una falsa scelta tra adozione rapida e controllo rigoroso. Una lunga approvazione manuale per ogni agente può spingere i dipendenti verso strumenti non autorizzati.

Shadow AI indica servizi AI utilizzati senza un'approvazione formale dell'organizzazione. Può spostare dati oltre i sistemi approvati e creare identità che i team di sicurezza non vedono mai.

Un programma praticabile deve rendere l'implementazione sicura più facile da trovare e utilizzare. Modelli di credenziali standard, connettori approvati, scadenze automatizzate e una chiara titolarità possono ridurre l'attrito.

È qui che contano anche le pratiche di gestione della conoscenza. I team necessitano di registri accessibili su chi ha approvato un agente, quali sistemi può raggiungere e perché tali autorizzazioni restano necessarie.

Una base di conoscenza tecnica ricercabile può supportare le revisioni, anche se la sola documentazione non può applicare policy di accesso.

Una lettura scettica non invalida l'avvertimento di ManageEngine. Restringe l'affermazione a ciò che le prove supportano.

La Malesia presenta un rischio plausibile e crescente legato alle identità macchina. Le fonti disponibili non stabiliscono un unico tasso di esposizione nazionale né dimostrano che il solo consolidamento delle piattaforme lo risolverà.

I tre segnali da osservare dopo questo report di Google News

La fase successiva sarà misurata attraverso inventari delle identità, cicli di vita degli accessi applicabili e prove che i consigli di amministrazione possano vedere gli stessi rischi dei professionisti.

Il primo segnale è se le organizzazioni malesi inizieranno a riportare inventari completi di agenti AI e identità non umane.

Un inventario dovrebbe collegare ogni identità a un responsabile, uno scopo aziendale, un ambiente, un tipo di credenziale, dati accessibili e una policy di scadenza. Contare gli account senza queste relazioni offre una protezione limitata.

Questo segnale rafforzerebbe l'avvertimento di ManageEngine se le aziende scoprissero un gran numero di credenziali orfane o condivise durante le revisioni. Indebolirebbe l'interpretazione più severa se gli inventari mostrassero una chiara titolarità e privilegi limitati.

Il processo dovrebbe includere gli agenti creati dai team tecnologici centrali e quelli assemblati nei singoli dipartimenti. Gli strumenti low-code possono consentire agli utenti aziendali di implementare automazioni senza i tradizionali controlli di rilascio del software.

I consigli di amministrazione non hanno bisogno di un elenco di ogni token. Hanno bisogno di metriche affidabili che mostrino quante identità di agenti esistono, quante sono prive di responsabile e quante mantengono privilegi permanenti.

Il secondo segnale è l'adozione di cicli di vita delle identità automatizzati e applicabili per gli agenti AI.

Le organizzazioni dovrebbero poter rilasciare credenziali a breve durata, limitare gli strumenti, riesaminare i comportamenti e revocare l'accesso quando cambia un workflow. La dismissione deve rimuovere i segreti e gli account di servizio associati.

La parola chiave è applicabili. Un documento di policy che afferma che gli agenti dovrebbero usare il privilegio minimo non impedisce a un amministratore di rilasciare un token permanente con un ambito molto ampio.

Le prove di scadenza automatizzata e privilegi just-in-time rafforzerebbero l'idea che l'architettura di sicurezza stia recuperando terreno. La continua dipendenza da fogli di calcolo manuali sosterrebbe le preoccupazioni di ManageEngine.

Questo segnale mette inoltre alla prova le affermazioni dei fornitori. Le piattaforme di gestione delle identità dovrebbero dimostrare copertura tra servizi cloud, directory interne, certificati, segreti applicativi e framework per agenti.

Una dashboard che mostra solo gli utenti della forza lavoro non risolverà il problema delle identità macchina. Nemmeno un assistente AI che raccomanda modifiche ma non può implementarle o verificarle in sicurezza.

Le imprese dovrebbero misurare sia la prevenzione sia il recupero. Devono sapere con quale rapidità possono disabilitare un agente, ruotare le credenziali correlate e ricostruirne le azioni recenti.

Il terzo segnale è se la Malesia trasformerà i principi nazionali sull'AI in requisiti di responsabilità più specifici.

Il National AI Office afferma che la Malesia non dispone ancora di una legge dedicata all'AI. Osserva inoltre che è allo studio un AI Governance Bill.

Le future policy potrebbero chiarire le responsabilità per chi implementa l'AI, la valutazione dei rischi, la documentazione, i test di sicurezza e il monitoraggio continuo. Anche le autorità di regolamentazione settoriali potrebbero emanare requisiti prima dell'arrivo di una legge generale.

Nuove norme rafforzerebbero il giudizio centrale dell'articolo se affrontassero esplicitamente identità degli agenti, accesso e dismissione. Un linguaggio etico generale privo di requisiti operativi lascerebbe il divario aziendale in gran parte immutato.

Lo sviluppo normativo non dovrebbe essere misurato soltanto in base all'approvazione, da parte del Parlamento, di un'unica legge sull'AI. L'applicazione delle norme sulla privacy, gli obblighi NCII, le regole sugli appalti e le linee guida settoriali possono tutti modellare le pratiche di gestione delle identità.

I servizi finanziari e gli operatori di infrastrutture critiche probabilmente subiranno il controllo più ravvicinato. I loro agenti possono interagire con record sensibili e sistemi operativi, dove autorizzazioni eccessive comportano conseguenze maggiori.

La risposta dei consigli di amministrazione merita uguale attenzione. Il National AI Office della Malesia ha pubblicato linee guida volontarie pensate per aiutare i direttori a supervisionare l'adozione dell'AI.

I consigli di amministrazione dovrebbero chiedere se l'organizzazione possa fermare immediatamente un agente, non soltanto se abbia approvato il business case iniziale. Dovrebbero inoltre chiedere chi riesamina gli accessi dopo che la funzione dell'agente cambia.

Queste domande collegano la responsabilità di alto livello con prove tecniche. Espongono inoltre il divario tra la fiducia dei dirigenti e la visibilità dei professionisti rilevato nel sondaggio di ManageEngine.

Per gli sviluppatori, la lezione è chiara. Le credenziali fanno parte dell’architettura di un agente, non sono un dettaglio di distribuzione da riconsiderare dopo il lancio.

Per gli acquirenti aziendali, la copertura dell’identità dovrebbe essere valutata insieme all’accuratezza del modello e alle funzionalità del flusso di lavoro. Un agente utile con un’autorità non tracciabile crea una passività operativa.

Per i knowledge worker, la questione riguarda quali documenti e sistemi un assistente possa raggiungere. La praticità aumenta quando gli strumenti si collegano ampiamente, ma cresce anche l’impatto di un’azione errata o manipolata.

L’inquadramento di Google News svanirà quando un altro titolo prenderà il suo posto. Il problema di fondo legato all’identità persisterà, perché ogni nuova azione automatizzata comporta una decisione di autorizzazione.

La Malesia ha già definito una direzione politica incentrata su IA responsabile, cybersicurezza e privacy. La prossima prova sarà capire se le organizzazioni riusciranno a rendere visibili questi principi nelle credenziali, nei log e nei controlli di revoca.

L’avvertimento di ManageEngine dovrebbe quindi essere valutato sulla base di evidenze operative nei prossimi mesi. Le imprese stanno trovando account di agenti abbandonati? Stanno sostituendo i privilegi permanenti? Possono dimostrare chi possiede ciascuna identità macchina?

Le risposte mostreranno se l’architettura di sicurezza della Malesia sta raggiungendo le sue ambizioni nell’IA.

Prima di approvare la prossima distribuzione di un agente, ponetevi una domanda concreta: se questo sistema si comportasse in modo inatteso stanotte, la vostra organizzazione riuscirebbe a identificare le sue credenziali e a rimuovere ogni autorizzazione prima del mattino?