AWS porta agenti AI, fine-tuning e Kafka verso una piattaforma enterprise integrata

☁️ Punti chiave

• AgentCore Evaluations usa OpenTelemetry e OpenInference per testare agenti costruiti con framework differenti attraverso gli stessi criteri di qualità e comportamento.
• SageMaker SDK v3 semplifica BYOM e Script Mode, mentre AWS formalizza strategie di qualità, selezione e augmentation dei dataset per il fine-tuning.
• Amazon MSK abilita la migrazione in-place da ZooKeeper a KRaft e supporta Replicator verso cluster Kafka esterni protetti con OAuth 2.0.

AWS sta collegando valutazione degli agenti, addestramento dei modelli, deployment custom, analytics e streaming dati in una piattaforma sempre più orientata alla produzione enterprise. Il nuovo Amazon Bedrock AgentCore Evaluations permette di valutare agenti costruiti anche fuori dall’ecosistema AWS attraverso telemetria standardizzata; SageMaker AI semplifica il Bring Your Own Model con il nuovo SDK v3 e AWS formalizza un metodo più rigoroso per preparare dataset destinati al supervised fine-tuning. Parallelamente Amazon Quick entra nei workflow analitici di GoDaddy, AgentCore viene applicato alla pianificazione sanitaria di Natera e Amazon MSK riduce la complessità delle migrazioni Kafka da ZooKeeper a KRaft e da cluster OAuth esterni.

AgentCore Evaluations separa il testing dal framework usato per costruire l’agente

La novità più rilevante riguarda Amazon Bedrock AgentCore Evaluations, che affronta uno dei problemi crescenti dell’AI agentica: aziende diverse utilizzano LangGraph, LlamaIndex, OpenAI Agents SDK, Google ADK, Claude Agent SDK o Strands Agents, ma i sistemi di valutazione tendono spesso a dipendere dal framework scelto. AWS introduce invece un livello comune basato su OpenTelemetry e OpenInference. AgentCore ricostruisce ogni sessione analizzando tre categorie essenziali di span: invocazione dell’agente, chiamate ai modelli e utilizzo degli strumenti.

Da queste tracce può calcolare metriche come GoalSuccessRate, Correctness e Helpfulness, oltre a evaluator personalizzati basati su LLM. La scelta completa il percorso già avviato con AgentCore Observability e CloudWatch per rendere misurabili latenza, tool calling e memoria degli agenti. Le valutazioni possono essere eseguite on demand nelle pipeline CI/CD oppure continuamente su una percentuale del traffico reale, trasformando il testing dell’agente da fase manuale a componente del ciclo operativo.

OpenTelemetry diventa il linguaggio comune degli agenti enterprise

Il punto architetturale è che AgentCore non richiede che l’agente sia stato scritto con un SDK AWS. Se la telemetria segue le convenzioni OpenTelemetry GenAI oppure OpenInference e utilizza gli scope previsti, il servizio può interpretare prompt, output, chiamate agli strumenti e risultati. Questo permette a un’azienda di cambiare framework senza dover ricostruire l’intero livello di evaluation, riducendo un’altra forma di lock-in applicativo. AWS sta applicando la stessa filosofia alle architetture AgentCore multi-model e multi-framework orientate a governance e controllo delle azioni: il modello, il framework e il runtime diventano componenti sostituibili, mentre osservabilità, policy e valutazione rimangono livelli infrastrutturali stabili. Per i team enterprise questo significa poter confrontare agenti diversi utilizzando gli stessi dataset di test e gli stessi criteri, verificando non soltanto la qualità della risposta finale ma anche la traiettoria degli strumenti utilizzati per raggiungerla.

AWS formalizza come costruire dataset migliori per il supervised fine-tuning

Sul fronte del training, AWS pubblica due guide complementari dedicate alla preparazione dei dati. Nella prima parte sul supervised fine-tuning il principio centrale è che la qualità degli esempi pesa più della quantità. AWS raccomanda controlli preliminari su duplicati, errori, distribuzione delle classi, coerenza delle annotazioni e contaminazione tra training ed evaluation set, oltre alla corretta formattazione conversazionale in JSONL. La seconda parte dedicata alle strategie avanzate affronta invece selezione dei subset, filtraggio, data mixing e augmentation.

Particolare attenzione viene data ai dati sintetici e alle reasoning trace, utili quando il dataset reale è insufficiente ma pericolosi se introdotti senza verifica perché possono moltiplicare duplicati ed errori sottili. AWS colloca SFT tra continued pre-training e reinforcement fine-tuning: per molti foundation model moderni la combinazione SFT più RFT può essere sufficiente senza ricorrere necessariamente a un nuovo pre-training. È la prosecuzione del lavoro su SageMaker, Amazon Nova e pipeline di addestramento personalizzato, con un’attenzione crescente alla qualità del dato prima ancora che alla capacità computazionale.

