L’AI agentica sta entrando in una fase nuova: non più semplici sperimentazioni o chatbot evoluti, ma sistemi autonomi capaci di operare su dati, applicazioni e workflow per ore o giorni, con un impatto diretto sui processi core. In questo scenario, il passaggio dal proof of concept alla produzione richiede scelte architetturali, governance e competenze diverse. Ne parliamo con Antonio d’Ortenzio, Solutions Architect Manager di AWS Italia, per capire come i Frontier Agents puntino a rendere concreto il modello “agent-first” anche nel contesto italiano
Con Frontier Agents parlate di sistemi capaci di lavorare per ore o giorni in autonomia. In Italia però molte aziende sono ancora ferme ai proof of concept. Qual è, secondo voi, il primo passo concreto per passare dagli esperimenti isolati a agenti AI realmente operativi nei processi core?
Molte aziende italiane si trovano effettivamente ancora in una fase sperimentale, e c’è una ragione precisa: gli agenti AI sono osservati con maggiore cautela rispetto all’AI conversazionale tradizionale, per la loro autonomia, per la possibilità di manifestare comportamenti non deterministici e per la capacità di prendere decisioni ed eseguire azioni nel mondo reale. Tutto questo pone importanti sfide di governance. Proprio per sostenere questa evoluzione abbiamo lanciato Amazon Bedrock AgentCore: una suite di servizi gestiti che consente di portare gli agenti AI dal prototipo alla produzione in modo sicuro e scalabile.
Non si tratta solo di servizi tecnici, ma di otto aree di focus fondamentali per rendere realmente produttivi i prototipi agentici.
Parliamo di:
Runtime, un ambiente sicuro che ospita ed esegue agenti AI, gestendo automaticamente scalabilità e isolamento delle sessioni;
- Memory, per mantenere il contesto e apprendere dalle esperienze;
- Gateway, per collegare gli agenti a tool, API e servizi esterni (oltre 300);
- Identity, per autenticazioni e autorizzazioni sicure;
- Observability, per monitorare in tempo reale le attività degli agenti;
- Evaluations, per verificare la correttezza delle decisioni prese;
- Code Interpreter, per eseguire e fare debugging del codice in ambienti sandbox sicuri;
- Browser, per interagire con i siti web in modo automatizzato tramite un runtime gestito e protetto.
Queste aree, che in un PoC possono non emergere, diventano critiche quando un agente deve operare su scala globale per milioni di utenti. Il primo passo concreto? Tre elementi: disporre di una data platform ben strutturata, perché gli agenti lavorano male se i dati non sono organizzati correttamente; identificare use case ad alto impatto, in cui sia possibile misurare chiaramente i benefici; adottare infine un approccio olistico che affronti sicurezza e compliance fin dall’inizio, e non come considerazioni dell’ultimo momento.
Dal vostro osservatorio, a che punto è l’adozione dell’AI agentica in Italia rispetto ad altri Paesi europei? Vedete una domanda più orientata all’efficienza operativa, allo sviluppo software o alla trasformazione dei modelli di business?
Dal nostro punto di osservazione vediamo un’adozione in crescita, ma non ancora pienamente strutturata. Ci sono molti tentativi e numerose sperimentazioni che, però, spesso non risultano coordinate nemmeno all’interno della stessa azienda.
I nostri partner italiani, come Reply, stanno costruendo attivamente la loro identità Gen AI insieme ad AWS, e osserviamo casi interessanti in cui l’innovazione AI per il mercato B2B italiano accelera in modo concreto. La domanda che riceviamo copre tutti e tre gli ambiti che hai citato.
C’è chi punta all’efficienza operativa, e in questo caso disponiamo di soluzioni come Amazon Quick Suite, che velocizzano i processi quotidiani. C’è chi si focalizza sullo sviluppo software, dove entra in gioco Kiro, con il suo Autonomous Agent capace di lavorare in autonomia per ore o giorni.
Infine c’è la trasformazione dei modelli di business, che è soprattutto una sfida culturale e organizzativa: qui supportiamo le aziende attraverso programmi di formazione e iniziative di modernizzazione delle applicazioni legacy. In sintesi, il mercato italiano è pronto, ma è necessario un cambio di mentalità: passare dalla sperimentazione isolata a iniziative strutturate, guidate da obiettivi chiari.
Molte aziende oggi usano l’AI come semplice chatbot o assistente. Con Frontier Agents si entra in una logica di sistemi che agiscono su dati, applicazioni e workflow. Quali cambiamenti architetturali sono necessari per supportare agenti persistenti e affidabili in produzione?
Molte aziende oggi utilizzano l’AI ancora come un semplice chatbot. Con gli agenti entriamo invece in una logica completamente diversa: sistemi che agiscono su dati, applicazioni e workflow, che mantengono memoria e che sono in grado di scalare in autonomia. I cambiamenti architetturali necessari sono sostanzialmente quelli che citavo prima e che trovano una copertura completa nei moduli di AgentCore.
Dal momento che citavi i Frontier Agents, vale la pena spiegare cosa ci ha spinto a crearli. AWS ha sviluppato i Frontier Agents ascoltando le esigenze concrete degli sviluppatori, che spesso si ritrovavano a fare da “collante umano” tra sistemi e processi diversi. I team segnalavano di perdere molto tempo nel ricostruire il contesto quando cambiavano attività, nel coordinare manualmente modifiche su più repository e nel ricollegare informazioni frammentate tra ticket, pull request e chat. Servivano agenti capaci di lavorare in modo più indipendente e persistente.
Da questi feedback è nata l’idea di creare agenti con tre caratteristiche distintive:
- Autonomi: capaci di pianificare ed eseguire task dall’inizio alla fine senza supervisione continua, liberando gli sviluppatori da compiti ripetitivi
- Scalabili: in grado di gestire più attività in parallelo o coordinare il lavoro tra diversi agenti
- Long-running: capaci di mantenere il contesto e lavorare per ore o giorni su problemi complessi, senza perdere il filo del discorso
L’obiettivo era evolvere da semplici “assistenti”, utili su singoli task, a veri e propri “compagni di squadra virtuali” capaci di portare avanti workflow complessi in autonomia. I test interni di Amazon hanno mostrato guadagni di produttività compresi tra 5 e 10 volte su progetti greenfield.
I tre Frontier Agents annunciati da AWS
- Kiro autonomous agent: agente per lo sviluppo software che gestisce bug, scrive codice, esegue test e crea pull request mantenendo il contesto su più repository.
- AWS Security Agent: esegue design review, controlli di sicurezza automatici su codice e PR, e penetration testing con raccomandazioni per le correzioni.
- AWS DevOps Agent: monitora l’infrastruttura, gestisce incident triage, identifica le cause principali dei problemi e suggerisce miglioramenti di resilienza.
Il tessuto italiano è fatto di ERP storici, applicazioni custom e infrastrutture ibride. Quanto è realistico inserire agenti AI in questo contesto senza dover riscrivere tutto da zero? E quali sono gli ostacoli che incontrate più spesso sul campo?
In Italia il tessuto aziendale è composto da ERP storici, applicazioni custom e infrastrutture ibride. La buona notizia è che, grazie agli agenti, non è necessario riscrivere tutto da zero. L’approccio è modulare: AgentCore Gateway consente di esporre servizi esistenti — REST API, funzioni Lambda, schemi OpenAPI — come tool utilizzabili dagli agenti.
Un esempio concreto: stiamo collaborando con un produttore di enterprise application per integrare agenti AWS con sistemi ERP legacy. L’obiettivo è permettere agli agenti di dialogare in modalità cross-platform senza spostare i dati. Se un chatbot riceve una richiesta e le informazioni necessarie sono in parte su sistemi enterprise interni e in parte su AWS, gli agenti comunicano tra loro, combinano i dati e restituiscono la risposta all’utente, che non percepisce la complessità sottostante.
In questo percorso, gli ostacoli più comuni sono tre.
- Il primo è la qualità dei dati: dataset non preparati per gli LLM rappresentano la principale causa di fallimento dei PoC.
- Il secondo riguarda sicurezza e compliance; in questo ambito, guardrail e policy engine aiutano a mitigare i rischi.
- Il terzo è la complessità architetturale, che può essere ridotta in modo significativo adottando servizi gestiti invece di sviluppare ogni componente da zero.
Un agente che prende iniziative autonome introduce nuove responsabilità. Come affrontate temi come auditabilità delle decisioni, controllo delle azioni, gestione degli errori e sicurezza operativa, soprattutto nei settori regolamentati?
Questo è un tema cruciale, soprattutto quando si parla di agenti capaci di prendere iniziative autonome. Proprio per questo abbiamo annunciato a re:Invent 2025 nuove funzionalità dedicate. Innanzitutto AgentCore Policy, che intercetta in tempo reale ogni chiamata a un tool e definisce confini operativi chiari. L’aspetto più interessante è che queste policy possono essere espresse in linguaggio naturale: non è necessario conoscere linguaggi di policy, si scrivono in forma narrativa e il sistema le converte automaticamente in Cedar, il nostro linguaggio di policy open source.
Dal punto di vista dell’auditability del comportamento degli agenti, abbiamo introdotto AgentCore Evaluations, che include 13 evaluator built-in per dimensioni come correttezza, helpfulness, accuratezza nella selezione dei tool e safety, oltre alla possibilità di definire evaluator custom. A questo si aggiunge un monitoraggio continuo con alert automatici su CloudWatch. Inoltre, ogni decisione dell’agente è completamente tracciata: reasoning steps, invocazioni dei tool e interazioni con i modelli sono tutte registrate. Tutto è visibile, tutto è verificabile.
Infine, è importante sottolineare che per AWS la sicurezza è “job zero” in tutti i settori, non solo in quelli regolamentati. Quando progettiamo una soluzione la pensiamo per tutti: non introduciamo controlli aggiuntivi solo dove vengono richiesti, perché la sicurezza è sempre by design.
Gli agenti AI cambiano il ruolo di sviluppatori, IT e operations. Che tipo di skill stanno diventando davvero critiche? E cosa dovrebbe fare oggi un CIO italiano per preparare il proprio team a un modello “agent-first”?
Questa domanda tocca il nodo centrale del cambiamento organizzativo. Gli agenti AI stanno effettivamente trasformando il ruolo di sviluppatori, IT e operations. Le skill critiche stanno evolvendo: meno coding tradizionale e più capacità di orchestrazione. Con Kiro e gli altri Frontier Agents, il focus si sposta dalla scrittura del codice alla definizione degli obiettivi e alla supervisione. Diventano fondamentali skill come prompt engineering, agent design, la definizione dei comportamenti e dei guardrail. L’aspetto interessante è che, grazie alle policy espresse in linguaggio naturale, non è più necessaria una competenza tecnica profonda: oggi chiunque può definire regole di sicurezza in modo comprensibile e strutturato.
Cosa fare, quindi? Primo, investire nell’upskilling dei team: formare gli engineer sul linguaggio del cloud fa una differenza concreta, anche partendo da una certificazione base come AWS Cloud Practitioner. Secondo, creare una cultura di sperimentazione sicura, ad esempio attraverso incubator e hackathon in cui l’esplorazione sia esplicitamente “safe to fail”. Terzo, istituire gruppi interni che coinvolgano executive, compliance, legal e subject matter expert, così da centralizzare le decisioni e accelerare l’adozione.
Osserviamo aziende che investono in modo significativo nella formazione cloud: alcune hanno certificato centinaia di ingegneri con AWS Cloud Practitioner per assicurarsi che tutti parlino lo stesso linguaggio tecnico, ottenendo un’accelerazione notevole nell’adozione. In definitiva, non si tratta tanto di acquisire nuove skill tecniche, quanto di un cambio di mentalità. Passare da un modello in cui tutto è controllato manualmente a un approccio “agent-first”, in cui si definiscono obiettivi e guardrail e poi si lascia che gli agenti operino in autonomia. È prima di tutto un salto culturale, ancora prima che tecnologico.
