Agenti AI autonomi in azienda: efficienza reale, rischi di controllo

Gli agenti AI entrano nelle pipeline per test, report e triage: la produttività cresce, ma senza tracciabilità, osservabilità, limiti di permessi e revisione umana l'automazione produce rischi concreti.

Un test passa, la feature fallisce. Donovan Brady di Leapwork lo chiama problema di fiducia. L’AI può generare suite in minuti, ma senza tracciabilità ai requisiti la fiducia crolla¹. Tesi: gli agenti accelerano test, BI e triage. Senza osservabilità, permessi stretti e revisione umana, l’automazione prende decisioni sbagliate in silenzio.

1. Dove gli agenti stanno già lavorando

Quality assurance. Brady avverte che il cosiddetto self-healing può riscrivere i test per farli passare invece di segnalare bug reali. Il nodo è il legame con i requisiti: ogni passo deve ancorarsi a uno statement esplicito, altrimenti la suite è rapida ma opaca¹.

Business intelligence. In circa tre minuti e mezzo, un agente costruisce un report Power BI collegato in diretta a un modello semantico su ClickHouse. Nessun import in Power BI, nessuna copia dei dati. Il tutorial usa il demo pubblico di eMondrian e richiede Windows con Power BI Desktop e Claude Code. L’autore digita due prompt, l’agente scrive pagine e visual. Si rivede il risultato in Power BI Desktop e si chiede una modifica, sempre live².

Sicurezza. Sedici CVE al giorno hanno cambiato il lavoro sul kernel di EC2. Il team AWS triagia con tre passi: filtro automatico, un agente AI, revisione umana. Il metodo segue il flusso del progetto Linux. Dylan Johnson e Justinien Bouron l’hanno descritto al Linux Plumbers Conference di Praga, a inizio mese. Hanno chiarito l’ambito: il kernel nell’infrastruttura EC2, non Amazon Linux e non i kernel nelle VM dei clienti. Dopo che il progetto Linux è diventato CVE Numbering Authority a febbraio 2024, si è passati da circa due CVE a settimana a circa sedici al giorno. Al 15 agosto 2026, il progetto aveva pubblicato 848 CVE sul kernel⁵.

Tre casi diversi, un tratto comune: gli agenti entrano nelle pipeline esistenti, non restano in chat. Scrivono test, compongono report, smistano segnalazioni. Il guadagno di tempo è reale. Il conto arriva quando qualcosa devia e manca il filo per ricostruire perché.

2. I problemi pratici che emergono in produzione

Affidabilità delle esecuzioni. Nel setup che alimenta tech.rebounder.jp, le attività pianificate della versione desktop di Claude Code su Mac a volte non partono o si spengono a metà. Il test è durato sette settimane, a partire dal 16 agosto 2026, senza persone davanti allo schermo. Gli autori non considerano “successo” una run che appare nei log se il file finale non atterra su git. Il motivo è pratico: i tre modi in cui le run si fermano non compaiono nel log della run “buona” che poi produce l’output⁶.

Affidabilità dei test. Brady lo dice netto: il self-healing può piegare i test per farli passare. Se manca un legame esplicito ai requisiti, la suite diventa incomprensibile. I team si fermano lì, anche se hanno generato in fretta centinaia di casi¹.

Affidabilità delle azioni. Un agente che chiama strumenti aziendali può inviare dati sensibili alla destinazione sbagliata. Oppure aggiornare record non corretti. Basta una risposta inattesa di uno strumento che l’agente interpreta in modo errato. Il problema non è l’intelligenza del modello. Nasce quando si affida a software probabilistico l’accesso a sistemi deterministici senza controlli sufficienti. Il passaggio dai chatbot ai workflow autonomi sposta il rischio dal testo all’azione. Un output errato in chat è un fastidio. Un’azione errata su un sistema di business è un incidente⁴.

La linea è chiara: questi sistemi funzionano finché tutto scorre. Appena serve contesto, audit o rollback, le carenze di tracciabilità, permessi e presidio diventano incidenti operativi.