SageMaker SDK v3 semplifica il Bring Your Own Model

AWS aggiorna anche il percorso per chi non vuole utilizzare esclusivamente modelli gestiti. Con Script Mode nel SageMaker Python SDK v3 gli sviluppatori possono portare codice personalizzato di training e inferenza dentro l’infrastruttura gestita SageMaker senza dover costruire e mantenere manualmente immagini Docker complete. Il concetto Script Mode esiste dal 2021, ma SDK v3 riduce il numero di primitive e uniforma training e deployment, velocizzando il passaggio dal codice locale a un job gestito e quindi a un endpoint di inferenza. Il modello è importante per aziende che utilizzano algoritmi proprietari, checkpoint sviluppati internamente o librerie che non rientrano nel catalogo standard. AWS cerca così di presidiare anche il BYOM: non obbligare il cliente a scegliere un foundation model del marketplace, ma rendere SageMaker il livello operativo su cui eseguire comunque training e serving.

Natera mostra come AgentCore entra in un workflow sanitario reale

Il caso Natera su Amazon Bedrock AgentCore mostra invece cosa significa portare un agente in produzione in un settore sensibile. L’azienda utilizza un voice agent per la pianificazione delle visite domiciliari per i prelievi, collegando telefonia, foundation model e servizi backend.

L’architettura utilizza un dual-WebSocket bridge, tecniche event-driven per mascherare la latenza e un modello di progressive trust: informazioni generiche possono essere fornite dopo una verifica minima, mentre conferma degli appuntamenti o accesso a dati sanitari richiedono autenticazione più forte. Natera ha migrato il workload da Amazon ECS ad AgentCore Runtime, che esegue gli agenti in microVM isolate con CPU, memoria e filesystem dedicati. È un esempio concreto della direzione già emersa con AgentCore e i framework per agenti AI verificabili: AWS non vende soltanto inferenza, ma runtime, memoria, sicurezza e gestione della sessione.

GoDaddy porta Amazon Quick dentro i processi analitici quotidiani

La trasformazione riguarda anche la business intelligence. Nel caso GoDaddy dedicato ad Amazon Quick, Amazon Redshift rimane il livello centrale di accesso ai dati mentre Okta gestisce il single sign-on. Quick aggiunge però funzioni come Quick Research, Quick Flows e agenti conversazionali, permettendo di automatizzare analisi e processi ricorrenti.

Il Weekly Business Review, per esempio, può essere alimentato da workflow automatici invece che da una sequenza manuale di raccolta e preparazione dei dati. GoDaddy integra inoltre le dashboard direttamente nei propri strumenti interni e prevede collegamenti con Slack, Outlook, Jira e Confluence. Il modello riprende l’evoluzione di Amazon Quick da piattaforma BI a livello semantico utilizzabile dagli agenti: insight e automazioni vengono portati dove gli utenti lavorano, invece di costringerli ad aprire un’applicazione separata.

Amazon MSK elimina ZooKeeper senza ricostruire i cluster Kafka

La modernizzazione scende infine sul livello dei dati in streaming. Con l’upgrade in-place da ZooKeeper a KRaft per Amazon MSK AWS permette ai cluster Kafka 3.9.x di migrare al nuovo sistema di metadata management senza ricreare l’infrastruttura e senza downtime previsto seguendo le best practice. KRaft incorpora il consenso basato su Raft direttamente in Kafka e sostituisce definitivamente ZooKeeper, rimosso con Apache Kafka 4.0. MSK crea temporaneamente i nuovi controller KRaft, migra i metadati, aggiorna progressivamente i broker, valida lo stato del cluster e soltanto alla fine elimina ZooKeeper. Cambiano anche monitoring e configurazioni operative, perché metriche e override specifici di ZooKeeper non sono più disponibili.

Parallelamente, la guida alla migrazione di cluster Kafka protetti con OAuth 2.0 estende MSK Replicator a identity provider come Keycloak, Okta, Microsoft Entra ID, PingFederate e Auth0 attraverso diversi grant OAuth. AWS sta quindi applicando alla pipeline dati la stessa strategia utilizzata per l’AI: ridurre il lavoro infrastrutturale necessario per spostare workload complessi verso servizi gestiti, mantenendo interoperabilità sufficiente da accogliere framework, modelli e cluster costruiti altrove.