Plano de continuidade de negócios para agentes de IA: como agir em quedas

Um plano de continuidade de negócios para agentes de IA define qual trabalho o agente faz, o que acontece com esse trabalho quando um modelo, uma ferramenta ou um canal para de responder e quem assume manualmente. Ele estabelece os modos de contingência com antecedência, mantém atualizados procedimentos manuais curtos e termina com verificações de recuperação que confirmam que nada foi perdido, duplicado ou enviado duas vezes. Escreva o plano antes da primeira queda, porque as decisões são mais fáceis de tomar com calma.

Principais pontos

• Planeje em torno do trabalho, não da tecnologia. Para cada tarefa, decida quanto tempo ela pode esperar e quem a executa manualmente.
• Defina um conjunto pequeno de modos de contingência, da operação normal até a pausa total, e diga quem pode alternar entre eles.
• Limite cada procedimento manual a uma página: gatilho, responsável, passos, onde registrar o que aconteceu e o que avisar às pessoas afetadas.
• A recuperação é uma fase própria. Concilie o que o agente fez com o sistema de registro antes de voltar ao normal.
• Faça um simulado em um dia tranquilo. Uma contingência que nunca foi testada é apenas uma suposição.

O que um plano de continuidade para agente de IA deve cobrir?

O plano cobre o papel que o agente desempenha, não o modelo por trás dele. O modelo é uma dependência entre várias. O agente também depende das ferramentas que chama, dos canais pelos quais as pessoas falam com ele, de uma memória ou base de conhecimento e das credenciais que o autorizam a agir. Qualquer um desses itens pode falhar enquanto os outros funcionam.

Comece pelas tarefas. Para cada uma, anote três coisas: o que o negócio perde se ela esperar, por quanto tempo ela pode esperar antes que essa perda importe e qual pessoa ou equipe consegue fazê-la sem o agente. Um resumo semanal pode esperar um dia. Confirmar uma visita técnica urgente pode exigir um humano dentro de pouco tempo. As respostas definem quanta contingência cada tarefa merece.

Guarde o resultado no mesmo lugar das demais anotações de operação. Se você já mantém um runbook, o plano de continuidade é uma seção dele. O artigo Runbook de operação para agente de IA: o que documentar descreve o que essas anotações devem conter para que alguém além de quem montou o agente consiga usá-las sob pressão.

Quais falhas você deve prever?

Planeje por categorias, não por cada incidente possível. A maioria das quedas cai em poucos formatos, e cada formato pede uma resposta segura diferente.

• Modelo indisponível ou muito lento: o agente não consegue raciocinar nem responder no prazo que a tarefa permite.
• Comportamento do modelo mudou: o serviço está no ar, mas as respostas diferem do que seus testes esperam.
• Ferramenta ou integração fora do ar: o agente consegue pensar, mas não consegue ler nem gravar em agenda, CRM, planilha ou sistema de chamados.
• Canal fora do ar: as pessoas não conseguem falar com o agente, ou o agente não consegue falar com elas, por chat, e-mail ou mensagens.
• Memória ou contexto indisponível ou desatualizado: o agente trabalha sem as anotações de que depende, ou com anotações velhas.
• Credencial expirada ou permissão revogada: um token venceu, uma conta foi alterada ou o acesso foi cortado de propósito.
• O próprio agente está agindo errado: ele está disponível, mas você precisa que ele pare.

O último item é o mais importante e costuma faltar. Um plano de continuidade não trata só de coisas que ficam em silêncio. Ele também precisa dizer quem pode parar o agente, como fazer isso e o que acontece com o trabalho em andamento quando isso ocorre.

Como desenhar os modos de contingência?

Um modo de contingência é um nível de operação combinado antecipadamente, com uma descrição clara do que o agente pode e não pode fazer. Dê nomes simples aos modos, para que qualquer pessoa da equipe consiga dizer qual está ativo. Use a lista abaixo como guia de decisão e escolha o modo mais baixo que ainda proteja o resultado.

