Ingeniería de Seguridad de IA

Seguridad de la Cadena de Suministro de IA & Integridad de Modelos

Sus modelos son código ejecutable. La mayoría de las organizaciones los tratan como archivos de datos. Esa brecha es donde ocurren las filtraciones.

$4.63M

Coste medio de una filtración que involucra IA en la sombra

IBM Cost of a Data Breach 2025

83%

De las organizaciones carecen de controles de seguridad de IA automatizados

Kiteworks 2025

352K

Problemas inseguros encontrados en 51.700 modelos en registros públicos

Protect AI 2025

La Superficie de Ataque Que la Mayoría de los Programas de Seguridad Pasan por Alto

Los modelos de IA no son artefactos estáticos. Son código que se ejecuta durante la carga, el entrenamiento, la inferencia y la ejecución de agentes. Cuatro categorías de ataque dominan el modelo de amenazas.

El Problema del Formato Pickle

torch.load() ejecuta Python arbitrario durante la deserialización. Esto no es un error. Es el comportamiento diseñado de la serialización pickle, y más del 80% de los modelos de ML lo utilizan.

Se descubrió que un modelo llamado "baller423" en Hugging Face establecía una shell inversa a Kreonet. El modelo parecía normal. Pasó los escaneos básicos. Ejecutó código arbitrario en el momento en que alguien lo cargó.

PickleScan, la defensa más utilizada, tiene al menos 3 bypasses de día cero conocidos (CVE-2025-10155). El escaneo basado en listas negras está fundamentalmente roto porque el atacante controla el formato de serialización.

El Ajuste Fino Destruye la Seguridad

Llama 3.1 8B cae de 0.95 a 0.15 en resiliencia frente a inyección de prompts tras una sola ronda de ajuste fino. Eso es una degradación del 84% en la alineación de seguridad a partir de un entrenamiento normal y no adversarial.

Casi nadie reevalúa la seguridad después del ajuste fino. El modelo pasa la evaluación de seguridad inicial, se ajusta con datos de dominio y pasa a producción con sus barreras de protección efectivamente eliminadas. Esto no es un ataque exótico. Es el flujo de trabajo predeterminado en la mayoría de las organizaciones.

Proliferación de IA en la Sombra

El 98% de las organizaciones tienen un uso no autorizado de IA. Ese número no es un error tipográfico. El coste adicional de filtración de $670K para incidentes de IA en la sombra refleja una realidad simple: no se puede asegurar lo que no se puede ver.

El 62% de los equipos de seguridad no pueden identificar dónde están desplegados los LLM en su entorno. Los desarrolladores descargan modelos de Hugging Face, llaman a las API de OpenAI con claves personales y despliegan modelos ajustados en cuentas de nube personales. Las herramientas de seguridad actuales detectan aproximadamente el 38% de esta actividad.

Amplificación de la IA Agéntica

La vulnerabilidad RCE de GitHub Copilot (CVE-2025-53773, CVSS 7.8) convirtió una inyección de prompts en la documentación de un repositorio en un compromiso total del sistema mediante el modo YOLO. El agente leyó una instrucción maliciosa, la ejecutó como código y la máquina del usuario quedó comprometida.

El archivo cleaner.md de Amazon Q distribuyó comandos destructivos a más de 950K usuarios a través de la ventana de contexto del agente. El mercado de OpenClaw acumuló 138 CVE en 63 días, con un 12% de las habilidades enviadas identificadas como maliciosas.

Los agentes convierten las inyecciones de prompts en compromisos a nivel de sistema porque tienen acceso a herramientas, credenciales y privilegios de ejecución que los LLM tradicionales no poseen.

Quién Hace Qué en la Seguridad de Modelos de IA

El ecosistema de proveedores está madurando rápidamente. Aquí hay una visión honesta de lo que cubre cada actor y dónde permanecen las brechas.

