Data agent no ChatGPT Work: o que a OpenAI lançou e como conferir o dashboard antes de mostrar ao time

Dashboard bonito rodando no canal do time com um número errado dentro é o jeito mais rápido de queimar a confiança de todo mundo nos dados

Em 10 de setembro de 2026 a OpenAI apresentou o Data agent no ChatGPT Work: ele conecta dados da empresa, investiga o que mudou e monta dashboards interativos compartilháveis, tudo em linguagem natural, na mesma conversa

O anúncio é massa, sem dúvida

Mas ele para exatamente onde começa o teu problema: como você sabe que aquele painel está certo antes de mandar pro time? É isso que a gente cobre aqui, o que foi lançado e a checagem que o lançamento não faz por você 🙂

O que a OpenAI anunciou e por que isso importa agora

A proposta é tirar a análise do vai e vem entre ferramentas

Segundo a OpenAI, o usuário conduz e refina a análise numa única conversa, sem escrever consultas e sem aprender outra ferramenta de analytics

Ou seja: você pergunta, o agente busca, você discorda, ele refaz, tudo no mesmo lugar

E o alcance do que dá pra plugar é bem grande. Se liga:

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

A própria OpenAI também soltou números de uso interno pra sustentar o anúncio: quase todo o time de produto e mais de dois terços da organização de go-to-market já usam data agents no ChatGPT Work

E o agente de dados interno deles consulta mais de 600 petabytes, abrangendo cerca de 70.000 datasets

Aqui vale a ressalva chata mas necessária: isso é a OpenAI falando da OpenAI

Não é auditoria independente, é relato de quem lançou o produto

O anúncio oficial ainda cita clientes que testaram na fase alpha: Zipline, Empower, Piston, Doeren Mayhew, CookUnity, Turing, micro1 e Unit8

Quem se beneficia e o que muda no dia a dia de quem mexe com dados

Traduzindo o anúncio pra quem vai sentir na pele:

• Analista de dados: deixa de ser o gargalo de toda pergunta simples que cai no chat, porque o gestor consegue puxar o recorte sozinho
• Dev que mantém pipeline: ganha um consumidor novo (e bem falante) em cima das tabelas que você mantém, o que joga luz em modelagem porca e em nomenclatura confusa
• Gestor que pede número: pergunta em português, recebe gráfico, e é justamente aí que mora o risco de circular coisa não conferida

A parte mais interessante pra quem já tem stack montada é a camada semântica

Que camada semântica? É onde vivem as definições do teu negócio: o que conta como "receita", o que é "cliente ativo", qual filtro entra e qual não entra

A OpenAI descreve que o agente interpreta os dados usando termos de negócio, definições de métricas, cálculos customizados e relações entre dados, puxando contexto de fontes como Databricks Genie Ontology, dbt, GitHub, Snowflake Horizon e dashboards de BI

Ou seja: se a tua definição de métrica já está versionada em algum lugar, ela vira insumo. Se está na cabeça de três pessoas, o agente vai inferir alguma coisa, e inferência não é acordo

Quem já brincou de conectar o ChatGPT a um banco MySQL sabe o tamanho da diferença entre "o modelo consegue ler a tabela" e "o modelo entende o que a tabela significa"

E quem monta orquestração fora do chat, tipo workflows multiagentes com n8n, vai reconhecer o padrão: o agente é bom no caminho, o problema é sempre o contrato de dado na ponta

Um detalhe que não dá pra ignorar: disponibilidade depende de plano (o recurso está ligado a Business e Enterprise) e de liberação do administrador

Antes de conectar: governança que o administrador precisa definir

Antes de sair plugando base, o combinado com o admin

O que está documentado:

• O recurso está ligado aos planos Business e Enterprise do ChatGPT Work
• Administradores escolhem quais conexões de dados ficam disponíveis e quais funções podem usá-las
• As consultas aplicam as permissões existentes da conta conectada, incluindo restrições de tabela, linha e coluna
• O caminho de administração é Workspace settings > Plugins, selecionando Data pra revisar a política de instalação e gerenciar o acesso por função ou grupo

Tome cuidado com isso aqui: a documentação avisa que instalar o plugin e ter acesso ao app subjacente são coisas separadas

O plugin pode estar instaladinho e bonito enquanto o app exigido ainda precisa de configuração, autorização ou liberação no workspace

Já vi gente passar tarde inteira achando que era bug sendo permissão faltando 😅

Uma recomendação editorial nossa, que não é recurso de produto: antes do primeiro pedido, escreva num documento a definição de cada métrica que você vai pedir

Qual período, qual filtro, o que entra e o que fica de fora

Isso não é burocracia, é o que permite comparar a resposta do agente com alguma coisa. Sem definição escrita, qualquer número parece plausível

Como conectar uma fonte e conferir o dashboard antes de mostrar ao time

O fluxo abaixo usa só o que está documentado. Bora?

1. Instale o plugin Data: localize e selecione Data no diretório de plugins e, se ele ainda não estiver instalado, escolha Install plugin

O erro comum deste passo: achar que instalou e está pronto. Como já falamos, o acesso ao app é separado, então se nada responder, o caminho é o admin, não o prompt

2. Inicie a conversa chamando o agente: digite @Data no campo do prompt

O erro comum deste passo: escrever a pergunta sem acionar o @Data e receber uma resposta genérica do chat, sem consulta nenhuma por trás

3. Escolha uma fonte pequena e conhecida pro primeiro teste: uma tabela que você já sabe de cor o total, não o data warehouse inteiro

O erro comum deste passo: estrear em cima da base mais crítica da empresa, justamente aquela onde você não tem como conferir nada na mão

4. Escreva o pedido no formato que a documentação orienta: descreva a pergunta de negócio incluindo fonte, métrica, período e comparação desejada

