Gli agenti AI autonomi hanno bisogno di un nuovo modello di governance

Google News ha evidenziato un titolo di SiliconANGLE con un avvertimento diretto: gli attori AI autonomi necessitano di una governance progettata per software in grado di compiere azioni con conseguenze rilevanti.

Questa distinzione è importante perché un agente AI fa più che generare una risposta. Può recuperare file, chiamare strumenti, eseguire codice, aggiornare record e comunicare con altri sistemi. Queste capacità trasformano un output inaffidabile in un'azione potenzialmente non autorizzata.

Il titolo coglie un conflitto che oggi riguarda i responsabili tecnologici aziendali. Le aziende vogliono agenti che operino con minore supervisione, ma molti controlli di sicurezza presuppongono ancora che un essere umano avvii ogni azione importante.

Autorità di regolamentazione, organismi di standardizzazione e fornitori di sicurezza hanno iniziato a colmare questa lacuna. La loro risposta emergente combina identità univoche per gli agenti, autorizzazioni limitate, monitoraggio continuo, punti di approvazione umana e meccanismi di recupero.

La questione centrale non è più se un modello produca una frase inaccurata. È se un'organizzazione possa identificare, contenere, spiegare e annullare le azioni di un agente prima che un errore si propaghi.

Il titolo di Google News indica un cambiamento più ampio nella governance

La governance dell'AI sta passando dalla supervisione degli output dei modelli al controllo di attori software dotati di identità, autorizzazioni, strumenti e responsabilità operative.

La governance tradizionale dell'AI generativa si è concentrata soprattutto sui dati di addestramento, sui contenuti dannosi, sulla valutazione dei modelli e sull'accuratezza delle risposte generate. Queste preoccupazioni restano importanti, ma gli agenti autonomi introducono un problema operativo diverso.

Un agente AI può perseguire un obiettivo attraverso una sequenza di decisioni. Può scegliere strumenti, leggere informazioni in evoluzione, rivedere un piano e avviare azioni senza chiedere approvazione a ogni passaggio.

Questo comportamento crea una catena più lunga tra l'istruzione originale dell'utente e il risultato finale. Ogni passaggio aggiuntivo introduce un ulteriore punto in cui intenzione, contesto o autorità possono deviare.

Si consideri un dipendente che chiede a un agente di preparare documenti per il rinnovo dei clienti. Un chatbot potrebbe redigere il testo e attendere. Un agente autonomo potrebbe recuperare record degli account, selezionare modelli, modificare un contratto e inviare il pacchetto.

Queste azioni coinvolgono diversi sistemi e molteplici confini di autorizzazione. Un'istruzione vaga o un documento avvelenato può influenzare l'intera sequenza.

L'elemento di Google News è quindi più di un altro avvertimento sull'AI inaccurata. Riflette un cambiamento strutturale nel modo in cui il software opera all'interno delle organizzazioni.

I servizi software utilizzano da tempo identità macchina. Tuttavia, tali servizi svolgono solitamente funzioni prevedibili entro confini tecnici ristretti.

Un agente AI può interpretare obiettivi ambigui e scegliere tra diverse azioni possibili. Il suo comportamento dipende da prompt, dati recuperati, memoria, output del modello, strumenti disponibili e condizioni ambientali in evoluzione.

Questo rende l'agente né un normale dipendente né un servizio software convenzionale. Le imprese devono comunque assegnargli un responsabile, definirne l'autorità e conservare prove della sua attività.

Questa responsabilità non può rimanere implicita. Se più team distribuiscono agenti attraverso piattaforme diverse, i responsabili della sicurezza hanno bisogno di un inventario completo che mostri dove tali agenti operano e a cosa possono accedere.

AppViewX ha illustrato questa categoria di prodotto emergente quando ha introdotto una piattaforma di identità per agenti. L'azienda afferma che il suo sistema rileva gli agenti, ne mappa le autorizzazioni e ne monitora il comportamento.

Il prodotto è stato rilasciato come anteprima privata per imprese qualificate. Le sue affermazioni richiedono ancora una convalida su implementazioni reali, ma il suo design riflette la direzione del mercato.

Il cambiamento importante è concettuale. Le imprese stanno iniziando a trattare ciascun agente come un attore soggetto a governance, anziché come una funzionalità invisibile all'interno di un'applicazione.

