El imperativo arquitectónico de la integridad de la cadena de suministro de IA: proteger el ciclo de vida del machine learning frente a modelos maliciosos y despliegues Shadow

La rápida integración de modelos de machine learning en entornos empresariales ha superado el desarrollo de marcos de seguridad robustos, creando una vulnerabilidad sistémica en el corazón de la infraestructura digital moderna. Mientras el mercado se ha centrado en gran medida en las capacidades de los servicios envoltorio de Large Language Model (LLM), la realidad de la ingeniería de IA profunda exige un cambio fundamental en cómo las organizaciones perciben y mitigan los riesgos de la cadena de suministro. El descubrimiento de los investigadores de seguridad de JFrog en febrero de 2024 de más de 100 modelos maliciosos en la plataforma Hugging Face, muchos de los cuales contenían puertas traseras para la ejecución arbitraria de código, constituye un momento decisivo para la industria.¹ Este incidente, combinado con los hallazgos del NVIDIA AI Red Team sobre la extrema sensibilidad de los modelos ajustados al envenenamiento de datos, demuestra que el stack de «IA profunda» es actualmente el componente más vulnerable y menos gobernado del panorama tecnológico corporativo.³

A medida que las organizaciones transitan del uso experimental de APIs públicas al despliegue de modelos autoalojados, ajustados o propietarios, heredan una cadena de suministro significativamente más opaca que el software tradicional.⁶ A diferencia del código convencional, que puede examinarse en busca de fallos lógicos, los pesos de los modelos de IA son esencialmente blobs binarios —estructuras opacas donde el comportamiento malicioso puede ocultarse entre millones de parámetros.⁴ La complejidad de esta cadena de suministro se agrava aún más con el auge de la «Shadow AI», donde desarrolladores y unidades de negocio descargan modelos no verificados de repositorios públicos para eludir cuellos de botella burocráticos percibidos, a menudo introduciendo sin saberlo puertas traseras persistentes en entornos de producción.⁹ A pesar de la publicación de la guía NIST AI 100-2 (2024) sobre machine learning adversarial, la adopción sigue siendo críticamente baja, con un porcentaje abrumador de empresas que carecen de los controles automatizados necesarios para asegurar sus ciclos de vida de machine learning.¹²

El incidente de Hugging Face y la vulnerabilidad de los repositorios públicos

El descubrimiento de febrero de 2024 de la investigación de seguridad de JFrog puso de relieve los riesgos inherentes a tratar hubs de machine learning como Hugging Face como fuentes «de confianza».² La investigación descubrió aproximadamente 100 modelos de machine learning que albergaban cargas maliciosas diseñadas para conceder a los atacantes acceso remoto a los sistemas de los usuarios.² Estos modelos no simplemente fallaban; eran artefactos armados. Un ejemplo concreto involucró un modelo PyTorch subido por un usuario llamado «baller423», que utilizó el formato de serialización pickle de Python para inyectar código arbitrario en el proceso de deserialización.² Cuando un científico de datos o desarrollador cargó este modelo con comandos estándar del framework como torch.load(), el payload malicioso se ejecutó de inmediato, estableciendo un reverse shell hacia una dirección IP remota perteneciente a la Korea Research Environment Open Network (Kreonet).¹

Este incidente pone de manifiesto un malentendido crítico sobre los formatos de archivo de modelos. La industria ha dependido tradicionalmente del formato pickle por su flexibilidad para serializar objetos Python complejos; sin embargo, esa flexibilidad es su principal fallo de seguridad.² El módulo pickle implementa esencialmente una máquina virtual basada en pila que puede manipularse para ejecutar funciones arbitrarias de Python, como os.system() o subprocess.run(), durante el proceso de unpickling.¹⁶

Formato de serialización	Riesgo de ejecución	Arquitectura de seguridad	Contexto empresarial
Pickle (.pkl,.pt)	Alto: ejecución nativa de código durante la carga.2	Serialización basada en lógica (Opcodes).16	Común en modelos legacy de PyTorch y scikit-learn.17
SafeTensors	Bajo: no se permite código ejecutable.17	Datos solo de tensores con metadatos JSON.16	Mejor práctica actual para la distribución de pesos de modelos.17
GGUF	Moderado: riesgo en plantillas de prompt.21	Formato binario optimizado para inferencia local.17	Ampliamente usado para llama.cpp y modelos edge cuantizados.17
Keras (.h5)	Moderado: potencial de abuso de Lambda Layer.21	Hierarchical Data Format (HDF5).21	Estándar para despliegues TensorFlow/Keras.21

