El equipo de TPRM de una empresa evaluaba el producto de análisis de contratos basado en IA de un proveedor y solicitó evidencia de pruebas de seguridad. El equipo de seguridad del proveedor entregó un paquete de evidencia completo: su informe SOC 2 Tipo II, que confirmaba los controles de su infraestructura en la nube; un informe de pruebas de penetración de una firma de seguridad reconocida que abarcaba la capa de su aplicación web; y una descripción de su ciclo de vida de desarrollo seguro, que incluía revisiones de código, análisis estático y escaneo de DAST durante la canalización de CI/CD. El analista de TPRM de la empresa revisó el paquete de evidencia y se dispuso a marcar las pruebas de seguridad de la IA como confirmadas. Un colega con más experiencia que revisaba el paquete de evidencia hizo una pregunta aclaratoria: de estos tres elementos de evidencia, ¿cuál probó el propio modelo de IA, es decir, la resistencia del modelo a las entradas adversarias, su comportamiento ante la inyección de instrucciones, la integridad de sus datos de entrenamiento o la exactitud de sus resultados y su tasa de confabulación? La respuesta fue ninguno. El SOC 2 evaluaba los controles operativos de la infraestructura que alojaba el modelo de IA. La prueba de penetración evaluaba la aplicación web que daba acceso al modelo de IA. Las revisiones de código evaluaban el código de la aplicación que envolvía el modelo de IA. Las tres eran actividades de garantía de seguridad legítimas y valiosas. Ninguna constituía una prueba de seguridad específica de IA, es decir, una prueba del propio modelo como superficie de seguridad.
¿Qué son realmente las brechas en las pruebas de seguridad de la IA?
Las brechas en las pruebas de seguridad de la IA son las omisiones del programa de pruebas de seguridad de un proveedor que dejan el propio modelo de IA, a diferencia de la infraestructura, la aplicación y los controles operativos que lo rodean, sin probar frente a las categorías de ataque específicas a las que son vulnerables los sistemas de IA. Los marcos tradicionales de pruebas de seguridad (pruebas de penetración, SAST/DAST, evaluación de controles SOC 2) se diseñaron para aplicaciones de software e infraestructura, no para sistemas de IA. Aplicar estos marcos tradicionales a los productos de IA produce evidencia de pruebas de seguridad que abarca todo excepto el propio modelo de IA.
La superficie de ataque específica de la IA es lo que las pruebas tradicionales pasan por alto. Los modelos de IA enfrentan un conjunto propio de desafíos de seguridad que no abordan las pruebas de penetración de aplicaciones web ni las auditorías de los controles de infraestructura: ataques de entradas adversarias que hacen que el modelo clasifique erróneamente las entradas, ataques de inyección de instrucciones que hacen que el modelo eluda sus restricciones operativas, envenenamiento de los datos de entrenamiento que compromete el comportamiento aprendido del modelo, ataques de extracción del modelo que roban su lógica de decisión y confabulación de los resultados que introduce información inexacta en las respuestas del modelo. Ninguna de estas categorías de ataque se evalúa en una prueba de penetración de una aplicación web ni en una auditoría de infraestructura SOC 2.
La brecha de madurez de los marcos de pruebas es el contexto del sector. Los marcos de pruebas de seguridad específicos de IA son mucho más recientes y están menos estandarizados que los marcos tradicionales de pruebas de seguridad de software. La metodología de pruebas de penetración que se aplica a las aplicaciones web tiene treinta años de desarrollo detrás. La metodología de pruebas adversarias de ML que se aplica a los modelos de IA todavía está en desarrollo. Los equipos de seguridad de los proveedores que tienen programas maduros de pruebas de seguridad tradicionales pueden tener prácticas de pruebas específicas de IA inmaduras o inexistentes simplemente porque el campo es más reciente y los estándares están menos consolidados.
La brecha en las pruebas de confabulación es una dimensión específica de las pruebas de seguridad de la IA que falta en casi todos los programas de pruebas de seguridad de los proveedores. Probar si un modelo de IA confabula (si produce resultados seguros, fluidos e inexactos) en el dominio específico para el que la empresa lo implementa es una actividad de aseguramiento de la calidad de la IA con implicaciones directas para la seguridad. Una IA que confabula análisis jurídicos, información médica u orientación financiera causa daños posteriores, por muy bien implementada que esté la seguridad de la aplicación.
Por qué es importante
Las brechas en las pruebas de seguridad de la IA son importantes para la TPRM porque la evidencia de garantía de seguridad que los proveedores entregan para los productos de IA suele abarcar exhaustivamente las dimensiones de seguridad tradicionales y dejar completamente sin evaluar las dimensiones de seguridad específicas de la IA. Un paquete de evidencia que confirma SOC 2, pruebas de penetración y seguridad de SDLC ofrece una garantía real sobre la infraestructura y la aplicación, y ninguna garantía sobre el modelo de IA.
Dónde se equivocan la mayoría de los equipos
La falla más constante es aceptar la evidencia de pruebas de seguridad tradicionales (SOC 2, pruebas de penetración, SDLC) como equivalente a la evidencia de pruebas de seguridad de la IA. Los marcos abordan superficies de seguridad distintas. Ambos son necesarios. Ninguno sustituye al otro.
- Evidencia de seguridad tradicional aceptada como evidencia de seguridad de la IA
- Pruebas de entradas adversarias ausentes del programa de pruebas del proveedor
- Pruebas de inyección de instrucciones no realizadas o no incluidas en la evidencia
- Evaluación de la tasa de confabulación no realizada
- Pruebas de integridad de los datos de entrenamiento no incluidas en el programa de seguridad de la IA
Cómo se ve una buena práctica
Los programas maduros de pruebas de seguridad de la IA realizan tanto pruebas de seguridad tradicionales (infraestructura, aplicación, SDLC) como pruebas de seguridad específicas de IA (entradas adversarias, inyección de instrucciones, tasa de confabulación, integridad de los datos de entrenamiento), y pueden aportar evidencia de ambas dimensiones por separado en respuesta a las solicitudes de TPRM.
- Programa de pruebas específicas de IA junto con las pruebas de seguridad tradicionales
- Pruebas de entradas adversarias: resistencia del modelo a entradas diseñadas para provocar una clasificación errónea
- Pruebas de inyección de instrucciones: resistencia del modelo a los intentos de anular sus instrucciones
- Evaluación de la tasa de confabulación: validación de la exactitud de los resultados en el dominio de implementación
- Pruebas de integridad de los datos de entrenamiento: validación del corpus de entrenamiento frente al envenenamiento
Herramientas
Pruebas de seguridad de la IA: Garak, Adversarial Robustness Toolbox (IBM ART), Microsoft PyRIT
Los marcos de pruebas de seguridad de la IA diseñados específicamente para grandes modelos de lenguaje y modelos de ML prueban la resistencia a las entradas adversarias, la inyección de instrucciones, la resistencia a la evasión de restricciones y la calidad de los resultados. Garak abarca específicamente las pruebas de seguridad de LLM en diversas categorías de ataque. Para los profesionales de TPRM, preguntar si las pruebas de seguridad de la IA del proveedor usan un marco de pruebas específico de IA, distinto de las pruebas tradicionales de seguridad de aplicaciones, ofrece una pregunta concreta sobre el programa de pruebas de IA.
Equipo rojo: marco MITRE ATLAS para ataques adversarios contra ML, ejercicios dedicados de equipo rojo de IA
Los ejercicios de equipo rojo de IA dirigidos específicamente al modelo, no solo a la envoltura de la aplicación, prueban categorías adversarias que las herramientas automatizadas pueden pasar por alto. Para los profesionales de TPRM, preguntar si el proveedor ha realizado un ejercicio de equipo rojo de IA, en el que los evaluadores intentan específicamente ataques adversarios contra la lógica de decisión del modelo y no solo contra la aplicación, ofrece una pregunta concreta sobre el equipo rojo de IA.
Desafíos de gobernanza
El desafío de gobernanza de las pruebas de seguridad de la IA es la brecha de conocimientos de los proveedores. Muchos equipos de seguridad de los proveedores tienen sólidos conocimientos de pruebas de seguridad tradicionales y conocimientos limitados de pruebas de seguridad específicas de IA. Solicitar evidencia de pruebas específicas de IA puede revelar que el programa de seguridad del proveedor necesita ampliar su alcance, y no que ya lo ha hecho. La solución de gobernanza consiste en incluir requisitos de pruebas específicas de IA en los contratos con proveedores como obligación de cara al futuro.
- Exija las pruebas de seguridad específicas de IA como categoría de evidencia separada
- Solicite los resultados de las pruebas de entradas adversarias específicas del modelo de IA
- Solicite los resultados de las pruebas de inyección de instrucciones como elemento de evidencia separado
- Solicite la evaluación de la tasa de confabulación en el dominio de implementación de la empresa
- Incluya requisitos de pruebas de seguridad de la IA en los contratos con proveedores
Si usted forma parte de un equipo pequeño
Al revisar la evidencia de seguridad de un proveedor de IA, haga una pregunta aclaratoria antes de aceptar el paquete de evidencia: de la evidencia de pruebas de seguridad que ha proporcionado, ¿qué prueba concreta evaluó el propio modelo de IA, en concreto su resistencia a las entradas adversarias, a la inyección de instrucciones o la exactitud de sus resultados? Si la respuesta es ninguna, ha identificado la brecha en las pruebas de seguridad de la IA. Luego pregunte qué pruebas específicas de IA tiene previsto realizar el proveedor y en qué plazo. La pregunta saca a la luz la brecha. El seguimiento establece si se está abordando.
- Pregunte qué elemento de evidencia probó específicamente el modelo de IA y no la aplicación ni la infraestructura
- Solicite los resultados de las pruebas de entradas adversarias y de inyección de instrucciones como evidencia separada
- Pregunte por la evaluación de la tasa de confabulación en su dominio de implementación
- Incluya requisitos de pruebas de seguridad de la IA en los contratos con proveedores
Qué exigir
Pregunte directamente:
"De la evidencia de pruebas de seguridad que ha proporcionado (SOC 2, pruebas de penetración, SDLC), ¿qué prueba concreta evaluó el propio modelo de IA frente a entradas adversarias, inyección de instrucciones y exactitud de los resultados? ¿Puede proporcionar evidencia separada de pruebas de seguridad específicas de IA para el modelo?"
Evidencia que debe esperar
- Evidencia de pruebas de seguridad específicas de IA: entradas adversarias, inyección de instrucciones
- Resultados de la evaluación de la tasa de confabulación
- Pruebas de integridad de los datos de entrenamiento
- Resultados del ejercicio de equipo rojo de IA
A un proveedor que entrega evidencia de SOC 2, pruebas de penetración y SDLC se le debe pedir evidencia de pruebas específicas de IA como categoría separada. La evidencia tradicional abarca la envoltura. Las pruebas de IA abarcan el modelo. Ambas son necesarias.
Cómo demostrarlo
- Registros de pruebas de seguridad específicas de IA
- Resultados de las pruebas de entradas adversarias y de inyección de instrucciones
- Evaluación de la tasa de confabulación
- Requisitos de pruebas de seguridad de la IA en los contratos con proveedores
Conclusión clave
SOC 2: infraestructura cubierta. Prueba de penetración: aplicación web cubierta. Revisión de código: código de la aplicación cubierto. Modelo de IA: no probado. El paquete de evidencia era real y completo para lo que abarcaba. Lo que abarcaba era la envoltura que rodea a la IA. La propia IA (su resistencia a las entradas adversarias, su comportamiento ante la inyección de instrucciones, su tasa de confabulación, la integridad de sus datos de entrenamiento) no figuraba en ninguno de los tres elementos de evidencia. Los marcos tradicionales de pruebas de seguridad se diseñaron para aplicaciones e infraestructura. Los marcos de pruebas específicos de IA abordan el modelo. Ambos son necesarios. Ninguno sustituye al otro. La pregunta aclaratoria (cuál de estos elementos probó el propio modelo) revela la brecha que se pasaría por alto si se revisara el paquete de evidencia sin hacerla.