Dashboard de dados com IA: do Excel ou SQL

Para criar um dashboard de dados com IA, mostre seus dados a um agente de código e peça que ele escreva o código de análise: ele lê seus dados de Excel, CSV ou SQL com pandas, limpa e resume tudo, e transforma isso em um dashboard interativo em Streamlit em poucas horas. Se o dashboard fizer parte de um produto, você faz o mesmo com Next.js e uma biblioteca de gráficos. O que precisa da sua atenção não é o código; é se os números estão certos e se os dados continuam privados.

Este post vai passo a passo de uma planilha de vendas até um dashboard que você pode compartilhar: ferramentas, o primeiro prompt, conexão com o banco de dados só para leitura, conferência das contas da IA e deploy.

O que vamos construir

O objetivo é substituir um relatório em Excel que você atualiza à mão toda semana por um dashboard que se atualiza sozinho. Um dashboard de vendas típico tem: o total do período, a variação em relação ao período anterior, um gráfico de receita mensal, os produtos mais vendidos, uma divisão por região ou canal e um filtro de datas.

Vamos fazer isso no estilo vibe coding: o agente escreve o código, você descreve o que quer ver e confere o resultado. Em trabalho com dados, essa abordagem tem uma condição: você precisa conhecer seus dados bem o suficiente para questionar os números que ela produz.

Qual caminho: Streamlit ou Next.js?

O caminho rápido: Python, pandas e Streamlit. Um único arquivo Python vira uma interface web funcionando. Filtros, tabelas, gráficos e cartões de métricas levam poucas linhas cada. Se você precisa de um dashboard interno para você, seu gestor ou uma equipe pequena, esse é o caminho mais curto. O pandas lê Excel, CSV e SQL igualmente bem.

O caminho de produto: Next.js e uma biblioteca de gráficos. Se clientes vão ver o dashboard e você precisa de login de usuários, permissões de dados por usuário e um design alinhado à sua marca, um app baseado em React se encaixa melhor. Recharts, Chart.js e ECharts são escolhas comuns. Os dados são consultados no servidor, em uma API route, e só o resumo de que o usuário precisa chega ao navegador.

Na dúvida, comece com Streamlit. Migrar para um produto fica muito mais fácil quando você já sabe quais gráficos as pessoas realmente usam.

Passo 1: preparação

Um agente de código de terminal (Claude Code, Codex, Gemini CLI, a CLI do Cursor e assim por diante) e Python bastam:

mkdir sales-dashboard && cd sales-dashboard
git init
python3 -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install pandas openpyxl streamlit plotly
mkdir data && cp ~/Downloads/sales_2026.xlsx data/
echo "data/" >> .gitignore
echo ".env" >> .gitignore

Deixo data/ fora do git desde o início; dados de clientes não têm nada que fazer no repositório.

Passo 2: conheça os dados primeiro

O erro mais comum é dizer ao agente “monte um dashboard” logo de cara. Peça primeiro que ele entenda os dados. Esse primeiro turno não desenha nada; só gera um relatório:

Read data/sales_2026.xlsx with pandas and write me a data report:
- Sheet names, row and column counts per sheet
- Each column’s type, share of empty values and 5 sample values
- Format of date and money columns (any comma decimals or mixed formats?)
- Duplicate rows and likely key columns (such as order ID)
- Anything that looks inconsistent
Don’t change any file and don’t draw charts. Save the report as analysis/data_report.md.

Leia esse relatório. Descobertas como “37 linhas da coluna Amount vieram como texto” ou “o mesmo ID de pedido aparece duas vezes” afetam todos os números que vêm depois. Você decide o que é erro e o que é real (reembolsos, pedidos divididos); não deixe o agente corrigir os dados no chute.

Passo 3: o prompt do dashboard

Com os dados limpos, peça o dashboard. Escreva as perguntas que ele precisa responder; o agente pode sugerir os tipos de gráfico:

Write app.py with Streamlit. Data: data/sales_2026.xlsx, sheet "Sales".

Put cleaning in its own function (load_data), cached with st.cache_data.
Refunds (Amount < 0) count towards revenue and are also shown as a separate metric.

The dashboard should answer:
1. Total revenue, order count and average order value for the selected date range
   (each with change versus the same period last year)
2. Monthly revenue trend (line chart)
3. Top 10 products by revenue (horizontal bar)
4. Revenue by region (bar) with a region filter

