Quando gli agenti AI eseguono sul campo: rischi, esempi e controlli necessari

Un agente AI che legge il CRM, scrive un’email e la invia può spedire dati sensibili alla destinazione sbagliata se uno strumento gli risponde in modo inatteso. L’errore non resta in chat, entra nei sistemi che governano dati e processi. La tesi è semplice: quando un agente passa dal testo all’azione, i permessi e i controlli fanno la differenza tra produttività e incidente¹.

1) Perché il rischio cambia quando l’agente esegue

Questi sistemi non si fermano alla conversazione. Cercano nei database, leggono messaggi, aggiornano record, eseguono workflow e si collegano ad applicazioni esterne. Una richiesta di lavoro tipica: trova i clienti con abbonamento in scadenza, prepara il promemoria e invialo. Se una risposta di uno strumento indica una destinazione diversa, l’agente può eseguire e diffondere dati dove non deve. Oppure tocca i record sbagliati. Il punto non è l’intelligenza del modello. È l’affidamento di software probabilistico ad accessi deterministici senza controlli sufficienti. Il passaggio dai chatbot ai workflow autonomi sposta il rischio: da output testuale a azioni su sistemi aziendali¹.

2) Tre casi che mostrano il problema in contesti reali

AWS ha descritto come ha cambiato il triage delle vulnerabilità del kernel che gira nell’infrastruttura EC2. Il volume lo impone. Da febbraio 2024, il progetto Linux è diventato CVE Numbering Authority. Si è passati da circa due CVE a settimana prima del 2024 a circa sedici al giorno dopo. Al 15 agosto 2026, il progetto aveva pubblicato 848 CVE che riguardano il kernel. Per gestire la scala, il team usa una catena in tre passi: filtro automatico, agente AI, revisione umana. L’obiettivo è capire in fretta cosa tocca i rami in produzione. Dylan Johnson e Justinien Bouron hanno presentato il metodo alla Linux Plumbers Conference di Praga, chiarendo che non si parla di Amazon Linux o dei kernel nelle VM dei clienti².

IBM, in uno Statement of Direction, riconosce la complessità operativa dei mainframe z/OS e annuncia IBM Z Atlas. La proposta è mappare l’intero stack del cliente su tre livelli, infrastruttura, middleware, applicazioni. Da questa base, “AI skills and agents” operano ancorati a workflow reali. Gli esempi citati sono “planning and validating changes” e “modernizing applications and infrastructure”. L’intento è ridurre lo sforzo manuale dove nasce più rischio operativo, con funzioni agganciate al contesto effettivo dei sistemi z/OS³.

Un test in produzione su Mac, con la versione desktop di Claude Code, mostra il rovescio della medaglia nelle esecuzioni senza presidio. Per sette settimane, a partire dal 16 agosto 2026, gli autori hanno schedulato sei slot al giorno: quattro scrivono articoli alle 08:06, 12:08, 16:05 e 20:07. Due preparano angoli e raccolgono numeri di traffico alle 11:02 e 17:07. Le attività a volte non partono o si spengono a metà. I log della run che poi va a buon fine non mostrano l’errore. Il criterio di successo diventa l’arrivo dell’artefatto su git. Se non “atterra”, per loro la run non è mai esistita. C’è un caso chiaro: lo slot salta quando il Mac è in stop o l’app è chiusa. Non c’è allarme. L’esecuzione riprende alla successiva apertura dell’app⁴.

Questi tre contesti mettono a fuoco lo stesso nodo: l’agente tocca sistemi reali, con impatti su produzione o contenuti, quindi servono confini, segnali affidabili e punti di controllo.

3) Cosa unisce questi esempi: mancanza di segnali, permessi e supervisione

La gestione dei permessi è centrale. Un agente con accessi ampi può propagare una risposta inattesa oltre la chat. Il risultato sono aggiornamenti sbagliati o invii verso destinatari errati. Il problema nasce quando si affida a software probabilistico l’accesso a sistemi deterministici senza controlli proporzionati¹.

