Engenharia do caos para agentes de IA

Um plano de contingência ainda precisa sobreviver ao teste

A equipe documenta que o agente deve manter a fila quando o CRM fica indisponível. O runbook indica um modo somente leitura, um responsável técnico e um caminho manual para casos urgentes. No papel, a resposta está resolvida.

Quando a integração falha de verdade, o agente repete chamadas, perde o estado de algumas tarefas e continua informando conclusão porque a API respondeu antes de confirmar a gravação. A fila humana recebe casos sem contexto suficiente. O plano existia, mas vários componentes nunca tinham sido exercitados juntos.

Engenharia do caos para agentes de IA usa falhas controladas para verificar como o serviço se comporta sob condições adversas. A equipe formula uma hipótese, limita o alcance, injeta uma perturbação conhecida, observa o processo completo e corrige o que a evidência revelar.

O objetivo consiste em encontrar fragilidades antes que uma indisponibilidade real as combine com volume, pressão e falta de tempo. O exercício precisa proteger clientes, dados e sistemas oficiais. Caos sem limite é só incidente patrocinado pela própria empresa.

Onde a engenharia do caos entra no ciclo de operação

Várias práticas próximas cumprem trabalhos diferentes.

O ambiente de teste para agentes de IA cria uma fronteira segura para dados, credenciais, integrações e versões. Ele responde onde cenários podem ser exercitados sem produzir consequências externas.

O plano de contingência para agentes de IA define como o processo mantém entrada, prioridade, capacidade mínima e registro durante uma interrupção.

O red team para agentes de IA procura caminhos adversariais em identidade, instruções, dados, ferramentas e permissões.

A engenharia do caos verifica se o sistema tolera falhas operacionais previstas e se os controles respondem como projetado. Seu artefato central é um experimento com hipótese, estado estável, perturbação, raio de impacto, critérios de aborto, observações e correções.

Ela pode começar em homologação. Experimentos em produção exigem maturidade, isolamento, monitoramento e autorização proporcional ao risco.

Comece pelo serviço que precisa continuar

Desligar um componente e observar alertas mede pouco. O exercício deve acompanhar uma unidade de trabalho reconhecível pela empresa.

Exemplos:

chamado recebido, classificado e encaminhado;
oportunidade comercial com próxima ação registrada;
documento extraído e entregue para conferência;
pedido validado e confirmado no sistema;
obrigação financeira preparada para aprovação;
agendamento concluído sem duplicidade.

Para a unidade escolhida, descreva o estado estável antes de criar a falha:

volume e mistura normal de casos;
prazo por classe;
taxa de conclusão válida;
filas técnicas e humanas;
erros impeditivos;
custo e tentativas por unidade;
dependências essenciais;
modo degradado disponível;
evidência que confirma o resultado.

Estado estável não significa ausência total de erro. Ele descreve uma faixa observada e aceitável do serviço. Sem essa linha de base, qualquer reação parece interessante e nenhuma conclusão mostra deterioração real.

Formule uma hipótese verificável

Uma hipótese útil liga a falha a um comportamento esperado.

Exemplo fraco:

Vamos desligar o CRM para ver o que acontece.

Exemplo verificável:

Se a escrita no CRM ficar indisponível por dez minutos, o agente deve interromper novas gravações após o limiar definido, preservar cada unidade com identificador e estado, continuar preparando casos de leitura e encaminhar oportunidades prioritárias para a fila manual. Nenhuma ação pode ser declarada concluída sem confirmação do destino.

A hipótese precisa incluir:

componente ou condição perturbada;
serviço e classes de caso afetadas;
resposta automática esperada;
comportamento humano esperado;
sinais que comprovam contenção;
limite de dano aceitável;
condição para interromper imediatamente;
evidência necessária para encerrar o teste.

A frase deve permitir reprovação. Se qualquer resultado puder ser explicado como aprendizado, o experimento virou uma demonstração sem critério.

Escolha falhas que representam a arquitetura real

Agentes dependem de modelos, dados, ferramentas, filas, pessoas e políticas. O programa de testes precisa variar as camadas.

