Cobrança com IA: Manual de Uso com Claude para Empresas

A cobrança com IA é o uso de modelos de linguagem, como o Claude, para automatizar a comunicação de inadimplência, segmentar devedores e personalizar negociações sem perder o controle jurídico e ético. O principal ganho não está em enviar mais mensagens, mas em enviar a mensagem certa, no tom certo e no momento certo, com registro completo de cada interação. Empresas que estruturam o processo em etapas, com regras claras de escalonamento para um humano, reduzem o tempo de resposta e ampliam o contato com clientes que antes ficavam sem retorno. Dados da Serasa Experian indicam que dezenas de milhões de brasileiros estavam negativados em 2024, o que mostra a escala do problema. A recomendação central é começar por um único segmento de carteira, medir taxa de acordo e taxa de reclamação, e só então expandir. Toda automação deve respeitar o Código de Defesa do Consumidor e a LGPD, com revisão humana antes de qualquer proposta formal.

A cobrança com IA costuma dar errado no mesmo ponto: o disparo em massa. Imagine um analista que filtra a carteira por atraso acima de 30 dias e envia a mesma mensagem para 800 devedores. Ele não sabe que parte deles já pagou, que outros estão negociando um acordo com a própria empresa e que alguns contestaram a dívida na semana passada. Todos recebem o mesmo lembrete.

O resultado é conhecido por quem trabalha com recuperação de crédito. A taxa de acordo fica baixa, o cliente se irrita, cresce o número de reclamações no Procon e no Consumidor.gov.br, e a equipe passa o dia em planilhas tentando corrigir o que a régua fez. Trocar o texto da mensagem não resolve. O problema está em não saber, para cada devedor, em que etapa ele está.

Este texto é um manual operacional. Não traz promessas sobre o potencial da IA. Traz fluxos de decisão, prompts que você pode testar com a sua própria carteira, regras para passar um caso a um humano, tabelas de decisão e um checklist de conformidade com o Código de Defesa do Consumidor e com a LGPD. Cada parte foi pensada para ser aplicada numa segunda-feira, sem depender de um projeto de dois anos.

O modelo usado nos exemplos é o Claude, porque é com ele que trabalho nos projetos que descrevo aqui. Mas os princípios valem para qualquer modelo. Se amanhã você trocar de ferramenta, a segmentação da carteira, a ordem das etapas da régua e as regras de escalonamento continuam válidas. A ferramenta muda. A lógica da operação, em grande parte, não.

Ao final da leitura, você terá uma estrutura de carteira segmentada, uma régua de cobrança com etapas e prazos definidos, modelos de mensagem revisados sob a ótica do CDC e da LGPD, critérios objetivos para propostas de acordo e um plano de implantação em 30 dias com métricas para acompanhar semana a semana.

Se a sua empresa já tem alguma régua, boa parte do trabalho é desmontá-la e observar o que ela faz com cada segmento de devedor. É por aí que começamos.

O que é cobrança com IA e onde o Claude se encaixa

Cobrança com IA é a automação das tarefas repetitivas da operação, não a substituição de quem cobra. O time continua responsável pela negociação e pelas decisões. O que sai da mão dele são as partes mecânicas: separar a carteira por faixa de atraso, ler o histórico antes de cada contato, escrever o primeiro rascunho de uma mensagem e organizar as respostas que chegam por WhatsApp e e-mail.

Quando implantei isso em um cliente do setor de serviços recorrentes, o ganho mais visível não foi na taxa de recuperação logo no início. Foi o tempo que o analista deixou de gastar lendo trinta mensagens para entender o que tinha acontecido com um cliente.

O Claude entra em três pontos, todos ligados à linguagem. O primeiro é a leitura de textos longos: históricos de atendimento com dezenas de interações, contratos com cláusula de multa, cadeias de e-mail em que o tom do cliente muda aos poucos. O segundo é a geração de mensagens com tom controlado. Você define o tom, os dados obrigatórios e o que não pode ser prometido, e o modelo entrega um rascunho para revisão humana. O terceiro é a classificação de intenção. Uma resposta como "não lembro dessa compra, me manda o detalhamento" não é promessa de pagamento. Ela é contestação, e o sistema precisa tratá-la diferente de "consigo pagar no dia 10".

