Como o aceite de incidentes por IA deve mantê-los abertos

Um agente que aceita um alerta fez apenas uma afirmação útil: alguém ou algum sistema assumiu a responsabilidade de investigar. O agente não provou que os clientes voltaram ao normal, que a condição do alerta desapareceu nem que o próximo responsável pode deixar o plantão. Qualquer integração que transforme o aceite em encerramento destrói essa distinção e registra uma ficção no histórico do incidente.

Trate as ações de incidentes como transições de estado separadas, com permissões próprias. Aceitar, resolver, suprimir e encaminhar podem aparecer lado a lado na interface do sistema de plantão, mas respondem a perguntas operacionais diferentes. Um agente deve chamar a ação mais restrita, uma pessoa deve aprovar a transição de maior consequência quando a política exigir, e a trilha de auditoria deve identificar os dois atores.

O aceite registra responsabilidade, não recuperação

Aceitar significa que uma pessoa assumiu o alerta e começou a investigar. Isso muda quem deve agir e muitas vezes altera o comportamento da escalação. Não diz se a falha ainda existe.

A documentação Incidents do PagerDuty torna a distinção explícita: um incidente aceito está sendo investigado, mas ainda não foi resolvido. O aceite assume a responsabilidade e interrompe a escalação até o fim de um prazo; a resolução significa que o problema foi corrigido. Esse prazo importa. Se ninguém resolver o incidente antes do vencimento, o PagerDuty pode devolvê-lo ao estado triggered e retomar a escalação. Um agente que feche o incidente no aceite remove silenciosamente esse mecanismo de segurança.

O Google Cloud Monitoring usa termos um pouco diferentes, mas preserva a mesma fronteira. Sua documentação define Acknowledged como um incidente aberto que alguém marcou manualmente enquanto investigava. Ela também diz que o aceite não interrompe notificações repetidas. Uma pausa ou alteração de política controla essas notificações, enquanto o encerramento ocorre após observações de recuperação, um fechamento manual ou uma condição automática. O comportamento do produto mostra por que não se deve presumir que todos os verbos de um sistema de plantão tenham os mesmos efeitos colaterais.

O contrato prático deve ser direto: acknowledge registra a pessoa designada, a hora do aceite e o ator que assumiu o trabalho. A ação pode pausar um caminho de escalação se o sistema oferecer esse comportamento. Ela deve manter aberto o estado de recuperação do incidente, preservar os alertas ativos e não alterar regras de notificação ou encaminhamento, a menos que o chamador solicite outra ação por outro controle.

Essa fronteira também protege as métricas. Se o aceite fecha o registro, o tempo para aceitar e o tempo para recuperar viram o mesmo horário. A equipe passa a premiar cliques rápidos e perde a medida que indica por quanto tempo os usuários realmente sofreram. As análises posteriores herdam o mesmo erro, pois a linha do tempo afirma que a recuperação ocorreu antes da mitigação.

Um verbo do agente deve gerar uma transição

Cada ferramenta de agente deve expor um verbo operacional e um efeito principal. Ações agrupadas parecem convenientes durante uma revisão tranquila, mas ficam impossíveis de analisar em meio a uma falha.

Aceitar responde quem assumiu o trabalho. Seu efeito principal é registrar a responsabilidade e o horário, sem implicar recuperação do serviço ou limpeza do alerta. Resolver responde se o incidente terminou. Essa ação encerra o registro após a obtenção de provas de recuperação e não deve silenciar alertas futuros nem mudar o responsável como efeito colateral.

Suprimir responde se um sinal selecionado deve criar ou notificar um incidente. Essa ação impede certas notificações ou a criação de incidentes em um escopo definido, mas não recupera um incidente já aberto. Encaminhar responde quem deve receber ou assumir o trabalho. Essa ação muda serviço, equipe, caminho de escalação ou responsável sem afirmar que o destino aceitou ou resolveu o incidente.

Essas definições formam uma fronteira de autorização. Uma pessoa pode aceitar que o agente confirme qualquer alerta destinado à sua equipe, mas exigir aprovação humana para resolver. A mesma pessoa pode permitir supressão apenas durante uma janela de manutenção declarada e encaminhamento apenas entre dois serviços. Uma capacidade ampla manage_incident não consegue representar essas escolhas sem ramificações escondidas.

