Tus modelos de IA son código ejecutable. La mayoría de las empresas los tratan como hojas de cálculo.

La primera vez que comprendí de verdad el problema, estaba observando cómo se desplazaba un rastreo de llamadas al sistema en un contenedor aislado, esperando que no hiciera nada.

Habíamos descargado un modelo de un registro público, del tipo que un científico de datos descarga cien veces por trimestre sin pensárselo. La ficha del modelo parecía normal. Había pasado un análisis básico. Lo había cargado en un entorno aislado no porque sospechara de ese archivo en concreto, sino porque había empezado a cargar todo en un entorno aislado. Y mientras se ejecutaba la deserialización, el rastreo mostró que el proceso intentaba abrir una conexión de red que no tenía por qué abrir.

Esa es toda la tesis de la seguridad de la cadena de suministro de la IA en un solo instante: tus modelos no son archivos de datos. Son código ejecutable que se ejecuta en cuanto los cargas. La mayoría de las organizaciones los tratan como hojas de cálculo (cosas inertes que descargas y abres), y esa brecha entre lo que un modelo es y cómo se lo trata es justo donde ocurren las brechas de seguridad.

Un modelo no es un documento que abres. Es un programa que ejecutas con los privilegios de quien lo ejecutó.

La historia de la shell inversa ni siquiera es un mito hipotético del sector. Se descubrió que un modelo llamado "baller423" en Hugging Face establecía una shell inversa hacia un host externo. Parecía normal. Pasó los análisis básicos. Ejecutó código arbitrario en el momento en que alguien lo cargó. Cuando cuento esa historia a una sala llena de líderes de seguridad, la incomodidad no está en que semejante cosa sea posible, sino en que se dan cuenta de que su equipo ha estado cargando modelos desde la misma fuente, de la misma manera, durante dos años.

El problema de pickle del que nadie quiere oír hablar

Esta es la parte que hace que los ingenieros experimentados hagan una mueca, porque no es un fallo que nadie pueda parchear.

Cuando invocas torch.load() en un modelo de PyTorch, este puede ejecutar código Python arbitrario durante la deserialización. Eso no es una vulnerabilidad en el sentido habitual. Es el comportamiento diseñado del formato de serialización pickle de Python: pickle tiene permitido reconstruir objetos ejecutando código, y un archivo de modelo no es más que un objeto serializado con pickle. Más del 80 % de los modelos de aprendizaje automático que circulan usan este formato. Así que la forma predeterminada en que todo el campo distribuye modelos es también una primitiva de ejecución remota de código esperando a que alguien la complete.

El instinto, razonablemente, es analizarlos en busca de ello. La defensa más ampliamente desplegada es una herramienta llamada PickleScan, que busca patrones maliciosos conocidos dentro de los archivos de modelo. Y PickleScan tiene al menos tres bypasses de día cero conocidos (entre ellos CVE-2025-10155), y posteriormente investigadores de Sonatype encontraron cuatro vulnerabilidades más en el propio analizador.

No lo digo para menospreciar un proyecto de código abierto que hace un trabajo real. Lo digo porque me enseñó un principio en torno al cual ahora construyo todo: cuando el atacante controla el formato del archivo, el análisis por listas negras pierde estructuralmente. El análisis estático pregunta "¿contiene este archivo un patrón que ya sé que es malo?". El atacante, que puede ver la misma lista negra que tú, simplemente usa un patrón que tú aún no conoces.

Así que dejamos de hacer esa pregunta. Los procesos de verificación que construye mi equipo no arrancan con "qué cadenas maliciosas conocidas hay en este archivo". Arrancan con el sandboxing conductual: cargar el modelo en un contenedor aislado, observar qué es lo que realmente hace (las llamadas al sistema, los intentos de conexión a la red, las escrituras de archivos) y juzgar el comportamiento, no la firma. La pregunta pasa de "¿está esto en una lista?" a "¿qué hace este código cuando se ejecuta?". Esa segunda pregunta es la única que atrapa el ataque que aún nadie ha nombrado.

El análisis estático atrapa el ataque de ayer. El sandboxing conductual atrapa el que el atacante está escribiendo ahora mismo.

No es gratis, ni es un producto que compras de la estantería. Protect AI, ahora parte de Palo Alto Networks tras una adquisición de aproximadamente 500-700 millones de dólares que se cerró en julio de 2025, analizó 4,47 millones de versiones de modelos y encontró 352 000 problemas inseguros o sospechosos en más de 51 700 modelos. Esa es la magnitud del pajar. Las herramientas pueden señalar lo evidente. Diseñar la compuerta que se sitúa entre un registro público y tu almacén interno de modelos, y hacerla lo bastante rápida como para que nadie la esquive, es la parte que no viene en una caja.

