Os agentes de IA mais úteis do Google não conversam. Eles ficam no code review e barram vulnerabilidades

Quando as empresas imaginam um agente de IA, quase sempre imaginam uma conversa: alguém pede, o agente responde ou age. Alguns dos agentes mais valiosos não se parecem nada com isso. Não têm janela de chat. Rodam dentro de um processo que a empresa já confia, e o que entregam é uma decisão que esse processo já sabe tratar.

Um texto publicado em setembro por duas lideranças de engenharia do Google descreve exatamente isso: agentes de IA embutidos no ciclo de desenvolvimento que protege o código da própria infraestrutura do Google. É um dos relatos públicos mais detalhados de agentes operando dentro de um processo de controle em escala, e as escolhas de desenho valem muito além do Google.

Como o sistema funciona

Segundo o Google, o sistema tem três etapas e um passo de correção:

• Varredura antes do envio. Cada alteração de código, em todas as camadas do stack, é avaliada em tempo real por agentes de IA dentro das ferramentas dos desenvolvedores. Os agentes usam modelos de ameaça locais, montados com metadados vivos do código e grafos de dependência.
• Triagem. Um agente de triagem separado e especializado valida cada achado em uma varredura leve de menos de um minuto, com análise da árvore sintática, percurso do grafo de chamadas e regras de segurança pré-indexadas, para provar que o caminho vulnerável é de fato alcançável por um atacante. O Google relata precisão acima de 92% nessa etapa.
• Varredura depois do envio. Uma varredura noturna, em capacidade ociosa, procura vulnerabilidades introduzidas pela soma de várias alterações.
• Correção automática, aprovação humana. Um agente de correção usa os achados e as provas geradas para montar o ajuste, que é enviado para revisão humana dentro do próprio code review da alteração original.

O Google diz que o sistema cobre toda alteração de código que vai para a sua infraestrutura, em centenas de milhões de linhas, e impede que centenas de vulnerabilidades por mês cheguem ao código ou à produção. Também relata falsos positivos de apenas 3% em alguns casos. São números do próprio Google sobre o próprio ambiente. O trabalho se apoia no Mantis, um harness de revisão multiagente que o Google abriu como open source.

1. Alteração de código enviada
2. Agente de varredura com modelo de ameaça
3. Agente de triagem com prova estrutural
4. Agente de correção propõe o ajuste
5. Revisor aprova no mesmo code review
6. Varredura noturna entre alterações

Etapa feita por agente de IADecisão humana, no processo que já existia

Cinco escolhas de desenho que valem ser copiadas

1. Separe os agentes. A primeira recomendação do Google é manter separados os harnesses, as regras e o contexto dos agentes de desenvolvimento, de varredura e de triagem, para evitar viés. É a versão agêntica da segregação de funções: quem encontra o problema não deveria ser quem decide se ele é real, e nenhum dos dois deveria escrever a correção sem conferência.

2. Combine IA com verificações determinísticas. A triagem não confia na opinião de um modelo de que o código é vulnerável. Ela usa análise estrutural para provar o caminho. Juntar uma varredura rápida com IA e uma validação determinística é o que reduz ao mesmo tempo a latência e os falsos positivos. O padrão vale para qualquer agente cujo resultado gera trabalho para pessoas.

3. Dê aos agentes o contexto que você já tem. O Google aponta os modelos de ameaça existentes como o insumo mais importante para a precisão. A maioria das empresas tem ativos equivalentes: catálogos de controles, registros de decisões de arquitetura, classificação de dados. Costumam ser o melhor contexto que um agente pode receber.

4. Coloque a aprovação humana onde as pessoas já decidem. A correção chega no code review original. O revisor não aprende uma ferramenta nova nem trabalha em outra fila. A adoção acontece porque o agente se encaixa no workflow, e não o contrário.

5. Use o harness para absorver a variação dos modelos. O Google observa que um harness multiagente compensa a variação entre modelos. Quem garante a confiabilidade é o desenho, não um modelo específico. Fizemos um argumento parecido na nossa análise sobre harness de IA.

O que isso significa no Brasil

Poucas empresas brasileiras têm a escala ou o time de segurança do Google. Mas muitas, sobretudo no setor financeiro, já precisam manter uma política de segurança cibernética aprovada e controles sobre o desenvolvimento de sistemas, como prevê a Resolução CMN nº 4.893/2021 para instituições autorizadas pelo Banco Central. Um agente que atua dentro do code review, com aprovação humana registrada no mesmo lugar, produz justamente o tipo de evidência que auditorias internas e reguladores pedem. O cuidado é não deixar o agente virar um atalho: a aprovação continua sendo de uma pessoa, com nome.

O que fazer agora

1. Escolha um controle existente com uma decisão clara: code review, revisão de acessos, questionários de risco de fornecedores, aprovação de mudanças.
2. Separe quem encontra de quem confirma. Um agente sinaliza; uma verificação determinística ou um segundo agente confirma. Meça a precisão antes de mostrar o resultado a alguém.
3. Entregue o resultado dentro do workflow atual, com o mesmo aprovador humano e a mesma trilha de evidências.
4. Trate falsos positivos como métrica principal. Um agente que inunda os revisores vai ser desligado, por mais problemas reais que encontre.
5. Mantenha as alterações dos próprios agentes sob revisão. Como dissemos na nossa análise do AIP Evolve, da Palantir, agentes que alteram sistemas precisam de avaliação e de aprovações próprias.

Em resumo

Os agentes descritos pelo Google são invisíveis para a maioria das pessoas que eles ajudam. É justamente esse o ponto. Os agentes enterprise de maior valor podem acabar desaparecendo dentro de processos de controle que já existem, onde o sucesso se mede em precisão, tempo de correção e confiança dos revisores, e não em conversas.