Aqui vale separar duas coisas que muita gente mistura. Data de vencimento, valor em atraso, dias de atraso e regra de envio de lembrete são automação determinística. Uma regra bem escrita ou um workflow faz isso melhor, mais barato e sem variação. Já "quero parcelar, mas só consigo depois do dia 10 e sem entrada" é tarefa de linguagem. Ninguém consegue escrever regra para cobrir todas as formas que um cliente encontra para dizer a mesma coisa. É nessa parte que o modelo agrega valor.

Um limite que não deve ser negociado: o modelo não decide crédito, não aprova desconto e não autoriza negativação. Ele prepara a informação para uma pessoa decidir. Resumo, classificação e rascunho chegam ao analista com a fonte destacada, e quem clica em "enviar" ou "negativar" responde pela decisão.

Vamos a um exemplo com uma carteira fictícia: uma provedora de internet com 1.200 clientes em atraso, divididos em faixas de 1 a 15, 16 a 60 e mais de 60 dias.

• Triagem (determinística): regras de faixa, valor e último pagamento separam os 1.200 clientes e disparam lembretes automáticos para quem está entre 1 e 15 dias. Sem IA.
• Resumo de histórico (IA): para cerca de 300 casos da faixa de 16 a 60 dias, o Claude lê o histórico e entrega um resumo de cinco linhas: o que foi prometido, o que não foi cumprido, se houve reclamação sobre o serviço.
• Classificação de respostas (IA): as 140 respostas recebidas na semana caem em categorias como "quer parcelar", "contesta a dívida" e "pediu cancelamento". Quem contesta vai direto para um analista.
• Rascunho de mensagem (IA, com revisão): para quem quer parcelar, o modelo sugere o texto usando só as opções aprovadas pela política de cobrança. O analista revisa e envia.
• Acordo, desconto e negativação (humano): nenhuma dessas decisões é automatizada. O sistema apresenta o caso completo e a pessoa decide.

Se quiser montar essa classificação de respostas passo a passo, incluindo as categorias de intenção e as regras de encaminhamento ao analista, o SWEN é a referência de implementação para esse trecho do processo.

No fim, a cobrança com IA funciona como um sistema de três camadas. A camada de dados é o histórico, os valores e as datas, e precisa estar correta antes de qualquer outra coisa. A camada de regras é o que o sistema faz sozinho, sem interpretar nada. A camada de linguagem é onde o Claude trabalha: lendo, resumindo, classificando e redigindo. Se uma delas estiver fraca, as outras duas não compensam.

Segmentação da carteira: antes de escrever qualquer mensagem

Antes de pedir ao Claude qualquer mensagem de cobrança, responda a uma pergunta mais simples: quem é esse devedor? Parece óbvio, mas é o passo que mais economiza retrabalho depois. Com a carteira mal segmentada, até um texto bem escrito chega à pessoa errada, no momento errado e com o tom errado.

Eu começo sempre pelas variáveis que realmente mudam a abordagem:

• Tempo de atraso, em faixas: 1 a 15 dias, 16 a 30, 31 a 60, 61 a 90 e acima de 90. Cada faixa pede um tipo de contato diferente.
• Valor em aberto. Uma fatura de R$ 80 e outra de R$ 8 mil não merecem o mesmo esforço nem o mesmo escalonamento.
• Histórico de pagamento. Quem atrasa dois dias há anos não é quem atrasou pela primeira vez.
• Acordo anterior. Quem já quebrou um parcelamento precisa de uma conversa diferente de quem nunca negociou.
• Canal preferido. WhatsApp costuma responder melhor que e-mail, mas isso varia por público. Meça na sua base em vez de presumir.
• Sinais de contestação: reclamação registrada, pedido de cancelamento, dúvida sobre o valor.
• Natureza do produto. Assinatura de software, mensalidade escolar e financiamento de bem durável têm dinâmicas de inadimplência bem diferentes.

Não precisa de ferramenta sofisticada para organizar isso. Uma planilha resolve, com uma linha por cliente e colunas para cada variável acima, mais uma coluna de observação livre. Se quiser partir de um modelo pronto, o SWEN tem um passo a passo para montar essa estrutura.

Onde o Claude ajuda de verdade é nas notas de atendimento. Atendentes escrevem coisas como "cliente disse que já pagou, não achou comprovante, pediu segunda via". Esse texto livre não serve para filtrar nada. Peça ao Claude que leia cada nota e classifique em categorias fixas que você definiu, por exemplo "alega pagamento", "dificuldade financeira declarada", "contesta serviço" ou "sem retorno". Ele preenche a coluna padronizada e pode marcar os casos em que não tem certeza. O passo que não pode ser pulado é a validação humana: sorteie uma amostra de cada lote, confira a classificação e meça quantas bateram com o que um atendente classificaria. Se uma categoria erra muito, ajuste a definição antes de confiar no resultado.

