Machine learning na cobrança: o que dá para prever e o que não dá

Toda operação de cobrança já ouviu que precisa de inteligência artificial. Quase nenhuma ouviu quais são as duas ou três coisas que um modelo realmente consegue estimar, quais ele não consegue, e o que precisa existir na carteira antes de treinar qualquer coisa.

O que um modelo consegue estimar numa carteira de cobrança

Na prática, o que dá para modelar bem em recuperação de crédito é curto e específico. Duas probabilidades:

Probabilidade de cura — a chance de o contrato voltar à normalidade dentro de uma janela de tempo definida.
Propensão a pagar — a chance de haver pagamento dentro dessa janela.

É isso. Note o que essas duas frases têm em comum: são probabilidades, sobre uma janela, válidas para uma população. Um score 82 não significa que aquele devedor vai pagar. Significa que, entre os contratos parecidos com aquele, historicamente cerca de 82 em cada 100 pagaram dentro da janela. E significa isso apenas se o modelo estiver calibrado — se não estiver, o número 82 não quer dizer coisa nenhuma além de “está mais para cima na fila do que o 40”.

Tudo o que a operação vê depois — persona, canal sugerido, melhor horário, desconto máximo, ordem de execução por valor esperado — não é saída de modelo. É regra aplicada sobre essas duas probabilidades — e é essa separação que deixa o motor auditável.

O que não dá para prever, e é honesto dizer

O que costumam prometer	Por que não se sustenta
“A IA sabe quem vai pagar”	Ninguém sabe. O modelo estima frequência numa população, não destino individual.
“O modelo antecipa o desemprego do devedor”	Choque de renda, doença, separação e perda de emprego não estão no histórico da carteira. São exatamente os eventos que quebram a previsão.
“O modelo diz o quanto ligar aumenta a recuperação”	Isso é pergunta contrafactual. Dado observacional não responde: só um teste com grupo de controle mede o efeito de uma ação.
“O modelo descobre oportunidade em segmento nunca trabalhado”	Se a operação nunca acionou aquele segmento, não há desfecho para aprender. O modelo tende a repetir a política antiga, inclusive os vieses dela.
“O modelo prevê a data do pagamento”	Data exata é ruído. Janela é previsível; dia não é.

Um modelo também não sobrevive a mudança de regra sem aviso. Credor que muda a política de desconto, produto novo na carteira, campanha de renegociação em massa, mudança regulatória: tudo isso desloca a distribuição dos dados e degrada o modelo em silêncio. Por isso monitoramento não é enfeite.

Por que tanto modelo de cobrança parece ótimo no slide e falha em produção

A causa número um tem nome: data leakage, ou vazamento de dado do futuro para dentro do treino.

Vazamento é usar, como variável explicativa, uma informação que na vida real só existiria depois do desfecho que você quer prever. O modelo aprende a “prever” o pagamento olhando para pistas do próprio pagamento. O resultado é sempre o mesmo: métricas espetaculares no teste e colapso quando o motor roda na carteira viva.

Em cobrança, o vazamento entra por portas muito banais:

Coluna de desfecho disfarçada de cadastro — valor pago, data de baixa, status “quitado”, flag de acordo cumprido, motivo de devolução.
Agregado calculado com a data de hoje — “quantidade de boletos emitidos”, “dias desde o último acionamento” ou “total de acordos” contados até agora, quando o alvo é um desfecho de três meses atrás.
A foto atual do contrato — ler a última ocorrência, a fase de atraso e o saldo de hoje para explicar o que aconteceu no passado.
Divisão aleatória entre treino e teste — sortear linhas embaralha futuro e passado. Metade do teste é contemporânea do treino, e o modelo já “viu” o período.
Rótulo imaturo — marcar como “não pagou” um contrato cuja janela ainda não fechou. Contrato de dez dias atrás, com janela de trinta, não é negativo: é indefinido.

O detalhe cruel é que vazamento não dá erro. Não trava, não estoura exceção, não aparece em log. Ele produz um modelo que parece o melhor que o time já fez. A conta chega meses depois, quando alguém compara previsão com realizado e descobre que a fila de prioridade não estava melhor do que ordenar por saldo devedor.

Aconteceu com a gente

A primeira geração do nosso motor de scoring era um monólito: uma procedure grande que montava base, treinava e recomendava no mesmo lugar. Ela tinha data leakage. Foi descontinuada e removida da frota em 05/08/2026 — a tabela que ela alimentava e a tela que a exibia saíram junto.

A segunda geração foi reescrita em camadas separadas justamente para tornar o vazamento difícil de cometer: é a diferença entre um número que orienta a operação e um número que orienta a operação para o lugar errado com muita confiança.

Feature store point-in-time: a única defesa estrutural contra vazamento

