Os quatro eventos de risco e a auditoria multi-frente
A confiança na IA não começa no modelo, começa no processo.
Esta é a sexta 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, entro na maquinaria mais pesada, que só se justifica depois de um gatilho real.
Quantas vezes você já sentiu que “deveria rodar uma revisão mais séria nisso”, mas nunca havia um momento óbvio o suficiente para realmente começar, até o momento chegar sozinho, tarde demais para ser confortável?
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.
As três práticas que nunca esperam gatilho (guardrails fixos, prova em vez de crença, registro de decisão com prazo curto) são baratas o bastante para rodar sempre. O que vem agora não é.
Auditoria com múltiplas frentes independentes, revisão de documentação tratada como caça a bug, consolidação retroativa de decisões de arquitetura: tudo isso custa tempo e atenção real, e por isso mesmo precisa de uma justificativa que não seja “seria bom fazer algum dia”.
Uma dívida que cresce em silêncio é como descrevi esse mesmo tipo de acumulação num artigo fora desta série sobre dívida técnica como risco corporativo. A lista ali já incluía “adoção de IA sem governança” como uma das camadas dessa dívida, ao lado de código ineficiente e testes ausentes. Na época, era só um item numa lista, sem nenhum protocolo de quando agir sobre ele. Os quatro eventos abaixo são a tentativa de responder exatamente essa lacuna.
Os quatro eventos que deveriam disparar disciplina mais pesada
Quatro eventos, que venho observando de forma consistente nos oito projetos, ativam essa disciplina mais cara: uma reescrita de peso, a aproximação de uma versão importante, a véspera de um lançamento estável, e uma revisão de documentação que já encontrou um bug real.
Existe um quinto candidato (a própria chegada da configuração de um agente de IA a um projeto ser, por si só, o gatilho), mas trato isso como hipótese a testar, não como regra. O que faria essa hipótese virar regra não é mais uma repetição sozinha. É ver, num segundo projeto independente, o mesmo padrão específico que apareceu no primeiro: a configuração inicial do agente já expondo, sem que nenhum outro evento tivesse acontecido ainda, um risco que só uma auditoria costuma revelar. Uma coincidência não vira padrão; duas ou mais, em projetos sem relação entre si, começam a virar.
A recomendação prática: programe esses eventos como parte do próprio ciclo de trabalho, em vez de esperar que a pressão do calendário force a decisão. Uma reescrita grande deveria abrir a janela de rigor desde o primeiro commit, não só quando já está quase pronta, porque nesse ponto, corrigir o que a auditoria encontrar já compete com o prazo, em vez de estar dentro dele.
Por que a auditoria vira um protocolo, não uma lista de verificação
A tentação óbvia, diante de um evento de risco, é tratar a auditoria como uma lista fixa de itens a checar: a mesma lista, todo projeto, toda vez. Resisto a isso de propósito.
O motivo é o mesmo problema que qualquer processo bem-intencionado enfrenta quando se repete demais: uma lista fixa sobrevive além do momento em que ela ainda fazia sentido, aplicada a situações que nunca foi desenhada para cobrir, até virar exatamente o ritual vazio que ninguém mais questiona.
A alternativa que uso é formalizar a auditoria como um protocolo repetível: instruções versionadas que carregam o “como” de um processo recorrente, deixando o “quando” e o “com quais ângulos específicos” para serem decididos a cada vez, por mim.
A primeira decisão de toda auditoria é sempre humana: antes de qualquer rodada começar, confirmar, trocar ou somar os ângulos de revisão propostos para aquele projeto, naquele momento específico (estabilidade, resiliência, observabilidade, usabilidade, complexidade, desempenho, ajustando a lista ao tipo de sistema). Nenhum checklist genérico herdado de um projeto anterior. Cada auditoria começa do zero nessa pergunta, porque cada projeto tem seus próprios riscos e sua própria história.
As regras que tornam isso confiável como processo, não só como boa intenção
Algumas regras específicas separam uma auditoria que realmente funciona de uma que só parece rigorosa:
Cada frente roda sem compartilhar contexto com as outras. Isso não é burocracia: é o que garante que um ponto cego numa análise não se propague automaticamente para todas as outras. Uma segunda opinião que já sabe o que a primeira concluiu deixa de ser uma segunda opinião de verdade.
Achados conflitantes entre frentes nunca são resolvidos silenciosamente. São reportados como conflito, para decisão humana. A tentação de suavizar uma discordância (escolher qual das duas análises parece mais provável e seguir em frente) destrói exatamente o sinal que a independência das frentes existia para produzir.
Todo bug encontrado dispara uma busca pelo mesmo padrão em outros lugares do código. Fechar a classe do problema, não só o caso relatado: um bug corrigido num lugar e deixado vivo em três outros não foi corrigido, foi só escondido.
O critério de parada é combinado antes da última rodada, não depois de ver o resultado. Pare quando uma frente parar de encontrar coisa nova, não quando bater um número fixo de rodadas decidido de antemão sem informação nenhuma sobre o projeto real.
Na prática, as frentes não convergem todas juntas. Numa auditoria real, cerca de metade delas chegou a duas rodadas consecutivas sem achado relevante e saiu de rotação. Uma teve o papel redefinido, de “frente que precisa convergir” para “verificação permanente ligada a mudanças reais de código”, porque desempenho, por exemplo, é algo que se mede para sempre, não um problema que se resolve uma vez e pronto. As demais nunca bateram duas rodadas limpas seguidas, mas encerraram num platô claro de achados cada vez mais residuais. Foi esse platô, não um número mágico de rodadas, que embasou a decisão de encerrar.
Se o risco justificar, pelo menos uma frente deveria rodar num modelo de IA diferente das outras. Frentes que usam o mesmo modelo, mesmo com instruções diferentes, tendem a ter os mesmos pontos cegos.
Nunca aceite o relatório de uma rodada de auditoria como fato sem confrontar as afirmações mais fortes com o registro bruto. O log de execução real, não o resumo que o agente escreveu sobre si mesmo. Um agente pode descrever seu próprio trabalho de forma otimista sem perceber: o mesmo overclaiming que descrevi no artigo Disciplina em rajada, só que numa escala onde o custo de não pegar é maior. Fora de uma auditoria formal, uma alegação isolada do dia a dia (“corrigi isso”, “os testes passam”) merece o mesmo cuidado, em miniatura.
Quando uma hipótese de bug plausível é investigada e não se confirma, isso vira um teste permanente, com um comentário explicando por que aquele medo específico não se concretiza. Um agente sem memória de sessões anteriores vai levantar a mesma suspeita de novo, e sem esse teste, alguém vai gastar tempo reinvestigando algo que já foi resolvido.
Onde esse protocolo degenera de volta em ritual
O risco que um protocolo bem desenhado tenta evitar nunca desaparece de vez. Só fica mais difícil de cair nele.
A forma mais comum é deixar de fazer a pergunta inicial (“quais ângulos fazem sentido aqui, agora?”) e simplesmente reaplicar os ângulos da última auditoria, porque “funcionou antes”. No momento em que isso acontece, o protocolo parou de ser adaptável e virou exatamente o checklist genérico que ele existia para evitar.
A segunda forma é deixar de tratar achados conflitantes como conflito genuíno, e começar a reconciliá-los automaticamente (“provavelmente essa frente está certa, porque geralmente está”), reintroduzindo, pela porta dos fundos, o mesmo ponto cego que a independência das frentes existia para eliminar.
Nenhuma das duas degenerações é dramática o suficiente para ser notada no momento em que acontece. Ambas acontecem devagar, decisão de conveniência após decisão de conveniência. É exatamente por isso que precisam ser guardadas como regra explícita, e não deixadas para o bom senso de quem executa naquele dia específico.
Conclusão
Uma auditoria bem desenhada não é sobre eliminar decisão humana de um processo repetível. É sobre isolar exatamente qual decisão precisa continuar sendo humana a cada vez, e blindar o resto contra a degeneração silenciosa que transforma disciplina em ritual. O “como” pode, e deve, se repetir. O “quando” e o “com quais ângulos” nunca deveriam.
No próximo artigo desta série, aplico essa mesma lógica de verificação num nível diferente: não “esse bug foi corrigido?”, mas “esse agente resolve issues de verdade, e com que frequência?”, usando o que a própria indústria de IA já construiu, em escala, para responder exatamente essa pergunta.
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 (este artigo)
- 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
- 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
Referências citadas
- Fernando Cerqueira, “Dívidas Técnicas: um risco corporativo que cresce silenciosamente” (enterprisearchitecture.com.br): https://enterprisearchitecture.com.br/dividas-tecnicas-um-risco-corporativo-que-cresce-silenciosamente/