Rules:
- All calculations in metrics.py as pure functions.
- Write pytest tests for metrics.py using a small sample dataset with hand-calculated results.
- Format money with the right currency symbol and thousands separators.
When done, run the tests and tell me the streamlit run command.

Manter os cálculos em um arquivo separado, com funções testáveis, é a parte mais importante desse prompt. A interface é fácil de mudar; uma função de total errada quebra todos os gráficos.

pytest -q
streamlit run app.py

Olhe o dashboard no navegador e depois peça pequenas mudanças: “Os nomes dos produtos estão cortados, deixe na horizontal.” “Deixe o filtro de datas no mês atual por padrão.” Faça commit depois de cada mudança para poder voltar atrás.

Passo 4: conecte ao banco de dados só para leitura

Se os dados estão no banco do seu app e não em uma planilha, a regra principal é: o usuário do dashboard só pode ler. Um usuário separado no PostgreSQL:

CREATE ROLE dashboard_reader LOGIN PASSWORD 'a-strong-password-here';
GRANT CONNECT ON DATABASE app TO dashboard_reader;
GRANT USAGE ON SCHEMA public TO dashboard_reader;
GRANT SELECT ON orders, order_items, products TO dashboard_reader;

Coloque a string de conexão no .env (DATABASE_URL=...) e diga ao agente apenas o nome da variável. Mais alguns pontos práticos:

• Dê acesso só às tabelas necessárias. Se a tabela de usuários guarda e-mails e telefones e o dashboard não precisa deles, ele não deveria conseguir lê-los.
• Use uma réplica de leitura ou uma cópia noturna quando puder. Uma consulta pesada escrita pelo agente pode deixar o sistema em produção lento.
• Defina um timeout de consulta (statement_timeout no PostgreSQL) e limite o tamanho dos resultados.
• Peça ao agente para manter o SQL em arquivos .sql separados; isso facilita ler e rodar as consultas à mão.

Passo 5: confira os números

Esta é a seção mais importante. A falha mais perigosa de um dashboard não é travar; é mostrar um número errado em um gráfico convincente.

Compare os totais principais à mão

Calcule 3 ou 4 números-chave de outra forma: uma tabela dinâmica no Excel, ou uma consulta SQL simples escrita por você. A receita de março, por exemplo:

SELECT SUM(total) FROM orders
WHERE created_at >= '2026-03-01' AND created_at < '2026-04-01'
  AND status <> 'cancelled';

Se o dashboard não bater, não siga em frente até conseguir explicar a diferença. A resposta costuma ser uma destas: os cancelamentos estão incluídos, onde estão os reembolsos, o imposto está incluído, qual fuso horário?

O join errado e silencioso

Este é o erro de SQL que a IA mais comete e o mais difícil de perceber:

-- WRONG: each order is repeated once per line item
SELECT SUM(o.total)
FROM orders o
JOIN order_items i ON i.order_id = o.id;

Um pedido com três itens vira três linhas, e o.total é somado três vezes. A consulta roda sem erro, o resultado parece plausível e a receita sai inflada. A correção é agregar no nível certo: ou somar só sobre orders, ou resumir os itens por pedido primeiro e depois fazer o join. Para conferir, pergunte ao agente:

For each JOIN in this query: is the row count after the join the same as the
row count of the main table before it? Show COUNT(*) and COUNT(DISTINCT o.id).

Se os dois números forem diferentes, há linhas se multiplicando em algum lugar.

Outras armadilhas

• Limites de datas: BETWEEN '2026-03-01' AND '2026-03-31' em uma coluna timestamp perde quase todo o dia 31 de março. Use um intervalo semiaberto.
• Fusos horários: se o banco guarda em UTC, pedidos perto da meia-noite caem no dia errado.
• Média de médias: a média do ticket médio de cada região não é o ticket médio geral.
• Valores ausentes: linhas com NaN somem em silêncio de algumas operações do pandas.

Passo 6: compartilhe e faça deploy

• Streamlit: para uso interno, rode em um servidor ou em um contêiner Docker atrás da rede da empresa ou de uma camada de login. O Streamlit também tem seu próprio serviço de hospedagem, mas não coloque um dashboard com dados de clientes em uma URL pública; você deve saber quem tem acesso.
• Next.js: faça deploy em uma plataforma como a Vercel ou no seu próprio servidor. Verifique no servidor a autenticação e se cada usuário vê apenas os próprios dados; filtrar só na interface não é segurança.
• Manter os dados atualizados: em dashboards baseados em planilha, ler o arquivo de uma pasta compartilhada ou carregá-lo em um banco com um pequeno script noturno acaba com as atualizações manuais.

