Notas de Campo: A Camada Semântica Deixou de Ser Tema de BI em Vegas

Post 3 de 5 das minhas notas de campo do Cloud Next 2026. Este é sobre a camada semântica — um tema que times de BI vêm escrevendo sobre há vinte anos e que times de IA acabaram de redescobrir, da maneira difícil. Sentei na sessão da Looker porque a pergunta com a qual cheguei a Vegas é pouco glamourosa: quando um agente de IA consulta o nosso data warehouse e escreve “receita”, de quem é a definição que ele usa?

A sala estava cheia. Os slides eram familiares para qualquer um que viveu os debates Looker–Tableau–Power BI da última década. O que era diferente era o enquadramento. Miles, PM sênior de Looker, abriu com um slide que eu esperava que fosse sobre dashboards e que acabou sendo sobre agentes. Alex Plepsow seguiu e tornou o argumento explícito: a camada semântica não é mais uma feature de BI. É o plano de governança entre os seus dados e o LLM que está prestes a escrever uma consulta sobre eles.

Quero passar pelo que mostraram, pelo que eu acho que de fato importa, e por onde eu começaria se estivesse rodando infraestrutura de dados hoje e ainda não estivesse na Looker.

O enquadramento do caos de dados

A abertura foi a padrão e estava correta. Empresas têm dados espalhados entre BigQuery, Snowflake, Postgres e uma cauda longa de sistemas operacionais. A mesma pergunta de negócio — “qual foi a nossa receita no último trimestre” — recebe uma resposta SQL diferente dependendo de quem escreve a consulta, qual tabela é consultada, se devoluções são líquidas e se o filtro de data respeita trimestre fiscal ou calendário.

Humanos convivem com essa ambiguidade há muito tempo. Dois analistas produzem dois números, a reunião discute por quinze minutos qual está certo e alguém eventualmente vence. O custo é incômodo.

Agentes não produzem esse debate. Produzem um número, anexam uma frase confiante a ele e seguem em frente. Se o número está errado, a confiança não muda. O custo deixa de ser incômodo e vira risco operacional, porque o agente não pausa no momento em que um analista humano teria pausado.

Esse foi o enquadramento com que a equipe de Looker começou. Acho que é a versão mais honesta da história de governança de IA que ouvi em qualquer keynote desta semana.

O que a camada semântica de fato faz

Uma camada semântica é um tier de tradução entre perguntas de negócio e SQL. Você define, uma vez, o que “receita” significa — qual tabela, quais colunas, quais filtros, qual conversão de moeda. Define o que é um “cliente”. Define o que é “risco de churn”, e o grafo de joins e a agregação por trás disso. A partir dali, qualquer um — ou qualquer coisa — que peça receita recebe a mesma resposta.

A versão da Looker é construída em torno de três desafios que, segundo eles, agentes têm dificuldade em data warehouses crus e que a camada semântica absorve:

Filtros de data relativa. “Últimos 30 dias”, “trimestre passado”, “ano até hoje”. O agente não precisa raciocinar sobre calendário fiscal ou fuso horário. A definição da métrica resolve.
Joins complexos entre tabelas. O agente não precisa descobrir que o fato de pedidos e o fato de devoluções compartilham uma chave parcial com uma ressalva conhecida sobre devoluções parciais. O join está codificado no modelo.
Medidas complexas. Medidas filtradas como “receita menos devoluções”, ou razões como “margem bruta”, vivem no modelo. O agente pede a métrica nomeada. Não escreve o SQL que a produz.

O punchline arquitetural é que o LLM não precisa ingerir o dataset para responder perguntas sobre o dataset. Ele lê metadados de métrica. Os dados ficam onde estão. Essa é uma mudança relevante. É a diferença entre dar ao agente um dicionário e entregar a biblioteca inteira.

LookML, e por que é mais entediante do que parece

LookML é a linguagem de modelagem da Looker. É código. Vive no git. Tem pipelines de CI/CD. Revisões acontecem em pull requests.

Essa é a parte sem glamour da história e acho que é a mais importante. Seja o que for a camada semântica conceitualmente, na prática ela precisa ser versionada e revisada como qualquer outra peça de infraestrutura governada. Se a sua “fonte única da verdade” para receita vive em uma UI que qualquer pessoa pode editar, você tem um wiki, não um plano de governança. LookML, a camada semântica do dbt, Cube — não se diferenciam pela elegância da sintaxe. Se diferenciam pelo fato de a mudança em “receita” deixar uma trilha de auditoria.

