🤖 AI

What AI Red-Team Evaluations Can and Cannot Prove

Este artículo establece un "techo de evidencia" calculable para las evaluaciones de red team de IA, demostrando que, si bien los benchmarks actuales pueden certificar eficazmente la seguridad para daños de alta frecuencia, son fundamentalmente insuficientes para probar la seguridad ante riesgos catastróficos poco comunes debido a limitaciones estadísticas inherentes.

Autores originales: Bandana Kaur

Publicado 2026-07-27

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Bandana Kaur

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres un detective intentando resolver un misterio: "¿Es este nuevo robot seguro para dejarlo suelto en el mundo real?". Para averiguarlo, no te limitas a pedirle al robot que diga "soy bueno"; lo sometes a una serie de pruebas truculentas, como un ejercicio de red-teaming donde intentas engañarlo para que diga algo malo o peligroso. Este es el mundo de la evaluación de la seguridad de la IA. Pero aquí está el truco: ¿cuántos trucos necesitas probar antes de poder estar seguro de que el robot es seguro? Si pruebas 10 trucos y pasa, ¿es eso suficiente? ¿Qué pasa si el robot es peligroso solo una vez en un millón de intentos?

Aquí es donde entra la estadística. Piensa en ello como una linterna en una habitación oscura. Una linterna pequeña (una prueba pequeña) puede mostrar fácilmente una roca grande y obvia en el suelo (un error frecuente). Pero si el peligro es una mota de polvo diminuta, casi invisible, que solo aparece de vez en cuando, esa misma linterna pequeña podría pasarla por alto por completo, incluso si la mota está ahí. Los científicos han debatido durante mucho tiempo si estas "pruebas de seguridad" de la IA son realmente útiles o si son simplemente una pérdida de tiempo. Algunos dicen que no prueban nada; otros dicen que lo prueban todo. Este artículo interviene para resolver la disputa haciendo algo muy específico: calcula exactamente qué tan brillante debe ser la linterna para ver diferentes tamaños de polvo.

El artículo, escrito por Bandana Kaur de APIsec Research Labs, sostiene que las pruebas de seguridad no son inútiles, pero tampoco son varitas mágicas. Tienen un límite duro en lo que pueden probar, y ese límite es un problema matemático, no una cuestión de opinión. La autora utiliza un concepto llamado "techo de evidencia". Imagina que tienes un cubo que solo puede contener cierta cantidad de agua. Si estás tratando de probar que una fuga es pequeña, un cubo lleno (una prueba limpia con cero fallos) es muy convincente. Pero si estás tratando de probar que una fuga es diminuta (como un fallo catastrófico poco común), ese mismo cubo podría ser demasiado pequeño para capturar suficiente evidencia para estar seguro.

El hallazgo principal del artículo es que existe un "punto de cruce" calculable. Si un tipo de daño ocurre con la suficiente frecuencia (como el 1% de las veces), una prueba estándar de unos 520 prompts es suficiente para decir: "Bien, este modelo es probablemente lo suficientemente seguro para ser desplegado". De hecho, si realizas 520 pruebas y ves cero problemas, eso es en realidad una evidencia más fuerte que ver solo un problema. Es como encontrar una habitación limpia: si esperas que los gérmenes estén por todas partes, una habitación limpia es una gran sorpresa y demuestra que algo está funcionando.

Sin embargo, el artículo traza una línea dura en la arena para los eventos raros. Si un comportamiento dañino es extremadamente raro (por ejemplo, que ocurra menos del 0,001% de las veces), no importa cuántos prompts intentes dentro de un presupuesto razonable, un "resultado limpio" (cero fallos) no te dice casi nada. La matemática muestra que para estos riesgos catastróficos y raros, un resultado de prueba limpio es una evidencia débil. En esta zona, un solo fallo observado es en realidad más informativo que una prueba limpia, porque la prueba limpia podría ser simplemente mala suerte. El artículo calcula que, para estos eventos raros, los benchmarks públicos actuales están "órdenes de magnitud cortos", lo que significa que son miles de veces demasiado pequeños para probar la seguridad.

