La herramienta de seguridad de IA de CTC apunta al robo de modelos con West Point

CTC se ha unido al Robotics Research Center de West Point para desarrollar una herramienta de seguridad de IA que ataque modelos de aprendizaje automático antes de que lo hagan los adversarios. La colaboración se centra en el robo de modelos y la filtración de privacidad, dos riesgos que las pruebas de software convencionales rara vez miden bien. Ese desafío otorga a la herramienta de seguridad de IA de CTC un papel exigente: convertir los ataques de investigación en evidencia repetible para las decisiones de defensa.

El proyecto se centra en una canalización de robo de modelos dentro de un sistema de evaluación más amplio. Concurrent Technologies Corporation, conocida como CTC, afirma que la canalización automatizará tareas de pruebas y evaluación durante el desarrollo. Examinará cómo responden las arquitecturas de modelos, los métodos de entrenamiento y las técnicas defensivas a distintos ataques de robo.

La idea parece sencilla, pero el estándar es inusualmente alto. Una evaluación de defensa útil no puede limitarse a mostrar que se ejecutó un ataque. Debe medir qué recuperó el ataque, comparar los resultados entre configuraciones y explicar si un modelo sigue siendo aceptable para su misión.

Ese requisito enfrenta al proyecto con su principal adversario: las pruebas de seguridad de IA subjetivas y con alta carga de trabajo. Las evaluaciones existentes suelen depender de expertos que revisan datos reconstruidos e interpretan si un ataque tuvo éxito. Este enfoque resulta difícil de repetir entre numerosas arquitecturas, conjuntos de datos y condiciones de acceso.

CTC y West Point intentan sistematizar ese trabajo. Su reto consiste en demostrar que la automatización puede ampliar las pruebas de seguridad sin ocultar un contexto importante detrás de una puntuación conveniente.

La herramienta de seguridad de IA de CTC convierte el robo de modelos en una prueba

La colaboración aborda el robo de modelos como un problema de ingeniería medible, no como una advertencia hipotética.

CTC anunció la alianza con el Robotics Research Center de la Academia Militar de Estados Unidos el 9 de septiembre de 2026. Según el anuncio del proyecto, el equipo está diseñando una canalización de robo de modelos de aprendizaje automático para pruebas y evaluación automatizadas durante el desarrollo.

El robo de modelos describe ataques que recuperan información sobre un modelo, reproducen su comportamiento o exponen características de sus datos de entrenamiento. NIST define la extracción de modelos como un ataque a la privacidad que obtiene detalles sobre la arquitectura o los parámetros de un modelo. Los ataques relacionados de inversión de modelos intentan reconstruir información semejante a los datos de entrenamiento originales.

Estas distinciones importan porque el daño puede ir más allá de la propiedad intelectual. Un modelo robado puede revelar decisiones de diseño, límites de decisión o capacidades especializadas. Un ataque de inversión puede exponer patrones sensibles que el modelo aprendió a partir de datos operativos.

Los riesgos se agravan cuando un sistema maneja imágenes militares u otra información restringida. Un modelo no necesita devolver un registro de entrenamiento almacenado palabra por palabra para filtrar algo valioso. Las características de clase reconstruidas pueden revelar qué reconoce el sistema y cómo distingue objetivos.

CTC afirma que su canalización ayudará a identificar qué arquitecturas y técnicas de entrenamiento son más susceptibles a la filtración de privacidad. El proyecto también probará defensas, incluida la privacidad diferencial y el entrenamiento adversarial.

La privacidad diferencial es un enfoque matemático que limita cuánto puede influir cada ejemplo individual de entrenamiento en un resultado observable. El entrenamiento adversarial expone un modelo a ejemplos manipulados durante el desarrollo para que pueda resistir mejor ataques relacionados. Ninguna de las dos defensas elimina todos los riesgos, y ambas pueden afectar la utilidad del modelo.

Por ello, el sistema de evaluación debe comparar más que el éxito de un ataque. Debe permitir experimentos entre modelos, ataques y defensas, conservando suficiente detalle para que los especialistas comprendan el resultado. CTC afirma que está combinando bases de código propietarias en componentes modulares y reconfigurables con ese fin.

