O que o Agente IA deve fazer quando CRM, agenda ou sistema de pagamento sai do ar?

Imagine que um cliente peça ao Agente IA da sua empresa para agendar uma reunião. O Agente coleta os dados, consulta a agenda e responde:

“Seu horário está confirmado para amanhã às 14h.”

O problema é que a agenda estava indisponível. Nenhuma reserva foi criada.

Em outro atendimento, o cliente solicita um link de pagamento. A integração demora mais do que o esperado, mas o Agente interpreta o silêncio do sistema como sucesso e informa que o pedido foi registrado.

Em um terceiro caso, o CRM sai do ar e o Agente tenta salvar o mesmo contato repetidamente. A conversa se prolonga, o cliente não entende o que está acontecendo e a equipe recebe vários registros duplicados quando o sistema volta.

Esses problemas afetam diretamente a confiança do cliente. Também podem gerar compromissos inexistentes, pagamentos duplicados, oportunidades perdidas e trabalho manual para corrigir informações inconsistentes.

Por isso, uma operação com Agentes IA não pode ser planejada apenas para o cenário em que todas as integrações funcionam. O comportamento durante uma falha precisa ser definido com o mesmo cuidado utilizado para projetar o atendimento normal.

Integrações vão falhar em algum momento

Um Agente conectado à operação da empresa depende de uma cadeia de serviços que não controla completamente.

O CRM pode ficar indisponível. A agenda pode demorar para responder. A API de pagamento pode retornar um erro temporário. Uma credencial pode expirar. Um sistema interno pode responder sem os dados necessários para comprovar que a ação foi concluída.

Quanto mais tarefas o Agente executa, maior é a importância de entender que ferramentas para resolver problemas de verdade também criam novas dependências operacionais.

A empresa precisa responder antecipadamente a quatro perguntas:

1. Como o Agente identifica que algo deu errado?

2. O que ele pode fazer enquanto o sistema está indisponível?

3. O que deve comunicar ao cliente?

4. Quando precisa interromper a automação e envolver uma pessoa?

A documentação de observabilidade de Agentes do Google Cloud apresenta logs, métricas e traces como sinais complementares para analisar o comportamento e a saúde de Agentes em produção.

A documentação de tracing do Agents SDK da OpenAI também descreve o registro de chamadas de modelos, ferramentas, guardrails, transferências entre Agentes e eventos personalizados.

Sem essas informações, a empresa pode enxergar apenas a mensagem enviada ao cliente. Ela não consegue verificar se o Agente realmente consultou a agenda, qual resposta recebeu do CRM ou em qual etapa a operação falhou.

A principal regra: não confirme o que não foi comprovado

A regra mais importante para lidar com integrações é simples:

O Agente não deve afirmar que uma ação aconteceu sem receber uma confirmação verificável do sistema responsável.

Enviar uma solicitação não significa que ela foi concluída.

Solicitar a criação de um contato não significa que ele foi salvo no CRM. Pedir uma reserva não significa que o horário foi bloqueado. Criar uma cobrança não significa que o pagamento foi aprovado. Encaminhar um pedido ao ERP não significa que o estoque foi atualizado.

Cada ação operacional precisa ter uma evidência de conclusão. Dependendo do sistema, essa evidência pode ser:

* um identificador de agendamento;

* um código de pedido;

* o número do contato criado no CRM;

* um status explícito de transação aprovada;

* uma resposta válida de sucesso;

* um evento posterior enviado pelo sistema responsável;

* a confirmação de que o novo estado foi persistido.

Quando essa evidência não existe, o estado correto não é “concluído”. A operação está pendente, não confirmada ou aguardando verificação.

Essa distinção evita uma das falhas mais perigosas em Agentes operacionais: transformar uma tentativa em uma confirmação.

Nem todo erro significa a mesma coisa

Um plano de contingência precisa distinguir os tipos de falha. Tratar todos os erros da mesma forma pode fazer o Agente repetir uma operação que já aconteceu ou desistir de uma solicitação que poderia ser recuperada.

Indisponibilidade explícita

O sistema retorna um erro claro, como serviço indisponível, credencial inválida, ausência de permissão ou limite de uso excedido.

Nesse caso, o Agente sabe que não recebeu uma confirmação válida. Ele não deve insistir indefinidamente. A resposta precisa seguir a alternativa prevista para aquela integração.

Tempo de resposta excedido

O Agente envia a solicitação, mas o sistema demora além do limite configurado.

Esse cenário exige cuidado porque a operação pode ter sido realizada, mesmo sem a resposta ter chegado. Repetir imediatamente a mesma solicitação pode gerar duplicidade.

O resultado deve ser tratado como incerto, e não automaticamente como falha ou sucesso.