La autora también señala que la forma en que se construyen estas pruebas importa. Si las preguntas de la prueba son todas muy similares (como hacer la misma pregunta con palabras ligeramente distintas), es como buscar una aguja en un pajar pero solo revisar una esquina de la habitación. El artículo sugiere que las pruebas actuales a menudo se agrupan, lo que las hace menos efectivas de lo que parecen en el papel. Además, el artículo argumenta contra la idea de que solo necesitamos "más" pruebas. En su lugar, necesitamos pruebas más inteligentes que sean mejores distinguiendo entre un modelo seguro y uno inseguro. Si una prueba puede engañar a un modelo malo el 90% de las veces pero solo a un modelo bueno el 10% de las veces, es una herramienta poderosa. Pero si engaña a ambos por igual, es inútil, sin importar cuántas veces la ejecutes.

Al final, el artículo propone una nueva regla sobre cómo los laboratorios de IA deben informar sus resultados. En lugar de simplemente decir "Realizamos 500 pruebas y no encontramos nada malo", deberían informar exactamente lo que su prueba puede probar. Si la tasa de daño es alta, pueden afirmar la seguridad. Si la tasa de daño es baja y rara, deben admitir que su prueba no pudo probar la seguridad y que necesitan otro tipo de evidencia. El artículo no dice que debamos dejar de hacer pruebas; dice que debemos dejar de pretender que nuestras pruebas pueden probar cosas que matemáticamente no pueden. Es un llamado a la honestidad: conoce los límites de tu linterna, y no pretendas ver toda la habitación si solo estás iluminando una esquina.

Resumen Técnico: Lo que las evaluaciones de Red-Teaming de IA pueden y no pueden probar

Planteamiento del problema
Las prácticas actuales de seguridad de la IA dependen en gran medida de las evaluaciones de red-teaming, donde se utilizan prompts adversarios curados para probar los modelos en busca de salidas dañinas. Estos resultados se utilizan cada vez más como la base empírica principal para la supervisión regulatoria y las decisiones de despliegue. Sin embargo, una crítica creciente sugiere que los resultados cuantitativos de estos benchmarks carecen de precisión estadística, no logran generalizarse a través de prompts semánticamente equivalentes y no pueden sustentar comparaciones significativas entre sistemas. Si bien estas críticas son válidas, el artículo argumenta contra la conclusión de que los benchmarks de seguridad sean "inútiles". En cambio, el problema central es que el campo carece de un marco formal para determinar qué proposiciones específicas puede sustentar una evaluación determinada. Sin esto, los laboratorios pueden sobreestimar la seguridad para daños catastróficos poco frecuentes o subutilizar los benchmarks para daños de alta frecuencia.

Metodología
El artículo introduce un marco estadístico formal para definir el "techo de evidencia" (evidential ceiling) de una evaluación. Este techo representa el factor máximo por el cual un único resultado puede desplazar las probabilidades a posteriori entre dos hipótesis: $H_0$ (riesgo aceptable) y $H_1$ (riesgo elevado).

Derivación del Techo de Evidencia: Los autores definen el techo para un resultado nulo de un benchmark (cero daños observados) en forma cerrada. Utilizando un enfoque de razón de verosimilitud, derivan la máxima evidencia que una hoja limpia puede proporcionar dado un presupuesto de recursos fijo ( $N_{max}$ ) y una tasa de daño ( $p$ ).
Cálculo del Límite: El artículo deriva un límite crítico, $p_{min}$ $p_{min}$ , que separa dos regímenes:
- Por encima de $p_{min}$ : Un benchmark de tamaño factible puede certificar una categoría a un estándar de evidencia establecido. En este régimen, una hoja limpia es la evidencia más fuerte en comparación con un único fallo observado.
- Por debajo de $p_{min}$ : Ningún benchmark pasivo de tamaño factible puede proporcionar la evidencia especificada de seguridad. En este régimen, un solo fallo observado pesa más que una hoja limpia.
Generalización a la Elicitación Adaptativa: El marco se extiende más allá de los benchmarks estáticos hacia el red-teaming adaptativo. Los autores reemplazan la tasa de daño bruta por "tasas de elicitación condicionadas a la hipótesis" ( $q_1$ para $H_1$ y $q_0$ para $H_0$ ). Demuestran que el valor de la evidencia está determinado por la discriminación entre estas tasas ( $\kappa = |\log_2((1-q_1)/(1-q_0))|$ ), no simplemente por la tasa de éxito del ataque.
Auditoría Empírica: Los autores auditan ocho suites de evaluación ampliamente utilizadas (por ejemplo, AdvBench, HarmBench, SafetyBench) frente a estos límites teóricos. Analizan el poder estadístico, las probabilidades de falsa certificación y la validez distributiva (comparando los prompts del benchmark con consultas de usuarios reales de LMSYS-Chat-1M).