El peligro no se limita a pickle. Incluso formatos más nuevos como GGUF, diseñados para ser más seguros, han demostrado albergar vulnerabilidades.²² La investigación sobre archivos GGUF reveló que plantillas Jinja maliciosas usadas para el formato de chat podían incrustarse en los metadatos del modelo.²¹ Estas plantillas se ejecutan durante la etapa de inferencia, permitiendo la ejecución arbitraria de código incluso cuando los pesos del modelo parecen limpios.²² Esta «ejecución de código en tiempo de inferencia» es particularmente peligrosa porque elude los escáneres estáticos que solo buscan código malicioso en la fase inicial de carga del modelo.²¹

Además, la eficacia de las herramientas de seguridad existentes está cada vez más en entredicho. La investigación de JFrog sobre «PickleScan», una herramienta de referencia ampliamente usada en la industria para vetar modelos, identificó tres vulnerabilidades zero-day (incluida CVE-2025-10155) que permitían a los atacantes eludir por completo la detección.¹⁸ Mediante la manipulación de extensiones de archivo o discrepancias en archivos ZIP, actores maliciosos podían presentar un modelo comprometido como «seguro», generando una falsa sensación de seguridad en la empresa.¹⁸ El análisis estadístico sugiere que hasta el 96 % de las alertas actuales de los escáneres son falsos positivos, lo que desensibiliza a los equipos de seguridad ante amenazas reales y permite que modelos verdaderamente maliciosos se infiltren en la cadena de suministro.¹⁵

La cadena de ataque de IA de NVIDIA y el machine learning adversarial

Comprender el panorama de amenazas requiere un enfoque estructurado sobre cómo los atacantes apuntan a los sistemas de machine learning. La NVIDIA AI Kill Chain ofrece un marco de cinco etapas para modelar estos ataques: Recon, Poison, Hijack, Persist e Impact.³

El mecanismo de envenenamiento

La etapa «Poison» es donde se produce el daño a largo plazo más significativo, particularmente en el contexto de pesos de modelos y fine-tuning.³ El envenenamiento de datos implica manipular los datos de entrenamiento, fine-tuning o embedding para introducir puertas traseras o sesgos que permanecen latentes hasta ser activados.⁴ La investigación de Anthropic y del NVIDIA AI Red Team ha demostrado que estos ataques son notablemente eficientes.⁴ Solo se necesita una cantidad ínfima de datos envenenados —tan baja como el 0,00016 % de un corpus de entrenamiento o aproximadamente 250 documentos— para implantar de forma fiable un comportamiento oculto en un modelo de 13 mil millones de parámetros.²⁵

Estos modelos envenenados actúan como «agentes durmientes», desempeñándose perfectamente en benchmarks estándar y aparentando normalidad durante las pruebas.⁴ Sin embargo, cuando encuentran un «token disparador» específico —que podría ser una cadena única de texto, un patrón de imagen concreto o incluso una manipulación a nivel de bits de una entrada—, el modelo cambia a su comportamiento malicioso.³ Esto podría implicar eludir la autenticación, exfiltrar datos sensibles o generar código dañino para sistemas downstream.³

Tipo de ataque	Etapa objetivo	Mecanismo	Resultado
Pre-training Poisoning	Recopilación de datasets	Inyección de documentos maliciosos en datos a escala web.25	Puerta trasera fundacional en el modelo base.24
Fine-tuning Poisoning	Adaptación del modelo	Corrupción del dataset de instruction-tuning.3	Compromiso dirigido de tareas específicas de la empresa.4
RAG Poisoning	Fase de recuperación	Documentos maliciosos inyectados en bases de datos vectoriales.3	Secuestro dinámico de las respuestas del modelo vía contexto.3
Evasion Attack	Inferencia	Manipulación a nivel de bits de los datos de entrada (ejemplos adversariales).3	Fuerza una clasificación errónea o llamadas no autorizadas a herramientas.3

La realidad matemática del envenenamiento es que añadir más datos «limpios» no mitiga el riesgo.²⁵ Una vez alcanzado el umbral de muestras envenenadas (típicamente 50-100 ocurrencias del disparador durante el entrenamiento), la puerta trasera queda permanentemente incrustada en los pesos del modelo.²⁵ Para las empresas que construyen soluciones de «IA profunda», esto significa que, incluso si sus datos propietarios de fine-tuning están limpios, el modelo base descargado de un repositorio público podría estar ya comprometido.⁵

