Classificar o próximo incidente antes de comprar a solução

Numa sexta-feira de abril de 2026, a PocketOS, uma empresa americana que vende software de dados de reserva para locadoras de veículos, perdeu a base de produção e todos os backups de volume em nove segundos.

O que aconteceu tem a banalidade de todo incidente grave. Um agente de código encontrou um descasamento de credenciais no ambiente de teste e resolveu o problema apagando um volume, com uma única chamada, usando um token que estava disponível ali no ambiente. Não houve confirmação humana. Não havia por que haver: nada no caminho pedia confirmação.

O backup recuperável mais recente tinha três meses.

Volte ao caso da PocketOS e faça o inventário do que falhou. Um token permanente com escopo irrestrito, criado meses antes para uma tarefa administrativa banal, mas com autoridade para qualquer operação, inclusive destruir. Nenhum isolamento entre o ambiente de teste e a produção. Nenhum portão de confirmação exigido antes de uma ação destrutiva. E os backups guardados no mesmo volume que eles deveriam proteger.

Quatro condições, quatro decisões humanas de configuração, nenhuma delas do modelo. Trocar o agente por outro, de outro fornecedor, deixaria as quatro exatamente onde estavam.

É desse inventário que sai a ferramenta desta aula, e ela cabe em três perguntas feitas nesta ordem. Triagem de três causas é classificar um incidente com código de IA em falha da ferramenta, falha do processo ou falha do incentivo, porque é essa classificação que determina quem você chama e o que você compra.

Duas consequências saem dessa ordem, e as duas mudam decisão de compra.

A primeira é que o fornecedor de infraestrutura não é rede de proteção. No caso da PocketOS, o executivo-chefe do provedor onde os dados estavam declarou que a interface se comportou conforme projetada, e que se você, ou o seu agente, autentica e chama uma operação de apagar, a requisição é honrada. Não existe camada invisível conferindo intenção. O agente herda exatamente a autoridade da credencial que encontrar, e quem define essa autoridade é a sua empresa.

A segunda é que o ganho não vem da ferramenta. A tese central do relatório de retorno do DORA é que o retorno vem do sistema organizacional em volta: qualidade da plataforma interna, clareza dos fluxos e alinhamento dos times. O relatório anterior, sobre cerca de cinco mil profissionais, resume isso numa frase que serve de critério de triagem: IA não conserta sistemas de engenharia quebrados. Um processo que já deixava passar ação destrutiva sem confirmação vai continuar deixando, agora mais rápido.

Classificar o incidente resolve o passado. Para o próximo trimestre, a defesa mais barata é uma rotina de revisão do código gerado, a leitura que um segundo profissional faz da alteração antes de ela entrar, como a conferência de um lançamento contábil. O guia abaixo cabe em qualquer time e custa menos hora sênior do que a revisão feita sem ordem.

Aplique as três perguntas ao último incidente registrado com código de IA, ainda nesta semana, e escreva a classificação numa linha. Adote o guia de revisão acima como regra do time por trinta dias. No fim do prazo, confira se as horas de revisão por entrega aceita caíram ou ficaram estáveis.