Modelo indisponível ou lento

Simule erro, latência elevada, resposta truncada ou limite de taxa. Observe se o agente respeita timeout, tenta uma rota aprovada, reduz escopo ou preserva a tarefa para retomada.

O fallback precisa manter o contrato da responsabilidade. Trocar para outro modelo e perder saída estruturada, limite de contexto ou suporte a ferramenta pode apenas deslocar a falha.

Fonte de dados atrasada

Entregue uma cópia tecnicamente acessível, mas fora da janela de validade. Verifique se a arquitetura reconhece idade, consulta a fonte oficial, bloqueia a decisão ou encaminha o caso.

Esse cenário encontra sistemas que medem disponibilidade da consulta e ignoram utilidade do dado.

Integração com estado incerto

Faça a ferramenta executar a ação e perder a confirmação. O agente deve reconciliar o destino antes de repetir. Sem esse controle, uma falha de rede pode gerar mensagem, pedido, tarefa ou cobrança duplicada.

O guia sobre idempotência em agentes de IA detalha a unidade de efeito, a chave estável e o tratamento do intervalo entre execução e confirmação.

Credencial expirada ou revogada

Verifique se a falha aparece como acesso indisponível, sem tentativa de contorno com outra identidade mais ampla. O alerta deve indicar agente, ferramenta, escopo, responsável e impacto no serviço.

Fila saturada

Aumente entradas dentro de um limite controlado ou reduza workers disponíveis. Observe prioridade, idade, expiração, pressão sobre dependências e tempo de drenagem. Tarefas críticas precisam manter reserva de capacidade.

Aprovador indisponível

Remova temporariamente uma pessoa ou alçada no ambiente de exercício. Confirme substituição autorizada, prazo de espera, escalonamento e bloqueio de ações que não podem seguir sem decisão.

Observabilidade parcial

Interrompa um coletor ou torne um painel indisponível. O teste precisa mostrar se a operação continua agindo sem evidência suficiente. Em certas responsabilidades, perder a capacidade de confirmar e investigar deve reduzir autonomia.

Falha combinada

Experimentos iniciais devem perturbar uma camada por vez. Depois de estabilizar respostas, combine condições plausíveis, como modelo lento durante pico de demanda ou CRM indisponível com fila humana reduzida.

Falhas combinadas revelam dependências que testes isolados não mostram. Também ampliam risco. Use um raio menor e critérios de aborto mais conservadores.

Limite o raio de impacto antes de executar

Raio de impacto descreve até onde o teste pode alcançar. Defina tecnicamente, sem depender apenas da intenção da equipe.

Possíveis fronteiras:

ambiente de homologação;
conta ou tenant fictício;
um agente e uma versão;
uma ferramenta específica;
somente operações de leitura;
uma classe de tarefa de baixo risco;
volume máximo de unidades;
janela curta com equipe disponível;
destinatários internos controlados;
dados sintéticos ou históricos anonimizados.

Quando o teste ocorrer em produção, use controles como flags, roteamento por grupo, limite de volume, conta dedicada e bloqueio de efeitos irreversíveis. O agente não deve conseguir ampliar o experimento por decisão própria.

Exclua pagamentos, exclusões, alteração contratual, dados sensíveis e comunicação externa quando a hipótese puder ser validada sem essas consequências. Se uma capacidade crítica precisar entrar, a autorização e o caminho de interrupção devem ter sido testados antes.

Defina critérios de aborto objetivos

O responsável pelo exercício precisa conseguir parar sem negociar interpretação no meio da falha.

Critérios possíveis:

qualquer mistura de dados entre clientes;
ação externa não autorizada;
perda de identificador ou estado da unidade;
duplicidade confirmada;
fila acima do limite seguro;
propagação para componente fora do escopo;
monitoramento essencial indisponível;
aumento de erro crítico;
incapacidade de acionar o modo degradado;
responsável pelo processo solicita interrupção.

O procedimento de aborto deve informar como remover a perturbação, bloquear novas entradas, preservar evidência, tratar execuções em andamento e confirmar retorno ao estado estável.

