Ferramenta de Segurança de IA da CTC Combate Roubo de Modelos com West Point

A CTC se uniu ao Robotics Research Center de West Point para criar uma ferramenta de segurança de IA que ataca modelos de aprendizado de máquina antes que adversários o façam. A colaboração tem como alvo o roubo de modelos e o vazamento de privacidade, dois riscos que os testes convencionais de software raramente medem bem. Esse cenário atribui à ferramenta de segurança de IA da CTC uma função exigente: transformar ataques de pesquisa em evidências repetíveis para decisões de defesa.

O projeto se concentra em um pipeline de roubo de modelos dentro de um sistema de avaliação mais amplo. A Concurrent Technologies Corporation, conhecida como CTC, afirma que o pipeline automatizará tarefas de teste e avaliação de desenvolvimento. Ele examinará como arquiteturas de modelos, métodos de treinamento e técnicas defensivas respondem a diferentes ataques de roubo.

A ideia parece direta, mas o padrão é incomumente elevado. Uma avaliação de defesa útil não pode apenas mostrar que um ataque foi executado. Ela deve medir o que o ataque recuperou, comparar resultados entre configurações e explicar se um modelo continua aceitável para sua missão.

Esse requisito coloca o projeto diante de seu principal adversário: testes de segurança de IA subjetivos e intensivos em mão de obra. Avaliações existentes frequentemente dependem de especialistas que revisam dados reconstruídos e interpretam se um ataque foi bem-sucedido. Essa abordagem se torna difícil de repetir entre muitas arquiteturas, conjuntos de dados e condições de acesso.

A CTC e West Point tentam tornar esse trabalho mais sistemático. O desafio é provar que a automação pode ampliar os testes de segurança sem esconder um contexto importante por trás de uma pontuação conveniente.

A Ferramenta de Segurança de IA da CTC Transforma Roubo de Modelos em Teste

A colaboração trata o roubo de modelos como um problema de engenharia mensurável, não como um alerta hipotético.

A CTC anunciou a parceria com o Robotics Research Center da U.S. Military Academy em 9 de setembro de 2026. Segundo o anúncio do projeto, a equipe está projetando um pipeline de roubo de modelos de aprendizado de máquina para testes e avaliações de desenvolvimento automatizados.

Roubo de modelos descreve ataques que recuperam informações sobre um modelo, reproduzem seu comportamento ou expõem características de seus dados de treinamento. O NIST define a extração de modelos como um ataque à privacidade que obtém detalhes sobre a arquitetura ou os parâmetros de um modelo. Ataques relacionados de inversão de modelos tentam reconstruir informações semelhantes aos dados de treinamento originais.

Essas distinções importam porque os danos podem ir além da propriedade intelectual. Um modelo roubado pode revelar escolhas de projeto, fronteiras de decisão ou capacidades especializadas. Um ataque de inversão pode expor padrões sensíveis que o modelo aprendeu a partir de dados operacionais.

Os riscos se tornam mais sérios quando um sistema lida com imagens militares ou outras informações restritas. Um modelo não precisa retornar palavra por palavra um registro de treinamento armazenado para vazar algo valioso. Características de classe reconstruídas podem revelar o que o sistema reconhece e como separa alvos.

A CTC afirma que seu pipeline ajudará a identificar quais arquiteturas e técnicas de treinamento são mais suscetíveis a vazamentos de privacidade. O projeto também testará defesas, incluindo privacidade diferencial e treinamento adversarial.

A privacidade diferencial é uma abordagem matemática que limita o quanto cada exemplo individual de treinamento pode influenciar um resultado observável. O treinamento adversarial expõe um modelo a exemplos manipulados durante o desenvolvimento para que ele possa resistir melhor a ataques relacionados. Nenhuma das defesas elimina todos os riscos, e ambas podem afetar a utilidade do modelo.

Portanto, o sistema de avaliação deve comparar mais do que o sucesso do ataque. Ele precisa dar suporte a experimentos entre modelos, ataques e defesas, preservando detalhes suficientes para que especialistas compreendam o resultado. A CTC afirma que está combinando bases de código proprietárias em componentes modulares e reconfiguráveis para esse fim.

