Blog

Modo degradado: manter o atendimento de pé quando a IA está indisponível

O provedor de LLM cai, e a pergunta que decide a qualidade do seu atendimento naquele momento não é técnica, é de produto: o que o cliente vê. Sem plano, ele vê um erro genérico, uma tela girando até o timeout ou, pior, silêncio. Nada disso é inevitável, porque quase tudo que o bot faz de útil não depende do modelo. A base de conhecimento continua lá, o histórico da conversa continua lá, a fila de humanos continua lá, o formulário de coleta continua lá. Modo degradado é a disciplina de decidir com antecedência quais capacidades caem primeiro, o que ainda é possível entregar sem cada uma, e como voltar sem derrubar de novo o serviço que acabou de se recuperar. Este artigo mostra como desenhar essa escada: por que falhar em modo aberto é diferente de falhar em modo fechado, como classificar a falha antes de reagir, quais níveis fazem sentido em atendimento, como evitar o pingue-pongue entre modos, o que dizer ao cliente em cada nível e como testar tudo isso antes que a queda real aconteça.

2026-07-30 / IA Aplicada / 14 min

01

A pergunta que precisa ser respondida antes do incidente

Todo sistema que depende de um serviço externo enfrenta uma escolha binária quando esse serviço some: falhar em modo aberto, deixando a operação seguir sem a proteção ou o enriquecimento que aquele serviço dava, ou falhar em modo fechado, bloqueando a operação por não conseguir garantir o resultado. Essa escolha não é técnica, é de negócio, e ela precisa ser feita por capacidade e não pelo sistema inteiro.

Em atendimento, a resposta certa quase sempre difere entre as capacidades do mesmo bot. Um classificador de intenção que caiu deve falhar aberto: sem ele o roteamento fica pior, mas mandar tudo para a fila geral é melhor do que não atender. Um verificador de elegibilidade de reembolso deve falhar fechado: sem ele, aprovar por otimismo cria prejuízo real e irreversível. Misturar as duas políticas no mesmo tratamento de erro é como a maioria dos sistemas erra, e o sintoma é sempre o mesmo: ou o bot bloqueia coisas inofensivas durante toda a queda, ou ele libera exatamente aquilo que precisava de verificação.

A regra prática que resolve quase todos os casos: falhe aberto quando o pior resultado da ausência é uma resposta pior, e falhe fechado quando o pior resultado é uma ação errada com efeito no mundo. Ler documentação, sugerir artigo, resumir histórico e classificar assunto caem no primeiro grupo. Cancelar assinatura, emitir crédito, alterar endereço de entrega e liberar acesso caem no segundo. Escreva essa classificação por capacidade antes do incidente, porque durante ele ninguém tem calma para decidir direito.

02

Classificar a falha antes de escolher a reação

Reagir a "deu erro" leva à reação errada com frequência. Um 429 pede espera e enfileiramento, um 400 pede correção do payload e nunca melhora com retentativa, um 503 pede troca de provedor, e um timeout não diz se a chamada aconteceu ou não. Tratar os quatro do mesmo jeito é o que transforma uma limitação temporária de taxa em queda total, porque a retentativa imediata contra um provedor que já está sinalizando saturação é o jeito mais rápido de piorar a saturação.

SintomaO que provavelmente éReação certaErro comum
HTTP 429 com Retry-AfterLimite de taxa, o serviço está de péRespeitar o cabeçalho, enfileirar e degradar só o não urgenteRetentar de imediato e ampliar a saturação
HTTP 5xx persistenteIndisponibilidade do provedorAbrir o disjuntor e cair para o provedor secundárioInsistir no primário até estourar todos os timeouts
Timeout sem respostaAmbíguo: pode ter executado do outro ladoNão repetir efeito colateral sem chave de idempotênciaRetentar cegamente e duplicar a ação
HTTP 400 ou 422Contrato quebrado, provavelmente após um deployFalhar rápido, alertar e reverter a mudançaRetentar, o que nunca corrige e ainda esconde o bug
Latência alta sem erroDegradação parcial, a pior de detectarCortar por orçamento de tempo e responder sem o modeloEsperar o timeout completo e travar a conversa
Resposta fora de formatoRegressão do modelo ou mudança silenciosa de versãoValidar a saída, uma retentativa e cair para o fluxo fixoAceitar o texto quebrado e propagar o defeito adiante