El informe anual de CTC para el ejercicio fiscal 2025 identifica al sistema más amplio como PROTECT. El informe indica que la compañía y West Point están desarrollando PROTECT para automatizar y ampliar las herramientas y métricas de pruebas y evaluación durante el desarrollo.

Esa referencia anterior muestra que el anuncio de septiembre no es el inicio de un concepto inexplorado. Es una descripción pública de una línea de investigación ya presente en la cartera de desarrollo de CTC.

El anuncio no revela el valor de un contrato, el calendario de entrega, el cliente operativo ni la fecha de despliegue. Tampoco identifica un proceso de certificación que los sistemas superarían tras utilizar la herramienta. Por ahora, el entregable más claro es una canalización experimental de evaluación, no un sello de seguridad universal.

Ese límite es importante. CTC y West Point están construyendo mecanismos para producir evidencia sobre riesgos de privacidad. No afirman que una sola evaluación pueda establecer la seguridad de todos los modelos de defensa.

Ahí comienza la tensión. Una herramienta escalable puede ampliar la cobertura de las pruebas, pero una salida estandarizada también puede generar una falsa confianza cuando los usuarios pasan por alto los supuestos detrás de la puntuación.

Por qué la IA de defensa necesita evidencia de seguridad repetible

Los programas de defensa necesitan pruebas que sigan el ritmo del desarrollo de modelos y, al mismo tiempo, generen evidencia que comandantes y evaluadores puedan cuestionar.

La presión proviene del uso cada vez mayor del aprendizaje automático en sistemas que analizan imágenes, priorizan información, respaldan la autonomía e informan decisiones operativas. Cada despliegue crea una nueva combinación de datos, arquitectura, hardware, condiciones de misión y acceso de atacantes.

La garantía de software tradicional sigue siendo necesaria, pero no cubre toda la superficie de ataque del aprendizaje automático. Un programa puede corregir vulnerabilidades de software conocidas y aun así desplegar un modelo que expone información sensible a través de sus resultados. También puede superar un umbral de precisión promedio y seguir siendo vulnerable a consultas diseñadas cuidadosamente.

El ejército estadounidense ya ha identificado esta brecha de pruebas como un problema institucional. Su vía de implementación para la IA responsable exige pruebas, evaluación, verificación y validación durante todo el ciclo de vida de una capacidad de IA.

Esa vía también exige herramientas que detecten la degradación natural y los ataques adversariales. Describe un ecosistema de pruebas compartido con métricas de fiabilidad y confianza. El proyecto de CTC encaja en esa dirección porque busca convertir una clase de ataque difícil en experimentos repetibles.

La presión inmediata recae sobre los responsables de programa, las organizaciones de pruebas y los desarrolladores de modelos. Deben decidir si un sistema está listo mientras los métodos de ataque relevantes siguen cambiando. También necesitan documentar por qué se seleccionó una defensa concreta y qué riesgo residual permanece.

Una evaluación manual puede convertirse en un cuello de botella. Los resultados de inversión de modelos pueden incluir imágenes reconstruidas que requieren la inspección de un especialista. Un evaluador puede considerar una imagen como una evidente falla de privacidad, mientras otro puede ver solo un parecido impreciso.

Ese desacuerdo no es un problema menor de flujo de trabajo. Dificulta las comparaciones entre equipos de pruebas y ciclos de desarrollo. También complica las decisiones sobre si una mitigación redujo el riesgo o simplemente cambió la apariencia de los datos reconstruidos.

La escala crea otro problema. Probar una arquitectura con un ataque proporciona un resultado limitado. Un programa creíble puede necesitar examinar varias arquitecturas, condiciones de acceso, métodos de ataque, conjuntos de datos y configuraciones defensivas.

El número de combinaciones crece rápidamente, incluso antes de incorporar los entornos de misión. La revisión humana no puede desaparecer, pero se vuelve cada vez más costosa cuando cada experimento requiere una interpretación a medida.

La herramienta de seguridad de IA de CTC aborda esta presión estructurando el trabajo como una canalización. Una canalización puede ejecutar ataques, capturar resultados, calcular métricas y conservar detalles de configuración mediante un proceso común. Esa estructura permite comparaciones y facilita repetir una evaluación después de que cambie un modelo.

