AWS abbassa i costi dei dati e porta l’AI agentica dentro i processi enterprise

☁️ Punti chiave

• AWS Glue 6.0 riduce i prezzi del 30%, passa a Spark 4.1 e implementa pienamente Apache Iceberg v3 con nuovi tipi di dato.
• ADOP usa agenti AI per automatizzare pipeline Bronze-Silver-Gold mantenendo artefatti deterministici, controllabili e verificabili negli ambienti di produzione.
• AgentCore centralizza l’accesso agli strumenti mentre la compressione query-aware riduce i token inviati ai modelli principali nelle applicazioni RAG.

Amazon Web Services interviene contemporaneamente sui due livelli che stanno diventando decisivi per l’intelligenza artificiale aziendale: preparazione dei dati e governo degli agenti. AWS Glue 6.0 arriva con un prezzo inferiore del 30%, runtime basato su Apache Spark 4.1 e pieno supporto ad Apache Iceberg v3, mentre la nuova architettura Agentic Data Operations Platform prova a comprimere da settimane a ore il lavoro necessario per costruire pipeline dati. Sul versante AI, Amazon Bedrock AgentCore Gateway centralizza identità e autorizzazioni degli strumenti, mentre una tecnica di query-aware compression punta a ridurre il costo dei sistemi RAG eliminando contesto inutile prima dell’inferenza. Un’implementazione sviluppata con Panasonic Avionics mostra infine come questi componenti possano essere applicati alla diagnostica aeronautica.

AWS Glue 6.0 taglia i prezzi e completa il supporto ad Apache Iceberg v3

La novità infrastrutturale più immediata riguarda AWS Glue 6.0, disponibile nelle regioni nelle quali opera il servizio e proposto con una riduzione del prezzo del 30% rispetto alle versioni precedenti. Secondo l’annuncio ufficiale di AWS Glue 6.0, il nuovo runtime combina Spark 4.1, Python 3.12 e Scala 2.13 e introduce l’implementazione completa delle funzionalità Apache Iceberg v3 basata su Iceberg 1.11.0. Una delle novità principali è il tipo VARIANT con shredding, pensato per conservare e interrogare dati semi-strutturati come JSON, log ed eventi senza doverli appiattire preventivamente in schemi rigidi. Arrivano anche tipi nativi Geometry e Geography per i workload geospaziali, timestamp con precisione al nanosecondo e una gestione più resiliente dei tipi sconosciuti quando gli schemi cambiano a monte.

L’evoluzione si inserisce nella strategia lakehouse già emersa quando AWS aveva combinato Apache Iceberg, analisi conversazionale e accesso privato degli agenti, ma questa volta l’intervento riguarda direttamente costo e runtime della pipeline. Spark 4.1 aggiunge inoltre pipeline dichiarative, Python UDF e UDTF basate su Apache Arrow e una modalità di streaming real-time che AWS dichiara capace di raggiungere latenze nell’ordine dei singoli millisecondi per elaborazioni stateless.

ADOP usa gli agenti in sviluppo ma mantiene deterministica la produzione

Il passaggio successivo consiste nell’automatizzare la costruzione stessa delle pipeline. La Agentic Data Operations Platform, o ADOP è una reference architecture basata su Amazon Bedrock e strumenti di coding AI che orchestra agenti specializzati lungo l’intero percorso Bronze-Silver-Gold. AWS parte da un problema tipico dei team dati: integrare una nuova sorgente può richiedere settimane tra codice ETL, controlli di qualità, aggiornamento dei modelli semantici e verifiche di compliance.

ADOP utilizza invece agenti per generare PySpark, SQL, DAG Airflow, policy IAM e Cedar, ma adotta una scelta architetturale importante: il modello opera prevalentemente nella fase di sviluppo, mentre in produzione vengono promossi attraverso CI/CD artefatti deterministici e revisionabili. Il modello non resta quindi necessariamente dentro il percorso operativo della pipeline. È una distinzione rilevante rispetto all’idea di affidare un processo aziendale interamente a un agente autonomo e prosegue la trasformazione già osservata quando AWS ha automatizzato migrazioni Spark e processi complessi attraverso workflow agentici.

L’obiettivo non è soltanto accelerare il singolo sviluppatore, ma fare in modo che strumenti differenti come Claude Code, Kiro, Cursor e Codex producano risultati conformi alla stessa architettura, agli stessi controlli e alle stesse regole aziendali.

AgentCore Gateway porta identità e policy davanti agli strumenti degli agenti

Quando gli agenti iniziano invece a operare direttamente con database, API e strumenti interni, il problema diventa l’accesso. AWS descrive scenari nei quali credenziali di produzione finiscono dentro file locali mcp.json, mentre team diversi mantengono decine di configurazioni indipendenti senza sapere con precisione quale agente possa utilizzare una determinata risorsa. La proposta di governance basata su Amazon Bedrock AgentCore Gateway introduce un singolo punto di ingresso per il traffico agentico, integrando AgentCore Identity per autenticazione e gestione delle credenziali, AgentCore Policy per le autorizzazioni, Bedrock Guardrails per controlli aggiuntivi e AWS Agent Registry per catalogare gli strumenti disponibili.