• Normal: o agente trabalha com o modelo, as ferramentas e as aprovações de sempre.
• Reduzido: um modelo reserva ou um conjunto menor de ferramentas está em uso. O agente cuida apenas das tarefas testadas nessa configuração e passa o restante para as pessoas.
• Somente rascunho: o agente prepara o trabalho, mas um humano envia, agenda ou registra. Use quando uma ferramenta de escrita estiver instável ou quando a qualidade das respostas estiver em dúvida.
• Somente fila: o agente recebe os pedidos, confirma o recebimento quando isso for seguro e não executa nenhuma ação. Um humano trabalha a fila.
• Pausado: o agente não faz nada. A equipe segue os procedimentos manuais, e um aviso curto informa as pessoas afetadas para onde ir.

Há dois cuidados. Primeiro, um modelo reserva não é uma cópia do principal. Ele pode seguir instruções de outro jeito, então rode-o contra o seu conjunto de testes de referência antes de depender dele e limite o escopo às tarefas que passaram. Segundo, não deixe o agente decidir sozinho subir para um modo com mais autoridade. Reduzir a capacidade pode ser automático. Voltar a subir deve exigir a confirmação de uma pessoa.

Que procedimentos manuais devem existir antes de uma queda?

Um procedimento manual é o que uma pessoa faz quando o agente não consegue. Ele deve ser curto o bastante para ser seguido no meio de interrupções. Uma página por tarefa crítica é um limite razoável, e ela deve conter o seguinte.

• Gatilho: como alguém sabe que o procedimento vale, por exemplo uma mensagem de status, um sinal de vida que não chegou ou o aviso de um colega.
• Responsável e substituto: funções nomeadas, não um alias de equipe que ninguém acompanha.
• Passos: as ações reais, usando os mesmos sistemas de registro do agente e as mesmas regras que ele segue.
• Registro: onde anotar o que foi feito à mão, para que o agente ou um revisor possa conciliar depois.
• Mensagem: a frase a enviar a clientes, parceiros ou colegas que estão esperando, escrita e aprovada com antecedência.
• Saída: o que precisa ser verdade antes de o agente reassumir o trabalho.

O registro é o passo que as equipes pulam. Quando uma pessoa agenda um atendimento manualmente durante a queda e depois o agente reprocessa a fila, surge uma reserva duplicada. Um único registro compartilhado, mesmo um documento simples, evita a maior parte disso.

A passagem de trabalho deve levar a decisão, não um monte de contexto bruto. O artigo Escalonamento humano em IA: entregue a decisão necessária mostra como montar um caso para que a pessoa que assume consiga agir de imediato.

Como é uma queda na prática? Um cenário ilustrativo

Este cenário é ilustrativo e não relata um caso real. Uma pequena empresa de serviços usa um agente que lê pedidos recebidos em um canal de chat da equipe, propõe horários e grava as visitas confirmadas em uma ferramenta de agenda.

Uma manhã, a ferramenta de agenda começa a estourar o tempo limite. O agente ainda lê os pedidos e raciocina sobre eles, mas suas chamadas de escrita falham. Um agente bem construído não fica insistindo. Ele segue as regras de repetição, para depois das tentativas permitidas e passa para somente fila em tudo o que exige agendamento. Envia uma única mensagem à coordenadora, listando cada pedido pendente com o horário que teria proposto. A orientação para limitar tentativas está em Política de repetição para agentes de IA sem duplicidades.

A coordenadora usa o procedimento de uma página: confirma as visitas por telefone, anota cada uma no registro compartilhado e envia a mensagem pré-aprovada a quem precisa esperar. Quando a ferramenta volta, o agente não reprocessa a fila às cegas. Primeiro ele compara a lista de pendências com o registro compartilhado, descarta o que já foi tratado e pede à coordenadora que confirme o restante.

Nada nesse fluxo é sofisticado. Ele funciona porque o modo, o responsável, o registro e a condição de saída foram decididos antes.

Como recuperar com segurança depois da queda?

