Quando a arquitetura combate a gravidade, as operações pagam o preço

• • • • Os armazenamentos incorporados pressupõem que os dados chegarão ao namespace. As forças que atuam em uma estrutura empresarial dizem que não.
      • O argumento do “namespace unificado” é uma aposta contra as três formas que os dados assumem.
      • O custo arquitetônico é estrutural: propriedade do pipeline, dívidas de reconciliação, acoplamento de esquema, contabilidade dupla de governança, falta de transparência de custos.
      • As forças externas (regulação, acoplamento de aplicação, contratos e propriedade) tornam o custo permanente, não transitório.
      • Um plano de controle federado opera nos dados onde eles estão — e só os transfere quando essa é a melhor solução.

Se você estiver avaliando plataformas de dados de IA, os itens de linha na cotação não são os únicos custos que você precisará considerar. A conta real aparece posteriormente — nos pipelines que você precisa criar, nas pessoas que você atribui para mantê-los em funcionamento e na flexibilidade que você abre mão sempre que os dados precisam ser transferidos apenas para serem usados.

Os dados têm gravidade, a estrutura empresarial está cheia de distorções que mantêm os dados no lugar, e os “dados” em si não são uniformes — eles possuem três formas (dados, metadados e vetores), cada uma com características e requisitos diferentes. Este post é sobre o que acontece quando uma arquitetura finge que essas leis não se aplicam.

A suposição arquitetônica subjacente a cada pilha incorporada ao armazenamento

As pilhas de IA incorporadas ao armazenamento, com o VAST AI OS sendo o exemplo mais visível, são construídas com base em uma única suposição arquitetônica: os serviços de IA serão executados em dados que já foram carregados na plataforma. Eles precisam estar na plataforma. Qualquer coisa fora do namespace é, do ponto de vista da plataforma, invisível.^1,4

A plataforma vem com ferramentas para importar dados. Ela vem com uma apresentação sobre como a centralização de dados simplifica as operações. Ela vem com uma interface do usuário unificada que, na demonstração, faz todo o ambiente parecer uma única estrutura limpa e integrada.

Essa história é internamente consistente. É também uma aposta contra as forças estruturais que atuam sobre as estruturas empresariais.

As três formas dizem que você não precisa mover os dados pesados

O que as empresas chamam de “dados” são, na verdade, três coisas distintas:

• • Dados — Pesados. Permanecem onde estão. Arquivos, registros, imagens, vídeos, telemetria, tabelas regulamentadas.
  • Metadados — Leves. Baixo custo para propagar. Permitem que cada IA veja todos os ativos, em qualquer lugar.
  • Vetores — Sensíveis à localidade. Transmitem significado por toda a estrutura sem transportar os dados em si.

As arquiteturas que tratam as três formas como a mesma coisa acabam chegando a uma resposta errada: transferir tudo. As arquiteturas que as tratam como coisas distintas deixam os dados pesados controlados onde eles estão, propagam metadados em toda a estrutura e permitem que os vetores façam o raciocínio entre ambientes que a IA realmente precisa.

Um namespace unificado é uma resposta adequada se a única forma que você conhece é a dos dados. É a resposta errada no momento em que você aceita que metadados e vetores existem como cidadãos de primeira classe.

O custo arquitetônico de puxar a estrutura para dentro da plataforma

Quando uma arquitetura é criada em torno da suposição de que os dados devem chegar antes que a IA possa tocá-los, todas as forças externas em sua empresa se tornam uma obrigação operacional:

• • Propriedade do pipeline. Todos os sistemas de origem, incluindo Snowflake, SharePoint, S3 e Kafka, o armazenamento de terceiros e SaaS precisam de uma tarefa de sincronização.¹ Toda tarefa de sincronização tem um humano por trás dela.
  • Dívida de reconciliação. Cada cópia acaba divergindo da origem. Desvio do esquema, picos de latência regional e truncamentos silenciosos quando o comprimento de um campo de origem muda e ninguém é informado. Alguém tem que detectar e corrigir esse desvio, para sempre.
  • Acoplamento de esquema. Quando os sistemas de origem mudam, as cópias downstream são interrompidas — e os serviços de inteligência artificial que dependem delas também são afetados.
  • Contabilidade dupla de governança. Os controles de acesso, as políticas de retenção, os bloqueios regulatórios e as trilhas de auditoria precisam ser mantidos em duas instâncias — na origem e na cópia.
  • Opacidade de custos. Sua equipe de FinOps agora está monitorando a movimentação de dados, a duplicação de armazenamento e os custos de saída de dados em uma arquitetura que foi vendida como uma solução de consolidação.

Nada disso é oculto de má-fé. É estrutural. É o que acontece quando um modelo fechado, incorporado ao armazenamento, se encontra com uma estrutura de dados aberta e distribuída e tenta puxá-la para dentro.^1,4

A linguagem do fornecedor é importante aqui. “O mecanismo de sincronização é gratuito” e “A sincronização é gratuita” não significam a mesma coisa. Uma tarefa de sincronização não é uma migração única. É uma relação permanente entre dois sistemas que devem ser mantidos consistentes para sempre: mesmo diante de alterações de esquema, eventos de rede, alterações de permissão, políticas de retenção, bloqueios regulatórios e interrupções ocasionais em ambos os lados.⁴ Multiplique isso por cada sistema de origem com o qual suas cargas de trabalho de IA interagem e você verá que não simplificou sua arquitetura. Você adicionou um novo plano de cópia específico do fornecedor, que está em execução em segundo plano.¹

As forças externas tornam os custos permanentes