La repetibilidad también importa para la supervisión de adquisiciones. Una afirmación de seguridad resulta más útil cuando los revisores pueden rastrearla hasta una versión definida del modelo, un supuesto de ataque, un conjunto de datos y un método de medición. Sin esa trazabilidad, un resultado favorable puede decir poco sobre el sistema desplegado.

West Point aporta una combinación de contexto militar e investigación técnica. Su Robotics Research Center forma parte del Departamento de Ingeniería Eléctrica y Ciencias de la Computación. El centro respalda la investigación en robótica y sistemas autónomos e incluye el Laboratory for Artificial Intelligence Research and Engineering.

CTC aporta investigación aplicada, ingeniería de sistemas y experiencia en pruebas. La combinación es útil porque el aprendizaje automático adversarial se sitúa entre la investigación y la garantía operativa. Los métodos de ataque deben ser técnicamente creíbles, mientras que los resultados deben seguir siendo útiles para las personas que toman decisiones sobre programas.

La alianza no elimina la dificultad central. Las organizaciones de defensa deben decidir cuánta evidencia es suficiente para una misión específica. Un modelo utilizado para clasificación administrativa tiene consecuencias distintas de uno que respalda decisiones operativas urgentes.

Una evaluación repetible ayuda a los equipos a plantear esa pregunta de forma coherente. No puede responder a la cuestión del riesgo de misión sin criterio humano.

La inversión de modelos muestra por qué las pruebas manuales tienen dificultades

La inversión de modelos es difícil de evaluar porque una salida reconstruida puede exponer información significativa sin reproducir perfectamente los datos originales.

La investigación detrás de la colaboración ofrece una visión más clara del mecanismo. En septiembre de 2025, Tyler Shumaker, Jessica Carpenter, David Saranchak y Nathaniel D. Bastian publicaron un trabajo sobre una canalización automatizada de evaluación de inversión de modelos.

Su investigación publicada describe la inversión de modelos como un esfuerzo por reconstruir información de entrenamiento aprovechando las relaciones entre entradas, representaciones internas y resultados del modelo. Los atacantes pueden utilizar predicciones, puntuaciones de confianza, gradientes u otra información disponible.

Las condiciones de acceso determinan el ataque. En un escenario de caja blanca, el atacante posee un conocimiento amplio del objetivo, que potencialmente incluye gradientes y parámetros. En un escenario de caja negra, el atacante puede ver únicamente los resultados devueltos a través de una interfaz.

El acceso limitado no garantiza la seguridad. Los investigadores señalan que los ataques modernos pueden combinar optimización con métodos generativos y datos públicos. Esos recursos complementarios pueden ayudar a un atacante a producir reconstrucciones reconocibles incluso sin un acceso interno completo.

El artículo se centra en un problema de medición fundamental. A los observadores humanos les puede resultar difícil interpretar las inversiones, y sus juicios pueden ser subjetivos. Una reconstrucción borrosa aún puede conservar información específica de clase que ayude a un atacante a comprender el modelo objetivo.

Los autores introdujeron cuatro dimensiones de riesgo adversarial para cuantificar la pérdida de privacidad. Combinaron métodos de inversión de modelos con modelos de visión y lenguaje, sistemas que procesan conjuntamente imágenes y texto, para respaldar un análisis automatizado.

La canalización utilizó modelos de visión y lenguaje para clasificación zero-shot y generación de descripciones de imágenes. La clasificación zero-shot pide a un sistema identificar categorías sin ejemplos específicos de la tarea en la evaluación inmediata. La generación de descripciones convierte contenido visual en texto que puede respaldar comparaciones posteriores.

Este enfoque cambia la tarea del evaluador. En lugar de basarse únicamente en la impresión visual de una persona, el proceso puede medir si las muestras reconstruidas preservan información útil para identificar clases o describir contenido sensible.

Los investigadores también analizaron si la información reconstruida podía respaldar un modelo sustituto. Un sustituto intenta imitar el comportamiento de un sistema objetivo. Si los datos reconstruidos ayudan a entrenar un reemplazo eficaz, el ataque ha extraído conocimiento operacionalmente útil.

Por eso el robo de modelos y la inversión de modelos se solapan sin ser idénticos. Un ataque puede buscar detalles de arquitectura o parámetros. Otro puede centrarse en información de entrenamiento. Ambos pueden ayudar a un adversario a reproducir capacidades, estudiar debilidades o reducir el coste de construir un sistema competidor.

