Lambert: proibir pesos abertos levaria à proibição das APIs de modelos de fronteira

Nathan Lambert, autor da newsletter Interconnects, afirma que a discussão sobre proibir modelos de pesos abertos parte de uma premissa equivocada. Na avaliação dele, a maioria dos ataques com participação de IA documentados até agora passou por modelos fechados. O gatilho para a análise foi o relatório da Anthropic sobre o GLM-5.3, modelo chinês. Lambert considera que o relatório contorna a pergunta central. A conclusão dele é dura: quem quer proibir pesos abertos em nome da segurança precisa estar disposto a proibir também as APIs públicas de modelos de fronteira.

Onde o argumento a favor da proibição falha

A lógica padrão dos defensores de restrições é simples. Pesos abertos não podem ser revogados, podem passar por fine-tuning e ter as proteções removidas, e por isso seriam mais perigosos. Lambert rebate: o quadro empírico é diferente. Os incidentes reais que puderam ser documentados estão, com mais frequência, ligados a sistemas fechados.

A razão, ao que tudo indica, é prosaica. Um atacante não precisa de um cluster próprio se um modelo forte é vendido por API. O acesso fechado é mais barato, mais rápido e não exige habilidade de engenharia. Os filtros do provedor podem ser burlados com ajuste de prompts ou com contas roubadas, e isso já acontece.

Daí vem a simetria que sustenta toda a posição do autor. Se o critério de proibição for "o modelo é capaz de ajudar em um ataque", ele atinge igualmente os pesos e as APIs. Proibir um e manter o outro significa proteger um modelo de negócio específico, e não a segurança.

O que há de errado com o relatório sobre o GLM-5.3

Segundo a descrição de Lambert, o relatório da Anthropic registra as capacidades do modelo chinês, mas não responde à pergunta-chave: quanto risco os pesos abertos acrescentam em comparação com o que o atacante já obtém por APIs fechadas. Sem essa linha de base, qualquer número sobre capacidades "perigosas" não diz nada sobre a utilidade de uma proibição. O modelo pode escrever exploits com segurança, mas, se os sistemas pagos de fronteira fazem o mesmo, proibir os pesos não muda nada.

Há também a questão dos interesses. A Anthropic lança modelos fechados, e o argumento contra pesos abertos coincide com a posição comercial dela. Isso não significa que as conclusões estejam erradas. Mas é justamente por isso que a metodologia precisa ser transparente e a comparação com equivalentes fechados, obrigatória.

O fator chinês

A terceira parte do argumento diz respeito aos laboratórios chineses. Eles avaliam os riscos à sua maneira e decidem publicar pesos com base em um critério próprio. Uma proibição nos EUA ou na UE não cancela lançamentos fora dessas jurisdições. Pesos que já foram publicados na rede continuam acessíveis a todos, inclusive a quem a proibição deveria barrar.

Principais pontos da análise:

• a maioria dos ataques documentados com IA passou, até agora, por modelos fechados;
• o relatório da Anthropic sobre o GLM-5.3 não compara o risco dos pesos abertos com o das APIs fechadas;
• os laboratórios chineses usam um critério próprio de avaliação de ameaças;
• uma proibição coerente de pesos abertos teria de abranger também as APIs públicas de modelos de fronteira.

O que equipes e reguladores devem verificar

Para os reguladores, a conclusão é prática: qualquer relatório sobre riscos cibernéticos de um modelo deve ser lido com uma pergunta sobre a linha de base. O que o atacante já conseguia fazer sem esse modelo e o que faz com ele? Sem resposta, as conclusões não servem de fundamento para uma lei.

Para empresas que constroem produtos sobre pesos abertos, é sensato manter um plano B. O risco de restrições existe, e a dependência de um único modelo, sobretudo de origem chinesa, pode virar um problema de compliance. Guardar cópias dos pesos e testar a substituição com antecedência sai mais barato do que migrar às pressas.

As equipes de segurança recebem uma lição mais importante: é preciso monitorar também as APIs fechadas. Se os ataques reais passam por elas, controle de abusos, verificação de clientes e análise de requisições anômalas rendem mais do que a disputa sobre licenças.