Plano de contingência quando o provedor de IA cai: filas e equipe

Quando um provedor de modelos fica indisponível, um agente de negócio deve continuar aceitando pedidos, guardá-los em uma fila durável, pausar qualquer ação que não possa ser repetida com segurança e enviar itens urgentes para pessoas nomeadas, com contexto suficiente para agir. O plano só funciona se for escrito antes da falha, com responsáveis claros, prazos e regras sobre o que o agente ainda pode fazer em modo degradado.

Principais pontos

• Decida antecipadamente quais tarefas podem ser retidas, quais podem ser concluídas por um método mais simples e quais devem parar até o provedor se recuperar.
• Dê a cada pedido na fila um identificador estável, para que uma nova tentativa após a recuperação não gere um segundo orçamento, agendamento ou mensagem.
• Associe cada categoria urgente a uma pessoa nomeada, com um substituto, acessível por um canal que não dependa do provedor que falhou.
• Mantenha o agente em modo de rascunho ou somente leitura após a recuperação, até que as respostas recentes passem nas suas verificações por amostragem.
• Registre cada entrada e saída do modo de contingência e atualize o plano após cada indisponibilidade, porque o primeiro incidente real costuma expor uma lacuna.

O que conta como indisponibilidade do modelo para um agente de negócio?

Uma queda total é o caso fácil, porque todas as requisições falham e todos percebem. As falhas mais difíceis são parciais. As requisições expiram só em horários de pico, as respostas chegam devagar demais para um chat ao vivo, o provedor começa a recusar chamadas porque sua conta atingiu um limite, ou o modelo continua respondendo enquanto a qualidade cai. O plano precisa cobrir essas situações, porque um agente parcialmente funcionando pode causar mais dano do que um que parou de forma limpa.

Dê a cada condição um nome, um sinal de detecção e uma resposta. Um conjunto inicial prático pode ser este:

• Queda total: as chamadas falham ou retornam erro em todas as requisições.
• Lentidão: as chamadas funcionam, mas demoram mais do que o fluxo de trabalho tolera.
• Limitação de uso: o provedor ou seu gateway recusa chamadas por causa do volume.
• Queda de qualidade: as saídas estão bem formadas, mas falham nas suas verificações com respostas conhecidas como boas.
• Falha de ferramenta: o modelo responde, mas o sistema de agendamento, a caixa de entrada ou o repositório de documentos do qual o agente depende não responde.

A limitação de uso merece regras próprias, porque tentativas agressivas podem piorar o problema. O guia sobre limites de taxa de API em agentes de IA explica como evitar essas surpresas antes que aconteçam.

Como escrever o plano de contingência antes de precisar dele?

Um plano escrito durante o incidente costuma ser ignorado, então escreva-o enquanto a operação está tranquila e mantenha-o curto o bastante para ser seguido sob pressão. Trabalhe nestes passos com as pessoas que são donas do processo de negócio, e não apenas com a equipe técnica:

• Liste cada tarefa que o agente executa e marque cada uma como reter, concluir em modo reduzido ou parar.
• Defina o gatilho que coloca o agente em contingência, como uma sequência de chamadas falhas ou respostas que ultrapassam um tempo limite definido por você.
• Nomeie quem pode declarar o fim da indisponibilidade e quem recebe os itens urgentes enquanto ela durar.
• Estabeleça uma idade máxima da fila para cada tipo de tarefa. Quando um item ultrapassa essa idade, ele vai para uma pessoa em vez de continuar esperando.
• Defina o que o cliente ou colega vê: uma mensagem de espera honesta, que diga o que acontece em seguida, nunca um palpite apresentado como resposta.
• Especifique a sequência de recuperação: ordem de reprocessamento, verificação de duplicidades, revisão por amostragem e o momento em que a autoridade normal volta.
• Guarde o plano em um lugar que o responsável pela operação consiga abrir sem depender do agente, e ensaie-o uma vez antes de precisar.

Um plano que cabe em poucas páginas é mais confiável do que um documento longo que ninguém lê durante um incidente.

Como enfileirar trabalho sem repeti-lo?

Durante a indisponibilidade, o agente deve continuar recebendo pedidos, mas evitar ações irreversíveis. Cada pedido recebido entra em uma fila durável com identificador estável, horário de recebimento, canal de origem e tipo de tarefa. A fila só é segura se o agente também souber o que já fez. Um cliente que envia três vezes o mesmo pedido de agendamento enquanto o agente está fora não deve gerar três agendamentos quando o serviço voltar.

O padrão seguro é a idempotência no ponto da ação. Toda escrita em sistema de agendamento, fatura, chamado ou mensagem de saída deve carregar uma chave derivada do pedido original, para que uma segunda tentativa devolva o primeiro resultado em vez de criar um registro novo. Plataformas de pagamento documentam esse padrão em detalhes, e vale a pena ler essas orientações mesmo que sua pilha tecnológica seja outra.

O desenho do reprocessamento importa tanto quanto a chave. Liberar um acúmulo de uma só vez pode acionar limitação de uso, ações duplicadas e uma enxurrada de respostas antigas. Reprocesse por ordem de idade, limite a velocidade e revalide qualquer item cujos fatos subjacentes mudaram. A política de repetição para agentes de IA mostra como impedir que o agente repita o mesmo erro nessa fase.

Como os itens urgentes devem chegar às pessoas nomeadas?

Algumas tarefas não podem esperar pelo modelo. Um cliente cujo sinal vence hoje, um fornecedor aguardando na doca ou um cliente com reclamação sobre um problema de segurança nunca devem ficar esquecidos em uma fila. Defina uma lista curta de categorias urgentes, em linguagem simples, e associe cada uma a uma pessoa nomeada com substituto. O canal de escalonamento deve ser e-mail, telefone ou uma ferramenta de chat interna que continue funcionando independentemente do provedor que falhou.

