Negli ultimi mesi, il concetto di Agentic AI è emerso come uno dei temi centrali nell’evoluzione dei sistemi informativi. Ma al di là dell’hype, ciò che sta realmente prendendo forma è una convergenza strutturale tra piattaforme cloud, framework open e architetture distribuite.
Questo articolo propone una lettura in tre atti: prima osservando la convergenza dei modelli nelle piattaforme hyperscaler, poi esplorando scenari ibridi e distribuiti orientati all’efficienza, e infine riportando il tutto nel contesto enterprise, dove entrano in gioco vincoli di governance, sicurezza e conformità.
Il risultato è una prospettiva unitaria in cui gli agenti non sono più semplici componenti applicativi, ma elementi infrastrutturali, da progettare e governare attraverso pattern architetturali come Zero Trust, Self-Contained Systems ed Event-Driven Architecture, supportati da pratiche CI/CD e Infrastructure as Code.
Table of Contents
Ouverture sul Quarto cerchio – Atto I – Convergenza
Negli articoli precedenti sul Quarto Cerchio abbiamo osservato come l’AI stia progressivamente smettendo di essere uno strumento per diventare una dimensione strutturale dell’ecosistema aziendale.
Un ecosistema che comprende software, piattaforme, dati, ma anche processi, persone e modelli operativi.
L’Interludio ci ha portato a fermarci un momento, a osservare il contesto, a prendere distanza dal rumore.
Ora è tempo di riprendere il tema.
Questa Ouverture nasce da una domanda che negli ultimi mesi è diventata inevitabile:
che cosa sta realmente emergendo sotto il termine “Agentic AI”?
Non come hype o come funzionalità di prodotto, ma come possibile nuova baseline tecnologica.
C’è però un aspetto che cambia radicalmente il modo in cui questo tema va affrontato.
Se osserviamo gli agenti dal punto di vista di un appassionato o di un contesto sperimentale, le opzioni disponibili sembrano quasi illimitate.
Ma in un ecosistema aziendale — soprattutto in ambiti regolati — la realtà è diversa.
Normative come NIS2, DORA e framework emergenti come ISO/IEC 42001 introducono vincoli concreti su:
• gestione del dato
• tracciabilità
• localizzazione
• auditabilità
In questo contesto, la domanda non è più “cosa è possibile fare”, ma: quali opzioni restano realmente praticabili.
Allo stesso tempo, sta emergendo un secondo fattore, meno visibile ma altrettanto rilevante: l’efficienza.
L’utilizzo intensivo di modelli di grandi dimensioni non è sempre sostenibile — né economicamente né operativamente — soprattutto quando gli agenti entrano in cicli iterativi o in scenari ad alta frequenza di invocazione.
Per questo motivo, iniziano a diffondersi approcci che affiancano ai modelli enterprise:
• modelli più leggeri, specializzati e a basso consumo di token
• esecuzioni distribuite tra cloud e ambienti locali
• logiche di orchestrazione ibride, in cui il modello “giusto” viene scelto in funzione del contesto
A questo punto è utile chiarire una scelta di campo.
In questa analisi prenderemo come riferimento principale le piattaforme cloud.
Non perché rappresentino l’unica opzione possibile, ma per alcuni motivi molto concreti:
• una conoscenza diretta e consolidata di questi ambienti
• il fatto che rappresentano oggi la più ampia capacità di calcolo distribuito disponibile a livello globale
• la presenza di framework e riferimenti consolidati per la conformità normativa su scala nazionale ed europea
Gli hyperscaler non sono solo fornitori di servizi, ma i principali punti di convergenza dove innovazione, scalabilità, integrazione e compliance vengono portate rapidamente a maturità.
Questo non esclude — anzi, rende ancora più interessante — la valutazione di scenari ibridi, in cui capacità computazionale e servizi possono essere distribuiti tra cloud pubblici e piattaforme dedicate.
Un esempio concreto, nel contesto italiano, è rappresentato da Intacture, piattaforma ad alta intensità computazionale sviluppata nell’ambito dell’iniziativa Trentino DataMine, fortemente voluta e supportata dal gruppo Dedagroup, che offre servizi avanzati, inclusi quelli legati alla GenAI.
Non si tratta quindi di scegliere tra cloud o alternative locali.
Si tratta di comprendere come queste opzioni possano coesistere in architetture ibride.
Per questo motivo, partiremo da ciò che viene proposto dai grandi player in ambito AI agentico, per poi osservare come queste capability possano essere estese, integrate o ribilanciate in contesti più articolati.
We can divide this history into distinct periods:
Opera in tre atti
Per provare a mettere ordine in questo scenario, questa Ouverture è articolata in tre atti, ciascuno osservato da una prospettiva diversa ma complementare.
Nel primo atto analizzeremo la convergenza che sta emergendo nelle principali piattaforme cloud, osservando come gli hyperscaler stiano costruendo, con approcci differenti, una base tecnologica sorprendentemente simile per lo sviluppo di sistemi agentici.
Nel secondo atto faremo un passo laterale, uscendo dal perimetro del cloud per osservare gli stessi pattern nel mondo dei framework open source e degli ambienti locali, dove le stesse capability emergono in forma più esplicita, meno astratta e spesso più flessibile.
Infine, nel terzo atto, riporteremo queste osservazioni nel contesto enterprise, per comprendere come questa convergenza venga filtrata, vincolata e resa operativa attraverso architetture, processi e modelli di governance.
La scelta di rappresentare questo percorso in tre atti non è casuale.
È un modo per rendere leggibile un fenomeno che, osservato nel suo insieme, rischia di apparire frammentato:
partire dall’offerta delle piattaforme, attraversare le alternative più flessibili e arrivare infine al punto in cui tutto questo deve essere governato.
L’obiettivo non è confrontare tecnologie, ma leggere un fenomeno:
capire se stiamo osservando una semplice evoluzione di strumenti o l’emergere di una nuova base infrastrutturale.
🎼 Atto I – La matrice di convergenza
Partendo da questo contesto, abbiamo provato a osservare direttamente cosa stanno proponendo le principali piattaforme cloud in ambito agentico.
Non attraverso confronti teorici, ma guardando ai servizi reali messi a disposizione dai principali hyperscaler: Amazon Web Services, Microsoft Azure, Google Cloud e Oracle Cloud Infrastructure.
L’analisi, almeno inizialmente, non è lineare.
Ogni piattaforma utilizza un proprio linguaggio, propone livelli di astrazione differenti e integra queste capability in modo profondamente legato al proprio ecosistema.
In alcuni casi si parla esplicitamente di agenti, in altri di estensioni, workflow o servizi intelligenti. Anche l’integrazione con dati e sistemi esterni viene raccontata con terminologie diverse, spesso difficili da confrontare direttamente.
A prima vista, il panorama appare frammentato.
Uno sguardo ai servizi
Se però entriamo nel dettaglio, iniziano a emergere elementi interessanti. Su Amazon Web Services, servizi come Agents for Bedrock si presentano come un layer capace di orchestrare modelli, integrare basi di conoscenza e invocare servizi esterni, mantenendo uno stretto legame con l’ecosistema AWS.
Nel caso di Microsoft Azure, le capability agentiche si distribuiscono tra Azure AI Agent Service e l’intero stack Copilot, con una forte integrazione con identità, strumenti di sviluppo e piattaforme di produttività già presenti in azienda.
Su Google Cloud, soluzioni come Vertex AI Agents ed Extensions propongono un modello più aperto, orientato all’interoperabilità con framework esterni e alla composizione di capacità distribuite.
Infine, Oracle Cloud Infrastructure esplicita in modo molto diretto le componenti agentiche, introducendo servizi in cui tool, dati e orchestrazione diventano primitive dichiarate della piattaforma.
Dal catalogo dei servizi al modello
A questo punto, qualcosa cambia.
Al di là dei nomi e delle differenze di presentazione, osservando questi servizi in modo trasversale emerge un pattern ricorrente.
Le stesse capability riappaiono, con forme diverse ma con responsabilità sorprendentemente simili.
Ciò che inizialmente sembrava frammentazione inizia a rivelare una struttura.
È proprio da questa osservazione che emerge la matrice di convergenza.
I blocchi che si ripetono
Analizzando le diverse piattaforme, è possibile identificare alcuni elementi fondamentali che si ripresentano sistematicamente.
Un primo blocco è rappresentato da un runtime agentico, ovvero un componente capace di orchestrare sequenze di azioni, mantenere stato e coordinare l’interazione tra modello, strumenti e dati.
Accanto a questo, emerge la presenza di meccanismi di tool calling, che permettono all’agente di invocare sistemi esterni — API, servizi applicativi, funzioni — in modo strutturato e controllato.
Un terzo elemento ricorrente è rappresentato dai pattern di RAG (Retrieval-Augmented Generation), che collegano il modello a basi di conoscenza, rendendo possibile un grounding contestuale delle risposte e delle azioni.
Infine, tutte le piattaforme si appoggiano a un data backbone ibrido, che combina dati strutturati e rappresentazioni vettoriali, spesso distribuiti su più livelli di storage.
A questo punto emerge una prima conclusione chiave:
- L’agente non è un chatbot avanzato.
- È un runtime di coordinamento tra modello, strumenti e dati.
La matrice di convergenza
Questi elementi possono essere sintetizzati in una matrice che rende esplicita la convergenza osservata:
La matrice di convergenza
Questi elementi possono essere sintetizzati in una matrice che rende esplicita la convergenza osservata:
| Blocco | Amazon Web Services | Microsoft Azure | Google Cloud | Oracle Cloud Infrastructure |
| Agent runtime | Agents for Bedrock | Azure AI Agent Service / Copilot | Vertex AI Agents | OCI Generative AI Agents |
| Tool calling | Lambda, API Gateway | Azure Functions, Logic Apps | Cloud Functions, Extensions | OCI Functions |
| RAG / grounding | Knowledge Bases for Bedrock | Azure AI Search | Vertex AI Search / RAG Engine | OCI Search |
| Data backbone | S3, DynamoDB, Vector DB | Data Lake, Cosmos DB, Vector Search | BigQuery, Vector Search | Autonomous DB, Vector |
Questa rappresentazione semplifica un punto fondamentale.
Non stiamo osservando funzionalità isolate, ma un modello che si ripete.
Un modello che emerge indipendentemente dal vendor e che tende a stabilizzarsi.
Una lettura architetturale
Se rileggiamo questa matrice in chiave architetturale, emerge una separazione molto netta delle responsabilità:
- il runtime governa il flusso
- i tool estendono le capacità operative
- il retrieval collega il sistema al contesto informativo
- il backbone dati garantisce consistenza e persistenza
Emerge quindi una struttura convergente, replicabile, scalabile, governabile in contesti enterprise ed in qualche modo indipendente almeno concettualmente dalla proposta dell’hyperscaler specifico, se ben organizzata a livello architetturale
La divergenza nella gestione della compliance
Se la struttura tecnica tende a convergere, il tema della compliance introduce un ulteriore livello di differenziazione, meno visibile ma estremamente rilevante in contesti enterprise.
Le normative di riferimento restano le stesse — come NIS2, DORA o gli standard emergenti come ISO/IEC 42001 — ma il modo in cui queste vengono supportate varia sensibilmente tra le piattaforme.
In alcuni casi, i meccanismi di controllo sono profondamente integrati nei servizi: identità, autorizzazioni, logging e tracciabilità diventano parte naturale del funzionamento dei sistemi agentici. Questo rende più immediata l’adozione in contesti regolati, perché molti requisiti sono già incorporati nella piattaforma.
In altri scenari, invece, la piattaforma mantiene un approccio più neutro e flessibile. Le stesse capability sono disponibili, ma richiedono una composizione esplicita: è l’architettura a dover costruire il livello di governance necessario, definendo regole, controlli e processi.
Questo introduce una differenza sottile ma fondamentale.
Non cambia la possibilità di essere compliant, ma cambia il punto in cui la responsabilità viene esercitata.
In un caso è prevalentemente incorporata nella piattaforma.
Nell’altro è distribuita tra architettura, processi e team.
E questo ha un impatto diretto non solo sulla progettazione, ma anche sulla gestione operativa, sull’audit e sulla sostenibilità nel tempo delle soluzioni adottate.
Una scelta che resta contestuale
A questo punto, la domanda naturale non è quale piattaforma scegliere in assoluto, ma quale approfondire in relazione al contesto specifico in cui ci si muove.
Le differenze che emergono — in termini di integrazione, apertura, gestione della compliance e modelli operativi — non definiscono una gerarchia, ma delineano scenari di adozione differenti.
In alcuni casi, può essere naturale orientarsi verso piattaforme che offrono un elevato livello di integrazione e una maggiore aderenza ai requisiti enterprise già a livello di servizio.
In altri, può risultare più efficace approfondire soluzioni che privilegiano flessibilità e composizione, soprattutto quando l’obiettivo è costruire architetture ibride o mantenere un maggiore controllo sui singoli componenti.
Per questo motivo, più che cercare una scelta definitiva, ha senso affrontare il tema con un approccio progressivo:
analizzare le proposte dei singoli hyperscaler, comprenderne i modelli operativi e valutare come questi si inseriscono nel proprio contesto architetturale, normativo e organizzativo.
- Non esiste una piattaforma “giusta” in senso assoluto.
- Esiste una piattaforma più coerente rispetto al problema che si sta cercando di risolvere.
Ma questa convergenza, così evidente nel cloud, è davvero limitata a questo perimetro?
Nel secondo atto proveremo ad allargare lo sguardo, esplorando scenari in cui queste stesse logiche vengono applicate al di fuori delle piattaforme hyperscaler.
In particolare, analizzeremo come sia possibile costruire architetture che mantengano i requisiti normativi e di governance richiesti in ambito enterprise, introducendo al tempo stesso elementi di ottimizzazione, differenziazione e controllo.
Scenari in cui modelli più leggeri, componenti specializzati e modalità di esecuzione locali o ibride iniziano a giocare un ruolo sempre più rilevante.
Non come alternativa al cloud, ma come estensione naturale del modello che abbiamo appena osservato.
Lascia un commento