O erro apareceu. O agente continuou trabalhando.
Uma integração começa a devolver timeout. O agente tenta consultar de novo, muda a resposta e segue atendendo. Em outra fila, a base desatualizada faz a IA informar a mesma regra errada para vários clientes.
A equipe percebe o padrão. Alguém avisa no grupo. Outra pessoa pergunta se é melhor desligar tudo. Enquanto a discussão acontece, novas conversas entram.
Esse é o problema: se a única opção conhecida é deixar rodando ou apagar o agente inteiro, a operação ainda não tem uma regra de pausa.
Pausar bem não significa abandonar o cliente. Significa interromper a parte insegura, preservar o que ainda funciona e entregar o restante para uma saída previsível.
Resposta curta
Pause o agente, uma intenção ou uma ferramenta quando continuar pode ampliar dano e a operação perdeu uma destas quatro certezas:
- verdade: não sabe se a resposta ou o dado ainda está correto;
- estado: não sabe se a ação aconteceu;
- limite: o agente repete, insiste ou executa além da regra;
- saída: não consegue entregar o caso para uma pessoa com contexto e prazo.
A pausa pode ser seletiva. Se consultar pedido funciona, mas cancelar está instável, mantenha a consulta e bloqueie o cancelamento. Se toda resposta depende da base errada, interrompa o agente inteiro.
O importante é que a decisão já esteja escrita antes do incidente.
Cinco sinais que não deveriam depender de opinião
“Parece estranho” ajuda a investigar. Não basta para operar em escala. Defina gatilhos observáveis.
| Sinal | Exemplo | Resposta inicial |
|---|---|---|
| erro repetido | mesma ferramenta falhou 3 vezes em 5 minutos | bloquear a ação e verificar estado |
| resultado incerto | cancelamento pode ter acontecido, mas não há confirmação | parar repetição e reconciliar |
| resposta sem evidência | regra citada não existe na fonte aprovada | suspender o tema afetado |
| loop de conversa | cliente corrigiu a IA duas vezes ou recebeu a mesma pergunta | passar para humano |
| ação de alto impacto | cobrança, reembolso, cancelamento ou envio sem aprovação exigida | impedir execução e abrir revisão |
O número exato varia. Três falhas podem ser demais para cobrança e pouco para uma consulta sem efeito colateral. A régua deve combinar frequência, impacto e capacidade de recuperação.
O guia da OpenAI para construção de agentes recomenda limites de tentativas e intervenção humana quando o agente excede esses limites. Também trata ações sensíveis, irreversíveis ou de alto impacto como candidatas a supervisão. Não é uma regra pronta para atendimento brasileiro, mas a disciplina é boa: tentativa não pode ser infinita e risco alto não pode depender só da confiança do modelo.
Não existe apenas “ligado” e “desligado”
Separe quatro níveis de intervenção:
1. Observar
Há um caso isolado, baixo risco, com estado confirmado. Registre e acompanhe uma amostra maior.
2. Limitar
Reduza tentativas, volume, horário, público, ferramenta ou tipo de ação. O agente continua dentro de um espaço menor.
3. Pausar seletivamente
Bloqueie uma intenção ou ferramenta afetada. O agente ainda pode responder temas seguros e encaminhar o restante.
4. Pausar o agente
Interrompa toda resposta ou execução automática quando a falha atravessa base, identidade, autorização, roteamento ou várias ferramentas — ou quando não existe saída humana confiável.
Essa separação evita dois erros comuns: continuar tudo por medo de afetar volume ou desligar tudo sem preparar o atendimento que recebe a demanda.
O alcance da pausa precisa caber numa frase
Antes de apertar qualquer botão, escreva o que está sendo interrompido.
Exemplos:
- “Pausar cancelamento pelo WhatsApp; manter consulta de status.”
- “Bloquear respostas sobre reajuste até publicar a regra corrigida.”
- “Desativar chamada da agenda; coletar pedido e abrir retorno humano.”
- “Pausar o agente de voz inteiro porque identidade e gravação não estão confiáveis.”
Se ninguém consegue descrever o alcance, duas coisas ruins acontecem. A pausa fica menor do que o incidente e deixa uma rota de erro aberta. Ou fica maior e remove serviço que ainda poderia ajudar o cliente.
Modo degradado é atendimento menor, não improviso maior
A AWS chama de degradação graciosa o desenho em que um componente continua oferecendo sua função principal, mesmo quando uma dependência falha, de forma previsível e recuperável.
No atendimento, isso pode significar:
- responder apenas informações aprovadas e estáticas;
- coletar identificação e motivo sem executar ação;
- criar protocolo para retorno;
- passar casos de risco para uma fila específica;
- informar indisponibilidade e prazo realista;
- manter consulta enquanto escrita está bloqueada;
- retirar a IA e deixar um menu simples com saída humana.
Modo degradado não é pedir ao agente para “tentar ajudar como puder”. É o oposto. É reduzir o que ele pode fazer.
Uma mensagem possível:
Não consigo confirmar esta alteração agora. Registrei seu pedido no protocolo 4821 e a equipe responsável continua por este WhatsApp até 16h. Você não precisa enviar os dados novamente.
Se a fila não consegue responder até 16h, não prometa 16h. Incidente técnico não melhora com prazo decorativo.
O botão de pausa não pode morar só no prompt
Escrever “pare em caso de risco” na instrução é útil, mas insuficiente.
A OWASP descreve agência excessiva como uma combinação de funcionalidade, permissão ou autonomia além do necessário. Entre as medidas recomendadas estão reduzir ferramentas e permissões, exigir aprovação humana para ações de alto impacto e aplicar autorização no sistema que executa a ação — não deixar a decisão apenas para o modelo.
Traduzindo para a operação:
- bloqueie a ferramenta no sistema, não apenas com uma frase;
- retire permissão de escrita quando só leitura é necessária;
- exija confirmação externa para cobrar, cancelar, reembolsar ou publicar;
- mantenha limite de taxa e de tentativas;
- registre quem pausou, quando, por quê e qual versão estava ativa;
- preserve uma forma manual de atender sem devolver poder ao agente por improviso.
O agente pode participar da decisão de parar. A trava final precisa sobreviver mesmo se ele interpretar a instrução errado.
Plano de pausa e retomada
Abra o plano de pausa e retomada do agente de IA e preencha para uma ação real. Escolha algo que pode causar consequência: alterar cadastro, marcar horário, cancelar, cobrar, enviar mensagem ou prometer prazo.
Erro repetido, estado incerto, resposta sem fonte, loop, risco ou pedido humano precisam de limite observável.
Ferramenta, intenção, canal, grupo de clientes, horário, fila ou agente inteiro.
Mensagem honesta, protocolo, coleta mínima, canal de retorno, prazo e saída humana.
Separe autoridade para pausar, responsável técnico, líder da operação e dono da fila afetada.
Versão, conversas, ferramentas, ações, estados e mensagens precisam permitir reconciliação.
Correção identificada, testes ruins aprovados, amostra pequena, monitoramento reforçado e possibilidade de voltar atrás.
Fluxo de pausa e retomada
Retomar exige mais do que o erro ter sumido
“Testei aqui e funcionou” não é critério suficiente.
Antes de retomar, confirme:
- a causa foi identificada ou o risco foi realmente contido;
- as ações durante o incidente foram reconciliadas;
- a correção está ligada a uma versão conhecida;
- o caso que falhou agora passa;
- os casos vizinhos continuam funcionando;
- timeout, resposta atrasada e duplicidade foram testados;
- fila humana e mensagem de contingência continuam disponíveis;
- monitoramento está mais sensível durante a retomada;
- existe autoridade para pausar de novo sem reunião extraordinária.
Retome em uma amostra pequena. Uma intenção, um canal, um turno ou uma porcentagem do volume. Se o único plano é liberar tudo e torcer com mais atenção, ainda não existe retomada controlada.
O NIST AI RMF trata gestão de risco como trabalho contínuo de mapear, medir, gerir e governar. Para este caso, isso significa que incidente não termina quando a resposta volta ao normal. Termina quando a operação sabe o que aconteceu, quem foi afetado, qual controle mudou e como vai detectar a repetição.
Quatro testes antes do próximo go-live
| Teste | O que deve acontecer |
|---|---|
| ferramenta falha várias vezes | tentativas param no limite e a ação é bloqueada |
| resposta perde a fonte aprovada | o tema é suspenso ou passa para revisão |
| ação de alto impacto aparece | sistema exige aprovação fora do modelo |
| fila humana fica indisponível | agente reduz escopo e não promete passagem inexistente |
Acrescente um quinto teste próprio: o erro mais constrangedor que já aconteceu na operação. Ele costuma ensinar mais do que outro caso feliz.
Quando uma planilha e uma chave manual bastam
O caminho simples é suficiente quando:
- há um ou poucos agentes;
- uma pessoa acompanha alertas no mesmo turno;
- ferramentas de risco já exigem confirmação humana;
- a operação consegue bloquear uma ação sem deploy complexo;
- o volume afetado pode ser localizado e revisado;
- existe uma fila humana capaz de absorver o modo degradado;
- a retomada pode começar com poucos casos.
Nesse estágio, mantenha o plano numa página acessível, teste a chave de pausa toda semana e registre cada uso. Uma chave que nunca foi testada é mais decoração do que controle.
Onde começa a quebrar
A coordenação manual começa a falhar quando:
- vários agentes usam as mesmas ferramentas;
- versões diferentes atendem ao mesmo tempo;
- uma falha atravessa voz, WhatsApp, CRM e agenda;
- ninguém consegue localizar todas as ações afetadas;
- cada fila recebe uma mensagem diferente durante o incidente;
- pausa e retomada dependem de uma única pessoa;
- a operação não sabe qual versão estava ativa;
- QA não consegue comparar antes e depois;
- a retomada precisa ser gradual, monitorada e reversível.
Aí o problema não é encontrar um botão vermelho bonito. É operar supervisão, autorização, observabilidade, handoff e evidência como parte do agente.
O que fazer agora
Escolha uma ação que o agente executa. Preencha o plano de pausa e retomada. Depois simule três coisas: ferramenta indisponível, resposta sem evidência e fila humana lotada.
Se a falha envolve uma chamada com resultado incerto, leia Falha de ferramenta em agente de IA: como recuperar. Se os casos pausados viram trabalho humano, use Fila de exceções: o trabalho que a IA devolve. Para uma bateria mais ampla, abra O teste da IA não é a demo. É a fila cheia..
Se uma pessoa consegue pausar, localizar os poucos casos e retomar uma amostra, resolva sem contratar.
Quando há vários agentes, ferramentas, versões e filas, e a operação precisa detectar, conter, atender, reconciliar, testar e retomar com evidência, Zild pode fazer sentido. Antes da conversa comercial, faça o teste menos elegante e mais útil: desligue uma ação de propósito e veja se o atendimento continua sabendo o que fazer.
Se você prefere ver em vídeo
Eu não encontrei um vídeo em português que eu colocaria como resposta principal para esta rotina. Há material sobre kill switch, circuit breaker e segurança de agentes. Pouco mostra a operação completa: cliente no canal, ferramenta falhando, pausa seletiva, fila humana, reconciliação e retomada por amostra.
Um vídeo útil teria que quebrar o agente de propósito e provar que o modo degradado funciona. Se bastante gente pedir, este assunto entra na fila de gravação. Não é promessa.