A latência alta sem erro merece atenção extra porque não dispara nenhum alarme convencional e é a forma mais comum de queda parcial. O que resolve é orçamento de tempo por turno, contado desde a chegada da mensagem e não desde o início de cada chamada. Quando o orçamento acaba, o turno responde com o que tiver, e responder em três segundos com um artigo relevante é melhor do que responder em quarenta com a resposta perfeita, porque em quarenta segundos o cliente já saiu.

03

Os quatro níveis da escada de degradação

Modo degradado não é um interruptor entre ligado e desligado. É uma escada em que cada degrau remove uma capacidade e mantém tudo o que não depende dela. Quatro níveis cobrem bem a realidade de um atendimento, e a virtude do desenho está em quanto ainda funciona no terceiro degrau.

NívelO que está foraO que ainda funcionaGatilho típico
PlenoNadaGeração, RAG, tools, resumo e classificaçãoOperação normal
ReduzidoModelo grande e tools de escritaModelo menor, RAG, leitura de dados, classificaçãoLatência acima do orçamento ou custo em alerta
RoteadorToda geração de texto livreBusca na base, resposta pronta por intenção, transbordoProvedor indisponível ou disjuntor aberto
RecadoBusca e classificação tambémReceber, confirmar, coletar dados e enfileirar para humanoFalha ampla, incluindo o índice de busca

O nível roteador é o que salva a operação na maioria dos incidentes reais e é justamente o que quase ninguém constrói. Sem modelo nenhum, uma busca léxica na base de conhecimento mais um conjunto de respostas prontas por intenção resolve uma fatia grande do volume, porque o atendimento é dominado por perguntas repetidas. A parte que exige disciplina é manter esse conjunto de respostas vivo: ele apodrece em silêncio quando ninguém exercita, e descobrir isso durante a queda é descobrir tarde.

O nível recado parece pouco e é muito. Confirmar o recebimento, coletar os dados que o humano vai precisar, informar prazo real e criar o ticket transforma uma queda de trinta minutos em uma fila de trabalho organizada em vez de uma pilha de clientes irritados que precisarão repetir tudo depois. É também o único nível que precisa funcionar sem nenhuma dependência externa além do seu próprio banco, e por isso ele merece o caminho de código mais simples e mais testado do sistema.

                    orcamento de tempo do turno
                              |
   +--------+   latencia   +---------+   disjuntor   +----------+   indice   +--------+
   | PLENO  | -----------> | REDUZID | ------------> | ROTEADOR | ---------> | RECADO |
   +--------+              +---------+               +----------+            +--------+
       ^                        ^                          ^                     |
       |                        |                          |                     |
       +---- sonda 5% ok -------+---- sonda 5% ok ---------+---- sonda 5% ok ----+
             (subir 1 nivel por vez, nunca do fundo direto ao topo)

   descer: imediato, na primeira evidencia de falha
   subir : so apos janela minima + sonda bem sucedida

04

Descer rápido, subir devagar e não ficar oscilando

A assimetria é o coração do desenho. Descer de nível deve ser imediato, porque cada segundo em um nível que não funciona é uma conversa perdida. Subir de nível deve ser lento e verificado, porque um provedor que acabou de voltar costuma voltar frágil, e mandar cem por cento do tráfego para ele no primeiro sinal de vida é a maneira mais confiável de derrubá-lo de novo.

O modo de falha específico a evitar é o pingue-pongue: o sistema sobe porque uma requisição funcionou, cai porque as dez seguintes falharam, sobe de novo, e cada oscilação custa uma leva de conversas atendidas pela metade além de encher o canal de alertas. Três mecanismos combinados resolvem, e os três são necessários. Histerese, com limiares diferentes para descer e para subir, para que o ponto de retorno não seja o mesmo ponto de saída. Tempo mínimo de permanência no nível, tipicamente de um a cinco minutos, para que nenhuma decisão seja revertida antes de ter efeito observável. E sonda de recuperação, mandando uma fração pequena do tráfego para a capacidade suspeita e só promovendo o nível quando essa fração passa por uma janela inteira.

// degraded/machine.js
// Maquina de nivel de degradacao: desce rapido, sobe devagar.
// Descer e imediato; subir exige janela minima + sonda bem sucedida.

export const LEVELS = ['full', 'reduced', 'router', 'message'];