Proveedor Qué Hacen Qué No Hacen Ideal Para
Palo Alto / Protect AI Escaneo de modelos, generación de AI-BOM, integrado en la plataforma Prisma AIRS Diseño de arquitectura, ingeniería de pipelines personalizados, gestión del cambio organizacional Empresas que ya están en la plataforma PANW
HiddenLayer Detección y respuesta de IA en tiempo de ejecución, monitoreo de seguridad agéntica Arquitectura de cadena de suministro, implementación de ML-BOM, mapeo de cumplimiento Equipos SOC que añaden visibilidad de IA
JFrog MLSecOps, seguridad del registro de modelos, integración con Hugging Face Red-teaming adversarial, validación de alineación de seguridad, diseño de gobernanza Equipos DevOps que gestionan artefactos de modelos
Wiz AI-BOM en el contexto de seguridad en la nube, escaneo de modelos Seguridad de modelos on-premise, seguridad de ajuste fino, arquitectura agéntica Organizaciones que priorizan la nube
NVIDIA NeMo Guardrails Guardrails de tiempo de ejecución de código abierto para LLM Escaneo de modelos, seguridad de la cadena de suministro, seguimiento de procedencia Equipos que construyen aplicaciones LLM personalizadas
Big 4 / Grandes SI Marcos de gobernanza, documentación de cumplimiento, presentaciones para la junta directiva Implementación. Construcción de pipelines de escaneo, configuración de ML-BOM, despliegue de firma de modelos. Los compromisos comienzan en $500K de estrategia y escalan hasta $3-10M. Organizaciones que necesitan documentación lista para auditorías
Código Abierto (ModelScan, PickleScan, SafeTensors) Escaneo básico gratuito y formatos de serialización más seguros Orquestación de nivel empresarial, sandboxing conductual, procedencia, aplicación de políticas Equipos con una sólida ingeniería de seguridad interna

Una brecha que nadie cubre bien. El cambio de cultura organizacional es la parte más difícil. Ninguna herramienta o consultoría elimina la tendencia humana a eludir la gobernanza por velocidad. Construimos los controles técnicos, pero el CISO aún necesita el respaldo de los ejecutivos. Cuando un científico de datos puede descargar un modelo de Hugging Face en 30 segundos, cualquier barrera de seguridad que tarde 30 minutos será eludida. Los controles deben ser lo suficientemente rápidos como para que cumplir sea más fácil que eludir.

Lo Que Construimos para los Programas de Seguridad de IA

Seis capacidades, cada una diseñada para integrarse con su stack de seguridad existente y sus pipelines de CI/CD.

01

Pipelines de Evaluación de Modelos

Construimos una evaluación automatizada que se sitúa entre los repositorios públicos de modelos y su registro interno. Cada modelo pasa por sandboxing conductual (cargado en contenedores aislados, con monitoreo de syscalls), análisis profundo multiformato (pickle, PyTorch, GGUF, Keras, SafeTensors) y firma criptográfica con su PKI empresarial.

Optamos por el análisis conductual en lugar del escaneo estático porque los bypasses de día cero de PickleScan demuestran que los enfoques basados en listas negras están fundamentalmente rotos. El escaneo estático pregunta "¿contiene este archivo patrones conocidos como maliciosos?" El sandboxing conductual pregunta "¿qué hace realmente este código cuando se ejecuta?" La segunda pregunta detecta ataques novedosos.

02

Arquitectura de ML-BOM & Procedencia

Generación de ML-BOM CycloneDX integrada en CI/CD. Cada modelo obtiene una lista de materiales que documenta la procedencia de los datos de entrenamiento, las versiones del framework, los árboles de dependencias y el historial de ajuste fino.

Usamos CycloneDX en lugar de SPDX porque las herramientas de ML-BOM están más maduras, aunque garantizamos la exportación a SPDX 3.0 para organizaciones que necesitan ambos. El ML-BOM no es una casilla de cumplimiento. Es la estructura de datos que hace posible todos los demás controles de seguridad: no se puede firmar lo que no se puede inventariar, y no se puede auditar lo que no se puede rastrear.