Os três perfis abaixo são ilustrativos. Eles reúnem padrões que observo com frequência em empresas de serviços recorrentes de porte médio, não são clientes específicos.

Cliente que esqueceu o vencimento

Atraso de poucos dias, valor baixo, histórico limpo e nenhuma menção a problema na nota. A abordagem deve ser um lembrete curto, sem tom de cobrança, com link de pagamento no canal preferido dele. Negociação não é necessária, e uma mensagem mais dura só gera atrito com quem pagaria em seguida.

Cliente com dificuldade temporária

Atraso entre 31 e 60 dias, histórico bom até então, e notas que mencionam redução de renda ou mudança de emprego. Aqui cabe uma oferta de reparcelamento ou de pagamento parcial com nova data, em tom empático. Se ele aceitar, o acordo volta para a régua normal. Se não responder, passe para um atendente humano em vez de insistir com mensagens automáticas.

Cliente que contesta o serviço

A nota diz algo como "isso nunca funcionou direito" ou pede cancelamento. Nesse caso, a cobrança é o último passo, não o primeiro. Encaminhe o caso para a área responsável com o histórico de chamados anexado e suspenda qualquer contato de cobrança até haver resposta.

O erro mais comum que vejo é usar a mesma régua para todo mundo. Uma régua única trata quem esqueceu como caloteiro, empurra quem está em dificuldade para o cancelamento e cobra quem está contestando, o que costuma virar reclamação formal. E o Claude não corrige um pedido genérico: se você pedir "escreva uma cobrança para inadimplentes", ele vai escrever uma cobrança genérica.

Por isso recomendo criar uma tag de contestação ativa. Qualquer sinal de contestação, seja na nota, em um chamado ou em um pedido de cancelamento, aplica a tag. Enquanto ela estiver ativa, nenhuma mensagem automática de cobrança sai para aquele cliente. A tag só sai quando um humano registra a resposta e define o desfecho, e a régua volta a valer a partir daí.

A qualidade da segmentação determina o resultado de todas as etapas seguintes: o texto, o canal, o momento do envio e a chance de acordo. Se ela estiver errada, a IA só erra mais rápido.

Régua de cobrança com IA: etapas, canais e cadência

A régua de cobrança é onde a IA mais economiza tempo e onde mais dá para estragar a relação com o cliente. Já vi uma operação automatizar tudo em uma semana e receber reclamação formal no mês seguinte. A estrutura abaixo tem cinco etapas. O Claude escreve e classifica, mas quem define canal, limite e alçada é a sua política.

As etapas da régua

D+1: lembrete

Objetivo: avisar que o vencimento passou, sem presumir má-fé. Canal: WhatsApp, com e-mail de reforço no D+3 se não houver leitura. Cadência: uma mensagem, em horário comercial. Tom: prestativo, com boleto ou link de pagamento já na primeira mensagem.

D+5: segundo contato

Objetivo: confirmar se o boleto chegou e oferecer ajuda. Canal: e-mail e SMS, com um dia de intervalo. Cadência: um toque por canal. Tom: neutro e objetivo.

D+10: ligação e oferta de acordo

Objetivo: tirar o caso do limbo. O cliente paga, parcela ou explica o motivo. Canal: ligação, precedida de aviso no WhatsApp. Cadência: uma tentativa, com nova janela apenas se houver resposta. Tom: direto, sem dramatizar.

D+20: proposta formal

Objetivo: formalizar as opções de parcelamento, com valor total, juros e prazo de validade. Canal: e-mail com proposta em PDF e link de aceite. Cadência: um envio. Tom: formal.

D+30: encaminhamento

Objetivo: passar o caso para a equipe de cobrança especializada ou para o jurídico. Canal: interno, com notificação formal ao cliente no canal cadastrado. Cadência: marco único. Tom: técnico, sem ameaça.

Canais por faixa de atraso

A tabela abaixo traz referências operacionais, não dados de mercado. Os valores de custo são uma escala relativa de 1 a 5 para ordenar opções, e as taxas de leitura são faixas de ponto de partida que usamos internamente. Meça a taxa real na sua base, separando por segmento e por canal, antes de tomar qualquer decisão de orçamento.

