Machine Learning em Finanças

Machine learning virou uma daquelas expressões que aparecem em quase toda apresentação de tecnologia, e costuma vir acompanhada de promessas grandes: prever o futuro, eliminar erros, substituir analistas. Em finanças, a realidade é mais modesta e, por isso, mais útil. O aprendizado de máquina identifica padrões em dados históricos e produz estimativas ou alertas. Quando bem aplicado, ele reduz o tempo entre um fato financeiro acontecer e alguém decidir o que fazer com ele.

A maior parte do valor de um projeto de machine learning em finanças não vem de algoritmos sofisticados. Vem de dados organizados, de objetivos bem definidos e de um processo de revisão humana que valida o que o modelo sugere. Sem essas três coisas, um modelo produz números com aparência de precisão e pouca utilidade prática. Com elas, ele vira uma ferramenta de apoio que a equipe consegue confiar e questionar.

Este guia explica onde o aprendizado de máquina ajuda de verdade, quais dados são necessários, como avaliar se um modelo merece confiança, quais riscos exigem atenção, como implantar um projeto por etapas e quais erros costumam transformar um bom projeto em um fracasso caro. Os exemplos são ilustrativos e servem para mostrar a lógica, não para garantir resultados.

O que é machine learning, sem jargão

Em termos simples, machine learning é um conjunto de métodos em que um computador aprende uma relação entre entradas e saídas a partir de exemplos, em vez de seguir regras escritas à mão. Se você mostrar milhares de pedidos com o resultado de cada um, o sistema pode aprender quais características costumam anteceder um atraso de pagamento, por exemplo.

Isso é diferente de uma planilha com fórmulas, em que a regra é explícita, e também diferente de um painel de indicadores, que apenas mostra o que aconteceu. O aprendizado de máquina tenta generalizar: prever algo que ainda não aconteceu, ou sinalizar algo fora do padrão. Essa capacidade de generalização é o que traz valor, mas também o que exige cuidado, porque um modelo pode aprender padrões que não se sustentam.

Onde o aprendizado de máquina ajuda de verdade

Nem toda tarefa financeira se beneficia de ML. As aplicações mais úteis costumam ter três características: muito volume de dados, padrões repetitivos e uma decisão que depende de responder rápido. Algumas delas aparecem com frequência em empresas que vendem online:

• Previsão de recebimentos e de caixa: estimar quando e quanto entra, a partir do histórico de vendas, dos meios de pagamento e dos prazos de cada canal.
• Detecção de anomalias: sinalizar uma despesa fora do padrão da categoria, uma queda incomum de margem ou um atraso de cobrança fora do perfil do cliente.
• Classificação de despesas e conciliação: sugerir categorias para lançamentos com base em descrição e histórico, deixando para a equipe apenas as exceções.
• Priorização de cobrança: ordenar a fila de inadimplentes pela chance de recuperação, para que a equipe ataque primeiro o que tem mais retorno.
• Análise de risco de fornecedores e clientes: identificar sinais de deterioração antes de um atraso grave.

Em todas essas aplicações, o modelo não decide sozinho. Ele ordena, sugere ou sinaliza, e uma pessoa valida. Essa divisão de papéis é o que mantém o projeto útil e auditável.

Previsão de caixa: cenário, não garantia

A previsão de recebimentos é uma das aplicações mais buscadas. Um modelo pode usar histórico de vendas, sazonalidade, prazos de recebimento e recorrência de clientes para estimar cenários. O resultado deve ser uma faixa, com um valor central e um intervalo, acompanhada da data de atualização e das premissas usadas.

O uso correto dessa previsão é para decisões de planejamento: quanto de estoque comprar, quanto reservar de caixa, qual ritmo de investimento em mídia é sustentável. Tratá-la como garantia leva a compromissos que o caixa não aguenta quando a realidade se afasta do cenário. Uma previsão honesta mostra quando a incerteza é grande, por exemplo em períodos de promoção ou de mudança de preço.

Detecção de anomalias: o alerta que precisa ser explicado

Um alerta compara o comportamento atual com um padrão esperado e avisa quando há um desvio relevante. Pode ser uma despesa que foge do histórico da categoria, uma queda incomum na margem de um produto ou um cliente que atrasa o pagamento fora do seu perfil habitual.