O relatório anual do exercício fiscal de 2025 da CTC identifica o sistema mais amplo como PROTECT. O relatório afirma que a empresa e West Point estão desenvolvendo o PROTECT para automatizar e ampliar ferramentas e métricas de teste e avaliação de desenvolvimento.

Essa referência anterior mostra que o anúncio de setembro não é o início de um conceito inexplorado. Trata-se de uma descrição pública de uma linha de pesquisa já representada no portfólio de desenvolvimento da CTC.

O anúncio não divulga valor de contrato, cronograma de entrega, cliente operacional ou data de implantação. Também não identifica um processo de certificação pelo qual os sistemas passariam após usar a ferramenta. Por enquanto, a entrega mais clara é um pipeline experimental de avaliação, não um selo universal de segurança.

Esse limite é importante. A CTC e West Point estão criando mecanismos para produzir evidências sobre o risco à privacidade. Elas não afirmam que uma única avaliação pode estabelecer a segurança de todos os modelos de defesa.

A tensão começa aí. Uma ferramenta escalável pode ampliar a cobertura dos testes, mas uma saída padronizada também pode criar falsa confiança quando usuários ignoram as premissas por trás da pontuação.

Por Que a IA de Defesa Precisa de Evidências de Segurança Repetíveis

Programas de defesa precisam de testes que acompanhem o desenvolvimento de modelos e ainda produzam evidências que comandantes e avaliadores possam contestar.

A pressão vem do uso crescente de aprendizado de máquina em sistemas que analisam imagens, priorizam informações, apoiam a autonomia e informam escolhas operacionais. Cada implantação cria uma nova combinação de dados, arquitetura, hardware, condições de missão e acesso de atacantes.

A garantia tradicional de software continua necessária, mas não cobre toda a superfície de ataque do aprendizado de máquina. Um programa pode corrigir vulnerabilidades conhecidas de software e ainda implantar um modelo que expõe informações sensíveis por suas saídas. Ele também pode ultrapassar um limite médio de precisão enquanto permanece vulnerável a consultas cuidadosamente projetadas.

As forças armadas dos EUA já identificaram essa lacuna de testes como um problema institucional. Seu caminho de implementação para IA responsável pede testes, avaliação, verificação e validação durante todo o ciclo de vida de uma capacidade de IA.

Esse caminho também pede ferramentas que detectem degradação natural e ataques adversariais. Ele descreve um ecossistema compartilhado de testes com métricas de confiabilidade e confiança. O projeto da CTC se encaixa nessa direção porque busca transformar uma classe difícil de ataque em experimentos repetíveis.

A pressão imediata recai sobre gerentes de programa, organizações de teste e desenvolvedores de modelos. Eles precisam decidir se um sistema está pronto enquanto os métodos de ataque relevantes continuam mudando. Também precisam documentar por que uma defesa específica foi selecionada e qual risco residual permanece.

Uma avaliação manual pode se tornar um gargalo. Resultados de inversão de modelos podem incluir imagens reconstruídas que exigem inspeção de um especialista. Um avaliador pode considerar uma imagem uma falha óbvia de privacidade, enquanto outro pode enxergar apenas uma vaga semelhança.

Essa discordância não é uma questão menor de fluxo de trabalho. Ela dificulta comparações entre equipes de teste e ciclos de desenvolvimento. Também complica decisões sobre se uma mitigação reduziu o risco ou apenas alterou a aparência dos dados reconstruídos.

A escala cria outro problema. Testar uma arquitetura com um ataque fornece um resultado restrito. Um programa confiável pode precisar examinar diversas arquiteturas, condições de acesso, métodos de ataque, conjuntos de dados e configurações defensivas.

O número de combinações cresce rapidamente, mesmo antes de os ambientes de missão entrarem em cena. A revisão humana não pode desaparecer, mas torna-se cada vez mais cara quando cada experimento exige uma interpretação personalizada.

A ferramenta de segurança de IA da CTC aborda essa pressão ao estruturar o trabalho como um pipeline. Um pipeline pode executar ataques, capturar saídas, calcular métricas e preservar detalhes de configuração por meio de um processo comum. Essa estrutura permite comparações e facilita repetir uma avaliação após a mudança de um modelo.