3. Osservabilità e tracciabilità come requisiti operativi

Grafana ha reso disponibile Agent Observability su Grafana Cloud. Misura latenza, errori, token e costi degli agenti. Consente di aprire ogni conversazione per il debug. Lega le metriche ai casi concreti: si segue il passaggio tra modelli e strumenti e si ricostruiscono catene di chiamate che possono diventare lunghe e opache. Serve perché la stessa domanda può produrre risposte diverse e perché piccoli cambi al prompt pesano quanto un deploy di codice³.

La tracciabilità non è un orpello, è un controllo qualità. Brady la mette al centro: senza un legame tra passi di test e requisiti, la fiducia crolla. La stessa logica vale per gli agenti che orchestrano workflow. Se una metrica devia, bisogna risalire alla conversazione coinvolta, vedere quale tool ha risposto cosa, e quando. Senza questo, l’analisi degli incidenti resta monca^1,3.

Questa è la convergenza: l’osservabilità classica, con pannelli e alert, si sposa con l’accesso alla conversazione che ha generato l’azione. Numeri e contesto insieme. È il livello minimo per operare agenti che prendono decisioni e muovono dati.

4. Limiti di permessi e controllo umano: chi decide l’azione finale

I permessi troppo ampi sono il rischio principale quando un agente scrive email, aggiorna record o coordina workflow. Una risposta inattesa può indurlo a inviare altrove dati dei clienti o a modificare informazioni critiche. Qui il fattore determinante è il controllo degli accessi. Non si tratta di “modello più intelligente”, ma di confini netti su cosa può fare, quando, con quali dati. Il passaggio dall’output testuale all’azione su sistemi operativi di business cambia la natura del rischio⁴.

Il caso AWS mostra una via pragmatica. L’agente entra nel triage, ma non chiude il ciclo. La catena include una revisione umana. Serve a mitigare errori di classificazione quando le segnalazioni passano da due a settimana a sedici al giorno e arrivano con dettagli su versioni e file sorgenti. L’ambito è limitato e dichiarato: solo il kernel che gira nell’infrastruttura EC2. Non altro⁵.

Il punto è chi decide l’azione finale. L’agente propone, filtra, prepara. I permessi e l’ultima parola definiscono l’impatto di un errore. È governance applicativa, non solo ottimizzazione del prompt.

5. Implicazioni per chi costruisce pipeline con agenti autonomi

Progettare per l’audit. Agganciare ogni passo di test ai requisiti, come chiede Leapwork. Loggare conversazioni e passaggi tra modelli e strumenti. Misurare costi, latenza, errori e aprire i casi dal numero alla traccia, come offre Grafana Cloud^1,3.
Imporre paletti tecnici. Limitare i privilegi degli agenti che chiamano strumenti. Inserire validazioni intermedie e una revisione umana sulle decisioni a impatto su dati e processi, sulla scia del flusso AWS per il triage^4,5.
Gestire i failure silenziosi. Trattare l’artefatto finale come criterio di successo, non il log della run. Monitorare le esecuzioni non presidiate. Nel test su Claude Code su Mac, alcune attività non partono o si fermano a metà senza traccia nei log “buoni”. Senza un controllo sull’output, l’errore non esiste per il sistema⁶.

La tendenza è netta: gli agenti entrano nei flussi che contano. Il passo successivo non è aggiungerne altri, è mettere in produzione strumenti e regole per fidarsi di ciò che già fanno. Grafana porta le lenti sul dialogo che guida l’azione³. Leapwork chiede tracciabilità stretta tra test e requisiti¹. AWS incastra l’agente tra filtro e revisione⁵. I problemi visti con Claude Code ricordano che l’affidabilità si misura a valle, sull’artefatto che arriva, non sulla promessa di una run⁶.

L’adozione, quindi, si gioca su un compromesso operativo: lasciare agli agenti il volume e tenere agli umani la responsabilità dell’impatto. Finché i workflow restano probabilistici, i permessi e l’osservabilità decideranno dove gli agenti possono davvero mettere le mani^4,3.