Questo cambiamento crea la tensione centrale dell'articolo. Più un agente diventa utile, maggiore è di solito l'accesso di cui necessita. Ogni autorizzazione aggiuntiva amplia inoltre il danno possibile dopo manipolazione, errore o compromissione delle credenziali.

La capacità autonoma non coincide con il potere autorizzato

La capacità tecnica di un agente non dovrebbe mai determinare ciò che l'organizzazione gli consente di fare.

Gli sviluppatori misurano spesso gli agenti attraverso tassi di completamento, test di ragionamento o benchmark sull'uso degli strumenti. Queste valutazioni descrivono le capacità, ma non rispondono alla domanda se un agente debba ricevere autorità operativa.

Un agente di coding potrebbe essere in grado di modificare un intero repository. Questo non significa che debba unire modifiche in produzione senza revisione.

Un agente finanziario potrebbe generare una valida istruzione di pagamento. Questo non significa che debba trasferire fondi oltre una soglia definita.

La governance deve separare ciò che un agente può realizzare da ciò che è autorizzato a eseguire. Questa separazione diventa essenziale quando un modello supporta molti agenti con responsabilità diverse.

Lo stesso modello sottostante potrebbe alimentare un assistente di ricerca, un agente di assistenza clienti e un operatore infrastrutturale. Le loro autorizzazioni dovrebbero differire perché le conseguenze delle loro azioni sono diverse.

Le organizzazioni applicano già un ragionamento analogo ai dipendenti e ai servizi software. Un addetto all'assistenza clienti non riceve accesso illimitato al database solo perché comprende le query di database.

Gli agenti hanno bisogno dello stesso principio, implementato attraverso controlli tecnici. Le autorizzazioni dovrebbero riflettere un'attività definita, un responsabile aziendale, un ambiente e un impatto accettabile.

NIST ha posto identità e autorizzazione al centro della propria iniziativa sugli standard per gli agenti, annunciata il 17 febbraio 2026. L'iniziativa si concentra su standard, protocolli aperti, ricerca sulla sicurezza e interoperabilità affidabile.

NIST ha inoltre descritto agenti in grado di scrivere codice, gestire comunicazioni e acquistare beni. Questi esempi mostrano perché le politiche di sicurezza a livello di modello non possono governare ogni azione risultante.

Un agente che opera tra più applicazioni necessita di un'identità verificabile. Ogni sistema ricevente deve sapere quale agente sta richiedendo l'accesso e per conto di chi agisce.

Tale identità dovrebbe essere collegata a una persona responsabile o a un'unità organizzativa. Altrimenti, un registro di audit può mostrare che un'azione è avvenuta senza stabilire chi abbia autorizzato l'attore.

L'autorizzazione deve inoltre considerare la delega. Un agente potrebbe creare un sotto-agente specializzato o chiamare un altro agente gestito da un fornitore esterno.

Una semplice credenziale utente non rappresenta questa catena. L'organizzazione ha bisogno di prove che descrivano la richiesta originale, l'autorità delegata, gli attori intermedi e l'azione finale.

È qui che i familiari strumenti di identità restano utili ma incompleti. L'autenticazione può verificare chi presenta una credenziale. Non stabilisce automaticamente se un'azione sensibile al contesto corrisponda allo scopo assegnato all'agente.

Un agente di approvvigionamento autenticato potrebbe comunque utilizzare impropriamente un valido strumento di acquisto. Un'istruzione compromessa potrebbe indirizzarlo verso un fornitore non autorizzato mentre ogni credenziale rimane tecnicamente valida.

La governance degli agenti necessita quindi di un'autorizzazione consapevole dell'attività. Il sistema deve valutare l'azione richiesta rispetto al ruolo dell'agente, all'obiettivo corrente, alla sensibilità dei dati e al potenziale impatto.

Le credenziali di breve durata possono ridurre l'esposizione. Ambiti limitati degli strumenti possono impedire a un agente di utilizzare funzioni non pertinenti al suo incarico.

Le organizzazioni dovrebbero inoltre separare l'accesso in lettura dall'autorità di azione. Un agente che necessita di dati sulle fatture per l'analisi non ha necessariamente bisogno dell'autorizzazione per approvare o pagare le fatture.

Questi controlli introducono attrito, ma l'autonomia indiscriminata non è l'alternativa utile. L'obiettivo migliore è un'autonomia proporzionata, in cui la supervisione diminuisce solo dopo che le prove supportano tale decisione.

