Resposta direta: montamos o BI de uma corretora de seguros multiramo a partir do ERP SACWEB: 4 painéis com login por perfil (diretoria, comercial, financeiro e cobrança, renovação), alerta de renovação e um chat de IA dentro do painel. O chat roda com o Gemini 3.7 Flash e responde em português usando as mesmas funções que alimentam as telas, então o número da conversa é sempre o número do painel.
listar_vencimentos42 apólices de automóvel vencem até o fim do mês, somando R$ 38.400 de comissão nos últimos 12 meses.
As 5 maiores concentram R$ 14.900. Três delas vencem em menos de 15 dias e estão sem cotação: são a prioridade.
Quer que eu proponha uma ação para o time de renovação?
Por que corretora de seguros precisa de BI (e de mais do que BI)
Numa corretora, os números que importam estão todos no sistema: comissão por seguradora, produção por ramo, inadimplência, apólices vencendo. O difícil é chegar neles na hora certa. A diretoria quer saber quanto entrou no caixa. O comercial quer ver a produção do mês contra o ano anterior. O financeiro precisa saber qual seguradora pagou comissão a menor. A renovação precisa da lista do que vence, em ordem de importância.
Cada uma dessas perguntas costuma virar um relatório exportado e uma planilha. Um dashboard de corretora resolve a parte de olhar: cada perfil abre o seu painel e vê o que precisa. Mas painel só responde o que alguém previu quando montou a tela. Por isso o projeto teve duas camadas: os painéis por perfil e um chat de IA dentro deles, para a pergunta que a tela não previu.
Os 4 painéis: cada perfil vê o seu
Diretoria
- Faturamento
- O que precisa de ação
- Vencimentos em 30 e 90 dias
- Carteira: emitidas, renovadas, clientes ativos
- Concentração nos maiores clientes
- Vê todos os painéis
Comercial
- Produção registrada
- Comissão por ramo e por seguradora
- Cancelamentos a investigar
- Clientes monoproduto
- Renovações nos próximos 60 dias
Financeiro e cobrança
- Comissão a receber
- Comissão paga a menor
- Receita faturada
- Parcelas a vencer
Renovação
- Taxa de renovação
- Não renovadas e recuperáveis
- Vencimentos em até 5, 15 e 30 dias
A separação por perfil não é só visual. A trava existe em dois lugares: na aplicação, que não deixa abrir a tela de outro perfil, e no banco, com regras de acesso por linha (Row Level Security do Supabase). Se alguém tentar chegar ao dado por fora da tela, o banco recusa. A diretoria vê os 4 painéis; os outros perfis veem o seu.
Dois alarmes nasceram de pedidos da própria corretora: renovação de automóvel com menos de 5 dias para vencer e o comparativo de comissão e prêmio do ano atual contra o anterior.
Como o BI conversa com o SACWEB
O ERP da corretora é o SACWEB, sistema muito usado por corretoras no Brasil. Ele libera relatórios do tipo Power BI pela API, e foi por aí que entramos. Nada foi instalado no ERP e a rotina de quem lança apólice não mudou.
A montagem ficou assim:
- Coleta nas janelas da API. A API do SACWEB só responde em três janelas de duas horas por dia (manhã, almoço e fim da tarde). Uma função agendada no Supabase roda logo no começo de cada janela, e repete a coleta 15 e 30 minutos depois para garantir que o dado do dia chegou. O agendamento usa o Supabase Cron.
- Dados em duas camadas. O que chega da API é guardado como veio, e uma segunda camada traz as tabelas limpas e as visões já agregadas por painel. Como as janelas são escassas, dá para reprocessar tudo sem chamar a API de novo.
- Painéis em Next.js. A aplicação é feita em Next.js, publicada na Vercel, com login do Supabase. O banco fica na região de São Paulo, porque há dado de segurado e a LGPD pede cuidado com onde ele mora.
- Chat com o Gemini. O chat usa o Gemini, do Google, pelo AI SDK, com chamada de ferramentas (function calling).
Como funciona o chat com IA nos dados
A decisão mais importante do projeto foi esta: o chat nunca escreve consulta ao banco. Não é text-to-SQL. Ele tem 15 ferramentas, e cada ferramenta é um invólucro fino sobre uma função que uma tela do painel já usa (caixa da diretoria, comissões, produção comercial, vencimentos, comissão paga a menor, concentração de clientes e outras).
Isso garante três coisas:
- O chat não diverge do painel. É a mesma função. Se o painel mostra um número, o chat mostra o mesmo.
- A trava de perfil vale no chat. A ferramenta roda como o usuário logado. Quem é do comercial não consegue pedir ao chat o caixa da diretoria, porque o banco recusa.
- A resposta mostra de onde veio. Cada resposta traz a fonte (qual métrica, qual relatório, quais filtros) e um link para a tela já filtrada.
Para perguntas analíticas ("por que o caixa mudou este mês?", "o que fazer com a renovação?"), o chat responde em quatro blocos fixos:
Para o "por quê", o chat recebe um conjunto de heurísticas do setor, escritas como experiência de mercado e marcadas como hipóteses a checar nos dados. Um exemplo é a régua de renovação que muitas corretoras usam: cotar 60 dias antes do vencimento, apresentar com 30, fechar com 15 e resgatar no dia seguinte ao vencimento. O chat usa a régua para dizer o que é urgente, mas o número que sustenta a resposta vem sempre de uma ferramenta.
Por que Gemini 3.7 Flash
O modelo foi escolhido num teste lado a lado, com as mesmas perguntas analíticas feitas a três modelos do Gemini. O critério tinha três pontos: responder só com o dado que as ferramentas devolvem, explicar a causa como um analista e fazer isso em poucos segundos. O Gemini 3.7 Flash entregou a análise no nível de analista em cerca de 9 segundos, aproximadamente 3 vezes mais rápido e 7 vezes mais barato por pergunta que o Gemini 3.5 Flash.
O provedor não ficou preso no código. Uma tela de configuração define o modelo de cada trabalho (chat, diagnóstico, parecer do mês), com opções do Gemini e do Claude. As chaves de API ficam só no servidor, nunca no banco nem na tela.
O resultado
A corretora passou a ter o dinheiro mostrado pelo que de fato entrou no caixa, com alerta de renovação antes do vencimento e um painel para cada área. Quem tem dúvida que a tela não responde pergunta ao chat, dentro do próprio painel, e recebe o número com a fonte e o link para a tela filtrada.
Boas práticas que aplicamos em BI com IA para corretora
1. Três contas de dinheiro, com três nomes. Em corretora, há a receita faturada (o que vira nota e entra no caixa), a comissão registrada por apólice (o que a seguradora diz que pagou por parcela) e a comissão contratada (o que foi vendido e ainda vai entrar). A segunda fica sempre abaixo do caixa. Se alguém pergunta "quanto entrou?", a resposta sai da primeira. Isso virou regra explícita do chat, e o painel mostra as três com nomes diferentes.
2. Renovação ligada à apólice de origem por cliente, ramo e vigência. No ERP, a apólice renovada nasce com número novo. Para medir retenção de verdade, o sistema liga cada renovação à apólice anterior pelo cliente, pelo ramo e pela janela de vigência, com 77,8% de acerto e sem precisar cruzar CPF. A tela deixa claro que essa sucessão é inferida.
3. O que precisa ser garantido fica no código, não no prompt. O usuário escreve o nome curto da seguradora e a base guarda o nome completo: o sistema casa os dois no código, antes de chamar a função, em vez de confiar que o modelo acerte o nome. O mesmo vale para ações: toda escrita pedida pela IA vira uma proposta na tela, e só o clique de uma pessoa grava.
4. Cada perfil recebe só as ferramentas dele. O chat da renovação conhece as 6 ferramentas da renovação, não o catálogo inteiro. Cada passo da conversa fica mais leve e mais rápido. E antes de cada consulta o chat escreve uma frase curta ("vou checar os vencimentos"), então o usuário vê a resposta começar em 1 ou 2 segundos.
5. O chat confere a data do dado antes de responder. Cada fonte do ERP atualiza num ritmo diferente. Antes de responder, o chat lê a data de cada fonte e avisa quando o dado é de um dia anterior, para que ausência de dado nunca apareça como zero.
O painel mostra o que vence; a conversa com o cliente é outra etapa. O case de SDR de IA para renovação de seguro de vida no WhatsApp detalha como o contato chega ao pedido de cotação e à passagem para o corretor.
Como a Nexus usa IA nesse tipo de projeto
Para nós, IA em dado de gestão começa pela pergunta de cada área, não pelo gráfico. Primeiro levantamos o que diretoria, comercial, financeiro e renovação perguntam toda semana. Depois montamos um painel por perfil, com a trava no banco, e só então colocamos a IA em cima, usando as mesmas funções das telas. O modelo entende a pergunta e explica; quem garante o número é a função validada.
É a mesma lógica do agente de IA no ERP Sankhya com o Claude, com uma diferença de formato: lá a diretoria pergunta direto no Claude, conectado ao ERP; aqui o BI com painéis por perfil é o centro e o chat mora dentro dele. Para corretoras, reunimos as soluções em IA para corretoras de seguros, e o desenho de dados está em copiloto de dados com IA.
Perguntas frequentes
Dá para fazer um BI de corretora de seguros com os dados do SACWEB? Sim. O SACWEB libera relatórios do tipo Power BI pela API. Eles são puxados em horários definidos, guardados num banco próprio e viram painéis por perfil, sem mudar a rotina de quem lança os dados no ERP.
O chat de IA pode dar um número diferente do painel? Neste projeto, não. O chat não escreve consulta ao banco: ele chama as mesmas funções que alimentam as telas. Se a pergunta não cabe em nenhuma delas, ele responde que não tem esse dado no painel.
Cada pessoa da corretora vê tudo? Não. São 4 perfis: diretoria, comercial, financeiro e cobrança, e renovação. Cada perfil vê o seu painel e o chat só tem acesso às ferramentas daquele perfil. A diretoria vê tudo.
Qual IA responde as perguntas? O chat roda com o Gemini 3.7 Flash, do Google, escolhido num teste lado a lado. O provedor é trocável numa tela de configuração, entre modelos do Gemini e do Claude, sem mexer no código.
A IA pode alterar dados ou criar tarefas sozinha? Não. Quando a IA sugere uma ação, a tela mostra a proposta e só um clique de uma pessoa grava. Toda escrita pedida pela IA passa por um humano.
