Idempotência em automação de IA sem cobrança dobrada

Equipe Viver de IA · 2026-09-22

Por que a mesma automação disparada duas vezes cobra o cliente duas vezes, e a lógica simples que evita isso.

O boleto que saiu duas vezes

Em um fluxo de automação com IA, cada tarefa pode ser disparada mais de uma vez sem que ninguém aperte o botão duas vezes. Uma conexão que caiu no meio, um webhook que reenviou, um agente que reprocessou a mesma mensagem: qualquer um desses faz a automação rodar de novo. E se a tarefa dela era emitir um boleto, o cliente recebe dois.

Quem monta automação séria trata isso como regra, não exceção. As estimativas de mercado sobre entrega de mensagens em sistemas distribuídos apontam a mesma coisa há anos: a rede não garante que algo aconteça exatamente uma vez. Ela garante, no máximo, que aconteça pelo menos uma vez. A diferença entre esses dois é onde mora o e-mail duplicado, a cobrança dobrada e o cliente irritado no WhatsApp às 22h.

É aqui que entra idempotência: a propriedade de uma tarefa que pode rodar dez vezes e produzir o mesmo resultado que rodaria uma vez só. Rodou de novo? Não gera efeito novo. É uma palavra feia pra uma ideia simples, e é a diferença entre uma automação que você deixa rodando sozinha e uma que precisa de alguém vigiando.

Idempotência na automação de IA, explicada sem engenheiro na sala

Apagar a luz é idempotente. O interruptor já está desligado, você aperta de novo, continua desligada. Nada muda.

Transferir R$ 500 não é. Você aperta duas vezes, saem R$ 1.000. O segundo clique produz um efeito novo, e esse efeito é dinheiro real saindo da conta de alguém.

Toda automação que sua empresa roda cai em um desses dois campos. O problema é que a maioria não para pra separar. A automação nasce funcionando no teste, onde tudo dispara uma vez, e vai pra produção onde a rede engasga, o servidor reinicia, o agente de IA relê a fila. Aí a tarefa que "transferia R$ 500" roda duas vezes.

Na nossa leitura, esse é o buraco mais comum em automação feita rápido. Não porque a pessoa é ruim, mas porque a repetição só aparece em produção, sob carga, quando já tem cliente do outro lado. No teste, nunca.

Evento chega → Já processei esse ID? → Sim: ignora → Não: executa e registra ID

Esse fluxinho de quatro passos é o coração da coisa. Todo evento carrega um identificador único. Antes de executar, a automação pergunta: "eu já vi esse ID?". Se já viu, descarta. Se não, executa e anota o ID. Simples de descrever, e a maior parte das automações caseiras não faz.

Os quatro tipos de tarefa, e o risco de cada uma repetir

Nem toda tarefa precisa da mesma proteção. Antes de blindar nada, vale classificar o que sua automação faz. São quatro grupos, do inofensivo ao perigoso.

1. Leitura pura

A tarefa só consulta e devolve informação. Puxa o saldo, lê o status de um pedido, busca o histórico do cliente. Rodou dez vezes? Devolveu a mesma resposta dez vezes. Nada muda no mundo. Esse tipo é naturalmente idempotente e você não precisa se preocupar com ele.

2. Escrita que substitui

A tarefa grava um valor, mas sobrescrevendo. "Marca o pedido 4521 como pago." Rodou de novo? Marca como pago de novo, e o resultado é o mesmo: pago. É idempotente por natureza, porque o segundo comando não empilha, ele repete o estado final. A maioria dos updates de banco de dados cai aqui, e por isso são seguros por acidente.

3. Escrita que acumula

Aqui começa o perigo. A tarefa soma, cria, incrementa. "Adiciona R$ 500 ao saldo." "Cria um novo agendamento." "Envia um e-mail." Cada execução empilha em cima da anterior. Rodou duas vezes, tem dois efeitos. É o campo da cobrança dobrada, do e-mail duplicado, do lead que entra três vezes no CRM. É onde a idempotência precisa ser construída de propósito, porque ela não vem de graça.

