Pular para conteúdo

Capítulo 5.6 — Incident response e runbooks

🎯 Objetivo

Garantir que, quando um incidente de IA acontecer - e ele vai acontecer -, exista caminho conhecido para diagnóstico, mitigação, comunicação e postmortem. Sem runbook, todo incidente vira invenção sob estresse.

🧠 Componentes de runbook

  • Quando acionar. Sinais que disparam (alertas, reclamações, métrica em SLO).
  • Diagnóstico inicial. Quais dashboards abrir, quais queries rodar, quais traces buscar. Idealmente, links diretos.
  • Ações de mitigação. Rollback (modelo, prompt, tool, policy); kill switch (desativar agente ou tool); fallback (rota alternativa); failover de provider.
  • Comunicação. Quem avisar, em qual canal, com qual mensagem inicial.
  • Postmortem. Formato (blameless), prazo (geralmente 5 dias úteis), itens obrigatórios (timeline, impacto, causa, contramedidas, ações de prevenção).

🧰 Cenários típicos com playbook próprio

  • Alta taxa de fallback em agente de suporte.
  • Aumento de custo súbito (loop, prompt grande, retries).
  • Cross-tenant leakage detectado.
  • Indirect prompt injection com efeito observado.
  • Modelo do provedor degradou após release dele.
  • Tool externa fora do ar durante horário de pico.
  • Indexing lag acima do SLA com documentos críticos desatualizados.

🧠 Diferença entre incidente, bug e mudança de comportamento

Em IA, mudança de comportamento após nova versão de modelo, prompt ou índice não é bug, mas pode causar incidente. Tratar todo desvio como bug leva a regressões inúteis. Tratar todo desvio como "é assim mesmo" leva a degradação silenciosa. A diferença operacional: regressão é mensurável contra eval; mudança sem regressão é decisão de produto.

🧰 Exemplos práticos relacionados (planejados)

  • EX-OPS-01 - runbook de incidente "alta taxa de fallback em agente de suporte".

🏢 Hermes Logística - onda 5

Em uma quinta-feira, a fatura semanal de LLM da Hermes pulou 4x. O alerta de custo por tenant disparou, e o trace mostrou um único agente em loop: a tool de busca interna devolvia "resultado truncado", o agente retentava com prompt maior, batia no limite, retentava de novo. O fix imediato: circuit breaker por agente + max_steps reduzido. O fix estrutural: budget por agente como contrato, não como sugestão. O incidente terminou em um runbook permanente; o eval de agentes ganhou um caso de regressão para "tool com resultado truncado". A lição: observabilidade só vale se houver gatilho e runbook.