Por que não posso simplesmente pedir para a IA somar a coluna?

Porque o modelo prevê texto, ele não executa aritmética confiável. O resultado não é determinístico, não é auditável e degrada conforme a planilha cresce, além de estourar a janela de contexto. Some com SQL ou pandas e deixe o modelo só descrever o número.

E se a planilha estiver bagunçada?

Essa é a regra, não a exceção. Célula mesclada, número armazenado como texto, data em formato brasileiro e linha de total no meio dos dados são o padrão. A camada de validação de esquema existe justamente para barrar o arquivo problemático antes do cálculo.

Precisa de revisão humana antes de enviar o relatório?

Sempre que o relatório embasar uma decisão. A revisão não é do texto apenas, é da conferência de totais e da explicação de qualquer variação fora da faixa esperada. Relatório automático que ninguém confere vira decisão errada com aparência de rigor.

IA que lê planilha e gera relatório: como montar

O princípio que organiza todo esse tipo de projeto cabe em uma frase: o LLM não deve calcular, ele deve escrever a consulta e narrar o resultado. Toda arquitetura que ignora isso funciona na demonstração com trinta linhas e quebra em produção com trinta mil. O pipeline correto tem quatro camadas antes do modelo aparecer: ingestão, validação de esquema, carga em banco ou dataframe e cálculo determinístico. Só depois disso o modelo entra, e o que ele recebe já são números fechados.

Por que pedir a soma direto ao modelo é o caminho errado

Quatro problemas concretos, e nenhum deles se resolve com prompt melhor:

Não é determinístico. A mesma planilha pode gerar totais diferentes em execuções diferentes. Em relatório financeiro isso é inaceitável.
Não é auditável. Quando o número sai errado, você não tem uma linha de código para inspecionar. Não dá para explicar ao contador que o modelo achou aquilo.
Quebra em escala. Trinta mil linhas não cabem na janela de contexto, e mesmo o que cabe consome muito token e degrada a atenção do modelo ao longo do texto.
Erra de forma silenciosa. O modelo produz um número plausível. Ninguém desconfia de R$ 847.320,00, e é exatamente por isso que o erro passa.

A regra prática: se o número aparece no relatório, ele foi calculado por código que você consegue ler e rodar de novo.

Ingestão e validação de esquema

A planilha bagunçada é a regra. Trate a validação como uma etapa de primeira classe, com relatório próprio de erros:

Colunas esperadas presentes, com nome normalizado, porque "Valor Total", "valor_total" e "VL TOTAL" chegam no mesmo mês
Tipo por coluna, com número armazenado como texto sendo um dos casos mais frequentes, junto com separador de milhar em ponto e decimal em vírgula
Data em formato brasileiro, com 03/04/2026 podendo ser março ou abril dependendo de quem exportou
Linhas em branco e linha de total no meio dos dados, que somam duas vezes se não forem removidas
Célula mesclada, que vira valor nulo nas linhas seguintes
Cabeçalho fora da primeira linha, comum em export de ERP com logo e período no topo
Registro duplicado, com regra explícita de qual manter

Se a validação falhar, o pipeline para e avisa quem enviou o arquivo. Ele não deve seguir tentando adivinhar. Automação que adivinha produz relatório errado no silêncio, que é o pior modo de falha possível.

Carga e cálculo determinístico

Dado validado vai para um lugar onde SQL funcione. Para volume pequeno e médio, DuckDB resolve muito bem lendo CSV e Parquet direto, sem servidor. Para dado recorrente com histórico, Postgres. Para transformação em memória, pandas ou polars.

O cálculo fica em código versionado no repositório, com três exigências:

Cada métrica definida uma única vez, reaproveitada em todos os relatórios
Teste automatizado com um conjunto de dados de referência e resultado conhecido
Registro da versão que gerou cada relatório, para quando alguém perguntar por que o número de março mudou

O modelo pode ajudar a escrever essa consulta, e ajuda bem. Mas a consulta é revisada por uma pessoa, entra no repositório e passa a ser executada como código, não regerada a cada rodada.