AWS sceglie un contrappeso esplicito. Automatizza il filtro, usa un agente per il triage e chiude con una revisione umana. La revisione tiene l’azione sotto controllo quando tocca rami in produzione, con un flusso che parte dai record ufficiali in JSON e usa campi chiave per il primo filtro. È un modo per gestire sedici CVE al giorno senza perdere il presidio sui passaggi che contano².

IBM sposta l’attenzione sul contesto. Propone una mappa condivisa di infrastruttura, middleware e applicazioni. Gli agenti operano su questa base, legati a workflow come la pianificazione e la validazione dei cambi. È una risposta alla complessità: ridurre l’opacità delle dipendenze e allineare l’azione degli agenti alle realtà dei sistemi z/OS³.

Claude Code evidenzia un altro rischio: l’assenza di segnali di errore affidabili nelle esecuzioni unattended. Se un’attività non parte o si ferma, e i log non lo mostrano nella run “buona”, la failure resta invisibile. Senza un artefatto su git, l’esecuzione è come se non fosse mai esistita. La mancanza di un allarme quando il Mac è in stop o l’app è chiusa lascia buchi nella catena di controllo⁴.

La tendenza è chiara: più autonomia e più integrazione richiedono meno fiducia implicita e più meccanica di sicurezza. Permessi ridotti allo stretto necessario, supervisione a tappe, contesto operativo esplicito e segnali che non saltano gli orari.

4) Implicazioni pratiche per chi progetta, sviluppa e testa agenti AI enterprise

• Limitare i permessi. Assegnare all’agente solo gli accessi necessari al workflow specifico. Riduce l’effetto di risposte inattese e restringe il raggio d’azione di un errore operativo¹.
• Inserire punti di revisione. Replicare la catena filtro automatico, agente, revisione umana dove le azioni toccano produzione o dati sensibili. Il volume di sedici CVE al giorno mostra che si può accelerare senza cedere il presidio².
• Mappare il contesto prima di agire. Una vista su infrastruttura, middleware e applicazioni, come prevede IBM Z Atlas, aiuta a pianificare e validare i cambi lungo dipendenze reali. Gli agenti operano meglio se ancorati a workflow concreti e a una base comune³.
• Curare segnali e audit. Un’esecuzione senza presidio deve generare prove verificabili e allarmi puntuali. Il caso delle attività di Claude Code che saltano senza traccia utile nei log rende chiaro perché. Senza segnale, l’errore resta invisibile e il ripristino rallenta⁴.
• Lasciare tracce utili a rollback e indagine. Ogni passaggio della catena deve produrre artefatti e log consultabili. La catena filtro, agente, revisione funziona se ogni stadio è ispezionabile e reversibile quando serve^2,1.

Queste scelte non spengono l’autonomia, la rendono più affidabile. Gli agenti continuano a leggere, scrivere, inviare e aggiornare. Ma lo fanno entro limiti chiari, con segnali che suonano quando qualcosa non va e con persone che chiudono il cerchio dove il rischio è alto.

Il segnale arriva da tre fronti diversi. Il triage del kernel di EC2 mostra come lavorare alla scala imposta dal nuovo ruolo del progetto Linux nelle CVE. Lo Statement of Direction su IBM Z Atlas punta a ridurre la complessità con una base comune di contesto. Il test di Claude Code evidenzia cosa succede quando un’esecuzione senza presidio fallisce senza lasciar detto nulla. La convergenza è operativa: integrare agenti nei sistemi richiede progettazione dei permessi, mappa delle dipendenze, e un sistema di eventi e revisioni che non salta gli orari fissati^2,3,4.

La prossima domanda non è se l’agente può fare il lavoro, ma cosa succede quando qualcosa va storto e chi lo vede per primo: il cliente, o il vostro allarme interno¹.