O que a IA não consegue auditar

Passei boa parte da carreira auditando sistemas, e uso modelos nesse trabalho todos os dias. Eles leem mais rápido do que eu, nunca cansam no quadringentésimo arquivo, e são muito bons em casar padrões com classes conhecidas de bug. Então quero ser preciso sobre o limite, porque ele não está onde as pessoas assumem. O modelo não é fraco em achar bugs. Ele é fraco em achar as falhas que parecem comportamento correto, e essas são as que derrubam sistemas.

O que ele faz bem

Entregue uma base de código a um modelo e ele vai achar a promise sem tratamento, o SQL montado por concatenação de string, o índice faltando, o retry sem limite, o segredo no arquivo de config. Isso é real e é valioso, e rodo isso cedo em toda auditoria para limpar as classes conhecidas e gastar meu tempo em outro lugar. Ele também resume: o que este serviço faz, por onde estes dados fluem, quais módulos falam com quais. Esse mapa levava um dia para eu construir. Agora leva uma hora para verificar.

O que ele não enxerga

As falhas para as quais sou chamado quase nunca estão só no código. Estão na lacuna entre o que o código faz e o que o negócio assumiu. Um job de reconciliação que roda corretamente num horário que não bate mais com a chegada dos dados upstream. Uma checagem de permissão correta para a estrutura organizacional de dois anos atrás. Um cache invalidado direito em todo caminho de escrita, exceto no que outro time adicionou em outro repositório. Um retry idempotente para a API para a qual foi escrito e não para a que ele chama agora. Para achar isso você precisa da intenção, do histórico e do contexto fora do repositório, e o modelo não tem nenhum dos três a menos que uma pessoa traga.

Plausibilidade é a inimiga

A força do modelo é gerar a leitura plausível do código. Auditar é a busca pela verdade implausível. Quando pergunto a um modelo se uma função é segura, ele explica por que a função é segura, com fluência, porque essa é a leitura que o código sustenta na superfície. O bug está na premissa que o código faz sobre quem o chama, e o modelo não viu quem chama, e mesmo quando viu, a premissa de quem chama é sobre uma ordem de deploy documentada numa mensagem de chat de alguém que já saiu da empresa. Uma explicação convincente de por que o código funciona é a saída mais perigosa que uma ferramenta de auditoria pode produzir, porque ela encerra a busca.

Como eu uso de verdade

• Como primeira passada para limpar as classes conhecidas de bug, para que o tempo humano vá para as desconhecidas.
• Como construtor de mapa, e depois verifico o mapa contra o sistema rodando, não contra o código.
• Como leitor hostil: peço que ele argumente que um componente está quebrado, não que me diga se está, e leio o argumento procurando as partes que ele não conseguiu sustentar.
• Como checagem de documentação: onde o resumo dele do que o código faz difere do que o time diz que faz, há um achado.

O leitor responsável

Uma auditoria é uma afirmação assinada por uma pessoa: eu olhei, aqui está o que encontrei, aqui está o que não encontrei. Um modelo não pode assinar isso. Não porque não seja inteligente o bastante, mas porque a afirmação inclui julgamento sobre o que importa neste negócio, para estes usuários, neste momento, e responsabilidade por estar errado. É pelo mesmo motivo que a ELUCENIA, a cadeia médica e científica global que estou construindo para a descoberta, trata toda saída de modelo como uma hipótese que precisa de evidência e de um humano responsável pela conclusão. A ferramenta amplia o que um auditor consegue cobrir. Ela não substitui o auditor. As falhas que importam continuam sendo encontradas por alguém que se recusa a acreditar na história plausível.