Evite uma ferramenta como handle_page com sinalizadores ack, mute, assign e close. Ela permite que o modelo escolha um pacote com base em texto, e uma frase mal interpretada pode selecionar várias mutações. Ferramentas separadas obrigam o chamador a declarar a intenção e permitem que o gateway autorize cada transição isoladamente.

A separação deve continuar nos adaptadores dos fornecedores. Se um fornecedor chama a ação de silenciar de snooze e outro de downtime, o adaptador pode mapear ambos para a intenção comum suppress_notifications. Ele não deve fingir que supressão e resolução são equivalentes só porque ambas podem deixar o sistema de plantão em silêncio.

Uma API segura torna combinações ilegais impossíveis

Um esquema de solicitação restrito evita mais incidentes do que uma instrução engenhosa. A solicitação abaixo pode aceitar um incidente existente e não consegue esconder uma operação de encerramento, silêncio ou reatribuição.

{
  "operation": "incident.acknowledge",
  "incident_id": "inc_01JQ8K4Q6M",
  "expected_version": 17,
  "actor": {
    "type": "agent",
    "session_id": "ses_01JQ8JY2P3"
  },
  "reason": "Accepted investigation after the database latency page"
}

O servidor, não o agente, deve acrescentar os fatos de identidade que consegue verificar. Um modelo pode fornecer um motivo, mas não deve declarar como verdade o próprio hash do executável, a identidade de assinatura de código, a conta de usuário ou o resultado da aprovação. O gateway deriva esses valores do processo autenticado e do canal de aprovação.

Uma resposta bem-sucedida deve descrever a transição exata e o estado que continua valendo:

{
  "operation_id": "op_01JQ8K5D7A",
  "incident_id": "inc_01JQ8K4Q6M",
  "transition": "triggered_to_acknowledged",
  "incident_status": "acknowledged",
  "recovery_status": "open",
  "version": 18,
  "approved_by": "usr_2048",
  "approved_at": "2026-07-24T02:14:31Z"
}

Retornar recovery_status: open pode parecer redundante. Mantenha o campo. Os agentes costumam raciocinar com base na última resposta recebida, e o estado explícito custa menos do que pedir a um modelo que deduza a semântica do fornecedor. A resposta também fornece uma afirmação estável para testes: o aceite funcionou e a recuperação continuou aberta.

Não aceite campos contraditórios de conveniência, como resolve_if_healthy, mute_for ou route_to, na solicitação de aceite. Esses campos transformam um endpoint em pacote novamente. Se o fluxo precisa de uma segunda ação, deve enviar outra solicitação, receber uma decisão separada e deixar outro evento de auditoria.

A aprovação pertence à transição

A aprovação deve autorizar uma mudança de estado descrita, e não liberar um agente em termos abstratos. A aprovação da sessão pode estabelecer que um processo conhecido pode funcionar, mas não deve autorizar automaticamente todas as mutações de incidentes encontradas depois.

Para cada transição, registre a operação proposta, o incidente alvo, o estado observado antes da decisão, o escopo pedido, a sessão do agente solicitante, a pessoa que aprovou, o momento e o método da aprovação. Acrescente a versão do estado ou o identificador de evento do fornecedor que a pessoa viu. Sem essa vinculação, um cartão exibido para o incidente A pode ser reutilizado no incidente B, ou uma aprovação concedida no estado triggered pode ser executada depois que outra pessoa resolveu o incidente.

A tela de aprovação deve usar linguagem operacional. Aceitar o incidente de latência do banco inc_01JQ8K4Q6M e atribuir a investigação ao plantão de Pagamentos permite uma revisão consciente. Permitir ação do agente não permite. Na resolução, mostre as provas de recuperação citadas pelo agente e diga o que permanece ativo. Na supressão, mostre o escopo exato do sinal, a duração e o vencimento. No encaminhamento, mostre o destino atual e o proposto.

Preserve quatro identidades em vez de reuni-las em um campo actor vago:

• O solicitante é a sessão do agente que propôs a mudança.
• Quem aprova é a pessoa que autorizou quando a aprovação era exigida.
• O executor é a identidade do gateway ou da integração que chamou o fornecedor.
• O objeto é o incidente, alerta, serviço ou rota que mudou.