A repetibilidade também é importante para a supervisão de aquisições. Uma alegação de segurança se torna mais útil quando revisores podem rastreá-la até uma versão definida do modelo, uma premissa de ataque, um conjunto de dados e um método de medição. Sem essa rastreabilidade, um resultado favorável pode dizer pouco sobre o sistema implantado.

West Point oferece uma combinação de contexto militar e pesquisa técnica. Seu Robotics Research Center faz parte do Department of Electrical Engineering and Computer Science. O centro apoia pesquisas em robótica e sistemas autônomos e inclui o Laboratory for Artificial Intelligence Research and Engineering.

A CTC oferece pesquisa aplicada, engenharia de sistemas e experiência em testes. A combinação é útil porque o aprendizado de máquina adversarial fica entre a pesquisa e a garantia operacional. Os métodos de ataque precisam ser tecnicamente confiáveis, enquanto as saídas precisam continuar utilizáveis por pessoas que tomam decisões de programa.

A parceria não elimina a dificuldade central. Organizações de defesa precisam decidir quanta evidência é suficiente para uma missão específica. Um modelo usado para classificação administrativa tem consequências diferentes de um que apoia decisões operacionais sensíveis ao tempo.

Uma avaliação repetível ajuda as equipes a fazer essa pergunta de forma consistente. Ela não pode responder à questão do risco de missão sem julgamento humano.

A Inversão de Modelos Mostra Por Que os Testes Manuais Têm Dificuldade

A inversão de modelos é difícil de avaliar porque uma saída reconstruída pode expor informações significativas sem reproduzir perfeitamente os dados originais.

A pesquisa por trás da colaboração oferece uma visão mais clara do mecanismo. Em setembro de 2025, Tyler Shumaker, Jessica Carpenter, David Saranchak e Nathaniel D. Bastian publicaram um trabalho sobre um pipeline automatizado de avaliação de inversão de modelos.

A pesquisa publicada descreve a inversão de modelos como um esforço para reconstruir informações de treinamento explorando relações entre entradas, representações internas e saídas do modelo. Atacantes podem usar previsões, pontuações de confiança, gradientes ou outras informações disponíveis.

As condições de acesso moldam o ataque. Em um cenário de caixa branca, o atacante possui amplo conhecimento do alvo, potencialmente incluindo gradientes e parâmetros. Em um cenário de caixa preta, o atacante pode ver apenas as saídas retornadas por uma interface.

O acesso limitado não garante segurança. Os pesquisadores observam que ataques modernos podem combinar otimização com métodos generativos e dados públicos. Esses recursos de apoio podem ajudar um atacante a produzir reconstruções reconhecíveis mesmo sem acesso interno completo.

O artigo se concentra em um problema central de medição. Observadores humanos podem achar as inversões difíceis de interpretar, e seus julgamentos podem ser subjetivos. Uma reconstrução desfocada ainda pode preservar informações específicas de classe que ajudam um atacante a compreender o modelo-alvo.

Os autores introduziram quatro dimensões de risco adversarial para quantificar a perda de privacidade. Eles combinaram métodos de inversão de modelos com modelos de visão e linguagem, sistemas que processam conjuntamente imagens e texto, para apoiar análises automatizadas.

O pipeline usou modelos de visão e linguagem para classificação zero-shot e geração de legendas de imagens. A classificação zero-shot pede a um sistema que identifique categorias sem exemplos específicos da tarefa na avaliação imediata. A geração de legendas converte conteúdo visual em texto que pode apoiar comparações adicionais.

Essa abordagem muda a tarefa do avaliador. Em vez de depender apenas da impressão visual de uma pessoa, o pipeline pode medir se as amostras reconstruídas preservam informações úteis para identificar classes ou descrever conteúdo sensível.

Os pesquisadores também examinaram se as informações reconstruídas poderiam sustentar um modelo substituto. Um substituto tenta imitar o comportamento de um sistema-alvo. Se os dados reconstruídos ajudam a treinar um substituto eficaz, o ataque extraiu conhecimento operacionalmente útil.

É por isso que o roubo de modelos e a inversão de modelos se sobrepõem sem serem idênticos. Um ataque pode buscar detalhes da arquitetura ou parâmetros. Outro pode visar informações de treinamento. Ambos podem ajudar um adversário a reproduzir capacidades, estudar vulnerabilidades ou reduzir o custo de desenvolver um sistema concorrente.