La compuerta que construí y que todos ignoraron

Quiero contarte la versión de esto que hice mal, porque el fracaso me enseñó más que el éxito.

Al principio, construí una compuerta de verificación de modelos para un cliente que era, técnicamente, excelente. Todo modelo que entraba desde una fuente pública se llevaba al entorno aislado, se analizaba en profundidad en distintos formatos, se perfilaba por su comportamiento y solo entonces se firmaba y se admitía en el registro interno. En una auditoría de seguridad habría obtenido una puntuación magnífica. Estaba orgulloso de ella.

En cosa de una semana, el equipo de ciencia de datos había dejado de usarla en silencio.

No por malicia. Tenían plazos. La compuerta añadía minutos reales a un flujo de trabajo en el que la alternativa (descargar un modelo directamente de Hugging Face) tardaba treinta segundos. Así que cuando un experimento necesitaba un modelo ya, lo descargaban en bruto a una cuenta de nube personal y seguían adelante. Mi hermosa compuerta protegía una puerta vacía mientras el tráfico real rodeaba el edificio por un lado.

Esa semana replanteó todo el problema para mí. El control más difícil en la seguridad de la cadena de suministro de la IA no es técnico. Es que una compuerta de seguridad que sea más lenta que el camino inseguro va a perder siempre, sin excepción. Cuando un científico de datos puede descargar un modelo en treinta segundos, cualquier proceso que tarde treinta minutos se acaba esquivando; no por parte de actores maliciosos, sino de buenos ingenieros bajo presión. Los controles tienen que ser lo bastante rápidos como para que cumplirlos sea más fácil que eludirlos. Si no lo son, no tienes un programa de seguridad. Tienes un teatro de seguridad con reseñas excelentes y sin público.

Por eso las cifras sobre la IA en la sombra nunca me sorprendieron después de aquello. El 98 % de las organizaciones tienen empleados que usan herramientas de IA no autorizadas. El 62 % de los profesionales de seguridad dicen no tener una forma fiable de saber siquiera dónde se están ejecutando los grandes modelos de lenguaje en su entorno. Solo alrededor del 9 % de las empresas tiene un sistema de gobernanza de la IA que funcione, aunque un tercio de los directivos te dirá que dispone de un seguimiento exhaustivo. Y el coste no es abstracto: el informe Cost of a Data Breach de IBM de 2025 sitúa la brecha media relacionada con la IA en la sombra en 4,63 millones de dólares, aproximadamente 670 000 dólares más que un incidente estándar.

No puedes proteger lo que no puedes ver, y ahora mismo la mayoría de las organizaciones no pueden ver la mayor parte de su IA.

¿Por qué el ajuste fino desarma sigilosamente tu modelo más seguro?

Este es el que provoca la reacción más fuerte cuando lo llevo a un equipo técnico, porque contradice algo que todo el mundo da por sentado.

La suposición es: evalué este modelo por seguridad, lo pasó, así que es seguro. La realidad es que la alineación de seguridad es frágil de una manera que el calendario de evaluación pasa completamente por alto. En un estudio, la resistencia de Llama 3.1 8B a la inyección de prompts cayó de una puntuación de 0,95 a 0,15 tras una única ronda de ajuste fino, y no de ajuste fino adversarial. Entrenamiento normal, benigno, específico del dominio. Eso es aproximadamente un desplome del 84 % en una propiedad de seguridad, causado por lo más corriente que una empresa le hace a un modelo.

Tuve exactamente esta discusión con el equipo de aprendizaje automático de un cliente. Habían ejecutado su evaluación de seguridad, el modelo la pasó, lo ajustaron con sus propios datos y estaban listos para lanzarlo. Les pregunté cuándo pensaban volver a ejecutar la evaluación. La sala se quedó un poco callada, porque la respuesta honesta era "no íbamos a hacerlo". El modelo pasa la compuerta antes de aquello que lo rompe. Luego pasa a producción con sus salvaguardas prácticamente desmanteladas, y todo el papeleo dice que es seguro.

El modelo pasa su control de seguridad antes del paso que destruye la seguridad. Casi nadie vuelve a comprobarlo después.

Así que trasladamos la evaluación de seguridad a después del ajuste fino, la convertimos en una compuerta de lanzamiento en lugar de una compuerta de admisión, y tratamos cualquier ajuste fino como un evento que invalida la atestación de seguridad previa. Suena casi demasiado obvio una vez lo dices en voz alta. La razón por la que no es práctica estándar es la misma que la de la compuerta que nadie usaba: el momento conveniente para evaluar es en la admisión, y volver a evaluar tras cada ajuste fino supone fricción. La fricción es el enemigo, pero en este caso es lo único que se interpone entre un informe aprobado y un modelo indefenso.

