Por qué un único interruptor de rechazo no distingue a un pentester de un atacante

¿Qué es esto?

Un artículo publicado en arXiv a principios de julio de 2026, «Not All Refusals Are Equal: How Safety Alignment Fails Cybersecurity at Scale», plantea un punto relevante para cualquiera que realice trabajo de seguridad autorizado con modelos de lenguaje: el comportamiento de rechazo entrenado en los modelos alineados distingue mal los dominios y distingue mal la intención benigna de la maliciosa. Una petición para explicar una corrupción de memoria y así corregirla, y una petición para explotarla, se parecen a ojos del mecanismo que decide si rechazar. El resultado es un sistema que rechaza en exceso preguntas legítimas de ciberseguridad y que, en los modelos de pesos abiertos, expone un mecanismo de rechazo que puede aislarse de forma selectiva.

Tratamos esto como una lectura de investigación y defensa, no como una receta. El artículo publica un análisis de cómo se representa el rechazo; no hace falta reproducirlo para entender la lección. El valor está en lo que dice sobre tratar el rechazo integrado de un modelo como si fuera una frontera de seguridad.

Cómo funciona

Trabajos previos de interpretabilidad establecieron que la tendencia de un modelo a rechazar queda capturada en gran medida por una «dirección de rechazo» de baja dimensión en su espacio de activaciones. Este artículo sostiene que el panorama es más distribuido que un único vector: en un estudio de 24 modelos de código abierto, el rechazo ocupa un subespacio multidimensional y —sobre todo en modelos de mezcla de expertos muy grandes, como un Kimi K2 de un billón de parámetros— ese subespacio está repartido ampliamente entre capas en lugar de concentrado en un solo lugar.

Suposición común: rechazo = 1 dirección, 1 lugar   -> un "interruptor de seguridad"
Realidad observada: rechazo = un subespacio, N capas -> distribuido, entrelazado
Consecuencia:       el concepto "ciber-dañino" no está limpiamente aislado
                    de "ciber-legítimo" -> el mismo circuito se activa para ambos

Como el concepto está entrelazado y es ciego al dominio, se siguen dos cosas. Primero, la misma circuitería que bloquea peticiones realmente peligrosas también se activa ante peticiones legítimas cercanas: el exceso de rechazo que frustra a los defensores. Segundo, sobre pesos abiertos donde todos los parámetros están expuestos, una representación de rechazo distribuida sigue siendo algo que los investigadores pueden caracterizar y manipular, lo que significa que un alineamiento aplicado únicamente mediante el rechazo no es un control duradero sobre un modelo que se ha entregado a un tercero.

Por qué importa

Para los equipos azules y los ingenieros de seguridad, el coste inmediato es el exceso de rechazo. Un modelo que se niega a razonar sobre la mecánica de un exploit, el comportamiento de un malware o el análisis de registros «por si acaso» es peor que inútil durante un incidente: empuja a los profesionales hacia herramientas no alineadas. El artículo lo enmarca como un defecto de diseño: el alineamiento trata «la ciberseguridad» como un peligro monolítico, cuando la mayor parte del trabajo es defensivo y autorizado.

Para quien despliega o depende de modelos de pesos abiertos, la segunda lección es más contundente. Si el rechazo es lo único que separa los pesos de una salida dañina, ese control viaja con los pesos y puede erosionarse. Una seguridad que vive por completo dentro del modelo no es una frontera que se pueda hacer cumplir una vez que el modelo escapa a tu control. Es la misma conclusión a la que ha llegado la comunidad sobre los jailbreaks y la manipulación de direcciones de rechazo, ahora medida a escala de un billón de parámetros.

Defensas

No trates el rechazo del modelo como una frontera de control de acceso. El rechazo es un valor por defecto útil, no una garantía; haz cumplir lo que un modelo tiene permitido hacer con controles externos —permisos de herramientas, aislamiento (sandbox), filtrado de salidas y aprobación humana en acciones de consecuencia— en lugar de confiar en que el modelo se vigile a sí mismo.

Diseña explícitamente para el trabajo de seguridad autorizado. Los equipos que necesiten modelos para tareas defensivas deberían preferir modelos y prompts de sistema que gestionen el contexto y la autorización, para que el análisis legítimo no se rechace en bloque. Distingue «quién pregunta y bajo qué autorización» de «este tema es sensible».

Añade capas de defensa alrededor de los despliegues de pesos abiertos. Si ejecutas pesos abiertos, asume que el rechazo integrado puede degradarse y añade clasificadores de entrada/salida independientes, monitorización y controles de tasa que operes tú, para que una sola copia manipulada no se convierta en una capacidad sin vigilancia.

Mide el exceso de rechazo, no solo la falta de rechazo. Evalúa los modelos por los falsos rechazos de consultas de seguridad legítimas además de por los bloqueos exitosos de las dañinas; una barrera ajustada solo contra los bypass romperá en silencio los flujos de trabajo de los defensores.

Rastrea la procedencia de los pesos. Trata como no fiables los pesos de fuentes no verificadas; prefiere distribuciones firmadas y verificadas por suma de comprobación, así como los canales de los proveedores, porque un modelo cuyo comportamiento de seguridad ha sido alterado parece idéntico desde fuera.

Estado

Elemento	Detalle
Divulgación	Artículo de investigación, arXiv, principios de julio de 2026; sin CVE
Alcance	Análisis sobre 24 modelos de código abierto; ejemplo MoE de un billón de parámetros
Hallazgo central	El rechazo es un subespacio multidimensional, repartido entre capas; ciego al dominio
Impacto práctico	Exceso de rechazo del trabajo de seguridad legítimo; el rechazo no es un control duradero en pesos abiertos
Clase afectada	LLM de pesos abiertos alineados en general
Postura de mitigación	Enforcement externo, filtrado en capas, evaluación del exceso de rechazo, procedencia de los pesos