A IA barateou produzir mudanças. Provar que estão certas é o orçamento que ninguém planejou

Imagine um líder de segurança numa manhã de segunda-feira. Durante o fim de semana, um agente trabalhou no backlog de vulnerabilidades e abriu quarenta pull requests draft, cada um com uma nova execução aprovada do scanner que levantou o alerta. O trabalho que costumava levar um trimestre está feito. O trabalho que resta, ler quarenta mudanças em código que o time do líder não escreveu, não diminuiu nada. Chegou tudo de uma vez.

Essa cena é para onde a IA enterprise está indo em todas as funções que produzem algo verificável: código, correções de segurança, contratos, reconciliações, relatórios. Nossa visão, e é uma visão e não uma medição, é que a capacidade de verificação está se tornando a restrição vinculante para a IA em produção, e a maioria das organizações não orçou para isso.

A evidência de uma semana

Quatro anúncios de 14 e 15 de outubro tornam o padrão difícil de ignorar:

• O GitHub tornou o Agentic Autofix e o AI Scan em disponibilidade geral (GA). O Autofix pode agrupar até 25 alertas em um único pull request. Nenhuma das funcionalidades pode fazer merge ou bloquear qualquer coisa; a revisão cai sobre as pessoas.
• A Snyk construiu seus novos agentes em torno da regra de que “o gerador não pode ser o validador”, e relata que revisões de segurança por LLM deram um achado que desapareceu na execução seguinte 49.7% das vezes.
• O Harness da Chainguard só reporta achados que se reproduzem em um sandbox novo todas as vezes, e um engenheiro nomeado revisa cada relatório.
• Pesquisadores da Anthropic descobriram que um auditor de IA recompensado por achados aprendeu a inventá-los.

Produtos diferentes, um formato. A geração é automatizada e escala. A verificação ou é determinística e estreita, ou humana e lenta, ou baseada em modelo e precisando de sua própria checagem.

Por que a verificação não escala da mesma forma

A geração ficou barata porque uma chamada de modelo pode produzir uma mudança plausível. A verificação resiste à mesma economia por três razões:

1. Os verificadores baratos são estreitos. Uma nova execução do CodeQL prova que um alerta foi fechado; uma verificação de schema prova um formato. Eles não dizem nada sobre comportamento, intenção ou efeitos colaterais.
2. Os verificadores amplos são caros. Uma pessoa que entende o código, o contrato ou o ledger é a verificação mais geral que existe, e a mais escassa.
3. Verificadores de modelo herdam problemas de modelo. Eles variam entre execuções, derivam quando seu modelo muda e, como a Anthropic mostrou, otimizam para o que são recompensados.

Quando o Google deixou um agente trabalhar durante a noite em uma grande base de código, engenheiros mantiveram duas de seis propostas. O valor era real, e o custo também: a revisão era o trabalho.

Planeje a verificação como capacidade

Se a verificação é a restrição, ela merece o tratamento que damos a outras restrições. Cinco práticas se seguem:

Dê a cada classe de mudança um caminho de verificação antes de automatizá-la. Para cada tipo de saída que um agente produzirá, anote o que a verifica: um teste determinístico, uma reprodução, um modelo independente com uma taxa de falsos positivos medida, uma pessoa, ou uma combinação. Sem caminho, sem automação. Isso estende as classes de mudança que propusemos em agentes como autores de mudanças em produção.

Meça a fila, não apenas a saída. Acompanhe quanto tempo a saída do agente espera por verificação e quanto dela é aprovada sem retrabalho. Uma fila crescente significa que o sistema está produzindo passivos mais rápido do que ativos.

Invista primeiro nos verificadores baratos. Cada teste, regra, harness de reprodução e dataset de referência que você adiciona converte revisão humana cara em checagens automatizadas baratas para uma fatia do trabalho. É para lá que os orçamentos de IA deveriam ir, junto com o gasto com modelos.

Mantenha o verificador caro para o que só ele pode julgar. As pessoas devem revisar intenção, risco e qualquer coisa que uma regra não possa expressar. Pedir que confirmem o que um teste poderia confirmar desperdiça o recurso mais escasso.

Verifique os verificadores. Toda checagem automatizada, especialmente uma baseada em modelo, precisa de casos conhecidos como bons e conhecidos como ruins e uma amostra humana periódica. Um avaliador sem uma taxa de erro medida tem uma desconhecida.

O que isso significa para o business case

A maioria dos business cases de IA conta as horas que a geração economiza. Poucos contam as horas que a verificação adiciona, e quase nenhum financia os testes e harnesses que tornariam a verificação mais barata. É assim que as organizações acabam com números impressionantes de piloto e rollouts estagnados, a lacuna que descrevemos quando escrevemos que horas economizadas não são valor.

Em trabalho regulado, isso não é opcional. A prova tem que vir de fora do modelo, e fora do modelo é exatamente onde a capacidade é limitada. Os times que escalarem IA em 2027 não serão os que mais geram. Serão os que construíram os meios para confiar no que foi gerado, e pagaram por isso de propósito.