Evaluación de vulnerabilidades específicas de la IA
¿Qué puede romper esta IA que no rompería un software corriente?
Enhanced: 5Advanced: 16 controles
A quién se aplica
Se entra solo en los sistemas que integráis, configuráis o entrenáis (B1) y cuya letra es E o A (esta área no tiene controles Baseline). Llega hasta donde alcance la letra del sistema, e implántalo en tu modo.
Por qué existe
Prueba tu IA frente a los ataques que de verdad se usan contra la IA, porque una prueba de seguridad convencional la dará por buena mientras el modelo siga siendo trivialmente manipulable. El ataque real más común contra la IA desplegada es desarmantemente simple: el atacante esconde instrucciones dentro del contenido que la IA va a leer —un documento, un correo, una página web, un registro de una base de datos— y la IA, incapaz de distinguir de forma fiable el contenido que procesa de las instrucciones que debe obedecer, le hace caso a él y no a ti. Esta técnica, conocida como inyección de instrucciones, no aparece en ninguna lista de verificación de seguridad clásica, y tampoco sus hermanas: convencer al modelo de que se salte sus reglas de seguridad, extraerle sus instrucciones permanentes confidenciales, o abusar del hecho de que lo que el modelo produce se suele introducir, sin examinar, en otros sistemas. Prueba estas cosas de forma explícita, o despliega sin probar frente a los ataques que vas a sufrir de verdad.
Qué hacer
Prueba el ataque de instrucciones ocultas donde de verdad llega: dentro del contenido, no en la caja de chat. La versión peligrosa de este ataque rara vez la escribe un usuario en una instrucción visible. Llega incrustada en el material que tu IA lee por encargo de alguien: una cláusula enterrada en un contrato subido, texto en blanco en una página web que el sistema resume, una línea fabricada en un registro que recupera. Toda IA que lea documentos, navegue o consulte tus almacenes de datos debe probarse frente a instrucciones ocultas en ese contenido; una prueba limitada al campo de instrucción visible se pierde precisamente el ataque que importa.
Trata la salida del modelo como entrada no confiable para lo que sea que la consuma. Si lo que el modelo produce fluye hacia delante —a código que se ejecuta, a una consulta de base de datos, a una página web, a la acción de otro sistema—, entonces quien pueda moldear la salida del modelo puede atacar ese destino a través de ella. Prueba cada uno de esos caminos como pruebas cualquier entrada no confiable frente a ataques de inyección, porque eso es exactamente lo que es: una entrada que no escribiste tú, yendo a un sitio que se fía de ella.
Da por hecho que los atacantes intentarán extraer las instrucciones permanentes: verifica que no hay nada que ganar. Los atacantes engañan de forma rutinaria a los modelos desplegados para que revelen sus instrucciones confidenciales y su contexto incrustado. Pruébalo y, sobre todo, verifica que conseguirlo no rinda nada: ni credenciales, ni direcciones internas, ni conocimiento privilegiado (la higiene que exige el área de arquitectura). Las instrucciones deberían ser una molestia si se pierden, nunca una brecha.
Vuelve a probar cuando cambie el modelo, no cuando lo diga el calendario. Una versión nueva del modelo puede reabrir en silencio una debilidad que habías cerrado y confirmado cerrada: la manipulación que fracasaba contra el modelo viejo puede funcionar contra el nuevo. Ata la repetición de las pruebas al evento de cambio de modelo —ese del que ahora te avisa tu contrato y que tu fijación de versión hace visible— en vez de esperar a una ventana anual de pruebas que certifica un modelo que quizá ya no estés ejecutando.
Prueba las imágenes y los demás medios que acepta el sistema, no solo su texto. Allí donde una IA lee imágenes, audio o documentos mixtos, una instrucción puede esconderse en la parte que no es texto —texto puesto con poco contraste dentro de una imagen, un pie fabricado para leerse como una orden— y dispararse cuando el modelo procesa el conjunto. Todo sistema que acepte algo más que texto se prueba frente a instrucciones ocultas en las demás modalidades, porque una prueba limitada al campo de texto se las pierde por completo.
Haz que las pruebas muerdan. Allí donde tengas un proceso de construcción o de publicación, ejecuta estas pruebas como baterías automatizadas de evaluación adversaria y de capacidad cuyo fallo bloquee la publicación. Una prueba que solo puede producir un informe es un hallazgo; una prueba que detiene una publicación es un control.
Controles
Enhanced5 controles
Control 98
Realiza pruebas de ataques con instrucciones ocultas, tanto tecleadas como incrustadas en el contenido.
EnhancedDetectivointegrador o desarrollador (deployer+)por sistema
Qué es
Todo sistema que lee documentos, navega o consulta almacenes de datos se prueba frente a instrucciones plantadas en ese contenido.
Cómo implantarlo · Pasos
Enumera todos los canales de entrada: chat, documentos subidos, correos, páginas web consultadas, registros recuperados de almacenes de datos
Redacta casos de prueba con instrucciones tecleadas directamente y con instrucciones ocultas en cada canal (texto oculto, comentarios, metadatos)
Fija criterios de superación: instrucciones ocultas ignoradas, ningún dato revelado, ninguna acción no autorizada
Ejecuta antes de la puesta en marcha y ante cambios relevantes; registra cada caso y resultado
Corrige los fallos y vuelve a ejecutar los casos fallidos
Cómo arrancar
Oculta una instrucción en un documento de prueba que lea tu sistema (por ejemplo, que revele sus instrucciones o envíe un resumen fuera) y comprueba si la obedece.
Evidencia
El plan de pruebas, los casos e informes, y los registros de corrección.
Modo: ligero / estándar / completo
ligero
Encarga la prueba a un especialista externo o usa una biblioteca breve de ataques conocidos, ejecutada por el responsable del sistema antes de la puesta en marcha.
estándar
El equipo de seguridad mantiene una batería de pruebas por sistema y la ejecuta en cada publicación.
completo
Un equipo de ataque simulado dedicado a la IA mantiene las baterías, las ejecuta automáticamente en el proceso de publicación y los fallos la bloquean.
Control 99
Prueba cada vía posterior que consume la salida del modelo.
EnhancedDetectivointegrador o desarrollador (deployer+)por sistema
Qué es
La salida que fluye hacia código, consultas, páginas o acciones se prueba como entrada no fiable.
Cómo implantarlo · Pasos
Traza cada ruta por la que viaja la salida del modelo: código que se ejecuta, consultas a bases de datos, páginas web, llamadas a API, acciones en otros sistemas
En cada ruta, ejecuta pruebas de inyección estándar usando la salida del modelo como vector de ataque (consultas, scripts, comandos)
Comprueba que el sistema receptor valida, escapa o parametriza la salida y nunca la ejecuta directamente
Registra los hallazgos y corrígelos en el sistema receptor, no solo en las instrucciones del modelo
Vuelve a probar cada vez que se añada un nuevo receptor de la salida del modelo
Cómo arrancar
Dibuja el flujo desde la salida del modelo hasta cada sistema receptor y prueba primero la ruta que ejecuta código o consultas.
Evidencia
El mapa de rutas de salida, los informes de pruebas y los registros de corrección.
Modo: ligero / estándar / completo
ligero
Encarga a un especialista pruebas de inyección en la ruta o las dos rutas donde la salida se ejecuta o se muestra.
estándar
Seguridad de aplicaciones incluye las rutas de salida en sus pruebas habituales de cada publicación de IA.
completo
Las pruebas de rutas de salida se ejecutan automáticamente en el proceso de publicación para cada receptor, y los fallos la bloquean.
Control 100
Realiza pruebas de evasión de las reglas de seguridad y de extracción de instrucciones.
EnhancedDetectivointegrador o desarrollador (deployer+)por sistema
Qué es
Y verifica que las instrucciones extraídas no revelan nada sensible.
Cómo implantarlo · Pasos
Pruebas de evasión: juego de rol, planteamientos hipotéticos, presión en varios turnos, peticiones codificadas o traducidas dirigidas a los comportamientos prohibidos del sistema
Pruebas de extracción: intentos directos e indirectos de que el sistema revele sus instrucciones permanentes y el contexto incrustado
Comprueba que lo extraído no contiene credenciales, direcciones internas ni conocimiento privilegiado
Fija criterios de superación y registra cada caso y resultado
Corrige los fallos y vuelve a probar; saca de las instrucciones cualquier elemento sensible encontrado
Cómo arrancar
Pide al sistema, primero directa y luego indirectamente, que repita sus instrucciones, y contrasta lo que salga con tu regla de cero secretos.
Evidencia
Los casos e informes de prueba, incluida la revisión del contenido extraído.
Modo: ligero / estándar / completo
ligero
Encarga la prueba a un especialista externo o ejecuta tú mismo un conjunto breve de ataques conocidos de evasión y extracción antes de la puesta en marcha.
estándar
El equipo de seguridad ejecuta baterías de evasión y extracción por sistema en cada publicación.
completo
Un equipo de ataque simulado dedicado a la IA mantiene y automatiza las baterías, actualizándolas a medida que aparecen técnicas nuevas.
Control 101
Desencadena nuevas pruebas con cada cambio de versión del modelo.
EnhancedDetectivointegrador o desarrollador (deployer+)por sistema
Qué es
Es el evento de cambio, no el calendario, lo que determina la prueba.
Cómo implantarlo · Pasos
Define el desencadenante: cualquier cambio de la versión fijada del modelo, un aviso de cambio del proveedor o una nueva adaptación
Mantén una batería de repetición por sistema: casos de instrucciones ocultas, evasión, extracción y rutas de salida
Ejecuta la batería con la nueva versión antes de que llegue a producción y compara con los resultados anteriores
Bloquea el cambio si reaparece una debilidad ya cerrada
Vincula el registro de la nueva prueba al registro del cambio
Cómo arrancar
Añade «repetir las pruebas de seguridad» como paso obligatorio de tu procedimiento de cambio de versión del modelo.
Evidencia
Los registros de repetición de pruebas vinculados a cada cambio de versión.
Modo: ligero / estándar / completo
ligero
El responsable del sistema repite las pruebas guardadas con la nueva versión antes de cambiar, o pide al especialista externo que lo haga.
estándar
El proceso de cambios no puede cerrar un cambio de versión sin un informe de repetición del equipo de seguridad vinculado.
completo
Un cambio de versión lanza automáticamente la batería completa en el proceso de publicación, y cualquier regresión bloquea el cambio.
Control 102
Prueba las entradas multimodales en busca de instrucciones ocultas siempre que el sistema las acepte.
EnhancedDetectivointegrador o desarrollador (deployer+)por sistema
Qué es
Las imágenes, el audio y los documentos mixtos se examinan en busca de instrucciones plantadas, además del texto.
Cómo implantarlo · Pasos
Identifica cada entrada no textual que acepta el sistema: imágenes, documentos escaneados, audio, vídeo, ficheros mixtos
Crea casos de prueba: texto tenue o diminuto en imágenes, instrucciones en pies de foto, metadatos o texto alternativo, órdenes habladas en audio, objetos incrustados en documentos
Comprueba si las instrucciones ocultas cambian el comportamiento, revelan datos o desencadenan acciones
Registra los resultados junto a las pruebas de texto; corrige y vuelve a probar
Cómo arrancar
Crea una imagen con una instrucción escrita de forma tenue y envíala al sistema como lo haría un usuario corriente.
Evidencia
Los casos e informes de pruebas multimodales, con los registros de corrección.
Modo: ligero / estándar / completo
ligero
Incluye unos pocos casos de imágenes y documentos en la prueba encargada al especialista externo.
estándar
El equipo de seguridad añade casos multimodales a la batería de cada sistema y los ejecuta en cada publicación.
completo
El equipo de ataque simulado de IA mantiene una biblioteca de ataques multimodales y la ejecuta automáticamente con las demás baterías.
Advanced1 controles
Control 103
Realiza pruebas de extracción del modelo y de los datos de entrenamiento en los sistemas de alto valor.
AdvancedDetectivointegrador o desarrollador (deployer+)por sistema
Qué es
Cuando valdría la pena robar el propio modelo, o aquello de lo que aprendió.
Cómo implantarlo · Pasos
Decide si el sistema es de alto valor: modelo propio o costoso de construir, o datos de entrenamiento o de referencia sensibles
Prueba de extracción del modelo: consultas sistemáticas para copiar su comportamiento; comprueba si los límites de uso y el detalle de las salidas hacen viable la copia
Prueba de extracción de datos: peticiones que intentan reproducir literalmente registros de entrenamiento o de referencia, y comprobación de si se usaron registros conocidos
Fija umbrales aceptables y mitigaciones: limitación de uso, salidas menos detalladas, vigilancia de patrones de consulta
Informa los resultados y repite tras cambios del modelo
Cómo arrancar
Enumera qué sistemas son de alto valor y, en el primero, intenta que reproduzca registros conocidos de sus datos de entrenamiento o de referencia.
Evidencia
La calificación de alto valor, el plan de pruebas y los informes de pruebas de extracción.
Modo: ligero / estándar / completo
ligero
Encarga una prueba especializada para el único sistema de alto valor, con el alcance definido por su responsable.
estándar
El equipo de seguridad ejecuta pruebas de extracción en los sistemas de alto valor en cada publicación importante.
completo
El equipo de ataque simulado de IA prueba la extracción de forma continua y vigila en producción los patrones de consulta propios de una extracción.
Evidencia
Los planes y los informes de pruebas específicas de IA; los casos de prueba de instrucciones ocultas y de evasión; los registros de subsanación; los registros de repetición de pruebas asociados a los cambios de versión.