Pentágono introduz 3 verificações para cada trecho de código gerado por IA

Um agente de IA atualizou uma biblioteca, ajustou o build e abriu uma solicitação de merge em um minuto. O patch parece limpo e, à primeira vista, os testes estão verdes. Mas quem responde se o agente enfraqueceu discretamente uma verificação de permissões de acesso? E é possível, meio ano depois, descobrir qual modelo fez a alteração e quem autorizou sua publicação?

A nova instrução 8430.01 do Departamento de Guerra dos EUA responde com rigor: o código criado ou alterado por IA é considerado não verificado até que a equipe confirme sua qualidade. Os desenvolvedores continuam responsáveis pela segurança, pelo funcionamento e pela integridade do resultado. Funções críticas exigem aprovação humana.

A regra vale para as organizações do departamento e para programas de aquisição que incluem software. Mas a abordagem é útil para qualquer empresa que já permite que agentes entrem em seus repositórios: a velocidade de geração de código não substitui a prova de que a alteração é segura.

O que exatamente é preciso provar

A instrução resume o trabalho com IA em três requisitos práticos.

Primeiro, rastreabilidade. A equipe deve saber onde a IA participou, qual modelo e versão foram usados e quais ações o agente executou. Um simples rótulo "feito com IA" não basta. O histórico deve ligar a alteração a um processo específico e à pessoa que o iniciou.

Segundo, verificação. O código do agente passa pelos mesmos testes, pela mesma análise de dependências, pela mesma busca de vulnerabilidades e pelas mesmas regras de aprovação que o código humano. Nas funções das quais dependem a segurança do sistema ou a vida de pessoas, a decisão final cabe a um especialista designado.

Terceiro, limites dos dados. Prompts, código-fonte e informações não públicas não devem ser enviados a um modelo externo sem avaliação. A organização deve definir com antecedência os modelos permitidos, onde eles são executados e as regras de retenção de dados.

Como isso fica em um patch comum

Suponha que um agente proponha atualizar uma biblioteca de autorização. Um processo normal é assim: o agente cria uma branch separada e uma solicitação de merge; o registro anota sua conta de serviço e o desenvolvedor que atribuiu a tarefa; o pipeline executa testes, análise de dependências e varredura de segurança. Como a alteração afeta uma área protegida, o sistema exige a aprovação de um engenheiro responsável. O agente pode corrigir um erro encontrado, mas não pode remover sozinho o bloqueio nem enviar o código à branch principal.

Essa ordem não proíbe a autonomia; ela define seus limites. É possível encarregar o agente de buscar atualizações, preparar um patch e reexecutar as verificações. O direito de fazer merge ou publicar depende do risco: uma correção de documentação pode passar automaticamente, enquanto uma alteração de autorização só passa por uma pessoa.

O GitLab apresenta sua própria plataforma como uma forma de atender a esses requisitos: logs de auditoria, branches protegidas, regras de aprovação, varredura de dependências e um gateway de modelos hospedado pelo próprio cliente. É um exemplo útil, mas a fonte continua sendo material comercial. A instrução descreve requisitos e não obriga a usar o GitLab; os mesmos princípios podem ser montados no GitHub, no Azure DevOps ou em um sistema interno.

O que mudar no processo de desenvolvimento

Comece não pela escolha de mais uma ferramenta de IA, mas por um mapa de atribuições. Registre a quais repositórios e dados o agente tem acesso, quais ações executa por conta própria e onde deve parar. Identifique as branches protegidas, os arquivos críticos e as operações de publicação. Atribua a eles responsáveis e verificações obrigatórias.

Em seguida, adicione a origem das alterações ao log de auditoria: o modelo, sua versão, a conta de serviço do agente e a pessoa que o iniciou. Não confie apenas em um comentário na solicitação de merge: ele se perde com facilidade e serve mal para uma investigação.

A principal conclusão é simples: a IA acelera a escrita de um patch, mas não transfere a responsabilidade da equipe para o modelo. Se uma empresa não consegue mostrar quem iniciou o agente, o que exatamente foi verificado e quem autorizou a publicação, ela ainda não tem desenvolvimento com IA sob controle, mas um gerador rápido de dívida técnica.