export function createDegradationMachine({
  now,                      // () => number, injetado para ser testavel
  minDwellMs = 60_000,      // tempo minimo em um nivel antes de subir
  probeRatio = 0.05,        // fracao do trafego que sonda o nivel acima
  probeSuccessesToRecover = 20,
  failuresToDegrade = 5,
} = {}) {
  if (typeof now !== 'function') throw new Error('now precisa ser uma funcao');

  let index = 0;                 // 0 = full
  let enteredAt = now();
  let failures = 0;
  let probeSuccesses = 0;

  const level = () => LEVELS[index];

  return {
    level,

    /** Falha observada no nivel atual: desce assim que houver evidencia. */
    recordFailure() {
      failures += 1;
      probeSuccesses = 0;
      if (failures >= failuresToDegrade && index < LEVELS.length - 1) {
        index += 1;
        enteredAt = now();
        failures = 0;
        return { changed: true, level: level(), direction: 'down' };
      }
      return { changed: false, level: level() };
    },

    /**
     * Sucesso observado. So conta para recuperacao se veio de uma sonda,
     * senao o sucesso do proprio nivel degradado promoveria o sistema.
     */
    recordSuccess({ fromProbe = false } = {}) {
      failures = 0;
      if (!fromProbe || index === 0) return { changed: false, level: level() };

      // Tempo minimo de permanencia: evita reverter antes de haver efeito.
      if (now() - enteredAt < minDwellMs) return { changed: false, level: level() };

      probeSuccesses += 1;
      if (probeSuccesses >= probeSuccessesToRecover) {
        index -= 1;              // um nivel por vez, nunca do fundo ao topo
        enteredAt = now();
        probeSuccesses = 0;
        return { changed: true, level: level(), direction: 'up' };
      }
      return { changed: false, level: level() };
    },

    /** Decide se esta requisicao testa o nivel acima. */
    shouldProbe(sample) {
      if (index === 0) return false;
      if (now() - enteredAt < minDwellMs) return false;
      return sample < probeRatio;   // sample em [0, 1), do chamador
    },

    snapshot() {
      return { level: level(), index, enteredAt, failures, probeSuccesses };
    },
  };
}

Duas decisões nesse código merecem destaque porque são exatamente onde as implementações caseiras erram. O sucesso só conta para recuperação quando vem de uma sonda: sem essa distinção, o bot no nível roteador acumula sucessos das próprias respostas prontas e se promove sozinho para um nível que continua quebrado. E a subida é de um nível por vez: pular do recado direto para o pleno é o caminho mais curto para reabrir o disjuntor em segundos.

05

O que o cliente vê e o que a operação precisa saber

Modo degradado mal comunicado é indistinguível de bot ruim. O cliente não sabe que o provedor caiu, ele sabe que perguntou uma coisa e recebeu outra. As três regras que evitam isso: seja específico sobre o que você ainda consegue fazer, nunca prometa prazo que depende de um sistema que você não controla, e não invente explicação técnica que ninguém pediu.

Compare duas mensagens no nível roteador. A primeira diz que houve um erro e pede para tentar mais tarde: ela empurra o problema para o cliente e não entrega nada. A segunda diz que naquele momento consegue consultar a base e encontrar o artigo sobre o assunto, e que se não resolver já deixa o caso com um atendente com tudo que foi conversado: ela entrega duas saídas concretas e preserva o contexto. O trabalho técnico é o mesmo, e a diferença de percepção é enorme.

  • Nível reduzido: não anuncie nada. A resposta continua sendo gerada, apenas com um modelo menor e sem ações de escrita, e avisar aqui só cria dúvida onde não havia problema.
  • Nível roteador: diga o que ainda é possível, ofereça o artigo encontrado e coloque o transbordo para humano a um toque de distância, sem exigir que o cliente reformule a pergunta.
  • Nível recado: confirme o recebimento com número de protocolo, informe o prazo real de retorno com base no tamanho da fila e colete o que o humano vai precisar para não perguntar de novo.
  • Em qualquer nível abaixo de pleno: preserve o histórico e passe-o ao atendente, porque fazer o cliente repetir tudo é o que transforma um incidente técnico em reclamação.

Do lado da operação, o mínimo é registrar o nível atual como um campo em toda conversa e emitir métricas de tempo em cada nível, de transições por hora e de resultado por nível. Sem isso você não consegue responder as duas perguntas que sempre aparecem depois: quanto do volume da semana passou por modo degradado, e o nível roteador resolveu ou apenas adiou. A segunda pergunta é a que justifica o investimento em manter as respostas prontas atualizadas.

06

Testar o modo degradado antes de precisar dele