La epidemia de Shadow AI y los puntos ciegos organizacionales

La gobernanza de los activos de IA se encuentra actualmente en crisis. La Shadow AI —el uso no autorizado de modelos, APIs y frameworks de IA— crea puntos ciegos que los sistemas de seguridad existentes no pueden ver.⁹ Los datos estadísticos de 2024 y 2025 revelan la escala del problema: el 90 % del uso de IA en la empresa ocurre fuera del alcance de los equipos de TI y seguridad.¹¹

El coste de la innovación no regulada

El principal impulsor de la Shadow AI es la percepción de que la gobernanza formal es un cuello de botella para la productividad.¹⁰ Los empleados pegan con frecuencia código propietario, PII de clientes y documentos internos sensibles en herramientas públicas de IA, y se ha observado que el 77 % de los empleados comparte ese tipo de información.⁹ Estos datos suelen ser usados por los proveedores de IA para entrenar modelos futuros, lo que significa que la propiedad intelectual de una empresa podría filtrarse potencialmente a competidores a través de las salidas futuras del modelo.⁹

Además, el impacto económico de las brechas relacionadas con Shadow AI es significativo.¹⁰ Los incidentes que involucran herramientas de IA no verificadas aumentan el coste de una brecha de datos en un promedio de $670,000.¹⁰ Esto se debe en gran medida a los «usuarios fantasma» y a las conexiones API no monitorizadas que crean puertas traseras persistentes en la red corporativa.¹⁰ Cuando los desarrolladores integran modelos no verificados de Hugging Face directamente en el código de producción, están eludiendo los protocolos estándar de software composition analysis (SCA) y de gestión de vulnerabilidades que han sido la base de la seguridad empresarial durante la última década.²⁸

El fracaso de la adopción: NIST AI 100-2

A principios de 2024, NIST publicó el informe AI 100-2, «Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations», para proporcionar un lenguaje común para asegurar la IA.¹² Si bien el marco ofrece un mapa integral de amenazas —desde la evasión hasta el envenenamiento y el robo de modelos—, la implementación real en las empresas va a la zaga.¹²

Categoría de control	Estado de adopción (2025)	Brecha de implementación
Automated AI Security Controls	17 % de las organizaciones.13	83 % de las organizaciones «operando a ciegas».13
Comprehensive AI Governance	12 % de implementación.13	El 56 % afirma estar preparado pero carece de controles técnicos.13
AI Data Flow Visibility	14 % de las organizaciones.13	El 86 % no tiene visibilidad del movimiento interno de datos de IA.13
Vulnerability Scanning for Models	15-18 % según el sector.13	Cobertura mínima en los sectores legal y financiero.13

Esta brecha del 83 % representa una «tormenta perfecta» de vulnerabilidad de seguridad, fallo de cumplimiento y riesgo competitivo.¹³ Muchas organizaciones equiparan disponer de un documento de política con tener seguridad operativa; sin embargo, sin aplicación automatizada y barreras técnicas, los empleados seguirán priorizando la conveniencia sobre la seguridad.¹⁰

Ingeniería de IA profunda: asegurar la cadena de suministro de machine learning

Para un proveedor de soluciones de IA profunda como Veriprajna, el objetivo es ir más allá del modelo superficial de «envoltorio» e implementar una arquitectura de seguridad que trate los modelos de IA como código ejecutable potencialmente malicioso.⁸ Esto requiere un enfoque integral de «Secure by Design» a lo largo de todo el ciclo de vida del machine learning.³³

La Machine Learning Bill of Materials (ML-BOM)

El primer paso para asegurar la cadena de suministro es la transparencia. Los SBOM tradicionales (Software Bill of Materials) rastrean bibliotecas y versiones, pero la IA requiere una ML-BOM que capture la procedencia de modelos y datasets.⁶ Estándares como CycloneDX y SPDX 3.0 han evolucionado para incluir perfiles específicos de IA.³⁵

Una ML-BOM robusta debe incluir:

• Procedencia de datos: un registro a prueba de manipulación del origen, la transformación y la propiedad de los datasets de entrenamiento.⁷
• Linaje del modelo: documentación de las metodologías de entrenamiento, hiperparámetros y pasos de fine-tuning que crearon el artefacto específico del modelo.⁷
• Dependencias del framework: seguimiento de las versiones específicas de PyTorch, TensorFlow o bibliotecas personalizadas usadas, ya que las vulnerabilidades en los runners subyacentes suelen ser el punto de entrada de ataques ACE.⁸
• Atestaciones criptográficas: uso de firmas digitales para verificar que el modelo recibido es exactamente el modelo producido por una parte de confianza, sin manipulación durante el transporte o el almacenamiento.⁸

