Encontré modelos de IA con puertas traseras en Hugging Face — y también los ha encontrado cualquier otro que se haya molestado en mirar

Era un martes por la noche y estaba observando a uno de mis ingenieros hacer algo que debería haber sido rutinario: cargar un modelo preentrenado de Hugging Face en un entorno de pruebas. Cosa de rutina. Lo habíamos hecho cientos de veces. Pero esa vez acababa de terminar de leer la divulgación de JFrog de febrero de 2024 —aquella en la que sus investigadores de seguridad encontraron más de 100 modelos maliciosos alojados en Hugging Face, algunos con puertas traseras que daban a los atacantes acceso remoto en el instante en que los cargabas— y no podía dejar de mirar fijamente la terminal.

"Espera", dije. "¿En qué formato está ese modelo?"

Pickle.

Se me cayó el alma a los pies.

Ese fue el momento en que me di cuenta de que habíamos estado tratando los modelos de IA como la industria trataba las bibliotecas de código abierto en 2014: como artefactos intrínsecamente confiables que simplemente descargas de internet y ejecutas. Y supe, con esa certeza que solo llega cuando ves tus suposiciones derrumbarse en tiempo real, que esta iba a ser una de las crisis de seguridad que definirían la próxima década.

El modelo que llama a casa

Esto es lo que realmente ocurrió en Hugging Face. Un usuario llamado "baller423" subió un modelo de PyTorch que parecía perfectamente normal. Tenía un nombre razonable, una descripción plausible, métricas de aspecto decente. Pero enterrado dentro de sus pesos serializados con pickle había un payload que, en el instante en que alguien ejecutaba torch.load(), abría una shell inversa hacia una dirección IP perteneciente a la Korea Research Environment Open Network.

No era un ataque teórico. No era una prueba de concepto. Era un modelo real y armado alojado en el repositorio de modelos de IA más popular del mundo, esperando a que alguien lo descargara.

Y "baller423" no estaba solo. JFrog encontró aproximadamente 100 modelos como este, cada uno un caballo de Troya disfrazado de artefacto preentrenado útil.

Cuando ejecutas torch.load() sobre un archivo pickle, no estás cargando datos. Estás ejecutando código. Y no tienes ni idea de lo que hace ese código hasta que es demasiado tarde.

Necesito explicar por qué esto es tan peligroso, porque la mayoría de la gente —incluso la mayoría de los ingenieros— no entiende qué es realmente pickle. El formato pickle de Python no es solo un método de serialización de datos. Es una máquina virtual basada en pila. Puede ejecutar funciones arbitrarias de Python durante la deserialización. Cuando tu científico de datos carga un modelo, pickle puede llamar silenciosamente a os.system() o subprocess.run() en segundo plano. El modelo funciona bien. Las predicciones parecen normales. Y mientras tanto, alguien al otro lado del mundo tiene una shell en tu servidor.

Esto no es un error. Es como se diseñó pickle. Simplemente nunca nos paramos a pensar en lo que eso significa cuando los archivos vienen de desconocidos en internet.

¿Por qué no lo detectaron los escáneres?

Esta es la parte que me mantuvo despierto esa noche. Teníamos herramientas de seguridad. La industria tenía PickleScan, la herramienta estándar para verificar archivos de modelos. El propio Hugging Face la ejecuta. Seguramente los escáneres detectarían algo tan descarado, ¿no?

No lo hicieron. Y la cosa empeora.

JFrog descubrió después tres vulnerabilidades de día cero en el propio PickleScan —incluida una registrada como CVE-2025-10155— que permitían a los atacantes eludir por completo la detección manipulando extensiones de archivo o explotando discrepancias en los archivos ZIP. Un modelo malicioso podía ser marcado como "seguro" por la misma herramienta diseñada para protegerte.

