Agente de IA errou. Quem corrige com o cliente?

O prompt foi corrigido. O cliente, ainda não.

Um agente confirma um cancelamento. O sistema não cancela. Ou aplica uma condição antiga. Ou manda a mensagem certa para a pessoa errada.

Alguém encontra a causa, muda a regra e testa a nova versão. O time respira. A próxima conversa parece correta.

Só que o cliente anterior continua com uma confirmação falsa. Talvez existam outros. Corrigir a versão evita repetição; não desfaz o que já aconteceu.

Quando um agente de IA erra, a operação precisa fechar três histórias: o comportamento do agente, o estado nos sistemas e a expectativa criada para cada cliente afetado. Se uma delas fica aberta, o incidente só mudou de tela.

Resposta curta

Depois de encontrar um erro de agente:

1. contenha a ação afetada sem derrubar o que ainda é seguro;
2. preserve versão, regra, ferramenta, período e identificadores;
3. localize conversas e ações potencialmente atingidas;
4. confirme o estado no sistema responsável;
5. classifique o impacto de cada caso;
6. corrija primeiro o estado, quando isso for seguro e autorizado;
7. fale com o cliente com fato, efeito, ação, dono e prazo;
8. registre a confirmação ou contestação recebida;
9. ligue o caso à mudança de regra, ferramenta, permissão ou QA;
10. só encerre quando passado e futuro estiverem tratados.

O registro de correção de erro do agente de IA organiza esse trabalho numa página copiável. Se foram cinco casos e uma pessoa consegue conferir cada sistema, uma planilha protegida resolve. O luxo começa depois; a responsabilidade começa agora.

Nem todo erro pede a mesma resposta

Antes de escrever para o cliente, descubra o que aconteceu de verdade.

Tipo de erro	Exemplo	Primeira ação
resposta sem efeito	agente disse “cancelado”, mas nada mudou	parar a confirmação e consultar o sistema responsável
efeito sem resposta	agenda mudou, mas o agente informou falha	reconciliar antes de repetir ou desfazer
efeito errado	cadastro, valor ou horário foi alterado incorretamente	conter ações semelhantes e avaliar correção autorizada
exposição indevida	mensagem revelou dado para pessoa errada	restringir acesso, preservar evidência e acionar segurança e privacidade
regra errada	condição antiga foi aplicada a vários clientes	delimitar versão, período, intenção e população afetada
destino errado	handoff ou mensagem foi para fila ou contato incorreto	bloquear a rota e localizar o que ficou sem dono
orientação ruim sem ação	agente deu instrução incorreta, mas não alterou sistema	corrigir informação e verificar se o cliente agiu com base nela

“Foi só uma resposta” pode ser uma avaliação errada. Uma orientação sem chamada de ferramenta ainda pode criar deslocamento, pagamento, perda de prazo ou decisão ruim.

Primeiro contenha. Depois discuta a causa inteira.

O NIST SP 800-61 Rev. 3 trata resposta e recuperação como partes de uma capacidade contínua de gestão de incidentes. A tradução prática para agente é simples: enquanto a análise acontece, a mesma rota não pode continuar produzindo o mesmo dano.

A contenção pode ser pequena:

• desativar apenas a ação de cancelamento;
• manter consulta e bloquear escrita;
• trocar confirmação automática por fila humana;
• retirar uma fonte desatualizada;
• limitar uma versão a zero novas conversas;
• suspender um destinatário ou canal;
• reduzir permissão da ferramenta;
• exigir aprovação para um tipo de efeito.

Não pause tudo por reflexo. Também não deixe uma rota lateral aberta. O guia Quando pausar um agente de IA em produção ajuda a definir alcance, modo degradado e retomada.

Delimite o alcance sem procurar pelo texto do erro

Buscar a frase errada nas transcrições encontra parte do problema. O mesmo comportamento pode ter produzido textos diferentes.

Procure por sinais estruturais:

• versão do agente;
• versão da regra ou fonte;
• ferramenta e operação chamadas;
• período entre publicação e contenção;
• intenção classificada;
• canal, fila ou campanha;
• aprovação usada;
• status gravado no CRM;
• identificador da tentativa;
• retorno técnico ou timeout;
• mensagem final enviada;
• revisão de QA que detectou o caso.

Defina duas listas:

1. casos confirmados: há evidência de resposta ou ação incorreta;
2. casos potencialmente afetados: passaram pela combinação de versão, regra, ferramenta e período, mas ainda precisam de conferência.