Onde o LLM entra de verdade

Depois de tudo calculado, o modelo recebe um bloco pequeno e estruturado, algo como faturamento do mês, comparação com o mês anterior, cinco maiores clientes, itens com variação acima do limite. E produz:

Narrativa do resultado, em linguagem de negócio
Destaque do que mudou em relação ao período anterior
Hipóteses de causa, claramente marcadas como hipóteses
Adaptação de tom por destinatário, com versão para diretoria e versão para operação

É um bom uso porque a tarefa é linguística, não aritmética. E é onde ele realmente economiza tempo de quem hoje escreve o texto do relatório à mão.

Checagens que precisam existir

Totais que precisam bater. Soma das partes igual ao total. Faturamento por produto igual ao faturamento consolidado. Se não bate, o relatório não sai.
Comparação com o período anterior, com alerta quando a variação passa de uma faixa definida por métrica.
Contagem de linhas processadas, comparada com a contagem do arquivo de origem.
Cobertura, ou seja, quantos registros ficaram sem categoria, sem cliente ou sem data.
Reprocessamento idempotente, para que rodar duas vezes não duplique nada.

O alerta de variação fora da faixa é o que mais pega erro real. Uma queda de 40% no faturamento de uma filial pode ser fato ou pode ser um arquivo que veio incompleto. Nos dois casos alguém precisa olhar antes de o relatório circular.

Quem responde pelo quê

Etapa	Ferramenta	Quem responde pelo resultado
Ingestão do arquivo	Script agendado, integração com ERP	Quem envia o dado de origem
Validação de esquema	Pydantic, Great Expectations, código próprio	Time de dados ou desenvolvimento
Carga	DuckDB, Postgres, pandas	Time de dados
Cálculo	SQL ou pandas versionado, com teste	Dono da métrica na área de negócio
Checagem de consistência	Testes automatizados e alertas	Time de dados
Texto do relatório	LLM a partir dos números fechados	Quem revisa antes de circular
Entrega	E-mail, PDF, WhatsApp, Slack, dashboard	Responsável pelo processo

Repare que o LLM aparece uma vez só, e não é onde está o número.

Entrega e revisão humana

Formato importa mais do que parece. PDF para relatório formal e arquivo, e-mail para o resumo com três números e link para o detalhe, mensagem no WhatsApp ou Slack para alerta por exceção, dashboard para quem quer investigar. Alerta por exceção é o formato mais subestimado, porque ninguém lê o relatório de vinte páginas e todo mundo lê a mensagem que diz que um cliente grande parou de comprar.

Sobre revisão: relatório que vira decisão passa por gente antes de circular. Não é desconfiança do sistema, é o mesmo motivo pelo qual balancete tem conferência. O revisor olha três coisas: os totais bateram, as variações fora da faixa têm explicação, e o texto não afirma causa onde só existe correlação. Leva dez minutos e evita a reunião em que a diretoria decide com base em um número que veio de uma planilha cortada pela metade.

Um roteiro realista de implantação

Escolha um relatório só, o que consome mais tempo hoje.
Documente as regras de cálculo atuais, entrevistando quem monta. Aqui aparecem exceções que ninguém tinha escrito.
Monte a validação de esquema com três meses de arquivos reais, incluindo os problemáticos.
Implemente o cálculo com teste e rode em paralelo com o processo manual por pelo menos um ciclo.
Explique cada divergência. Às vezes quem está errado é a planilha antiga, e descobrir isso é parte do valor.
Só então adicione a narrativa gerada e a entrega automatizada.

Como ordem de grandeza de mercado, um relatório de complexidade média leva de três a oito semanas nesse formato, e a parte lenta quase nunca é o código. É descobrir qual é a regra de verdade. A Retti Tech trata a etapa 2 como a mais importante do projeto justamente por isso: automatizar um cálculo que ninguém sabe explicar apenas transforma um problema lento em um problema rápido.