Quando o agente escalona, deve enviar a decisão, não a confusão. Isso significa o pedido em uma ou duas frases, o que já foi verificado, o que não pôde ser verificado, o prazo e a única escolha que ele precisa da pessoa. Uma transcrição bruta obriga quem lê a reconstruir o caso. O guia de escalonamento humano para agentes de IA detalha esse formato.

Use um guia simples de decisão quando um item da fila chegar durante a contingência:

• Se o item envolve dinheiro, um compromisso jurídico ou uma decisão de segurança, envie-o imediatamente a uma pessoa nomeada.
• Se o item é sensível ao tempo, mas rotineiro, retenha-o e avise o responsável pela tarefa à medida que o limite de idade da fila se aproxima.
• Se o item exige apenas informações que o agente pode obter em fontes aprovadas, retenha-o e responda depois que o modelo voltar.
• Se um método reduzido pode concluir o item com segurança, use-o, registre o uso e marque o caso para revisão.

Durante a contingência, o agente não deve improvisar aprovações. Ele não pode conceder reembolsos, alterar preços acordados ou confirmar informações regulamentadas, a menos que uma pessoa nomeada tenha concedido essa autoridade para o período, por escrito.

Cenário ilustrativo: um pedido de orçamento durante a queda do provedor

O cenário a seguir é ilustrativo e não descreve uma empresa específica. Uma pequena prestadora de serviços usa um agente para responder pedidos de orçamento do site, verificar disponibilidade e propor visitas técnicas. Ao meio-dia, o provedor do modelo começa a expirar as chamadas. O agente detecta falhas seguidas, entra em contingência e informa a cada visitante que o pedido foi salvo e que um coordenador responderá dentro do prazo publicado pela empresa.

O agente guarda cada pedido com os dados do formulário e o horário, e não propõe datas de visita enquanto o provedor estiver fora. Pedidos marcados como serviço do mesmo dia são enviados ao coordenador de operações por mensagem de texto, por um canal que não depende do modelo. Quando o provedor volta, o agente reprocessa a fila por ordem de idade, consulta o sistema de agenda para verificar agendamentos existentes antes de criar qualquer um e envia um resumo em rascunho ao coordenador para revisão antes de retomar respostas diretas. O coordenador aprova o primeiro lote, e o agente volta à autoridade normal apenas para aquele tipo de tarefa.

Como a recuperação e a revisão mantêm o plano honesto?

A recuperação é onde muitas equipes relaxam cedo demais. Antes que o agente volte à autoridade plena, confirme o estado da fila e das saídas que ele produziu. Use uma checklist curta:

• A fila está vazia, ou cada item restante tem um motivo declarado para esperar.
• Não existem agendamentos, mensagens ou chamados duplicados originados de pedidos reprocessados.
• Uma amostra das saídas produzidas após a recuperação corresponde ao padrão usado antes da indisponibilidade.
• Cada item enviado a uma pessoa tem um resultado registrado.

Mantenha uma nota breve do incidente, com o gatilho, o horário em que o agente entrou em contingência, o número de itens retidos, os escalonamentos enviados e qualquer ação que uma pessoa precisou corrigir manualmente. Depois, atualize o plano. A maioria das lacunas é pequena, como uma categoria de tarefa que ninguém listou ou um contato de escalonamento que mudou de função.

A Be Human trata o comportamento de contingência como parte do agente, e não como algo acrescentado depois. Um primeiro projeto define um papel útil, a memória e as ferramentas de que ele precisa, os limites de aprovação, o comportamento de contingência para cada tarefa e as pessoas nomeadas que recebem os escalonamentos. A operação gerenciada pode então cobrir o monitoramento do provedor, verificações recorrentes das saídas, revisão de permissões e resposta a incidentes quando a contingência for acionada, com mudanças controladas no plano à medida que cada evento ensinar algo novo.

Se você não tem certeza de qual tarefa do seu agente merece um plano de contingência primeiro, o diagnóstico gratuito de IA da Be Human pode ajudar a encontrar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

O agente deve continuar respondendo clientes durante a indisponibilidade do modelo? Ele pode confirmar o recebimento do pedido, explicar que o pedido foi salvo e dizer quando uma pessoa fará contato, mas não deve produzir respostas substantivas que não consegue verificar. Uma mensagem de espera curta e honesta é melhor do que um palpite dado com segurança. Tudo o que envolve dinheiro, datas ou exceções de política aguarda uma pessoa nomeada.

Um segundo modelo ou uma resposta em cache podem substituir o principal durante a queda? Às vezes, para tarefas restritas em que você testou a alternativa com seus próprios exemplos. Um modelo diferente se comporta de outra forma, então execute os mesmos casos de teste antes de direcionar trabalho real para ele e mantenha os mesmos limites de aprovação. Respostas em cache só são seguras para fatos que não mudaram, por isso cada uma precisa de um responsável e de uma data de revisão.

Como saber quando a indisponibilidade realmente acabou? Não confie apenas na página de status do provedor. Exija várias chamadas bem-sucedidas, confirme que a latência voltou ao seu limite e peça que o responsável pela tarefa revise uma amostra das saídas. Só então o agente deve voltar à autoridade plena nas tarefas afetadas.

Quem deve ser dono do plano de contingência? Um dono do negócio ou o responsável pela operação deve decidir quando entrar e sair da contingência, um responsável técnico deve manter os gatilhos, registros e ferramentas de reprocessamento, e cada categoria de escalonamento precisa de uma pessoa nomeada. Registre esses papéis por escrito, porque durante um incidente ninguém tem tempo para adivinhar. O NIST AI Risk Management Framework é uma referência útil para atribuir responsabilidades em torno do risco de IA.

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