4. Chamada externa que gera custo ou efeito irreversível

O grupo mais caro. A tarefa aciona um serviço de fora que cobra por uso ou faz algo que não dá pra desfazer: dispara um pagamento pra um gateway, chama uma API de IA que fatura por chamada, manda um SMS que já saiu. Aqui a repetição duplica o efeito e cobra dinheiro de verdade a cada rodada. Uma automação que reprocessa uma fila de 500 mensagens e reenvia todas porque caiu no meio pode gerar uma fatura de API que ninguém previu.

A régua prática: os grupos 1 e 2 você deixa em paz. Os grupos 3 e 4 são os que exigem trabalho. E dá pra saber quais são os seus olhando cada tarefa e perguntando: "se isso rodar de novo agora, o que acontece de errado?". Se a resposta for "nada", relaxa. Se for "cobra de novo", "manda de novo", "cria outro", você achou onde investir.

Por que a IA piora esse problema em vez de resolver

Automação tradicional é previsível: recebe X, faz Y. Automação com agente de IA no meio é outra história, e aqui a gente é teimoso em alertar.

Um agente decide o que fazer a cada passo. Ele pode reler a mesma mensagem do cliente e concluir, na segunda leitura, que ainda não respondeu, e responder de novo. Pode reprocessar uma fila e disparar a ação duas vezes porque "não encontrou o registro" na primeira tentativa por causa de um atraso de gravação. O agente não tem noção do que já fez a menos que você dê essa memória a ele.

E tem o retry automático. Quando uma chamada de IA demora ou falha, a plataforma quase sempre tenta de novo sozinha. Isso é ótimo pra confiabilidade e ruim pra idempotência, porque a primeira chamada pode ter funcionado, só demorou pra responder. Aí a segunda executa a ação que a primeira já tinha executado. Dois e-mails. Duas cobranças.

O Centro Médico Alphaview automatizou entre 80% e 87% da recepção com confirmação de consultas por WhatsApp e reforço por voz com IA. Um fluxo desses, num dia cheio, dispara a mesma confirmação pra centenas de pacientes. Sem idempotência, um reprocessamento manda a segunda mensagem pro paciente que já confirmou, e do outro lado é um sinal de desorganização, não de eficiência. É exatamente o tipo de operação onde a repetição some no teste e aparece no volume real. (veja o case.)

As três formas de blindar uma tarefa contra repetição

Não existe uma solução única. Existem três mecanismos, e você escolhe pela natureza da tarefa.

1. Chave de idempotência. Cada operação carrega um identificador único gerado na origem: o ID do pedido, o ID da mensagem, um código que representa aquela ação específica. Antes de executar, a automação consulta se já viu essa chave. Se viu, ignora. Os gateways de pagamento sérios já pedem essa chave justamente por isso: você manda "cobrar pedido ABC123" e, mesmo que mande dez vezes, o gateway cobra uma. É o mecanismo mais robusto pro grupo 4, o das chamadas externas com custo.

1. Trava de registro (lock). Antes de rodar, a tarefa marca "estou processando isso agora" e só libera quando termina. Se uma segunda execução chega enquanto a primeira roda, ela vê a trava e espera ou desiste. Serve bem pra escrita que acumula, pra evitar que dois processos criem o mesmo agendamento ao mesmo tempo.

1. Verificação de estado. Antes de agir, a tarefa checa o mundo. "Esse cliente já recebeu o e-mail de boas-vindas?" "Esse boleto já foi emitido?" Se sim, não faz de novo. É o mais fácil de entender e o mais frágil, porque depende de a verificação e a ação acontecerem juntas, sem brecha entre elas. Duas execuções simultâneas podem checar ao mesmo tempo, as duas verem "não enviado", e as duas enviarem.

Na prática, uma automação madura combina as três. A chave garante o caso geral, a trava cobre a corrida entre execuções simultâneas, e a verificação de estado é a rede de segurança. Você não precisa saber implementar isso na mão. Precisa saber que existe, pra cobrar de quem monta.