O que a IA costuma errar

• “Consertar” dados no chute: preencher vazios com zero, descartar datas que não consegue interpretar. Faça-a escrever cada regra de limpeza explicitamente e aprove-as.
• Nomes de colunas inventados: sem ver o schema, ela inventa uma coluna como customer_name. Dê a ela o schema real.
• Formatos de número: ler 1.234,56 como 1.234. Peça para mostrar os valores brutos e os interpretados lado a lado.
• Fazer gráfico de tudo: um dashboard com 15 gráficos é um dashboard que ninguém olha. Limite-o às perguntas que importam.
• “Eu verifiquei”: um agente testando o próprio código com o próprio teste pode cometer a mesma suposição errada duas vezes. Confira você mesmo um número.

Segurança e privacidade

• Dados de conexão no .env, com .env e data/ fora do git.
• Nunca cole uma senha ou string de conexão no chat. Dê ao agente o nome da variável.
• Não envie dados brutos de clientes ao modelo. O agente precisa do schema e de algumas linhas de exemplo para escrever o código; anonimize os exemplos ou gere dados falsos. Quem processa os dados é o código na sua máquina, não o modelo. Suas obrigações legais sobre dados pessoais (LGPD, GDPR) não mudam.
• Leia os comandos e o SQL que o agente executa. Rodar qualquer coisa com DELETE, UPDATE ou DROP pelo usuário do dashboard deveria ser impossível de qualquer forma; é para isso que serve o usuário só de leitura.
• Saiba quem pode ver a URL do dashboard. Compartilhar um link é compartilhar os dados.

Fazendo isso com o AgentVera

Nada do que está acima exige uma ferramenta específica. Eu faço esse tipo de trabalho no AgentVera porque ele encurta alguns passos de banco de dados:

• Gerenciador de banco de dados. O gerenciador de banco de dados conecta a PostgreSQL, MySQL/MariaDB e SQLite. Uma conexão marcada como “read-only” também é aberta só para leitura do lado do servidor. Você pode rodar o SQL do agente no editor SQL para comparar totais e usar EXPLAIN para encontrar consultas pesadas.
• Acesso controlado dos agentes. Se você ativar o acesso de agentes em uma conexão, os agentes que suportam MCP fazem consultas pela ferramenta agentvera-db; eles nunca veem a senha, o modo padrão é só leitura e toda consulta fica registrada. O botão “AI”, que transforma um pedido em SQL, envia nomes de tabelas e colunas, não as linhas das tabelas.
• DB Guard. Se o agente escrever uma migration de índice ou view para o dashboard, o DB Guard a analisa ao fim do turno e aponta riscos como criação de índice com lock ou perda de dados.
• Agentes em paralelo e previews. O Claude Code pode escrever o SQL e as métricas em um painel enquanto o Codex trabalha na interface em outro, cada um no seu próprio git worktree. Os ambientes de preview iniciam o servidor de cada worktree em uma porta própria.
• Revisão de diff. A revisão de código dá uma segunda olhada nas funções de métricas antes do merge.

O gerenciador de banco de dados e o acesso de agentes estão nos planos Pro e Team. Para saber mais sobre como conferir código escrito por agentes, veja revisão de código com IA; para trabalhar em paralelo, veja git worktrees para agentes em paralelo.

Checklist rápido

• O agente escreveu primeiro um relatório dos dados, e você aprovou as regras de limpeza
• Os cálculos ficam em funções separadas e testadas
• Pelo menos 3 números principais conferidos à mão de outra forma
• Contagem de linhas conferida em cada JOIN
• A conexão com o banco usa um usuário só com SELECT
• .env e data/ fora do git, nenhum dado de cliente enviado ao modelo
• Acesso ao dashboard limitado a pessoas conhecidas

Conclusão

Criar um dashboard com IA acelera a programação, mas não terceiriza o raciocínio. O agente escreve código em pandas, SQL e Streamlit em minutos; decidir qual número está certo e quais dados podem ser compartilhados continua sendo trabalho seu. Escolha um relatório em Excel que você atualiza à mão nesta semana, peça primeiro ao agente um relatório dos dados, monte o primeiro dashboard em Streamlit e confira você mesmo três números.