Seguridad selectiva en LLM: negar el subconjunto correcto, no todo el tema

El problema: la seguridad tratada como categoría amplia

En muchos esfuerzos de alineamiento, el daño se asume como una propiedad del tema. Un prompt es inseguro si cae en categorías generales como armas, fraude o autolesiones. Guard models como LlamaGuard-3 replican exactamente ese enfoque por tópico, y benchmarks como XSTest u OR-Bench muestran el fallo típico: modelos que rechazan prompts seguros solo por contener una palabra que parece peligrosa. Corregir la calibración de rechazo suele ser el objetivo inmediato.

Pero las implementaciones reales raramente encajan en esa imagen de “todo o nada” por tema. El mismo modelo base puede usarse en un asistente general, un producto educativo, un sistema empresarial o un servicio público; cada uno requiere límites distintos dentro del mismo tema. Por ejemplo, un tutor de civismo y un asistente del sector público pueden compartir un modelo y ambos deben responder preguntas fácticas sobre elecciones, pero solo uno deberá negarse a redactar manipulación política dirigida. Un guard a nivel de tema no puede expresar esa diferencia.

De tema a frontera: ¿qué es realmente inseguro para un despliegue?

La idea central es desplazar la pregunta: no se trata de si todo un tema debe rechazarse, sino qué subconjunto de ese tema es incompatible con la política de despliegue. En la investigación que resumimos, ese límite se formaliza como un “conjunto dañino objetivo” dentro del universo temático (en sus experimentos, todo lo político) que debe rechazarse, mientras que el complemento benigno debe seguir siendo atendido. El comportamiento ideal sería un escalón nítido: rechazar dentro del subconjunto y responder en todo lo demás del tema.

En la práctica, un modelo entrenado aprende una probabilidad de rechazo suave que solo aproxima ese escalón. Entrenar para aumentar el rechazo dentro del subconjunto dañino puede, sin querer, empujar el rechazo hacia el territorio benigno vecino. Entonces el problema real incluye dar forma al comportamiento cercano a la frontera: minimizar el derrame hacia ejemplos permitidos.

Cómo operacionalizar la frontera

Para medir y entrenar contra esa frontera, se usan pares de prompts que comparten el mismo anclaje temático y difieren solo en la intención: uno debería rechazarse (por ejemplo, pedir tácticas de persuasión dirigida) y el otro deberia responderse (por ejemplo, preguntar por historia o datos fácticos). La persuasión política es un buen banco de pruebas: la manipulación puede causar daño real, mientras que la información política fáctica es legítima.

Por qué falla la auto-generación de datos de seguridad

Una forma natural de generar datos es la auto-generación: tomar el modelo objetivo, dirigirlo para que produzca un rechazo en cada prompt dañino, y conservar las trazas que un guard verifica como rechazos genuinos. Métodos como ThinkSafe siguen este flujo y fue adoptado como referencia. Plantear la seguridad como una frontera revela tres debilidades en ese pipeline estándar:

1. Brecha de cobertura. Un solo intento de steering no siempre produce un rechazo aceptado, y esos prompts suelen eliminarse silenciosamente del conjunto de entrenamiento. En la auditoría reportada, la generación de un solo intento descartó 19.88% de los prompts (8,009 de ellos). Es probable que esos fallos incluyan los ejemplos más difíciles.

2. Reacciones adversas (over-rejection). Ajustar la seguridad tiende a generar rechazos falsos en prompts benignos que solo lucen peligrosos superficialmente.

3. Métricas que no miden la forma de la frontera. Un modelo puede mejorar la tasa de rechazo en dañinos simplemente expandiendo el rechazo hacia prompts permisibles cercanos; una métrica a nivel de tema podría llamarlo una mejora cuando en realidad es un empeoramiento.

Tres reparaciones prácticas

Los investigadores proponen tres medidas concretas para abordar esas fallas, sin las cuales los checkpoints pueden parecer seguros cuando en realidad son “máquinas de rechazo”:

• Escalada de cobertura (retry escalonado). En vez de desechar los prompts que fallan en un primer intento de steering, re-muestrean el mismo prompt con estrategias de steering progresivamente más fuertes. Con este plan, las fallas residuales bajaron a 0.20% (79 prompts), dejando 40,293 prompts dañinos para entrenamiento donde la estrategia ingenua habría tirado miles.

• Datos benignos en-distribución. Para evitar reacciones adversas, incluyen en el entrenamiento ejemplos benignos verificados que tienen aspecto superficialmente peligroso. El conjunto incluye 11,955 prompts benignos que parecen peligrosos, organizados en 18 tipos semánticos, de modo que el modelo aprende a ver estas formulaciones como seguras.

• Medición de la frontera con pares held-out. Los pares separados (1,539 por lado) permiten evaluar directamente ambos costados de la frontera: cuánto se rechaza lo dañino y cuánto se sobre-rechaza lo benigno cercano.

Resultados: la trampa de la aparente mejora

Entrenar con datos de rechazo político mejora métricas obvias. En Qwen3-8B, el modelo con cobertura escalada aumentó el rechazo político en-distribución de 9.47% a 84.75%. Además, hubo transferencia: la tasa media de respuestas inseguras en tres benchmarks más amplios (HarmBench, StrongREJECT y WildJailbreak), evaluada por LlamaGuard-3, cayó de 26.26% a 0.14% en la configuración más fuerte.

Sin embargo, esos números no cuentan la historia completa. En el mismo punto de control, el sobre-rechazo en XSTest subió de 2.00% a 74.00%. La configuración que obtiene la menor tasa de respuestas dañinas también rechazaba casi tres cuartos de prompts claramente seguros. En otras palabras, parecía una victoria hasta que se midió el lado benigno: se transformó en una máquina de rechazo contundente, no en un modelo realmente más seguro.

Lección central y recomendaciones para despliegues

El mensaje central es que la composición de los datos define dónde queda un checkpoint en el espacio que contrapone seguridad contra sobre-rechazo. Por eso ambas dimensiones deben reportarse juntas: cuánto rechazo hay en lo dañino y cuánto sobre-rechazo hay en lo benigno cercano.

Para equipos de producto y responsables de políticas en América Latina esto tiene implicaciones prácticas:

• Definan políticas de despliegue finas por caso de uso. Una solución “one-size-fits-all” por tema puede bloquear servicios críticos (p. ej. información cívica) o permitir abusos en otros contextos.

• Exijan métricas duales en evaluaciones de seguridad: tasas en ejemplos dañinos y tasas en ejemplos benignos que parezcan peligrosos.

• Adopten pipelines de generación de datos que incluyan reintentos escalados y ejemplos benignos en-distribución para mejorar cobertura sin aumentar el sesgo de rechazo.

• Evalúen con pares de frontera (intent-clones) para entender el derrame hacia el lado benigno.

Conclusión

Proteger a usuarios y organizaciones no se logra solo negando tópicos completos; se requiere delimitar qué subset exacto de un tema es inapropiado para un despliegue y enseñar al modelo a respetar esa frontera. Técnicas como escalada de cobertura y entrenamiento con benignos verificados, combinadas con métricas que midan ambos lados de la frontera, permiten acercarse a ese objetivo. Para los responsables en la región, la clave es integrar estas mediciones en los criterios de aceptación antes de poner en producción cualquier guard de seguridad.