Essas identidades respondem a perguntas diferentes durante a revisão. O solicitante explica por que a automação começou. Quem aprovou estabelece a autoridade humana. O executor liga o evento às credenciais e aos registros do fornecedor. O objeto impede que uma decisão válida migre para outro recurso.

O Sallyport pode exigir aprovação por chamada para ações de API HTTP e SSH quando uma chave armazenada assim determina, enquanto a credencial permanece no cofre criptografado e nunca chega ao agente. Esse mecanismo combina com transições de incidentes porque a aprovação pode ser vinculada à solicitação concreta ao fornecedor, e não a uma promessa livre feita pelo modelo.

Corridas transformam automação plausível em linha do tempo falsa

O estado do incidente muda enquanto o agente raciocina, espera aprovação ou repete uma chamada de rede. Um projeto que ignore esse atraso acabará aceitando um incidente resolvido, retirando trabalho de uma pessoa que já investiga ou aplicando uma supressão antiga depois do fim da manutenção.

Use concorrência otimista. O agente lê a versão 17, propõe o aceite contra a versão 17 e o gateway executa apenas se o registro do fornecedor ainda corresponder ao estado relevante. Se outra pessoa mudar o incidente primeiro, retorne um conflito que explique a diferença em vez de aplicar silenciosamente a operação ao novo estado.

{
  "error": "state_conflict",
  "incident_id": "inc_01JQ8K4Q6M",
  "expected_version": 17,
  "actual_version": 19,
  "actual_status": "resolved",
  "retryable": false
}

Não ensine o agente a repetir todos os conflitos. Um timeout de transporte pode justificar uma repetição idempotente com o mesmo identificador de operação. Um conflito de estado exige nova leitura e quase sempre outra decisão. Se o incidente já foi resolvido, o aceite está obsoleto. Se foi encaminhado a outra equipe, a aprovação original talvez não cubra o novo destino.

Uma falha comum começa com uma aprovação demorada. Um agente lê um alerta triggered do banco de dados e pede a Alice que aprove o aceite. Enquanto o cartão espera, Bob mitiga o problema e resolve o incidente. Alice aprova então o cartão antigo. Um adaptador ingênuo envia acknowledge, recebe um sucesso específico do fornecedor ou força o incidente de volta ao estado ativo, e registra Alice como responsável por um trabalho que já terminou. A vinculação com a versão interrompe a ação antes que a linha do tempo perca o sentido.

A idempotência resolve outro problema. Dê a cada transição proposta um ID de operação imutável e guarde o resultado. Se o gateway perder a resposta HTTP depois que o fornecedor aplicar o aceite, uma repetição retorna o resultado salvo em vez de acrescentar outra entrada à linha do tempo ou enviar outra notificação. O controle de concorrência protege a intenção contra um estado alterado; a idempotência protege uma intenção contra execução duplicada.

Encaminhamento e supressão precisam de permissões próprias

O encaminhamento muda quem carrega a responsabilidade, enquanto a supressão muda quais sinais produzem ruído. Nenhuma das ações comprova recuperação e nenhuma deve se esconder no aceite.

Encaminhe antes do aceite quando o serviço atual estiver claramente errado e ninguém tiver assumido o trabalho. Depois do aceite, tome cuidado, pois alguém já pode estar investigando. A transição deve informar se a responsabilidade muda, se a pessoa original continua inscrita e se a política de escalação do destino começa. O agente não pode deduzir esses efeitos pelo nome da equipe.

A supressão precisa de escopo e vencimento explícitos. A documentação Event Management do PagerDuty diz que alertas suprimidos permanecem disponíveis para análise, mas não criam incidentes. A documentação Event Orchestration também descreve o encaminhamento de eventos sem correspondência para um serviço ou sua supressão por uma rota padrão. Essas são decisões de entrada, não sinônimos de fechar um incidente aberto.

A documentação Downtimes do Datadog estabelece outra distinção útil: o período de inatividade silencia alertas e notificações, mas não impede transições de estado do monitor. Quando o período termina e o monitor ainda informa alerta, a notificação pode voltar. Esse costuma ser o comportamento desejado durante manutenção. O sistema lembra o estado não saudável em vez de reescrevê-lo como saudável só para interromper uma notificação.