Contribuciones Clave

Límite de Forma Cerrada: El artículo proporciona una expresión calculable para el límite entre tasas de daño certificables y no certificables. Este límite cae como $1/n$ , lo que significa que los benchmarks más grandes extienden el rango de daños certificables, pero no pueden superar el límite fundamental para eventos extremadamente raros.
Reversión de la Fuerza de la Evidencia: Los autores demuestan que la fuerza de la evidencia relativa de una "hoja limpia" frente a un "único fallo observado" no es absoluta. Por encima de la tasa de cruce ( $p_\times$ ), una hoja limpia es evidencia más fuerte; por debajo, un solo fallo es evidencia más fuerte. Este punto de cruce también es calculable.
Discriminación sobre Tasa de Éxito: El artículo establece que, para el red-teaming adaptativo o automatizado, la métrica de valor es la discriminación entre las tasas de elicitación bajo hipótesis seguras e inseguras, no la tasa bruta de éxito del ataque. Un procedimiento que se activa por igual en modelos seguros e inseguros proporciona cero evidencia.
Plantilla de Reporte: Se propone una plantilla de reporte mínimo (Tabla 5) que requiere que los laboratorios publiquen parámetros específicos (por ejemplo, tamaño de muestra efectivo, correlación intra-clúster, tasas de elicitación bajo $H_0$ y $H_1$ ) para permitir que el valor de la evidencia de un resultado sea ponderado.

Resultados

Adecuación para Daños de Alta Frecuencia: Para categorías de daño con tasas alrededor de $10^{-2}$ (1%), los benchmarks públicos existentes (por ejemplo, AdvBench con $n=520$ ) son adecuados para sustentar afirmaciones de mejoras de seguridad de un orden de magnitud.
Inadecuación para Daños Raros/Catastróficos: Para categorías raras (por ejemplo, $p = 10^{-4}$ o $10^{-5}$ ), los benchmarks actuales se quedan cortos por varios órdenes de magnitud. El artículo encuentra que ningún benchmark de tamaño factible ( $N_{max} \approx 10^5$ ) puede certificar la ausencia de daños en estas tasas.
Brecha Distributiva: El análisis empírico muestra que los prompts de los benchmarks están mensurablemente separados de la distribución de tráfico de despliegue ordinario (un exceso de 3.1 a 3.5 veces en métricas de distancia). Si bien esto no limita la distancia al tráfico adversario, confirma que los benchmarks no representan las distribuciones de usuarios ordinarios.
Efectos de Agrupamiento (Clustering): Los benchmarks del mundo real exhiben agrupamiento (prompts derivados de plantillas), lo que reduce el tamaño de muestra efectivo ( $n_{eff}$ ) y empuja el límite certificable hacia arriba, limitando aún más la utilidad de las suites actuales para eventos raros.

Significancia y Reivindicaciones
El artículo afirma que los benchmarks de seguridad no son informativos, sino que son informativos sobre un "conjunto específico y computable de proposiciones". La significancia radica en cambiar la disciplina de preguntar si los benchmarks funcionan a definir qué pueden probar.

Los autores argumentan que el límite entre lo que se puede y no se puede probar es una cuestión de cálculo, no de juicio experto. Al formalizar este límite, el artículo propone una disciplina donde los laboratorios puedan determinar antes de ejecutar una evaluación si su diseño sustenta una afirmación de certificación específica. Si una categoría de daño cae por debajo del límite calculable, la disciplina debería dejar de intentar certificarla mediante benchmarks de resultado nulo y, en su lugar, confiar en evidencia ajena a los benchmarks. El artículo concluye que la "sobrecorrección" actual que afirma que los benchmarks son inútiles es incorrecta; más bien, los benchmarks son instrumentos precisos con una resolución calculable que debe declararse explícitamente en los informes de seguridad.

Más como este