Para que um alerta seja útil, ele precisa mostrar o que mudou, em qual período e qual dado originou o sinal. Um alerta que diz apenas "anomalia detectada" gera ansiedade e pouca ação. Um alerta que diz "a categoria de frete subiu 38% em março, concentrada em três pedidos de uma transportadora" permite investigar e decidir. Essa explicabilidade é uma exigência prática, não um detalhe técnico.

Também é importante calibrar o limite do alerta. Um limite muito baixo dispara alarmes todo dia e a equipe passa a ignorá-los. Um limite muito alto deixa passar problemas reais. O ajuste deve ser feito com o histórico de alertas úteis e inúteis, revisado periodicamente.

Classificação e conciliação: economizar tempo sem esconder a trilha

Lançamentos bancários e de cartões costumam ter descrições confusas, e a classificação manual consome muitas horas. Um modelo pode sugerir categorias com base na descrição e no histórico, e a equipe valida apenas os casos ambíguos. Esse ganho é real e costuma ser um dos primeiros que as empresas percebem.

O cuidado está na trilha de auditoria. Toda classificação sugerida precisa ser registrada com a origem, a confiança e a validação humana, para que o contador possa explicar qualquer lançamento depois. Sem essa trilha, o ganho de tempo vira um risco de conformidade.

Qualidade dos dados: a base que decide tudo

Nenhum modelo supera dados ruins. Em finanças, a qualidade costuma falhar em pontos conhecidos: datas em formatos diferentes, valores com e sem imposto, cancelamentos que não aparecem no histórico, categorias criadas e abandonadas ao longo do tempo, e lacunas que foram preenchidas com a média sem registro. Cada um desses problemas cria padrões falsos que o modelo aprende como se fossem reais.

Antes de qualquer modelo, a recomendação é auditar a base: conferir a completude, a consistência de datas e valores, a estabilidade das categorias e a relação entre os sistemas. Essa auditoria parece trabalhosa, mas é a etapa que mais protege o projeto contra resultados aparentemente bons e errados.

Como avaliar se um modelo merece confiança

Um modelo deve ser avaliado com dados que não usou no treino. Dividir o histórico em um período de aprendizado e um período de teste é a forma mais simples de medir se ele generaliza. Depois, compare o desempenho com uma linha de base simples, como a média móvel ou a regra de negócio atual. Se o modelo complexo não supera a regra simples de forma consistente, a complexidade não se justifica.

Também é preciso olhar o tipo de erro. Em um alerta de fraude, deixar passar um caso real pode custar muito mais do que gerar um falso positivo. Em uma priorização de cobrança, ordenar mal a fila custa dinheiro de forma gradual. Cada aplicação tem um custo diferente para cada tipo de erro, e isso deve orientar a escolha do limite e da métrica.

Riscos que exigem atenção

Há riscos específicos quando o aprendizado de máquina é aplicado a finanças. O primeiro é o viés: um modelo treinado com decisões passadas pode reproduzir critérios injustos de crédito ou de cobrança que a empresa não quer manter. O segundo é a dependência: uma equipe que confia cegamente no modelo perde a capacidade de questionar os números. O terceiro é a privacidade, porque dados de clientes exigem tratamento conforme a LGPD, com finalidade definida e acesso restrito.

Há também o risco de mudança de cenário. Um modelo aprende o comportamento do passado. Quando a empresa muda de preço, de canal ou de público, o modelo pode continuar projetando o que não existe mais. Por isso, o monitoramento contínuo é obrigatório, e não opcional.

Como implantar por etapas

Um projeto bem conduzido começa pequeno. Escolha um problema específico, com dados disponíveis e uma decisão clara que depende dele. Por exemplo, priorizar a cobrança dos cinco maiores atrasos da semana, ou classificar as despesas de uma única conta bancária. Defina a métrica de sucesso antes de começar e a linha de base que o modelo precisa superar.

Depois, valide com um período de teste e com a equipe que vai usar a ferramenta. Só então amplie para outros problemas. Essa progressão reduz o risco de um projeto grande parar no meio, sem resultado, e cria aprendizado para os próximos passos.

