AWS ha annunciato due nuovi servizi al Summit di New York del 17 giugno 2026: Context e Continuum, pensati per risolvere i problemi strutturali che frenano l’adozione degli agenti AI in ambiente enterprise. Il comunicato ufficiale pubblicato su aboutamazon.com li descrive come la risposta ai due nodi che l’industria non ha ancora sciolto: la cecità sul contesto aziendale e la fragilità del codice generato automaticamente.
Il problema non è la capacità degli agenti, ma la loro ignoranza strutturale. Un agente AI può ragionare su un task complesso e produrre output tecnicamente corretti, eppure restare del tutto cieco su come funziona davvero l’azienda che lo ha messo in produzione: quali sono le politiche interne, chi ha accesso a cosa, cosa si intende per “cliente prioritario” in quel contesto specifico. Nello stesso tempo, il codice che questi agenti producono arriva spesso con vulnerabilità che sfuggono ai controlli tradizionali, perché i tool di sicurezza legacy non sono stati progettati per analizzare produzione ad alta velocità. AWS ha deciso di affrontare entrambe le lacune con un approccio infrastrutturale, non con patch.
Un agente che non conosce l’azienda è come un consulente che non ha letto il contratto
AWS Context costruisce automaticamente un knowledge graph dai dati aziendali esistenti: database, documenti, email, conversazioni di chat aziendale. Questo grafo diventa una base di conoscenza condivisa, disponibile a tutti gli agenti dell’organizzazione senza che ciascuno debba ricostruire il contesto da zero a ogni nuova istanza. I controlli di accesso sono nativi: l’agente vede solo ciò che il profilo utente che lo ha attivato ha il permesso di vedere, senza configurazioni manuali aggiuntive.
Senza contesto condiviso, ogni agente reinventa le regole e sbaglia.
La logica è semplice quanto lo è stata a lungo ignorata: ogni messa in produzione di un agente che parte da zero sul contesto è una messa in produzione che sbaglia per difetto, non per eccesso. Context inverte questo schema portando la conoscenza al livello dell’infrastruttura, non della singola applicazione. Non è un RAG configurato manualmente per ogni caso d’uso: è un layer aziendale trasversale che si aggiorna in modo continuo dai sistemi sorgente.
Per chi ha già provato a far funzionare agenti AI in produzione, questo risolve uno dei punti di attrito più costosi: il lavoro sommerso di “contestualizzazione” che i team interni devono fare manualmente per ogni nuovo agente, spiegandogli chi è l’azienda, cosa fa e come. Con Context, quella conoscenza esiste una volta sola e viene condivisa. È un pattern che chi ha lavorato con sistemi di identità aziendale riconosce: il principio dell’unica fonte di verità applicato al contesto cognitivo degli agenti.
AWS Continuum affronta invece il secondo problema: la sicurezza del codice AI-generato. Il servizio copre l’intero ciclo delle vulnerabilità, dalla discovery alla prioritizzazione, dalla validazione alla correzione automatica. Come descritto nel blog ufficiale AWS Security, il sistema parte in modalità “learning”: osserva, segnala, propone correzioni, ma richiede l’approvazione umana prima di agire. Solo dopo una fase di calibrazione può passare in “enforcement mode”, in cui la correzione avviene in autonomia.
Gli agenti scrivono codice veloce. Non sanno ancora dove stanno mettendo le mani.
La scelta di rendere il learning mode il punto di ingresso obbligatorio non è casuale. AWS ha imparato, a proprie spese, che la velocità di produzione del codice AI-generato può superare la capacità di supervisione umana. Nel 2026 si sono verificati due interruzioni di servizio attribuite a Kiro, il coding agent AWS. A febbraio l’azienda ha introdotto una policy interna che richiede ingegneri senior per approvare tutto il codice AI-generato prima del merge. Continuum è, in parte, la risposta infrastrutturale a quella policy: uno strumento che non si limita a rilevare le vulnerabilità ma le valida e le corregge in modo sistematico, riducendo il carico di revisione manuale. Per il rilevamento, AWS cita tra i modelli che alimentano Continuum Claude Mythos di Anthropic, specializzato nell’analisi di vulnerabilità software.
Sul fronte dei tool esistenti, gli annunci del Summit portano novità anche per DevOps Agent, che riceve due funzionalità in anteprima: una Release Readiness Review automatizzata e la generazione di un piano di test derivato dinamicamente dalla specifica modifica apportata al codice. Non test generici, ma test costruiti sul delta: il sistema capisce cosa è cambiato e genera la copertura necessaria per validare esattamente quella modifica, non l’intero progetto. Come spiegato nel blog ufficiale AWS, l’obiettivo è ridurre il tempo tra il commit e la validazione senza abbassare la qualità del controllo.
Kiro arriva su iOS come app nativa per il controllo da smartphone. L’accesso è riservato ai clienti a pagamento: una scelta che segnala come AWS stia posizionando Kiro come tool professionale con livelli di servizio definiti, non come strumento aperto a tutti. La disponibilità mobile non modifica il flusso di sviluppo, ma consente ai team di monitorare e approvare task in corso senza essere alla scrivania.
Bedrock AgentCore si espande con una knowledge base gestita e connettori nativi a S3, SharePoint, Confluence e Google Drive, più una web search integrata e filtri di sicurezza contro la manipolazione via prompt. Queste aggiunte completano il quadro: Bedrock AgentCore diventa la piattaforma su cui Context e Continuum si appoggiano, un layer di orchestrazione che connette contesto, strumenti, sicurezza e modelli. Chi ha già agenti gestiti su Bedrock trova un ecosistema che si è allargato in tutte le direzioni rilevanti.
La risposta infrastrutturale di AWS agli annunci del Summit è coerente e ben costruita. Context e Continuum non sono funzionalità aggiuntive: sono tentativi di risolvere problemi di classe, quelli che bloccano non una singola implementazione ma l’intera categoria degli agenti in produzione. Portare il contesto aziendale a livello di infrastruttura condivisa è la mossa giusta, e l’integrazione con i controlli di accesso esistenti fa sì che non sia necessario ridisegnare la governance ogni volta che si aggiunge un agente.
Il punto critico, però, è quello che GeekWire ha sintetizzato bene nell’analisi degli annunci: AWS sta cercando di bilanciare autonomia e controllo umano, un equilibrio che Continuum incarna esplicitamente con la distinzione tra learning mode e enforcement mode. La domanda che ogni organizzazione deve porsi prima di passare in enforcement mode non è tecnica: è di governance. Chi decide che l’agente ha imparato abbastanza? Sulla base di quali metriche? Con quale processo di escalation in caso di errore?
L’interruzione di servizio causata da Kiro non è stata risolta da Continuum: è stata tamponata con una policy manuale (l’approvazione degli ingegneri senior) in attesa che l’infrastruttura si adeguasse. Continuum è quella infrastruttura. Ma la policy manuale è rimasta, e su questo AWS è stata prudente nelle comunicazioni. La transizione verso l’autonomia piena non è un interruttore da accendere: è un percorso che richiede dati, fiducia accumulata e confini espliciti. Il rischio, per le organizzazioni che adottano questi tool, è di bruciare le tappe spinte dalla promessa dell’enforcement mode senza aver costruito le basi del learning mode. Restano lacune critiche ancora aperte sul fronte dell’identità degli agenti e della loro tracciabilità in ambienti multi-cloud, e AWS ha indicato quattro principi per la sicurezza dell’AI agentica che Context e Continuum cominciano finalmente a tradurre in prodotto.
Dagli agenti AI personalizzati alla formazione.
C’è molto che possiamo fare insieme.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Marco Ferretti
Source link