Limites de horário e de conduta

O Decreto 11.034/2022 regulamenta a cobrança de dívidas de consumidores e restringe os horários de contato. O artigo 42 do Código de Defesa do Consumidor proíbe qualquer constrangimento. Confirme a janela exata com o seu jurídico, mas a regra prática que eu adoto é simples: nada à noite, nada em fim de semana e feriado sem autorização expressa do cliente. Configure isso no próprio agendador, não na memória de quem opera.

Como o Claude entra no fluxo

Para as variações de mensagem, monte um banco por etapa, com instruções de tom, tamanho e o que não pode aparecer. Peça cinco variantes para cada momento e descarte as que começarem igual ou usarem a mesma estrutura. Com isso, o cliente que recebe três cobranças não percebe o robô na terceira.

Para as respostas, o Claude classifica cada mensagem recebida em categorias: pedido de parcelamento, contestação, promessa de pagamento, pagamento informado ou ausência de resposta. Pedidos de parcelamento seguem para o fluxo de acordo. Contestações vão para o jurídico ou para o atendimento, nunca para uma resposta automática. A classificação ambígua vai para um humano. Vale a pena ser conservador aqui.

Por fim, a orquestração. Um agente no Claude Code, conectado à base de dados via API, pode executar a régua inteira. Cada decisão deve gerar log com data, entrada, classificação, ação tomada e motivo. Quando um cliente reclamar, você reconstrói o caso em minutos, e não em uma semana de planilha. O passo a passo de integração com a base está no SWEN, para quem quiser começar pelo básico.

Como escrever prompts de cobrança que funcionam

Quando alguém me pede um prompt de cobrança, a versão inicial costuma ser uma frase do tipo "escreva uma mensagem educada para cobrar o cliente". Funciona na primeira semana. Depois, alguém pede uma versão mais firme, outro quer incluir desconto, e em dois meses ninguém sabe qual texto está rodando. Por isso eu monto o prompt sempre em blocos fixos.

O modelo de prompt

Os campos entre chaves são preenchidos pelo seu sistema antes do envio ao Claude. O operador não digita nada na hora.

Papel: Você escreve mensagens de cobrança para {nome_empresa}, pelo canal {canal}.

Contexto: Primeiro nome do cliente: {primeiro_nome}. Valor em aberto: {valor}. Vencimento: {data_vencimento}. Dias em atraso: {dias_atraso}. Resumo do relacionamento: {resumo_relacionamento}.

Objetivo desta etapa: {objetivo_etapa}.

Tom: cordial, direto, sem jargão financeiro. Trate o cliente por você.

Restrições: não ameace. Não use linguagem vexatória. Não ofereça condições além de {condicoes_autorizadas}. Mencione negativação somente se {negativacao_disponivel} for "sim". Não cite dívidas de terceiros nem dados de outros clientes.

Formato: texto curto, até 600 caracteres, sem assunto, assinado por {nome_remetente}.

O bloco de contexto precisa de disciplina. Nome, valor, datas e um resumo curto bastam. CPF, endereço e histórico completo de pagamentos não ajudam o modelo a escrever uma boa mensagem e só aumentam o risco se o log vazar. Já vi empresa mandar a base inteira no prompt "por garantia". Não faça isso.

O campo {negativacao_disponivel} merece atenção especial. Ele deve vir do sistema, refletindo se a empresa realmente pode negativar naquele caso, com as notificações prévias cumpridas. Se o modelo puder decidir sozinho, ele vai mencionar negativação em casos em que ela não existe, e isso gera problema jurídico sério.

As restrições precisam estar escritas, mesmo que você ache óbvio. Sem elas, o modelo tende a ser mais agressivo ou mais generoso do que deveria. Além das proibições do bloco acima, a mensagem não pode expor a dívida a terceiros, como familiares ou colegas de trabalho, nem prometer desconto que ninguém autorizou.

Três exemplos de saída

Lembrete amigável (etapa 1):

Oi, Mariana, tudo bem? Passando para lembrar que a fatura de R$ 384,90 venceu ontem. Se já pagou, desconsidere. Se precisar da segunda via, é só responder aqui que eu envio na hora.

Mensagem de negociação (etapa 2, 30 dias de atraso):

Mariana, sei que nem sempre o mês fecha como a gente planeja. Podemos dividir os R$ 384,90 em duas parcelas de R$ 192,45, com a primeira no dia 15. Se essa data não funcionar, me fala qual encaixa melhor.