03

Descubrimiento de IA en la Sombra

Detección a nivel de red de descargas de modelos no autorizadas y llamadas a API de IA. Integración con su SIEM/SOAR existente. Mapeamos cada punto de contacto de IA, incluidos los despliegues en la sombra, y luego construimos una aplicación de políticas que bloquea el riesgo sin bloquear la innovación.

El objetivo: que su equipo de seguridad vea el 100% del uso de IA, no el 38% que detectan las herramientas actuales. La detección cubre las descargas de Hugging Face, las llamadas a API de OpenAI/Anthropic/Google, las transferencias de pesos de modelos por HTTP/S y la ejecución de modelos locales mediante el monitoreo de procesos en los endpoints gestionados.

04

Validación de Seguridad Posterior al Ajuste Fino

Reevaluación automatizada de seguridad después de cada ejecución de ajuste fino. Suite de benchmarks OWASP LLM Top 10, sondeo adversarial de desencadenantes de puertas traseras y pruebas de regresión de alineación de seguridad.

Construimos esto porque casi nadie reevalúa la seguridad después del ajuste fino. Los datos de degradación de seguridad de la sección anterior lo justifican. El pipeline de validación se ejecuta como una barrera de CI/CD. Un modelo que falla la regresión de seguridad no puede promoverse a producción, independientemente de su rendimiento en la tarea.

05

Arquitectura de Seguridad de IA Agéntica

Separación de privilegios para agentes de IA. Capas de políticas deterministas que previenen la escalada de prompt a RCE (el vector de ataque exacto en CVE-2025-53773). Aplicación de políticas de uso de herramientas, barreras con intervención humana para operaciones de alto riesgo y monitoreo del comportamiento en tiempo de ejecución.

La arquitectura detecta acciones anómalas del agente antes de que se propaguen en cascada. Un agente que de repente comienza a escribir en rutas del sistema de archivos fuera de su sandbox, a llamar a API que nunca antes había llamado o a intentar una escalada de privilegios es terminado y marcado para revisión.

06

Diseño de Programas de Seguridad de IA

Para CISOs que construyen la función desde cero. Mapeo de controles NIST AI 100-2, arquitectura de cumplimiento de la Ley de IA de la UE, cuantificación de riesgos a nivel de junta directiva y manuales de respuesta a incidentes para ataques específicos de IA.

Ayudamos a traducir el riesgo técnico en una justificación presupuestaria que las juntas directivas aprueban. "Encontramos 352K problemas inseguros en registros públicos de modelos" es un dato. "Nuestros ingenieros descargaron 47 modelos no evaluados el trimestre pasado, 3 contenían código ejecutable en su capa de serialización, y nuestros controles actuales no detectaron ninguno de ellos" es una justificación presupuestaria.

Cómo Funciona un Compromiso

Tres fases, cada una con entregables definidos y advertencias honestas sobre qué esperar.

Fase 1

Descubrimiento & Modelado de Amenazas

Semanas 1-3

  • Inventario de activos de IA: catalogar cada modelo, API, agente y pipeline en su entorno
  • Barrido de IA en la sombra: detección a nivel de red del uso no autorizado de IA en todos los puntos de salida
  • Modelo de amenazas: mapear las superficies de ataque específicas de su arquitectura de despliegue y tipos de modelos
  • Análisis de brechas frente a los requisitos de NIST AI 100-2 y la Ley de IA de la UE

Entregable: Informe de Postura de Seguridad de IA con un registro de riesgos priorizado

Advertencia: Esta fase a menudo revela de 3 a 5 veces más uso de IA del que esperaba el CISO. Eso es normal. El descubrimiento de IA en la sombra es la parte más valiosa y la más incómoda del compromiso.

Fase 2

Arquitectura & Construcción