Não comunique hipótese como fato. Também não use a incerteza como desculpa para esperar a lista perfeita enquanto o cliente continua com o estado errado.

O sistema responsável decide o que precisa ser corrigido

A conversa mostra o que foi prometido. O CRM mostra parte do histórico. A ferramenta pode mostrar uma tentativa. O estado verdadeiro costuma morar no sistema que responde pela ação.

Ação	Fonte de confirmação provável
agendamento	agenda ou sistema de reservas
cobrança ou reembolso	sistema financeiro ou adquirente
cancelamento	sistema contratual ou de pedidos
cadastro	base responsável pelo dado
envio	provedor do canal e registro de entrega
acesso	diretório ou sistema de identidade
handoff	fila de destino e registro de assunção

Para cada caso, registre:

• o que o agente afirmou;
• o que a ferramenta tentou;
• o que o sistema confirma agora;
• qual diferença precisa ser corrigida;
• se a correção é reversível;
• quem tem autoridade;
• qual prova ficará depois.

O rastro de execução do agente ajuda quando conversa, aprovação, ferramenta e estado não fecham a mesma história.

Corrigir no sistema e corrigir com o cliente são trabalhos diferentes

Imagine que o agente marcou quinta, mas disse terça.

A operação pode:

• ajustar a agenda para terça;
• manter quinta e corrigir a mensagem;
• pedir nova escolha ao cliente;
• cancelar uma duplicidade;
• passar o caso para uma pessoa.

A decisão depende do pedido original, da disponibilidade atual, do efeito criado e da autoridade para alterar. Não deixe o agente escolher sozinho a correção apenas porque ele produziu o erro.

Separe dois donos:

• dono do estado: corrige ou confirma agenda, cobrança, cadastro, pedido ou acesso;
• dono do contato: explica o que aconteceu, confirma a solução e registra a resposta do cliente.

Podem ser a mesma pessoa num piloto pequeno. As responsabilidades continuam diferentes.

Uma mensagem de correção precisa de cinco peças

A resposta não precisa dramatizar. Precisa ser verificável.

1. fato: qual informação ou ação estava incorreta;
2. efeito: o que mudou ou não mudou de verdade;
3. correção: o que já foi feito e o que ainda falta;
4. dono e prazo: quem acompanha e quando retorna;
5. confirmação: o que o cliente precisa validar ou pode contestar.

Exemplo quando o sistema não executou:

Na mensagem anterior, informamos que seu cancelamento estava concluído. Conferimos o sistema e o cancelamento não tinha sido efetivado. O pedido foi corrigido agora sob o protocolo 8472, sem nova cobrança. Vou acompanhar por este canal até você confirmar que ficou certo.

Exemplo quando o estado continua incerto:

A confirmação enviada antes não é suficiente para provar a alteração. Suspendemos uma nova tentativa para evitar duplicidade e estamos conferindo o estado no sistema responsável. Retorno até 15h pelo protocolo 8472. Você não precisa repetir o pedido.

Exemplo quando o cliente precisa decidir:

O agente registrou quinta, mas informou terça na conversa. Os dois horários ainda estão disponíveis. Antes de alterar novamente, preciso que você confirme qual prefere. Depois da sua resposta, uma pessoa fará a mudança e enviará o protocolo.

Evite:

• “houve uma inconsistência” sem dizer qual;
• culpar “a IA” como se ninguém operasse o serviço;
• declarar resolvido antes de consultar o sistema;
• pedir todos os dados outra vez quando o protocolo basta;
• prometer prazo que a fila não consegue cumprir;
• colocar detalhe técnico ou dado de outra pessoa na mensagem;
• oferecer compensação sem autoridade definida.

Fluxo para corrigir sem deixar o passado para trás

Um quadro simples para priorizar contato

Nem sempre dá para falar com todos ao mesmo tempo. Priorize pela combinação de efeito e urgência, não pela ordem em que a conversa apareceu no dashboard.

Prioridade	Situação	Tratamento inicial
imediata	risco financeiro, acesso, privacidade, saúde, segurança ou prazo crítico	conter, escalar para responsáveis e tratar comunicação formal conforme política
alta	ação errada já confirmada ou promessa que vence em horas	corrigir estado e contatar no mesmo turno
média	informação errada que pode orientar decisão, mas sem efeito confirmado	verificar e corrigir com prazo definido
monitorada	caso passou pela versão afetada, sem evidência de erro	revisar por lote e manter dono até descartar impacto