Resposta a quem pediu mais prazo:

Claro, Mariana. Consigo estender o vencimento até o dia 22. Fica bom para você? Se até lá ainda houver dificuldade, me avisa antes, para ajustarmos juntos.

Few-shot com mensagens aprovadas pelo jurídico

Peça ao jurídico entre 20 e 30 mensagens por etapa e situação, já aprovadas. Guarde-as em uma base separada. Na hora de gerar, o sistema seleciona três a cinco exemplos parecidos com o caso e os inclui no prompt. O modelo aprende o estilo, não o texto. Não deixe ele copiar frases literalmente, senão as mensagens ficam todas iguais e o cliente percebe.

Testes e revisão humana

Antes de trocar qualquer versão, faça teste A/B com divisão aleatória da carteira. Altere uma variável por vez, seja o tom, o horário ou o tamanho, e meça taxa de resposta, taxa de pagamento, reclamações e descadastros. Teste com amostra pequena costuma enganar. Espere volume suficiente antes de declarar vencedor. Nas primeiras cem mensagens geradas por cada prompt novo, a revisão deve ser humana, com alguém de cobrança e alguém do jurídico lendo. Defina critérios de parada antes de começar, por exemplo, duas mensagens com erro de tom ou restrição violada pausam o prompt.

O prompt é um ativo

Trate o prompt como código de produção. Guarde-o em repositório, com número de versão, data, autor, quem aprovou e changelog explicando o que mudou. Registre qual versão gerou cada mensagem enviada. Quando algo der errado, você precisa saber em minutos qual texto saiu e como voltar à versão anterior. Se quiser ver exemplos de prompts testados com esse mesmo passo a passo, o SWEN tem tutoriais com a estrutura completa.

Negociação e propostas de acordo com apoio da IA

Obs.: o blog aceita apenas os elementos HTML listados na política de formatação, então a tabela de alçadas foi montada como lista estruturada. Os dados são os mesmos.

Negociação é a fase em que a IA mais ajuda e também a que mais pode causar prejuízo. A regra que sigo com clientes é simples: o Claude monta, simula e explica, mas quem autoriza é a alçada. A tabela abaixo é a única referência de limites deste manual, e todo o processo parte dela.

Alçadas de desconto

Organizei as propostas em quatro níveis pela faixa de atraso. As faixas não se sobrepõem, então cada caso cai em exatamente uma linha. Os valores são referências e precisam ser confirmados com a política financeira vigente antes de entrar em produção.

• Nível 1, automático: atraso de 0 a 30 dias. Desconto automático de até 5% sobre multa e juros, em até 3 parcelas. O sistema monta e envia a proposta depois de validada.
• Nível 2, supervisor: atraso de 31 a 90 dias. Desconto acima de 5% até 15%, em até 6 parcelas. Nenhum desconto sai sem aprovação do supervisor, que recebe a simulação pronta.
• Nível 3, gerência financeira: atraso de 91 a 180 dias. Desconto acima de 15% até 30%, em até 12 parcelas. Exige aprovação da gerência, com o motivo registrado.
• Nível 4, jurídico: atraso acima de 180 dias, ou qualquer caso fora dos limites acima. Também vão para jurídico clientes com ação em andamento, sinais de superendividamento ou pedido de parcelamento acima de 12 vezes. Nesses casos, o Claude não formula proposta. Ele só resume o histórico para o jurídico.

O que o Claude faz de fato

Nesta fase, o Claude faz três coisas. Primeiro, simula parcelamentos a partir de uma função de cálculo que a empresa controla. Ele pode testar "e se fosse em 4 vezes?" e comparar cenários, mas não calcula juros de cabeça. Segundo, transforma a proposta em linguagem clara, sem jargão de cobrança. Terceiro, escreve o resumo para o cliente: custo total, valor de cada parcela e datas de vencimento.

O resumo é onde mais vejo problema. Nas relações de consumo, o Código de Defesa do Consumidor (art. 52) exige que juros, multa, correção e custo total sejam informados de forma prévia e clara. Na prática, cada encargo deve aparecer em uma linha própria, com valor em reais. Se a empresa esconde tudo em "encargos", o acordo fica frágil. E a multa moratória não pode passar de 2%.

O risco de a IA prometer o que não pode