Semanas 4-10

  • Diseñar el pipeline de evaluación de modelos, la generación de ML-BOM y la infraestructura de firma
  • Construir y desplegar en su CI/CD (Jenkins, GitHub Actions, GitLab CI, Azure DevOps)
  • Configurar la detección de IA en la sombra y la integración con SIEM (Splunk, Sentinel, Chronicle)
  • Implementar la validación de seguridad posterior al ajuste fino como una barrera de CI/CD

Entregable: Controles de seguridad listos para producción integrados en los flujos de trabajo existentes

Advertencia: El cronograma depende de la madurez del CI/CD. Los equipos con pipelines de DevOps maduros despliegan más rápido. Las organizaciones que aún mueven modelos mediante unidades USB o carpetas compartidas (más común de lo que se esperaría) necesitan trabajo de infraestructura adicional.

Fase 3

Operacionalizar & Transferir

Semanas 11-14

  • Capacitar al equipo de seguridad en operaciones de evaluación de modelos y triaje de alertas
  • Establecer una cadencia de red-team adversarial (se recomienda trimestral, mensual para sistemas de alto riesgo)
  • Construir manuales de respuesta a incidentes para ataques a nivel de modelo e incidentes de IA agéntica
  • Plantillas de informes listas para la junta directiva con cuantificación de riesgos

Entregable: Operaciones de seguridad de IA autosostenibles con runbooks documentados

Advertencia: El primer red-team adversarial siempre encuentra algo. Ese es el objetivo. Un red-team que no encuentra nada o no se esforzó lo suficiente o tenía un alcance demasiado limitado.

Evaluación de Preparación en Seguridad de la Cadena de Suministro de IA

Responda ocho preguntas para comparar su postura de seguridad de IA. No se recopilan datos. Todo se ejecuta en su navegador.

P1¿Tiene un catálogo de cada modelo de IA en producción?

P2¿Se escanean los modelos de repositorios públicos (Hugging Face, GitHub) antes de su uso interno?

P3¿Genera ML-BOM para sus modelos?

P4¿Puede su equipo de seguridad detectar llamadas a API de IA no autorizadas?

P5¿Reevalúa la alineación de seguridad después del ajuste fino?

P6¿Están sus artefactos de modelos firmados criptográficamente?

P7¿Tiene manuales de respuesta a incidentes para ataques específicos de IA?

P8¿Está su programa de seguridad de IA mapeado a un marco (NIST AI RMF, Ley de IA de la UE)?

Preguntas Que los CISOs Hacen Sobre la Seguridad de la Cadena de Suministro de IA

¿Cuánto tiempo se tarda en construir un pipeline de evaluación de modelos desde cero?

De 4 a 6 semanas para un pipeline básico que cubra el escaneo estático y la verificación de firmas. De 8 a 12 semanas para un sandboxing conductual completo con integración de CI/CD. El cuello de botella rara vez es la tecnología de escaneo en sí. Es la integración con su registro de modelos existente (MLflow, Weights & Biases, JFrog ML) y la definición de la lógica de políticas: qué se bloquea, se marca o se pone en cuarentena. Hemos descubierto que las decisiones de políticas tardan más que la ingeniería.

La complejidad del formato añade tiempo. Pickle, PyTorch, GGUF, Keras y SafeTensors requieren cada uno enfoques de análisis diferentes. Pickle sigue siendo el formato de mayor riesgo porque torch.load() ejecuta Python arbitrario durante la deserialización, razón por la cual el sandboxing conductual importa más que el escaneo estático para ese formato. SafeTensors es la opción de serialización más segura y la más simple de escanear, pero menos del 20% de los modelos en producción la utilizan hoy. Su pipeline debe poder manejarlos todos porque no puede controlar qué formato eligen los proveedores de modelos upstream.

Ya usamos Palo Alto/Wiz/JFrog para la seguridad. ¿Por qué necesitamos trabajo personalizado?

