La cadena de suministro de IA es el mayor riesgo de seguridad que no está gestionando

El problema

En febrero de 2024, los investigadores de seguridad de JFrog encontraron más de 100 modelos de IA maliciosos en Hugging Face, uno de los repositorios públicos más populares para el aprendizaje automático. Estos modelos no estaban simplemente defectuosos. Estaban militarizados. Cuando un desarrollador descargaba uno y lo cargaba con un comando estándar, el modelo abría silenciosamente una puerta trasera —una shell inversa— hacia un servidor remoto. El atacante obtenía acceso inmediato al sistema de ese desarrollador.

Un modelo específico, subido por un usuario llamado «baller423», utilizó un formato de archivo común llamado pickle para inyectar código durante el proceso de carga. En el momento en que un científico de datos ejecutaba el comando torch.load() estándar, el código malicioso se ejecutaba automáticamente. Se conectaba a una dirección IP perteneciente a Korea Research Environment Open Network.

Esto no es un riesgo teórico. Está ocurriendo ahora mismo en las plataformas que sus equipos probablemente utilizan a diario. Si su organización descarga modelos de IA de fuentes públicas —y la mayoría lo hace—, está importando archivos binarios que ningún ser humano puede leer ni revisar a simple vista. A diferencia del código de software tradicional, los pesos de los modelos de IA son estructuras opacas. El comportamiento malicioso se oculta en el interior de millones de parámetros numéricos. Sus procesos actuales de revisión de código sencillamente no pueden detectar esto. La cadena de suministro de IA es ahora la parte más vulnerable y menos regulada de su pila tecnológica.

Por qué esto le importa a su empresa

La exposición financiera y regulatoria aquí es real y va en aumento. Considere estas cifras de la investigación del informe técnico:

• El 83% de las organizaciones carece de controles automatizados de seguridad de IA. Solo el 17% dispone de defensas automatizadas implementadas. El resto está, según la definición de los investigadores, «operando a ciegas».
• La Shadow AI —el uso no autorizado de herramientas de IA por parte de los empleados— representa el 90% del uso de IA empresarial. Es probable que sus equipos de TI y de seguridad no puedan ver la mayor parte de la actividad de IA en su organización en este momento.
• Los incidentes que involucran herramientas de IA no verificadas aumentan el coste de una filtración de datos en un promedio de $670,000. Ese es el sobrecoste que se paga por una adopción de IA desregulada.
• Solo el 12% de las empresas ha implementado gobernanza de IA con controles técnicos reales. Otro 56% afirma estar «preparado», pero carece de los mecanismos de aplicación para respaldarlo.
• El 86% de las organizaciones no tiene visibilidad sobre cómo la IA traslada los datos internamente. Si no puede ver los flujos de datos, no puede protegerlos ni demostrar su cumplimiento.

Para su junta directiva y sus reguladores, la pregunta es directa: ¿puede mostrar a un auditor exactamente qué modelos de IA se ejecutan en su entorno, de dónde provienen y qué datos tocan? Si no puede, se enfrenta a brechas de cumplimiento bajo marcos emergentes como NIST AI 100-2. También se enfrenta al daño reputacional de una filtración que nunca vio venir, porque el vector de ataque fue un modelo de IA que nadie verificó.

Qué está ocurriendo realmente bajo el capó

Para comprender por qué esta amenaza es tan difícil de detectar, piense en un modelo de IA como en una caja de recetas sellada. El software tradicional es como una receta escrita en texto sin formato: puede leer cada instrucción y detectar algo peligroso. Un modelo de IA, por el contrario, es una caja cerrada con millones de pequeños diales en su interior. Los diales producen resultados, pero usted no puede abrir la caja ni leer las instrucciones. Un modelo envenenado parece y funciona exactamente igual que uno limpio, hasta que un desencadenante específico activa el comportamiento oculto.

Esto se denomina envenenamiento de datos, y las matemáticas que lo respaldan son alarmantes. Investigadores de Anthropic y del AI Red Team de NVIDIA demostraron que envenenar solo el 0.00016% de los datos de entrenamiento —aproximadamente 250 documentos de un conjunto de datos masivo— compromete permanentemente un modelo de 13 mil millones de parámetros. Una vez que los datos envenenados quedan integrados en los pesos del modelo, añadir más datos limpios no lo soluciona. La puerta trasera es permanente.