1. Liste as tarefas: escreva cada ação que a automação executa
2. Classifique o risco: marque quais acumulam, criam ou cobram
3. Escolha o mecanismo: chave, trava ou verificação por tarefa de risco
4. Teste a repetição: dispare a mesma tarefa duas vezes de propósito e veja se dobra
5. Registre o comportamento: documente como cada tarefa reage a rodar de novo

O erro que quase todo mundo comete: testar só o caminho feliz

A automação é testada uma vez, funciona, vai pro ar. O teste do que acontece quando ela roda duas vezes seguidas com o mesmo dado fica de fora. Esse é o furo.

O teste que importa é o mais chato de fazer: pegar a mesma entrada, disparar duas vezes de propósito, e olhar se algo dobrou. Se dobrou, a tarefa não é idempotente e vai te morder em produção. Não é questão de "se", é de "quando", porque a rede vai engasgar em algum momento.

Tem um segundo erro, mais sutil, que é confiar que a plataforma resolve sozinha. Ferramentas de automação como n8n, Make e Zapier têm mecanismos de retry e alguns controles de deduplicação, mas nenhuma adivinha quais das suas tarefas são perigosas. A deduplicação delas costuma agir na entrada do fluxo, não no efeito final. Você ainda precisa dizer o que não pode repetir. A ferramenta te dá o interruptor; decidir que a tarefa de transferir dinheiro precisa dele é seu.

Uma automação que você não testou rodando duas vezes é uma automação que ainda não foi testada.

A régua: onde travar primeiro e onde deixar quieto

Blindar tudo é caro e desnecessário. Blindar nada é uma bomba-relógio. A decisão é por tarefa, e dá pra colocar número nela.

Pergunte, pra cada tarefa: "se essa rodar duas vezes hoje, quanto custa o erro?". Custo em dinheiro direto, em confiança do cliente, em retrabalho de alguém pra desfazer.

• Custo alto e irreversível (pagamento, cobrança, contrato assinado, SMS pago, chamada de API que fatura): idempotência obrigatória, com chave de idempotência. Sem exceção. Esse é o grupo onde um único incidente paga o trabalho de blindar todos.
• Custo médio, reversível com fricção (e-mail duplicado, lead repetido no CRM, agendamento em dobro): idempotência recomendada, verificação de estado ou trava resolvem. Dá pra desfazer, mas custa tempo e queima imagem, então vale prevenir.
• Custo baixo ou nulo (leitura, atualização de status que sobrescreve, log): deixa quieto. Investir aqui é gastar esforço onde não dói.

Se você tem trinta tarefas na sua operação automatizada, provavelmente cinco ou seis são do grupo alto. São essas que decidem se a automação dorme tranquila ou vira um problema de suporte. Comece por elas, na ordem do custo do erro, da mais cara pra menos.

E aqui entra a escolha de fundo, a mesma que a gente coloca na mesa em toda implementação. Dá pra comprar uma automação pronta e torcer pra quem montou ter pensado nisso. Dá pra construir do zero e cuidar de cada detalhe você mesmo, o que exige um dev e tempo que a maioria não tem. E dá pra implementar por dentro, com método e plataforma, onde a idempotência vem como parte do desenho e não como surpresa em produção, e a capacidade de manter isso fica na sua empresa em vez de num fornecedor. Essa terceira via pede um dono interno e uma rotina, mas é a única em que você entende o que roda na sua operação. Se quiser ver como isso se estrutura, os planos mostram o caminho.

Automação boa rodou de novo, sozinha, às 3h da manhã, e não cobrou ninguém duas vezes.

Relacionados

Agentes de IA: o guia completo

Soluções de IA prontas para empresas

Mais de 500 cases reais de IA

R$ 2,97 bi em IA no banco esbarra no sistema dos anos 90

O que é copiloto de IA: o assistente que trabalha ao lado do time