AWS governa gli agenti AI con Dogwood, architetture aperte e controllo dei costi

🤖 Cosa cambia

• AgentCore traduce regole aziendali scritte in linguaggio naturale in policy Dogwood applicate in tempo reale alle azioni e alle sequenze degli agenti.
• AWS propone architetture multi-model e multi-framework che separano controllo ed esecuzione, mentre AgentCore automatizza discovery, IaC, governance e operazioni nelle migrazioni cloud.
• SageMaker Unified Studio aggiunge un modello FinOps basato su CUR e tag personalizzati per attribuire correttamente i costi di AI e analytics ai progetti.

AWS sta spostando il problema degli agenti AI dalla semplice capacità del modello alla governance dell’infrastruttura che consente agli agenti di agire. Cinque nuove architetture pubblicate dall’azienda affrontano policy, vendor lock-in, migrazioni cloud, retrieval vettoriale e controllo dei costi attraverso Amazon Bedrock AgentCore e SageMaker Unified Studio. Il filo comune è netto: un agente enterprise non può essere governato soltanto attraverso il system prompt. Servono policy deterministiche sugli strumenti, identità, osservabilità, routing, isolamento e attribuzione economica delle risorse. È la stessa necessità emersa quando AgentCore ha mostrato quanto sia delicato separare la decisione del modello dall’autorizzazione effettiva degli strumenti.

Dogwood trasforma le policy aziendali in regole applicate agli agenti

La novità più interessante riguarda Policy Authoring in Amazon Bedrock AgentCore, capace di convertire documenti scritti in linguaggio naturale nel linguaggio open source Dogwood. Il sistema non si limita a vietare un singolo tool: può imporre ordine temporale, prerequisiti, rate limit e limiti cumulativi. Nell’esempio di AWS, un agente bancario può effettuare un trasferimento soltanto se l’identità è stata verificata sullo stesso conto nei 15 minuti precedenti, impedire più di tre tentativi di rimborso in un’ora o bloccare trasferimenti che superino complessivamente 50.000 dollari in 12 ore.

Le policy vengono applicate dal monitor Dogwood integrato in AgentCore Gateway, con filosofia default-deny, e possono richiamare Bedrock Guardrails per controllare anche testo libero. AWS precisa però che la traduzione automatica va revisionata dall’uomo: una policy sintatticamente valida può comunque non rappresentare correttamente l’intenzione originale. Il passaggio rafforza il modello già introdotto con MCP stateless e AgentCore Gateway, dove sicurezza e routing vengono spostati dall’agente verso l’infrastruttura.

Il vendor lock-in si combatte standardizzando il controllo, non il modello

Nel secondo modello architetturale dedicato agli ambienti agentici enterprise AWS parte da un’osservazione realistica: le grandi aziende finiranno inevitabilmente con sistemi multi-model, multi-framework e multi-provider. Imporre un unico modello o framework rischia quindi di produrre più lock-in che governance.

La proposta consiste nel centralizzare ciò che sta sotto l’applicazione — identità, policy enforcement, osservabilità, routing e attribuzione dei costi — lasciando decentralizzata l’esecuzione degli agenti. Il control plane diventa stabile mentre modelli e framework possono cambiare. Anche il routing dovrebbe essere dinamico, scegliendo risorse differenti in base a costo, latenza e accuratezza.

È un’impostazione coerente con l’evoluzione di AgentCore verso agenti più verificabili e infrastrutture intercambiabili, ma introduce una conseguenza importante: la vera dipendenza strategica non si misura più soltanto dal modello utilizzato, bensì da chi controlla identità, telemetria, memoria, gateway e autorizzazioni.

Quattro agenti riducono da settimane a minuti la creazione dell’infrastruttura

AWS applica questa impostazione anche alle migrazioni cloud attraverso un framework multi-agent costruito su Bedrock AgentCore. L’architettura separa Intake Agent, dedicato alla discovery e alle dipendenze, IaC Agent, che genera Infrastructure as Code, Migration Intelligence and Governance Agent, responsabile delle valutazioni e del reporting, e SRE Agent, destinato alle operazioni successive alla migrazione. AWS Professional Services dichiara che, in un progetto comprendente oltre 300 applicazioni, il tempo necessario per produrre IaC è passato dalle tradizionali 3-4 settimane per applicazione a pochi minuti, sulla base dei dati interni del progetto.

Gli agenti comunicano con gli strumenti tramite MCP, utilizzano ruoli IAM limitati e condividono lo stato attraverso AgentCore Memory. L’automazione resta però subordinata a controlli umani e policy: gli incidenti recenti nei quali agenti AI hanno raggiunto workflow e infrastrutture reali dimostrano perché velocizzare una migrazione senza confinare strumenti e privilegi aumenterebbe contemporaneamente la superficie di rischio.

I vettori restano dove sono già i dati aziendali

Sul retrieval AWS propone invece un principio volutamente semplice: non spostare i dati solo per aggiungere la ricerca vettoriale. Nel modello dedicato alle vector solutions l’azienda raccomanda di utilizzare le capacità vettoriali direttamente in OpenSearch Service, S3, Aurora PostgreSQL, DynamoDB, ElastiCache per Valkey o Neptune, scegliendo un servizio differente soltanto quando esiste una reale necessità.

L’obiettivo è eliminare copie, sincronizzazioni e nuovi layer operativi, mantenendo vettori e dati originali nello stesso ambiente. Per i workload nuovi AWS indica OpenSearch come soluzione generalista per ricerca lessicale, vettoriale e ibrida, mentre GraphRAG, knowledge graph e retrieval multimodale possono utilizzare engine più specializzati. È una scelta architetturale importante perché il costo degli agenti non dipende soltanto dai token: aumentano anche storage, embedding, sincronizzazione, query e infrastrutture dedicate al contesto.

SageMaker porta il FinOps direttamente dentro i progetti AI

Proprio il costo diventa il quinto livello della governance. In una nuova architettura FinOps per SageMaker Unified Studio AWS affronta il limite per cui tag personalizzati come CostCenter, Team ed Environment non vengono propagati automaticamente a tutte le risorse dinamiche create attraverso Studio. La soluzione utilizza EventBridge e Lambda per registrare l’associazione tra progetto e tag in DynamoDB, mentre un job AWS Glue arricchisce i dati del Cost and Usage Report 2.0 conservati in S3; Athena e Quick Sight producono infine dashboard dei costi per progetto, team o centro di spesa.

Il tema sviluppa quanto già emerso nell’analisi sul costo reale dell’AI e sulla necessità di misurare l’intero stack anziché il solo prezzo dell’inferenza. Governance degli agenti significa ormai governare contemporaneamente ciò che possono fare, quali dati possono raggiungere, quale infrastruttura utilizzano e quanto ogni decisione autonoma costa all’organizzazione. È questo, più del singolo modello, il livello sul quale AWS sta costruendo la propria piattaforma agentica enterprise.