Quando agentes criam dashboards, a governança precisa voltar ao código

Lincoln Ferraz

16 de setembro de 2026 · 8 min de leitura

O dbt Charts propõe dashboards declarados em YAML, SQL e Git. A abordagem amplia versionamento e auditoria, mas não resolve sozinha o problema mais difícil: garantir que todos calculem a mesma métrica.

Em 14 de setembro, a dbt Labs apresentou o dbt Charts como uma linguagem aberta para criar dashboards interativos com SQL e YAML. A proposta responde a uma contradição que começa a aparecer nas empresas: agentes de inteligência artificial conseguem produzir gráficos cada vez mais rápido, enquanto a capacidade humana de conferir o que esses gráficos significam continua limitada.

O anúncio não comprova que o mercado adotará o projeto nem que ele substituirá as plataformas tradicionais de Business Intelligence (BI). O software está em beta, ainda não chegou à versão 1.0 e sua sintaxe pode mudar. Mesmo assim, ele ajuda a enxergar uma mudança importante. Se o agente passa a ser autor de dashboards, a governança não pode depender apenas da interface na qual o resultado aparece.

Ela precisa acompanhar a lógica que produziu o número.

Um copiloto na interface e um dashboard no repositório não são a mesma coisa

A primeira onda de IA aplicada a BI colocou assistentes de conversa dentro das ferramentas visuais. O usuário pede um gráfico, a plataforma interpreta a solicitação e gera uma visualização com os recursos que o produto oferece. Essa solução preserva parte dos controles já existentes, como permissões, fontes conectadas e objetos administrados pela própria ferramenta.

O dbt Charts parte de outra arquitetura. SQL declara quais dados devem ser consultados; YAML descreve como eles serão exibidos. Consultas, filtros, gráficos, textos e layout podem ficar em um arquivo legível, mantido no mesmo repositório Git dos modelos de dados. Em vez de operar uma interface por cliques, o agente trabalha no ambiente em que já é mais competente: arquivos, código e comandos.

A diferença não é apenas técnica. Em uma ferramenta visual, parte relevante da lógica pode permanecer como estado interno do produto. Quando o dashboard vira código, uma alteração pode aparecer como um *diff*: quais linhas entraram, quais saíram, quem fez a mudança e em qual revisão ela foi aprovada.

Isso cria condições para rastreabilidade. Não cria governança por decreto.

O que Git acrescenta à governança

O repositório permite aplicar aos dashboards práticas conhecidas do desenvolvimento de software. Uma mudança pode nascer em uma branch, seguir para um *pull request*, receber comentários e ser testada antes de chegar ao ambiente usado pela empresa. O GitHub também permite designar responsáveis por determinados arquivos com o mecanismo CODEOWNERS e, quando as regras do repositório estão configuradas, exigir a aprovação desses responsáveis antes do merge.

No caso do dbt Charts, o comando `dct validate` verifica a estrutura do YAML sem precisar acessar o *data warehouse*. O `dct render` executa consultas e faz verificações sobre o resultado. Em um projeto dbt, os painéis também podem referenciar modelos com `ref()`, o que aproxima a visualização da transformação dos dados. Segundo a documentação do projeto, uma mudança de modelo e os gráficos dependentes podem seguir na mesma branch e pela mesma execução de integração contínua.

Na prática, esse desenho permite responder perguntas que ficam difíceis quando as alterações acontecem apenas por cliques:

• Qual definição mudou?

• Quem propôs a alteração?

• Quem tinha responsabilidade para aprová-la?

• Quais painéis dependem da coluna modificada?

• É possível voltar ao estado anterior?

Mas a resposta depende da disciplina organizacional. Um arquivo em Git sem política de revisão é apenas um arquivo com histórico. Se qualquer agente puder abrir e mesclar uma alteração sem dono definido, testes adequados e aprovação humana, a empresa terá automatizado a produção do erro e registrado muito bem como ele aconteceu.

Gerar o gráfico é a parte menos difícil

Considere uma pergunta comum: qual foi a receita mensal? O agente consegue escrever uma consulta e desenhar uma linha. O problema começa antes do gráfico. Receita significa pedidos emitidos, pagamentos aprovados ou valor líquido depois de cancelamentos e impostos? A data válida é a da venda, a do pagamento ou a do reconhecimento contábil? A moeda deve ser convertida por qual cotação?

Nenhuma escolha visual resolve essas ambiguidades.

É por isso que a velocidade de geração pode multiplicar versões conflitantes da verdade. Dois agentes recebem instruções ligeiramente diferentes, escrevem duas consultas plausíveis e entregam dois números tecnicamente calculáveis. Ambos podem estar sintaticamente corretos. Só um pode representar a definição que a empresa decidiu usar — e talvez nenhum represente.