Erros que transformam um bom projeto em fracasso

• Começar pelo algoritmo: escolher a técnica antes de definir o problema e a decisão que ela vai apoiar.
• Ignorar a qualidade dos dados: construir sobre uma base não auditada, que repete e amplia erros.
• Medir só com dados de treino: o modelo parece excelente e falha no primeiro uso real.
• Não ter linha de base: sem comparação com uma regra simples, não há como saber se o modelo agrega valor.
• Automatizar decisões sem revisão: transferir ao modelo uma decisão que exige julgamento humano, sobretudo em crédito e cobrança.
• Não monitorar: o modelo envelhece e continua sendo usado como se estivesse atualizado.

Modelos explicáveis e a caixa-preta

Existe uma tensão conhecida entre desempenho e explicabilidade. Modelos mais complexos, como redes neurais profundas, podem captar padrões sutis, mas são difíceis de interpretar. Modelos mais simples, como árvores de decisão ou regressões, são menos sofisticados, porém permitem entender por que uma previsão foi feita. Em finanças, essa escolha pesa mais do que em muitas outras áreas, porque decisões de crédito, cobrança e alocação de capital precisam ser justificáveis.

A recomendação prática é começar com o modelo mais simples que resolve o problema e só migrar para algo mais complexo quando houver ganho real e mensurável. Mesmo com modelos complexos, é possível usar técnicas de explicação que mostram quais variáveis mais influenciaram cada resultado. Essa informação não é apenas técnica: ela permite que o gestor questione o sinal e que o contador explique o lançamento.

Um critério útil é perguntar se a equipe conseguiria explicar a decisão a um auditor ou a um cliente sem citar o modelo. Se a resposta for não, o risco de uso indevido é alto, e a decisão deve voltar para uma pessoa.

Dados sensíveis: cartão, Pix e identificação de clientes

Projetos de machine learning em finanças costumam tocar em dados sensíveis, como informações de pagamento, histórico de compras e dados cadastrais. Mesmo quando a empresa não armazena números de cartão, a combinação de dados transacionais pode identificar pessoas. Por isso, a regra básica é usar o mínimo necessário para o problema e, sempre que possível, trabalhar com dados pseudonimizados.

A LGPD exige finalidade definida, base legal adequada e transparência com o titular. Na prática, isso significa documentar para que os dados serão usados, quem tem acesso, por quanto tempo serão guardados e como o titular pode exercer seus direitos. Esses pontos devem estar definidos antes do primeiro teste, não depois.

Vale também cuidado com dados de terceiros usados em modelos, como informações de bureaus de crédito. O uso deve estar previsto em contrato e ser compatível com a finalidade declarada.

Quanto custa um projeto de machine learning

O custo de um projeto depende menos da tecnologia e mais das pessoas, do tempo de preparação dos dados e da integração com os sistemas existentes. Uma implantação pequena, com ferramentas prontas e um problema bem delimitado, pode ser feita em semanas, com custo baixo. Um projeto que exige integração com vários sistemas, modelos próprios e monitoramento contínuo leva meses e demanda uma equipe dedicada.

Uma armadilha comum é orçar apenas a parte visível, o modelo, e esquecer a manutenção. Modelos envelhecem e precisam ser recalibrados. Alertas precisam ser ajustados. Novas fontes de dados exigem integração. Esses custos recorrentes costumam superar o investimento inicial, e devem entrar no cálculo de retorno desde o início.

Exemplo ilustrativo: alerta de margem por campanha

Para mostrar como um projeto pequeno pode gerar valor, imagine uma loja que quer ser avisada quando a margem de uma campanha cair abaixo do aceitável. Hoje, a equipe revisa os números uma vez por semana, e frequentemente descobre a queda tarde demais.

O projeto começou com um modelo simples: uma média móvel da margem por campanha, com um intervalo de variação esperado. Quando a margem diária sai desse intervalo por dois dias seguidos, o sistema envia um alerta com a campanha, o produto envolvido e a variação do custo de mercadoria ou do frete no período. A equipe passou a receber o alerta na mesma semana em que a queda acontece.