La combinazione affronta problemi di credential sprawl, policy drift, audit incompleti, costi non attribuibili e shadow IT. In un’installazione minima, un client MCP può autenticarsi tramite JWT e raggiungere un tool registrato senza ricevere direttamente le credenziali del backend; CloudWatch e CloudTrail registrano invece quali risorse vengono utilizzate. È l’evoluzione naturale di AgentCore Gateway verso l’accesso privato alle infrastrutture aziendali: una volta risolta la connettività, AWS sta spostando il problema sulla capacità di stabilire chi può chiamare quale strumento, con quali privilegi e con quale tracciabilità.

La compressione query-aware riduce i token prima di interrogare il modello principale

Il costo rimane un altro vincolo importante quando l’AI viene utilizzata su grandi volumi. Nei sistemi Retrieval-Augmented Generation, recuperare più documenti aumenta la probabilità di fornire al modello l’informazione corretta, ma ogni chunk aggiunto al prompt aumenta contemporaneamente i token di input. AWS propone quindi un’architettura di query-aware compression per Amazon Bedrock che inserisce un modello più piccolo tra il retriever e il modello incaricato della risposta. Nell’esempio illustrato da AWS, Claude Haiku riceve la domanda e i chunk recuperati, estrae soltanto i passaggi testuali realmente pertinenti e consegna il contesto ridotto a Claude Sonnet, che genera la risposta finale. Il modello più costoso deve così elaborare meno token. L’approccio può essere applicato anche alle Knowledge Bases di Amazon Bedrock e combinato con prompt caching, Intelligent Prompt Routing e reranking. Il beneficio non è garantito in ogni scenario: aggiungere il modello di compressione introduce un ulteriore costo e una certa latenza, perciò il vantaggio cresce soprattutto quando il contesto recuperato è molto ampio e il rapporto di prezzo tra modello piccolo e modello principale è elevato. L’arrivo su Bedrock di modelli con finestre sempre più grandi, come Claude Opus 5 con un milione di token di contesto, rende paradossalmente ancora più importante decidere quali token valga davvero la pena pagare invece di riempire automaticamente la finestra disponibile.

Panasonic Avionics applica gli agenti alla diagnostica degli aerei

La trasformazione diventa concreta nel progetto realizzato da Panasonic Avionics Corporation insieme ad AWS e all’AWS Generative AI Innovation Center. I sistemi In-Flight Entertainment and Connectivity, distribuiti su configurazioni differenti e su una vasta flotta internazionale, producono log, metriche e ticket che devono essere correlati per individuare le cause di un malfunzionamento.

L’analisi manuale può richiedere ore e dipende fortemente dall’esperienza degli specialisti. Nell’architettura agentica sviluppata per la diagnostica IFEC i dati vengono normalizzati e conservati in un lakehouse Amazon S3 basato su Apache Iceberg, mentre AWS Glue e Amazon EMR gestiscono la pipeline ETL. Un Trend Analyzer individua degradazioni e anomalie, più agenti diagnostici eseguono in parallelo correlazioni, controlli di sistema e analisi dei log, mentre un LLM sintetizza risultati, possibile root cause e azioni raccomandate. Il modello mostra perché AWS stia lavorando contemporaneamente su Iceberg, Glue, Bedrock e governance: l’agente da solo non risolve il problema se i dati sottostanti sono incoerenti, se gli strumenti dispongono di privilegi opachi o se il contesto inviato ai modelli cresce senza controllo.

AWS porta l’agentic AI dalla demo alla disciplina operativa

Il filo comune degli aggiornamenti è quindi meno spettacolare, ma più importante, della semplice introduzione di un nuovo modello generativo. AWS sta costruendo i componenti necessari per trasformare l’agentic AI in una disciplina infrastrutturale: dati meno costosi da elaborare, pipeline generate più rapidamente, artefatti deterministici in produzione, accessi agli strumenti governati centralmente e contesti RAG ottimizzati prima dell’inferenza. È lo stesso passaggio emerso con AgentCore e i sistemi progettati per rendere gli agenti AI più efficienti e verificabili, ma ora il perimetro si amplia fino al livello dei dati. Glue 6.0 riduce direttamente il prezzo dell’elaborazione, ADOP interviene sul costo umano della data engineering, AgentCore Gateway limita il disordine degli accessi e la query-aware compression punta al costo variabile dell’inferenza. La strategia AWS diventa così abbastanza chiara: l’AI aziendale non deve soltanto funzionare, ma deve poter essere misurata, autorizzata, auditata e resa economicamente sostenibile prima di entrare nei processi critici.