Uma análise externa publicada pela Embeddable sobre dashboards como código aponta exatamente essa lacuna: versionamento torna a lógica reproduzível e revisável, mas não garante sozinho definições confiáveis de métricas, segurança em nível de linha ou isolamento entre clientes. A fonte tem interesse comercial no tema e deve ser lida como análise de mercado, não como teste independente do dbt Charts. Ainda assim, o contraponto é válido: código visível não substitui controles de acesso nem consenso de negócio.

O gargalo muda de lugar.

Quando escrever um dashboard era caro, a escassez de especialistas limitava a quantidade de artefatos. Com agentes, o custo de produzir a primeira versão cai. Revisar significado, impacto e acesso passa a ser a etapa crítica. A empresa deixa de perguntar apenas “quem sabe construir o gráfico?” e precisa responder “quem pode definir essa métrica, quem pode contestá-la e quem autoriza sua publicação?”.

A camada semântica é o contrato, não o acabamento

A camada semântica existe para concentrar definições de negócio reutilizáveis. Em vez de cada dashboard reescrever em SQL o cálculo de receita, margem ou cliente ativo, a métrica é definida uma vez e consumida por diferentes ferramentas. A documentação do dbt descreve sua Semantic Layer como uma forma de definir métricas sobre modelos existentes e tratar automaticamente as junções necessárias.

Para agentes, essa camada funciona como um contrato. Ela reduz o espaço em que o modelo precisa improvisar e torna explícitos nome, fórmula, dimensões, granularidade e relações permitidas. Também facilita a contestação: se um número parece errado, a discussão pode chegar à definição compartilhada, em vez de começar pela inspeção de dezenas de gráficos isolados.

Aqui está a principal limitação atual do dbt Charts. A integração com a dbt Semantic Layer ainda não está disponível. O item público que acompanha a funcionalidade informa que os painéis hoje acessam os dados por SQL e precisam repetir a definição das métricas. A proposta de consumir a métrica como ela foi definida no projeto está classificada como planejada, mas ainda sem cronograma e sem formato de autoria definido.

Isso significa que o projeto já oferece mecanismos para validar arquivos, aproximar painéis e modelos e registrar alterações no Git. Mas a promessa mais forte de consistência entre métricas ainda depende de uma integração futura. Tratar o recurso planejado como capacidade atual seria confundir direção de produto com produto entregue.

Código também cobra um preço

Levar dashboards ao repositório favorece equipes que já trabalham com SQL, Git, revisão e integração contínua. Para áreas de negócio acostumadas a ajustar uma visualização diretamente na tela, esse fluxo pode adicionar atrito. Uma mudança simples de rótulo ou layout pode passar a depender de alguém confortável com arquivos e *pull requests*.

O próprio anúncio tenta reduzir essa tensão. A linguagem aberta pode ser usada localmente, enquanto a plataforma hospedada da dbt Charts acrescenta editor visual, histórico, compartilhamento e permissões. É importante separar as duas ofertas: nem todo recurso da plataforma faz parte automaticamente do pacote aberto.

Também há uma questão de responsabilidade. O Git permite definir ownership técnico sobre um arquivo, mas a empresa ainda precisa nomear o ownership de negócio. O líder de dados pode validar a consulta; finanças pode ter autoridade sobre receita; operações pode decidir o que conta como pedido entregue. Sem essa divisão, a revisão corre o risco de conferir apenas se o código funciona.

E código que funciona pode produzir uma decisão errada.

Uma conclusão prática: acelere depois de definir as barreiras

Empresas que quiserem experimentar dashboards produzidos por agentes não precisam começar por uma migração ampla. O caminho mais seguro é escolher um painel de baixo risco e estabelecer antes cinco controles: um catálogo mínimo de métricas aprovadas; um responsável técnico e um responsável de negócio; revisão obrigatória antes da publicação; testes de estrutura, consulta e acesso; e registro do motivo de cada mudança.

Depois disso, o agente pode acelerar a execução dentro de limites verificáveis. O dashboard como código oferece a infraestrutura para histórico, revisão e reversão. A camada semântica oferece o contrato para que “receita” continue significando a mesma coisa em diferentes análises. As políticas de acesso e aprovação determinam quem pode ver e alterar o resultado.

O dbt Charts ainda é uma aposta em beta, não uma prova de que o BI migrou para o Git. Seu valor imediato está em tornar visível a pergunta que a automação costuma esconder: se produzir ficou fácil, como garantir que o que foi produzido merece confiança?

A velocidade do agente só vira vantagem quando a organização sabe onde colocar o freio.