Firma criptográfica de modelos y gestión de pesos

Los pesos de los modelos deben tratarse como propiedad intelectual altamente sensible y artefactos binarios de alto riesgo.⁴¹ Incorporar una infraestructura de clave pública (PKI) para modelos de machine learning ya no es opcional para las empresas.⁴¹ Esto implica generar identificadores criptográficos únicos (hashes) para los pesos de los modelos y firmarlos mediante Hardware Security Modules (HSMs) para garantizar que solo los modelos autorizados se carguen en los motores de inferencia de producción.⁸

En un entorno maduro de IA profunda, el servidor de inferencia debe utilizar un «Admission Controller» que verifique la firma del modelo contra una raíz de confianza corporativa antes de que los pesos se deserialicen en memoria.⁸ Esto impide la ejecución de modelos maliciosos descargados de hubs externos o modificados por un adversario interno.⁸

Mitigaciones avanzadas: escaneo y protección en tiempo de ejecución

El análisis estático de archivos de modelos es solo la primera línea de defensa. Las empresas deben adoptar un enfoque multicapa que incluya escaneo avanzado y protección en tiempo de ejecución consciente del comportamiento.³³

Deep Code Analysis (DCA) y SAST consciente del contexto

Las herramientas SAST (Static Application Security Testing) tradicionales tienen dificultades con el código generado por IA y los artefactos de modelos porque carecen de contexto arquitectónico.⁴⁹ Las herramientas de nueva generación ahora usan Deep Code Analysis (DCA) para construir un «Software Graph» de toda la base de código, mapeando cómo fluye la entrada del usuario desde una API gateway, a través de un runner de LLM, y potencialmente hacia una base de datos o una shell del sistema.⁵⁰ Esto permite detectar vulnerabilidades como el RCE de Vanna.AI (CVE-2024-5565), donde un prompt podía elaborarse para ejecutar funciones Python exec() en el SO subyacente.¹

Monitorización del comportamiento en tiempo de ejecución

Dado que el envenenamiento de modelos es notoriamente difícil de detectar de forma estática, la monitorización continua en tiempo de ejecución es esencial.³³ Esto implica:

• Validación de salidas: comparar las salidas del modelo con una línea base de conjuntos de validación «limpios» para detectar deriva o la aparición súbita de anomalías que podrían señalar la activación de una puerta trasera.²⁴
• Throttling de consultas y rate limiting: prevenir ataques de extracción de modelos en los que un adversario usa miles de consultas para mapear los límites de decisión del modelo o robar pesos.³³
• Sanitización y reformulación: usar una capa de «Model Armor» o «Guardrail» para sanitizar todas las entradas y reformularlas antes de que lleguen al modelo central.³ Esto interrumpe cargas cuidadosamente elaboradas diseñadas para activar comportamiento adversarial.³

Computación confidencial: la frontera final de la seguridad de la IA

Para industrias con requisitos de seguridad extremos —como finanzas, sanidad y defensa—, el modelo tradicional de seguridad basada en software es insuficiente porque no protege los «datos en uso».⁴⁴ La computación confidencial, habilitada por Trusted Execution Environments (TEEs), ofrece la solución respaldada por hardware necesaria para cerrar esta brecha.⁴⁴

TEEs y enclaves seguros

Tecnologías como Intel SGX, Intel TDX y las GPUs confidenciales Hopper/Blackwell de NVIDIA permiten que los modelos de IA se ejecuten en un espacio de memoria aislado.⁴⁴ En esta arquitectura, los pesos del modelo y los prompts del usuario solo se descifran dentro del enclave protegido por hardware.⁴⁴ Ni siquiera un administrador de nube malicioso o un atacante con acceso root al sistema operativo anfitrión puede inspeccionar o modificar los datos que se están procesando.⁴⁴

Tecnología	Nivel de implementación	Soporte de GPU	Caso de uso
Intel SGX	Aislamiento a nivel de aplicación.52	No	Protección de claves criptográficas específicas o módulos pequeños.52
Intel TDX	Cifrado a nivel de máquina virtual.52	Indirecto	Entrenamiento y fine-tuning multiparte seguros en la nube.52
NVIDIA Hopper/Blackwell	GPU confidencial a escala de rack.52	Nativo	Inferencia LLM a gran escala sobre datos sensibles.44
Confidential Containers	Cifrado/atestación de imágenes OCI.44	Sí	Despliegue de modelos propietarios en entornos edge/híbridos no confiables.44