Já vi um modelo oferecer 25% de desconto para um cliente com teto de 10%. Não houve má intenção. O prompt dizia "seja flexível para fechar acordos", e o modelo leu isso como permissão. Prompt orienta, mas não controla. Quem decide o que sai do sistema é o código.

Por isso a validação precisa ser determinística. Toda proposta gerada passa por uma rotina fixa que compara desconto, número de parcelas e faixa de atraso com a tabela de alçadas. Se algo ultrapassa o teto do nível, a proposta é bloqueada e encaminhada para a alçada correta. O modelo nunca grava condição final no sistema de cobrança. Ele sugere, e a aplicação valida e aplica. O tutorial completo dessa integração está no SWEN, com exemplos de regras de validação.

Checklist antes de enviar qualquer proposta formal

• A faixa de atraso corresponde ao nível aplicado?
• Desconto e número de parcelas estão dentro do teto do nível, ou há aprovação registrada?
• Juros, multa e correção aparecem separados, com valores em reais?
• O custo total bate com a soma das parcelas?
• Todas as parcelas têm data de vencimento?
• O texto está em linguagem simples, sem promessas que a empresa não cumpre?
• A aprovação está registrada com nome de quem aprovou e data?
• Casos de nível 4 foram para o jurídico e não foram enviados ao cliente?

Compliance: Código de Defesa do Consumidor e LGPD

Compliance é a parte do projeto que ninguém gosta de ler e que, quando falha, vira assunto da reunião inteira. Abaixo estão os pontos que de fato aparecem em cobrança com IA. Nada disso substitui parecer jurídico, e o fluxo precisa ser validado com advogado especializado em consumidor e proteção de dados antes de entrar em produção.

O que o Código de Defesa do Consumidor exige

O artigo 42 é o mais citado e o que mais gera reclamação. O consumidor inadimplente não pode ser exposto a ridículo, nem submetido a constrangimento ou ameaça. Isso vale para o tom das mensagens, para listas de devedores visíveis a terceiros e para qualquer frase que sugira vergonha pública.

Cobrança de valor indevido tem consequência financeira direta. Quem cobra além do devido pode ser obrigado a devolver em dobro, salvo engano justificável. Um modelo que calcula juros, multa ou correção errada é um risco concreto. Por isso o valor deve sair de uma regra determinística, e o modelo apenas redige a mensagem em torno dele.

O artigo 39 trata das práticas abusivas. O Decreto 11.034/2022 detalha regras para cobrança de dívidas de consumo, incluindo faixa de horário para contato e restrições a contatos com terceiros. Automação roda 24 horas, e é justamente aí que a regra de horário costuma ser ignorada.

Clareza também é obrigação. Valor principal, encargos, forma de pagamento e consequência do não pagamento precisam estar compreensíveis. Um texto simpático que omite o cálculo não atende ao artigo 6º, inciso III.

Princípios da LGPD que pesam na operação

Finalidade e necessidade são os que mais vejo ignorados. Os dados enviados ao modelo devem servir a uma finalidade declarada de cobrança, na medida do necessário. Se a tarefa é redigir um lembrete de vencimento, o modelo não precisa do histórico completo de compras do cliente.

Transparência significa que o titular sabe que existe uma camada de IA no atendimento, quando isso for relevante. Segurança e prevenção exigem controle de acesso, criptografia em trânsito e em repouso, e prazo de retenção definido. Se o cliente pede revisão de decisão automatizada, o artigo 20 garante esse direito, e o fluxo precisa ter caminho humano.

O que implementar na prática

Minimização é o primeiro filtro. Antes de qualquer chamada, remova CPF, endereço completo, dados bancários e tudo que a tarefa não usa. Metade dos problemas de exposição que já encontrei começou com um prompt que carregava o cadastro inteiro por comodidade.

Anonimização funciona bem quando a tarefa não exige identificação, como classificar o tipo de atraso ou sugerir o tom do contato. Quando a mensagem precisa de personalização, use identificadores internos e reidentifique só na etapa final, dentro do seu sistema.

Contrato de processamento com o fornecedor do modelo é obrigatório. Você é controlador e ele é operador. O acordo precisa tratar finalidade, subprocessadores, local de processamento e exclusão. Como o processamento costuma ocorrer fora do Brasil, verifique também os requisitos de transferência internacional do artigo 33.

