Plano de contingência para agentes de IA

Quando o agente para, o processo precisa continuar legível

Um agente pode deixar de operar porque o modelo ficou indisponível, uma credencial expirou, o CRM recusou gravações, a fila travou ou a fonte necessária não respondeu. Também pode ser suspenso pela própria empresa após detectar uma saída inadequada.

Em qualquer desses cenários, a pergunta operacional é a mesma: como o trabalho continua sem perder prioridade, estado e evidência?

Um plano de contingência para agentes de IA define a resposta antes da falha. Ele indica quais serviços devem continuar, em que nível, quem assume, onde as demandas serão registradas e como reconciliar o período quando a automação voltar.

Desligar o agente resolve apenas a interrupção técnica. Sem um caminho alternativo, a empresa troca risco automatizado por backlog invisível.

Contingência, incidente e recuperação têm funções diferentes

Os três temas se relacionam, mas organizam decisões distintas.

Resposta a incidente contém e investiga

Quando existe dano ou risco relevante, a prioridade é interromper propagação, preservar evidências, avaliar impacto e corrigir a causa.

O plano de resposta a incidentes de IA cobre classificação, contenção, investigação, comunicação e autorização de retomada.

Contingência mantém o serviço possível

Durante a indisponibilidade, a empresa precisa receber novas demandas, priorizar casos, preservar registros e atender o que não pode esperar. A contingência define esse modo temporário de operação.

Recuperação restaura e reconcilia

Depois que a capacidade técnica volta, ainda existem filas, ações manuais, casos parcialmente executados e estados divergentes. Recuperar significa retomar por etapas e reconciliar o trabalho feito durante a interrupção.

Uma operação pode acionar contingência sem incidente. Uma manutenção programada ou falha de fornecedor pode reduzir o serviço sem causar dano. Também pode responder a um incidente sem desligar tudo, mantendo partes seguras em modo limitado.

Mapeie o serviço operacional, não apenas o agente

O plano deve começar pela unidade de trabalho que a empresa precisa preservar.

Exemplos:

solicitação de cliente recebida e encaminhada;
oportunidade comercial registrada com próxima ação;
documento crítico conferido antes do prazo;
pedido validado e enviado para separação;
obrigação financeira preparada para aprovação;
reunião confirmada com contexto disponível.

Para cada serviço, registre:

evento de entrada;
volume normal e picos;
prazo por classe;
fontes essenciais;
sistemas conectados;
ações que o agente executa;
decisões humanas necessárias;
condição de conclusão;
consequência do atraso;
capacidade mínima aceitável.

Esse recorte evita um plano centrado em servidores. O objetivo de continuidade não é manter uma aplicação com luz verde. É preservar trabalho empresarial dentro de limites conhecidos.

Identifique dependências e modos de falha

Um agente em produção depende de uma cadeia. O modelo é apenas uma parte.

Entrada

E-mail, formulário, WhatsApp, evento de sistema, arquivo ou tarefa agendada podem parar de chegar.

Identidade e acesso

Tokens expiram, permissões mudam, contas são bloqueadas e cofres deixam de responder.

Contexto e memória

A base de conhecimento pode ficar indisponível, atrasada ou inconsistente. O agente pode perder o estado de uma tarefa em andamento.

Modelo e orquestração

O provedor pode falhar, aumentar latência, impor limite ou devolver erro. O workflow pode travar entre etapas.

Ferramentas

CRM, ERP, agenda, pagamento e armazenamento possuem disponibilidade própria. Uma chamada pode retornar timeout depois de executar a ação.

Aprovação humana

A fila técnica funciona, mas ninguém com alçada está disponível. O trabalho preparado se acumula.

Registro e observabilidade

O processo pode executar sem conseguir gravar evidência, atualizar o estado ou emitir alerta. Continuar nesse cenário pode ser mais perigoso do que parar.

Para cada dependência, pergunte como detectar falha, qual serviço é afetado, que alternativa existe e por quanto tempo a operação consegue funcionar assim.

Defina modos degradados em vez de um único botão

A escolha entre “ligado” e “desligado” costuma ser grosseira. Modos degradados preservam partes seguras do serviço.

Somente leitura

O agente consulta fontes e prepara análise, mas não altera sistemas nem envia mensagens. Funciona quando a camada de decisão está disponível e a escrita perdeu confiabilidade.

Preparação sem execução

O agente organiza casos, rascunha respostas e produz pacotes para revisão. Pessoas autorizadas executam a ação pelo sistema oficial.

Fonte reduzida

O processo continua apenas para casos que podem ser resolvidos com fontes confirmadas. Demandas dependentes da fonte indisponível ficam pendentes ou seguem para análise humana.

Escopo restrito

A operação aceita categorias de baixo risco e bloqueia exceções, valores altos, dados sensíveis ou ações irreversíveis.

Fila preservada

