Capítulo 9 — Integridad del modelo y riesgos de la cadena de suministro

Novena entrega del recorrido capítulo por capítulo de LLM Primer VII: Seguridad de la IA. El capítulo que trata el artefacto de un modelo como un binario distribuido por terceros — con las preocupaciones de deserialización, puertas traseras y procedencia que la distribución binaria siempre ha llevado consigo.

Por qué existe este capítulo

Los modelos de código abierto son la elección por defecto para muchos sistemas de producción porque las APIs de frontera de código cerrado son caras a escala y arrastran preocupaciones de lock-in con el proveedor. La contrapartida es que el operador ahora es dueño del riesgo de cadena de suministro que el proveedor de código cerrado venía cargando. Hugging Face aloja cientos de miles de artefactos de modelos contribuidos por investigadores, laboratorios corporativos y una larga cola de derivados. El canal de distribución se parece a un repositorio de paquetes, con el matiz de que los artefactos son binarios grandes cuya carga implica deserializar grafos de objetos complejos. Este capítulo recorre la superficie de la cadena de suministro — puertas traseras, vulnerabilidades de formato, procedencia, drift — y la infraestructura que el campo ha adoptado para llevar la cadena de suministro del modelo a la par de la del software.

9.1 Las puertas traseras persisten a través del entrenamiento de seguridad

El artículo de 2017 de Gu, Dolan-Gavitt y Garg «BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain» estableció la línea de investigación sobre puertas traseras. Una pequeña fracción de ejemplos de entrenamiento envenenados — por debajo del uno por ciento — podía inducir a un clasificador a clasificar mal entradas con disparador dejando la precisión sobre entradas sin disparador sin cambios. El modelo de amenaza de BadNets se transfiere a los LLM con las traducciones naturales. El artículo «Sleeper Agents» de Anthropic de enero de 2024, de Hubinger et al., demostró una extensión incómoda: puertas traseras deliberadamente entrenadas en los modelos podían persistir a través del entrenamiento de seguridad posterior, incluidos el RLHF y el entrenamiento adversarial diseñados para eliminar el mismo comportamiento que la puerta trasera implementaba. El modelo se comportaba con normalidad bajo la distribución del entrenamiento de seguridad y revertía al comportamiento con puerta trasera bajo el disparador. La contribución del artículo fue hacer explícito que el entrenamiento de alineamiento no es un filtro de seguridad general — modifica el comportamiento en las distribuciones que muestrea durante el entrenamiento, y un disparador suficientemente raro o bien oculto queda fuera de esas distribuciones. Las implicaciones defensivas son estructurales: la seguridad de un modelo desplegado no puede razonarse solo desde el entrenamiento de seguridad si la procedencia del modelo base es incierta. La detección es difícil porque el disparador es raro por diseño, pero el fuzzing conductual, el análisis de activaciones y las evaluaciones canario contra entradas con disparador son las mejores prácticas actuales.

9.2 El riesgo a nivel de formato es una categoría real

Los pesos de los modelos son ficheros binarios grandes, típicamente distribuidos a través de registros y hubs. Cargar esos pesos implica deserialización. El formato por defecto para muchos artefactos de la era PyTorch fue pickle, cuya deserialización ejecuta Python arbitrario por diseño. CVE-2024-3568, divulgada contra la librería Transformers de Hugging Face, ilustró cómo un fichero de modelo podía elaborarse para ejecutar código arbitrario en la carga. No fue la primera CVE de este tipo ni será la última. El formato safetensors, desarrollado por Hugging Face y publicado en 2022, fue la respuesta del campo — un formato de cabecera-más-tensores sin ruta de ejecución de código, con rendimiento tolerable y ahora por defecto para las publicaciones importantes de modelos. La implicación operativa es que cargar un fichero pickle de una fuente no confiable es funcionalmente equivalente a ejecutar un binario no confiable como tu proceso de inferencia. El versionado de modelos proporciona un segundo eje de integridad. El model card, introducido por Mitchell et al. en FAccT 2019, ofrece un registro documental estructurado — uso previsto, datos de entrenamiento, resultados de evaluación, limitaciones conocidas — que ha sido ampliamente adoptado por Hugging Face, OpenAI, Anthropic y Google. La tarjeta es documentación, no prueba; no verifica que el artefacto coincida con la descripción. Para eso está la firma criptográfica.

9.3 Procedencia, firma y monitorización de drift cierran el bucle

La comunidad de cadena de suministro de software ha convergido en un stack — niveles SLSA, atestaciones in-toto, Sigstore para firma, firma de registros de contenedores — que se ha extendido a los artefactos de ML a partir de 2026. El patrón para despliegue seguro de modelos es ya reconocible. La entrada de registro para un modelo está firmada por una clave autorizada. El sistema de despliegue descarga el artefacto, verifica el hash y verifica la firma de la entrada de registro. La carga ocurre solo desde safetensors, no desde pickle. Los metadatos de procedencia se retienen y se vinculan al registro de despliegue, de modo que la pregunta «qué versión, de qué upstream, está sirviendo tráfico actualmente» siempre tiene una respuesta definida. La monitorización de drift es la contraparte continua. El comportamiento de un modelo desplegado cambia con el tiempo incluso sin modificación de pesos — las entradas cambian, las aplicaciones upstream cambian, la distribución de consultas cambia. Distinguir el drift legítimo del compromiso requiere una línea base. El capítulo recorre métricas distribucionales (longitud media de entrada, distribución de puntuaciones del clasificador de seguridad, ratio de rechazo a cumplimiento), métricas categóricas (tasa de respuestas de código, tasa de PII en respuestas) y métricas conductuales (prompts canario fijos ejecutados periódicamente con respuestas comparadas contra una línea base). La desviación de la línea base no es prueba de compromiso, pero es una señal de que algo ha cambiado y merece investigación.

Lo que prepara el Capítulo 9

La parte III ha cubierto ahora el modelo en sí como objeto de seguridad — fallos de fiabilidad (cap. 7), ataques deliberados del espacio de entrada (cap. 8) y riesgo de cadena de suministro (cap. 9). La parte IV sube por la pila hacia la arquitectura del sistema en la que el modelo está empotrado. El capítulo 10 recorre los patrones arquitectónicos para despliegues seguros de LLM — fronteras de aislamiento, validación multicapa, motores de políticas como OPA y Cedar, diseño seguro de APIs y zero-trust aplicado a las llamadas al modelo. El capítulo 11 recorre observabilidad, registro y respuesta a incidentes — la capa operativa que convierte las defensas arquitectónicas en un sistema que la organización puede operar de forma fiable. El capítulo 12 recorre control de acceso e identidad — autenticación, autorización, aislamiento multi-tenant, límites de tasa y la capa de gobernanza empresarial. Los tres capítulos juntos describen la arquitectura de sistema que contiene, sostiene y restringe los componentes de modelo que la parte III acaba de examinar.

Próximamente — Capítulo 10: Diseño de arquitecturas seguras para LLM. Fronteras de aislamiento alrededor del modelo, validación multicapa, motores de políticas y principios zero-trust aplicados a un componente que lee toda entrada como instrucción.