Sua equipe atualiza o modelo de IA porque ele escreve código melhor, entende mais contexto ou custa menos. Os testes funcionais melhoram e a migração parece resolvida. O risco começa quando essa evolução é interpretada como prova de que o código também ficou mais seguro.
O que o estudo acompanhou
Pesquisadores da Ruhr-Universität Bochum compararam 32 modelos de sete famílias: duas proprietárias e cinco open-weight. Para observar evolução, organizaram três lançamentos sucessivos por família e, quando disponível, variantes flagship e compactas [1][2].
A avaliação usou 119 tarefas do CWEval em cinco linguagens e 31 categorias CWE. Com 100 amostras por tarefa e modelo, a população chegou a 380.800 programas. Cada solução foi submetida a oráculos dinâmicos distintos para funcionalidade e segurança; o estudo chama de gap a distância entre código que funciona e código que, além disso, passa nos testes de segurança [1][2][3].
Os modelos melhoraram, mas o gap permaneceu
Em todas as sete famílias, o lançamento mais novo produziu mais código simultaneamente funcional e seguro do que o primeiro. Esse é um resultado importante: o estudo não sustenta a tese simplista de que nada evoluiu. Ao mesmo tempo, nenhuma família eliminou a diferença entre desempenho funcional e segurança [1][2].
A abertura dos pesos também não separou vencedores e perdedores. Todas as cinco famílias open-weight reduziram significativamente o gap em pelo menos uma configuração de tentativas. Modelos compactos foram, em geral, menos seguros que seus flagships, mas houve exceções. Licença, tamanho e preço são atributos operacionais; não são uma classificação de segurança [1][2].
A média melhora enquanto uma fraqueza regride
O estudo encontrou fraquezas persistentes, como injeção em logs (CWE-117) e divisão de resposta HTTP (CWE-113). Também observou regressões nos lançamentos proprietários mais recentes em categorias ligadas a memória e inteiros. Uma média agregada melhor pode, portanto, esconder uma falha relevante para a arquitetura da empresa [1][2].
O risco variou por linguagem; C apresentou a maior taxa condicional de vulnerabilidade na maioria dos modelos. Isso impede uma política única do tipo “modelo aprovado para código”. A pergunta precisa incluir linguagem, operação, categoria de fraqueza, bibliotecas oferecidas no contexto e consequência de uma falha.
O que muda na governança de modelos
- Versione modelo, configuração, prompt, ferramentas, dependências e conjunto de testes como uma única mudança avaliável.
- Mantenha gates funcionais e de segurança separados; um não deve compensar silenciosamente o outro.
- Segmente resultados por linguagem, CWE, criticidade e número de tentativas, em vez de depender apenas de uma média.
- Reexecute o baseline quando mudar de flagship para compacto, de proprietário para open-weight ou entre lançamentos da mesma família.
- Ofereça APIs e padrões seguros no contexto do agente, reduzindo a chance de ele escolher um caminho inseguro por conveniência.
- Conserve revisão humana e rastreabilidade para código que alcança dados, identidade, pagamentos, infraestrutura ou produção.
O que este levantamento ainda não prova
- CWEval mede funções isoladas e 31 categorias; não reproduz todo um repositório, sua arquitetura ou sua cadeia de entrega.
- Segurança é operacionalizada por testes direcionados; aprovação não demonstra ausência de vulnerabilidades.
- As tarefas podem ter aparecido em dados de treinamento, e o desenho mede comportamento padrão sem instrução explícita de segurança.
- Amostras proprietárias antigas foram reutilizadas porque algumas APIs deixaram de servir essas versões.
- O preprint é versão v1 de 06/10/2026. Os dados são oferecidos pelos autores mediante solicitação, e não localizamos reprodução independente completa até o corte editorial.
- O estudo mede diretamente modelos, não o efeito combinado de um agente com ferramentas, sandbox, políticas e revisão.
A regra prática: upgrade não herda aprovação
Um modelo novo pode ser melhor e ainda reabrir riscos. A aprovação anterior pertence ao conjunto exato que foi avaliado: versão, configuração, contexto, ferramentas, linguagem, testes e ambiente. Quando uma dessas peças muda, a evidência precisa ser renovada na proporção do impacto.
Nota editorial e de responsabilidade
Números, população, método, autoria, afiliações e limitações foram atribuídos às fontes diretas. O artigo separa achados reportados pelos pesquisadores de interpretação editorial e recomendações profissionais. Pontos de vista pessoais e profissionais do autor não são fatos universais nem garantia de qualidade ou segurança. O conteúdo é informativo e não substitui avaliação técnica, jurídica, regulatória ou de segurança aplicada ao seu contexto. Nomes de empresas, produtos e modelos pertencem aos respectivos titulares; não há patrocínio ou endosso. Tech Human e Trustyu atuam comercialmente em desenvolvimento e governança de produtos digitais. Pesquisa, estrutura e redação tiveram assistência de IA; revisão factual, aprovação autoral e autorização de publicação foram confirmadas por Fernando Parreiras em 07/10/2026, sem revisão humana independente adicional.