Negli ultimi mesi sarà capitato spesso a chi lavora in direzione IT di assistere alla stessa demo: un agente AI riceve una richiesta, interroga tre sistemi diversi, prepara una risposta e chiude il caso senza che nessuno tocchi la tastiera. Funziona, e funziona bene.
Poi l’agente esce dalla demo ed entra nel processo reale, e le storie prendono due direzioni opposte. In un caso l’agente viene arginato da approvazioni manuali, finché non diventa più lento della persona che doveva affiancare. Nell’altro, opera con permessi troppo ampi, finché non accede a un dato o a un sistema che non avrebbe dovuto toccare.
La risposta più diffusa è che il problema sia la maturità dei modelli. Ma nelle aziende che stanno portando gli agenti in produzione emerge una questione più scomoda: l’autonomia non dovrebbe essere un interruttore acceso/spento, ma un parametro di progetto da graduare in funzione del rischio. E non è una scelta di policy da fare a valle: coinvolge architettura, sicurezza, processo e responsabilità, e va decisa prima della messa in produzione.
Il problema: un’autonomia concessa come un interruttore
A maggio 2026 Gartner si è lanciata in una previsione interessante: entro il 2027, il 40% delle imprese potrebbe declassare o dismettere agenti AI autonomi per lacune di governance emerse dopo l’ingresso in produzione.
Il punto non è che gli agenti siano inaffidabili, ma che le aziende applicano lo stesso modello di controllo a sistemi con autonomia e perimetri di accesso completamente diversi. Trattare la governance come una scelta binaria — tutto bloccato oppure piena fiducia — produce due fallimenti speculari.
Da un lato, agenti semplici (un assistente che legge documenti e propone una classificazione) vengono sottoposti a controlli pensati per sistemi che modificano dati o eseguono operazioni critiche. Il valore, in questo caso, si perde nella latenza delle approvazioni e il progetto viene archiviato come «interessante ma non pratico». Dall’altro, agenti che agiscono davvero sui sistemi di produzione ricevono permessi troppo ampi, senza monitoraggio granulare, identità dedicata o meccanismi di interruzione: qui il progetto non muore di lentezza, ma rischia di produrre un incidente.
L’errore metodologico è trattare alla stessa stregua ciò che un agente sa fare e ciò che gli è permesso fare. Sono, invece, dimensioni indipendenti. Un agente molto capace può avere un perimetro strettissimo; un agente semplice può diventare rischioso con credenziali eccessive.
Cosa sta cambiando
La differenza tra un copilota e un agente non è la quantità di «intelligenza»: è dove finisce il lavoro. Un copilota produce un output che qualcuno rivede, e il controllo avviene sul risultato. Un agente esegue un’azione (apre un ticket, aggiorna un record, modifica una configurazione) e quando l’azione è avvenuta può essere troppo tardi. Il controllo si sposta quindi sul perimetro: quali dati l’agente vede, con quale identità accede ai sistemi, quali strumenti può usare, quali azioni può e non può eseguire, cosa deve provocarne l’arresto.
Non ogni automazione che utilizza un modello linguistico è però un «agente». Il confine tra workflow automatizzati, copiloti e sistemi realmente agentici non è netto: prima di scegliere una soluzione conviene definire quale grado di autonomia si sta effettivamente introducendo nel processo.
Evidenze e dati
L’adozione, intanto, accelera. Secondo lo State of AI 2026 di McKinsey, il 40% dei rispondenti in organizzazioni con oltre un miliardo di dollari di ricavi è in fase di scaling degli AI agent, contro il 22% nelle organizzazioni più piccole. Ma crescita dell’adozione non significa crescita del valore: nella stessa ricerca il 37% dichiara un impatto dell’AI sull’EBIT, quota invariata rispetto all’anno precedente, e solo il 6% circa attribuisce all’AI almeno il 5% dell’EBIT.
In Italia il fenomeno è in una fase precedente: il mercato dell’AI ha raggiunto 1,8 miliardi di euro nel 2025 (+50% sul 2024) e il 71% delle grandi imprese aveva già avviato almeno un progetto (Osservatorio Artificial Intelligence, Politecnico di Milano). Molte aziende devono ancora decidere non soltanto se utilizzare agenti, ma come governarne l’utilizzo.
Il problema non è la maturità tecnologica dei modelli, ma la difficoltà di trasformarli in sistemi affidabili, sostenibili e governabili.
1. Non tutto ciò che viene definito «agentico» lo è davvero
Gartner ha evidenziato il fenomeno dell’«agent washing»: il mercato usa il termine agentic AI per soluzioni con livelli di autonomia molto diversi, creando un problema non solo terminologico. Se non si distingue un workflow automatizzato da un agente capace di pianificare e agire attraverso più strumenti, non se ne possono valutare rischio, costi e governance: la selezione del fornitore diventa così parte della governance stessa.
2. I dati restano una condizione fondamentale
Un agente non può essere più affidabile dei dati e dei sistemi sui quali opera. Gartner aveva previsto nel 2025 che entro il 2026 le organizzazioni avrebbero abbandonato una quota significativa dei progetti AI non supportati da dati adeguatamente preparati, rilevando al tempo stesso una forte carenza di pratiche di data readiness. Prima di automatizzare una decisione bisogna sapere quali dati la alimentano, chi ne è responsabile e quanto siano affidabili.
Gli agenti, in altre parole, possono fallire sia a monte, per problemi di dati e di processo, sia a valle, per permessi, sicurezza e governance insufficienti.
Cosa significa per le aziende
La prima conseguenza è che la governance degli agenti non può essere un documento: va incorporata nell’architettura, nei processi e nelle responsabilità. Una policy che dichiara «gli agenti operano sotto supervisione umana» non serve a nulla se l’agente agisce con le credenziali di un’utenza di servizio condivisa, perché diventa impossibile ricostruire chi ha fatto cosa. Identità dedicata, least privilege, logging e tracciabilità sono precondizioni tecniche, da progettare insieme al caso d’uso.
La seconda è che il costo del controllo deve essere commisurato al rischio. Ogni approvazione umana ha un prezzo in tempo e attenzione: inserirla dove non serve non produce sicurezza, ma un tasso di approvazione vicino al 100% da parte di persone che hanno smesso di leggere.
La terza riguarda la sicurezza. Un agente che legge dati, utilizza strumenti e compie azioni è una nuova superficie di attacco: prompt injection, uso improprio degli strumenti, escalation dei privilegi e concatenazione di errori tra più sistemi vanno considerati in progettazione. La domanda non è quindi soltanto «cosa succede quando l’agente sbaglia?», ma anche «cosa succede se qualcuno cerca deliberatamente di farlo comportare male?».
La quarta è organizzativa. Chi approva deve sapere cosa sta approvando, chi riceve un output deve sapere come è stato prodotto, chi governa il processo deve sapere quando fermare l’agente. L’AI literacy non è soltanto una competenza utile: è la condizione perché la supervisione umana funzioni.
Foto di Kelly Sikkema su Unsplash
AI Act: una scadenza cambiata non significa che il lavoro possa aspettare
Il Digital Omnibus sull’AI è stato formalmente adottato con il Regolamento (UE) 2026/1744, pubblicato in Gazzetta Ufficiale il 24 luglio 2026 ed entrato in vigore il 27 luglio. Il nuovo calendario rinvia alcune disposizioni sui sistemi ad alto rischio: al 2 dicembre 2027 per quelli classificati ai sensi dell’articolo 6(2) e dell’Allegato III, al 2 agosto 2028 per quelli rientranti nell’articolo 6(1) e nell’Allegato I.
Non si tratta però di una sospensione generale dell’AI Act: i capitoli I e II restano in applicazione dal 2 febbraio 2025, con alcune eccezioni, e gli obblighi di trasparenza dell’articolo 50 mantengono la scadenza originaria del 2 agosto 2026.
Una scadenza spostata non elimina quindi il lavoro di classificare i casi d’uso, governare i dati, definire responsabilità e costruire controlli efficaci: gli stessi elementi che servono per portare un agente in produzione in modo affidabile.
Prospettiva pratica: quattro livelli e un criterio di uscita
Come uscirne? Gartner propone un modello semplice, ma operativo: classificare ogni agente in funzione del livello di autonomia e applicare controlli proporzionati.
- Osservare. Accesso in sola lettura: l’agente analizza documenti, recupera informazioni, segnala anomalie. Bastano controlli di base su accesso ai dati, autenticazione e logging.
- Consigliare. L’agente formula raccomandazioni, l’esecuzione resta umana. Il rischio non è solo l’errore dell’AI, ma l’automation bias: la tendenza a fidarsi eccessivamente di una raccomandazione automatica. Servono test sulla qualità dell’output e formazione degli utenti.
- Agire con approvazione. L’agente esegue azioni, ma solo previa approvazione esplicita. Servono workflow tracciabili, audit trail, test di sicurezza e gestione degli incidenti, oltre alla verifica che l’approvazione resti significativa.
- Agire in autonomia. L’agente esegue le azioni consentite dentro guardrail definiti, con monitoraggio continuo, limiti operativi, rollback rapido, circuit breaker e responsabilità assegnate.
Lo schema diventa operativo con quattro domande per ogni agente, da chiudere prima della produzione: quali dati vede, e con quale identità? Quali azioni può eseguire, e quali mai? Cosa succede quando sbaglia o viene attaccato? Chi se ne accorge, e cosa viene fermato?
L’elemento che manca più spesso: il criterio di promozione
Un agente non dovrebbe salire di livello perché il progetto è in ritardo o perché le approvazioni manuali sono diventate scomode, ma perché ha accumulato evidenze misurate: tasso di correzione umana, numero e gravità degli incidenti, accuratezza su campioni rappresentativi, costo per pratica, rispetto dei limiti di sicurezza.
E lo stesso criterio deve funzionare al contrario: chi supera una soglia di errore o di rischio retrocede automaticamente, senza aspettare che un incidente diventi una riunione. L’autonomia non è una promozione permanente, ma un livello revocabile sulla base delle evidenze.
Tre errori ricorrenti
- Partire dall’agente invece che dal processo: senza ridisegnare il flusso, l’automazione replica l’inefficienza esistente più velocemente.
- Non definire criteri di uscita, trasformando l’autonomia in una decisione presa una volta sola e mai più rivista.
- Confondere supervisione e sicurezza: se l’agente può essere manipolato, l’essere umano davanti all’approvazione non elimina il rischio.
La prospettiva DMBI
Un approccio efficace parte dal problema aziendale, non dall’agente. Prima della tecnologia viene il processo: dove nasce il dato, chi lo utilizza, quali decisioni vengono prese, dove si concentrano gli errori. Da qui si procede per passi, business problem, processo, dati, tecnologia, controlli, valore di business, evitando la trappola più costosa di questa fase dell’AI: scegliere lo strumento prima di aver definito il problema.
Per questo una parte importante del lavoro su un progetto agentico non sembra, a prima vista, lavoro sull’AI: è data architecture, data quality, data governance, cybersecurity e process design. Discipline che pesano ancora di più quando un sistema non si limita a suggerire una decisione, ma può contribuire a eseguirla.
Conclusione
Il problema degli agenti AI non è decidere se fidarsi della tecnologia. È decidere dove l’autonomia crea valore, dove introduce rischio e quali condizioni vanno soddisfatte prima di concederla.
Le organizzazioni che nei prossimi anni avranno agenti realmente integrati nei processi non saranno quelle che si saranno fidate di più, né quelle che avranno controllato tutto. Saranno quelle capaci di rispondere, per ogni singolo agente, a una domanda più concreta: quanto può essere autonomo, in questo processo, con questi dati, questi permessi e questo livello di rischio? L’autonomia non è una caratteristica da concedere una volta per tutte: è un parametro di progetto, da misurare e rivedere nel tempo.
A cura di Claudia Paniconi — Marketing Manager, DMBI Consultants
Foto in evidenza di Towfiqu barbhuiya su Unsplash
Fonti
- Gartner, «Gartner Says Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure», 26 maggio 2026 — https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure
- Gartner, «Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027», 25 giugno 2025 — https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
- Gartner, «Lack of AI-Ready Data Puts AI Projects at Risk», 26 febbraio 2025 — https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk
- McKinsey & Company, «The State of AI: Global Survey 2026 — On the road to ROI», 25 agosto 2026 — https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- Osservatorio Artificial Intelligence, Politecnico di Milano, «Il mercato dell’AI in Italia cresce del 50% nel 2025», febbraio 2026 — https://www.osservatori.net/comunicato/artificial-intelligence/intelligenza-artificiale-italia/
- Unione Europea, Regolamento (UE) 2026/1744 (Digital Omnibus on AI), pubblicato in GUUE il 24 luglio 2026 — https://eur-lex.europa.eu/eli/reg/2026/1744/oj
- Commissione Europea, «AI Act — Regulatory framework for artificial intelligence» — https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- NIST, «Artificial Intelligence Risk Management Framework (AI RMF 1.0)», 2023 e aggiornamenti successivi — https://www.nist.gov/itl/ai-risk-management-framework