Nas primeiras semanas, houve muitos falsos alertas, causados por promoções previstas. A correção foi incluir o calendário de promoções como exceção, reduzindo o ruído. O exemplo é hipotético, mas ilustra o ciclo típico: começar simples, medir a qualidade dos alertas e ajustar as regras com base no que a equipe realmente usa.

Tempo de resposta como indicador

Um indicador útil para avaliar projetos de ML é o tempo entre o fato financeiro e a ação tomada. Se uma queda de margem era percebida em uma semana e passa a ser percebida em um dia, o projeto gerou valor concreto, mesmo que o modelo seja simples. Esse indicador é mais fácil de defender para a diretoria do que métricas técnicas, porque se traduz em decisões tomadas antes.

Outro indicador é a proporção de alertas que levam a uma ação. Se a maioria dos alertas é ignorada, o problema não é de tecnologia, e sim de calibração ou de utilidade. Acompanhar essa proporção mostra onde ajustar o projeto.

Previsão de demanda para compras de estoque

Além do caixa, a previsão de demanda é uma aplicação importante para empresas de varejo. Ela estima quanto de cada produto será vendido nas próximas semanas, o que orienta compras e reposição. Um modelo bem feito pode considerar sazonalidade, promoções, preço, tendência e até o efeito de datas comemorativas. O benefício financeiro vem de comprar a quantidade certa: menos ruptura, que faz vendas se perderem, e menos excesso, que prende capital e aumenta o risco de perda.

A previsão de demanda também exige cuidado com a granularidade. Prever o total da loja costuma ser mais preciso, mas não ajuda a comprar um produto específico. Prever cada produto isoladamente oferece o detalhe necessário, mas com séries mais ruidosas. Uma prática comum é agrupar produtos parecidos para ganhar estabilidade e depois desagregar a previsão conforme o necessário.

Como em qualquer modelo, a previsão precisa de uma linha de base. A média das vendas das últimas semanas, ajustada pela sazonalidade do ano anterior, costuma ser um ponto de comparação forte. Se o modelo não supera essa referência de forma consistente, a compra deve continuar baseada na regra simples até que os dados justifiquem a mudança.

Priorização de cobrança: um exemplo ilustrativo

Uma das aplicações mais diretas de ML em finanças é ordenar a fila de cobrança. Equipes pequenas têm poucas horas para cobrar, e a ordem em que os atrasos são tratados muda o resultado. Um modelo pode estimar, para cada atraso, a probabilidade de recebimento em um prazo, com base no histórico do cliente, no valor e no tempo de atraso.

Um exemplo ilustrativo: uma empresa tem 300 títulos em atraso e capacidade para cobrar cerca de 40 por dia. Sem priorização, a equipe cobra por ordem de vencimento. Com um modelo que ordena pela probabilidade de recuperação multiplicada pelo valor, os primeiros contatos passam a ser os de maior retorno esperado. Depois de um mês, a equipe percebeu que recuperou um valor parecido com o do método anterior, mas com menos horas de trabalho. O ganho veio da ordem, não de um aumento de esforço.

Esse tipo de aplicação exige cuidado com o viés. Se o modelo aprende que clientes antigos pagam melhor, ele pode deixar sem cobrança clientes novos que apenas tiveram um atraso pontual. A revisão humana das decisões, principalmente em clientes importantes, evita que a eficiência vire injustiça.

Probabilidade não é certeza: erros de leitura

Um modelo costuma entregar probabilidades, como "70% de chance de atraso". Esse número é útil, mas é frequentemente mal interpretado. Uma probabilidade de 70% significa que, em casos parecidos, cerca de sete em cada dez atrasaram. Não significa que este cliente certamente atrasará, nem que o modelo sabe disso.

Outro equívoco é tratar a probabilidade como se fosse uma decisão. Um cliente com 30% de chance de atraso não deve ser automaticamente aprovado ou recusado. A decisão depende do valor em jogo, do custo de cada tipo de erro e da política da empresa. A probabilidade alimenta a decisão, mas não a substitui.

Manutenção: o modelo precisa ser recalibrado