Modo degradado tem a mesma patologia de todo caminho de exceção: ele é escrito uma vez, nunca é executado e apodrece em silêncio até o dia em que é a única coisa que importa. A resposta pronta que mencionava um produto descontinuado, o índice de busca que parou de ser atualizado, o formulário de coleta que quebrou num deploy de três meses atrás, tudo isso só aparece durante a queda se ninguém exercitar antes.

  1. Torne o nível forçável por configuração, de forma que qualquer pessoa possa colocar o sistema em roteador ou recado sem simular uma falha real.
  2. Rode um exercício semanal em produção com uma fatia pequena do tráfego, entre um e cinco por cento, atendida no nível roteador de propósito.
  3. Teste a máquina de níveis com relógio injetado, cobrindo pingue-pongue, tempo mínimo de permanência e subida de um nível por vez.
  4. Verifique a saúde do nível recado sem nenhuma dependência externa disponível, porque ele é o único que precisa funcionar quando tudo mais caiu.
  5. Meça a taxa de resolução dentro de cada nível degradado e trate a queda dessa taxa como um bug de produto, não como consequência aceitável do incidente.
  6. Revise o conjunto de respostas prontas na mesma cadência em que revisa a base de conhecimento, porque ele envelhece pelo mesmo motivo.

O exercício semanal em produção é o item que mais incomoda e o que mais entrega. Servir um por cento do tráfego em nível roteador tem custo real e pequeno, e é a única forma honesta de saber que ele funciona: teste em ambiente de homologação prova que o código roda, não que a resposta pronta ainda faz sentido para o cliente de hoje. Se a taxa de transbordo do grupo exercitado for muito maior que a do grupo normal, você descobriu isso numa terça-feira tranquila em vez de descobrir durante a queda.

FAQ

Perguntas frequentes

Quantos níveis de degradação vale a pena manter?

Menos do que a vontade inicial sugere, porque cada nível é um caminho de código que precisa ser exercitado para não apodrecer, e níveis que ninguém exercita são código morto que dá falsa sensação de segurança. Comece com dois além do pleno: um sem geração de texto livre, que responde por busca e respostas prontas, e um que só recebe, confirma e enfileira para humano. Esses dois cobrem a grande maioria dos incidentes reais, porque as falhas que importam são indisponibilidade do provedor e queda ampla. O nível reduzido, com modelo menor e sem ações de escrita, vale a pena quando você já tem um segundo modelo integrado e um orçamento de tempo por turno implementado, e não antes disso. Adicionar um quinto nível quase sempre significa que a classificação de falha está imprecisa, e vale mais consertar a classificação do que criar mais um degrau.

O modo degradado deve valer para o sistema inteiro ou por capacidade?

Por capacidade, com um nível global calculado a partir delas. Se o índice de busca vetorial caiu mas o modelo está de pé, degradar tudo joga fora a geração que ainda funcionaria perfeitamente; se o provedor caiu mas a busca está de pé, manter tudo em pleno gera timeout em cada turno. O desenho que funciona é declarar a política por capacidade, definindo para cada uma se ela falha aberta ou fechada e qual nível ela força quando indisponível, e derivar o nível efetivo da conversa a partir da capacidade mais degradada que aquele fluxo específico exige. Um fluxo de consulta a pedido e um fluxo de cancelamento de assinatura não precisam estar no mesmo nível ao mesmo tempo, e forçá-los a isso é o que faz o sistema degradar mais do que precisava.

Vale a pena manter um provedor secundário em vez de degradar?

As duas coisas são complementares e resolvem problemas diferentes, então tratá-las como alternativas é o erro. O provedor secundário cobre indisponibilidade de um fornecedor específico e é a primeira linha de defesa, com a ressalva de que ele precisa ser exercitado com tráfego real de vez em quando, porque prompt calibrado em um modelo raramente funciona igual no outro e descobrir isso durante a queda é descobrir tarde. O modo degradado cobre o que o fallback não alcança: os dois provedores fora, a rede da sua nuvem com problema, o índice de busca corrompido, o limite de gasto atingido, o bug no seu próprio código de orquestração. Sistemas que só têm fallback ficam sem plano nenhum exatamente nos incidentes mais graves, que são justamente aqueles em que a alternativa também está indisponível.

Sem plano, a indisponibilidade da IA vira indisponibilidade do atendimento

A queda do provedor é certa e a data é o único detalhe desconhecido. O que separa meia hora de operação em ritmo reduzido de meia hora de clientes sem resposta é ter decidido antes quais capacidades falham abertas e quais falham fechadas, ter uma escada de níveis em que o degrau sem modelo nenhum ainda resolve, descer rápido e subir devagar com sonda e histerese, e exercitar tudo isso em produção antes de precisar. Posso desenhar e implementar essa camada de degradação no seu atendimento com IA, da classificação de falha à comunicação com o cliente em cada nível.