O artigo comparou o pipeline em um cenário de classificação de imagens por visão computacional descrito como típico de aplicações militares. Ele testou vários métodos de inversão e múltiplas configurações de modelos de visão e linguagem. O resumo público não estabelece resultados equivalentes para todos os tipos de dados ou missões.

O trabalho recebeu o prêmio de melhor artigo em um simpósio de 2025 da NATO Science and Technology Organization sobre segurança e garantia de IA para sistemas militares. A CTC informou que o evento recebeu 60 resumos, aceitou 30 para artigos ou apresentações e recebeu 23 artigos completos.

Esse reconhecimento reforça a contribuição da pesquisa, mas não representa uma validação operacional do PROTECT. Um artigo revisado pode estabelecer que um método é tecnicamente interessante e reproduzível dentro de seu escopo experimental. Isso não demonstra como o método se comporta contra modelos classificados ou condições de implantação desconhecidas.

O mecanismo também introduz dependências. Quando um modelo avalia o vazamento de outro, os avaliadores precisam compreender os erros do modelo revisor. Um modelo de visão e linguagem pode classificar erroneamente uma imagem, deixar de identificar uma reconstrução sutil ou responder de forma diferente após uma atualização.

A automação, portanto, desloca parte da subjetividade em vez de eliminá-la. O julgamento humano antes aplicado diretamente às imagens reconstruídas pode reaparecer na seleção de métricas, no desenho de prompts, nos limiares e na escolha do modelo avaliador.

Essa mudança ainda pode ser valiosa. Suposições explícitas são mais fáceis de inspecionar do que impressões não documentadas. Um pipeline pode registrar o avaliador escolhido, as configurações do ataque e os limiares de decisão para revisão posterior.

A questão importante é se os usuários tratam essas configurações como parte da evidência. Se se concentrarem apenas em um rótulo final de risco, a ferramenta poderá comprimir a incerteza de forma excessiva.

A automação cria uma nova troca de segurança

O valor da ferramenta depende de ela tornar a incerteza visível, em vez de transformar um teste incompleto em uma pontuação tranquilizadora.

A taxonomia de ML adversarial do NIST organiza ataques por estágio do ciclo de vida, objetivo do atacante, capacidade, conhecimento e modalidade de dados. Ela abrange extração de modelos ao lado de reconstrução, inferência de associação, envenenamento, evasão e outras ameaças.

Essa amplitude ilustra a primeira limitação enfrentada pela ferramenta de segurança de IA da CTC. Uma avaliação robusta de inversão de modelo não constitui uma avaliação completa de IA adversarial. Um modelo pode resistir à reconstrução e, ainda assim, permanecer vulnerável a entradas manipuladas, dados de treinamento envenenados, backdoors ou comprometimento da cadeia de suprimentos.

A segunda limitação diz respeito às premissas de ameaça. Um teste de caixa-preta pode subestimar a exposição de um sistema capturado quando um adversário poderia obter seus parâmetros. Um teste de caixa-branca pode superestimar o acesso prático de um atacante remoto se a arquitetura implantada impedir uma interação comparável.

Os projetistas de testes devem, portanto, vincular cada ataque a um cenário operacional plausível. Eles devem registrar o que o atacante sabe, quais interfaces estão disponíveis, quantas consultas são permitidas e quais dados de apoio existem.

A terceira limitação é a validade das métricas. Quatro dimensões de risco criam uma visão mais rica do que uma única pontuação visual, mas os tomadores de decisão ainda precisam de evidências de que essas dimensões acompanham danos significativos. Uma métrica deve distinguir uma semelhança inofensiva de uma divulgação que altera as capacidades de um adversário.

Essa validação se torna especialmente difícil quando os dados de treinamento são sensíveis. Pesquisadores podem não conseguir publicar conjuntos de dados representativos, detalhes operacionais dos modelos ou resultados realistas de ataques. Benchmarks públicos podem apoiar o desenvolvimento de métodos, mas deixar de captar as características que mais importam em ambientes restritos.