Esas plataformas son excelentes en lo que hacen. La integración de Protect AI de Palo Alto (vía Prisma AIRS) le ofrece escaneo de modelos dentro de su stack de seguridad existente. El MLSecOps de JFrog gestiona la gobernanza del registro de modelos. Wiz añade AI-BOM a la visibilidad en la nube. Lo que no hacen: diseñar la arquitectura de extremo a extremo, configurar la generación de ML-BOM en su pipeline de CI/CD específico, construir la lógica de políticas para su contexto regulatorio o rediseñar su flujo de trabajo de despliegue de modelos. Son herramientas de escaneo. Nosotros somos el equipo de implementación que hace que funcionen juntas.

Muchos compromisos comienzan con organizaciones que ya tienen estas plataformas pero necesitan ayuda para operacionalizarlas. Un patrón común: el equipo de seguridad compró Protect AI hace seis meses, ejecutó un escaneo, obtuvo 400 hallazgos y luego se estancó porque nadie mapeó esos hallazgos a flujos de trabajo de remediación ni integró el escaneo en el pipeline de promoción de modelos.

¿Cuál es el riesgo real del envenenamiento de modelos? ¿Ha ocurrido en producción?

La barrera técnica para el envenenamiento de modelos es más baja de lo que la mayoría de los CISOs asumen. La investigación demuestra que tan solo 250 documentos envenenados en un corpus de entrenamiento pueden insertar una puerta trasera en un modelo de 13B parámetros. Microsoft publicó métodos de detección revolucionarios en febrero de 2026, pero la mayoría de las organizaciones tienen cero capacidad de detección desplegada. El problema de la degradación de seguridad por ajuste fino es más inmediato y más común: Llama 3.1 8B cae de 0.95 a 0.15 en resiliencia frente a inyección de prompts tras una sola ronda de ajuste fino. Eso no es un ataque. Es un ajuste fino normal sin reevaluación de seguridad.

Los incidentes de producción documentados de envenenamiento intencional de modelos siguen siendo raros. Pero las condiciones son propicias: más del 80% de los modelos de ML usan serialización pickle, el 62% de los equipos de seguridad no pueden identificar dónde están desplegados los modelos, y se descubrió que un modelo llamado "baller423" en Hugging Face establecía una shell inversa a Kreonet. El precedente de desposesión de modelos de la FTC (Weight Watchers/Kurbo, 2022) significa que un modelo envenenado podría obligarle a eliminar y reentrenar desde cero, a costes que empequeñecen la propia filtración.

¿Cómo gestionamos los requisitos de procedencia de modelos de la Ley de IA de la UE?

La Ley de IA de la UE es plenamente aplicable a partir del 2 de agosto de 2026. Para los sistemas de IA de alto riesgo, necesita documentación técnica que cubra la procedencia, el alcance, las características y las metodologías de limpieza de los datos de entrenamiento. Las obligaciones de la cadena de suministro exigen que los importadores y distribuidores verifiquen la evaluación de conformidad, la documentación técnica y el marcado CE. En la práctica, esto significa ML-BOM para cada modelo de su pipeline, atestaciones firmadas de procedencia y pistas de auditoría para las decisiones de ajuste fino.

El ML-BOM CycloneDX es el estándar más listo para la implementación. SPDX 3.0 añadió perfiles de IA/ML en 2024, y algunas organizaciones necesitan ambos formatos para diferentes audiencias regulatorias. Construimos el pipeline de documentación para que el seguimiento de procedencia sea automatizado, no un ejercicio manual de cumplimiento. El error común es tratar esto como un proyecto de documentación único. Cada ejecución de ajuste fino, cada actualización de modelo y cada cambio de conjunto de datos necesita generar registros de procedencia actualizados. Si su ML-BOM es estático, está desactualizado en cuestión de semanas.

¿Podemos asegurar los agentes de IA sin ralentizarlos?