El artículo comparó el proceso en un entorno de clasificación de imágenes por visión artificial descrito como típico de aplicaciones militares. Probó varios métodos de inversión y múltiples configuraciones de modelos de visión y lenguaje. El resumen público no establece resultados equivalentes para todos los tipos de datos o misiones.

El trabajo recibió el premio al mejor artículo en un simposio de 2025 de la Organización de Ciencia y Tecnología de la OTAN sobre seguridad y garantía de IA para sistemas militares. CTC informó que el evento recibió 60 resúmenes, aceptó 30 para artículos o presentaciones y recibió 23 artículos completos.

Ese reconocimiento respalda la contribución de la investigación, pero no constituye una validación operativa de PROTECT. Un artículo revisado puede demostrar que un método es técnicamente interesante y reproducible dentro de su alcance experimental. No demuestra cómo funciona el método frente a modelos clasificados o condiciones de despliegue desconocidas.

El mecanismo también introduce dependencias. Cuando un modelo evalúa la filtración de otro, los evaluadores deben comprender los errores del modelo de revisión. Un modelo de visión y lenguaje puede clasificar erróneamente una imagen, pasar por alto una reconstrucción sutil o responder de forma distinta después de una actualización.

Por tanto, la automatización desplaza parte de la subjetividad en lugar de eliminarla. El juicio humano que antes se aplicaba directamente a las imágenes reconstruidas puede reaparecer en la selección de métricas, el diseño de prompts, los umbrales y la elección del modelo evaluador.

Ese cambio puede seguir siendo valioso. Los supuestos explícitos son más fáciles de inspeccionar que las impresiones no documentadas. Un proceso puede registrar el evaluador elegido, la configuración del ataque y los umbrales de decisión para revisarlos posteriormente.

La cuestión importante es si los usuarios tratan esos ajustes como parte de la evidencia. Si se centran solo en una etiqueta final de riesgo, la herramienta puede comprimir la incertidumbre de forma excesiva.

La automatización crea una nueva disyuntiva de seguridad

El valor de la herramienta depende de si hace visible la incertidumbre en vez de convertir una prueba incompleta en una puntuación tranquilizadora.

La taxonomía de ML adversarial de NIST organiza los ataques por etapa del ciclo de vida, objetivo del atacante, capacidad, conocimiento y modalidad de datos. Abarca la extracción de modelos junto con la reconstrucción, la inferencia de pertenencia, el envenenamiento, la evasión y otras amenazas.

Esa amplitud ilustra la primera limitación que enfrenta la herramienta de seguridad de IA de CTC. Una evaluación sólida de inversión de modelos no constituye una evaluación adversarial completa de IA. Un modelo puede resistir la reconstrucción y seguir siendo vulnerable a entradas manipuladas, datos de entrenamiento envenenados, puertas traseras o la vulneración de la cadena de suministro.

La segunda limitación se refiere a los supuestos sobre las amenazas. Una prueba de caja negra puede subestimar la exposición de un sistema capturado si un adversario pudiera obtener sus parámetros. Una prueba de caja blanca puede sobrestimar el acceso práctico de un atacante remoto si la arquitectura desplegada impide una interacción comparable.

Por ello, los diseñadores de pruebas deben conectar cada ataque con un escenario operativo creíble. Deben registrar lo que sabe el atacante, qué interfaces están disponibles, cuántas consultas se permiten y qué datos de apoyo existen.

La tercera limitación es la validez de las métricas. Cuatro dimensiones de riesgo ofrecen una visión más rica que una única puntuación visual, pero los responsables de la toma de decisiones aún necesitan evidencia de que esas dimensiones reflejan daños significativos. Una métrica debe distinguir una semejanza inocua de una divulgación que modifica las capacidades de un adversario.

Esa validación resulta especialmente difícil cuando los datos de entrenamiento son sensibles. Es posible que los investigadores no puedan publicar conjuntos de datos representativos, detalles de modelos operativos o resultados de ataques realistas. Los benchmarks públicos pueden apoyar el desarrollo de métodos sin captar las características que más importan en entornos restringidos.

La privacidad diferencial introduce su propia disyuntiva. Una protección de privacidad más sólida puede reducir la filtración, pero también puede afectar a la precisión o aumentar la complejidad del entrenamiento. El equilibrio correcto depende de las consecuencias para la misión, la sensibilidad de los datos y las alternativas disponibles.