A defesa não é revisar features à mão antes de cada treino. Isso falha na terceira vez. A defesa é arquitetural: uma feature store point-in-time.

A ideia é simples de enunciar e chata de implementar. Cada linha da base de treino é a fotografia do contrato numa data específica, montada como se aquele fosse o dia de hoje. Regras que valem sem exceção:

Nenhuma variável usa a data atual. Toda janela, todo contador, todo “dias desde” é relativo à data da foto. Se o código consulta o relógio do servidor, a foto está contaminada.
O rótulo só entra quando amadurece. A janela do desfecho precisa ter fechado antes daquela linha virar exemplo de treino. Antes disso, ela fica sem rótulo — nunca vira negativa por conveniência.
A série histórica é reconstruída, não improvisada. Um backfill gera as fotos passadas com as mesmas regras das fotos futuras, para que treino e produção falem a mesma língua.

Como se valida um modelo de cobrança sem enganar a si mesmo

Prática	Por que importa em cobrança
Validação out-of-time	Treina até um corte de data e testa no período seguinte, como acontece na vida real. Split aleatório inflaciona o resultado porque o teste é contemporâneo do treino.
Respeito à maturação	Testar sobre um período cuja janela ainda não fechou faz o modelo parecer melhor do que é: parte dos positivos ainda vai acontecer.
Calibração	Ranquear bem não é o mesmo que acertar a probabilidade. Para decidir desconto ou ordenar por valor esperado, você precisa que 0,30 signifique 30% de verdade. Calibração isotônica corrige a escala depois do treino.
PSI e drift monitorados	Compara a distribuição de hoje com a do treino. No nosso motor, PSI acima de 0,25 dispara alerta para os administradores. Sem isso, o modelo envelhece calado.
Prevalência e defasagem no painel	Além do drift, vale acompanhar a taxa real de eventos e há quanto tempo cada título não é escorado. Score velho é pior que score ausente, porque ninguém desconfia dele.
Registry versionado com champion	Modelo, calibrador, metadados e o ponteiro do campeão ficam versionados, um champion por modelo. É o que permite responder, meses depois, qual modelo gerou determinado score.

Um teste rápido que qualquer gestor pode aplicar sem saber estatística: pegue os scores de três meses atrás, separe em faixas e compare a taxa de pagamento realizada em cada faixa. Se a faixa de 80 pagou em torno de 80% e a de 20 pagou em torno de 20%, o modelo está calibrado. Se todas pagaram parecido, o modelo não está separando nada, por mais bonita que fosse a apresentação.

A regra que quase ninguém diz em voz alta: sem histórico maturado, não existe modelo

Modelo supervisionado precisa de exemplos rotulados dos dois lados. Em recuperação, isso quer dizer pagamentos datados, em volume, cobrindo janelas já fechadas. Não é opinião de arquitetura: é pré-requisito matemático.

Quem não tem isso, e é muita gente:

carteira recém-implantada, com poucos meses de operação;
credor novo dentro de uma carteira antiga, cujo comportamento ninguém observou ainda;
produto ou modalidade nova, sem safra maturada;
operação que acabou de digitalizar o registro e cujo histórico anterior não é confiável.

Nesse cenário, treinar mesmo assim produz um modelo que memoriza ruído de algumas centenas de eventos. Ele vai gerar score, vai preencher dashboard e vai errar. Pior: vai errar com aparência de método.

Por isso, no nosso motor, o machine learning só liga onde a carteira tem histórico de pagamento maturado. Onde não tem, a instância roda a régua determinística — priorização, canal e melhor horário por regra —, com o modelo armado e desligado. Ligar depois é habilitar um processo agendado, não refazer o projeto. Essa é a configuração padrão da frota; o ciclo completo de ML é a exceção, avaliada por instância. Ninguém deveria pagar por um modelo que ainda não pode existir.

E vale dizer o que a régua determinística já resolve sozinha, porque é bastante: ordenar a fila, escolher o canal, respeitar melhor dia e melhor hora e aplicar as exclusões que o credor pediu. Muita operação ganha mais organizando isso do que treinando qualquer coisa. É o assunto do nosso texto sobre régua de cobrança.

Separar o que é modelo do que é política

Camada de ML: produz as duas probabilidades. Só isso.
Camada de política: transforma probabilidade em ação. Persona, canal sugerido, desconto máximo, valor esperado de recuperação e ordem de execução saem de regras determinísticas, escritas, versionadas e legíveis por quem não é cientista de dados.

Três ganhos concretos:

Mudar política não exige retreinar. O credor apertou o desconto máximo? Muda a regra, hoje, sem tocar no modelo.
Dá para explicar ao credor. “Este contrato entrou primeiro na fila porque a probabilidade estimada é X e o saldo é Y” é auditável. “A IA decidiu” não é.
Nenhum valor monetário nasce de IA. No nosso fluxo, quando um acordo é fechado — inclusive por atendimento automático no WhatsApp — os valores vêm do cálculo do sistema, pela configuração de fase do credor: juros, mora, multa, honorário, desconto permitido. A IA escolhe entre opções que o banco de dados calculou; ela não inventa número.

Como o Revo360 faz isso na prática

O motor se chama jAcob (Credit Optimization & Recovery Engine). O que ele é, sem adjetivo:

Feature store point-in-time, materializada por procedure, sem uso do relógio do servidor nas variáveis, com rótulo apenas maturado e backfill para reconstruir a série.
Scoring dos modelos de cura e de propensão a pagar — só nas instâncias que têm campeão treinado — em Python isolado no próprio servidor, com calibração, gravando o histórico de scores em tabela própria. O scoring não roda dentro do banco: o caminho in-database foi avaliado e descartado.
Camada de política em view, derivando os scores 0 a 100, persona, canal, desconto máximo, valor esperado e ordem de execução — determinística, sem treino.
Fila de contato sugerida por título e canal, com melhor dia e hora, alimentando as campanhas. A régua de cada credor é compilada uma vez a partir do texto de requisitos que a operação escreve — esse passo usa LLM — e fica gravada como JSON, executado depois de forma determinística.
Monitoramento de MLOps: PSI e drift com alerta acima de 0,25, prevalência e defasagem, com notificação aos administradores e painel técnico próprio.
Registry versionado com um champion por modelo, por instância. Não existe “o modelo do produto”: existe o campeão daquela carteira.
Operação enxuta: dois processos agendados por instância. O de régua e melhor horário é T-SQL puro e fica sempre ligado; o de scoring só roda onde há campeão treinado. Desligar o ML é desabilitar um deles.
Retenção e custo sob controle: o motor acumula fotos diárias e, sem expurgo, isso cresce por volta de 2,3 KB por título ativo por dia — em uma carteira de 90 mil títulos, cerca de 200 MB por dia. Há expurgo com janelas configuráveis que preserva a safra mensal de treino e a baseline do PSI, e compressão que devolve por volta de dois terços do espaço sem apagar nada.

Onde o resultado aparece para quem opera: na fila de contato que alimenta as campanhas, nas diretrizes que chegam ao atendimento automático — que negocia dentro dos limites calculados pelo sistema — e, nas instâncias com modelo treinado, no painel técnico que mostra drift e defasagem. Uma pendência que vale declarar: o dossiê que o copiloto interno entrega ao negociador ainda lê as colunas de propensão da geração antiga, hoje vazias — o campo fica em branco até o repoint para a tabela de scores nova.

Um esclarecimento que economiza confusão: o motor de campanhas é determinístico. Ele executa a consulta que a operação cadastrou, no horário configurado, uma vez por lote por dia, respeitando dia útil e feriado, e só quando o lote foi marcado como testado. O agendador verifica pendências a cada dez minutos. A parte inteligente da régua vem do jAcob; o disparo em si é execução previsível, e é bom que seja.

Sete perguntas para fazer a qualquer fornecedor que diz usar IA na cobrança

Qual é o alvo, exatamente, e em qual janela de tempo?
Como vocês garantem que nenhuma variável usa informação posterior ao desfecho? Peça a lista de features e a data de referência de cada uma.
A validação foi out-of-time ou divisão aleatória?
O modelo é calibrado? Mostre previsto contra realizado por faixa de score.
Qual é o PSI atual contra a baseline do treino, e quando foi o último retreino?
O que acontece na minha carteira nova, que não tem histórico maturado?
Na tela, o que é saída de modelo e o que é regra de negócio?

Fornecedor que responde às sete sem desconversar está falando de engenharia; quem responde com percentual de aumento de recuperação, não.

O que preparar antes de pensar em modelo

Nenhum motor conserta base ruim. Antes de discutir treino, garanta:

data de pagamento confiável na parcela — é a matéria-prima do rótulo;
tabulação de ocorrência com significado — o cadastro de ocorrências é o que define o que conta como acionamento e como contato com a pessoa certa; se ele é bagunçado, toda métrica de esforço fica errada;
configuração de fase por credor — faixas de atraso, taxas, desconto permitido e comissão, porque é daí que sai o cálculo do acordo;
algumas safras já maturadas, e não apenas meses de cadastro.

Com isso de pé, a discussão deixa de ser sobre fornecedor e passa a ser sobre a sua carteira.

Próximo passo

Se você quer ver o motor por dentro — a feature store datada, a separação entre modelo e política, o painel de drift e a régua determinística que roda antes do ML entrar —, agende uma demonstração do Revo360. Mostramos inclusive as partes que ainda não estão ligadas na sua carteira e o porquê.