Modelos aprendem o passado e se degradam quando o contexto muda. Uma mudança de preço, a entrada de um novo canal, uma crise econômica ou uma alteração nas regras de pagamento podem tornar o histórico menos representativo. Por isso, o desempenho deve ser monitorado com regularidade, comparando previsões e resultados reais.

Quando o desempenho cai abaixo de um limite definido, o modelo deve ser recalibrado ou substituído. Essa decisão precisa de um critério escrito, para evitar tanto a manutenção negligente, que deixa um modelo ruim em uso, quanto a troca constante, que impede aprender com a série. Uma revisão trimestral, com indicadores fixos, costuma ser suficiente para a maioria das aplicações financeiras.

Cultura de dados: o ativo que sobrevive às ferramentas

Ferramentas mudam, fornecedores são substituídos e modelos envelhecem. O que permanece, quando a empresa acerta, é a cultura de tomar decisões com dados. Essa cultura se constrói com hábitos simples: registrar premissas antes de uma decisão, comparar o resultado com o que foi previsto, admitir quando uma estimativa errou e ajustar o processo. Um projeto de machine learning pode acelerar essa cultura, mas não a cria sozinho.

Na prática, a empresa ganha quando cada previsão ou alerta vira uma conversa sobre o que aconteceu e o que mudar. Se a equipe passa a perguntar "por que o modelo errou?" e não apenas "o modelo está certo?", o aprendizado se acumula. Esse é o verdadeiro ativo de longo prazo, mais valioso do que qualquer modelo específico.

Para quem está começando, a melhor aposta é organizar bem os dados que já existem, definir alguns indicadores com dono e revisar o desempenho com regularidade. Quando esses fundamentos estiverem firmes, a inteligência artificial deixa de ser uma promessa distante e passa a ser uma extensão natural do trabalho financeiro.

Vale também registrar, para cada aplicação, quem é o responsável por olhar os resultados e em que data a próxima revisão acontece. Projetos desse tipo costumam perder força não por falha técnica, mas porque ninguém voltou a conferir o que foi implantado. Um calendário simples de revisão, com responsável nomeado, evita que o modelo se torne um item esquecido no sistema e garante que a empresa continue aprendendo com o que construiu.

Por fim, convém lembrar que nenhuma ferramenta substitui a leitura cuidadosa de quem conhece o negócio. Um alerta que aponta uma queda de margem precisa de alguém que entenda se a causa é um reajuste de fornecedor, uma promoção esquecida ou um erro de lançamento. A tecnologia aponta onde olhar. O julgamento sobre o que fazer continua sendo humano, e é isso que mantém o projeto útil e responsável ao longo do tempo.

Governança: quem aprova um modelo antes de usar

Um modelo de machine learning não deveria entrar em produção por decisão individual de quem o construiu. Ele precisa de um processo de aprovação que envolva as áreas afetadas, normalmente financeiro, jurídico e operação, além de quem o desenvolveu. A aprovação deve registrar o problema que o modelo resolve, os dados usados, a métrica de avaliação, a linha de base superada e as limitações conhecidas.

Esse registro também vira referência quando o modelo começar a errar. Sem ele, a equipe não sabe o que foi testado, quais premissas foram assumidas e quem é responsável por decidir sobre uma mudança. A governança não precisa ser burocrática: uma página bem preenchida, com revisão trimestral, já cumpre o papel.

Vale definir também quem pode desligar um modelo. Se um alerta começa a gerar decisões erradas, a pessoa responsável precisa ter autonomia para suspendê-lo, sem depender de uma longa cadeia de aprovação.

Integração com o fechamento contábil

Para que um modelo financeiro seja confiável, ele precisa conversar com o fechamento contábil. Previsões e alertas que usam dados diferentes dos registrados na contabilidade geram duas versões da realidade, e a equipe perde tempo tentando conciliá-las. Por isso, a fonte de dados do modelo deve ser a mesma usada no fechamento, ou pelo menos ter uma conciliação documentada.

Quando há ajustes contábeis no fim do mês, como provisões e estornos, o modelo deve ser alimentado com a versão final desses lançamentos, e não com a versão preliminar. Caso contrário, os alertas dos primeiros dias do mês podem parecer anomalias que, na verdade, são apenas dados incompletos.