I controlli di accesso statici non possono governare intenzioni mutevoli

Gli agenti AI richiedono controlli in fase di esecuzione perché credenziali valide non garantiscono un comportamento valido.

I sistemi di accesso tradizionali chiedono solitamente se un utente o un servizio possa raggiungere una risorsa. La governance degli agenti deve anche chiedere cosa l'attore intenda fare e se quell'azione rimanga entro il suo obiettivo assegnato.

Questa differenza diventa evidente quando un agente elabora contenuti non attendibili. Un documento, un'email, un sito web o la risposta di uno strumento potrebbe contenere istruzioni in conflitto con la richiesta dell'utente.

La prompt injection è un attacco che inserisce istruzioni dannose nei contenuti elaborati da un sistema AI. L'agente può scambiare tali istruzioni per indicazioni legittime.

Un agente di ricerca potrebbe leggere una pagina web che gli ordina di divulgare informazioni archiviate. Un agente di assistenza potrebbe incontrare un messaggio che lo indirizza a ignorare le regole di verifica dei clienti.

Il modello può rimanere tecnicamente funzionante pur seguendo l'istruzione sbagliata. La sola autenticazione non fermerà il comportamento perché l'agente presenta ancora un'identità valida.

L'elenco dei rischi agentici di OWASP identifica dirottamento degli obiettivi, uso improprio degli strumenti, abuso dei privilegi, avvelenamento della memoria e debolezze della catena di fornitura tra le principali preoccupazioni.

L'elenco ha raccolto contributi da oltre 100 ricercatori di sicurezza, professionisti, organizzazioni utenti e fornitori tecnologici. Riflette un cambiamento importante nel modo di pensare alla sicurezza.

I difensori non possono valutare solo il modello. Devono esaminare l'intero sistema dell'agente, inclusi prompt, memoria, strumenti, connettori, credenziali, logica di orchestrazione e comunicazioni esterne.

L'applicazione delle policy in fase di esecuzione offre una risposta. Valuta un'azione mentre l'agente è operativo, invece di fare affidamento interamente su regole stabilite durante la distribuzione.

Un livello di policy potrebbe consentire a un agente di approvvigionamento di preparare un ordine, ma richiedere l'approvazione prima dell'invio. Potrebbe impedire allo stesso agente di modificare i dati bancari del fornitore.

La decisione può dipendere anche dalla reversibilità. Redigere un invito in calendario è facile da annullare. Eliminare dati di produzione comporta un onere di recupero molto diverso.

Le azioni ad alto impatto necessitano di punti di controllo più rigorosi. Possono includere conferma umana, un secondo verificatore automatizzato, limiti di transazione o l'esecuzione in un ambiente isolato.

Tuttavia, l'approvazione umana non è automaticamente significativa. Un revisore non può prendere una decisione informata dopo aver ricevuto una richiesta di conferma priva di spiegazioni, contenente solo un pulsante di approvazione.

Il sistema dovrebbe presentare l'azione proposta, le risorse interessate, le prove a supporto e le conseguenze previste. Dovrebbe inoltre comunicare incertezze o informazioni contrastanti.

La memoria aggiunge un'altra complicazione. La memoria dell'agente conserva fatti o interazioni passate per un uso successivo, consentendo al comportamento di persistere tra le sessioni.

Questa persistenza può migliorare la continuità, ma può anche conservare informazioni false o dannose. Una voce di memoria avvelenata potrebbe influenzare le decisioni molto tempo dopo la scomparsa dell'attacco originale.

Le organizzazioni necessitano di controlli su chi può scrivere nella memoria, su come le voci ricevono la provenienza e su quando il vecchio contesto scade. Anche gli archivi di memoria sensibili richiedono la stessa disciplina di accesso degli altri dati aziendali.

Questo è importante per i sistemi di conoscenza interni. Una base di conoscenza ricercabile diventa parte dell'ambiente decisionale dell'agente quando viene collegata tramite strumenti di recupero.

Le autorizzazioni devono rispettare i documenti sottostanti. La connessione di un agente non dovrebbe appiattire i controlli di accesso né esporre informazioni che l'utente richiedente non può normalmente visualizzare.

Il titolo di Google News presenta questi sistemi come attori autonomi, ma l'autonomia dovrebbe restare condizionata. Ogni azione significativa necessita di un percorso delimitato dall'autorità all'esecuzione.

La vera sfida è tra autonomia e responsabilità

