Calibrando a intensidade ao risco real
A confiança na IA não começa no modelo, começa no processo.
Esta é a décima parte de uma série sobre a metodologia que uso para continuar sendo, de fato, o responsável pelo que um agente de IA produz. Aqui, respondo à pergunta que fica em aberto depois de descrever toda a estratégia pesada: quanto disso vale a pena, em qual projeto.
Quantas vezes você já viu um processo de qualidade ser aplicado com a mesma intensidade num projeto crítico e num projeto satélite que ninguém mais usa, com os dois lados saindo perdendo: um por excesso de cerimônia, o outro por falta dela?
Disclaimer: este texto reflete minha visão prática sobre o tema, construída em projetos pessoais e profissionais. Não representa, necessariamente, a posição oficial de nenhuma organização à qual eu esteja afiliado.
Tudo o que descrevi até aqui nesta série (auditoria com frentes independentes, registro de decisão em lote, revisão de documentação como caça a bug) tem um custo real. Aplicar esse custo por igual a todo projeto, independente do risco real que ele carrega, não é rigor. É desperdício disfarçado de disciplina.
A pergunta que fecha essa lacuna é simples de fazer e desconfortável de responder com honestidade: quanto risco esse projeto específico realmente tem?
As três perguntas que decidem quanto investir
O projeto tem estado compartilhado ou concorrência real? Um bug de corrida (duas partes do sistema competindo pelo mesmo recurso sem coordenação) é silencioso por natureza. O código passa em todo teste sequencial, funciona bem na maioria das execuções reais, e só aparece quando a condição de corrida específica se alinha, geralmente sob carga, geralmente no pior momento possível.
Um sistema sem estado compartilhado simplesmente não tem essa classe de risco disponível para existir. Investir pesado em auditoria de concorrência num sistema que não tem concorrência real é gastar atenção num risco que não existe. Não investir nela num sistema que depende de estado compartilhado é apostar que a corrida nunca vai se alinhar, o que é exatamente o tipo de aposta que um bug de corrida existe para vencer.
Nota: Em um dos projetos em que apliquei esta série, respondi errado a esta primeira pergunta. Tratei como concorrência real o que era um único dono por cópia de trabalho, e a resposta virou uma trava de sequência com toda a maquinaria de recuperação que uma trava exige. As rodadas de auditoria sobre essa trava nunca convergiam: cada uma fechava um caso e a seguinte achava outro. O que isso revelou, e por que a saída foi reabrir a premissa em vez de rodar mais uma vez, está no artigo da v2 (e preparação) desta série: “O sinal de premissa: quando a auditoria que não converge está pedindo outra especificação”.
Quantos outros projetos dependem dele? Um projeto sem dependentes pode falhar sem que ninguém além de quem o mantém perceba. Um projeto do qual outros dez dependem propaga qualquer falha para dez lugares diferentes, cada um com seu próprio contexto e sua própria urgência.
O número de dependentes não é só uma medida de importância. É uma medida de quantos lugares diferentes vão herdar um erro que ninguém pegou a tempo, e de quão mais difícil fica reverter uma decisão depois que ela já se espalhou.
Existe um lançamento público próximo? Um bug encontrado antes de qualquer usuário externo ver o sistema custa uma correção. O mesmo bug, encontrado depois, custa a correção mais a reputação, mais o suporte a quem já foi afetado, mais a dúvida que fica sobre o que mais pode estar quebrado. A proximidade de um lançamento não muda a probabilidade de um bug existir. Muda o custo de encontrá-lo tarde.
Nos oito projetos que venho analisando, essa diferença já apareceu na prática: bibliotecas de interface, sem estado compartilhado e sem outros projetos dependendo delas, nunca justificaram uma auditoria de seis frentes. Essa intensidade só fez sentido nos projetos de infraestrutura, com concorrência real e vários outros sistemas dependendo do resultado. Aplicar a mesma cerimônia aos dois não teria sido mais seguro. Teria sido rigor gasto onde o risco não existia, à custa de atenção que faltava onde ele existia de verdade.
O prazo curto de registro de decisão que descrevi no artigo sobre as três práticas que nunca esperam gatilho (a semana sugerida ali) também deveria ser ajustado pelos mesmos três fatores. Um projeto de alta concorrência, muitos dependentes e release próximo justifica um prazo mais curto que uma semana. Um projeto satélite de baixo risco pode tolerar uma folga maior sem que isso vire irresponsabilidade.
Reversibilidade: boa prática reconhecida, mas nem sempre disponível
Uma prática que costuma aparecer em discussões de governança de IA é a capacidade de reverter rapidamente uma mudança já em produção: desligar uma feature flag, desfazer um deploy, reverter uma migração. Nenhum dos oito projetos que venho analisando chegou a demonstrar essa capacidade de ponta a ponta, e vale entender por que antes de tratá-la como obrigação universal.
É boa prática de engenharia reconhecida em geral, mas sua viabilidade depende totalmente do tipo de sistema. Uma API sem estado é barata de tornar reversível: desligar a mudança é, na prática, voltar a rotear para o código antigo, que continua existindo, intocado, esperando ser reativado.
Uma migração de banco de dados já aplicada é uma categoria de problema totalmente diferente. Os dados já foram transformados, o esquema antigo pode não existir mais para receber os dados de volta, e “reverter” pode significar reconstruir um estado que nunca foi salvo em lugar nenhum. Tratar as duas situações com a mesma expectativa de reversibilidade é ignorar uma diferença estrutural real entre elas: não uma diferença de disciplina, mas uma diferença do que é fisicamente possível fazer depois que o dado já mudou de forma.
A recomendação prática, dado esse limite real: avaliar caso a caso, não tratar como obrigação. Antes de prometer que uma mudança é reversível, perguntar especificamente o que reverter significaria depois que ela já estiver em produção. Se a resposta envolve reconstruir um estado que ninguém está salvando hoje, a promessa de reversibilidade é uma ilusão cara, não uma proteção real.
Na prática
Responda às três perguntas antes de decidir o nível de rigor, não depois. Decidir a intensidade do processo depois de já ter começado a aplicá-lo tende a racionalizar o que já foi feito, não a medir o risco real.
Trate o prazo de registro de decisão como uma variável, não uma constante. A mesma semana que é generosa demais para um projeto crítico pode ser rigor desnecessário para um projeto satélite. Calibrar pelos mesmos três fatores evita os dois erros.
Nunca assuma reversibilidade sem perguntar o que ela significaria na prática, para aquele sistema específico. Uma migração de banco já aplicada e uma feature flag desligada não são a mesma categoria de “desfazer”, mesmo que ambas apareçam como boa prática na mesma lista genérica.
Revise a calibração quando qualquer um dos três fatores mudar. Um projeto satélite que ganha um novo dependente importante, ou que de repente tem um lançamento público marcado, precisa de uma nova resposta às três perguntas, não da resposta antiga, aplicada por inércia.
Conclusão
Calibrar intensidade ao risco real não é uma forma mais barata de fazer o mesmo trabalho. É reconhecer que aplicar o mesmo nível de rigor a projetos com riscos genuinamente diferentes desperdiça atenção nos dois extremos: rigor demais onde o risco não justifica, rigor de menos onde ele justificaria muito mais.
As três perguntas (estado compartilhado, número de dependentes, proximidade de release) não substituem julgamento. Dão a ele uma estrutura que sobrevive à pressão do momento, quando a tentação é sempre a de aplicar menos rigor do que o risco real pede.
O próximo artigo desta série parte da mesma pergunta de fundo por outro ângulo: se calibrar intensidade é decidir quanto rigor uma decisão merece, o artigo O alinhamento entre produto e engenharia começa onde a decisão fica registrada é sobre onde, exatamente, mora a verdade sobre essa decisão depois que ela foi tomada, um problema bem mais antigo do que qualquer agente de IA.
Tenham um excelente dia!
Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável. Como arquiteto sênior, aproveito meus mais de 30 anos de experiência em arquitetura e desenvolvimento de software para projetar e implementar soluções baseadas em nuvem que ajudam os clientes a transformar seus negócios com tecnologia.
Este texto foi escrito com apoio do Claude Code, a partir da minha experiência, minhas decisões e revisão: o próprio processo que a série descreve.
Nesta série
- Metodologia de Desenvolvimento Assistido por IA Centrada na Decisão Humana
- Disciplina em rajada: por que o rigor não nasce junto com o código
- O código duplicado que a IA cria enquanto parece produtiva
- As três práticas que nunca esperam gatilho
- Quem autorizou essa atualização de dependência? Pode ter sido sua IA
- Os quatro eventos de risco e a auditoria multi-frente
- Seu agente de IA resolve a issue de verdade, ou só parece resolver?
- ADRs em lote, e a regra da visibilidade
- IA no time não reduz o bus factor do seu projeto — pode aumentar
- Calibrando a intensidade ao risco real (este artigo)
- O alinhamento entre produto e engenharia começa onde a decisão fica registrada
- Segurança psicológica também vale para o time formado por você e sua IA
- Releitura: o papel do humano, os sinais que funcionam, e onde a metodologia ainda é fraca
