Cuando la arquitectura desafía la gravedad, las operaciones pagan las consecuencias

• • Las pilas integradas en almacenamiento asumen que los datos llegarán al espacio de nombres. Las fuerzas que actúan sobre el ecosistema tecnológico empresarial indican que no será así.
  • La propuesta del “espacio de nombres unificado” es una apuesta contra las tres formas de los datos.
  • La carga arquitectónica es estructural: propiedad de los pipelines, deuda de reconciliación, acoplamiento de esquemas, doble contabilidad en la gobernanza y falta de transparencia en los costes.
  • Las fuerzas externas (normativas, dependencias entre aplicaciones, obligaciones contractuales y cuestiones de propiedad) convierten ese coste en algo permanente, no transitorio.
  • Un plano de control federado trabaja con los datos en su ubicación original y solo los desplaza cuando existe una razón justificada para hacerlo.

Si está evaluando plataformas de datos para IA, los conceptos incluidos en el presupuesto no representan todos los costes que deberá asumir. El coste real se manifiesta más adelante: en los pipelines que habrá que crear, las personas que deberá asignar para mantenerlos operativos y la flexibilidad que perderá cada vez que haya que mover los datos solo para poder utilizarlos.

Los datos tienen gravedad, los ecosistemas tecnológicos reales de las empresas están llenos de distorsiones que mantienen los datos en su lugar; los propios “datos” no son una entidad homogénea, sino que existen en tres formas: datos, metadatos y vectores, cada cual con características y requisitos diferentes. En este artículo analizaremos qué sucede cuando una arquitectura ignora esas leyes.

La premisa arquitectónica que subyace a toda pila integrada en almacenamiento

Las pilas de IA integradas en almacenamiento, siendo VAST AI OS el ejemplo más visible, se basan en una única premisa arquitectónica: que los servicios de IA se ejecutarán sobre datos que ya se encuentran alojados en la plataforma. Tienen que estar en la plataforma. Todo lo que se encuentre fuera del espacio de nombres es, desde el punto de vista de la plataforma, invisible.^1,4

Por eso, la plataforma incluye herramientas para incorporar los datos a su propio entorno y se presenta con la promesa de que centralizarlos simplificará la operación. Incluye una interfaz de usuario unificada que, en las demostraciones, hace que todo el ecosistema tecnológico parezca un único sistema limpio y coherente.

El relato es consistente a nivel interno. Pero también supone apostar contra las fuerzas estructurales que operan en los ecosistemas tecnológicos reales de las empresas.

Las tres formas señalan que no hace falta mover los datos de gran volumen

Lo que las empresas llaman “datos” son en realidad tres cosas distintas:

• • Datos — pesados. Permanecen donde están. Archivos, registros, imágenes, vídeo, telemetría, tablas reguladas.
  • Metadatos — ligeros. Baratos de propagar. Permiten que cualquier IA vea cualquier activo, en cualquier lugar.
  • Vectores — sensibles a la localización. El significado se propaga por todo el ecosistema sin necesidad de trasladar los datos.

Las arquitecturas que tratan las tres cosas como si fueran lo mismo acaban adoptando por defecto una mala solución: moverlo todo. Las arquitecturas que tratan estas tres formas como elementos distintos pueden dejar los datos pesados gobernados allí donde residen, propagar los metadatos a lo largo del ecosistema y permitir que los vectores realicen el razonamiento entre entornos que la IA realmente necesita.

Un espacio de nombres unificado resulta coherente solo si se consideran los datos como la única forma existente. Se transforma en la respuesta incorrecta en el momento en que se acepta que los metadatos y los vectores existen como elementos de primera clase.

El coste arquitectónico de centralizar el ecosistema tecnológico

Cuando una arquitectura se construye sobre la suposición de que los datos deben llegar antes de que la IA pueda interactuar con ellos, todas las fuerzas externas de la empresa se convierten en cargas operativas:

• • Propiedad de los pipelines. Cada fuente, incluyendo Snowflake, SharePoint, S3, Kafka, almacenamiento de terceros y SaaS, necesita un proceso de sincronización.¹ Detrás de cada uno de esos procesos hay una persona.
  • Deuda de reconciliación. Cada copia se desvía de su origen. Deriva de esquemas, picos de latencia regional, truncamientos silenciosos cuando la longitud de un campo en el origen cambia y nadie informa a nadie. Es necesario que alguien detecte y corrija esa deriva de forma constante.
  • Acoplamiento de esquemas. Cuando los sistemas de origen cambian, las copias en sistemas posteriores fallan, y los servicios de IA que dependen de ellas también.
  • Doble contabilidad en la gobernanza. Los controles de acceso, las políticas de retención, las retenciones regulatorias y las pistas de auditoría deben mantenerse por partida doble: en el origen y la copia.
  • Falta de transparencia en los costes. El equipo de FinOps ahora tiene que hacer seguimiento del movimiento de datos, la duplicación de almacenamiento y el tráfico de salida en una arquitectura que se presentó como una consolidación.

Nada de esto se hace de forma intencionada u opaca. Se trata de algo estructural. Es lo que pasa cuando un modelo cerrado integrado en almacenamiento se encuentra con un ecosistema de datos abierto y distribuido e intenta atraerlo hacia su interior.^1,4

El idioma del proveedor es importante en este punto. Decir “el motor de sincronización es gratuito” no es lo mismo que decir “la sincronización es gratuita”. Un proceso de sincronización no es una migración puntual. Se trata de una relación permanente entre dos sistemas que debe mantenerse en sincronía para siempre: frente a cambios de esquema, eventos de red, cambios de permisos, políticas de retención, retenciones regulatorias e interrupciones ocasionales en cualquiera de los dos lados.⁴ Multiplique todo esto por cada sistema de origen al que accedan sus cargas de trabajo de IA, y no estará simplificando su arquitectura. Habrá añadido una nueva capa de copia, propia del proveedor, que opera por debajo de toda la arquitectura.¹

Las fuerzas externas hacen que el coste sea permanente

La razón por la que este coste no se atenúa con el tiempo es que las fuerzas que lo generan no son transitorias. Son rasgos estructurales de la empresa:

• • Restricciones regulatorias y soberanas. RGPD, HIPAA, leyes de residencia de datos, controles de exportación. Algunos datos deben procesarse allá donde residen. El proceso de sincronización que cruza una frontera soberana pasa a ser un incidente de cumplimiento.
  • Requisitos de las aplicaciones. Las aplicaciones que funcionan como fuente de verdad, como ERP, CRM, EHR y sistemas transaccionales, están vinculadas a sus propietarios. No fueron diseñadas para alimentar el espacio de nombres de un proveedor. Se diseñaron para gestionar un negocio.
  • Fricción contractual. Las tarifas de salida de hiperescaladores y los formatos registrados hacen que extraer datos sea más caro que dejarlos donde están. Extraer los datos para trasladarlos a otro lugar es una partida que su director financiero terminará descubriendo.
  • Dinámica organizativa. Dos unidades de negocio que reclaman los mismos datos, el ecosistema de una empresa adquirida que se integra de la noche a la mañana, un responsable de datos que no cede la gobernanza: el organigrama suele imponerse sobre el ideal arquitectónico.
  • Datos desconocidos o no catalogados. Los datos cuya existencia conoce, pero que no puede catalogar. No se puede sincronizar lo que no se puede encontrar. Y aquello que no se puede sincronizar, su IA no puede verlo, al menos no en un modelo integrado en almacenamiento.

Cada una de estas fuerzas es una característica permanente del entorno en el que opera una empresa real. Las arquitecturas que dependen de que desaparezcan acabarán pagando ese coste de forma indefinida.

La alternativa federada

Dell AI Data Platform se basa en una premisa muy diferente. En lugar de pedir a los clientes que copien datos en un espacio de nombres controlado por el proveedor antes de poder utilizarlos, el enfoque de Dell es federado: un plano de control que opera sobre los datos allí donde residen, en PowerScale, ObjectScale, almacenamiento de terceros, almacenes, SaaS y cloud pública, y que solo los mueve cuando trasladarlos es la decisión correcta.^4,5

Esa única decisión de diseño es una aplicación directa del enfoque de las tres formas de los datos:

