Área 2.4

Robustez adversarial e integridad del modelo

¿Cómo se comporta el modelo ante un ataque deliberado, y podemos fiarnos del archivo de modelo que hemos cargado?

Baseline: 1Enhanced: 1Advanced: 4 6 controles

A quién se aplica

Se entra solo en los sistemas que integráis, configuráis o entrenáis (B1). Llega hasta donde alcance la letra del sistema, e implántalo en tu modo.

Por qué existe

Si construyes modelos, los adaptas o descargas ficheros de modelo para ejecutarlos tú, caen sobre ti dos riesgos de los que quien solo compra se libra en gran medida, y los dos tienen que ver con el modelo como objeto, no como servicio. El primero: al modelo se le puede engañar o degradar deliberadamente con entradas fabricadas para ello. El segundo, menos evidente: el propio fichero del modelo —el artefacto que descargas y cargas— puede haber sido manipulado antes de que lo ejecutaras siquiera, exactamente igual que un instalador de software. Un fichero de modelo es material con categoría de ejecutable y con alcance dentro de tus sistemas; trátalo con la desconfianza que ya aplicas al software que no has escrito tú. Esta área se aplica en su totalidad a las organizaciones que construyen o adaptan modelos y a los despliegues de alto riesgo; si solo consumes servicios de IA, la primera medida de abajo —verificar lo que descargas— es la que te corresponde.

Qué hacer

Verifica el origen y la integridad de cada fichero de modelo antes de cargarlo: esto ya lo haces con el software. Equipos que jamás ejecutarían un instalador sin firmar en un servidor de producción se descargan ficheros de modelo de un repositorio público y los cargan sin verificar. Acaba con esa asimetría: comprueba la integridad del fichero frente a su huella publicada, prefiere ficheros cuyo origen esté certificado criptográficamente y registra qué verificaste. Un fichero de modelo sin verificar es un programa sin auditar con acceso a todo aquello a lo que lo conectes.
Firma los modelos que construyas, y niégate a desplegar lo que no supere la verificación. Para cada modelo que produzca tu propia cadena de construcción, genera un sello criptográfico en el momento de construirlo y verifícalo automáticamente al cargarlo. Es el control que caza un modelo sustituido o corrompido en cualquier punto entre tu construcción y tu producción, un ataque que por lo demás es invisible, porque un modelo manipulado tiene el mismo aspecto y se comporta casi igual que el original.
Revisa los ficheros de modelo de terceros en busca de comportamientos ocultos con disparador. Un modelo obtenido de fuera puede llevar un comportamiento implantado deliberadamente que permanece latente —el modelo funciona con normalidad ante cualquier entrada corriente— hasta que aparece un disparador concreto, momento en el que hace lo que pretendía quien lo implantó. Cuando lo que está en juego en el despliegue lo justifique, revisa los ficheros de modelo externos en busca de esos implantes antes de adoptarlos; después es tarde, porque el disparador lo elige el atacante, no lo encuentras tú.
Prueba la robustez frente al ataque que importa en tu caso de uso, no como un ritual genérico. Ajusta las pruebas adversarias al despliegue. Un modelo que clasifica o detecta se prueba frente a entradas fabricadas para colarse. Un modelo adaptado con tus propios datos se prueba para ver si esa adaptación se puede envenenar. Un modelo entrenado con datos sensibles se prueba para ver si un atacante puede determinar qué —o quién— estaba en el conjunto de entrenamiento. Las pruebas acotadas encuentran el fallo que de verdad te haría daño; las genéricas producen un informe tranquilizador sobre el riesgo equivocado.
Prefiere formatos de modelo que no ejecuten código al abrirse. Algunos ficheros de modelo habituales ejecutan código incrustado en el momento en que se cargan: basta con abrir el fichero para que se ejecute la carga útil de un atacante, antes de que el modelo haya respondido nada. Prefiere formatos diseñados para contener solo datos; y donde no puedas evitar un formato capaz de llevar código, analízalo antes de cargarlo siquiera, exactamente como tratarías a un ejecutable de origen desconocido.

Controles

Baseline 1 controles

Control 104

Verifica el origen y la integridad de cada archivo de modelo antes de su primer uso.

BaselinePreventivointegrador o desarrollador (deployer+)por sistema

Qué es

Comprobaciones de huella digital y origen certificado, registrados; la única medida de esta dimensión que se aplica a todas las organizaciones.

