Quando l’architettura combatte la gravità, le operazioni pagano il conto

• • • Gli stack storage-embedded presuppongono l’arrivo dei dati nel namespace. Le forze che agiscono sul patrimonio dei dati aziendali dicono che non funziona così.
    • La tesi del “namespace unificato” è una scommessa contro le tre tipologie di dati.
    • La tassa architetturale è strutturale: proprietà delle pipeline, debito di riconciliazione, accoppiamento degli schemi, contabilità doppia della governance, opacità dei costi.
    • Le forze esterne (regolamentazione, accoppiamento delle applicazioni, contratti, proprietà) rendono la tassa permanente, non transitoria.
    • Un piano di controllo federato opera sui dati nella posizione in cui risiedono e li sposta solo quando lo spostamento è la risposta più idonea.

Se stai effettuando la valutazione di piattaforme dati per l’AI, le singole voci del preventivo non sono i tuoi unici costi da sostenere. Il conto reale si presenterà in seguito: nelle pipeline da creare, nelle persone a cui demandi il compito di mantenerle attive e nella flessibilità a cui rinunci ogni volta che i dati devono essere spostati solo per essere utilizzabili.

I dati hanno gravità, il reale patrimonio dei dati aziendali è pieno di distorsioni che trattengono i dati sul posto e i “dati” in sé non sono una sostanza unica, in quanto possono appartenere a tre tipologie (dati, metadati e vettori), ognuna con caratteristiche e requisiti diversi. In questo post esamineremo quel che accade quando un’architettura finge che queste leggi non esistano.

Il presupposto architetturale alla base di ogni stack storage-embedded

Gli stack AI storage-embedded, di cui VAST AI OS ne è l’esempio più evidente, si basano su un unico presupposto architetturale: i servizi di AI verranno eseguiti sui dati già pervenuti sulla piattaforma. I dati devono trovarsi sulla piattaforma. Tutto ciò che si trova al di fuori del namespace è, dal punto di vista della piattaforma, invisibile^1,4.

La piattaforma viene pertanto fornita con gli strumenti necessari per portare i dati al suo interno. Accompagnata da una narrazione sul modo in cui la centralizzazione dei dati semplifica le operazioni, viene fornita con un’interfaccia utente unificata che, nella demo, fa apparire l’intero ambiente come un’unica soluzione semplice e pulita.

Questa narrazione è internamente coerente, ma è anche una scommessa contro le forze strutturali che agiscono sui reali patrimoni dei dati aziendali.

Le tre tipologie di dati indicano che non è necessario spostare i dati pesanti

Ciò che le aziende chiamano “dati” sono in realtà tre elementi distinti:

• • Dati (pesanti). Restano dove sono. File, record, immagini, video, dati di telemetria, tabelle regolamentate.
  • Metadati (leggeri). Economici da propagare. Consentono a ogni AI di accedere a ogni asset, ovunque si trovi.
  • Vettori (sensibili alla posizione). Trasportano il significato in tutto l’ambiente senza trasportare i dati stessi.

Le architetture che trattano tutte le tre tipologie come una stessa sostanza finiscono automaticamente con una risposta sbagliata: spostare tutto. Le architetture che le trattano distintamente possono lasciare i dati pesanti regolamentati dove risiedono, propagare i metadati in tutto l’ambiente e consentire ai vettori di eseguire il ragionamento tra i diversi ambienti di cui l’AI ha effettivamente bisogno.

Un namespace unificato è una risposta coerente se i dati sono l’unica tipologia riconosciuta. È la risposta sbagliata nel momento in si accetta che i metadati e i vettori esistano come elementi principali di prima classe.

La tassa architetturale di portare il patrimonio di dati all’interno

Quando un’architettura si basa sul presupposto che i dati debbano pervenire prima che l’AI possa utilizzarli, ogni forza esterna dell’azienda diventa un onere operativo:

• • Proprietà delle pipeline. Ogni origine, tra cui Snowflake, SharePoint, S3 e Kafka, storage di terze parti, SaaS, necessita di un processo di sincronizzazione¹. Ogni processo di sincronizzazione ha un essere umano alle spalle.
  • Debito di riconciliazione. Ogni copia subisce una deviazione dalla sua origine. Spostamento dello schema, picchi di latenza localizzati, troncamenti silenti quando la lunghezza di un campo di origine cambia senza alcun avviso. Qualcuno deve rilevare e correggere tale deviazione, per sempre.
  • Accoppiamento dello schema. Quando i sistemi di origine cambiano, le copie a valle si interrompono e i servizi di AI che da esse dipendono si interrompono altrettanto.
  • Doppia contabilità della governance. I controlli degli accessi, le policy di retention, le conservazioni normative e gli audit trail devono essere gestiti due volte, nell’origine e nella copia.
  • Opacità dei costi. Il team FinOps monitora lo spostamento dei dati, la duplicazione dello storage e l’uscita dei dati in un’architettura venduta come consolidamento.

Niente di tutto ciò è tenuto nascosto in malafede. È un fatto strutturale. È ciò che accade quando un modello storage-embedded chiuso incontra un patrimonio di dati aperto e distribuito e tenta di portare tale patrimonio all’interno^1,4.

Il linguaggio del vendor è importante in questo contesto. “L’engine di sincronizzazione è gratuito” e “La sincronizzazione è gratuita” non sono la stessa cosa. Un processo di sincronizzazione non è una migrazione una tantum, bensì una relazione permanente tra due sistemi che devono essere mantenuti coerenti per sempre: a fronte di modifiche dello schema, eventi di rete, modifiche delle autorizzazioni, policy di retention, conservazioni normative e interruzioni occasionali dell’alimentazione su entrambi i lati⁴. Se moltiplichi tutto ciò per ogni sistema di origine con cui i carichi di lavoro di AI entrano in contatto, il risultato è che non hai semplificato affatto l’architettura. Hai invece aggiunto un nuovo piano di copia specifico del vendor in esecuzione al di sotto di essa¹.

Le forze esterne rendono permanente la tassa

Il motivo per cui questa tassa non si riduce nel tempo è che le forze che la determinano non sono transitorie. Si tratta di caratteristiche strutturali dell’azienda:

• • Vincoli normativi e sovrani. GDPR, HIPAA, legge sulla residenza dei dati, controlli sulle esportazioni. Alcuni dati devono essere elaborati nella posizione in cui risiedono. Il processo di sincronizzazione che attraversa un confine sovrano è il processo di sincronizzazione che si trasforma in un incidente di conformità.
  • Requisiti delle applicazioni. Le applicazioni fonte di verità, come i sistemi ERP, CRM, EHR e i sistemi transazionali, sono strettamente legate ai rispettivi proprietari. Non sono state progettate per alimentare il namespace di un vendor: sono state progettate per gestire un’azienda.
  • Attrito contrattuale. I costi di uscita degli hyperscaler e i formati proprietari fanno sì che i dati siano più costosi da estrarre che da lasciare in posizione. Estrarre i dati per portarli altrove è un costo che il tuo CFO si ritroverà alla fine.
  • Dinamiche organizzative. Due business unit che richiedono gli stessi dati, il patrimonio di un’azienda acquisita da un giorno all’altro, un amministratore di dati che non cede il controllo sulla governance: l’organigramma dell’organizzazione scavalca regolarmente il modello architetturale ideale.
  • Dati sconosciuti o non catalogati. I dati che sai che esistono ma che non puoi catalogare. Non puoi sincronizzare quel che non trovi. E quel che non puoi sincronizzare, non può essere visto dall’AI, almeno non in un modello storage-embedded.

Ognuna di queste forze è una caratteristica permanente dell’ambiente in cui opera un’azienda reale. Le architetture che presuppongono la loro sparizione pagheranno la tassa a tempo indeterminato.

L’alternativa federata

Dell AI Data Platform si basa su un principio molto diverso. Anziché chiedere ai clienti di copiare i dati in un namespace controllato dal vendor prima di poterli utilizzare, l’approccio Dell è federato: un piano di controllo che opera sui dati nella posizione in cui risiedono in soluzioni PowerScale, ObjectScale, storage di terze parti, warehouse, SaaS e public cloud e che sposta i dati solo quando lo spostamento è la risposta più idonea^4,5.