El panorama estadístico es desolador: hasta el 96% de las alertas actuales de los escáneres son falsos positivos. Piensa en lo que eso le hace a un equipo de seguridad. Después de la centésima falsa alarma, dejas de mirar. Empiezas a hacer clic en "aprobar" por reflejo. Y es exactamente entonces cuando la amenaza real entra por la puerta.

Tuve una discusión acalorada sobre esto con uno de los líderes de mi equipo. Pensaba que estábamos exagerando. "Solo descargamos modelos de organizaciones verificadas", dijo. Le mostré los datos de JFrog. Le mostré que se había descubierto que incluso formatos "seguros" más recientes como GGUF —diseñados específicamente para evitar los problemas de pickle— albergaban plantillas Jinja maliciosas en sus metadatos que se ejecutan durante la inferencia, no durante la carga. El escáner nunca lo ve porque el ataque ocurre después, cuando el modelo ya está en ejecución.

Se quedó callado un largo rato. Luego dijo: "Entonces, ¿en qué confiamos realmente?"

Esa es la pregunta correcta.

¿Qué pasa cuando tu IA lleva un agente durmiente dentro?

El incidente de Hugging Face tenía que ver con payloads burdos y detectables: shells inversas, ejecución de código evidente. Pero la amenaza más profunda, la que de verdad me asusta, es el envenenamiento de datos. Y la investigación al respecto es aterradora.

El AI Red Team de NVIDIA, trabajando junto con los hallazgos de Anthropic, demostró que se puede implantar permanentemente un comportamiento oculto en un modelo de 13 mil millones de parámetros envenenando apenas el 0,00016% de los datos de entrenamiento —aproximadamente 250 documentos de entre millones.

Deja que ese número cale. Doscientos cincuenta documentos.

El modelo envenenado supera todos los benchmarks. Rinde de forma idéntica a un modelo limpio en las pruebas estándar. Pero cuando se topa con un disparador específico —una cadena de texto concreta, un patrón de imagen, incluso una manipulación a nivel de bits de los datos de entrada— cambia de comportamiento. Puede eludir la autenticación. Puede exfiltrar datos. Puede generar código malicioso que se canaliza hacia un sistema posterior.

Un modelo de IA envenenado es el agente durmiente perfecto: pasa todas las pruebas, arrasa en todos los benchmarks y espera pacientemente un disparador que solo el atacante conoce.

Y aquí viene el mazazo matemático: añadir más datos limpios no lo soluciona. Una vez que la puerta trasera alcanza un umbral —normalmente de 50 a 100 apariciones del disparador durante el entrenamiento— queda grabada permanentemente en los pesos. No puedes eliminarla reentrenando. No puedes diluirla.

NVIDIA formalizó esto en lo que denomina la AI Kill Chain: cinco etapas —Recon, Poison, Hijack, Persist, Impact— que trazan cómo los atacantes comprometen sistemáticamente los sistemas de aprendizaje automático. Escribí sobre este marco y sobre todo el espectro de vectores de ataque en nuestra visión general interactiva de la investigación, y animaría a cualquiera que despliegue modelos en producción a dedicarle tiempo.

La implicación para cualquier empresa que aplique ajuste fino a modelos con sus propios datos es contundente: incluso si tu conjunto de datos propietario es impecable, el modelo base que descargaste de un repositorio público podría estar ya comprometido. Estás construyendo sobre unos cimientos cuyo interior no puedes ver.

El problema de la Shadow AI del que nadie quiere hablar

Estuve en una cena con la CISO de una firma mediana de servicios financieros. Me contó, casi de pasada, que su equipo había descubierto recientemente 47 modelos de IA distintos ejecutándose en producción en toda la compañía. Su política de gobernanza de la IA cubría tres de ellos.

Esto es Shadow AI, y es una epidemia. Los datos son abrumadores: el 90% del uso de IA en la empresa ocurre fuera del alcance de los equipos de TI y de seguridad. Los desarrolladores y las unidades de negocio descargan modelos sin verificar de repositorios públicos porque el proceso oficial tarda demasiado. Pegan código propietario y datos de clientes en herramientas de IA públicas: se ha observado que el 77% de los empleados lo hace. Y cada uno de esos modelos no autorizados es una posible puerta trasera que ningún escáner ha tocado jamás.