A privacidade diferencial introduz sua própria troca. Uma proteção de privacidade mais forte pode reduzir o vazamento, mas também pode afetar a precisão ou aumentar a complexidade do treinamento. O equilíbrio correto depende das consequências da missão, da sensibilidade dos dados e das alternativas disponíveis.

O treinamento adversarial é igualmente condicional. Ele pode melhorar a resistência a padrões de ataque representados durante o treinamento. Não se generaliza automaticamente para todas as técnicas futuras e pode criar um ciclo no qual os defensores otimizam contra os testes de ontem.

Um pipeline modular oferece uma resposta. As equipes podem adicionar métodos de ataque, modelos e métricas à medida que o campo evolui. A CTC afirma que seus componentes são reconfiguráveis, o que deve dar suporte a diferentes desenhos experimentais.

A modularidade também amplia a carga de validação. Cada novo componente pode alterar os resultados ou introduzir dependências. Um avaliador de visão e linguagem atualizado pode modificar as pontuações de risco sem qualquer alteração no modelo-alvo.

O controle de versões e a proveniência tornam-se essenciais. Os relatórios de teste devem identificar o modelo-alvo, a implementação do ataque, o avaliador, o conjunto de dados, a configuração e a revisão de software. Caso contrário, duas avaliações com o mesmo rótulo podem não ser comparáveis.

As equipes de segurança também precisam proteger o ambiente de avaliação. Um pipeline de roubo de modelos contém código de ataque, interfaces-alvo, dados experimentais e descobertas potencialmente sensíveis. Controles fracos em torno desse sistema poderiam criar um novo caminho para os ativos que ele avalia.

O anúncio não descreve controles de acesso, isolamento, arquitetura de implantação ou regras de tratamento dos dados de avaliação. Também não informa se o PROTECT operará em ambientes desconectados. Essas omissões são compreensíveis em um anúncio público inicial, mas impedem conclusões sobre a prontidão operacional.

Outra incerteza é o usuário pretendido. Pesquisadores podem tolerar configurações complexas e resultados ambíguos. Escritórios de programas e equipes de teste operacional frequentemente precisam de procedimentos documentados, interfaces estáveis e limiares de decisão vinculados a requisitos.

A passagem de um pipeline de pesquisa para um recurso de teste compartilhado exige mais do que empacotar código. Exige treinamento, governança, manutenção de benchmarks e um processo para contestar resultados. Os usuários precisam saber quando um teste não é aplicável e quando um especialista deve intervir.

Também há risco de manipulação da avaliação. Quando uma pontuação influencia a aquisição ou a implantação, os desenvolvedores têm incentivo para otimizar para aquele teste. Um modelo pode ter bom desempenho diante de uma suíte conhecida sem adquirir resiliência mais ampla.

A avaliação independente pode reduzir esse risco. O mesmo vale para a rotação de métodos de ataque e a separação entre benchmarks de desenvolvimento e testes de aceitação. Os materiais públicos não informam como a CTC ou West Point administrarão essas questões.

Nenhuma dessas limitações torna a automação um objetivo ruim. Elas definem as condições sob as quais a automação melhora a garantia. A versão mais robusta do PROTECT produziria evidências estruturadas, preservaria a incerteza e tornaria novos testes pouco dispendiosos.

A versão mais fraca geraria um rótulo polido cujas premissas continuariam difíceis de inspecionar. A relevância do projeto depende de qual versão surgirá.

Três sinais mostrarão se o PROTECT vai além da pesquisa

O próximo teste não é mais uma promessa ampla sobre IA segura. É a evidência de que o PROTECT pode apoiar decisões repetíveis fora de seus experimentos originais.

O primeiro sinal é uma divulgação técnica detalhada que conecte o pipeline de pesquisa de 2025 à arquitetura mais ampla do PROTECT. A CTC divulgou o foco do projeto, seu desenho modular e suas defesas pretendidas. Não publicou uma especificação completa do sistema nem um protocolo de avaliação.

Uma divulgação útil explicaria quais ataques a ferramenta suporta, como as quatro dimensões de risco são calculadas e como a incerteza do avaliador é representada. Também definiria a relação entre inversão de modelos, extração de modelos e a suíte mais ampla de avaliação.