Novas entradas são armazenadas com identificador, horário e prioridade, sem processamento. O objetivo é evitar perda enquanto a capacidade está indisponível.

Operação manual priorizada

A equipe assume somente casos críticos ou próximos do vencimento. As demais classes recebem comunicação e permanecem em fila.

Cada modo precisa de condição de entrada, autoridade para ativar, limite de duração e critério de saída. Sem isso, a operação degradada pode virar o novo normal sem controle.

Calcule a capacidade humana de contingência

“Transferir para a equipe” não basta quando o agente trata um volume muito maior do que as pessoas conseguem absorver.

Meça:

entradas por hora ou dia;
tempo humano por unidade;
pessoas disponíveis;
cobertura por horário;
volume já pendente;
classes que não podem esperar;
tempo máximo tolerável de backlog.

Considere um agente que prepara 300 solicitações por dia. A equipe consegue processar manualmente 40. O plano precisa escolher quais 40 entram, como as outras 260 ficam registradas e que mensagem será enviada aos públicos afetados.

A capacidade de contingência pode ser ampliada com formulários mais restritos, modelos de resposta aprovados, checklists, divisão de fila e suspensão temporária de serviços secundários. Ainda assim, a prioridade precisa ser explícita.

Crie classes de prioridade observáveis

A classificação deve usar sinais que a equipe e o sistema consigam verificar.

Crítica

Risco para pessoa, dado, dinheiro, contrato, segurança, continuidade ou prazo irreversível. Recebe atenção imediata e dono nomeado.

Prioritária

Impacto comercial ou operacional relevante, cliente bloqueado, vencimento próximo ou dependência de outra atividade. Entra na capacidade manual disponível antes da rotina.

Rotina

Demanda reversível, com prazo maior e alternativa de espera. Pode permanecer em fila com comunicação adequada.

Suspensa

Serviço que depende integralmente da capacidade indisponível ou cujo risco supera o benefício de continuar. Novas entradas podem ser bloqueadas temporariamente.

Evite permitir que qualquer usuário marque tudo como urgente. Valor, prazo, tipo de dado, efeito no cliente e possibilidade de reversão oferecem critérios melhores.

O artigo sobre como definir SLA para agentes de IA ajuda a ligar classes, prazos, qualidade e continuidade ao processo completo.

Preserve entrada, estado e evidência

A contingência falha quando a empresa mantém o atendimento, mas perde o registro necessário para retomar.

Cada caso precisa conservar:

identificador único;
horário de entrada;
origem;
cliente ou objeto relacionado;
categoria e prioridade;
dados mínimos recebidos;
última etapa confirmada;
ação tentada;
resultado conhecido;
decisão manual;
responsável;
próxima ação;
prazo;
status de reconciliação.

Use uma fila ou sistema acessível durante a falha principal. Uma planilha controlada pode servir em operação pequena, desde que tenha acesso delimitado, campos obrigatórios, histórico e responsável. Para volumes maiores, uma fila durável ou módulo específico reduz perda e duplicidade.

Mensagens soltas em um grupo não formam uma fila. Elas não garantem identificador, prioridade, estado nem conclusão.

Evite duplicidade durante falhas ambíguas

O cenário mais perigoso nem sempre é o erro explícito. Pode ser um timeout depois de a ação ter ocorrido.

Antes de repetir:

consulte o sistema de destino;
procure o identificador da tentativa;
compare o estado anterior e o atual;
confirme se houve efeito externo;
encaminhe para revisão quando a situação continuar incerta.

A arquitetura deve usar chaves de idempotência quando o sistema oferece suporte. Também deve preservar o identificador da unidade entre agente, fila, integração e sistema oficial.

Se a equipe envia manualmente uma mensagem durante a contingência, o caso precisa receber marcação que impeça o agente de repetir o envio quando voltar.

Defina papéis e alçadas

Um plano executável nomeia responsabilidades.

Dono do processo

Decide prioridade, nível mínimo de serviço, suspensão de atividades e retorno operacional.

Responsável técnico

Diagnostica dependências, ativa controles, preserva filas e restaura componentes.

Coordenador da contingência

Mantém quadro de situação, distribui tarefas, registra decisões e atualiza os envolvidos.

Operadores manuais

Assumem as unidades priorizadas usando procedimento e sistema definidos.

Aprovadores

Tratam decisões que continuam exigindo alçada, mesmo durante a falha.

Comunicação

Informa equipe, clientes ou parceiros quando atraso, canal ou expectativa precisa mudar.

Em empresas menores, uma pessoa pode acumular papéis. O plano ainda deve dizer quem decide cada coisa e quem substitui essa pessoa.

Prepare um runbook curto e acionável

Durante a falha, ninguém deveria procurar instruções em uma apresentação extensa.

O runbook precisa responder:

como reconhecer a condição;
quem deve ser avisado;
quem pode declarar contingência;
qual modo degradado ativar;
como interromper ações perigosas;
onde registrar novas demandas;
como classificar prioridades;
quem assume cada fila;
que comunicação usar;
como acompanhar backlog e prazo;
quais evidências preservar;
quem autoriza a retomada;
como reconciliar o período.

Inclua links diretos para painéis, filas, contatos, procedimentos e controles. Registre a data do último teste. Um runbook que depende de senha desconhecida ou documento sem permissão falha antes de começar.

Planeje a comunicação operacional

A equipe precisa saber o que mudou e como agir.

Uma atualização interna deve informar:

serviço afetado;
horário conhecido;
modo de operação atual;
atividades suspensas;
fila ou canal temporário;
prioridades;
responsável pela coordenação;
horário da próxima atualização.

A comunicação externa depende do impacto e das obrigações aplicáveis. Use fatos confirmados, expectativa realista e orientação clara. Evite prometer prazo antes de entender a capacidade de recuperação.

Quando o agente atende clientes, desative respostas automáticas que afirmem normalidade. A mensagem temporária deve refletir o serviço realmente disponível.

Reconcilie antes de liberar a fila inteira

O retorno técnico não encerra a contingência.

Durante a interrupção, pessoas podem ter atualizado sistemas, enviado mensagens, aprovado exceções e criado registros temporários. O agente também pode ter deixado tarefas em estados intermediários.

A reconciliação precisa:

congelar novas execuções durante a comparação;
exportar a fila pendente;
identificar ações manuais concluídas;
consultar o estado atual no sistema oficial;
eliminar duplicidades;
corrigir registros divergentes;
reprocessar somente casos seguros;
priorizar itens vencidos ou críticos;
confirmar resultados no destino;
encerrar marcações temporárias;
registrar perdas, atrasos e correções.

Retome por lote ou classe. Liberar todo o backlog de uma vez pode derrubar novamente integrações, consumir limites e enviar comunicações atrasadas fora de contexto.

O guia sobre agentes de IA para tarefas longas explica como checkpoints e retomada segura preservam o estado entre etapas.

Teste o plano antes de precisar dele

Um teste de mesa reúne os responsáveis e apresenta um cenário. A equipe percorre decisões, acessos, comunicação e retorno sem interromper a produção.

Depois, faça exercícios controlados:

bloquear a escrita no CRM;
expirar uma credencial de teste;
simular indisponibilidade do modelo;
pausar uma fonte de conhecimento;
retirar um aprovador;
acumular uma fila limitada;
executar reconciliação com ações manuais fictícias.

Observe:

tempo até detecção;
tempo até ativação;
clareza dos papéis;
acesso aos recursos alternativos;
capacidade manual real;
perda ou duplicidade;
qualidade da comunicação;
tempo de reconciliação;
decisões que dependeram de improviso.

Corrija o plano depois de cada exercício e mudança relevante na arquitetura. Nova integração, novo fornecedor, aumento de volume ou ampliação de autonomia alteram a contingência.

Métricas para continuidade

Acompanhe indicadores que ajudem a melhorar o desenho:

tempo para detectar indisponibilidade;
tempo para ativar o modo degradado;
percentual de entradas preservadas;
capacidade manual por classe;
backlog máximo;
casos vencidos durante a contingência;
duplicidades e perdas;
tempo para restaurar o serviço;
tempo para reconciliar a fila;
correções após retomada;
incidentes causados pela própria contingência;
data e resultado do último teste.

Uma média geral pode esconder a classe crítica. Separe resultados por processo, prioridade e modo de falha.

Checklist do plano de contingência

Antes de colocar um agente em um processo relevante, confirme:

[ ] a unidade de trabalho está definida;
[ ] dependências técnicas e humanas foram mapeadas;
[ ] existe detecção para falhas importantes;
[ ] modos degradados possuem critérios de entrada e saída;
[ ] a capacidade manual foi medida;
[ ] prioridades usam sinais observáveis;
[ ] entradas recebem identificador e estado preservado;
[ ] ações manuais ficam registradas;
[ ] retentativas evitam duplicidade;
[ ] papéis, substitutos e alçadas estão definidos;
[ ] o runbook está acessível;
[ ] mensagens temporárias refletem o serviço real;
[ ] a reconciliação possui sequência e responsável;
[ ] a retomada acontece por etapas;
[ ] o plano foi testado;
[ ] mudanças na arquitetura disparam revisão.

Continuidade também faz parte da arquitetura

Agentes aumentam capacidade quando entram em processos reais. Quanto maior a dependência, maior a necessidade de uma alternativa operacional conhecida.

O plano de contingência preserva entrada, prioridade, responsabilidade e registro durante a falha. Ele também impede que a retomada transforme backlog em duplicidade. Com modos degradados, capacidade medida, fila durável e reconciliação, a empresa consegue reduzir serviço sem perder o controle do trabalho.

A automação madura inclui a forma de operar quando a automação não está disponível. Sem essa camada, eficiência aparente vira fragilidade acumulada.