A mesma superfície governada, uma vez definida em LookML, é exposta a dashboards e a agentes via o serviço MCP do Looker. Um modelo, dois consumidores. Essa parte é genuinamente útil. O dashboard que o CFO abre na segunda-feira de manhã e o agente que rascunha o relatório de board na terça leem a mesma definição de métrica.

A camada de analytics conversacional

A Google está unificando analytics conversacional em três superfícies: Data Canvas (BigQuery direto), a plataforma Looker (BI governado mais IA) e Data Studio Pro (BigQuery mais Looker mais planilhas). A pitch é que você escolhe a superfície que combina com o usuário, mas todas se apoiam na mesma espinha semântica quando ela existe.

A leitura honesta disso é que a Google está reposicionando o Looker. Não como a ferramenta de BI que compete com Tableau, mas como o plano de governança para IA no GCP — conectado ao que estão chamando de camada universal de contexto, junto com o catálogo de conhecimento e os metadados do BigQuery. Se esse reposicionamento vai dar certo é outro ensaio. A intenção arquitetural está clara.

O caso da Overdose

O demo mais útil foi Paul Pritchard, da Openhouse Media, e Ryan, da Overdose Digital, apresentando um projeto para a Cook Brothers. Time de três pessoas, seis meses, marca de varejo. Construíram o que chamaram de “cérebro” semântico ancorado em lucro, não em receita — que é o tipo de escolha de definição que um time de marketing normalmente nunca tem a chance de fazer explicitamente.

Em cima desse cérebro, construíram um sistema multi-agente chamado Cradle. Ele gera briefs criativos, peças de anúncio e ciclos de feedback. O enquadramento que usaram foi “ver o que está acontecendo, decidir, agir.” Eu sou cético da metade “agir” até ver as guardrails, mas a metade “ver e decidir” foi crível porque a fundação era uma camada semântica à qual todos no sistema — humanos e agentes — se referiam.

Não vou inventar detalhes sobre os resultados financeiros além do que mostraram no palco. O que estou disposto a afirmar é que um time pequeno com uma definição de métrica clara foi mais longe em seis meses do que vi times maiores irem em dois anos sem ela.

Minha contribuição: comece pequeno, atrás de um MCP

Aqui é onde eu divirjo do keynote.

Se você ainda não está na Looker, minha recomendação não é comprar Looker com base nesta sessão. A camada semântica é a ideia certa. Looker é uma implementação dela. A camada semântica do dbt é outra. Cube é outra. Views SQL curadas à mão atrás de um serviço MCP dedicado é outra, e para a maior parte das empresas eu acho que esse é o lugar certo para começar.

Escolha as cinco a dez métricas pelas quais o seu negócio de fato discute. Receita. Clientes ativos. Taxa de churn. Margem bruta. Cobertura de pipeline. Qual for a sua lista específica. Defina cada uma — uma vez — como uma consulta parametrizada atrás de um MCP dedicado. Documente a definição em português claro ao lado da consulta. Conecte os seus agentes a esse MCP e proíba-os de ir direto ao data warehouse para esses conceitos.

Você vai capturar a maior parte do valor de uma camada semântica a uma fração pequena do custo. E vai descobrir, no processo de escrever essas dez definições, que três delas são contestadas dentro do negócio e que essa disputa estava mascarada pelo fato de cada um usar um SQL ligeiramente diferente. Só isso já vale o exercício.

Quando você souber quais métricas de fato precisa governar, aí pode decidir entre Looker, a camada semântica do dbt ou construir a sua própria em escala. Vai estar escolhendo com informação, não com pitch de fornecedor.

O que eu trouxe de Vegas

A camada semântica não é uma ideia nova. A razão pela qual ela importa de repente é que a população de consumidores que consultam o data warehouse acabou de crescer uma ordem de magnitude, e os novos consumidores não pausam quando a resposta deles está errada. Governar a definição da métrica deixa de ser cortesia de BI e vira pré-condição para deixar agentes chegarem perto dos dados.

Você pode comprar esse plano de governança. Também pode construir a primeira versão dele em uma semana com cinco métricas atrás de um MCP. As pessoas em quem confio nesse tema são as que começaram com cinco métricas primeiro.

Fontes

Google Cloud. “Google Cloud Next 2026.” Abril de 2026.
Google Cloud. “Looker.” Abril de 2026.
Overdose Digital. “overdose.digital.” Abril de 2026.
Notas pessoais do autor, presencial em Las Vegas.

A Victorino ajuda times a desenhar a camada semântica de governança entre seus dados e seus agentes: contato@victorino.com.br | www.victorino.com.br