Modelo ou regra: como testar a diferença

Uma das perguntas mais úteis antes de adotar um modelo é se uma regra simples resolveria o problema quase tão bem. Uma regra como "alertar quando a despesa for 30% maior que a média da categoria nos últimos três meses" é transparente, barata de manter e fácil de explicar. Se um modelo complexo melhora pouco em relação a ela, a complexidade adicional tem custo que não se justifica.

Para testar, rode a regra e o modelo sobre o mesmo período de teste e compare os alertas gerados com o que de fato foi relevante. Conte os acertos, os falsos positivos e os casos perdidos. A diferença entre as duas abordagens, medida dessa forma, é a informação que a decisão precisa.

Como conversar com a equipe sobre IA

Projetos de IA costumam gerar receio em equipes financeiras, seja pelo medo de substituição, seja pela desconfiança em números que ninguém entende. Uma conversa honesta ajuda. O modelo deve ser apresentado como um assistente que reduz tarefas repetitivas, e não como um substituto de julgamento. Mostrar exemplos concretos de alertas úteis e de erros que foram corrigidos costuma convencer mais do que qualquer apresentação técnica.

Também é importante envolver a equipe na definição do que é um alerta útil. Quem faz a conciliação sabe quais exceções aparecem com frequência. Quem acompanha o caixa sabe que tipo de variação importa. Essas pessoas são as melhores fontes para calibrar o projeto, e a participação delas aumenta a chance de adoção.

Checklist antes de colocar um modelo em uso

Antes de qualquer modelo sair do teste, um checklist curto protege a decisão:

• O problema e a decisão que o modelo apoia estão descritos por escrito.
• A base foi auditada quanto a completude, consistência e estabilidade das categorias.
• Há uma linha de base simples e o modelo a supera de forma consistente no período de teste.
• O tipo de erro mais caro foi identificado e o limite foi calibrado para ele.
• Existe uma trilha de auditoria para cada sugestão ou alerta.
• O tratamento de dados pessoais segue a LGPD, com finalidade e acesso documentados.
• Há um responsável pelo monitoramento e pela decisão de suspender o modelo.
• A equipe que vai usar a ferramenta participou da definição e foi treinada.

Esse checklist não garante sucesso, mas evita os problemas mais comuns. Projetos que passam por ele tendem a ser menores, mais úteis e mais fáceis de defender quando surgem perguntas.

Onde a Fortunato Soluções pode ajudar

Para empresas que querem reunir dados de vendas, custos e caixa antes de qualquer modelo, a base costuma ser o primeiro trabalho. A Fortunato Soluções atua na montagem de painéis e na organização dessas fontes, o que cria o terreno para projetos de previsão e alerta depois.

Perguntas frequentes sobre machine learning em finanças

Preciso de um cientista de dados para começar? Não necessariamente. Muitas aplicações começam com ferramentas prontas e com regras simples. Quando o problema pede modelos próprios, uma consultoria especializada pode ajudar.

Machine learning substitui o contador ou o financeiro? Não. Ele reduz tarefas repetitivas e sinaliza exceções. A análise, a decisão e a responsabilidade continuam com pessoas.

Quanto dado é necessário? Depende do problema, mas quanto mais estável e completo o histórico, melhor. Séries curtas e com muitas mudanças tendem a produzir modelos pouco confiáveis.

Como saber se o projeto deu certo? Pela melhora de uma métrica de negócio, comparada com a linha de base, e pela utilidade percebida pela equipe. Um modelo tecnicamente bom que ninguém usa não entrega valor.

Conclusão: machine learning é ferramenta de decisão, não substituto dela

Machine learning pode reduzir o tempo entre o fato financeiro e a decisão, organizar grandes volumes de dados e sinalizar o que merece atenção. Mas seu valor depende de dados confiáveis, de objetivos claros, de avaliação honesta e de revisão humana permanente.

O caminho recomendado é começar por um problema específico, auditar a base, comparar com uma linha de base simples e só então ampliar. Com essa disciplina, o aprendizado de máquina deixa de ser uma promessa e passa a ser uma ferramenta que a equipe usa com confiança.