El envenenamiento demuestra lo mismo desde la otra dirección. La investigación ha mostrado que tan solo 250 documentos envenenados pueden implantar una puerta trasera en un modelo de 13 000 millones de parámetros, alrededor del 0,00016 % del corpus de entrenamiento. No necesitas comprometer los datos a gran escala. Necesitas la cantidad equivalente a un error de redondeo. Microsoft publicó una respuesta genuinamente alentadora a esto en febrero de 2026: un método de detección de "agentes durmientes" que puede identificar un modelo envenenado sin conocer la frase desencadenante, detectando un patrón de atención distintivo. Esa es la primera defensa real que he visto contra un ataque que antes era casi indetectable. Es también exactamente el tipo de capacidad que vive en un artículo de investigación, no en tu canalización de CI/CD, hasta que alguien hace la ingeniería para ponerla ahí.

Los agentes convirtieron una inyección de prompts en una cadena de ataque

Durante años, el peor caso con un modelo manipulado o una inyección de prompts era una salida defectuosa. El modelo dice algo incorrecto, filtra algo que no debería, te avergüenza. Acotado. Molesto. Sobrevivible.

La IA agéntica eliminó el límite.

Un agente de IA tiene acceso a herramientas, credenciales y privilegios de ejecución que un modelo de chat no tiene. Así que cuando inyectas una instrucción maliciosa en algo que un agente lee, ya no estás corrompiendo una respuesta: estás emitiendo una orden a un sistema que puede actuar. GitHub Copilot tuvo una vulnerabilidad de ejecución remota de código, CVE-2025-53773, calificada con CVSS 7,8 y parcheada en agosto de 2025, en la que una inyección de prompts plantada en la documentación de un repositorio podía inducir al agente a su "modo YOLO" autónomo y escalar hasta el compromiso total del sistema. El agente leyó un comentario malicioso, lo ejecutó como código, y la máquina quedó bajo control ajeno.

Luego estuvo el incidente de la cadena de suministro de Amazon Q en julio de 2025: una plantilla de prompt cleaner.md maliciosa se inyectó a través de un token de GitHub mal configurado, y una versión lanzada distribuyó comandos destructivos a una base de instalaciones muy grande. Y en 2026, el ecosistema de agentes OpenClaw se convirtió en la primera gran crisis de seguridad de agentes de IA del año: 138 CVE en 63 días, más de 135 000 instancias expuestas y un 12 % de las habilidades de su mercado resultaron ser maliciosas. El informe de amenazas de HiddenLayer de 2026 vincula ahora aproximadamente una de cada ocho brechas de IA con sistemas agénticos.

El hilo conductor en todos estos casos es el mismo: los agentes convierten una única entrada manipulada en una cadena de ataque orquestada y multiherramienta. Lo que antes era una sola frase equivocada se convierte en una secuencia de acciones reales con credenciales reales. Esa es la frontera que más me preocupa ahora mismo, porque se está expandiendo más rápido de lo que cualquier categoría de producto puede seguir, y todavía no hay un manual establecido para protegerla.

Entonces, ¿qué haces realmente al respecto?

La gente siempre me pregunta alguna versión de: "¿No puedo simplemente comprar una herramienta para esto?". Y la respuesta honesta es que puedes comprar piezas, y las piezas están mejorando rápido.

El panorama de proveedores ha madurado hasta convertirse en un ecosistema real: Protect AI de Palo Alto y Wiz para el análisis y la generación de la lista de materiales de IA dentro de sus suites de nube y de plataforma, JFrog para asegurar el registro de modelos y la canalización de artefactos, HiddenLayer para la detección y respuesta en tiempo de ejecución, las guardrails de código abierto de NVIDIA para los controles de LLM a nivel de aplicación, Fortanix aportando la computación confidencial a la distribución de modelos. Ese último es un buen ejemplo de por qué las herramientas por sí solas no cierran la brecha: las GPU confidenciales que mantienen un modelo cifrado incluso mientras se ejecuta (las generaciones Hopper y Blackwell de NVIDIA) existen de verdad, pero conectar esos entornos de ejecución de confianza a una canalización de inferencia en vivo es ingeniería especializada que la mayoría de los equipos sencillamente no tiene en plantilla. Cada proveedor es genuinamente bueno en su porción. Ninguno diseña tu canalización de extremo a extremo, la asocia con tus obligaciones ni cambia cómo se comporta realmente tu organización.

