O agente funciona até uma dependência parar
Uma empresa coloca um agente de IA para ler solicitações, consultar o histórico do cliente, preparar uma recomendação e atualizar um sistema de negócio. O piloto funciona, e o fluxo passa a fazer parte da operação diária. Então o provedor do modelo fica lento, a API do CRM começa a devolver erros ou o índice de documentos fica desatualizado. O agente permanece disponível, mas o processo já não entrega um resultado confiável.
Continuidade não pode depender da esperança de que todos os componentes estarão disponíveis ao mesmo tempo. Gestores precisam definir qual trabalho deve continuar, qual pode esperar, quando o processo pode usar uma alternativa limitada e quando o controle precisa voltar para uma pessoa.
Mapeie o serviço mínimo antes de escolher a contingência
Comece pelo resultado de negócio, não pela tecnologia. Identifique o serviço mínimo que ainda protege clientes, prazos e obrigações regulatórias. Em uma operação de atendimento, esse mínimo pode ser receber a solicitação, emitir um protocolo e preservar o conteúdo original, mesmo que classificação e elaboração da resposta fiquem temporariamente indisponíveis.
Separe dependências críticas das que apenas enriquecem o resultado. O identificador do cliente pode ser essencial, enquanto uma sugestão de tom para a resposta pode ser opcional. Registre também a interrupção máxima aceitável, o volume que pode se acumular e quem decide se a operação degradada continua aceitável.
O playbook do NIST AI Risk Management Framework recomenda planos pós-implantação que incluam monitoramento, possibilidade de intervenção, resposta a incidentes, recuperação e gestão de mudanças. Também orienta considerar alternativas não baseadas em IA ou semiautomatizadas. Assim, continuidade vira uma decisão de gestão, não um remendo técnico improvisado.
Use quatro respostas controladas em vez de repetir sem limite
Um fluxo resiliente costuma combinar quatro respostas. Primeiro, falhar rapidamente quando uma dependência está claramente indisponível, para não ocupar recursos esperando um resultado que não virá. Segundo, repetir apenas falhas transitórias, com limite, intervalo e um orçamento compartilhado pelo serviço. Terceiro, colocar o trabalho elegível em uma fila durável com identificador, horário, prioridade e estado atual. Quarto, encaminhar casos críticos ou vencidos para uma rota de recuperação manual com o contexto já coletado.
As novas tentativas merecem atenção especial. A orientação de Google SRE mostra como repetições em várias camadas podem multiplicar uma solicitação em muitas chamadas e agravar uma indisponibilidade. A regra prática é diferenciar erros temporários dos permanentes, limitar tentativas e impedir que cada camada repita de forma independente a mesma ação que falhou.
Um modelo alternativo ou uma API secundária pode ajudar, mas não é automaticamente equivalente. Defina quais tarefas essa alternativa pode realizar, qual limite de qualidade vale e quais ações continuam bloqueadas. Se a opção de contingência produz um resultado mais restrito, a interface e os sistemas seguintes devem marcar esse estado de maneira explícita.
Preserve o estado para a recuperação não duplicar ações
Cada execução interrompida precisa de um estado durável. Registre o identificador do caso de negócio, as etapas concluídas, versões das entradas, respostas das ferramentas, aprovações e a ação pendente. A recuperação deve continuar de um ponto conhecido, em vez de refazer todo o fluxo.
Use chaves de idempotência ou controles equivalentes em ações como criar pedido, enviar mensagem ou alterar cadastro. Antes de repetir uma gravação, verifique se o resultado pretendido já existe. Um plano de continuidade que restaura a disponibilidade, mas duplica uma ação financeira ou voltada ao cliente, cria um segundo incidente.
Exemplo hipotético: cadastro de fornecedores
Considere uma indústria hipotética, que não é um caso de cliente da NM Solutions. Um agente recebe documentos de fornecedores, extrai dados cadastrais, verifica certificados obrigatórios e prepara um registro para aprovação. O fluxo depende de um modelo de linguagem, de um repositório de documentos e da API do ERP.
Se o modelo ficar indisponível, a empresa ainda recebe o pacote, atribui um protocolo e armazena os arquivos. O caso entra em uma fila sem extração automática. Se o repositório responder, mas o ERP estiver fora do ar, os dados validados ficam pendentes e nenhum fornecedor é criado. Um cadastro prioritário que poderia interromper a produção é enviado a um analista com arquivos, checklist de validação e histórico do erro.
Quando os serviços voltam, o processo de recuperação retoma cada caso do último ponto confirmado. Ele verifica se o registro já existe no ERP antes de gravar, processa primeiro os casos mais urgentes e envia extrações incertas para revisão. O exemplo não garante cadastro sem interrupção, mas evita perda silenciosa, repetição descontrolada e decisões com dados incompletos.
Pratique a recuperação e defina a volta à normalidade
Uma rota de contingência nunca exercitada é apenas um desenho. Teste em uma cadência planejada a falha de dependências, o crescimento da fila, o vencimento do trabalho, a transferência manual e a restauração. Confirme se os alertas chegam ao responsável certo e se as pessoas entendem o caso sem reconstruir o raciocínio do agente a partir de registros espalhados.
Defina critérios de saída do modo degradado. Voltar ao normal pode exigir latência estável, índice de dados atualizado, uma amostra de verificações bem-sucedidas e processamento controlado do acúmulo. Mantenha trilha do que foi automático, adiado, concluído manualmente ou abandonado.
Reconheça limites e faça a continuidade ser proporcional
Redundância aumenta custo e pode introduzir comportamentos diferentes entre provedores. Filas atrasam o trabalho e exigem controles de privacidade, retenção e capacidade. A recuperação manual pode sobrecarregar especialistas, enquanto um modelo alternativo talvez não alcance a qualidade necessária para decisões sensíveis. Alguns processos devem parar completamente quando falta evidência ou não existe alternativa segura.
A orientação da OpenAI para agentes recomenda definir limites de falha e transferir o controle para uma pessoa quando as tentativas ultrapassam esses limites. A NM Solutions ajuda empresas a mapear dependências críticas, estados de recuperação, responsáveis e alternativas seguras ao redor do processo de negócio. Um diagnóstico pode mostrar onde a continuidade precisa de engenharia e onde um procedimento operacional claro é suficiente.