☁️ Punti chiave
- Decathlon porta Chronos-2 in produzione per prevedere la domanda su decine di migliaia di prodotti, riducendo errori e tempi di deployment.
- Salesforce usa SageMaker Inference Components per garantire alta disponibilità Multi-AZ, mentre Feature Store introduce scrittura batch e discovery dei record.
- AWS corregge due path traversal in amazon-ssm-agent e awsdac, con potenziale esecuzione di codice rispettivamente come root e sull’ambiente locale.
AWS spinge il machine learning dalla sperimentazione alla produzione su larga scala. Decathlon ha scelto Chronos-2 per le previsioni della domanda globale, Salesforce usa i SageMaker Inference Components per distribuire Agentforce con alta disponibilità Multi-AZ e SageMaker Feature Store introduce API per scrivere record in batch e recuperarli più facilmente. In parallelo, Razor Group ricostruisce la propria piattaforma dati come lakehouse basato su S3 e Apache Iceberg. La crescita dell’infrastruttura porta però anche nuove esigenze di sicurezza: AWS ha pubblicato due bollettini per CVE-2026-81849 in amazon-ssm-agent e CVE-2026-81838 in awsdac.
Cosa leggere
Decathlon porta Chronos-2 nelle previsioni della domanda globale
Decathlon utilizza Chronos-2 come componente centrale del proprio sistema di demand forecasting, con previsioni settimanali su orizzonti di 12 e 52 settimane e fino a 25.000 prodotti per area geografica. Secondo l’analisi tecnica pubblicata da AWS con Decathlon, il modello fine-tuned ha ridotto il WAPE di 11 punti percentuali nel Sud-est asiatico e 15 punti in America Latina sull’orizzonte a 12 settimane.
L’inferenza richiede circa 40 secondi per 7.000 serie temporali e 75 secondi per 15.000, mentre il fine-tuning passa da una frequenza settimanale a una ogni sei mesi. Decathlon stima inoltre che ogni punto di miglioramento WAPE produca benefici su inventario, disponibilità dei prodotti e vendite. La scelta conferma il passaggio dei foundation model da chatbot e generazione di contenuti a problemi industriali strutturati come forecasting e supply chain, seguendo la stessa evoluzione con cui AWS sta portando cataloghi, osservabilità e agenti AI dentro gli ambienti produttivi.
Salesforce distribuisce Agentforce su più Availability Zone
Anche Salesforce sta utilizzando SageMaker per risolvere un problema molto meno visibile dell’AI generativa: mantenere disponibili i modelli quando un’istanza o un’intera Availability Zone fallisce. AWS descrive l’architettura adottata per Agentforce attraverso la nuova capacità di placement dei SageMaker Inference Components. Salesforce aveva già ottenuto una riduzione fino a 8 volte dei costi infrastrutturali condividendo le GPU tra più modelli, ma la distribuzione automatica delle copie non garantiva che ogni modello fosse realmente bilanciato tra più AZ.
La configurazione SPREAD con AvailabilityZoneBalance consente ora di mantenere almeno due copie distribuite tra zone differenti, eliminando il singolo punto di failure e preservando la disposizione anche durante scaling e aggiornamenti. È un ulteriore passo nella trasformazione già osservata quando AWS ha reso stateless MCP e automatizzato workload Spark e OpenSearch: l’AI enterprise sta diventando soprattutto un problema di disponibilità, orchestrazione e controllo dei costi.
Leggi anche: AWS porta osservabilità e governance negli agenti AI in produzione
SageMaker Feature Store accelera la scrittura dei dati per il machine learning
AWS introduce inoltre due nuove API in Amazon SageMaker Feature Store. BatchWriteRecord e ListRecords affrontano rispettivamente il throughput delle pipeline ML e la difficoltà di individuare i record presenti nello storage online. BatchWriteRecord permette di scrivere fino a 25 record in una singola richiesta, anche attraverso più feature group, mantenendo errori indipendenti per ogni elemento. ListRecords consente invece di enumerare gli identificativi memorizzati sia nello storage Standard basato su DynamoDB sia nel livello In-Memory basato su Redis. Il problema diventa evidente su pipeline ad alto volume: uno scenario da 10.000 record al secondo distribuiti su cinque feature group avrebbe richiesto 50.000 singole chiamate API al secondo utilizzando esclusivamente PutRecord. Le nuove API riducono quindi overhead e complessità proprio mentre SageMaker viene utilizzato per workload sempre più grandi e continui.
Razor Group sposta oltre mille modelli SQL verso un lakehouse aperto
La stessa logica di separare storage e capacità di calcolo emerge nella trasformazione di Razor Group, aggregatore europeo di e-commerce con oltre 250 brand. La nuova architettura lakehouse descritta da AWS utilizza Amazon S3 Tables, Apache Iceberg, Spark, Redshift Serverless, Lake Formation e Glue Data Catalog, sostituendo una piattaforma nella quale oltre 1.000 modelli SQL competevano sulle stesse risorse. Razor ha spostato l’ingestion verso S3 e Iceberg, ottenendo già in quella fase circa il 40% di riduzione dei costi compute, per poi migrare oltre 1.000 modelli da Redshift a Spark.
Circa il 30% ha richiesto intervento umano, concentrando il 70% dello sforzo, e il gruppo ha utilizzato Claude per accelerare conversione SQL, dipendenze e validazione. È una prosecuzione naturale della strategia AWS già vista nell’eliminazione dei cold start Java attraverso Lambda Managed Instances: compute più elastico e storage persistente diventano il modello comune per dati, AI e applicazioni.
AWS corregge SSM Agent e awsdac per due path traversal
La nuova ondata di servizi arriva insieme a due bollettini di sicurezza. CVE-2026-81849 interessa amazon-ssm-agent dalla versione 2.0.767.0 alla 3.3.4364.0. Secondo il bollettino AWS 2026-091, un utente remoto autenticato con permessi ssm:SendCommand limitati al documento AWS-DownloadContent può utilizzare object key S3 costruite ad hoc per scrivere file fuori dalla directory prevista con privilegi root. La sovrascrittura di file sensibili può arrivare all’esecuzione arbitraria di codice; la correzione è nella versione 3.3.4515.0 e AWS precisa che non esistono workaround. La vulnerabilità si aggiunge alle recenti correzioni AWS che hanno interessato OpenSearch e SDK, confermando l’importanza di mantenere aggiornati anche gli agenti di gestione installati sulle istanze.
Continua con:
- AWS e Cisco correggono vulnerabilità in AgentCore, Strands e jsii
- AWS corregge OpenSearch e SDK mentre SharePoint e SAP restano sotto attacco
awsdac espone soprattutto pipeline CI/CD che elaborano file non fidati
Il secondo problema, CVE-2026-81838, è uno Zip Slip path traversal in awsdac, tool diagram-as-code che genera architetture AWS da definizioni YAML. Il bollettino AWS 2026-090 spiega che un archivio ZIP manipolato può scrivere file fuori dalla cache prevista fino a qualsiasi percorso accessibile all’utente che esegue il programma, con possibile esecuzione di codice. Sono vulnerabili le versioni 0.10-0.23, mentre la correzione arriva con awsdac 0.24. Il rischio principale riguarda pipeline CI/CD che elaborano definizioni provenienti da fonti non affidabili o semi-affidabili; AWS precisa che la falla non compromette direttamente servizi AWS, account cloud o dati dei clienti, ma soltanto la macchina locale sulla quale viene eseguito awsdac. In pochi giorni AWS mostra quindi entrambe le facce della propria evoluzione: machine learning e lakehouse sempre più maturi per la produzione, ma anche una superficie software che richiede patch rapide quando agenti e strumenti di sviluppo acquisiscono privilegi sufficienti a trasformare un path traversal in esecuzione di codice.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