Esta tabela organiza operação. Não substitui avaliação jurídica, de segurança ou privacidade. Se houve dado exposto, fraude, obrigação regulatória ou dano relevante, o fluxo precisa envolver as funções responsáveis antes de uma mensagem improvisada.

Não apague o erro para deixar o histórico bonito

A correção precisa preservar:

• mensagem original;
• horário da detecção;
• versão e regra envolvidas;
• estado antes e depois;
• ação corretiva;
• pessoa que autorizou;
• contato enviado;
• resposta do cliente;
• compensação, quando houver;
• teste e mudança que encerraram a causa.

Isso não significa guardar dado sensível sem limite. A OWASP recomenda registros estruturados e alerta contra dados sensíveis em texto aberto. Guarde referência, categoria, versão e resultado quando forem suficientes. Restrinja conteúdo detalhado, retenção e acesso conforme a necessidade real.

O caso só fecha depois da confirmação

Marcar uma tarefa como concluída não prova que o cliente voltou ao estado correto.

Use critérios de fechamento:

• a rota de erro foi contida;
• o alcance foi pesquisado e documentado;
• cada caso confirmado tem estado final;
• a ação errada foi corrigida, revertida ou assumida por um dono;
• o cliente recebeu informação compatível com o sistema;
• contestação ou ausência de resposta tem próximo passo;
• a causa entrou em regra, ferramenta, permissão, teste ou QA;
• a retomada começou numa amostra verificável;
• ninguém depende da memória do grupo para reconstruir o caso.

O NIST AI RMF Playbook é voluntário e não é uma lista para seguir inteira. O mecanismo útil aqui é manter governança, contexto, medição e gestão ligados. Traduzindo: alguém responde, o alcance aparece, o resultado é conferido e a operação muda.

Quando uma planilha basta

O caminho simples funciona quando:

• há poucos casos confirmados;
• uma versão e uma ferramenta estão envolvidas;
• o estado pode ser consultado manualmente;
• uma pessoa consegue corrigir e contatar no mesmo turno;
• o acesso ao registro é controlado;
• cada caso recebe protocolo e dono;
• a retomada pode esperar a revisão completa.

Use o registro de correção, confira caso por caso e revise a mensagem antes do envio. Não compre software para evitar a conversa que a operação precisa ter.

Onde o caminho manual quebra

A planilha perde força quando:

• milhares de conversas passaram pela versão afetada;
• vários agentes, canais e ferramentas produziram ações encadeadas;
• voz, WhatsApp, CRM e sistemas responsáveis guardam IDs separados;
• o erro pode continuar enquanto o alcance é investigado;
• clientes precisam de tratamentos diferentes por estado e risco;
• correções exigem autoridade, aprovação ou compensação;
• segurança, privacidade e jurídico precisam trabalhar sobre a mesma evidência;
• QA não consegue ligar incidente, contato, resposta e mudança de regra;
• ninguém sabe quais casos já foram fechados de verdade.

Aí correção deixa de ser mutirão. Vira parte da operação supervisionada: contenção, reconciliação, contato, evidência, QA e melhoria contínua.

É nesse cenário que uma camada de gestão de agentes em produção pode fazer sentido. Antes disso, escolha um erro real, preencha o registro e tente responder uma pergunta bastante pouco tecnológica: quem ficou com a consequência e quem voltou para resolver?

O teste desta semana

Pegue o último erro conhecido de um agente, bot ou automação.

Esconda a correção técnica e olhe apenas para as pessoas afetadas. A equipe consegue dizer quem recebeu a mensagem, qual estado ficou no sistema, quem fez a correção e se o cliente confirmou?

Depois faça o contrário: esconda as conversas e olhe os sistemas. A equipe consegue localizar a promessa errada e ligar o efeito à versão que a produziu?

Se nenhuma visão fecha o caso, o erro ainda está aberto. Mesmo que o ticket diga outra coisa.

Vídeo

Eu não encontrei um vídeo em português que eu usaria como resposta principal para esta rotina. Há material sobre incidentes, observabilidade e desculpas ao cliente. Pouco começa numa ação errada de agente e acompanha contenção, alcance, estado, correção, contato e mudança de regra até o fim.

Se bastante gente pedir, este assunto entra na fila de gravação. Não é promessa.