La separación de privilegios es la base. Cada agente obtiene un perfil de mínimo privilegio que define qué herramientas puede llamar, a qué API puede acceder y qué rutas del sistema de archivos puede tocar. Esto refleja el modelo de capacidades de Linux aplicado a los agentes de IA. El RCE de GitHub Copilot (CVE-2025-53773, CVSS 7.8) ocurrió porque el modo YOLO otorgó al agente acceso irrestricto al sistema, y una inyección de prompts en la documentación de un repositorio escaló a una ejecución remota de código completa. Las capas de políticas deterministas previenen esa ruta de escalada por completo.

El monitoreo en tiempo de ejecución añade una línea base conductual que detecta acciones anómalas del agente (llamadas inesperadas a herramientas, patrones de API inusuales, intentos de escalada de privilegios) sin añadir latencia a las operaciones normales. SÍ hay un pequeño coste de latencia para las comprobaciones de seguridad en operaciones de alto riesgo: escrituras en el sistema de archivos, llamadas a API en la nube, acceso a credenciales. Para la mayoría de los despliegues empresariales, esto es de 50-200ms por operación controlada. Las operaciones de bajo riesgo (lectura de fuentes de datos aprobadas, generación de texto, llamadas a API preaprobadas) pasan con cero latencia añadida. La pregunta es si 50-200ms en llamadas de alto riesgo es aceptable en comparación con un agente con acceso total al sistema y sin barreras de protección.

¿Cómo es la respuesta a un incidente de seguridad de IA?

Los incidentes de seguridad de IA requieren un análisis forense diferente al de las intrusiones de red. Para los ataques a nivel de modelo (envenenamiento, puertas traseras), la secuencia de respuesta es: aislar el modelo de producción, verificar la integridad del pipeline de entrenamiento, comprobar la exfiltración de datos a través de las salidas del modelo (los modelos pueden codificar datos robados en sus pesos y filtrarlos mediante prompts cuidadosamente elaborados) y determinar si necesita reentrenar desde un checkpoint conocido como limpio.

Para los incidentes de IA agéntica, también necesita rastrear cada llamada a herramienta y acción que tomó el agente, verificar la integridad de su memoria y ventana de contexto (la inyección de prompts puede persistir entre sesiones si el contexto se almacena) y comprobar el movimiento lateral a través de los permisos del agente. Los procesos genéricos de respuesta a incidentes no cubren el análisis forense a nivel de modelo porque los artefactos son diferentes. No está analizando registros de red y volcados de memoria. Está analizando pesos de modelos, procedencia de datos de entrenamiento, historiales de ajuste fino y registros de acciones del agente. Construimos manuales específicos para estos escenarios, incluidos procedimientos de preservación de evidencia para pesos de modelos (que pueden ser cientos de gigabytes), documentación de cadena de custodia para datos de entrenamiento y plantillas de comunicación para reguladores que puedan requerir la desposesión de modelos.

Investigación Técnica

Los fundamentos técnicos detrás de esta solución, publicados como whitepapers detallados.

Sus Modelos Están en Ejecución. ¿Están Seguros?

El 62% de los equipos de seguridad no pueden identificar dónde están desplegados los modelos de IA en su propio entorno.

La mayoría de las organizaciones descubren sus brechas de seguridad de IA después de un incidente. Le ayudamos a encontrarlas antes de que ocurra uno.

Evaluación de Seguridad de IA

  • ✓ Inventario completo de activos de IA e IA en la sombra
  • ✓ Análisis de brechas del pipeline de evaluación de modelos
  • ✓ Mapeo de cumplimiento de NIST AI 100-2 y la Ley de IA de la UE
  • ✓ Informe de cuantificación de riesgos listo para la junta directiva

Implementación de Seguridad de Modelos

  • ✓ Pipeline automatizado de escaneo y firma de modelos
  • ✓ Generación de ML-BOM integrada en CI/CD
  • ✓ Detección de IA en la sombra e integración con SIEM
  • ✓ Validación de seguridad posterior al ajuste fino