Quando l'autonomia ha bisogno di tutori, qualcosa nella promessa non torna
C'è un momento specifico in cui il linguaggio aziendale diventa auto-incriminante. Accade quando la stessa azienda che annuncia che i propri agenti di intelligenza artificiale possono lavorare da soli, in parallelo, senza supervisione, e consegnare risultati prima che qualcuno li richieda, presenta nello stesso evento una batteria di strumenti la cui unica funzione è sorvegliare quegli agenti, correggerli e disfare ciò che hanno fatto male.
È esattamente quello che è successo all'AWS Summit di New York nel giugno del 2026. Amazon Web Services si è presentata al mercato aziendale con la promessa dell'"Era degli Agenti" ed è uscita dall'evento avendo annunciato, simultaneamente, il proprio sistema di agenti autonomi più ambizioso e l'infrastruttura di controllo più densa fino a quel momento. La distanza tra le due cose non è un dettaglio tecnico. È una dichiarazione di posizione su dove si trova realmente l'industria.
Per chi guida un'organizzazione e deve prendere decisioni su dove allocare capitale, talento e credibilità istituzionale, questa tensione merita un'analisi più approfondita di quella che solitamente riceve.
---
L'offerta ha due livelli e se ne vende solo uno
Il centro dell'annuncio di AWS è stato Amazon Quick, una piattaforma che consente a utenti senza conoscenze di programmazione di creare agenti autonomi descrivendo la loro funzione in linguaggio naturale e distribuirli in pochi secondi. L'esempio circolato: un agente che monitora le presentazioni regolamentari durante la notte, le confronta con le politiche interne e consegna un'analisi d'impatto prima dell'alba. Senza intervento umano. Senza codice. Senza attrito.
L'argomento di vendita è pulito. E in certi contesti circoscritti, probabilmente funziona. Ma la stessa presentazione includeva altri elementi che raccontano una storia diversa.
L'AWS DevOps Agent ha incorporato capacità di gestione delle versioni che revisionano il codice generato dagli agenti di intelligenza artificiale prima che arrivi in produzione, perché, come la stessa azienda lo inquadra, gli agenti di codifica scrivono a velocità straordinaria mentre la revisione umana rimane lenta. È apparso anche AWS Transform, costruito sulla premessa che più velocemente si genera codice, più velocemente si accumula debito tecnico, e che quel debito necessita di una pulizia continua e autonoma. Ed è stato presentato AWS Continuum, un servizio di sicurezza che inizia in "modalità apprendimento" e passa all'enforcement autonomo solo man mano che cresce la fiducia del sistema.
Ognuno di questi strumenti assume, per design, che gli agenti commetteranno errori, che quegli errori raggiungeranno la produzione se nessuno li intercetta, e che il ritmo di generazione dei problemi può superare la capacità umana di rilevarli. Questa non è una descrizione di autonomia. È la descrizione di un sistema che richiede sorveglianza continua su scala perché, senza di essa, i rischi diventano ingestibili.
Swami Sivasubramanian, vicepresidente dell'IA agenziale in AWS, ha respinto la lettura secondo cui ciò costituisce una contraddizione. Il suo argomento: i controlli non indeboliscono l'autonomia, la rendono possibile. L'attrito manuale in ogni decisione non è una garanzia di buona governance; è un collo di bottiglia travestito da prudenza. Ciò che AWS propone è sostituire quell'attrito manuale con controlli basati su politiche che possano operare alla velocità e alla scala che le organizzazioni moderne richiedono.
È un argomento intelligente. E in parte ha ragione. Ma schiva qualcosa.
---
Il problema non è tecnico, è di governance irrisolta
L'affermazione che i controlli automatizzati siano superiori all'attrito manuale funziona bene quando i controlli sono correttamente calibrati, quando le politiche che governano gli agenti riflettono con precisione le intenzioni dell'organizzazione, e quando gli errori commessi all'interno del sistema sono rilevabili e reversibili. Nessuna di queste tre condizioni è gratuita. Tutte richiedono un lavoro organizzativo preliminare che la maggior parte delle aziende non ha ancora svolto.
Liz Miller, vicepresidente e analista principale di Constellation Research, lo dice senza mezzi termini: la governance, il rischio e la responsabilità sono sistematicamente le prime restrizioni che bloccano i progetti di agenti di intelligenza artificiale nelle imprese. Non la tecnologia. Non il budget. L'incapacità di rispondere con chiarezza a chi spetta la responsabilità quando l'agente prende una decisione che nessuno ha approvato esplicitamente.
Questa è la conversazione che molte organizzazioni evitano. E la evitano perché ha un costo politico interno. Definire cosa può decidere un agente senza validazione umana implica prendere posizione su quali processi possono essere standardizzati, quali eccezioni esistono, cosa succede quando il sistema fallisce e chi ne risponde. Queste non sono domande tecniche. Sono domande su potere, responsabilità e propensione al rischio che richiedono che qualcuno al vertice della direzione le nomini per primo.
Sivasubramanian lo ha riconosciuto nell'intervista con Fast Company in un modo che merita attenzione: "Gli esseri umani approvano meno azioni individuali pur rimanendo responsabili delle decisioni a livello di sistema che determinano i risultati. La responsabilità non si riduce." Questa è una descrizione onesta di ciò che accade. Ma è anche un segnale che il modello di responsabilità organizzativa che molte aziende hanno oggi, costruito attorno ad approvazioni individuali e revisioni caso per caso, non è attrezzato per funzionare in questo nuovo schema.
La domanda a cui AWS non può rispondere al posto dei propri clienti è quante organizzazioni abbiano la maturità interna necessaria per distinguere quale tipo di decisioni possono delegare a un agente, quali devono continuare a essere umane, e come progettare il confine tra le due. Quel confine non lo definisce la tecnologia. Lo definisce la leadership.
---
Cosa dice Gartner sul 40% e perché conta più di quanto sembri
Gartner prevede che più del 40% dei progetti di agenti di intelligenza artificiale verrà abbandonato prima della fine del 2027. Le ragioni citate sono tre: costi crescenti, valore di business poco chiaro e controlli del rischio insufficienti. Questa proiezione non è allarmismo. È la descrizione statistica di un pattern che esisteva già prima degli agenti: l'adozione tecnologica aziendale fallisce più spesso per problemi di governance e definizione del valore che per limitazioni tecniche.
Ciò che rende il numero rilevante in questo contesto è che AWS, costruendo un'infrastruttura così densa di controlli e monitoraggio, sta riconoscendo implicitamente che gli agenti senza tale infrastruttura hanno un tasso di fallimento inaccettabile per la produzione aziendale. La decisione di lanciare AgentCore con politiche di governance incorporate, di avviare AWS Continuum in "modalità apprendimento", di creare meccanismi di rollback nell'DevOps Agent, non è marketing sulla sicurezza. È architettura difensiva di fronte a un problema reale.
Il problema che questo crea per il cliente aziendale è di una natura che poche organizzazioni stanno nominando: se il valore degli agenti dipende dalla qualità delle politiche che li governano, e quelle politiche dipendono dal fatto che l'organizzazione sappia con precisione cosa vuole automatizzare, chi ha l'autorità per farlo e cosa costituisce un errore inaccettabile, allora il vero lavoro non è tecnico. È organizzativo. E quel lavoro non è incluso in nessuna licenza software.
Miller avverte che le aziende che confondono l'automazione di compiti ripetitivi con l'autonomia reale, cioè con sistemi che prendono decisioni orientate agli obiettivi in contesti mutevoli, sono le più esposte. Non perché la tecnologia le inganni, ma perché esse stesse si permettono di non porre le domande che genererebbero attrito interno prima di impegnarsi nel dispiegamento.
AWS porta la stessa logica al design del prodotto quando dichiara che "l'intelligenza non è più il collo di bottiglia, lo è il contesto." Quella frase ha un significato organizzativo concreto: gli agenti sono buoni quanto la qualità, la coerenza e l'accessibilità dei dati su cui operano. E la maggior parte delle grandi aziende ha dati frammentati, archivi storici incoerenti e sistemi che non comunicano tra loro. Risolvere questo prima di dispiegare gli agenti non è un prerequisito tecnico che il team IT può gestire da solo. È una decisione sulle priorità di investimento che il C-Level deve prendere e sostenere.
---
La scommessa di piattaforma che AWS non sta nominando esplicitamente
C'è una dimensione di questo annuncio che merita un'analisi separata perché influisce sull'economia decisionale di qualsiasi azienda che consideri l'adozione di questi servizi.
AWS non sta solo vendendo agenti. Sta costruendo un'architettura in cui gli agenti dipendono da componenti propri: AWS Context per la conoscenza aziendale, Amazon S3 Annotations per i dati strutturati, AgentCore per l'orchestrazione, Bedrock Guardrails per il controllo degli input e degli output. Ogni livello di valore che un'organizzazione crea all'interno di quel sistema, ogni politica definita, ogni workflow codificato, ogni agente addestrato su dati propri archiviati in quella infrastruttura, approfondisce il costo di uscita.
Con ricavi che hanno superato i 104,9 miliardi di dollari nel 2024, AWS ha la scala per sostenere questa architettura per tutto il tempo necessario affinché il mercato aziendale maturi verso l'uso di agenti autonomi. La scommessa non è che gli agenti siano perfetti oggi. È che le organizzazioni che costruiranno le proprie operazioni su questa infrastruttura avranno un costo di migrazione sufficientemente elevato da rendere la relazione strutturale, non transazionale.
Questo non è una critica. È una descrizione di come le piattaforme competono nell'infrastruttura critica. Microsoft sta facendo qualcosa di analogo con Copilot Studio e Azure AI Studio. Google Cloud ha la propria versione con Vertex AI Agent Builder. Tutti offrono lo stesso argomento centrale: l'integrazione verticale tra modelli, dati, orchestrazione e governance è il vantaggio reale, non il modello in sé.
Per l'executive che valuta dove impegnarsi, la domanda non è se gli agenti funzionano in un pilota. È se l'organizzazione ha la maturità nei processi, la chiarezza dei dati e la cultura di responsabilità necessarie per operare nell'architettura di piattaforma che ciascun fornitore propone. Quella valutazione non può essere delegata al team tecnologico. Richiede che chi guida capisca cosa sta firmando.
---
Autonomia con tutori non è la destinazione, è il punto di partenza
Sivasubramanian ha paragonato la resistenza attuale agli agenti ai dubbi che esistevano sul cloud nei suoi primi anni. L'argomento è che i controlli maturano e la fiducia cresce. È un'analogia ragionevole. Ma omette qualcosa sulla natura di ciò che viene delegato.
Quando un'azienda è migrata al cloud, ha delegato infrastruttura di calcolo. Gli errori erano costosi ma generalmente recuperabili: un server inattivo, un database lento, un servizio inaccessibile. Quando un'azienda distribuisce un agente autonomo in un processo decisionale, la categoria di errore cambia. Un agente che fraintende una presentazione regolamentare e consegna un'analisi errata alle 6 del mattino, sulla quale qualcuno prende decisioni prima che nessuno la revisioni, genera un tipo di danno diverso. La recuperabilità non è garantita dalla velocità del rollback tecnico.
Il modello di governance che AWS propone, dove gli esseri umani approvano le decisioni a livello di sistema mentre gli agenti eseguono a livello di compito, è concettualmente coerente. Ma funziona solo se la distinzione tra "livello di sistema" e "livello di compito" è definita con precisione all'interno di ciascuna organizzazione, e se chi opera al vertice comprende con sufficiente profondità cosa sta governando.
La promessa di autonomia che AWS ha portato al Summit è genuina nella sua ambizione. I limiti che ha installato accanto a quella promessa sono anch'essi genuini nella loro utilità. Ciò che nessuna delle due cose può sostituire è il lavoro di leadership che deve avvenire prima che qualsiasi agente tocchi un processo che conti. Quel lavoro non è glamour. Non ha slide da keynote. Ma è la condizione su cui poggia tutto il resto.
Le organizzazioni che usciranno meglio posizionate da questo ciclo non saranno quelle che hanno adottato gli agenti più velocemente. Saranno quelle che, prima di distribuirli, hanno saputo nominare con onestà ciò che non avevano ancora risolto.