Um botão que encerra o script de teste pode não parar workers, agendadores, filas e retentativas. A página sobre kill switch para agentes de IA ajuda a verificar interrupção por camada.

Prepare o experimento como uma mudança controlada

Cada rodada deve ter uma ficha operacional.

Escopo

Registre serviço, agente, versão, ambiente, componentes, público, volume e duração.

Donos

Nomeie condutor, dono do processo, responsável técnico, observador e autoridade de aborto. Em operações sensíveis, inclua segurança, privacidade ou responsável regulatório quando aplicável.

Pré-condições

Confirme backup ou estado recuperável, fila vazia ou conhecida, alertas ativos, credenciais de teste, comunicação interna, contingência disponível e acesso aos painéis.

Perturbação

Descreva o mecanismo exato: bloquear endpoint, acrescentar latência, devolver código específico, limitar worker, expirar credencial de homologação ou retirar um aprovador fictício.

Observações

Liste sinais técnicos e de negócio. Inclua tempo de detecção, unidades afetadas, fila, tentativas, estado, escalonamentos, confirmações e carga humana.

Encerramento

Defina como restaurar, reconciliar, validar o estado estável e decidir se o experimento passou, falhou ou ficou inconclusivo.

O controle de mudanças em agentes de IA deve versionar alterações feitas para corrigir os achados.

Observe o processo inteiro durante a falha

Um alerta disparado não prova resiliência. A operação precisa completar ou encaminhar o trabalho de forma conhecida.

Acompanhe quatro grupos de sinais.

Detecção

tempo até perceber a condição;
origem do alerta;
componente e serviço identificados corretamente;
ausência de falsos positivos que escondam a falha principal.

Contenção

novas chamadas interrompidas no momento previsto;
escopo da falha preservado;
retentativas e fan-out controlados;
ações perigosas bloqueadas;
dados e identidades isolados.

Continuidade

entradas preservadas;
classes críticas priorizadas;
modo degradado ativado;
pacote entregue à equipe;
comunicação coerente com o serviço disponível;
capacidade manual dentro da faixa planejada.

Recuperação

dependência restaurada;
backlog drenado sem nova saturação;
ações manuais reconciliadas;
duplicidades evitadas;
estados incertos resolvidos;
métricas retornando à faixa normal.

Logs precisam chegar até a unidade individual. Uma curva agregada mostra que o serviço piorou. O trace explica por que uma oportunidade específica sumiu ou recebeu duas tarefas.

Transforme achados em correções com dono

O relatório do exercício deve evitar uma lista genérica de observações. Cada achado precisa apontar para mecanismo, consequência e decisão.

Registre:

| Campo | Pergunta | |---|---| | evidência | o que aconteceu e em quais unidades? | | hipótese | qual comportamento esperado falhou? | | camada | entrada, dado, modelo, fila, ferramenta, política, pessoa ou monitoramento? | | impacto | que prazo, qualidade, risco ou capacidade foi afetado? | | correção | qual mudança reduz a fragilidade? | | dono | quem responde pela mudança? | | prazo | quando a correção deve estar validada? | | regressão | qual teste impedirá retorno do problema? | | decisão | repetir, ampliar, manter limitado ou encerrar? |

Uma correção só entra como concluída depois de novo teste. Atualizar o runbook sem exercitar o caminho mantém a incerteza original.

Achados também podem mudar a arquitetura. Talvez o fallback não preserve qualidade. Talvez o CRM concentre dependência demais. Talvez a fila humana não suporte o volume. Talvez o agente precise perder autonomia quando a trilha de auditoria falha.

Crie uma progressão de exercícios

Comece pequeno e aumente complexidade conforme a equipe demonstra controle.

Nível 1: mesa

Os responsáveis percorrem um cenário, decisões, acessos e comunicação. O exercício encontra donos ausentes, links quebrados e critérios ambíguos sem alterar sistemas.

Nível 2: componente isolado