El impacto financiero no es abstracto. Los incidentes que involucran herramientas de IA sin verificar incrementan el coste de una filtración de datos en una media de $670.000. Ese es el sobreprecio que pagas por "ir rápido" sin gobernanza.

Entiendo el impulso. De verdad que sí. Cuando eres un ingeniero intentando entregar una funcionalidad y el proceso de revisión de seguridad tarda tres semanas, por supuesto que te tienta simplemente descargar un modelo de Hugging Face y conectarlo. Yo mismo he sentido esa tentación. Pero la divulgación de JFrog debería haber puesto fin a esa era. Ahora sabemos, con certeza empírica, que los repositorios públicos de modelos contienen artefactos armados. Tratarlos como fuentes de confianza es el equivalente en IA a ejecutar curl | bash desde un gist cualquiera de GitHub en producción.

¿Por qué todo el mundo sigue volando a ciegas?

NIST publicó su guía AI 100-2 en 2024: una taxonomía exhaustiva de ataques adversarios al aprendizaje automático y sus mitigaciones. Es un buen trabajo. Da a la industria un lenguaje común para estas amenazas. Y casi nadie la ha implementado.

Las cifras son demoledoras:

• Solo el 17% de las organizaciones tiene controles automatizados de seguridad de la IA
• Solo el 12% tiene una gobernanza integral de la IA implantada
• Solo el 14% tiene visibilidad sobre los flujos internos de datos de IA
• El 83% de las organizaciones, según el planteamiento del NIST, "opera a ciegas"

He visto esta brecha de cerca. Las organizaciones confunden tener un documento de políticas con tener seguridad operativa. Te enseñarán un PDF de gobernanza de la IA bellamente maquetado mientras sus desarrolladores cargan modelos pickle sin firmar en clústeres de Kubernetes en producción. El documento existe. Los controles no.

El 83% de las empresas no tiene controles automatizados sobre su cadena de suministro de IA. Eso no es una brecha: es una puerta abierta.

Cómo empezamos a tratar los modelos como código malicioso

Tras la revelación de aquel martes por la noche, mi equipo en Veriprajna dedicó semanas a rediseñar nuestro enfoque de la ingesta de modelos. El cambio filosófico de fondo era simple pero radical: tratar cada modelo de IA como código ejecutable potencialmente malicioso hasta que se demuestre lo contrario.

No "probablemente esté bien". No "viene de una fuente reputada". Potencialmente malicioso. Punto.

La lista de materiales de aprendizaje automático

Lo primero que necesitábamos era transparencia. Las listas de materiales de software tradicionales (SBOM) registran bibliotecas y versiones, pero los artefactos de IA necesitan algo más: un ML-BOM —una lista de materiales de aprendizaje automático— que capture la procedencia de los datos, el linaje del modelo, las dependencias del framework y las atestaciones criptográficas.

¿De dónde salieron los datos de entrenamiento? ¿Quién aplicó ajuste fino a este modelo, y con qué? ¿Qué versión de PyTorch se usó, y tiene vulnerabilidades conocidas? ¿Podemos verificar criptográficamente que el modelo que estamos cargando es exactamente el artefacto que produjo un pipeline de confianza, sin manipulación durante el transporte?

Si no puedes responder a estas preguntas, no sabes qué estás desplegando.

Matar pickle, firmarlo todo

Tomamos dos decisiones de ingeniería inmediatas. Primera: se acabó pickle. Punto. Todos los modelos de nuestro pipeline usan SafeTensors, un formato que almacena únicamente datos de tensores con metadatos JSON y que no puede ejecutar código durante la carga. Es menos flexible que pickle, y esa es exactamente la idea.

