Google redesenhou sua arquitetura de dados para que a IA pare de fracassar nas empresas
Durante anos, as equipes de dados e as equipes de IA nas grandes corporações operaram como departamentos de países distintos. As primeiras construíam armazéns, catálogos e pipelines. As segundas implantavam modelos, APIs e agentes. Os dois mundos se comunicavam por meio de exportações manuais, processos descontínuos e uma fé cega de que "a outra equipe já resolve". O resultado era previsível: os agentes de IA chegavam ao ambiente de produção e colapsavam diante de dados que ninguém havia preparado para que uma máquina autônoma pudesse ler, interpretar e agir sobre eles.
No Google Cloud Next 2026, o Google nomeou esse colapso com precisão: a separação entre plataforma de dados e plataforma de IA é o maior freio à implantação empresarial de agentes autônomos. Sua resposta foi a Nuvem de Dados Agêntica, uma reconfiguração profunda de sua arquitetura de dados que não adiciona uma camada de IA sobre o que já existe, mas sim redesenha os alicerces para que os agentes sejam usuários de primeira classe do dado empresarial.
A diferença de ambição não é pequena. Não estamos falando de novos conectores nem de dashboards enriquecidos com linguagem natural. Estamos falando de um redesenho estrutural que obriga a repensar como qualquer empresa da Fortune 500 — com dados distribuídos entre AWS, Azure e Google Cloud — vai governar, servir e monetizar a informação que já possui.
O diagnóstico que os executivos preferem ignorar
Há um dado que incomoda: segundo a pesquisa que acompanha o lançamento, cerca de 70% das empresas descobrem as falhas de sua infraestrutura de dados depois de implantar os agentes, não antes. Isso não é um problema técnico. É um problema de liderança com disfarce técnico.
Os dados fragmentados, sem governança, presos em silos de diferentes nuvens, não apareceram do dia para a noite. Foram se acumulando durante anos de decisões apressadas, aquisições corporativas mal integradas e uma tendência organizacional muito humana: adiar a conversa difícil sobre a arquitetura real do dado porque "o negócio continua funcionando". Até que deixa de funcionar.
A arquitetura que o Google apresentou é composta por seis componentes que não são independentes entre si, mas formam um sistema com lógica sequencial. Na base, o Data Lakehouse Multinuvem, construído sobre o formato aberto Apache Iceberg, permite que o BigQuery consulte dados hospedados no AWS S3 e no Azure ADLS sem necessidade de movê-los ou replicá-los, eliminando os custos de egresso e o risco de incoerência entre cópias. Sobre essa base opera o Motor Lightning para Apache Spark, uma camada de execução vetorizada em C++ que entrega até 4,9 vezes o desempenho do Spark convencional. O dado não é apenas acessível; é processável em uma velocidade que torna viável que um agente gere, execute e corrija código Spark em ciclos contínuos sem que o custo dispare.
Acima dessa infraestrutura de execução vem a camada de inteligência contextual: o Catálogo de Conhecimento, a evolução do Dataplex Universal Catalog apresentada em 10 de abril de 2026. Essa peça é a que mais deveria ocupar a atenção dos arquitetos empresariais. O catálogo não exige que as equipes de dados cataloguem manualmente os ativos. Ele examina os registros de consultas, perfila tabelas, analisa modelos semânticos de ferramentas como o Looker e extrai relações entre entidades a partir de arquivos não estruturados. O resultado é um grafo de conhecimento dinâmico, mantido automaticamente, que responde à pergunta que qualquer agente precisa resolver antes de agir: quais dados existem, o que significam com precisão e se são confiáveis.
Quando o armazenamento deixa de ser passivo
A peça que mais radicalmente muda a geometria operativa do dado é o Armazenamento Inteligente, atualmente em pré-visualização. Até agora, um arquivo que entrava em um bucket do Google Cloud Storage era inerte até que alguém decidisse processá-lo. Com essa funcionalidade, no momento em que um arquivo chega ao bucket, o sistema o etiqueta automaticamente, gera embeddings, extrai entidades relevantes e o vincula ao Catálogo de Conhecimento. PDFs, contratos, tickets de suporte, gravações de áudio: tudo se converte em um ativo pesquisável sem que nenhum engenheiro precise intervir.
Para os executivos que têm adiado projetos de preparação de dados não estruturados — aqueles que "levarão seis meses" de extração, OCR, indexação e catalogação — isso reconfigura a equação de tempo e custo de uma maneira que não admite adiamento confortável. O que antes era um projeto com patrocinador executivo, orçamento próprio e data de entrega incerta passa a ser uma consequência automática da política de armazenamento.
O Agente de Pesquisa Profunda, baseado no Gemini 3.1 Pro, ilustra o caso de uso terminal de toda essa infraestrutura. Opera combinando fontes internas do Catálogo de Conhecimento e do Lakehouse com fontes abertas na internet, gera planos de pesquisa estruturados e entrega relatórios com citações verificáveis em minutos. Tarefas que em áreas como inteligência competitiva, ciências da vida ou serviços financeiros consumiam entre uma e três semanas de trabalho analítico passam a ser o ponto de partida, não o ponto de chegada.
O Kit de Agentes de Dados completa o quadro do lado do desenvolvedor. Oferece ferramentas MCP pré-configuradas e três agentes especializados: um que converte instruções em linguagem natural em pipelines gerenciados, escolhendo entre BigQuery, dbt, Spark ou Airflow; outro que automatiza o ciclo completo de modelos de ciência de dados; e um terceiro dedicado à observabilidade de infraestrutura. O Protocolo de Contexto de Modelo atua como uma camada de interoperabilidade que permite que agentes de qualquer fornecedor — Gemini, Claude, modelos próprios — acessem os ativos de dados sem conectores personalizados.
A multinuvem deixa de ser uma queixa e se torna uma decisão de arquitetura
Nenhuma empresa entre as da Fortune 500 opera exclusivamente no Google Cloud. Os sistemas SAP, Salesforce, Workday e Oracle estão distribuídos entre AWS e Azure por razões históricas, contratuais e operativas que nenhum mandato de CTO pode resolver com um memorando. Durante anos, a multinuvem foi o argumento recorrente para não avançar com nenhuma iniciativa de IA em escala: "primeiro precisamos consolidar o dado".
O Data Lakehouse Multinuvem desmonta esse argumento com especificidade técnica. Usando o Catálogo REST do Iceberg, a Interconexão Multinuvem e uma camada de cache inteligente, o BigQuery pode consultar dados no AWS S3 e no Azure ADLS com latência e custo comparáveis aos de dados nativos no Google Cloud. Um agente de aquisições pode combinar em uma única consulta dados de contratos armazenados no S3, inventário no Azure e registros transacionais no BigQuery, tudo sob um catálogo Iceberg unificado, sem que nenhuma equipe de engenharia precise gerenciar um processo de ETL entre nuvens.
A implicação para os arquitetos de integração é de ordem estratégica. A conversa deixa de ser "como migramos tudo para uma única nuvem" e se torna "como governamos um catálogo único sobre a distribuição de dados que já temos". Não é a mesma conversa. A primeira tem um custo político e financeiro proibitivo na maioria das organizações maduras. A segunda é executável sem interromper os contratos existentes com outros fornecedores.
O que o Google está propondo, em seu conjunto, é uma mudança de paradigma com consequências organizacionais que vão além da arquitetura técnica. O MCP como camada de governança de agentes exige ser gerenciado com a mesma disciplina que hoje se aplica a um gateway de APIs: versionamento, autenticação, monitoramento, limites de uso. O Catálogo de Conhecimento deixa de ser um projeto de documentação e se torna uma dependência operativa em tempo real, o que implica acordos de nível de serviço, manutenção contínua e um modelo de operação que as equipes de dados ainda não têm desenhado.
A cultura de uma organização não é o cartaz emoldurado na sala de reuniões nem o discurso do CEO na convenção anual. É a soma acumulada de todas as decisões que os líderes tomaram quando era mais cômodo adiar do que decidir, mais seguro delegar do que assumir, mais fácil culpar a dívida técnica do que reconhecer que a arquitetura do dado reflete com exatidão cirúrgica a arquitetura do poder, do medo e das conversas que a diretoria nunca teve coragem de sustentar.