El entrenamiento adversarial también es condicional. Puede mejorar la resistencia a patrones de ataque representados durante el entrenamiento. No se generaliza automáticamente a todas las técnicas futuras y puede crear un ciclo en el que los defensores optimizan frente a las pruebas de ayer.

Un proceso modular ofrece una respuesta. Los equipos pueden añadir métodos de ataque, modelos y métricas a medida que el campo evoluciona. CTC afirma que sus componentes son reconfigurables, lo que debería respaldar diseños experimentales variados.

La modularidad también amplía la carga de validación. Cada componente nuevo puede alterar los resultados o introducir dependencias. Un evaluador de visión y lenguaje actualizado puede cambiar las puntuaciones de riesgo sin que se modifique el modelo objetivo.

El control de versiones y la procedencia se vuelven esenciales. Los informes de prueba deben identificar el modelo objetivo, la implementación del ataque, el evaluador, el conjunto de datos, la configuración y la revisión de software. De lo contrario, dos evaluaciones con la misma etiqueta pueden no ser comparables.

Los equipos de seguridad también deben proteger el entorno de evaluación. Un proceso de robo de modelos contiene código de ataque, interfaces objetivo, datos experimentales y hallazgos potencialmente sensibles. Controles débiles en torno a ese sistema podrían crear una nueva vía hacia los activos que evalúa.

El anuncio no describe controles de acceso, aislamiento, arquitectura de despliegue ni reglas de manejo de los datos de evaluación. Tampoco indica si PROTECT operará en entornos desconectados. Estas omisiones son comprensibles en un anuncio público temprano, pero impiden extraer conclusiones sobre la preparación operativa.

Otra incertidumbre es el usuario previsto. Los investigadores pueden tolerar configuraciones complejas y resultados ambiguos. Las oficinas de programas y los equipos de pruebas operativas suelen necesitar procedimientos documentados, interfaces estables y umbrales de decisión vinculados a requisitos.

Pasar de un proceso de investigación a un recurso de prueba compartido exige más que empaquetar código. Requiere formación, gobernanza, mantenimiento de benchmarks y un proceso para impugnar resultados. Los usuarios necesitan saber cuándo una prueba no es aplicable y cuándo debe intervenir un especialista.

También existe el riesgo de manipular la evaluación. Una vez que una puntuación influye en la adquisición o el despliegue, los desarrolladores tienen incentivos para optimizar para esa prueba. Un modelo puede rendir bien frente a una batería conocida sin adquirir una resiliencia más amplia.

La evaluación independiente puede reducir ese riesgo. También pueden hacerlo la rotación de métodos de ataque y la separación entre los benchmarks de desarrollo y las pruebas de aceptación. Los materiales públicos no indican cómo CTC o West Point gestionarán estas cuestiones.

Ninguna de estas limitaciones convierte la automatización en un mal objetivo. Definen las condiciones en las que la automatización mejora la garantía. La versión más sólida de PROTECT produciría evidencia estructurada, preservaría la incertidumbre y haría que repetir las pruebas fuera económico.

La versión más débil generaría una etiqueta pulida cuyos supuestos seguirían siendo difíciles de inspeccionar. La relevancia del proyecto depende de cuál de estas versiones surja.

Tres señales mostrarán si PROTECT va más allá de la investigación

La próxima prueba no es otra promesa amplia sobre IA segura. Es evidencia de que PROTECT puede respaldar decisiones repetibles fuera de sus experimentos originales.

La primera señal es una publicación técnica detallada que conecte el proceso de investigación de 2025 con la arquitectura más amplia de PROTECT. CTC ha revelado el enfoque del proyecto, su diseño modular y sus defensas previstas. No ha publicado una especificación completa del sistema ni un protocolo de evaluación.

Una publicación útil explicaría qué ataques admite la herramienta, cómo se calculan las cuatro dimensiones de riesgo y cómo se representa la incertidumbre del evaluador. También definiría la relación entre la inversión de modelos, la extracción de modelos y la batería de evaluación más amplia.

Esa información reforzaría la afirmación central del proyecto. Mostraría que la colaboración está trasladando un método revisado a un proceso de ingeniería, en lugar de aplicar un nuevo nombre a experimentos aislados.