Segunda: firma criptográfica de modelos. Cada artefacto de modelo recibe un hash único, firmado con nuestra infraestructura interna de PKI. Nuestros servidores de inferencia ejecutan un controlador de admisión que verifica la firma contra nuestra raíz de confianza antes de que los pesos se deserialicen en memoria. Si la firma no coincide, el modelo no se carga. Sin excepciones, sin anulaciones, sin "pero si es solo para pruebas".

Uno de mis ingenieros se opuso con fuerza a esto. "Estás añadiendo fricción al flujo de trabajo de desarrollo", dijo. Tenía razón. Añadí fricción a propósito. Porque la alternativa —el camino sin fricción en el que cualquiera puede cargar cualquier modelo desde cualquier sitio— es la manera de acabar con una shell inversa hacia Corea ejecutándose en tu servidor de inferencia.

Monitorización en tiempo de ejecución: porque los análisis estáticos no bastan

Aprendimos de la vulnerabilidad de las plantillas GGUF que el análisis estático solo detecta una parte de la superficie de amenaza. Un modelo puede ser limpio en el momento de la carga y malicioso en el momento de la inferencia. Así que añadimos monitorización continua en tiempo de ejecución: validación de las salidas frente a líneas base limpias para detectar la deriva, limitación de consultas para impedir ataques de extracción de modelos y capas de saneamiento de entradas que reformulan las consultas antes de que lleguen al modelo central, desbaratando payloads adversarios cuidadosamente elaborados.

Para la arquitectura técnica completa —incluido nuestro enfoque de la computación confidencial con Trusted Execution Environments respaldados por hardware— consulta el análisis técnico en profundidad de nuestro informe de investigación. Allí hay un nivel de detalle de implementación que va más allá de lo que puedo cubrir en un ensayo.

La verdad incómoda sobre la "Deep AI" frente a los wrappers de API

Hay una razón por la que vuelvo una y otra vez a la distinción entre lo que yo llamo "Deep AI" —sistemas de IA autoalojados, con ajuste fino y controlados a nivel arquitectónico— y el enfoque de wrapper de API que domina el mercado. No es solo una preferencia técnica. Es un argumento de seguridad.

Cuando envuelves una API pública, externalizas tu cadena de suministro de IA a otra persona. No tienes visibilidad sobre la procedencia de sus modelos, sus datos de entrenamiento ni su postura de seguridad. Estás confiando en que OpenAI, Anthropic o Google hayan hecho el trabajo duro de asegurar su pipeline. Puede que lo hayan hecho. Pero no puedes verificarlo, y en seguridad, la confianza sin verificación no es más que esperanza.

Cuando construyes en profundidad —cuando controlas los pesos del modelo, el pipeline de entrenamiento, la infraestructura de inferencia— heredas la responsabilidad de toda la cadena de suministro. Eso es más difícil. Es más caro. Exige el tipo de disciplina de ingeniería que vengo describiendo. Pero es el único camino hacia una seguridad verificable.

Un inversor me dijo una vez: "Usa simplemente la API de GPT y céntrate en el producto". Le respondí que para los sectores a los que servimos —donde un modelo comprometido podría significar datos financieros filtrados, diagnósticos médicos manipulados o análisis jurídicos corrompidos— "usa simplemente la API" es un pasivo, no una estrategia.

La seguridad de la IA y la seguridad del software ya son el mismo problema

Esta es la idea que hizo que todo encajara para mí: la seguridad de la IA y la seguridad de la cadena de suministro de software ya no son disciplinas separadas. No pueden serlo. Los modelos de IA no se ejecutan de forma aislada: se construyen y se despliegan a través de los mismos pipelines de CI/CD, registros de contenedores y árboles de dependencias que usa el software tradicional.