Resposta inválida ou incompleta

A ferramenta responde, mas não entrega os campos necessários para comprovar a conclusão.

Uma agenda pode retornar um status genérico sem fornecer o identificador da reserva. Um CRM pode dizer que recebeu a solicitação sem informar se o contato foi criado. Um provedor de pagamentos pode responder que a transação está sendo processada.

A chamada terminou, mas a ação ainda não pode ser confirmada ao cliente.

Falha parcial

Uma parte da operação funciona e outra falha.

O pagamento pode ser aprovado, mas o pedido não ser registrado no sistema interno. O contato pode ser criado no CRM, mas a tarefa comercial não ser atribuída a um vendedor. A reserva pode ser feita, mas a mensagem de confirmação não ser enviada.

Executar todo o processo novamente pode duplicar a etapa que já funcionou. A recuperação precisa continuar a partir do ponto que falhou.

Dados possivelmente desatualizados

O sistema responde, mas a informação pode estar antiga por causa de atrasos de sincronização.

Esse risco aparece em consultas de estoque, disponibilidade, preços, limites de crédito, situação financeira e andamento de pedidos.

Quando a atualidade dos dados não pode ser garantida, o Agente precisa limitar a promessa que faz.

O que fazer quando o CRM fica indisponível

A indisponibilidade do CRM não precisa encerrar o atendimento.

O Agente ainda pode coletar nome, telefone, e-mail, empresa, necessidade, produto de interesse e outras informações relevantes. O que ele não deve fazer é afirmar que o cadastro foi concluído.

Uma política de contingência pode determinar que o Agente:

1. continue coletando os dados necessários;

2. armazene as informações temporariamente em uma fila segura;

3. registre que a sincronização com o CRM está pendente;

4. gere um protocolo interno para rastreamento;

5. tente sincronizar novamente quando o serviço retornar;

6. encaminhe o caso para revisão humana se o problema persistir.

A comunicação com o cliente pode ser direta:

“Recebi seus dados, mas nosso sistema de cadastro está temporariamente indisponível. Sua solicitação ficou registrada para processamento e nossa equipe dará continuidade assim que o acesso for restabelecido.”

Essa mensagem explica a situação sem expor detalhes técnicos desnecessários. Também evita confirmar que o contato já foi salvo no CRM.

Quando o sistema voltar, a recuperação não termina com o restabelecimento da conexão. A empresa precisa processar os registros acumulados, verificar duplicidades e confirmar que nenhuma oportunidade ficou parada.

Esse tipo de processamento posterior pode ser tratado como uma execução assíncrona, na qual a conversa termina sem que a tarefa operacional precise ser abandonada.

O que fazer quando a agenda não responde

Uma agenda indisponível exige uma política diferente porque existe risco de conflito entre horários.

Sem consultar a disponibilidade real, o Agente não deve prometer que determinado horário está livre. Ele pode coletar preferências, registrar uma solicitação ou sugerir períodos gerais com base nas regras conhecidas, mas não pode apresentar isso como reserva confirmada.

Uma resposta adequada seria:

“Não estou conseguindo confirmar a disponibilidade da agenda neste momento. Posso registrar sua preferência por amanhã às 14h e retornar com a confirmação assim que o sistema estiver disponível.”

Caso exista atendimento humano disponível, outra possibilidade é:

“A agenda está temporariamente indisponível. Vou encaminhar sua solicitação para que nossa equipe confirme o melhor horário com você.”

A operação precisa separar três estados:

Horário solicitado: o cliente informou sua preferência.

Horário em verificação: a solicitação foi registrada, mas a agenda ainda não confirmou.

Horário confirmado: existe uma reserva válida e identificável no sistema.

O Agente deve utilizar a palavra “confirmado” apenas no terceiro estado.

O que fazer quando o sistema de pagamento falha

Falhas de pagamento exigem limites mais rigorosos. Uma decisão incorreta pode gerar cobrança duplicada, liberação indevida de produtos ou divergências financeiras.

A empresa precisa separar ações que parecem semelhantes, mas representam etapas diferentes:

* o link de pagamento foi criado;

* o link foi enviado;

* o cliente iniciou o pagamento;

* a transação foi autorizada;

* o pagamento foi confirmado;

* o pedido foi liberado;

* o registro financeiro foi conciliado.

O Agente não deve tratar esses estados como equivalentes.

Se a criação do link falhar, ele pode informar que não conseguiu gerar a cobrança e oferecer uma nova tentativa posterior.

Se o resultado ficar indefinido depois que o cliente tentou pagar, o Agente não deve afirmar que houve aprovação. Também não deve pedir imediatamente que o cliente pague novamente.

A resposta mais segura é:

“Ainda não conseguimos confirmar o resultado da transação. Para evitar uma cobrança duplicada, seu pedido ficará em verificação até recebermos a confirmação do sistema de pagamento.”

A empresa também deve definir quais ações podem ser repetidas automaticamente e quais precisam de uma consulta prévia.

Por exemplo, antes de gerar uma nova cobrança, o sistema pode pesquisar se já existe uma transação com o mesmo pedido, cliente e valor. Outra proteção é usar uma chave única para que solicitações repetidas sejam reconhecidas como a mesma operação, em vez de criarem cobranças adicionais.

Quanto maior o impacto financeiro ou contratual, menor deve ser a liberdade do Agente para improvisar.

Tentar novamente nem sempre é a melhor resposta

Retentativas automáticas ajudam a recuperar erros temporários, mas precisam de limites.

Sem uma política definida, o Agente pode chamar a mesma integração várias vezes, aumentar a sobrecarga de um sistema instável e criar operações duplicadas.

Uma política de retentativa deve responder:

* Quantas novas tentativas são permitidas?

* Quanto tempo deve existir entre elas?

* Quais tipos de erro justificam outra tentativa?

* A operação pode ser repetida com segurança?

* Como verificar se a tentativa anterior foi concluída?

* Em qual momento o caso deve ser transferido para uma pessoa?

Uma consulta de disponibilidade pode admitir outra tentativa após alguns segundos. A criação de uma cobrança, pedido ou reserva exige mais cuidado, porque a primeira solicitação pode ter sido processada mesmo sem uma resposta conclusiva.

O intervalo entre tentativas também pode aumentar progressivamente. Em vez de chamar o sistema repetidamente, o Agente espera alguns segundos, tenta novamente e amplia a espera se a indisponibilidade continuar.

Quando o sistema apresenta uma sequência de falhas, a operação também pode suspender temporariamente novas chamadas. Isso impede que cada nova conversa continue pressionando uma integração que já está fora do ar.

O Agente não deve permanecer silencioso durante esse processo. Se a espera ultrapassar o limite aceitável, ele precisa explicar a situação e oferecer um próximo passo.

A comunicação da falha faz parte da experiência

Esconder detalhes técnicos do cliente é diferente de fingir que a operação ocorreu normalmente.

Uma boa mensagem de contingência informa:

* o que não foi possível confirmar;

* o que já foi registrado com segurança;

* o que acontecerá em seguida;

* se o cliente precisa fazer alguma coisa;

* quando uma nova comunicação pode ser esperada.

Considere a diferença entre estas mensagens:

“Seu pagamento foi concluído e seu pedido está confirmado.”

e:

“Recebemos sua solicitação, mas ainda não conseguimos confirmar o pagamento. Seu pedido permanecerá em análise até recebermos a resposta do sistema.”

A segunda resposta pode ser menos conveniente naquele momento, mas evita uma promessa incorreta.

A função Manage do NIST AI RMF Playbook recomenda que tratamentos de risco, planos de resposta, recuperação e comunicação sejam documentados e monitorados.

A estrutura AI RMF 1.0 do NIST também inclui monitoramento após a implantação, resposta a incidentes, recuperação, gestão de mudanças e comunicação de erros entre as práticas de gerenciamento de risco.

O objetivo não é fazer o Agente inventar uma solução durante o incidente. A empresa precisa preparar antecipadamente as opções que estarão disponíveis.

Quando o Agente deve chamar uma pessoa

A transferência para atendimento humano não deve acontecer apenas quando o Agente não sabe responder. Ela também é um mecanismo de segurança operacional.

O encaminhamento pode ser obrigatório quando:

* existe risco de cobrança duplicada;

* o resultado de uma transação está indefinido;

* um sistema crítico continua indisponível após as tentativas permitidas;

* existe divergência entre duas fontes;

* o cliente demonstra urgência;

* uma falha parcial precisa ser conciliada;

* a operação possui impacto jurídico, financeiro ou contratual;

* a alternativa automática também está indisponível;

* o cliente contesta uma confirmação anterior.

Esses critérios devem fazer parte da política de supervisão humana em Agentes IA.

O Agente também precisa transferir o contexto completo. O atendente deve receber:

* os dados já coletados;

* as ferramentas acionadas;

* os erros retornados;

* as tentativas realizadas;

* os identificadores obtidos;

* o estado atual da solicitação;

* o que já foi comunicado ao cliente.

Enviar o cliente para uma pessoa sem esse contexto transforma uma medida de segurança em uma nova frustração.

O que precisa ser monitorado

Não é possível melhorar o comportamento diante de falhas sem medir o que acontece.

Para cada ferramenta utilizada pelo Agente, a empresa deve acompanhar pelo menos:

* quantidade de chamadas;

* taxa de sucesso e erro;