Le imprese non stanno scegliendo tra agenti utili e agenti sicuri; stanno decidendo se l'autonomia possa restare responsabile alla velocità operativa.

L'argomento più forte a favore degli agenti autonomi è l'efficienza. Possono coordinare attività ripetitive, operare in modo continuo e ridurre i ritardi tra analisi ed esecuzione.

L'obiezione più forte riguarda il raggio d'impatto. Un agente veloce può ripetere una cattiva azione su molti record, sistemi o clienti prima che una persona se ne accorga.

Questo rischio aumenta quando un agente dispone di credenziali ampie. Aumenta ulteriormente quando l'agente può delegare lavoro o modificare il contesto utilizzato da agenti successivi.

I fornitori di sicurezza stanno rispondendo da direzioni diverse. Gli specialisti dell'identità puntano su identità crittografiche e privilegi limitati. Le aziende di data security enfatizzano monitoraggio, ripristino e protezione delle informazioni sensibili.

I fornitori di cloud security si concentrano sulle connessioni tra agenti, applicazioni e dati. I fornitori di piattaforme per agenti spesso sottolineano valutazione, definizione delle policy e controlli per gli sviluppatori.

Questi approcci si sovrappongono, ma nessuno risolve da solo il problema. Un'identità verificata non impedisce la manipolazione degli obiettivi, mentre il monitoraggio comportamentale non stabilisce chi abbia concesso l'autorità.

Allo stesso modo, un passaggio di approvazione umana non può rimediare alla mancanza di record di audit. Uno strumento di rollback non può annullare ogni conseguenza fisica, finanziaria o reputazionale.

L'Infocomm Media Development Authority di Singapore ha pubblicato il suo quadro di governance per gli agenti il 22 gennaio 2026. Il documento organizza la governance attorno a quattro dimensioni pratiche.

Le organizzazioni dovrebbero prima delimitare il rischio limitando autonomia e accesso. Dovrebbero poi stabilire una responsabilità umana significativa e punti di approvazione.

Il quadro richiede inoltre controlli lungo il ciclo di vita, test di base e accesso a servizi inclusi in una whitelist. La sua dimensione finale riguarda trasparenza, formazione e responsabilità dell'utente finale.

Questo approccio riconosce che la governance degli agenti non può risiedere interamente nel reparto sicurezza. I responsabili di prodotto decidono il caso d'uso, gli sviluppatori assemblano il sistema e i dirigenti aziendali autorizzano l'implementazione operativa.

Anche i team di procurement influenzano il rischio quando selezionano strumenti di terze parti. L'agente di un fornitore potrebbe elaborare dati aziendali attraverso modelli esterni, connettori o servizi di memoria.

I contratti devono affrontare registrazione dei log, notifica degli incidenti, conservazione dei dati, subappaltatori e modifiche al sistema. Gli acquirenti dovrebbero capire se il fornitore possa ricostruire il percorso decisionale di un agente dopo un incidente.

Il compromesso centrale non si risolve fissando per sempre un unico livello di autonomia. I permessi di un agente dovrebbero cambiare con il variare dell'attività, dell'ambiente e delle evidenze.

Un nuovo agente potrebbe iniziare con accesso in sola lettura e approvazione obbligatoria. Test controllati riusciti potrebbero giustificare un'esecuzione limitata all'interno di un flusso di lavoro ristretto.

Fallimenti ripetuti dovrebbero ridurre l'autorità. Comportamenti inattesi, deriva della configurazione o un aggiornamento del modello dovrebbero attivare una nuova revisione.

Questo crea un modello di autonomia guadagnata. L'agente riceve maggiore libertà operativa solo dopo che i test mostrano un comportamento accettabile nelle condizioni pertinenti.

Anche in questo caso, le organizzazioni dovrebbero mantenere confini rigidi. Alcune azioni restano inadatte a un'esecuzione non supervisionata perché le loro conseguenze sono difficili da annullare.

Tra gli esempi figurano la modifica dei controlli di accesso, la pubblicazione di comunicazioni regolamentate, la cessazione del rapporto di lavoro, il trasferimento di somme ingenti o l'eliminazione di record primari.

Il confine preciso varierà tra le aziende. Ciò che dovrebbe restare costante è una decisione esplicita che colleghi l'autonomia al rischio, alla reversibilità e a una titolarità responsabile.

Ciò che gli attuali prodotti di governance non possono ancora dimostrare