Registro de operações: guarde entrada minimizada, saída, versão do modelo, data e responsável. Isso sustenta a auditoria e é o que você apresenta ao Procon ou à ANPD em caso de questionamento. Logs que armazenam o prompt completo com CPF criam um banco de dados paralelo que ninguém quis criar. Se quiser ver como estruturar esses campos, o SWEN tem um tutorial com o modelo de log.

Dados de terceiros nas notas

Notas de atendimento costumam citar pessoas que não são o devedor: o familiar que atendeu o telefone, o avalista, o cônjuge de um acordo. Se essas notas entram no contexto do modelo, esses terceiros também estão sendo processados. Filtre o que não se relaciona à dívida e encaminhe para revisão humana quando um terceiro aparecer de forma relevante.

Registro de atividades de tratamento

Inclua a camada de IA no registro previsto no artigo 37 da LGPD. Descreva a finalidade, as categorias de dados enviadas ao modelo, o fornecedor, as medidas de segurança e o responsável pelo fluxo. Esse registro costuma ficar desatualizado porque a IA entrou depois, por fora do processo formal. Corrigir isso antes de uma fiscalização custa muito menos do que depois.

Integração com CRM, ERP e meios de pagamento

Na prática, a IA é a parte menos complicada de uma cobrança automatizada. O trabalho pesado está em fazer os sistemas conversarem sem disparar cobrança para quem já pagou. Já vi uma operação em que o modelo classificava bem a situação de cada cliente, mas a mensagem saía para quem tinha acabado de quitar o boleto. O problema estava na arquitetura, e não no modelo.

Os componentes e o papel de cada um

São cinco peças, e cada uma tem uma responsabilidade clara.

• CRM ou ERP: guarda os títulos, vencimentos, histórico de contato e dados do cliente. Se o título está errado aqui, todas as outras peças herdam o erro.
• Camada de orquestração: busca os dados, monta o contexto e chama o Claude via API. É ela que guarda as chaves, controla retentativas e grava os logs.
• Módulo de regras determinísticas: decide quem entra na régua, em que canal e com qual limite de frequência. Tudo que pode ser resolvido por regra fixa não deve passar pela IA.
• Envio de mensagens: WhatsApp, e-mail ou SMS, sempre com a mensagem já validada.
• Gateway de pagamento: confirma a quitação e devolve o status para o CRM ou ERP.

Webhooks: a régua precisa saber quando o cliente pagou

Sem webhook, a régua trabalha com uma foto de ontem. O cliente paga às 10h, o sistema só percebe no lote da madrugada, e às 9h do dia seguinte recebe uma cobrança. Isso gera reclamação, desgaste e, em alguns casos, ação jurídica desnecessária. Configure o gateway para notificar o sistema a cada evento de pagamento, atualize o status do título imediatamente e cancele qualquer mensagem agendada para aquele cliente. Trate o webhook como a fonte principal de verdade e deixe a consulta periódica apenas como rede de segurança.

Registro de cada chamada à IA

Auditoria não é opcional quando há dinheiro e relacionamento em jogo. Para cada chamada ao modelo, registre a entrada enviada, a saída bruta recebida, a versão do prompt, o modelo utilizado e a decisão final tomada pelo sistema. Quando um cliente contestar uma mensagem, você precisa reconstruir exatamente o que aconteceu naquele momento. Versionar o prompt como se fosse código faz muita diferença aqui.

Limites de taxa, erros e fallback

A API tem limites de requisições por minuto, e um pico de vencimentos no dia 10 pode estourar esse teto. Use fila e espaçamento entre chamadas, e trate o erro 429 com retentativa exponencial. Se o modelo não responder ou responder algo inválido, o caso vai para uma fila de revisão humana, nunca para um envio automático. Vale ler o tutorial de configuração de filas e retentativas no SWEN, que detalha os parâmetros que costumo usar.

A IA recebe dado filtrado e sua saída passa por validação

Não mande a base inteira para o modelo. Primeiro, as regras determinísticas eliminam quem não deve ser cobrado naquele dia. Depois, a IA recebe apenas os campos necessários para decidir o tom e a mensagem. Na volta, a resposta precisa seguir um esquema fixo, por exemplo um JSON com canal, texto, data sugerida e nível de confiança. Se faltar um campo obrigatório, ou se o valor vier fora do permitido, a resposta é descartada. Só depois dessa validação o sistema age.

Fluxo resumido

