Lista de verificación de seguridad adversarial y robustez

Cómo usar este documento

• Para qué sirve. Es una lista de verificación base para comprobar, antes de un piloto, un paso a producción o un cambio relevante, que un modelo o una aplicación de IA se probó frente a manipulación y fallos: inyección de instrucciones, jailbreak, fuga de datos, abuso de agentes, envenenamiento, evasión, entradas fuera de distribución abuso del servicio y, para modelos de terceros alojados internamente, puertas traseras, plantillas de chat manipuladas y alineamiento o censura incorporados. No sustituye una prueba de penetración ni un ejercicio de equipo rojo completo, pero deja constancia de qué se probó, qué se encontró y qué se decidió.
• Quién debe ser su dueño. Seguridad de la información, junto con el dueño del sistema y el equipo técnico que lo construye o integra. Indique el área en [ÁREA RESPONSABLE] y la persona que firma el resultado en [RESPONSABLE].
• Decisiones previas. Defina qué profundidad de pruebas corresponde a cada nivel de riesgo (ayuda C), quién ejecuta las pruebas (equipo interno, equipo independiente o tercero), qué severidad bloquea el despliegue y quién puede aceptar riesgos residuales.
• Campos a completar. Complete la identificación, marque cada control como «Cumple», «Parcial», «No cumple» o «N/A», anote la evidencia y registre cada hallazgo en la sección 14. Use la «Selección de módulos» para quedarse con las secciones que corresponden a sus perfiles y al tipo de sistema.
• Variantes por país. Este documento no tiene variantes por país. Use «Referencias normativas relacionadas» para ver qué normas de ciberseguridad, de productos con elementos digitales o de IA piden pruebas adversariales o documentación de robustez a su organización.
• Referencias técnicas. Para diseñar los casos de prueba, puede apoyarse en catálogos públicos como OWASP Top 10 for LLM Applications (edición 2025), MITRE ATLAS y NIST AI 600-1.
• Aprobación y archivo. La decisión de la sección 15 la firman seguridad de la información y el dueño del sistema; el [COMITÉ DE IA] decide cuando el sistema es de riesgo Alto y la decisión es «Aprobar con condiciones» o «Escalar». Archive la lista con la tarjeta de modelo y, para modelos de terceros alojados internamente, anote el resumen en su ficha de procedencia.

Selección de módulos

Perfil, nivel o tipo de sistema	Secciones que conservar
Todos	1 a 4, 7, 9, 11, 12, 14 y 15
P2 Integra modelos por API o RAG	Además, 5 y 6; y 13.5 y 13.6 si usa modelos de terceros en sistemas de riesgo Medio o Alto
P3 Aloja modelos, incluidos los de pesos abiertos	Además, 5, 6 y 13
P4 Entrena o ajusta modelos	Además, 10 y, si ajusta un modelo de lenguaje, 5, 6 y 13.7
P5 Usa agentes que actúan en sistemas	Además, 5, 6 y 8
Modelo clásico de clasificación o puntuación	Además, 10
Nivel Básico	Filas sin marca de nivel
Nivel Estándar y Reforzado	Todas las filas, incluidas las marcadas [NIVEL REFORZADO] solo en el nivel Reforzado

Elimine las secciones que no apliquen a su organización.

Lista de verificación de seguridad adversarial y robustez

Campo	Valor
Organización	[RAZÓN SOCIAL]
Área responsable	[ÁREA RESPONSABLE]
Responsable de la verificación	[RESPONSABLE]
Sistema de IA	[SISTEMA DE IA]
Versión del modelo y de la aplicación	[COMPLETAR]
Proveedor o desarrollador del modelo	[PROVEEDOR]
Perfiles de despliegue del sistema	[COMPLETAR: P1 a P5]
Tipo de sistema	[COMPLETAR: aplicación con modelo de lenguaje, búsqueda aumentada con documentos, agente con herramientas, modelo clásico de clasificación o puntuación, visión u otro]
Momento	[COMPLETAR: antes del piloto, antes de producción, cambio relevante o revisión periódica]
Nivel de riesgo (según el «Inventario de sistemas de IA»)	[COMPLETAR: Bajo, Medio o Alto]
Equipo de pruebas	[COMPLETAR: interno, independiente o tercero]
Fechas de las pruebas	Del [FECHA] al [FECHA]

1. Uso de la lista

1.1 [NOMBRE DE LA ORGANIZACIÓN] aplica esta lista a todo sistema de IA de riesgo Medio o Alto, a toda aplicación de IA expuesta a clientes o al público, a todo agente que pueda ejecutar acciones y a todo modelo de terceros alojado en infraestructura propia o alquilada, antes del piloto, antes del paso a producción y tras cambios relevantes del modelo, de las instrucciones de sistema, de las fuentes de datos, de las herramientas conectadas, de la versión de los pesos o de la plantilla de chat.

1.2 Cada control se marca así:

Resultado	Significado
Cumple	El control existe y se probó con evidencia.
Parcial	El control existe pero no cubre todos los casos o no se probó por completo.
No cumple	El control no existe o la prueba falló.
N/A	No aplica a este tipo de sistema; se indica el motivo.

1.3 Cada «Parcial» o «No cumple» genera un hallazgo en la sección 14 con su severidad. La severidad del hallazgo no es un nivel de riesgo: al anotar el hallazgo en el registro de riesgos del «Procedimiento de gestión de riesgos de IA», se le asigna el nivel de riesgo que indica la última columna.

Severidad del hallazgo	Criterio	Nivel de riesgo en el registro
Crítica	Permite exponer datos confidenciales o personales, ejecutar acciones no autorizadas, activar un comportamiento oculto del modelo o generar contenido ilícito o gravemente dañino de forma reproducible.	Alto (Inaceptable si equivale a una práctica prohibida)
Alta	Permite eludir controles relevantes o degradar de forma significativa los resultados con un esfuerzo moderado.	Alto
Media	Requiere condiciones poco probables o tiene un impacto limitado y reversible.	Medio
Baja	Debilidad menor o de buenas prácticas, sin impacto directo demostrado.	Bajo

2. Alcance y modelo de amenazas

ID	Control	Resultado	Evidencia
2.1	El sistema está en el «Inventario de sistemas de IA», con su dueño del sistema y su responsable técnico identificados.	[COMPLETAR]	[COMPLETAR]
2.2	Se documentaron los activos a proteger: datos, instrucciones de sistema, credenciales, herramientas conectadas, el propio modelo y la reputación.	[COMPLETAR]	[COMPLETAR]
2.3	Se identificaron los posibles atacantes y abusadores: usuarios externos, usuarios internos, contenido de terceros que el sistema lee y proveedores.	[COMPLETAR]	[COMPLETAR]
2.4	Se identificaron todas las vías de entrada al modelo: mensajes del usuario, documentos, páginas web, correos, respuestas de herramientas y datos de entrenamiento.	[COMPLETAR]	[COMPLETAR]
2.5	Se definió qué consecuencias serían inaceptables para este sistema.	[COMPLETAR]	[COMPLETAR]