Il mercato sta producendo strumenti di controllo per agenti più rapidamente di quanto gli acquirenti possano verificare se tali controlli funzionino tra modelli, piattaforme e flussi di lavoro delegati.

Gli annunci di prodotto promettono spesso individuazione, monitoraggio, applicazione delle policy e rapida correzione. Queste funzioni sono preziose, ma le evidenze circostanti restano disomogenee.

Un fornitore può dimostrare che la sua piattaforma blocca una chiamata a uno strumento nota. Quel test non dimostra le prestazioni contro nuovi attacchi, obiettivi ambigui o catene complesse di delega.

Anche l'individuazione presenta un problema difficile. Gli agenti gestiti centralmente sono più facili da inventariare, ma i dipendenti possono creare automazioni informali tramite strumenti browser, script e servizi esterni.

Questi agenti potrebbero usare credenziali personali o chiavi API copiate. Possono operare al di fuori dei sistemi monitorati da una console di governance centrale.

Le organizzazioni si trovano quindi di fronte a un equivalente degli agenti dello shadow IT. La differenza è che gli agenti ombra possono avviare azioni e creare ulteriore automazione.

Gli strumenti di monitoraggio devono distinguere il comportamento malevolo dalla variazione legittima. Gli agenti utilizzano spesso sequenze diverse per completare lo stesso compito, rendendo le regole comportamentali rigide inclini ai falsi allarmi.

Troppi avvisi possono compromettere la supervisione. I team di sicurezza potrebbero ignorare segnalazioni rumorose, mentre i team aziendali cercano modi per aggirare controlli che bloccano frequentemente il lavoro legittimo.

Le spiegazioni sono un altro punto debole. Un agente può fornire un resoconto plausibile del proprio ragionamento senza offrire prove affidabili del processo che ha generato un'azione.

I sistemi di audit dovrebbero dare priorità agli eventi osservabili. I record utili includono provenienza degli input, chiamate agli strumenti, decisioni di autorizzazione, accesso ai dati, versioni dei modelli, risultati delle policy e output finali.

Questi record devono rimanere protetti dalle modifiche. Un agente non dovrebbe poter cancellare le prove necessarie per indagare sul proprio comportamento.

Anche le affermazioni sul ripristino meritano esame. Ripristinare un branch di codice eliminato è possibile quando esiste una copia indipendente. Richiamare un'email esterna o annullare informazioni divulgate è molto più difficile.

Alcune azioni sono reversibili solo in parte. Un pagamento potrebbe essere annullato, ma il tentato trasferimento può comunque generare problemi di conformità o frode.

Una piattaforma di governance dovrebbe dichiarare quali risorse può ripristinare e quali conseguenze restano al di fuori del suo controllo. Gli acquirenti hanno bisogno di evidenze basate su scenari, non di una promessa generica di rollback.

L'interoperabilità aggiunge ulteriore incertezza. Le imprese raramente operano con un solo modello, un solo framework per agenti o un solo provider di identità.

Una policy che funziona all'interno della piattaforma di un fornitore potrebbe perdere contesto quando l'agente chiama uno strumento esterno. Gli agenti delegati possono attraversare confini organizzativi e tecnici.

Gli standard possono ridurre questa frammentazione, ma sono ancora in fase di sviluppo. Il lavoro del NIST segnala slancio, mentre le implementazioni pratiche dovranno essere testate su sistemi aziendali reali.

Il World Economic Forum ha riferito che l'82% dei dirigenti prevedeva di adottare agenti entro uno-tre anni. La cifra descrive un'intenzione, non un'adozione in produzione dimostrata.

Questa distinzione conta. L'entusiasmo emerso dai sondaggi non dimostra che le organizzazioni dispongano di inventari affidabili, controlli maturi o rendimenti misurabili.

Le affermazioni dei fornitori dovrebbero pertanto restare tali finché valutazioni indipendenti non le confermeranno. Gli acquirenti dovrebbero richiedere prove da implementazioni simili al proprio profilo di rischio.

Il mercato della governance affronta anche un problema di incentivi. Le piattaforme che vendono maggiore autonomia spesso vendono anche i controlli destinati a rendere accettabile tale autonomia.

Questo assetto non invalida i loro strumenti. Significa però che i clienti necessitano di test di sicurezza indipendenti, responsabilità contrattuale chiara e autorità interna per limitare l'implementazione.