Uma solicitação de supressão deve incluir seletor de sinal, horários de início e fim, motivo, criador e comportamento no vencimento. Seletores amplos, como um serviço inteiro, merecem aprovação mais rigorosa do que um grupo de monitores. Uma supressão sem prazo deve ser rejeitada ou exigir uma exceção explícita. O agente não pode criar uma falha silenciosa sem responsável.

Não suprima automaticamente depois do aceite apenas porque alguém assumiu o alerta. Alguns sistemas pausam a escalação no aceite; outros mantêm notificações repetidas. O Google Cloud Monitoring documenta expressamente que o aceite não interrompe essas notificações. Preserve o comportamento do fornecedor ou peça a supressão em separado para que a razão do silêncio permaneça visível.

A resolução deve seguir as provas, não a confiança do agente

Resolva apenas quando as provas de recuperação atenderem a uma condição declarada. O sucesso de um comando de correção prova que uma ação foi executada; não prova que o serviço se recuperou.

Essa distinção evita uma falha conhecida de automação. Um agente reinicia um processo, recebe código de saída zero e fecha o incidente. O processo começa, falha no teste de prontidão e cai novamente trinta segundos depois. O comando funcionou, mas o serviço nunca se recuperou. Fechar com base no sucesso do comando cria dois incidentes, dois alertas e um tempo de recuperação enganoso em vez de um evento contínuo.

Defina as provas de resolução perto do tipo de incidente. Um incidente de disponibilidade pode exigir que a condição de alerta desapareça e permaneça assim durante uma janela de avaliação. Um incidente de fila pode exigir que o volume pendente e a idade da mensagem mais antiga fiquem abaixo dos limites. Um alerta de certificado só deve ser resolvido quando o endpoint implantado apresentar o certificado esperado, e não quando um arquivo for escrito em uma máquina.

O agente pode reunir provas e propor a resolução. O gateway deve anexar à aprovação as observações, seus horários, suas fontes e eventuais lacunas. Se o monitor ainda informar uma condição ativa, rejeite o fechamento. O Google Cloud Monitoring adota essa postura para incidentes de métricas: sua documentação informa o erro Unable to close incident with active conditions quando dados recentes ainda violam a política.

A resolução manual continua tendo lugar. Monitores podem atrasar, a telemetria pode falhar, e uma pessoa pode saber que o serviço afetado foi retirado de propósito. Torne a exceção explícita com motivo e aprovador, e preserve a última observação não saudável. Uma exceção deve ser atribuível, não servir como motivo para enfraquecer a transição normal.

O comportamento de reabertura também pertence ao contrato. Diga se um sinal recorrente reabre o mesmo incidente ou cria outro e preserve os identificadores de correlação em ambos os casos. Um agente não deve presumir que resolve silencia o próximo evento. O PagerDuty diz que um incidente resolvido pode ser reaberto se houver mais trabalho, enquanto o Datadog documenta que a resolução manual só coloca o monitor em OK até a próxima avaliação. Uma nova avaliação não saudável pode alertar de novo.

A trilha de auditoria deve preservar a decisão

Os registros de atividade do fornecedor mostram que uma credencial de API chamou um endpoint. Raramente guardam contexto suficiente para explicar o que o agente propôs, o que uma pessoa aprovou e qual estado ela viu. Mantenha um registro de decisão separado e vincule-o ao evento do fornecedor.

Um evento completo de transição contém ID de operação imutável, hash da carga da solicitação, ação normalizada, alvo, estados anterior e posterior, identidade solicitante, identidade aprovadora, identidade executora, método de aprovação, horários da decisão, identificador de resposta do fornecedor e resultado. Registre também propostas recusadas e vencidas. Uma supressão negada explica por que as notificações continuaram; uma aprovação vencida explica por que um aceite proposto nunca foi executado.

Proteja a sequência contra edições silenciosas. Armazenamento por anexação, escritores restritos, controles de retenção e encadeamento criptográfico tratam ameaças diferentes. O Sallyport projeta seus registros Sessions e Activity a partir de um único log de auditoria criptografado e encadeado por hash, e sp audit verify consegue verificar a cadeia de texto cifrado offline, sem chave de descriptografia. A integração obtém provas da execução do agente e de cada chamada externa sem expor a credencial ao agente.