• • Los datos permanecen donde residen, gobernados por los equipos que ya los gestionan.
  • Los metadatos se propagan por todo el sistema, de modo que cualquier IA que elija puede ver todos los activos, independientemente de su ubicación.
  • Los vectores transportan el significado a través del ecosistema, de modo que la IA puede razonar sobre los datos sin necesidad de reubicarlos primero.

No se trata de que las arquitecturas federadas nunca muevan datos. Lo hacen, cuando tiene sentido. Pero no convierten el movimiento de datos en un requisito previo para extraer valor de la plataforma. Además, esa única decisión arquitectónica elimina la mayor parte del coste operativo descrito anteriormente, porque ese coste solo existe si ha construido su arquitectura sobre la suposición de que los datos deben reubicarse antes de que la IA pueda interactuar con ellos.⁴

También preserva lo que más le importa al director financiero: la opcionalidad. Un plano de control federado no encierra el ecosistema de datos dentro del espacio de nombres de un proveedor. Deja el ecosistema donde ya está, gobernado por los equipos que ya lo gestionan, y lo hace útil para la IA en su propia ubicación.^2,4

Los analistas independientes están poniendo esta dinámica de relieve. Un artículo reciente señalaba que, a pesar del soporte de VAST para estándares abiertos, su “arquitectura unificada podría crear dependencias que hagan más complejas las migraciones futuras”; una forma diplomática de decir que, cuanto más datos se sincronizan dentro, más difícil resulta abandonar el sistema.² Otro artículo destacaba que el enfoque de VAST es “más parecido al modelo de infraestructura hiperconvergente, al ofrecer un stack altamente integrado y con visión propia, donde VAST controla toda la experiencia”.³ La HCI mostró al sector lo que sucede cuando ese modelo se encuentra con la heterogeneidad a gran escala. Las mismas lecciones son aplicables en este caso.

Tres preguntas que conviene hacerse antes de firmar

Deben incluirse directamente en el RFP.

1. 1. En estado estable, ¿cuántos pipelines se ejecutarán en el espacio de nombres? Solicite una estimación realista basada en un ecosistema de datos similar al suyo, no en una arquitectura de referencia diseñada para un entorno nuevo. A continuación, contraste esa estimación teniendo en cuenta su ecosistema ligado a aplicaciones y condicionado por requisitos regulatorios.
   2. ¿Quién asume la responsabilidad de la reconciliación cuando un sistema de origen cambia? Si la respuesta es “su equipo, haciendo uso de nuestras herramientas”, entonces eso forma parte de su coste operativo. Póngale precio.
   3. Si dentro de tres años quiero dejar de sincronizar una fuente, ¿cómo sería el proceso? La respuesta es un indicador directo del nivel de pérdida de flexibilidad y de lo difícil que será abandonar la arquitectura.

La versión corta: no pague por una infraestructura que nadie le dijo que estaba comprando.

Siguientes pasos

En el próximo artículo, volveré a la sala del centro de datos, porque este coste arquitectónico no se limita solo a un problema de FTE. En el fondo, es un problema de economía de GPU. Cuando los datos tienen que llegar primero para que el procesamiento pueda ejecutarse, la partida más cara de su infraestructura de IA es la que acaba asumiendo el coste.

 ¹ VAST Data, documentación de los productos “DataSpace y SyncEngine”.

 ² DataPro.news, “VAST Data: Revolutionary AI OS or Silicon Valley Hyperbole?” (VAST Data: ¿sistema operativo de IA revolucionario o hipérbole de Silicon Valley?) Junio de 2025.

 ³ NAND Research, “How to Think about VAST Data” (Cómo interpretar VAST Data), febrero de 2026.

 ⁴ Prowess Consulting, “Architectural and Operational Comparison: Dell AI Data Platform vs. VAST AI OS” (Comparativa arquitectónica y operativa: Dell AI Data Platform frente a VAST AI OS), encargado por Dell, abril de 2026.

 ⁵ Dell Technologies, “Dell AI Data Platform with NVIDIA Supercharges Enterprise AI with Breakthrough Data Orchestration and Storage Innovations” (Dell AI Data Platform con NVIDIA potencia la IA empresarial con innovaciones revolucionarias en orquestación de datos y almacenamiento), PR Newswire, marzo de 2026.