Tre segnali indicheranno se la governance degli agenti sta maturando

La prossima fase sarà misurata attraverso identità interoperabile, autonomia basata sulle evidenze e implementazioni in produzione recuperabili, anziché tramite ulteriori dichiarazioni di policy.

Il primo segnale è una guida concreta all'implementazione dall'AI Agent Standards Initiative del NIST. Il suo valore dipenderà dalla capacità delle organizzazioni di tradurre gli standard in controlli interoperabili.

Un risultato utile consentirebbe a un'applicazione di verificare l'identità di un agente, l'autorità delegata, l'ambito consentito e il proprietario responsabile oltre i confini dei fornitori.

Campi di identità comuni migliorerebbero anche la risposta agli incidenti. Gli investigatori potrebbero ricostruire quale agente abbia agito, chi lo abbia autorizzato e se la sua autorità sia cambiata durante l'esecuzione.

Se gli standard resteranno astratti, i fornitori continueranno a implementare modelli di identità incompatibili. Questa frammentazione indebolirebbe l'argomento a favore di una governance centralizzata in ambienti eterogenei.

Il secondo segnale è l'adozione di policy di autonomia dinamiche. Le aziende dovrebbero iniziare a comunicare come i permessi degli agenti cambiano in base a test, rischio e prestazioni osservate.

Ciò richiede criteri misurabili. I soli tassi di completamento sono insufficienti, perché un agente può completare un'attività violando al contempo una policy o esponendo informazioni protette.

Le valutazioni dovrebbero coprire l'uso non autorizzato di strumenti, prompt injection, avvelenamento della memoria, uso improprio delle credenziali, delega e ripristino. I test dovrebbero inoltre riflettere l'effettivo ambiente di produzione dell'agente.

Un'implementazione matura collegherà i risultati delle valutazioni ai permessi. I test falliti dovrebbero bloccare automaticamente un'autorità più ampia finché la debolezza non sarà corretta e riesaminata.

Le prove di questa pratica rafforzerebbero l'argomento secondo cui le imprese possono scalare l'autonomia in modo responsabile. Modelli di permesso statici suggerirebbero che la governance resta indietro rispetto all'implementazione.

Il terzo segnale è l'evidenza pubblica sul contenimento e il ripristino degli incidenti. Le organizzazioni devono dimostrare di poter rilevare attività dannose degli agenti e limitarne le conseguenze.

Ciò non richiede l'esposizione di dettagli sensibili sugli incidenti. Le aziende possono pubblicare scenari anonimizzati, valutazioni indipendenti e prestazioni di ripristino misurate.

Le divulgazioni utili spiegherebbero cosa è accaduto, quale controllo lo ha rilevato, fino a che punto si è diffusa l'azione e cosa poteva essere annullato.

Anche i fallimenti forniranno informazioni. Un incidente che coinvolga un agente correttamente autenticato dimostrerebbe perché la sola identità non può stabilire un intento affidabile.

Un fallimento che attraversi più agenti metterebbe alla prova se i log attuali preservino una catena completa di delega. Un esito irreversibile esporrebbe i limiti del marketing sul rollback.

Questi segnali contano più di un'altra dashboard di governance. La tecnologia deve dimostrare che i controlli restano efficaci quando gli agenti operano alla velocità delle macchine su sistemi reali.

Per gli sviluppatori, l'implicazione immediata è chiara. L'architettura degli agenti dovrebbe esporre checkpoint delle policy, chiamate agli strumenti tracciabili e credenziali limitate fin dall'inizio.

Per gli acquirenti aziendali, i requisiti di governance devono entrare nel procurement prima dell'implementazione. Adattare retroattivamente titolarità, auditabilità e ripristino dopo che gli agenti si sono diffusi tra i reparti costerà di più.

Anche i knowledge worker hanno interesse nella questione. Gli agenti agiscono sempre più attraverso i loro account, dati e strumenti di comunicazione, creando conseguenze che possono apparire sotto un'identità umana.

Il titolo di Google News identifica correttamente la necessità di un nuovo modello di governance. La domanda più difficile è se le organizzazioni imporranno tale modello prima che l'attività autonoma diventi infrastruttura ordinaria.

Chiedetevi chi possiede ogni agente implementato, quali azioni può intraprendere e cosa accade quando le sue istruzioni cambiano. Poi richiedete prove che le risposte resistano a un fallimento reale.