Não guarde apenas a explicação em texto do agente. Modelos podem produzir resumos confiantes e inexatos. Preserve fatos estruturados ao lado do texto. Um motivo como alerta de latência aceito ajuda uma pessoa a percorrer a linha do tempo; ID do incidente, versão do estado, hash da solicitação HTTP e identidade da aprovação permitem verificar a informação.

Leitores da auditoria precisam de semântica estável durante a evolução da integração. Versione o esquema de eventos e os nomes normalizados das ações. Se um adaptador mudar o mapeamento do fornecedor, registre a versão que executou cada chamada. Sem isso, um evento antigo acknowledge pode ficar ambíguo quando uma versão nova alterar seus efeitos.

O acesso à trilha de auditoria não deve dar acesso às credenciais do incidente. Separe a capacidade de verificar a ordem dos eventos da capacidade de descriptografar campos sensíveis. Remova segredos antes que entrem no registro, em vez de esperar que todos os leitores cuidem deles depois.

Teste as transições como fluxos hostis

Testes do caminho feliz provam que um endpoint funciona quando nada de interessante acontece. A automação de incidentes precisa de testes que interrompam o fluxo entre cada leitura, aprovação, chamada e resposta.

Comece com cinco invariantes:

1. O aceite nunca muda a recuperação de aberta para fechada.
2. A resolução nunca cria nem prolonga uma supressão.
3. O encaminhamento nunca implica que o destino aceitou o incidente.
4. Toda mutação aprovada identifica solicitante, aprovador, executor e objeto.
5. Uma aprovação antiga não pode ser executada contra outra versão ou outro alvo.

Depois execute o adaptador contra um fornecedor simulado que possa mudar o estado entre as chamadas. Resolva o incidente enquanto um aceite espera aprovação. Mude a rota antes da execução de uma supressão. Retorne um timeout após aceitar a solicitação e envie o mesmo ID de operação outra vez. Revogue a sessão depois da aprovação e antes da execução. Cada caso deve gerar resultado determinístico e evento de auditoria.

Teste as diferenças entre fornecedores em vez de apagá-las. Um sistema pode interromper a escalação no aceite; outro pode manter notificações repetidas. A resposta normalizada pode expor escalation_paused e notifications_suppressed como fatos separados. Não prometa um efeito universal que o adaptador não consiga verificar.

Revise as descrições das ferramentas com a mesma desconfiança aplicada ao código. Cuide deste incidente convida o modelo a escolher um resultado. Registre que o plantão de Pagamentos assumiu a investigação; mantenha a recuperação aberta descreve uma transição limitada. O texto da ferramenta faz parte da superfície de controle porque molda a solicitação que o agente tenta enviar.

Por fim, teste a ausência de autoridade. Um agente com permissão apenas para aceitar deve receber uma negação clara ao tentar resolver, encaminhar ou suprimir. A negação não deve oferecer uma alternativa automática que faça outra mutação. Uma falha segura deixa o incidente visível e inalterado.

A autoridade deve diminuir quando as consequências aumentam

O desenho de permissões deve seguir o efeito de cada ação, não a conveniência do fluxo que a chama. Ler um incidente, aceitar trabalho atribuído, mudar a responsabilidade, silenciar um sinal e declarar recuperação merecem concessões cada vez mais rigorosas quando suas consequências são diferentes.

Comece com capacidades que indiquem verbo e escopo. incident.acknowledge para o serviço Pagamentos é mais restrito que incident.write em toda a produção. Uma concessão de encaminhamento pode limitar destinos a serviços do mesmo grupo. Uma concessão de supressão pode limitar seletores e duração. Uma concessão de resolução pode exigir um perfil de provas aprovado. O gateway deve avaliar essas restrições com campos estruturados, nunca com a explicação do agente.

Tempo e identidade do processo pertencem à concessão. Uma sessão iniciada para uma tarefa de programação não deve conservar autoridade sobre incidentes depois que o processo termina. Se alguém revogar a sessão enquanto uma aprovação espera, a execução deve falhar mesmo que a decisão anterior fosse válida naquele momento. A aprovação confirma uma transição proposta; não devolve autoridade a um solicitante que a perdeu.