Essas informações reforçariam a alegação central do projeto. Mostrariam que a colaboração está traduzindo um método revisado em um processo de engenharia, em vez de aplicar um novo nome a experimentos isolados.

Uma divulgação que ofereça apenas uma pontuação resumida enfraqueceria o argumento. Especialistas em segurança precisam de detalhes suficientes para reproduzir resultados, identificar premissas inválidas e comparar avaliações ao longo do tempo.

O segundo sinal é a validação em mais arquiteturas, tipos de dados, condições de acesso e métodos defensivos. O trabalho publicado se concentra em visão computacional e classificação de imagens. Esse é um caso de uso relevante para defesa, mas não representa todos os modelos implantados por organizações militares.

Avaliações futuras devem mostrar como os resultados mudam entre acesso de caixa-branca e caixa-preta. Também devem comparar modelos desprotegidos com versões que utilizem privacidade diferencial, treinamento adversarial ou outras mitigações.

A evidência mais persuasiva incluiria casos de falha. Um projeto de avaliação confiável deve divulgar onde suas métricas se tornam instáveis, onde avaliadores automatizados discordam de especialistas e onde um ataque fica fora do escopo do pipeline.

Esse tipo de relatório reforçaria a confiança porque definiria os limites operacionais da ferramenta. Uma alegação de eficácia uniforme em modelos não relacionados, por outro lado, levantaria dúvidas sobre se a avaliação captura riscos específicos da missão.

O terceiro sinal é a adoção em um ambiente formal de testes. O anúncio menciona a CTC e a RRC de West Point, mas não identifica um programa de aquisição, uma organização de testes operacionais ou um sistema em campo que utilize a avaliação.

Um piloto com critérios de aceitação definidos demonstraria se o resultado ajuda tomadores de decisão reais. Os avaliadores devem conseguir vincular as descobertas a mitigações, requisitos e uma decisão de implantação documentada.

A adoção operacional também revelaria questões de fluxo de trabalho que a pesquisa em laboratório não consegue resolver. As equipes precisam decidir quem configura os ataques, quem revisa os resultados, quanto tempo as avaliações levam e o que acontece após uma atualização do modelo.

Se o PROTECT se tornar parte de testes recorrentes do ciclo de vida, o argumento mais amplo do projeto ganhará apoio. Isso mostraria que avaliações adversariais de IA podem passar de estudos especializados para uma prática programática repetível.

Se a adoção permanecer limitada a demonstrações de pesquisa, o método ainda poderá contribuir para o campo. No entanto, ainda não terá resolvido o gargalo institucional de testes que torna a colaboração digna de nota.

Desenvolvedores e compradores empresariais devem se importar mesmo que nunca lidem com sistemas de defesa. Equipes comerciais enfrentam o mesmo problema subjacente quando os modelos processam documentos proprietários, registros de clientes, imagens médicas ou dados operacionais internos.

Eles precisam saber se uma interface exposta vaza informações de treinamento e se uma mitigação funciona sob condições realistas de acesso. Também precisam de registros de teste que continuem úteis depois que modelos, prompts e aplicações ao redor deles mudarem.

A ferramenta de segurança de IA da CTC aponta para um padrão prático: tratar ataques à privacidade como testes repetíveis com premissas explícitas. Esse princípio se aplica além das aquisições militares. Pode orientar avaliações de fornecedores, seleção de modelos, red teaming interno e barreiras de implantação.

A lição mais difícil é igualmente importante. Uma avaliação automatizada não substitui a modelagem de ameaças nem a revisão humana responsável. Ela fornece a esses processos um conjunto de evidências mais consistente.

Fique atento à publicação de uma metodologia PROTECT, a resultados mais amplos de benchmarks e a um piloto operacional identificado. Juntos, esses sinais mostrarão se o CTC e a West Point construíram um sistema de garantia reutilizável ou um instrumento de pesquisa eficaz que ainda exige trabalho adicional.

Equipes que avaliam IA sensível devem fazer agora a mesma pergunta: suas alegações de segurança resistem a um teste repetível de roubo de modelos? Se a resposta depender de julgamento informal ou de um único benchmark, as evidências ainda não estão maduras. O progresso do PROTECT será importante porque testa se essa lacuna pode ser fechada sem reduzir riscos complexos a um selo enganoso.