Saltar para o conteúdo
Se não funciona, não pagas. 30 dias.
Implementa.

Solução · AI Operations

Gestão de incidentes dos agentes de IA: a função que responde quando algo se parte em produção — triagem, prevenção, rollback e postmortem — e não quando o cliente reclama

A monitorização deteta que algo está mal; alguém tem de responder. Sem uma função de gestão de incidentes, cada falha de um agente em produção é uma corrida improvisada: ninguém sabe quem responde, que severidade tem, se se faz rollback ou se aguenta, nem porque voltou a acontecer na semana seguinte. Isto não é apagar um fogo uma noite; é a função que corre — severidades, prevenção, runbooks, rollback, causa raiz e ações corretivas — para que um incidente de IA se resolva depressa e não se repita.

O problema

Quando um agente falha em produção, ninguém sabe quem responde, com que prioridade, nem como se fecha para não voltar

  • O incidente resolve-o quem estava a ver, à mão e de memória: não há severidades, nem prevenção, nem runbook, por isso a mesma falha recebe uma resposta diferente conforme quem a apanha.
  • A decisão de fazer rollback ou aguentar toma-se a quente e sem critério: às vezes deixa-se um agente partido a dar respostas más horas, às vezes deita-se abaixo toda a produção por uma falha menor.
  • Não há causa raiz nem postmortem: apaga-se o fogo, respira-se e segue-se — até o mesmo incidente voltar na semana seguinte porque ninguém fechou a ação corretiva.
  • O custo do incidente é invisível até ser enorme: respostas más a clientes, um ciclo de agente que dispara a fatura, ou uma ação errada sobre um sistema real, sem ninguém que meça quanto demora a detetar e a resolver.

O custo de continuar igual

Um agente em produção sem gestão de incidentes não é um que não falha — é um em que, quando falha, o dano corre livre enquanto alguém improvisa a resposta. A diferença entre um incidente de dez minutos e um de dois dias não é a sorte: é ter ou não a função que responde. E um incidente que não se fecha com uma causa raiz não é um incidente, são todos os que vêm: o que não se aprende, repete-se, e cada repetição é a mesma fatura — em confiança do cliente, em custo e no tempo da equipa que reapaga o mesmo fogo.

A solução

Uma função de resposta a incidentes para os teus agentes: severidades, prevenção, runbook, rollback e postmortem — montada e a operar

  1. 1Definimos severidades e classificação: o que é um incidente crítico (um agente que age mal sobre um sistema real ou dispara o custo) face a um menor, para que a resposta seja proporcional e não dependa de quem o apanha.
  2. 2Montamos a prevenção e a escalada: quem responde, em que ordem e com que runbook por tipo de incidente — incluindo o rollback seguro do agente, do prompt ou do modelo à última versão boa — com o contexto já recolhido da monitorização.
  3. 3Fechamos cada incidente com causa raiz e postmortem: o que aconteceu, porquê, que ação corretiva evita que volte, e quem a tem. A ação segue-se até estar feita, não até se esquecer.
  4. 4Deixamo-la com um painel: tempo até detetar, tempo até resolver (MTTR), incidentes por severidade e % de recorrência. Uma função que corre, não um herói de prevenção a queimar-se.

O que muda

O que deixas de perder

  • O incidente resolve-se por processo, não por quem estava a ver: severidade, runbook e prevenção dão à mesma falha a mesma resposta rápida sempre.

    Mecanismo

  • A falha deixa de se repetir porque cada incidente se fecha com uma causa raiz e uma ação corretiva com dono e seguimento, não com um «pronto, seguimos».

    Mecanismo

  • O que medimos: tempo até detetar, tempo até resolver (MTTR), incidentes por severidade e % de incidentes recorrentes.

    O que medimos

Ficha técnica

Trabalho que elimina
responder às falhas dos agentes em produção à toa, sem severidade, sem runbook e sem fechar a causa raiz
Implementação habitual
2–4 semanas
Entrada
um alerta da monitorização ou uma falha de um agente em produção
Saída
incidente triado, tratado por runbook (com rollback se preciso) e fechado com uma causa raiz e uma ação corretiva com um responsável
Compatível com
PagerDutyOpsgenieJira
Pode ligar-se a
Os teus agentes e os seus registos de produçãoA tua monitorização / observabilidade de IAO teu gestor de incidentes ou ticketingO teu canal de alertas e a tua escala de prevenção
O que medimos
tempo para detetar um incidentetempo para resolver (MTTR)incidentes por severidade% de incidentes recorrentes
Adequado para
empresas com agentes de IA em produção que já monitorizam mas respondem aos incidentes à toa, sem severidades, prevenção nem postmortem
Não adequado para
a deteção em direto do problema (isso é a monitorização, a montante) e a decisão de negócio do que o agente faz, que fica na tua equipa

Perguntas frequentes

São complementares e consecutivas, não a mesma coisa. A monitorização é a montante: vigia em direto latência, custo, falhas e desvio, e lança o alerta quando algo se desvia. A gestão de incidentes é o que acontece depois desse alerta: quem responde, com que severidade, que runbook se segue, se se faz rollback e como se fecha com uma causa raiz para não voltar. Monitorizar sem gestão de incidentes é ter alarmes que ninguém sabe atender; gerir incidentes sem monitorização é responder às cegas. Montam-se juntas, e por isso ambas apontam para o chapéu de AI Operations.

Estar atento não é uma função; é uma pessoa a queimar-se e um processo que se parte no dia em que essa pessoa está de férias. Uma função de incidentes a sério dá o que a boa vontade não pode: severidades para que a resposta seja proporcional, prevenção para que haja sempre quem responda, runbooks para que a falha se resolva igual seja quem for que a apanha, e postmortems para que se aprenda. A diferença entre um incidente de dez minutos e um de dois dias não é a atenção; é ter o processo montado antes de acontecer.

Corre. Não te entregamos um PDF de «política de incidentes» e adeus: montamos as severidades, a prevenção e a escalada no teu gestor de incidentes, os runbooks de resposta e o rollback seguro ligados aos teus agentes, e o ciclo de postmortem com as ações corretivas seguidas até fechar. E deixamo-la com um painel — MTTR, incidentes por severidade, recorrência — para que vejas a função a operar, não a existir num documento. Uma função com dono, não um manual numa gaveta.

Montamos no teu negócio?

Localizaste o problema. Nós entregamos a solução e deixamo-la medida.

Ver o serviço
Gestão de incidentes dos agentes de IA: a função que responde quando algo se parte em produção — triagem, prevenção, rollback e postmortem — e não quando o cliente reclama · Implementa