As pilhas de dados corporativos foram criadas para humanos que executam consultas agendadas. À medida que os agentes de IA agem cada vez mais de forma autônoma em nome das empresas, 24 horas por dia, essa arquitetura está desmoronando – e os fornecedores estão correndo para reconstruí-la. A resposta do Google, anunciada no Cloud Next na quarta-feira, é o Agentic Data Cloud.
A arquitetura tem três pilares:
-
Catálogo de Conhecimento. Automatiza a curadoria semântica de metadados, inferindo a lógica de negócios a partir de logs de consulta sem intervenção manual do administrador de dados
-
Casa no lago entre nuvens. Permite que o BigQuery consulte tabelas Iceberg no AWS S3 por meio de rede privada sem taxas de saída
-
Kit de agente de dados. Coloca ferramentas MCP no VS Code, Claude Code e Gemini CLI para que os engenheiros de dados descrevam os resultados em vez de escrever pipelines
“A arquitetura de dados precisa mudar agora”, disse Andi Gutmans, vice-presidente e gerente geral de nuvem de dados do Google Cloud, ao VentureBeat. “Estamos passando da escala humana para a escala do agente.”
Do sistema de inteligência ao sistema de ação
A premissa central por trás do Agentic Data Cloud é que as empresas estão migrando de operações em escala humana para operações em escala de agentes.
Historicamente, as plataformas de dados foram otimizadas para relatórios, painéis e algumas previsões – o que o Google caracteriza como “inteligência reativa”. Nesse modelo, os humanos interpretam os dados e decidem o que fazer.
Agora, com a expectativa cada vez maior de que os agentes de IA tomem ações diretamente em nome da empresa, Gutmans argumentou que as plataformas de dados devem evoluir para sistemas de ação. “Precisamos ter certeza de que todos os dados corporativos podem ser ativados com IA, o que inclui dados estruturados e não estruturados”, disse Gutmans. “Precisamos ter certeza de que existe o nível certo de confiança, o que também significa que não se trata apenas de obter acesso aos dados, mas de realmente compreendê-los”.
O Catálogo de Conhecimento é a resposta do Google para esse problema. É uma evolução do Dataplex, o produto de governança de dados existente do Google, com uma arquitetura materialmente diferente por baixo. Enquanto os catálogos de dados tradicionais exigiam que administradores de dados rotulassem tabelas manualmente, definissem termos comerciais e construíssem glossários, o Catálogo de Conhecimento automatiza esse processo usando agentes.
A implicação prática para as equipes de engenharia de dados é que o Catálogo de conhecimento é dimensionado para todo o conjunto de dados, não apenas para o subconjunto selecionado que uma pequena equipe de administradores de dados pode manter manualmente. O catálogo abrange BigQuery, Spanner, AlloyDB e Cloud SQL nativamente e é federado com catálogos de terceiros, incluindo Collibra, Atlan e Datahub. A federação de cópia zero amplia o contexto semântico de aplicativos SaaS, incluindo SAP, Salesforce Data360, ServiceNow e Workday, sem exigir movimentação de dados.
A casa do lago do Google atravessa a nuvem
O Google tem um data lakehouse chamado Lago Grande desde 2022. Inicialmente estava limitado apenas aos dados do Google, mas nos últimos anos teve alguns recursos de federação limitados, permitindo que as empresas consultassem dados encontrados em outros locais.
Gutmans explicou que a federação anterior funcionava por meio de APIs de consulta, o que limitava os recursos e otimizações que o BigQuery poderia aplicar em dados externos. A nova abordagem é o compartilhamento baseado em armazenamento por meio do formato aberto Apache Iceberg. Isso significa que se os dados estão no Amazon S3 ou no Google Cloud, ele argumentou que não faz diferença. “Isso realmente significa que podemos trazer todas as vantagens e todos os recursos de IA para esses conjuntos de dados de terceiros”, disse ele.
O resultado prático é que o BigQuery pode consultar tabelas Iceberg no Amazon S3 por meio do Cross-Cloud Interconnect do Google, uma camada de rede privada dedicada, sem taxas de saída e com desempenho de preço que o Google diz ser comparável aos armazéns nativos da AWS. Todas as funções do BigQuery AI são executadas nesses dados entre nuvens sem modificação. A federação bidirecional na versão prévia se estende ao Databricks Unity Catalog no S3, Snowflake Polaris e ao AWS Glue Data Catalog usando o padrão aberto Iceberg REST Catalog.
Da escrita de pipelines à descrição de resultados
O Catálogo de Conhecimento e o Lakehouse entre nuvens resolvem os problemas de contexto e acesso a dados. O terceiro pilar aborda o que acontece quando um engenheiro de dados realmente se senta para construir algo com tudo isso.
O Data Agent Kit é fornecido como um conjunto portátil de habilidades, ferramentas MCP e extensões IDE que podem ser incluídas no VS Code, Claude Code, Gemini CLI e Codex. Não introduz uma nova interface.
A mudança arquitetônica que ela permite é uma mudança do que Gutmans chamou de “experiência prescritiva de copiloto” para uma engenharia orientada pela intenção. Em vez de escrever um pipeline do Spark para mover dados da origem A para o destino B, um engenheiro de dados descreve o resultado — um conjunto de dados limpo e pronto para o treinamento do modelo, uma transformação que impõe uma regra de governança — e o agente seleciona se deseja usar o BigQuery, o Lightning Engine para Apache Spark ou o Spanner para executá-lo e, em seguida, gera o código pronto para produção.
“Os clientes estão cansados de construir seus próprios pipelines”, disse Gutmans. “Eles estão realmente mais no modo de revisão do que no modo de escrever o código.”
Onde o Google e seus rivais divergem
A premissa de que os agentes necessitam de contexto semântico, e não apenas de acesso a dados, é partilhada por todo o mercado.
Databricks tem Unity Catalog, que fornece governança e uma camada semântica em todo o seu lago. Snowflake tem Cortex, sua oferta de IA e camada semântica. Tecido Microsoft inclui uma camada de modelo semântico construída para inteligência de negócios e, cada vez mais, para fundamentação do agente.
A disputa não é sobre se a semântica é importante – todos concordam que sim. A disputa é sobre quem os constrói e mantém.
“Nosso objetivo é apenas obter toda a semântica possível”, explicou ele, observando que o Google se federará com modelos semânticos de terceiros em vez de exigir que os clientes recomecem.
O Google também está posicionando a abertura como um diferencial, com federação bidirecional no Databricks Unity Catalog e Snowflake Polaris por meio do padrão aberto Iceberg REST Catalog.
O que isso significa para as empresas
O argumento do Google – e que tem eco em todo o mercado de infraestrutura de dados – é que as empresas estão atrasadas em três frentes:
O contexto semântico está se tornando uma infraestrutura. Se o seu catálogo de dados ainda for curado manualmente, ele não será dimensionado para as cargas de trabalho dos agentes – e Gutmans argumenta que a lacuna só aumentará à medida que o volume de consultas dos agentes aumentar.
Os custos de saída entre nuvens são um imposto oculto sobre a IA agente. A federação baseada em armazenamento por meio de padrões abertos Iceberg está emergindo como a resposta arquitetônica do Google, Databricks e Snowflake. As empresas presas a abordagens de federação proprietárias devem testar esses custos em volumes de consulta em escala de agente.
Gutmans argumenta que a era da escrita de pipelines está terminando. Os engenheiros de dados que migrarem para a orquestração baseada em resultados terão agora uma vantagem significativa.