A razão pela qual esse custo não desaparece ao longo do tempo é que as forças que o criam não são transitórias. São características estruturais da empresa:

• • Restrições regulamentares e de soberania. GDPR, HIPAA, lei de residência de dados e controles de exportação. Alguns dados devem ser processados onde residem. A tarefa de sincronização que cruza um limite de soberania é a tarefa de sincronização que se torna um incidente de conformidade.
  • Requisitos das aplicações. Aplicativos de fonte de verdade, como ERPs, CRMs, EHRs e sistemas transacionais estão fortemente vinculados aos seus proprietários. Eles não foram projetados para alimentar um namespace de fornecedor. Eles foram projetados para administrar uma empresa.
  • Atritos contratuais. As taxas de saída de hiperescaladores e os formatos exclusivos fazem com que seja mais caro extrair os dados do que mantê-los onde estão. Extrair dados para transferi-los para outro lugar é uma despesa que seu CFO acabará descobrindo.
  • Dinâmica organizacional. Duas unidades de negócios que reivindicam os mesmos dados, a estrutura de uma empresa adquirida que surgiu da noite para o dia, um administrador que se recusa a abrir mão da governança — o organograma frequentemente se sobrepõe ao ideal arquitetônico.
  • Dados desconhecidos ou não catalogados. Os dados que você sabe que existem, mas não pode catalogar. Você não consegue sincronizar o que não consegue encontrar. E o que você não pode sincronizar, sua IA não pode ver, pelo menos não em um modelo incorporado ao armazenamento.

Cada uma dessas forças é uma característica permanente do ambiente em que uma empresa real opera. As arquiteturas que dependem do fim dessas forças acabarão arcando com esse custo indefinidamente.

A alternativa federada

A Dell AI Data Platform foi criada com base em uma premissa muito diferente. Em vez de pedir aos clientes que copiem os dados para um namespace controlado pelo fornecedor antes de poderem usá-los, a abordagem da Dell é federada: um plano de controle que opera nos dados onde eles estão no PowerScale, ObjectScale, armazenamento de terceiros, warehouses, SaaS e nuvem pública, e só transfere dados quando essa transferência for realmente a solução correta.^4,5

Essa única decisão de design é uma aplicação direta do enquadramento das três formas:

• • Os dados permanecem onde estão, controlados pelas equipes que já os controlam.
  • Os metadados se propagam em todos os lugares, para que cada IA escolhida veja todos os ativos, independentemente da localização.
  • Os vetores transmitem significado em toda a estrutura, para que a IA possa raciocinar sobre os dados sem primeiro realocá-los.

Não significa que as arquiteturas federadas nunca movimentam dados. Elas movimentam, quando faz sentido. Mas elas não tornam a movimentação de dados a pré-condição para obter valor da plataforma. E essa única opção de arquitetura elimina a maior parte dos custos operacionais acima — porque eles só existem se você tiver criado sua arquitetura em torno da suposição de que os dados precisam ser realocados antes que a IA possa acessá-los.⁴

Além disso, ela garante o que mais importa para o CFO: a flexibilidade. Um plano de controle federado não aprisiona a estrutura de dados dentro do namespace de um fornecedor. Ela mantém a estrutura onde já está, controlada pelas equipes que já a controlam, e a torna útil para a IA já existente.^2,4

Analistas independentes estão cada vez mais chamando a atenção para essa dinâmica. Um artigo recente observou que, apesar do suporte do VAST a padrões abertos, sua “arquitetura unificada pode criar dependências que tornam as migrações futuras desafiadoras” — uma maneira educada de dizer que quanto mais dados você sincroniza, mais difícil fica sair desse serviço.² Outro artigo observou que “a abordagem do VAST é mais semelhante ao modelo de infraestrutura hiperconvergente, oferecendo uma pilha altamente integrada e definida, onde o VAST controla toda a experiência”.³ A HCI mostrou ao setor o que acontece quando esse modelo se depara com a heterogeneidade em escala. As mesmas lições se aplicam aqui.

Três perguntas a serem feitas antes de assinar

Elas vão direto para sua RFP.

1. 1. Em um estado estável, quantos pipelines vou executar em seu namespace? Peça uma estimativa realista com base em uma estrutura de dados semelhante ao seu, e não em uma arquitetura de referência criada em torno de um greenfield. Relacione isso com a sua estrutura associada a normas e aplicativos.
   2. Quem é responsável pela reconciliação quando um sistema de origem muda? Se a resposta for “sua equipe, usando nossas ferramentas”, esse é o custo de suas operações. Calcule esse custo.
   3. Se eu quiser parar de sincronizar uma fonte de dados no terceiro ano, como isso seria? A resposta é uma medida direta do grau de flexibilidade que você está abrindo mão e um indicador direto do nível de atrito que a arquitetura cria em relação à saída.

Resumindo: não pague por serviços que ninguém lhe disse que você estava contratando.

Próximos passos

No próximo artigo, voltarei ao assunto do data center, porque a consequência desse custo de arquitetura não é apenas um problema de FTE. É um problema econômico da GPU. Quando os dados precisam ser carregados antes que a computação possa ser executada, o item de linha mais caro em sua infraestrutura de IA é aquele que paga a conta.

¹ VAST Data, documentação do produto “DataSpace and SyncEngine”.

² DataPro.news, “VAST Data: Revolutionary AI OS or Silicon Valley Hyperbole?” Junho de 2025.

³ NAND Research, “How to Think About VAST Data”, fevereiro de 2026.

⁴ Prowess Consulting, “Architectural and Operational Comparison: Dell AI Data Platform vs VAST AI OS”, encomendado pela Dell, abril de 2026.

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