Separe permissão e aprovação. A permissão responde se o solicitante pode tentar aquela classe de ação. A aprovação responde se aquela tentativa específica pode seguir agora. Exigir aprovação não corrige uma permissão excessiva, pois as pessoas acabam aprovando sem atenção, principalmente quando os cartões escondem o escopo. Da mesma forma, uma permissão restrita não substitui a aprovação humana exigida para uma transição de maior consequência.

Trate com mais rigor ações que reduzem visibilidade. O aceite acrescenta um responsável e mantém a falha visível. O encaminhamento pode retirar o alerta da visão da equipe atual. A supressão pode impedir que as pessoas saibam de uma falha contínua. A resolução pode remover o incidente das filas ativas e alterar relatórios de desempenho. Essa ordem não é universal, mas documentá-la revela divergências antes que um agente as encontre de madrugada.

As credenciais devem respeitar as mesmas fronteiras. Se o fornecedor oferecer funções ou tokens diferentes, não dê ao executor uma conta capaz de administrar escalas e serviços só para aceitar um incidente. Se o fornecedor oferecer apenas uma credencial ampla, aplique a operação restrita no gateway e torne a limitação visível no modelo de ameaças. A auditoria do fornecedor mostrará o que a credencial podia fazer; o registro do gateway deve mostrar o que ela foi autorizada a fazer nesta solicitação.

A revogação precisa de resultado previsível. Revogue a sessão para bloquear toda nova operação do processo. Revogue uma aprovação para bloquear a operação vinculada se a execução ainda não começou. Revogue uma concessão de encaminhamento ou supressão para interromper solicitações futuras, tratando supressões existentes com uma transição explícita de cancelamento. Não apague silenciosamente a prova de que a decisão anterior existiu.

Equipes costumam propor uma única aprovação humana no início do incidente e deixar o agente cuidar do restante. A ideia é popular porque perguntas repetidas interrompem as pessoas. Ela continua errada quando mistura consequências. Aprove a sessão uma vez para acesso rotineiro e reserve a aprovação de transição para supressão ampla, encaminhamento entre equipes e resolução. O trabalho de baixo risco avança sem transformar o primeiro clique apressado em autoridade para fechar o incidente uma hora depois.

Antes da implantação, escreva uma matriz de autoridade com ações nas linhas e escopos nas colunas. Para cada célula, decida se o agente pode ler, propor, executar sem nova decisão ou executar apenas após aprovação. Inclua duração máxima de supressão, destinos permitidos, provas aceitáveis de resolução e o comportamento quando ninguém aprova. Uma célula vazia deve negar a ação, não herdar permissão de um rótulo mais amplo.

Exercite a matriz com a credencial real do fornecedor. Uma política que nega resolução no gateway está incompleta se outra ferramenta HTTP exposta permite chamar diretamente o endpoint do fornecedor. Faça um inventário de todos os caminhos até o sistema de plantão, incluindo ferramentas genéricas de solicitação, executores de comandos, relés de webhooks e scripts salvos. Credenciais que contornam o gateway não devem estar disponíveis ao processo do agente.

As solicitações de aprovação também precisam de controle de frequência, mas o limite deve falhar com segurança. Se o agente inundar a pessoa com pedidos repetidos, reúna propostas idênticas ou deixe as extras vencerem. Não responda à sobrecarga aprovando, resolvendo ou ocultando o incidente automaticamente. Registre os pedidos excedentes para que a equipe corrija o ciclo que os produziu.

Um sistema silencioso ainda pode mostrar um incidente aberto

O ruído dos alertas, a responsabilidade de quem responde, a saúde do serviço e o encaminhamento entre equipes são dimensões independentes. Comprimi-las em um único estado simplifica a aparência da interface, mas transfere a ambiguidade para automação, métricas e análises posteriores.

Mantenha o aceite restrito mesmo quando o agente o executar perfeitamente. Deixe-o assumir o trabalho, registrar quem aprovou essa atribuição e preservar o incidente aberto. Se o fluxo também precisar de nova rota, supressão temporária ou resolução após recuperação verificada, torne cada ação visível como uma solicitação e decisão próprias.

Esse projeto custa algumas chamadas extras. Em troca, produz uma linha do tempo na qual quem lidera o incidente pode confiar às duas da manhã: quem assumiu o alerta, quem permitiu a transição, o que o sistema mostrava naquele momento e por que o incidente finalmente foi fechado.