Si tu modelo está firmado criptográficamente pero la biblioteca de Python de la que depende ha sido comprometida mediante un ataque a la cadena de suministro, estás vulnerado. Si tu pipeline de entrenamiento se ejecuta en una imagen de contenedor contaminada, los pesos de tu modelo no son fiables por muy limpios que sean tus datos de entrenamiento.

La industria sigue intentando crear equipos separados de "seguridad de IA" y de "seguridad de aplicaciones". Esa división organizativa es una vulnerabilidad. La superficie de ataque está unificada, y la defensa también debe estarlo.

A medida que el código generado por IA acelera la velocidad de desarrollo, el proceso tradicional de revisión humana de código se derrumba bajo el peso del volumen. Las pull requests grandes generadas por IA son difíciles de revisar con cuidado bajo la presión de los plazos, lo que crea una cultura de "revisión superficial" que elimina uno de los últimos controles de seguridad con intervención humana. En este entorno, la verificación automatizada y determinista —basada en firmas criptográficas y ML-BOM— no es opcional. Es lo único que escala.

"Pero nosotros no somos un objetivo"

La gente siempre replica con alguna versión de esto. "No hacemos nada lo bastante sensible como para justificar este nivel de seguridad". "Nuestros modelos son solo para herramientas internas". "Nadie se molestaría en envenenar un modelo para atacarnos".

Oí los mismos argumentos sobre la seguridad de las bibliotecas de código abierto en 2018. Luego llegó SolarWinds. Luego llegó Log4Shell. Luego llegó la puerta trasera de XZ Utils: una campaña de ingeniería social de varios años para comprometer una única biblioteca de compresión utilizada por SSH en todos los servidores Linux del mundo.

La cadena de suministro de IA sigue la misma trayectoria, solo que más rápido. La superficie de ataque es mayor (los pesos de los modelos son blobs binarios opacos que no pueden auditarse como sí puede hacerse con el código fuente), las herramientas son menos maduras (PickleScan tiene vulnerabilidades de día cero) y la brecha de gobernanza es más amplia (el 83% de las empresas no tiene controles automatizados).

No hace falta ser un objetivo para ser una víctima. Basta con estar en el camino.

Así es la seguridad de la IA aburrida

Mi objetivo —y puede que esto suene extraño— es hacer que el despliegue de IA sea aburrido. Ni emocionante, ni puntero, ni "muévete rápido y rompe cosas". Aburrido. Predecible. Auditable.

Aburrido significa que todos los modelos tienen un ML-BOM. Aburrido significa firmas criptográficas verificadas en el momento de la carga. Aburrido significa nada de pickle, nunca. Aburrido significa monitorización en tiempo de ejecución que detecta la deriva antes de que se convierta en una brecha. Aburrido significa un registro centralizado de activos de IA en el que cada modelo, conjunto de datos y dependencia está inventariado, verificado y bajo control de versiones.

Aburrido significa que cuando alguien pregunta "¿qué modelos de IA se están ejecutando en producción?" puedes responder en menos de cinco minutos, con prueba criptográfica.

El objetivo no es hacer que el despliegue de IA sea emocionante. Es hacerlo aburrido: predecible, auditable y seguro. Una seguridad de la IA emocionante significa que algo ha salido mal.

Los más de 100 modelos maliciosos en Hugging Face no fueron un incidente aislado. Fueron un síntoma de una industria que construyó capacidades increíbles sobre unos cimientos de confianza ciega. Descargábamos modelos igual que antes descargábamos MP3 de LimeWire: esperando lo mejor, ignorando los riesgos evidentes y fingiendo sorpresa cuando algo salía mal.

Esa era ha terminado. Las organizaciones que sobrevivan a la próxima oleada de ataques a la cadena de suministro de IA serán las que decidieron, ahora mismo, tratar sus modelos no como cajas mágicas sino como código ejecutable con toda la superficie de ataque que eso implica. Las que eligieron lo aburrido antes que lo rápido. Las que miraron la terminal, vieron cargarse el archivo pickle y dijeron: "Espera. ¿Qué formato es ese?"