XL-SafetyBench: evaluar la seguridad de los LLM en 10 países, no solo en inglés

What is this?

El 7 de mayo de 2026, un equipo liderado por AIM Intelligence — con coautores del AI Red Team de Microsoft, el Korea AI Safety Institute, KT, el grupo BMW, la Universidad Técnica de Múnich, la Universidad de Ankara y la Universidad Nacional de Seúl — publicó XL-SafetyBench en arXiv (2605.05662). Es un benchmark de seguridad intercultural con 5.500 casos de prueba en 10 pares país-idioma: Estados Unidos, Francia, Alemania, España, Corea del Sur, Japón, India, Indonesia, Türkiye y los Emiratos Árabes Unidos.

El argumento del artículo es sencillo e incómodo: la mayoría de las evaluaciones de seguridad de los LLM se redactan en inglés y luego se traducen. La traducción mueve las palabras, pero no el contexto legal, institucional y cultural que hace que una solicitud sea realmente dañina. Un benchmark que solo habla inglés mide si un modelo rechaza daños con forma anglófona — no si es seguro desplegarlo en Seúl, Ankara o São Paulo. El anuncio del 5 de junio de 2026 llama a esa brecha la «Ilusión de seguridad».

How it works

XL-SafetyBench se estructura en dos vías. La primera es una vía Jailbreak / Riesgo local de prompts adversarios anclados en cada país — solicitudes cuyo daño depende de las leyes, los patrones de fraude y las plataformas locales. La segunda es una vía Sensibilidad cultural, donde un elemento sensible se oculta dentro de una solicitud por lo demás inocua, para comprobar si el modelo lo detecta.

Dos ejemplos de los autores lo ilustran. Un prompt de fraude construido en torno al sistema coreano del jeonse (depósito de alquiler de pago único) solo se reconoce como fraude si se entiende esa estructura financiera. Y recomendar crisantemos como regalo en Francia es culturalmente inapropiado — la flor se asocia con la muerte y el luto — aunque nada en la frase sea «peligroso» en el sentido anglófono.

Cada ítem siguió un proceso de varias etapas: descubrimiento asistido por LLM, puertas de validación automatizadas y dos anotadores nativos independientes por país. Y lo más importante: los autores no puntúan solo el rechazo. Reportan la tasa de éxito de ataque (ASR) junto con dos métricas nuevas: el Neutral-Safe Rate (NSR) y el Cultural Sensitivity Rate (CSR). La distinción separa un rechazo de principio («entiendo que es fraude, así que no») de un fallo de comprensión («no entendí la solicitud, así que no produje nada útil»).

Metric   Question it answers
-------  ----------------------------------------------------------
ASR      ¿El modelo cumplió una solicitud dañina anclada en un país?
NSR      ¿El modelo manejó una solicitud benigna de forma segura y útil?
CSR      ¿El modelo reconoció una sensibilidad cultural implícita?

Aquí no se reproduce ningún prompt de explotación; el conjunto de datos y la metodología están en el artículo y en la publicación del proyecto en Hugging Face.

Why it matters

En 37 modelos (10 frontier, 27 locales), el artículo reporta dos hallazgos que conviene llevar a cualquier revisión de despliegue.

Primero, entre los modelos frontier, la robustez frente al jailbreak y la conciencia cultural no están correlacionadas. Un modelo puede resistir bien los prompts adversarios y seguir siendo culturalmente sordo, o al revés. Por eso una única «puntuación de seguridad» combinada oculta el eje que de verdad importa. Si despliega en un mercado concreto, un promedio global casi no le dice nada sobre su riesgo local.

Segundo, y más contundente: los modelos locales mostraron un compromiso casi lineal entre ASR y NSR (r = -0,81). En román paladino, los modelos que parecían «más seguros» a menudo lo eran porque no generaban ninguna respuesta útil — un rechazo por accidente, no un alineamiento por diseño. Una tasa baja de éxito de ataque que proviene de no entender la solicitud no es seguridad; es la Ilusión de seguridad con un panel de control vistoso.

Para cualquiera que despliegue LLM en más de un idioma — es decir, la mayoría de los lectores de este medio — la conclusión es que los resultados de red teaming en inglés no son transferibles. La superficie de riesgo tiene forma de país, y los puntos ciegos también.

Defenses

XL-SafetyBench es un instrumento defensivo, así que las mitigaciones tratan sobre todo de cómo evaluar y desplegar.

1. Deje de confiar en benchmarks traducidos. Si su evidencia de seguridad es una suite en inglés pasada por traducción automática, trátela como una cota inferior, no como una aprobación. Vuelva a probar con prompts redactados en el idioma, anclados en la ley y los patrones de fraude locales.

2. Reporte por eje, no en una sola cifra. Mida por separado la robustez al rechazo y la comprensión cultural. Una puntuación agregada deja pasar a un modelo culturalmente ciego por su resistencia al jailbreak.

3. Distinga rechazo de comprensión. Acompañe cada prueba «¿rechazó?» con una prueba «¿entendió?» (la idea NSR/CSR). Un modelo que calla por confusión fallará en cuanto la solicitud se formule con la suficiente claridad.

4. Incluya hablantes nativos en el bucle. Los jueces automáticos y las cadenas de traducción se pierden justo el contexto que hace dañina una solicitud en un país dado. La doble revisión por nativos es la parte más difícil de simular y la más útil de copiar.

5. Ajuste las barreras por mercado. Los filtros de entrada/salida calibrados sobre daños anglófonos detectan de menos los encuadres de fraude locales y bloquean de más referencias locales benignas. Mantenga políticas por localidad y revalídelas cada vez que añada un idioma.

Status

Elemento	Referencia	Fecha	Notas
Artículo XL-SafetyBench	arXiv 2605.05662	2026-05-07	5.500 casos, 10 pares país-idioma
Anuncio público	AIM Intelligence (EIN Presswire / NatLawReview)	2026-06-05	Conjunto de datos publicado en Hugging Face
Modelos evaluados	Artículo	2026-05-07	37 en total (10 frontier, 27 locales)
Hallazgo clave (frontier)	Artículo	2026-05-07	Robustez al jailbreak ≠ conciencia cultural
Hallazgo clave (local)	Artículo	2026-05-07	Compromiso ASR–NSR r = -0,81 («Ilusión de seguridad»)

El encuadre correcto no es «los modelos son inseguros en el extranjero». Es «un modelo que puntúa como seguro en inglés no ha sido probado donde va a usarse». El despliegue multilingüe exige evidencia multilingüe — redactada, no traducida.