1. O CRM ou ERP envia o título vencido e o histórico do cliente para a camada de orquestração.
2. As regras determinísticas removem clientes em negociação, pagamentos em compensação e quem já foi contatado no limite do dia.
3. A orquestração monta o contexto mínimo e chama o Claude, registrando entrada e versão do prompt.
4. A saída é validada contra o esquema. Se falhar, o caso vai para revisão humana.
5. A mensagem válida entra na fila de envio pelo canal definido.
6. O webhook do gateway informa qualquer pagamento e cancela imediatamente as mensagens pendentes daquele cliente.
7. O status final volta ao CRM ou ERP, fechando o registro de auditoria da cobrança.

Métricas e plano de implantação em 30 dias

Antes de falar em semanas, precisa de números. Já vi equipes montarem um piloto, verem a taxa de acordo subir na primeira semana e comemorarem sem saber qual era o número de antes. Sem linha de base, qualquer resultado vira opinião.

Estas são as métricas que acompanho em qualquer projeto de cobrança:

• Taxa de contato efetivo: conversas reais sobre o total de tentativas, sem contar mensagem apenas entregue.
• Taxa de acordo: negociações fechadas sobre contatos efetivos. É a métrica mais fácil de inflar com desconto excessivo.
• Valor recuperado por carteira: dinheiro pago, separado por faixa de atraso.
• Taxa de reclamação: reclamações em SAC, ouvidoria e Procon por mil cobranças.
• Tempo médio até o primeiro contato: do vencimento até a primeira abordagem.
• Taxa de contestação: dívidas questionadas pelo cliente. Aponta erro de dados antes que vire problema jurídico.
• Custo por recuperação: custo total da operação (pessoas, telefonia, tokens) dividido pelo valor recuperado.

Linha de base e grupo de controle

Levante pelo menos oito semanas de histórico com essas métricas, separadas por carteira. Se houver sazonalidade, como dezembro, compare com o mesmo período do ano anterior.

Para medir impacto real, sorteie clientes em dois grupos. O tratado recebe a régua nova. O controle segue a operação atual. Mantenha o controle até o fim do piloto, mesmo quando alguém pedir para "liberar todo mundo". Sem ele, você compara a IA com o passado, e o passado nunca é neutro.

Plano de quatro semanas

Semana 1, mapeamento e segmentação. Liste carteiras, motivos mais comuns de inadimplência e canais que funcionam para cada perfil. Escolha para o piloto um segmento de valor baixo a médio e volume alto. Não comece pela carteira mais difícil.

Semana 2, prompts e régua em piloto. Escreva regras explícitas: o que o modelo pode oferecer, o que nunca pode prometer, quando transferir para humano e como tratar pedido de comprovante. Acompanhe reclamações diariamente.

Semana 3, análise de amostras e ajustes. Leia cinquenta conversas aleatórias por semana. Procure condições inventadas, tom agressivo e contestações tratadas como cobrança comum. Corrija antes de ampliar.

Semana 4, expansão controlada e documentação. Se passou nos critérios, amplie para mais uma carteira mantendo controle. Registre a versão de cada prompt, a data de cada mudança e o resultado.

Critérios de parada

Defina os gatilhos por escrito antes de começar. Os que costumo usar:

• Taxa de reclamação no grupo tratado acima de 1,5 vez a do controle.
• Qualquer reclamação formal no Procon atribuída à abordagem automatizada.
• Contestações subindo mais de dois pontos percentuais.
• Qualquer conversa em que o modelo tenha prometido condição não aprovada.

Reverter não é desligar tudo. É voltar ao fluxo anterior no segmento afetado, entender a causa e reabrir só quando houver correção.

Revisão mensal como rotina

Prompts envelhecem. A política de acordo muda, a carteira muda, o modelo recebe atualizações. Marque uma revisão mensal com cobrança, jurídico e atendimento: releia as métricas, confira uma amostra de conversas e atualize os prompts com histórico de versões. Quem faz isso uma vez e para, em seis meses opera com regras que ninguém mais entende.

Próximos passos

Esta semana, levante as sete métricas da sua operação atual, escolha a carteira do piloto e escreva os critérios de parada. Se quiser um ponto de partida para a configuração da régua, o tutorial no SWEN ajuda a organizar esse primeiro desenho.

A vantagem da IA em cobrança não está no modelo. Qualquer concorrente tem acesso ao mesmo Claude. Está em quem mede a linha de base, separa grupo de controle, lê as conversas e revisa os prompts todo mês. A tecnologia se compra. A disciplina operacional se constrói.