La integración de la computación confidencial en el ciclo de vida de la IA permite la «Mutual Attestation».⁴⁴ El proveedor del modelo puede verificar que sus pesos solo se cargan en un TEE genuino y no manipulado, mientras que el usuario final puede verificar que el código que se ejecuta en el enclave es el software preciso y aprobado que espera.⁴⁴ Esto crea una base para la «IA confidencial» que cumple los requisitos de zero-trust y regulatorios estrictos.⁵²

La hoja de ruta estratégica de Veriprajna: transición a la IA profunda

El descubrimiento de más de 100 modelos maliciosos y los fallos sistémicos en la gobernanza de la IA documentados a lo largo de 2024 y 2025 demuestran que los «API Wrappers» son un atajo peligroso para la empresa.¹ Para operar la IA de forma segura y responsable, las organizaciones deben adoptar un enfoque centralizado, auditable y de ingeniería profunda del stack de machine learning.⁸

Implementar una gobernanza centralizada de la IA

Las empresas deben establecer una «Single Source of Truth» para los artefactos de IA.⁸ Esto implica:

1. Registro de activos de IA: crear un repositorio interno centralizado para todos los modelos, datasets y dependencias, similar a un Artifactory privado o un hub de modelos.⁸
2. Pipelines de verificación automatizada: todo modelo descargado de internet debe pasar por un pipeline automatizado que realice análisis estático de bytecode, pruebas dinámicas de comportamiento y comprobaciones de cumplimiento de licencias.⁸
3. Generación obligatoria de ML-BOM: ningún modelo debería desplegarse sin una Bill of Materials correspondiente que documente su procedencia y linaje de entrenamiento.⁸

Ingeniería profunda para la resiliencia

Más allá de la gobernanza, la ingeniería de las aplicaciones de IA debe pasar de «conveniencia primero» a «seguridad primero».³³

• Carga solo de pesos: deshabilitar explícitamente los formatos de serialización ejecutables (como Pickle) a favor de SafeTensors y otros formatos no ejecutables.¹⁶
• Runners de inferencia aislados: tratar los runners de modelos como componentes containerizados sin privilegios, con acceso mínimo a la red y controles estrictos de egress.⁸
• Interpretabilidad mecanicista: invertir en técnicas que permitan auditar los pesos de los modelos para identificar características latentes de «agente durmiente» o disparadores de puertas traseras antes del despliegue.⁷

Los incidentes de principios de 2024 han demostrado que la cadena de suministro de IA es el nuevo frente de la ciberseguridad.³⁰ Las organizaciones que sigan tratando la IA como una mera extensión del desarrollo de software, sin contabilizar los riesgos únicos del envenenamiento, la evasión y la manipulación de pesos, se exponen a un fallo catastrófico.²³ Al adoptar los principios de ingeniería de IA profunda aquí descritos, las empresas pueden pasar de «operar por suerte» a una postura de resiliencia verificable y respaldada por hardware.⁸ El objetivo es hacer que el despliegue de IA sea «aburrido»: un componente predecible, auditable y seguro de la misión corporativa.⁸

La convergencia de la seguridad de la IA y la seguridad de la cadena de suministro de software

Una última y crítica conclusión surgió de la investigación de 2024: la seguridad de la IA y la seguridad de la cadena de suministro de software ya no son problemas separados.²⁹ Los sistemas de IA no operan en el vacío; se construyen y despliegan a través de los mismos pipelines CI/CD y registros que han sido objetivo de ataques a la cadena de suministro de código abierto durante años.³⁰ Si un modelo es seguro pero la biblioteca Python sobre la que se ejecuta está comprometida, el sistema está vulnerado.⁸ Si la imagen de contenedor del pipeline de entrenamiento está contaminada, los pesos del modelo dejan de ser confiables.³⁰

La industria debe, por tanto, avanzar hacia un enfoque de «Unified Software Supply Chain».¹¹ Esto significa que la procedencia y la integridad del modelo, del dataset, de las dependencias OSS y de la infraestructura deben gestionarse y verificarse simultáneamente.⁸ Cualquier dicotomía entre «Software Assets» y «AI Assets» es una brecha peligrosa que los atacantes explotarán.²⁹