Cómo implantarlo · Pasos

Descarga solo desde la fuente oficial del editor o desde la página propia del editor en un repositorio de modelos
Calcula la huella (hash) del fichero y compárala con la que publica el editor
Si se ofrece, comprueba la firma o la atestación de origen
Registra: modelo, versión, dirección de origen, huella, resultado, fecha, quién lo comprobó
No cargues un fichero que falle o no pueda verificarse sin una decisión registrada del responsable del sistema

Cómo arrancar

Para cada fichero de modelo ya en uso, calcula su huella, compárala con la del editor y registra el resultado.

Evidencia

El registro de verificación de cada fichero de modelo en uso.

Modo: ligero / estándar / completo

ligero: Una persona designada ejecuta el comando de huella del sistema operativo y anota el resultado en una hoja de cálculo.
estándar: La verificación es un script dentro del proceso de descarga, con los resultados guardados en el registro de modelos.
completo: Los ficheros de modelo solo entran por un repositorio interno que verifica automáticamente huellas y origen y rechaza los que fallan.

Enhanced 1 controles

Control 105

Da preferencia a formatos de modelo no ejecutables y analiza cualquier archivo cargable que pueda ejecutar código al abrirse.

EnhancedPreventivointegrador o desarrollador (deployer+)por sistema

Qué es

Se aplica a cada archivo de modelo antes de su primera carga, junto con la comprobación de origen e integridad.

Cómo implantarlo · Reglas mínimas

Por defecto: usa formatos de modelo diseñados para contener solo datos, que no pueden ejecutar código al cargarse
Formatos con código permitidos solo con justificación registrada cuando no exista versión de solo datos
Analiza cada fichero con código con un escáner de ficheros de modelo antes de su primera carga
Los ficheros con hallazgos en el análisis no se cargan
Registra la decisión de formato y el resultado del análisis junto a la comprobación de origen e integridad

Cómo arrancar

Enumera los formatos de los ficheros de modelo que tienes y sustituye los que llevan código por versiones de solo datos siempre que el editor las ofrezca.

Evidencia

Las decisiones de formato y los registros de análisis de los ficheros con código.

Modo: ligero / estándar / completo

ligero: Quien descarga los modelos elige formatos de solo datos y, en cualquier excepción, ejecuta un escáner y anota el resultado en la hoja de verificación.
estándar: Las reglas de formato figuran en el estándar de gestión de modelos, con el análisis integrado en el proceso de descarga.
completo: El repositorio interno de modelos solo acepta por defecto formatos de solo datos y analiza y aísla automáticamente cualquier fichero con código.

Advanced 4 controles

Control 106

Firma los modelos de construcción propia y verifícalos automáticamente al cargarlos.

AdvancedPreventivodesarrollador (developer)por sistema

Qué es

El despliegue rechaza un modelo que no supera la verificación.

Cómo implantarlo · Reglas mínimas

El proceso de construcción firma cada artefacto de modelo al generarlo con una clave guardada en el almacén de secretos o un servicio de firma
La firma abarca el fichero y sus metadatos (versión, referencia a la ficha de entrenamiento)
Todos los entornos verifican la firma automáticamente al cargar
El despliegue rechaza un modelo sin firma o con firma fallida, y se genera una alerta
Claves de firma restringidas al proceso, rotadas y con cada uso registrado

Cómo arrancar

Añade un paso de firma al final del proceso de entrenamiento de un modelo y una verificación al arrancar su servicio, y extiéndelo después a todos.

Evidencia

La configuración del proceso de firma y los registros de verificación al cargar.

Modo: ligero / estándar / completo

ligero: Quien desarrolla firma cada modelo con una herramienta de firma estándar y el script de servicio no arranca si la verificación falla.
estándar: El equipo de ingeniería de modelos integra la firma en el proceso de construcción y la verificación en cada entorno de servicio.
completo: Un servicio central de firma con claves protegidas firma todos los modelos y la plataforma impone la verificación en cada carga.

Control 107

Examina los archivos de modelo externos en busca de comportamientos activadores implantados.

AdvancedDetectivointegrador o desarrollador (deployer+)por sistema

Qué es

Se aplica antes de la adopción, en proporción a lo que está en juego en el despliegue.

Cómo implantarlo · Pasos