* tempo médio de resposta;

* percentis de latência;

* quantidade de timeouts;

* erros por categoria;

* número de retentativas;

* operações com resultado indefinido;

* transferências causadas por falha;

* solicitações acumuladas para processamento posterior;

* tempo necessário para recuperação;

* mensagens enviadas aos clientes durante o incidente.

A visão geral de observabilidade da Gemini Enterprise Agent Platform destaca o acompanhamento do desempenho, do comportamento, da saúde dos Agentes e dos caminhos de execução.

Logs mostram eventos e erros. Métricas ajudam a identificar tendências de volume, latência e taxa de falhas. Traces permitem reconstruir o caminho de uma execução e entender como uma chamada afetou as etapas seguintes.

Esses dados complementam as métricas além do tempo de resposta utilizadas para avaliar se o Agente está funcionando de maneira adequada.

Os registros também precisam proteger informações sensíveis. Entradas e saídas de modelos e ferramentas podem conter dados pessoais, informações financeiras e conteúdo confidencial. O nível de detalhe coletado deve permitir investigação sem transformar a observabilidade em um novo risco.

Crie uma matriz de contingência para cada integração

A maneira mais prática de transformar essas orientações em operação é criar uma matriz de contingência.

Para cada sistema utilizado pelo Agente, documente:

| Item | Pergunta que precisa ser respondida |

| --- | --- |

| Sistema | De qual integração o atendimento depende? |

| Ação executada | O que o Agente tenta fazer nesse sistema? |

| Evidência de sucesso | Qual retorno comprova que a ação aconteceu? |

| Tipos de falha | Quais erros, timeouts ou respostas incompletas podem ocorrer? |

| Estado incerto | Como identificar uma operação que pode ter sido concluída sem confirmação? |

| Retentativa | A ação pode ser repetida? Quantas vezes e em quais condições? |

| Proteção contra duplicidade | Como impedir que a mesma operação seja criada novamente? |

| Alternativa | Existe fila, armazenamento temporário ou processo manual? |

| Comunicação | O que o Agente deve dizer ao cliente? |

| Limite | O que ele está proibido de confirmar? |

| Escalonamento | Quando uma pessoa precisa assumir? |

| Recuperação | O que deve ser processado depois que o sistema voltar? |

| Monitoramento | Quais métricas e alertas precisam existir? |

| Responsável | Quem acompanha a falha e valida a recuperação? |

Essa matriz transforma uma orientação genérica como “se der erro, avise o cliente” em regras específicas e testáveis.

Teste as falhas antes que elas aconteçam

O plano de contingência não pode existir apenas em um documento. Ele precisa ser testado.

Em um ambiente controlado:

1. desative temporariamente uma integração;

2. simule um timeout;

3. retorne uma resposta incompleta;

4. faça uma operação concluir parcialmente;

5. simule a volta do sistema;

6. verifique como os registros pendentes são recuperados;

7. confirme se o atendimento humano recebe o contexto necessário.

O teste precisa avaliar tanto o sistema quanto a conversa. Uma integração pode falhar tecnicamente e, ainda assim, o Agente se comportar bem. Também pode ocorrer o contrário: a aplicação detecta o erro corretamente, mas envia uma mensagem enganosa ao cliente.

O guia de resposta a incidentes NIST SP 800-61r3 organiza a preparação e o tratamento de incidentes em torno das funções de governar, identificar, proteger, detectar, responder e recuperar. O documento também reforça o aprendizado contínuo a partir dos incidentes.

Cada falha relevante deve gerar uma revisão:

* O erro foi detectado no momento correto?

* O Agente fez alguma promessa incorreta?

* Houve duplicidade?

* A mensagem ao cliente foi clara?

* O caso chegou à pessoa certa?

* O trabalho acumulado foi processado?

* Alguma regra, teste ou alerta precisa ser criado?

Esses cenários devem integrar o processo usado para testar um Agente IA antes do atendimento real e também permanecer nos testes contínuos depois da implantação.

Confiabilidade não significa nunca falhar

Um Agente confiável não é aquele que nunca encontra erros.

É aquele que reconhece quando uma integração não respondeu, não transforma incerteza em confirmação, oferece alternativas coerentes e permite que a empresa reconstrua o que aconteceu.

Quando CRM, agenda, pagamento ou qualquer outro sistema externo fica indisponível, o comportamento do Agente não pode depender de improviso. A mensagem, a alternativa, o limite de autonomia e o processo de recuperação devem ter sido definidos antes do incidente.

Liste os sistemas dos quais o seu atendimento depende e documente o que deve acontecer quando cada um deles falhar.

Esse exercício pode revelar que algumas das integrações mais importantes da operação ainda não possuem uma alternativa segura.