É na recuperação que o dano silencioso acontece. Os serviços voltam, as filas esvaziam e ações duplicadas ou desatualizadas saem. Trate o retorno ao normal como uma sequência com verificações, não como um interruptor.

• Confirme que a causa foi resolvida executando uma ação pequena e inofensiva no modelo, na ferramenta ou no canal recuperado.
• Congele novas gravações automáticas até concluir os passos seguintes.
• Concilie: compare o registro de ações do agente com cada sistema de registro no período da queda e liste as ações iniciadas, mas não concluídas.
• Procure duplicidades e ações parciais, como uma mensagem enviada sem a atualização correspondente no registro.
• Revise a idade dos itens na fila. Um pedido urgente de manhã pode ser irrelevante à tarde, então uma pessoa decide o que reprocessar e o que encerrar.
• Verifique eventos perdidos. Provedores que enviam notificações por webhook costumam documentar as repetições de envio e como verificar e buscar de novo os eventos, como na documentação de webhooks da Stripe. Confirme que suas próprias integrações conseguem se atualizar da mesma forma. O artigo Webhooks ou consultas periódicas em fluxos de IA ajuda a comparar as duas abordagens.
• Rode de novo o conjunto de testes de referência e confira se a memória e o contexto estão atuais, e não parados no momento da falha.
• Suba o agente um modo por vez, com uma pessoa nomeada aprovando cada etapa.
• Escreva uma nota curta: causa, duração, o que foi tratado manualmente e o que mudou no plano.

Bons registros tornam isso possível. Se você não sabe o que o agente fez e quando, a conciliação vira adivinhação. O artigo Observabilidade de agentes de IA: o que registrar? lista os eventos que valem a pena guardar, e o material introdutório de observabilidade do projeto OpenTelemetry explica as ideias de base sobre traces, métricas e logs.

Como uma operação gerenciada trata a continuidade?

Em um projeto da Be Human, os modos de contingência e os procedimentos manuais são definidos junto com o papel do agente, suas ferramentas, seus limites de aprovação e seu critério de sucesso, de modo que o plano existe antes de o agente receber autoridade. A operação gerenciada inclui monitoramento, manutenção das integrações, revisão de permissões e resposta a incidentes. Isso significa que alguém acompanha os formatos de falha descritos acima e o runbook é mantido atualizado conforme ferramentas e canais mudam. A empresa mantém o controle das trocas de modo que afetam seus clientes, e a identidade, a memória e as permissões do agente permanecem sob supervisão humana o tempo todo.

Perguntas frequentes

Com que frequência devemos testar o plano de continuidade? Teste em um ritmo proporcional à dependência do negócio em relação ao agente, e de novo após qualquer mudança de modelo, ferramenta, canal ou permissão. Um simulado curto, em que alguém coloca o agente em somente fila e percorre um procedimento manual, basta para encontrar contatos desatualizados e acessos que faltam. Registre o que falhou no simulado e corrija antes do próximo.

Precisamos de um modelo reserva para cada agente? Nem sempre. Se a tarefa pode esperar, uma pausa com procedimento manual pode ser mais segura e mais barata de manter do que um segundo modelo que se comporta de outro jeito. Adicione um modelo reserva quando a tarefa for sensível ao tempo e você tiver testado o reserva em exemplos reais dessa tarefa.

Quem deve poder pausar o agente? Nomeie pelo menos duas pessoas com autoridade e acesso para isso, para que uma ausência não trave a decisão. A pausa deve ser fácil e não exigir explicação técnica. Retomar deve ser um passo deliberado, aprovado por alguém depois das verificações de recuperação.

E se a queda for em um canal como Slack ou e-mail? Decida antes para onde vão os alertas urgentes quando o canal principal estiver fora do ar e mantenha esse caminho separado do canal do próprio agente. O procedimento manual deve listar o contato alternativo e a mensagem pré-aprovada. Quando o canal voltar, concilie as mensagens enviadas durante a interrupção antes de o agente retomar.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.