Decide si lo que está en juego justifica el examen: el modelo influye en decisiones relevantes, trata datos sensibles o puede actuar
Comprueba la procedencia: identidad e historial del editor, documentación de los datos y el método de entrenamiento
Haz un examen de comportamiento: entradas variadas e inusuales y posibles patrones desencadenantes, buscando salidas anómalas
Compara el comportamiento con un modelo de referencia fiable cuando exista
Registra el resultado y la decisión de adopción antes del despliegue

Cómo arrancar

Toma el modelo externo de mayor riesgo que vayas a adoptar y completa la comprobación de procedencia y un primer examen de comportamiento antes de la puesta en marcha.

Evidencia

Los informes de examen y las decisiones de adopción registradas.

Modo: ligero / estándar / completo

ligero: Prioriza modelos de editores bien documentados y encarga un examen especializado solo para el caso de alto riesgo.
estándar: El equipo de seguridad examina los modelos externos de despliegues de alto riesgo como parte de su aprobación.
completo: Una función dedicada de aseguramiento de modelos examina cada modelo externo, en proporción al riesgo, antes de que entre en el repositorio interno.

Control 108

Realiza pruebas de robustez adversarial ajustadas al caso de uso.

AdvancedDetectivointegrador o desarrollador (deployer+)por sistema

Qué es

Evasión, envenenamiento o exposición de los datos de entrenamiento: el riesgo que el despliegue corra realmente.

Cómo implantarlo · Pasos

Nombra el ataque que importa: evasión en clasificadores y detectores, envenenamiento en modelos adaptados con tus datos, exposición de datos de entrenamiento en modelos entrenados con datos sensibles
Redacta un plan de pruebas para ese ataque con umbrales de superación (p. ej. caída máxima de precisión ante entradas manipuladas)
Ejecuta las pruebas con entradas manipuladas o muestras envenenadas y mide el efecto
Corrige mediante refuerzo, filtrado de entradas o controles de datos, y vuelve a probar
Repite en cada cambio de modelo o nueva adaptación

Cómo arrancar

Escribe una frase que diga qué ataque haría más daño a este despliegue y construye el plan de pruebas en torno a él.

Evidencia

Los planes de pruebas de robustez acotados y sus resultados.

Modo: ligero / estándar / completo

ligero: Encarga una prueba especializada acotada al único ataque que haya identificado el responsable.
estándar: Los equipos de ciencia de datos y seguridad ejecutan pruebas de robustez acotadas antes de cada publicación importante.
completo: Un equipo de ataque simulado de IA mantiene baterías de robustez por caso de uso y las ejecuta automáticamente en el proceso de publicación.

Control 109

Evalúa la exposición de los datos de entrenamiento cuando los datos son sensibles.

AdvancedDetectivodesarrollador (developer)por sistema

Qué es

Se comprueba si la pertenencia a los datos de entrenamiento, o su contenido, puede inferirse a partir del modelo.

Cómo implantarlo · Pasos

Identifica qué datos de entrenamiento son sensibles: datos personales, información confidencial de negocio
Prueba de inferencia de pertenencia: si un atacante puede saber si un registro concreto estaba en el conjunto de entrenamiento
Prueba de extracción de contenido: si el modelo puede reproducir registros de entrenamiento literalmente o casi
Fija umbrales de fuga aceptables y mitigaciones: deduplicación, eliminación de registros, entrenamiento que preserve la privacidad, filtrado de salidas
Registra los resultados y repite tras cada reentrenamiento

Cómo arrancar

Toma una muestra de registros sensibles del conjunto de entrenamiento y prueba si el modelo los reproduce o revela que se usaron.

Evidencia

El plan de pruebas de exposición, los resultados y las mitigaciones aplicadas.

Modo: ligero / estándar / completo

ligero: Encarga una evaluación especializada para el único modelo entrenado con datos sensibles y conserva el informe.
estándar: El equipo de ciencia de datos ejecuta pruebas de exposición antes de cada publicación, revisadas por el responsable de protección de datos.
completo: Las pruebas de exposición se ejecutan automáticamente tras cada entrenamiento y bloquean la publicación por encima de los umbrales acordados.

Evidencia

Los registros de verificación de los ficheros de modelo descargados; la cadena de firma y sus registros de verificación en la carga; los informes de revisión; los planes y los resultados de las pruebas de robustez acotadas. Las decisiones sobre el formato del modelo y los registros de análisis de los ficheros que pueden contener código.