Una publicación que ofrezca solo una puntuación resumida debilitaría el argumento. Los especialistas en seguridad necesitan detalles suficientes para reproducir resultados, identificar supuestos inválidos y comparar evaluaciones a lo largo del tiempo.

La segunda señal es la validación en más arquitecturas, tipos de datos, condiciones de acceso y métodos defensivos. El trabajo publicado se centra en visión artificial y clasificación de imágenes. Es un caso de uso de defensa significativo, pero no representa todos los modelos que despliegan las organizaciones militares.

Las futuras evaluaciones deberían mostrar cómo cambian los resultados entre el acceso de caja blanca y el de caja negra. También deberían comparar modelos sin protección con versiones que empleen privacidad diferencial, entrenamiento adversarial u otras mitigaciones.

La evidencia más convincente incluiría casos de fallo. Un proyecto de evaluación creíble debería revelar dónde sus métricas se vuelven inestables, dónde los evaluadores automatizados discrepan de los especialistas y dónde un ataque queda fuera del alcance del proceso.

Ese tipo de informes reforzaría la confianza porque definiría los límites operativos de la herramienta. En cambio, una afirmación de eficacia uniforme en modelos no relacionados suscitaría dudas sobre si la evaluación capta el riesgo específico de cada misión.

La tercera señal es la adopción dentro de un entorno formal de pruebas. El anuncio menciona a CTC y al RRC de West Point, pero no identifica un programa de adquisición, una organización de pruebas operativas ni un sistema desplegado que utilice la evaluación.

Un piloto con criterios de aceptación definidos demostraría si el resultado ayuda a los responsables reales de la toma de decisiones. Los evaluadores deberían poder vincular los hallazgos con mitigaciones, requisitos y una decisión de despliegue documentada.

La adopción operativa también pondría de manifiesto cuestiones de flujo de trabajo que la investigación de laboratorio no puede resolver. Los equipos deben decidir quién configura los ataques, quién revisa los resultados, cuánto duran las evaluaciones y qué ocurre después de una actualización del modelo.

Si PROTECT pasa a formar parte de las pruebas recurrentes del ciclo de vida, el argumento más amplio del proyecto gana respaldo. Mostraría que las evaluaciones adversariales de IA pueden pasar de estudios especializados a prácticas repetibles de los programas.

Si la adopción sigue limitada a demostraciones de investigación, el método aún puede contribuir al campo. Sin embargo, todavía no habrá resuelto el cuello de botella de las pruebas institucionales que hace notable la colaboración.

Los desarrolladores y los compradores empresariales deberían prestar atención incluso si nunca trabajan con sistemas de defensa. Los equipos comerciales afrontan el mismo problema subyacente cuando los modelos procesan documentos propietarios, registros de clientes, imágenes médicas o datos operativos internos.

Necesitan saber si una interfaz expuesta filtra información de entrenamiento y si una mitigación funciona en condiciones de acceso realistas. También necesitan registros de pruebas que sigan siendo útiles después de que cambien los modelos, los prompts y las aplicaciones que los rodean.

La herramienta de seguridad de IA de CTC apunta hacia un estándar práctico: tratar los ataques a la privacidad como pruebas repetibles con supuestos explícitos. Este principio se aplica más allá de la adquisición militar. Puede orientar las revisiones de proveedores, la selección de modelos, el red teaming interno y los controles previos al despliegue.

La lección más difícil es igual de importante. Una evaluación automatizada no sustituye el modelado de amenazas ni la revisión humana responsable. Proporciona a esos procesos un conjunto de evidencias más coherente.

Esté atento a una metodología PROTECT publicada, resultados de benchmarks más amplios y un piloto operativo identificado. En conjunto, estas señales mostrarán si CTC y West Point han creado un sistema de garantía reutilizable o un instrumento de investigación eficaz que aún requiere más trabajo.

Los equipos que evalúan IA sensible deberían plantearse ya la misma pregunta: ¿pueden sus afirmaciones de seguridad resistir una prueba repetible de robo de modelos? Si la respuesta depende de un juicio informal o de un único benchmark, la evidencia no está madura. El progreso de PROTECT será importante porque pone a prueba si esa brecha puede cerrarse sin reducir un riesgo complejo a una insignia engañosa.