Modelos de inteligência artificial com pesos abertos estão se aproximando do desempenho de sistemas fechados em tarefas de invasão simulada. A conclusão aparece em uma reportagem publicada pela WIRED nesta sexta-feira, 6 de novembro, sobre testes conduzidos pela empresa Vals em redes corporativas fictícias. O resultado interessa a desenvolvedores e equipes de segurança porque reduz a distância entre ferramentas de laboratório, que exigem acesso controlado, e modelos que podem ser baixados e executados por mais pessoas.
O ponto central não é que qualquer pessoa consiga invadir uma empresa com um modelo aberto. O teste ocorreu em ambientes simulados e mede a capacidade de completar objetivos definidos. A conclusão mais prudente é que a defesa digital precisa assumir que recursos avançados de automação podem estar disponíveis fora dos grandes laboratórios. Isso muda a prioridade de quem mantém aplicações, bibliotecas, servidores e redes conectadas à internet.
O que o teste comparou
A Vals avaliou modelos em dois cenários de rede. No primeiro, havia uma rede corporativa simulada acessível por um site público. No segundo, o sistema precisava comprometer uma rede para alcançar outra. As tarefas exigiam várias etapas e instruções encadeadas, uma situação mais próxima de um fluxo real de investigação do que de uma pergunta isolada feita a um chatbot.
A reportagem informa que o modelo Daybreak, da OpenAI, disponível apenas para parceiros confiáveis, concluiu em média 81% dos objetivos nas duas execuções realizadas. O DeepSeek, um modelo chinês com pesos abertos, completou 73% dos objetivos em média. Em algumas tarefas, os resultados foram equivalentes. A diferença ainda existe, mas já não parece grande o suficiente para ser tratada como uma barreira permanente.
A comparação também envolve custo. De acordo com os dados apresentados pela WIRED, uma operação com GPT-6-Sol custaria entre 17 e 46 dólares em tokens, enquanto o uso do DeepSeek ficaria entre 2 e 3 dólares. Modelos abertos podem ser executados em hardware próprio, o que reduz a dependência de uma API externa e facilita testes internos por equipes que não querem enviar código sensível para um provedor.
Por que os pesos abertos importam
Um modelo com pesos abertos permite que a organização baixe os componentes necessários e faça a execução em sua própria infraestrutura, dentro dos limites de licença e capacidade computacional. Isso pode ajudar uma equipe de defesa a analisar código, encontrar padrões suspeitos e priorizar correções sem compartilhar todo o material com um serviço remoto. A mesma característica, porém, reduz o controle que o fornecedor exerce sobre quem usa o modelo.
Em sistemas fechados, o provedor pode exigir cadastro, limitar volume, bloquear determinados pedidos e observar sinais de abuso. Com pesos disponíveis para download, essas barreiras podem não existir ou podem ser modificadas. Por isso, a discussão de segurança deixa de ser apenas sobre o que um modelo sabe fazer. Ela passa a incluir quem consegue obter o modelo, qual hardware tem disponível, quais proteções foram removidas e como a atividade pode ser detectada.
Isso não significa que o modelo aberto substitua um especialista. Invasões reais dependem de configuração, credenciais, falhas existentes, acesso à rede e persistência. Um modelo pode gerar uma hipótese errada, interpretar mal uma resposta ou perder tempo em uma etapa simples. A utilidade prática está na velocidade e na escala: uma ferramenta automatizada pode revisar muitos componentes e testar mais caminhos do que uma equipe pequena conseguiria examinar manualmente.
O risco para quem desenvolve software
O aumento de capacidade torna mais valiosa a higiene básica de segurança. Dependências precisam ser inventariadas, atualizações críticas devem ter responsáveis definidos e serviços expostos na internet precisam de monitoramento. Também é importante revisar permissões, retirar credenciais antigas e reduzir o alcance de cada conta. Essas medidas não dependem de um modelo específico e continuam funcionando mesmo quando a tecnologia muda.
Para quem mantém uma aplicação, a maior mudança é o ritmo. Uma vulnerabilidade que antes seria difícil de encontrar pode ser descoberta com mais rapidez por pesquisadores ou atacantes. O processo de correção deve incluir alerta, análise de impacto, teste, distribuição do patch e acompanhamento depois da atualização. Não basta publicar uma correção e presumir que todos os sistemas receberam a mudança.
Equipes de desenvolvimento também precisam considerar o uso seguro de IA no próprio fluxo de trabalho. Um assistente pode revisar código e apontar problemas, mas não deve receber segredos, tokens de produção ou dados pessoais sem controles. O código sugerido precisa passar por testes e revisão humana. A automação ajuda a encontrar erros, mas não transforma uma sugestão do modelo em garantia de segurança.
Defesa também pode usar modelos abertos
A mesma capacidade que reduz o custo de uma ofensiva pode beneficiar quem está defendendo. Um modelo instalado internamente pode ajudar a classificar alertas, resumir alterações, comparar versões de dependências e procurar padrões anormais em registros. Para ambientes com regras rígidas de privacidade, a execução local pode ser preferível a enviar informações para uma plataforma externa.
O uso defensivo exige limites claros. O sistema deve trabalhar com dados autorizados e ambientes de teste isolados. A equipe deve registrar quais arquivos foram analisados, quais sugestões foram aceitas e quais ações foram executadas. Também é necessário evitar que o agente tenha permissão direta para alterar servidores críticos. A automação pode recomendar uma correção, enquanto a aplicação da mudança segue um processo aprovado.
Outra boa prática é medir o resultado com casos próprios. Um modelo que aparece bem em uma avaliação pública pode ter desempenho fraco em uma tecnologia ou linguagem específica usada pela empresa. Testes internos ajudam a descobrir falsos positivos, omissões e limites de contexto antes que a ferramenta seja incorporada ao processo de resposta a incidentes.
O que o resultado não prova
Os números da Vals não equivalem a uma taxa de sucesso em ataques reais. A amostra foi pequena, os ambientes eram simulados e os objetivos foram definidos pelos avaliadores. O desempenho pode variar conforme a rede, a qualidade das instruções, as ferramentas conectadas ao modelo e o tempo permitido. Também não é possível concluir que todos os modelos de pesos abertos têm capacidade semelhante à do DeepSeek testado.
A reportagem registra ainda que grupos criminosos observados no mundo real costumam economizar recursos e usar modelos mais antigos ou menos capazes. Isso é um lembrete contra o alarmismo. A capacidade técnica de um sistema não determina sozinha a frequência de ataques. Motivação, oportunidade, exposição da vítima e qualidade das defesas continuam importantes.
Ao mesmo tempo, a incerteza não deve ser usada como desculpa para esperar. Se uma equipe sabe que seu código público, seus servidores ou suas dependências podem ser analisados por ferramentas automatizadas, a resposta racional é reduzir a quantidade de falhas exploráveis e melhorar a visibilidade sobre o ambiente.
Como se preparar a partir de agora
O primeiro passo é listar os serviços expostos e as dependências que sustentam cada produto. Depois, vale priorizar correções com base em impacto, facilidade de exploração e presença de dados sensíveis. Autenticação forte, menor privilégio, cópias de segurança testadas e registros centralizados formam uma camada mais importante do que escolher o modelo de IA mais novo.
Empresas que desejam testar modelos abertos devem começar em um ambiente sem acesso a produção. O teste deve definir quais dados entram, quais ferramentas ficam disponíveis, quais saídas precisam de revisão e como o sistema será desligado. Para desenvolvedores individuais, a recomendação é semelhante: usar a IA para aprender, revisar e automatizar tarefas controladas, sem entregar credenciais ou executar comandos desconhecidos diretamente.
A notícia da WIRED aponta para uma mudança de equilíbrio. O avanço de modelos abertos não torna a segurança impossível, mas diminui o valor de confiar apenas na ideia de que ferramentas muito capazes estão restritas a poucas empresas. A defesa precisa evoluir para um cenário no qual análise automatizada é barata, rápida e acessível. Isso começa com correções básicas bem feitas e termina com processos capazes de detectar e responder antes que uma falha se transforme em incidente.
Fonte original: WIRED, Free Chinese AI Models Are Getting Scary Good at Hacking. Imagem: Photo Illustration of 3 AI models running passed the line, crédito Jobanny Cabrera e Getty Images via WIRED.