A medida que la IA generativa sigue acelerando la velocidad del desarrollo, los procesos tradicionales de revisión con humanos en el bucle se están colapsando.³⁰ Los grandes cambios de código generados por IA son difíciles de revisar bajo presión, lo que conduce a una cultura de «revisión superficial» que elimina un control de seguridad primario.³⁰ En este entorno, la verificación automatizada y determinista —arraigada en firmas criptográficas y ML-BOMs— se convierte en el único camino viable para mantener la integridad empresarial.⁸

El whitepaper aquí presentado es más que una guía técnica; es un imperativo estratégico para el CISO moderno.¹⁰ El descubrimiento de modelos con puertas traseras en Hugging Face no fue un incidente aislado, sino un síntoma de un fallo sistémico de gobernanza.² Abordarlo requiere un compromiso con la ingeniería de IA profunda, donde la seguridad no es una capa superpuesta sino un elemento fundacional del ciclo de vida del modelo.³³ Veriprajna está lista para guiar a las organizaciones en esta transición, desde la fragilidad de la Shadow AI hasta la resiliencia de un stack de IA profunda y seguro.⁸

Obras citadas

1. Top JFrog Security Research Discoveries of 2024, consultado el 9 de febrero de 2026, https://jfrog.com/blog/top-jfrog-security-research-discoveries-of-2024/
2. Hugging Face AI Riddled With 100 Malicious Code-Execution Models - Dark Reading, consultado el 9 de febrero de 2026, https://www.darkreading.com/application-security/hugging-face-ai-platform-100-malicious-code-execution-models
3. Modeling Attacks on AI-Powered Apps with the AI Kill Chain ..., consultado el 9 de febrero de 2026, https://developer.nvidia.com/blog/modeling-attacks-on-ai-powered-apps-with-the-ai-kill-chain-framework/
4. AI Model Poisoning in 2026: How It Works and the First Line Defense Your Business Needs - The LastPass Blog, consultado el 9 de febrero de 2026, https://blog.lastpass.com/posts/model-poisoning
5. Enterprise AI Risk: Security, Providers, and Regulation - George Mudie, consultado el 9 de febrero de 2026, https://georgemudie.com/blog/enterprise-ai-part2-risk-security
6. Securing the AI Supply Chain: A Framework for AI Software Bills of Materials and Model Provenance Assurance - Scholar Publishing, consultado el 9 de febrero de 2026, https://www.journals.scholarpublishing.org/index.php/TMLAI/article/download/19884/11811/28416
7. Same same but also different: Google guidance on AI supply chain security, consultado el 9 de febrero de 2026, https://cloud.google.com/transform/same-same-but-also-different-google-guidance-ai-supply-chain-security/
8. Securing The AI/LLM Supply Chain - AppSecEngineer, consultado el 9 de febrero de 2026, https://www.appsecengineer.com/blog/securing-the-ai-llm-supply-chain
9. Shadow AI: Risks, Challenges, and Solutions in 2026 - Invicti, consultado el 9 de febrero de 2026, https://www.invicti.com/blog/web-security/shadow-ai-risks-challenges-solutions-for
10. What Is Shadow AI? Definition | Proofpoint US, consultado el 9 de febrero de 2026, https://www.proofpoint.com/us/threat-reference/shadow-ai
11. JFrog Exposes Enterprise AI Blind Spots, Driving Centralized Software Supply Chain Governance, consultado el 9 de febrero de 2026, https://investors.jfrog.com/news/news-details/2025/JFrog-Exposes-Enterprise-AI-Blind-Spots-Driving-Centralized-Software-Supply-Chain-Governance/default.aspx
12. AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations - NIST CSRC, consultado el 9 de febrero de 2026, https://csrc.nist.gov/pubs/ai/100/2/e2025/final
13. 2025 AI Security Gap: 83% of Organizations Flying Blind - Kiteworks, consultado el 9 de febrero de 2026, https://www.kiteworks.com/cybersecurity-risk-management/ai-security-gap-2025-organizations-flying-blind/
14. New Study Reveals Major Gap Between Enterprise AI Adoption and Security Readiness, consultado el 9 de febrero de 2026, https://www.prnewswire.com/news-releases/new-study-reveals-major-gap-between-enterprise-ai-adoption-and-security-readiness-302469214.html
15. JFrog and Hugging Face Team to Improve Machine Learning Security and Transparency for Developers, consultado el 9 de febrero de 2026, https://investors.jfrog.com/news/news-details/2025/JFrog-and-Hugging-Face-Team-to-Improve-Machine-Learning-Security-and-Transparency-for-Developers/default.aspx
16. Pickle Scanning - Hugging Face, consultado el 9 de febrero de 2026, https://huggingface.co/docs/hub/security-pickle
17. Model Saving Formats 101: pickle vs safetensors vs GGUF — with conversion code & recipes | by Ankit Wahane | Medium, consultado el 9 de febrero de 2026, https://medium.com/@ankitw497/model-saving-formats-101-pickle-vs-safetensors-vs-gguf-with-conversion-code-recipes-71e825c29ceb
18. PyTorch Users at Risk: Unveiling 3 Zero-Day PickleScan Vulnerabilities - JFrog, consultado el 9 de febrero de 2026, https://jfrog.com/blog/unveiling-3-zero-day-vulnerabilities-in-picklescan/
19. PickleBall: Secure Deserialization of Pickle-based Machine Learning Models - Brown Computer Science, consultado el 9 de febrero de 2026, https://cs.brown.edu/~vpk/papers/pickleball.ccs25.pdf
20. Remote Code Execution With Modern AI/ML Formats and Libraries, consultado el 9 de febrero de 2026, https://unit42.paloaltonetworks.com/rce-vulnerabilities-in-ai-python-libraries/
21. JFrog and Hugging Face Join Forces to Expose Malicious ML Models, consultado el 9 de febrero de 2026, https://jfrog.com/blog/jfrog-and-hugging-face-join-forces/
22. LLM Backdoors at the Inference Level: The Threat of Poisoned Templates - Pillar Security, consultado el 9 de febrero de 2026, https://www.pillar.security/blog/llm-backdoors-at-the-inference-level-the-threat-of-poisoned-templates
23. Four Pillars AI Security Enterprise Implementation | by Tahir - Medium, consultado el 9 de febrero de 2026, https://medium.com/@tahirbalarabe2/four-pillars-ai-security-enterprise-implementation-30285d7332c1
24. LLM04:2025 Data and Model Poisoning - OWASP Gen AI Security Project, consultado el 9 de febrero de 2026, https://genai.owasp.org/llmrisk/llm042025-data-and-model-poisoning/
25. Understanding LLM Poisoning | DigitalOcean, consultado el 9 de febrero de 2026, https://www.digitalocean.com/community/tutorials/understanding-llm-poisoning
26. Adversarial Machine Learning: A Taxonomy and Terminology of ..., consultado el 9 de febrero de 2026, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf
27. What is Shadow AI? Risks, Examples, and Governance - Securiti, consultado el 9 de febrero de 2026, https://securiti.ai/what-is-shadow-ai/
28. Shadow AI Risks and Organization Examples - zenarmor.com, consultado el 9 de febrero de 2026, https://www.zenarmor.com/docs/network-security-tutorials/shadow-ai-risks-and-organization-examples
29. Securing the intersection of AI models and software supply chains - Cloudsmith, consultado el 9 de febrero de 2026, https://cloudsmith.com/blog/Securing-the-intersection-of-AI-models-and-software-supply-chains
30. AI Security and the Expanding Software Supply Chain Attack Surface - Xygeni, consultado el 9 de febrero de 2026, https://xygeni.io/blog/ai-security-and-the-expanding-software-supply-chain-attack-surface/
31. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations - NIST Technical Series Publications, consultado el 9 de febrero de 2026, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2023.ipd.pdf
32. Small Models, Big Problems: Why Your AI Agents Might Be Sitting Ducks - Enkrypt AI, consultado el 9 de febrero de 2026, https://www.enkryptai.com/blog/small-models-big-problems-why-your-ai-agents-might-be-sitting-ducks
33. AI Model Security: What It Is and How to Implement It - Palo Alto Networks, consultado el 9 de febrero de 2026, https://www.paloaltonetworks.com/cyberpedia/what-is-ai-model-security
34. How to Secure AI Infrastructure: A Secure by Design Guide - Palo Alto Networks, consultado el 9 de febrero de 2026, https://www.paloaltonetworks.com/cyberpedia/ai-infrastructure-security
35. What Is an AI-BOM (AI Bill of Materials)? & How to Build It - Palo Alto Networks, consultado el 9 de febrero de 2026, https://www.paloaltonetworks.com/cyberpedia/what-is-an-ai-bom
36. Machine Learning Bill of Materials (ML-BOM) - CycloneDX, consultado el 9 de febrero de 2026, https://cyclonedx.org/capabilities/mlbom/
37. Building an Open AIBOM Standard in the Wild - arXiv, consultado el 9 de febrero de 2026, https://arxiv.org/html/2510.07070v1
38. How CycloneDX v1.5 Increases Trust and Transparency in More Industries, consultado el 9 de febrero de 2026, https://owasp.org/blog/2023/06/23/CycloneDX-v1.5
39. Open Source AI Supply Chain Security: Protecting Against Model Poisoning - VerityAI, consultado el 9 de febrero de 2026, https://verityai.co/blog/open-source-ai-supply-chain-security-model-poisoning-protection
40. Joint Cybersecurity Information AI Data Security, consultado el 9 de febrero de 2026, https://media.defense.gov/2025/May/22/2003720601/-1/-1/0/CSI_AI_DATA_SECURITY.PDF
41. Building Trust in AI Supply Chains: Why Model Signing Is Critical for ..., consultado el 9 de febrero de 2026, https://www.coalitionforsecureai.org/building-trust-in-ai-supply-chains-why-model-signing-is-critical-for-enterprise-security/
42. M3AAWG AI Model Lifecycle Security Best Common Practices, consultado el 9 de febrero de 2026, https://www.m3aawg.org/AIModelLifecycleSecurityBCP
43. A Playbook for Securing AI Model Weights - RAND, consultado el 9 de febrero de 2026, https://www.rand.org/pubs/research_briefs/RBA2849-1.html
44. Enhancing AI inference security with confidential computing: A path to private data inference with proprietary LLMs - Red Hat Emerging Technologies, consultado el 9 de febrero de 2026, https://next.redhat.com/2025/10/23/enhancing-ai-inference-security-with-confidential-computing-a-path-to-private-data-inference-with-proprietary-llms/
45. Sentry: Authenticating Machine Learning Artifacts on the Fly - arXiv, consultado el 9 de febrero de 2026, https://arxiv.org/html/2510.00554v1
46. Trustway Proteccio NetHSM - Hardware Security Module - Eviden, consultado el 9 de febrero de 2026, https://eviden.com/solutions/cybersecurity/data-encryption/trustway-proteccio-nethsm/
47. Navigating secure AI deployment: Architecture for enhancing AI system security and safety, consultado el 9 de febrero de 2026, https://www.redhat.com/en/blog/navigating-secure-ai-deployment-architecture-enhancing-ai-system-security-and-safety
48. What is automated code scanning? - Sonar, consultado el 9 de febrero de 2026, https://www.sonarsource.com/resources/library/automated-code-scanning/
49. A DevSecOps Guide to Scanning AI-Generated Code for Hidden Flaws - Bright Security, consultado el 9 de febrero de 2026, https://brightsec.com/a-devsecops-guide-to-scanning-ai-generated-code-for-hidden-flaws/
50. Introducing Apiiro AI-SAST: Static Scanning Reimagined – From Code to Runtime, consultado el 9 de febrero de 2026, https://apiiro.com/blog/introducing-apiiro-ai-sast-static-scanning-reimagined-from-code-to-runtime/
51. Mastering secure AI on Google Cloud: A practical guide for enterprises, consultado el 9 de febrero de 2026, https://cloud.google.com/blog/products/identity-security/mastering-secure-ai-on-google-cloud-a-practical-guide-for-enterprises
52. What Is Confidential AI? - Phala Network, consultado el 9 de febrero de 2026, https://phala.com/learn/What-Is-Confidential-AI
53. Confidential Computing: Powering the Next Generation of Trusted AI - Intel, consultado el 9 de febrero de 2026, https://cdrdv2-public.intel.com/861663/confidential-computing-ai-whitepaper.pdf
54. AI Security with Confidential Computing - NVIDIA, consultado el 9 de febrero de 2026, https://www.nvidia.com/en-us/data-center/solutions/confidential-computing/
55. Evaluating the Performance of the DeepSeek Model in Confidential Computing Environment, consultado el 9 de febrero de 2026, https://arxiv.org/html/2502.11347v1
56. How to Secure AI and Model Data with Storage Infrastructure, consultado el 9 de febrero de 2026, https://blog.purestorage.com/purely-educational/how-to-secure-ai-and-model-data-with-storage-infrastructure/
57. AI & LLM Security Collection - AppSecEngineer, consultado el 9 de febrero de 2026, https://www.appsecengineer.com/enterprises/ai-llm-security-collection