O exemplo oficial é esse:

   @Data Compare revenue this quarter with last quarter and explain the largest changes

Na prática, escreva a tua versão explicitando tudo o que você não quer que seja adivinhado:

   @Data Na tabela de pedidos, some o valor liquido por mes
   entre 2026-01-01 e 2026-06-30, excluindo pedidos cancelados
   e reembolsos, e compare com o mesmo periodo do ano anterior

O erro comum deste passo: pedir "receita do semestre" e deixar cancelamento, reembolso e fuso horário por conta da inferência

5. Peça a lógica e as premissas antes de olhar o gráfico: mande o agente declarar quais tabelas usou, quais filtros aplicou e como chegou em cada métrica

O erro comum deste passo: aceitar o resumo como se fosse auditoria. Ele é ponto de partida da conferência, não o fim dela

6. Valide contra uma consulta feita por fora: quatro checagens, sempre as mesmas

   -- 1) total geral do periodo
   SELECT SUM(valor_liquido) AS total
   FROM pedidos
   WHERE data_pedido BETWEEN '2026-01-01' AND '2026-06-30'
     AND status NOT IN ('cancelado', 'reembolsado');

   -- 2) contagem de linhas consideradas
   SELECT COUNT(*) AS linhas
   FROM pedidos
   WHERE data_pedido BETWEEN '2026-01-01' AND '2026-06-30'
     AND status NOT IN ('cancelado', 'reembolsado');

   -- 3) um recorte que voce ja conhece de cor
   SELECT SUM(valor_liquido) AS total_mes
   FROM pedidos
   WHERE data_pedido BETWEEN '2026-03-01' AND '2026-03-31'
     AND status NOT IN ('cancelado', 'reembolsado');

   -- 4) o caso de borda (o registro estranho que sempre existe)
   SELECT *
   FROM pedidos
   WHERE valor_liquido <= 0
      OR data_pedido IS NULL;

O erro comum deste passo: conferir só o total geral. Total bate fácil, é a soma de tudo. O que quebra é o recorte

7. Anote período, filtro e fonte de cada número antes de compartilhar: uma nota curta ao lado de cada card, dizendo de onde aquilo saiu

O erro comum deste passo: mandar o painel e deixar a nota "pra depois". Depois vira nunca, e a primeira pergunta da reunião vai ser exatamente "esse número considera cancelado?"

O resultado que você quer sair daqui é bem concreto: um dashboard com pelo menos três números conferidos na mão e uma nota de período, filtro e fonte pra cada um

Três checagens que pegam erro de dashboard gerado por IA

O número que bate no total mas quebra no recorte

Esse é o clássico

O total do semestre fecha certinho, todo mundo relaxa, e aí alguém filtra por região e o valor não fecha com nada

Geralmente é filtro aplicado em um nível e não no outro, ou linha duplicada que some na soma geral e aparece no corte

Por isso a checagem de contagem de linhas importa tanto quanto a de valor: duas consultas podem dar o mesmo total com quantidades de linha completamente diferentes

A junção que ninguém pediu

Você pede receita por cliente, o agente encontra uma tabela de contatos e junta

Parece útil

Aí o cliente que tem três contatos cadastrados aparece com a receita multiplicada por três, e o gráfico fica lindo apontando pro céu

A pergunta de checagem é sempre a mesma: quais tabelas entraram nesse número e por qual chave? Se a resposta não bate com o que você pediu, a conversa acabou ali

A métrica que muda de cálculo entre uma conversa e outra

Você pergunta hoje, dá um valor

Semana que vem, outra pessoa pergunta parecido, dá outro

Nenhum dos dois está "quebrado", os pedidos é que foram diferentes. É exatamente pra isso que serve a definição escrita que a gente sugeriu lá em cima, e é por isso que camada semântica versionada vale ouro

A orientação da OpenAI, aliás, vai na mesma direção: quando o ChatGPT usa Python na análise, a documentação manda revisar o código gerado, as saídas e as premissas antes de confiar no resultado

Traduzindo pro nosso contexto: revisar a lógica não é desconfiança exagerada, é o uso recomendado ✌️

Limites do Data agent: o que ainda não dá para assumir

Parte honesta do papo

Não existe benchmark público de acurácia ou correção divulgado pra esse recurso

O que existe é relato da própria OpenAI sobre o próprio uso, e isso não é verificação independente

Outro ponto que confunde bastante: a descrição de um agente que resume premissas e passos de execução, e que linka os resultados subjacentes pra você inspecionar o dado bruto, aparece no relato da OpenAI sobre o agente interno deles

Não é a mesma coisa que garantir que a interface do produto te entrega a consulta exata de cada card do dashboard

Então evite construir teu processo assumindo que esse botão existe. Construa assumindo que a conferência é tua

E fica o princípio que resume tudo:

valor apresentado com confiança não é valor auditado

O agente vai responder com a mesma segurança tanto no número certo quanto no número errado, porque é assim que esses sistemas se comportam

Conclusão

O Data agent no ChatGPT Work resolve um problema real: tirar a análise do gargalo de quem sabe escrever consulta e levar pra conversa, com dashboard interativo no fim

O próximo passo prático é bem direto:

• alinhe com o administrador o que fica disponível em Workspace settings > Plugins, incluindo quais funções podem usar
• rode o primeiro teste numa fonte pequena e conhecida, nunca na base crítica
• só circule o painel com pelo menos três números conferidos manualmente e uma nota de período, filtro e fonte

E antes de conectar qualquer base sensível, dá uma passada na documentação oficial da OpenAI pra confirmar quais conectores existem hoje, quem pode habilitar e como o dado é tratado nesse fluxo

Dashboard errado circulando internamente custa mais caro que uma tarde de conferência, sempre

Até o próximo post! 😀