A equipe injeta falha em sandbox ou mock e confirma timeout, retentativa, estado e alerta.

Nível 3: fluxo em homologação

A unidade completa atravessa agente, filas, ferramentas simuladas, aprovação e reconciliação.

Nível 4: produção limitada

Uma classe reversível, pequeno volume e janela acompanhada recebem perturbação controlada. O modo degradado e a recuperação são observados com dados reais dentro das permissões.

Nível 5: exercício combinado

Dependências e capacidade humana são reduzidas ao mesmo tempo, dentro de um escopo estreito. Esse nível exige histórico de testes, monitoramento confiável e poder de interrupção comprovado.

Avançar de nível depende de evidência. Um exercício bem apresentado não compensa estado perdido, alerta tardio ou reconciliação manual sem registro.

Métricas do programa de resiliência

Acompanhe:

experimentos planejados e executados;
hipóteses aprovadas, reprovadas e inconclusivas;
tempo de detecção;
tempo de contenção;
tempo de ativação do modo degradado;
unidades perdidas, duplicadas ou vencidas;
percentual de entradas preservadas;
tempo de recuperação e drenagem;
achados por camada;
correções abertas e validadas;
recorrência de achados;
cobertura de dependências críticas;
data do último exercício por serviço;
procedimentos que falharam por acesso ou dono ausente.

Quantidade de testes não representa maturidade. O indicador útil mostra se falhas conhecidas permanecem contidas, se o processo continua legível e se as correções reduzem recorrência.

Erros comuns

Testar sem estado estável

A equipe injeta a falha sem conhecer volume, prazo e qualidade normais. O resultado gera discussão, mas não mostra deterioração.

Usar produção como primeiro laboratório

Falhas básicas de timeout, permissão e fila podem ser exercitadas em ambiente controlado. Produção limitada entra depois que isolamento e recuperação já funcionam.

Medir apenas infraestrutura

CPU, latência e códigos de erro ajudam a diagnosticar. O serviço precisa mostrar unidades preservadas, prazos, qualidade, filas humanas e confirmação no destino.

Ignorar pessoas

Contingência costuma transferir trabalho. Se o aprovador, operador ou responsável não sabe agir, a arquitetura falhou mesmo com todos os componentes técnicos disponíveis.

Encerrar quando o sistema volta

Recuperação inclui backlog, tarefas intermediárias, ações manuais e estados divergentes. Voltar a receber chamadas não prova que a operação está reconciliada.

Repetir o mesmo cenário

Um teste conhecido pode virar coreografia. Varie camada, duração, ordem, classe de tarefa e horário dentro dos limites autorizados.

Checklist antes do experimento

[ ] A unidade de trabalho e o estado estável estão definidos?
[ ] Existe uma hipótese que pode reprovar?
[ ] A falha representa uma dependência real?
[ ] Ambiente, público, volume e duração limitam o raio?
[ ] Consequências irreversíveis estão bloqueadas?
[ ] Condutor, dono do processo e autoridade de aborto foram nomeados?
[ ] Critérios de aborto são objetivos?
[ ] Monitoramento técnico e operacional está ativo?
[ ] O modo degradado pode ser acionado?
[ ] Entradas e execuções em andamento preservarão estado?
[ ] A remoção da perturbação foi ensaiada?
[ ] Existe procedimento de reconciliação?
[ ] Cada achado receberá dono, prazo e teste de regressão?
[ ] A decisão de repetir ou ampliar será registrada?

Resiliência precisa de evidência produzida sob falha

Documentação mostra a resposta planejada. Um experimento controlado mostra como agentes, integrações, filas, políticas e pessoas respondem quando uma condição real sai da faixa.

Engenharia do caos cria essa evidência com limites. A empresa começa por um serviço, define estado estável e hipótese, reduz o raio, injeta uma falha conhecida e acompanha detecção, contenção, continuidade e recuperação.

Os achados mostram onde existe fragilidade prática. Corrigir e repetir o exercício transforma o plano de contingência em capacidade operacional testada, antes que a combinação de falha, volume e pressão decida o resultado pela empresa.