Y la otra mitad del mercado (las grandes consultoras de estrategia) te venderá el problema opuesto: un marco de gobernanza de la IA de 200 páginas, una presentación para el consejo, documentación lista para auditorías y un proyecto que arranca en torno a 500 000 dólares por la estrategia y escala hasta los millones para la implementación. Lo que normalmente no harán es construir la canalización de firma de modelos, configurar la generación del ML-BOM dentro de tu CI/CD o poner en marcha la detección de IA en la sombra a nivel de red. Acabas con la carpeta y no con la construcción.

Esa brecha (entre herramientas que analizan y presentaciones que asesoran) es la razón entera por la que Veriprajna aborda la seguridad de la cadena de suministro de la IA como ingeniería en lugar de como un informe. Lo que construimos es concreto: canalizaciones automatizadas de verificación de modelos que someten a sandboxing conductual cada modelo entrante y firman los limpios con tu PKI empresarial; un ML-BOM (una lista de materiales de aprendizaje automático, el equivalente en IA de una etiqueta de ingredientes que rastrea cada componente y su procedencia) generado y fijado dentro de la canalización usando el estándar CycloneDX; procedencia y firma construidas sobre el emergente trabajo de atestación de CoSAI; controles de seguridad posteriores al ajuste fino; y detección de IA en la sombra que saca a la luz los modelos que tus herramientas de seguridad no pueden ver actualmente.

Los estándares para hacer la mayor parte de esto ya existen. CycloneDX ML-BOM, la firma de modelos de CoSAI y la taxonomía actualizada de aprendizaje automático adversarial del NIST (AI 100-2) están todos publicados y son utilizables hoy. El problema nunca fue de conocimiento. Según la medición de Kiteworks de 2025, el 83 % de las organizaciones aún carece de controles automatizados de seguridad de la IA; vuelan a ciegas no porque falte el manual, sino porque nadie tiene la capacidad de ingeniería para implementarlo. La brecha son manos, no ideas.

También hay un reloj regulatorio corriendo sobre esto. La Ley de IA de la UE entra en plena aplicación el 2 de agosto de 2026, y para los sistemas de alto riesgo exige documentación técnica real: la procedencia de los datos de entrenamiento, la evaluación de la conformidad, el tipo de atestación de la cadena de suministro que un ML-BOM está diseñado para producir. Los importadores y distribuidores de componentes de IA tendrán que verificar lo que pasan aguas abajo, y los proveedores y sus proveedores de componentes de terceros deben acordar por escrito la información y el acceso técnico que compartirá cada uno. He empezado a decirles a los clientes la parte silenciosa de esa cláusula: una vez que la Ley muerda, la procedencia de los modelos deja de ser solo tu problema que absorber; tus proveedores tienen que atestiguarla por escrito, y los que no puedan simplemente dejarán de ser utilizables. Las empresas que tratan la procedencia de los modelos como algo prescindible van a descubrir que es un requisito de presentación obligatoria.

La diapositiva que de verdad movió el presupuesto

Terminaré donde estas conversaciones suelen terminar: frente a un consejo de administración.

He visto a muchos casos de seguridad bien construidos no lograr financiación porque se presentaron como casos de seguridad: riesgo abstracto, atacantes hipotéticos, una categoría que suena a seguro. La presentación que funcionó fue la que puso una sola cifra sobre la mesa: los 4,63 millones de dólares de coste medio de una brecha por IA en la sombra, frente al coste de construir los controles que la previenen. No miedo. Un diferencial. Aquí está el riesgo cuantificado, aquí está lo que cuesta cerrarlo, aquí está la diferencia.

Ese enfoque funciona porque es fiel a cómo se comporta realmente este problema. La amenaza no es exótica. Es el flujo de trabajo predeterminado (descargar un modelo, ajustarlo, desplegarlo, no volver a mirar nunca) ejecutándose en cada organización que construye con IA, que ahora son casi todas. Los presupuestos de los CISO lo reflejan: alrededor del 85 % de las organizaciones aumentaron su gasto en ciberseguridad de cara a 2026, y la seguridad de la IA es la partida más comentada.

Un modelo es el único artefacto de tu entorno que es a la vez lo más valioso que tienes y una pieza de código ejecutable sin verificar que descargaste de un desconocido en internet. Hasta que lo trates como ambas cosas a la vez (verificarlo como código, rastrearlo como una cadena de suministro y volver a comprobarlo cada vez que lo cambias), el informe que dice que estás seguro está auditando un control que en realidad nadie usa. Si estás pensando por dónde empezar, empieza por ahí: deja de confiar en la ficha del modelo y observa qué hace el modelo cuando se ejecuta.