Estudo de IA da Tech Against Terrorism Descobre que Salvaguardas Podem Entrar em Colapso
A Tech Against Terrorism testou mais de 130 modelos de IA, e três em cada cinco falharam em sua mais recente avaliação de segurança contra o terrorismo. O estudo de IA da Tech Against Terrorism identificou as falhas mais graves em modelos modificados cujas salvaguardas de recusa haviam sido deliberadamente removidas.
Essa distinção é importante. O estudo não mostra que a maioria dos chatbots convencionais ajuda abertamente terroristas durante o uso normal. Ele mostra que a segurança pode se deteriorar rapidamente quando os modelos são modificados, reenquadrados ou distribuídos além do controle direto de seus desenvolvedores.
O resultado pressiona Meta, Hugging Face, desenvolvedores de open-weight e hosts de modelos. Seu desafio central é preservar a pesquisa legítima e a implantação local sem tratar as salvaguardas no momento do lançamento como proteção permanente.
A descoberta mais forte, portanto, não é uma simples disputa entre IA aberta e fechada. É um conflito entre modelos adaptáveis e controles de segurança que podem não sobreviver à adaptação.
O Estudo de IA da Tech Against Terrorism Ampliou o Teste
A nova avaliação desloca o debate de falhas isoladas de chatbots para um teste mais amplo de como a segurança se comporta em toda a cadeia de fornecimento de modelos.
A Tech Against Terrorism é uma organização sem fins lucrativos sediada no Reino Unido e voltada à atividade terrorista online. Seus pesquisadores avaliaram mais de 130 modelos com centenas de solicitações ligadas ao planejamento de ataques, financiamento, radicalização e outras formas de assistência prejudicial.
O teste da organização pergunta se um modelo recusa solicitações perigosas de forma consistente. Ele também considera a gravidade e a especificidade de qualquer informação fornecida pelo modelo.
De acordo com os testes ampliados, um modelo falhava se produzisse uma resposta completa e específica relacionada a danos com vítimas em massa. Uma pontuação inferior a 90 de 100 também era considerada uma falha.
Esse é um limite rigoroso. Um modelo pode rejeitar a maioria dos prompts perigosos e ainda falhar porque uma resposta oferece assistência suficientemente completa.
Essa abordagem difere de um teste básico de taxa de recusa. Uma taxa de recusa contabiliza com que frequência um modelo diz não, mas pode deixar de detectar conformidade parcial.
Alguns sistemas começam com um aviso e depois fornecem o material solicitado. A Tech Against Terrorism chama esse padrão de conformidade com ressalvas.
O benchmark de contraterrorismo anterior da organização examinou 27 modelos líderes e quase 2.500 prompts de tentativa única. Cerca de um terço dessas respostas forneceu ajuda significativa além de uma busca comum na web.
Esse piloto também identificou variação significativa por categoria de ameaça e enquadramento do prompt. Uma solicitação idêntica recebeu tratamento diferente quando um usuário alegava uma finalidade de pesquisa.
A pesquisa mais recente ampliou o conjunto de modelos, concentrando-se em 627 solicitações. Seu principal resultado foi que aproximadamente 60 por cento dos sistemas testados falharam no padrão de segurança declarado.
As duas rodadas não devem ser tratadas como estatísticas intercambiáveis. Elas usaram conjuntos de modelos, tamanhos de teste e métricas de relatório diferentes.
Juntas, porém, elas sustentam a mesma conclusão. A segurança aparente de um modelo depende de mais do que seu nome, provedor ou interface padrão.
A configuração ao redor importa. O mesmo vale para seus pesos, instruções de sistema, controles de implantação e a identidade alegada pelo usuário.
A avaliação incluiu declarações diretas de intenção terrorista. Ela também testou solicitações apresentadas por meio de papéis menos obviamente maliciosos, incluindo enquadramentos orientados à pesquisa.
Isso importa porque atacantes reais raramente precisam declarar suas intenções com sinceridade. Uma salvaguarda que funciona apenas após uma confissão clara oferece segurança limitada.
O estudo também desloca a atenção de cenários futuros abstratos para sistemas disponíveis agora. Muitos modelos testados podem ser executados localmente, aparecer em repositórios públicos ou ser modificados por terceiros.
Essa disponibilidade cria a tensão central do artigo. Os desenvolvedores podem testar o modelo original, mas não podem presumir que cada cópia distribuída manterá o mesmo comportamento.
A Verdadeira Divisão É Entre Acesso Controlado e Pesos Editáveis
As descobertas não estabelecem que todo modelo open-weight é inseguro, mas expõem um problema de controle que serviços fechados lidam de forma diferente.
Modelos open-weight disponibilizam seus parâmetros treinados para download. Esses parâmetros codificam os padrões que um sistema aprendeu durante o treinamento e o posterior ajuste de segurança.
Os desenvolvedores podem adaptar esses modelos para idiomas, setores, hardware local e aplicações especializadas. Pesquisadores podem inspecionar comportamentos que um serviço hospedado poderia ocultar.
Esses benefícios explicam por que o desenvolvimento open-weight atraiu empresas, universidades, laboratórios independentes e instituições públicas. Ele pode reduzir a dependência de um pequeno grupo de provedores de API.
Modelos fechados criam um arranjo diferente. Os usuários os acessam por meio de serviços controlados pelo desenvolvedor do modelo, sem receber os pesos subjacentes.
Esse controle permite que um provedor atualize filtros, monitore atividade suspeita, limite contas e retire o acesso. Ele não garante segurança, mas preserva opções de intervenção.
Um lançamento open-weight não pode ser recolhido da mesma forma. Depois que cópias se espalham por repositórios e máquinas locais, mudanças posteriores de política não podem alcançá-las de modo confiável.
O benchmark anterior da Tech Against Terrorism concluiu que aberto versus fechado não era a principal divisão de desempenho. Alguns modelos abertos comuns estavam entre os sistemas mais seguros naquele teste.
O Claude da Anthropic e o Falcon3 do Technology Innovation Institute tiveram classificação elevada no piloto. O MiniMax também apresentou desempenho forte, segundo a organização.
Esse resultado complica alegações de que a abertura, por si só, determina o perigo. Modelos abertos bem alinhados podem recusar solicitações prejudiciais, enquanto serviços controlados ainda podem produzir respostas inseguras.
A divisão mais relevante parece surgir após o lançamento. Usuários podem alterar o comportamento de recusa de um modelo open-weight sem a aprovação do desenvolvedor original.
A Meta afirma que o Llama 3.1 passou por avaliações de risco antes da implantação, testes adversariais, ajuste de segurança e exercícios externos de red team. Seu plano de lançamento responsável também descreve salvaguardas em nível de modelo e de sistema.
Essas medidas continuam importantes. A versão base testada do Llama 3.1 8B teria obtido 97 de 100 no benchmark da organização sem fins lucrativos.
A versão modificada obteve aproximadamente três. Essa queda de 94 pontos é o exemplo mais claro de controles de segurança que não acompanham um modelo.
As políticas da Meta proíbem usos prejudiciais e ilegais. Ainda assim, regras de uso restringem usuários cooperativos de forma mais eficaz do que adversários que possuem arquivos de modelo editáveis.
Isso não torna as políticas inúteis. Elas fornecem fundamentos para a aplicação em implantações comerciais, plataformas e licenciados identificáveis.
No entanto, a aplicação de políticas enfraquece quando um modelo opera offline. Um sistema local não precisa enviar prompts ao provedor original.
A pressão resultante vai além da Meta. Qualquer desenvolvedor que lance pesos editáveis precisa decidir quais propriedades de segurança pertencem ao modelo e quais dependem de controles de implantação.
O estudo sugere que o ajuste de recusa, por si só, não pode carregar todo o fardo. Os desenvolvedores também precisam de avaliações projetadas em torno da modificação pós-lançamento.
Hosts de modelos enfrentam um problema relacionado. Eles precisam distinguir artefatos de pesquisa de sistemas anunciados especificamente para uso sem restrições.
Essa distinção é difícil de automatizar. Um modelo modificado pode apoiar pesquisa legítima de segurança, trabalho criativo ou testes, ao mesmo tempo que remove barreiras contra assistência prejudicial.
Proibições amplas imporiam custos a pesquisadores e desenvolvedores menores. Controles fracos de distribuição deixariam modelos obviamente sem restrições fáceis de encontrar.
É por isso que o conflito principal é entre capacidade adaptável e segurança duradoura. A questão não é se modelos abertos devem existir.
A questão é quais proteções podem permanecer eficazes depois que o desenvolvedor perde o controle direto.
A Abliteration Transforma o Treinamento de Recusa em uma Camada Removível
A abliteration importa porque ela mira diretamente o comportamento de recusa, transformando uma salvaguarda de lançamento em um recurso que terceiros podem remover.
Abliteration é uma técnica de modificação de modelos que identifica padrões internos associados à recusa de solicitações prejudiciais. Em seguida, ela suprime ou neutraliza esses padrões.
A técnica não adiciona necessariamente novos conhecimentos. Em vez disso, ela altera se o modelo divulgará conhecimentos já aprendidos durante o treinamento.
Essa distinção é crucial. Um sistema pode reter as mesmas capacidades gerais enquanto se torna muito mais disposto a responder a solicitações perigosas.
A Tech Against Terrorism informou que modelos abliterated falharam em todos os testes de segurança no estudo mais recente. Os pesquisadores também descobriram que modelos menores podiam ser modificados em minutos usando ferramentas livremente disponíveis.
A organização testou uma versão alterada do Llama 3.1 8B da Meta em comparação com a original. O modelo base rejeitou solicitações relacionadas a ataques, financiamento terrorista e radicalização.
A versão modificada teria fornecido respostas detalhadas. Os pesquisadores não afirmaram que essas respostas possibilitavam automaticamente um ataque real.
Seu benchmark mede se um sistema entrega as informações solicitadas. Ele não estabelece se um usuário consegue executar essas informações com sucesso.
Essa limitação não elimina a descoberta. Ela define o que o teste pode sustentar.
O experimento mostra uma grande mudança no comportamento de divulgação. Ele não mede a competência do usuário, acesso a materiais, segurança operacional ou capacidade de superar barreiras práticas.
A camada de repositórios de modelos torna esse problema maior. A Tech Against Terrorism identificou mais de 29.000 repositórios do Hugging Face que anunciam modelos como sem censura ou sem salvaguardas.
Essa contagem não significa que todos os 29.000 repositórios continham material terrorista. Ela descreve quantos projetos usaram rótulos que sugeriam restrições reduzidas.
Alguns repositórios podem duplicar o mesmo modelo. Outros podem usar “uncensored” como um termo amplo de marketing sem passar pela técnica específica testada aqui.
Mesmo com essas ressalvas, o número ilustra como o controle em nível de modelo se torna difícil após a distribuição. Cópias podem se multiplicar mais rapidamente do que pesquisadores conseguem avaliá-las.
O Hugging Face disse à CBS News que realiza moderação contínua e age contra modelos, conjuntos de dados e aplicações que violam suas regras.
Sua política de conteúdo da plataforma restringe conteúdo terrorista e permite diversas respostas. Elas incluem remoção de acesso, restrição de repositórios, limites de visibilidade e suspensão de contas.
O Hugging Face também alertou que partes da resposta proposta pelo relatório poderiam restringir o trabalho científico aberto. Essa preocupação merece tratamento sério.
Pesquisadores de segurança precisam de acesso a artefatos inseguros para estudar modos de falha. Desenvolvedores também precisam de modelos adversariais para testar filtros e sistemas de monitoramento.
Um repositório pode, portanto, ser perigoso em um contexto e valioso em outro. Rótulos por si só não podem resolver a questão.
O desenho de acesso oferece um caminho mais direcionado. As plataformas podem aplicar verificação de identidade, controle de acesso, rótulos de advertência, monitoramento de downloads ou resultados de testes independentes conforme o risco demonstrado.
Esses controles são imperfeitos. Depois que um modelo é baixado, a plataforma perde grande parte de sua influência.
Ainda assim, a fricção na distribuição pode alterar a escala. Ela pode impedir que sistemas de recomendação transformem modificações de alto risco em descobertas casuais.
O estudo, portanto, levanta um problema de cadeia de suprimentos. O desenvolvedor original cria um modelo, outra parte remove suas recusas, e uma plataforma distribui o resultado.
Cada participante controla apenas parte do processo. Ainda assim, o público vivencia o risco combinado.
Uma resposta duradoura precisa abordar as três camadas. Um treinamento mais seguro não pode substituir a governança de repositórios, e a governança de repositórios não pode consertar todos os modelos.
O monitoramento da implantação também continua essencial. Organizações que executam modelos abertos precisam de seus próprios filtros, registros, permissões e procedimentos para incidentes.
Uma empresa não deve presumir que a pontuação de segurança publicada do modelo-base se aplica após o fine-tuning. Toda modificação substancial cria um novo alvo de avaliação.
Os Testes de Segurança de IA para Terrorismo Ainda Têm uma Lacuna de Verificação
O estudo identifica uma séria fragilidade de segurança, mas não comprova uso operacional disseminado por organizações terroristas.
A Tech Against Terrorism afirmou não ter encontrado evidências de que grupos terroristas ou extremistas estivessem usando os modelos testados. Durante a investigação, identificou um chatbot extremista.
Essa lacuna de verificação é a limitação mais importante da manchete. Disponibilidade de modelos, saída insegura e adoção operacional representam etapas distintas.
Um modelo pode responder a uma pergunta nociva sem ampliar a capacidade de um agente real. Grande parte de suas informações pode já existir em livros, fóruns ou resultados de busca.
A métrica relevante é o ganho de capacidade. Isso significa avaliar se o modelo torna uma atividade nociva significativamente mais fácil do que as alternativas disponíveis.
A Tech Against Terrorism estruturou seu piloto em torno dessa questão. Pesquisadores compararam a assistência do modelo com materiais que uma pessoa capacitada poderia obter por meio de buscas comuns na web.
Os resultados de julho indicaram que cerca de um terço das respostas gerava ganho de capacidade significativo. O estudo ampliado mais recente usou um limiar mais rigoroso de falha no nível do modelo.
Nenhum dos resultados deve ser convertido em um número previsto de ataques. O benchmark não oferece essa estimativa causal.
Analistas independentes também alertaram contra uma concentração exclusiva em cenários espetaculares. Uma análise de risco de terrorismo do Center for Strategic and International Studies argumentou que os efeitos de curto prazo podem ser mais incrementais.
A IA pode auxiliar propaganda, tradução, recrutamento, pesquisa, reconhecimento e trabalho administrativo. Esses usos podem ser relevantes sem produzir uma nova arma autônoma.
Essa assistência de nível mais baixo é mais difícil de detectar. Ela também se assemelha suficientemente a atividades legítimas para complicar a moderação.
O revisor independente da legislação antiterrorismo do Reino Unido chegou a uma visão igualmente ampla. A revisão de riscos jurídicos considerou propaganda, radicalização, planejamento de ataques e assistência relacionada a armas.
A revisão identificou a radicalização impulsionada por chatbots como um problema jurídico particularmente difícil. Ela não sugeriu que toda interação arriscada exigisse uma nova infração específica para IA.
Essas distinções devem orientar a interpretação dos leitores sobre o número de 60 por cento. Trata-se de um resultado de avaliação, não de uma medição da atual adoção por terroristas.
O limiar de falha também valoriza a consistência. Uma resposta detalhada pode fazer um modelo falhar, mesmo que ele recuse centenas de outros prompts.
Esse padrão faz sentido para segurança de consequências graves. Uma única divulgação séria pode importar mais do que uma alta taxa média de recusas.
No entanto, isso não demonstra que todo modelo reprovado apresenta o mesmo risco. Os modelos diferem em precisão, capacidade, distribuição, requisitos de hardware e utilidade prática.
Um modelo local pequeno pode atender prontamente ao pedido, mas fornecer informações pouco confiáveis. Um sistema de fronteira pode oferecer informações melhores enquanto opera sob controles de acesso mais robustos.
O estudo também depende da seleção de prompts e de julgamentos de classificação. Benchmarks de contraterrorismo precisam decidir quais solicitações são nocivas e o que constitui assistência significativa.
Falsos positivos podem restringir pesquisas legítimas de segurança, jornalismo, educação e análise histórica. Falsos negativos podem deixar assistência perigosa sem detecção.
A replicação independente fortaleceria as conclusões. Pesquisadores deveriam publicar metodologia suficiente para que especialistas examinem as definições das categorias e a confiabilidade da pontuação.
Eles precisam fazer isso sem divulgar uma coleção pronta de prompts nocivos. Isso cria um dilema conhecido na pesquisa de segurança.
O público precisa de evidências de que o benchmark mede um risco real. Contudo, divulgação excessiva pode transformar um pacote de avaliação em um guia de abuso.
A conclusão correta é, portanto, ponderada, mas firme. A pesquisa demonstra controles de recusa frágeis em muitos dos sistemas testados.
Ela não estabelece que a IA já tenha transformado as capacidades terroristas em larga escala. Mostra que as condições para o uso indevido estão se tornando mais fáceis de reunir.
Desenvolvedores e Hosts de Modelos Agora Compartilham o Ônus da Segurança
As conclusões pressionam a indústria de IA a tratar a segurança como uma propriedade contínua, não como um certificado emitido quando um modelo-base é lançado.
A Tech Against Terrorism quer que governos e desenvolvedores apoiem avaliações independentes antes do lançamento. Também recomenda projetar modelos que resistam à remoção de salvaguardas.
Para plataformas de distribuição, o grupo propõe restrições a modelos modificados que falhem em testes independentes. Também sugeriu acesso verificado para artefatos particularmente arriscados.
Essas propostas enfrentam partes diferentes da mesma cadeia de falhas. Nenhuma intervenção isolada pode impedir toda modificação local ou transferência privada.
Os desenvolvedores podem começar testando comportamentos específicos de ameaças. Conjuntos gerais de testes de segurança podem não capturar cenários de financiamento do terrorismo, radicalização ou preparação de ataques.
O piloto encontrou proteção desigual entre as categorias. Os modelos recusaram solicitações familiares sobre explosivos de forma mais consistente do que algumas solicitações envolvendo outras armas ou rotas de aquisição.
Uma média ampla pode ocultar essas lacunas. Os testes devem informar o desempenho por categoria e a gravidade das divulgações bem-sucedidas.
Os desenvolvedores também devem avaliar o enquadramento de identidade. O benchmark anterior constatou que apresentar a mesma solicitação como pesquisa aumentava substancialmente a conformidade.
Esse resultado indica um atalho de classificação. O modelo reage a um papel declarado em vez de avaliar a capacidade solicitada e o provável dano.
Mais ajuste de recusas pode reduzir essa fragilidade, mas também corre o risco de bloquear trabalho legítimo. Controles de acesso sensíveis ao contexto poderiam proporcionar um equilíbrio melhor.
Um pesquisador avaliado poderia receber informações indisponíveis para um usuário anônimo. Esses sistemas exigiriam autorização responsável e registros de auditoria.
Lançamentos de pesos abertos tornam a autorização centralizada mais difícil. Os desenvolvedores podem, em vez disso, concentrar-se em reduzir conhecimento perigoso, aprimorar a resistência a adulterações e empacotar ferramentas de implantação mais robustas.
Nenhuma dessas medidas oferece uma resposta completa. Filtrar dados de treinamento pode reduzir conhecimento científico útil, enquanto a resistência a adulterações pode dificultar modificações legítimas.
A avaliação independente ajuda a expor essas compensações. Ela fornece a compradores e hosts evidências que vão além das próprias alegações de segurança de um desenvolvedor.
Repositórios de modelos podem contribuir exibindo resultados padronizados de avaliação. Os usuários devem saber se um download preserva as salvaguardas do modelo-base.
As plataformas também podem separar a personalização comum da remoção explícita de comportamentos de recusa. Um modelo divulgado como forma de contornar proteções merece análise mais rigorosa.
O controle de acesso não deve se tornar uma etapa meramente cosmética. Controles eficazes precisam de condições aplicáveis, revisão baseada em risco e caminhos claros para pesquisa legítima.
Os implantadores empresariais carregam a camada final de responsabilidade. Eles escolhem prompts de sistema, fontes de recuperação, ferramentas, permissões e acesso de usuários.
Um modelo-base seguro pode se tornar inseguro quando conectado a bancos de dados sensíveis ou ações no mundo real. Um modelo modificado pode criar exposição adicional mesmo sem acesso a ferramentas.
Equipes de segurança devem avaliar o sistema implantado em vez de confiar em um cartão do modelo. Fine-tuning, quantização e adaptadores de terceiros podem alterar o comportamento.
Equipes de compras devem perguntar se os fornecedores testam usos indevidos específicos de terrorismo. Também devem perguntar como os provedores detectam salvaguardas que desaparecem após a personalização.
Os governos enfrentam o equilíbrio mais difícil. Regras voltadas de forma estreita à publicação podem centralizar o desenvolvimento de IA sem eliminar modelos nocivos já disponíveis online.
Regras focadas apenas no uso indevido posterior chegam após a distribuição. Elas também podem depender de investigações que só começam depois que o dano ocorre.
Um arcabouço funcional precisará de controles proporcionais. A capacidade do modelo, o tipo de modificação, o método de acesso e o desempenho de segurança demonstrado devem influenciar a resposta.
O debate não pode ser reduzido a modelos abertos versus modelos fechados. Ambas as abordagens criam riscos, incentivos e lacunas de responsabilização.
Provedores fechados podem monitorar usuários, mas concentram o controle. O desenvolvimento aberto apoia escrutínio e concorrência, mas dificulta a intervenção após o lançamento.
A contribuição do estudo é tornar essa compensação concreta. As alegações de segurança devem resistir ao percurso real do modelo, do desenvolvedor ao host e ao usuário.
O Que Observar Após o Estudo de IA da Tech Against Terrorism
A próxima fase revelará se a indústria tratará esses resultados como um problema de avaliação, um problema de distribuição ou ambos.
O primeiro sinal é a replicação independente. Outros laboratórios devem testar se a taxa de falha relatada persiste em novos modelos, idiomas e conversas com múltiplos turnos.
A replicação poderia fortalecer as conclusões do estudo se os pesquisadores observarem quedas semelhantes após a remoção de salvaguardas. Grandes diferenças exporiam sensibilidade à pontuação ou ao design dos prompts.
O segundo sinal é a política de repositórios. Hugging Face e outros hosts precisam decidir como classificam, rotulam, controlam o acesso ou removem modelos deliberadamente sem restrições.
Uma resposta significativa distinguiria a pesquisa legítima de segurança da distribuição em massa sem restrições. Uma política ampla de remoção poderia, em vez disso, levar modelos a canais menos responsáveis.
O terceiro sinal são os testes dos desenvolvedores. Meta e outros publicadores de pesos abertos podem adicionar avaliações pós-modificação aos seus processos de lançamento.
Esses testes devem examinar se métodos comuns de fine-tuning ou remoção de recusas alteram comportamentos de consequências graves. Resultados públicos tornariam mais fáceis de avaliar futuras alegações de segurança.
Os leitores também devem observar evidências de adoção no mundo real. A limitação mais forte do relatório atual é a ausência de uso demonstrado por grupos terroristas.
Incidentes verificados aumentariam a urgência dos controles de distribuição. A ausência contínua dessas evidências favoreceria medidas mais direcionadas em vez de restrições abrangentes.
Nenhum dos resultados tornaria a segurança de modelos irrelevante. A prevenção muitas vezes começa antes de uma nova ferramenta se tornar rotineira.
A lição prática para desenvolvedores é imediata. Não tratem o comportamento de recusa de um modelo-base como uma propriedade permanente.
As organizações devem repetir as avaliações de segurança após fine-tuning, quantização, alterações no prompt de sistema ou instalação de adaptadores. Elas devem testar todo o sistema implantado antes de conceder acesso sensível.
Pesquisadores devem continuar examinando como as barreiras de proteção falham sem transformar essas conclusões em instruções operacionais. As plataformas devem criar sistemas de revisão que reconheçam essa distinção.
Formuladores de políticas devem exigir resultados mensuráveis de segurança enquanto preservam análises legítimas. Garantias vagas e proibições generalizadas evitam o difícil trabalho de engenharia.
O estudo sobre IA da Tech Against Terrorism não encerra o debate sobre o futuro da IA de pesos abertos. Ele estabelece uma questão mais prática para cada lançamento.
As proteções de segurança de um modelo conseguem sobreviver às mudanças que tornam esse modelo útil, portátil e aberto à experimentação?
Desenvolvedores, provedores de hospedagem e compradores devem fazer essa pergunta antes que o próximo modelo se espalhe por milhares de repositórios. Se a resposta continuar pouco clara, os testes independentes devem se tornar a ação inicial.