Questa singola decisione di progettazione è un’applicazione diretta dell’approccio basato sulle tre tipologie:

• • I dati rimangono nella posizione in cui risiedono, governati dai team che già li governano.
  • I metadati si propagano ovunque, quindi ogni AI che scegli può accedere a tutti gli asset, indipendentemente dalla loro posizione.
  • I vettori trasportano il significato in tutto il patrimonio, per cui l’AI può ragionare sui dati senza alcun trasferimento precedente.

Non è che le architetture federate non spostano mai i dati. Lo fanno quando ha senso. Ma non rendono lo spostamento dei dati la precondizione necessaria per generare valore dalla piattaforma. Questa singola scelta architetturale elimina gran parte della tassa operativa menzionata in precedenza, perché la tassa esiste solo se l’architettura è stata creata partendo dal presupposto che i dati debbano essere trasferiti prima che l’AI possa utilizzarli⁴.

Inoltre, preserva quello a cui il CFO tiene di più: la flessibilità. Un piano di controllo federato non blocca il patrimonio di dati all’interno del namespace di un vendor. Lascia il patrimonio dove si trova, governato dai team che già lo governano e lo rende utile per l’AI nella posizione in cui si trova^2,4.

Gli analisti indipendenti stanno sempre più mettendo in evidenza questa dinamica. Un recente articolo ha rilevato che, nonostante VAST supporti gli standard aperti, la sua “architettura unificata potrebbe creare dipendenze che rendono difficili le migrazioni future”, un modo gentile per dire che più sono i dati che sincronizzi all’interno, tanto più difficile sarà abbandonare la piattaforma². Un altro ha osservato che l’approccio di VAST è “più simile al modello della hyper-converged infrastructure, offrendo uno stack strettamente integrato e dogmatico in cui VAST controlla l’intera esperienza”³. L’HCI ha insegnato al settore cosa succede quando quel modello incontra l’eterogeneità su larga scala. Le stesse lezioni valgono anche qui.

Tre domande da porre prima di firmare un contratto

Vanno inserite direttamente nella tua richiesta di offerta.

1. 1. In stato stazionario, quante pipeline eseguirò nel vostro namespace? Chiedi una stima realistica basata su un patrimonio di dati simile al tuo, non su un’architettura di riferimento creata su una base greenfield. Confrontala con il tuo l’ambiente normativo e applicativo.
   2. Chi è il proprietario della riconciliazione quando un sistema di origine cambia? Se la risposta è “il tuo team con i nostri strumenti”, si tratta di un tuo costo operativo. Definiscine il prezzo.
   3. Se desidero interrompere la sincronizzazione di un’origine nel terzo anno, cosa succede? La risposta è una misura diretta della quantità di flessibilità a cui stai rinunciando e un’indicazione diretta della quantità di attrito che l’architettura crea al momento dell’abbandono.

In breve: non pagare per i collegamenti di fondo che nessuno ti aveva detto che stavi comprando.

Cosa ci aspetta?

Nel prossimo post, tornerò a parlare del data center, poiché la conseguenza di questa tassa architetturale non è solo un problema di ETP. Si tratta di un problema di economia delle GPU. Quando i dati devono pervenire prima che l’elaborazione possa essere eseguita, la voce più costosa dell’infrastruttura di AI è quella che paga il conto.

¹ VAST Data, “DataSpace and SyncEngine”, documentazione del prodotto.

² DataPro.news, “VAST Data: Revolutionary AI OS or Silicon Valley Hyperbole?”, giugno 2025./p>

³ NAND Research, “How to Think about VAST Data”, febbraio 2026.

⁴ Prowess Consulting, “Architectural and Operational Comparison: Dell AI Data Platform vs. VAST AI OS”, commissionato da Dell, aprile 2026.

⁵ Dell Technologies, “Dell AI Data Platform with NVIDIA Supercharges Enterprise AI with Breakthrough Data Orchestration and Storage Innovations”, PR Newswire, marzo 2026.