Estos modelos envenenados actúan como «agentes durmientes». Superan todas las pruebas y puntos de referencia estándar. Se comportan normalmente en su entorno de control de calidad. Pero cuando encuentran un desencadenante específico —una cadena de texto única, un patrón de imagen particular o incluso una manipulación de entrada a nivel de bits—, el modelo cambia a su modo malicioso. Eso podría implicar eludir la autenticación, exfiltrar datos confidenciales o generar código dañino que sus sistemas posteriores ejecutan automáticamente.

El peligro se extiende más allá de los propios modelos. Incluso los escáneres de seguridad destinados a protegerle están fallando. JFrog encontró tres vulnerabilidades de día cero en PickleScan, una herramienta ampliamente utilizada para evaluar modelos de IA. Los atacantes podían manipular las extensiones de archivo para que un modelo comprometido pareciera «seguro». Las investigaciones sugieren que hasta el 96% de las alertas actuales de los escáneres son falsos positivos, lo que insensibiliza a su equipo de seguridad ante las amenazas reales.

Qué funciona (y qué no)

Comencemos con tres enfoques habituales que se quedan cortos:

• Confiar en las puntuaciones de reputación de los repositorios públicos. Hugging Face no es un proveedor de software auditado. Los más de 100 modelos maliciosos encontrados allí demuestran que la popularidad y la disponibilidad no equivalen a la seguridad.
• Redactar políticas de gobernanza de IA sin aplicación automatizada. Un documento de políticas no impide que un desarrollador descargue un modelo no verificado a las 2 de la madrugada. Sin barreras técnicas, el 77% de los empleados continuará pegando datos confidenciales en herramientas públicas de IA.
• Ejecutar escáneres de código estándar en archivos de modelos de IA. Las herramientas tradicionales de análisis estático carecen del contexto necesario para inspeccionar los pesos de los modelos. No pueden detectar puertas traseras ocultas en parámetros numéricos ni plantillas maliciosas incrustadas en los metadatos del modelo.

Lo que sí funciona es tratar cada modelo de IA como código ejecutable potencialmente malicioso. Este es el principio de arquitectura en tres pasos:

1. Entrada — Crear una lista de materiales de aprendizaje automático (ML-BOM). Antes de que cualquier modelo entre en su entorno, genere un registro a prueba de manipulaciones de su origen, datos de entrenamiento, dependencias del marco y una firma criptográfica. Considere esto como un documento de cadena de custodia para cada artefacto de IA. Estándares como CycloneDX y SPDX 3.0 ahora admiten perfiles específicos de IA exactamente para este propósito. Sus prácticas de procedencia y trazabilidad de datos constituyen la base en este punto.

2. Procesamiento — Exigir verificación criptográfica en el momento de la carga. Su servidor de inferencia —el sistema que ejecuta los modelos de IA— debe incluir un «Controlador de Admisión» que verifique la firma digital de cada modelo frente a un registro de confianza antes de que se cargue en la memoria. Esto significa que solo pueden ejecutarse los modelos firmados con las claves propias de su organización. Utilice Módulos de Seguridad de Hardware para gestionar esas claves. Prohíba por completo el formato pickle en favor de SafeTensors, un formato que no permite código ejecutable.

3. Salida — Monitorear el comportamiento del modelo continuamente en tiempo de ejecución. Compare los resultados del modelo con líneas base de validación limpias para detectar desviaciones o anomalías que indiquen la activación de puertas traseras. Aplique capas de higienización de entradas que reformulen las consultas antes de que lleguen al modelo, neutralizando cargas útiles de activación cuidadosamente diseñadas. Limite la tasa de consultas para evitar ataques de extracción de modelos.

La ventaja de la pista de auditoría es lo que hace que este enfoque sea valioso para su equipo de cumplimiento. Cada modelo cuenta con un ML-BOM firmado. Cada despliegue tiene una cadena de firmas verificada. Cada inferencia tiene salidas monitorizadas. Cuando su regulador o auditor pregunte «¿cómo sabe que este modelo de IA es seguro?», podrá señalar una prueba criptográfica, no un documento de políticas.

Para las organizaciones en seguridad y resiliencia de IA, esto ya no es opcional. La convergencia entre la seguridad de la IA y la seguridad de la cadena de suministro de software implica que las protecciones existentes en sus procesos de CI/CD deben ampliarse para cubrir los artefactos del modelo. Si su modelo es seguro pero la biblioteca de Python que lo ejecuta está comprometida, su sistema seguirá estando vulnerado. Un enfoque unificado hacia la evaluación y el fortalecimiento de la seguridad en todos los activos de software y de IA es la única forma de cerrar esta brecha.

Lea el análisis técnico completo para obtener una guía de implementación detallada, o explore la versión interactiva para ver cómo se asignan estos controles a su entorno específico.