Volver al blog

Qwen3 27B Obliterated: cuando borrar los guardrails de un LLM es trivial

Qwen3 27B Obliterated: cuando borrar los guardrails de un LLM es trivial

📌 TL;DR. OBLITERATUS ha publicado en Hugging Face una versión modificada de Qwen3.8-27B de Alibaba que elimina prácticamente todos sus comportamientos de rechazo mediante una técnica llamada abliteration, sin reentrenamiento completo. Las versiones V2/V3 reportan tasas de rechazo cercanas al 0% con una pérdida de rendimiento general de apenas ~2 puntos en MMLU. Esto no es solo una curiosidad técnica: demuestra que los guardrails de seguridad de cualquier modelo open-weight son reversibles con herramientas accesibles, y obliga a repensar cómo se diseña la seguridad en sistemas de IA para entornos empresariales.


El contexto: un modelo de 27B sin frenos

Qwen3.8-27B es el modelo multimodal de Alibaba de 27.000 millones de parámetros, parte de la familia Qwen3, con capacidades sólidas en razonamiento, código y tareas multilingües. Como todos los modelos de su categoría, llega con un conjunto de restricciones de seguridad entrenadas: rechaza ciertos tipos de peticiones, añade advertencias, se niega a generar determinados contenidos.

El repositorio OBLITERATUS/Qwen3.8-27B-OBLITERATED en Hugging Face distribuye una versión de ese mismo modelo a la que se le ha aplicado abliteration, una técnica de edición de pesos que elimina esas restricciones de forma quirúrgica [1][2][3]. El resultado es un modelo que responde donde el original se habría negado, distribuido en múltiples formatos listos para ejecutar en hardware de consumo.

Lo que hace relevante este caso no es la existencia de modelos "uncensored" en sí, que llevan años circulando. Lo que importa es la madurez técnica y la accesibilidad del proceso, y lo que eso implica para cualquiera que construya productos sobre modelos open-weight.


Qué es la abliteration y cómo funciona

La abliteration no es un jailbreak de prompt. No consiste en engañar al modelo con instrucciones elaboradas para que ignore sus restricciones. Opera a un nivel más profundo: modifica directamente los pesos del modelo.

El procedimiento, en términos accesibles, funciona así:

  1. Se recopila un conjunto de prompts que el modelo base rechaza sistemáticamente.
  2. Se analiza cómo se activan las capas internas del modelo ante esos prompts, buscando las direcciones en el espacio de representaciones que corresponden al comportamiento de rechazo.
  3. Esas direcciones se proyectan fuera del espacio de activaciones, es decir, se eliminan mediante una operación matemática sobre los pesos. El modelo deja de "ver" esa señal interna que le indica que debe rechazar.
  4. El resultado es un modelo cuyos pesos ya no contienen esa representación de rechazo, sin necesidad de reentrenar desde cero ni de ajuste fino supervisado extenso [1][4][5].

La diferencia con un jailbreak es fundamental: un jailbreak se puede detectar y bloquear en el nivel del prompt con filtros. La abliteration actúa sobre el modelo en sí. No hay prompt que revertir; el comportamiento modificado está en los pesos.

Las versiones V2 y V3 de OBLITERATUS reportan tasas de rechazo prácticamente del 0% en baterías de más de 1.000 prompts restringidos, incluyendo tanto rechazos explícitos como respuestas tipo sermón de seguridad [4][5]. La pérdida en benchmarks generales como MMLU es del orden de ~2 puntos porcentuales frente al modelo base, lo que indica que la capacidad general del modelo se preserva en gran medida [4].

"Abliteration removes refusals at the weight level, not the prompt level. There is no system prompt that can undo it."

Esta frase, implícita en la documentación técnica del repositorio, resume el problema central para cualquier arquitectura de seguridad que dependa exclusivamente del modelo.


Distribución y adopción: no es un experimento marginal

El modelo se distribuye en formatos que cubren prácticamente todo el ecosistema de inferencia local y en la nube:

  • GGUF para llama.cpp, Ollama y LM Studio, con cuantizaciones desde Q2_K (~11 GB) hasta Q8_0 (~27 GB) [3][4].
  • Safetensors en precisión completa y shards bfloat16 de ~54 GB para uso directo con Transformers [4].
  • MLX para hardware Apple Silicon [4].

Existen forks y cuantizaciones externas de terceros (mradermacher, legatos, bzannah) que amplían la distribución más allá del repositorio original [3][5]. Servicios de inferencia comerciales como NanoGPT y Wiro AI lo ofrecen como modelo de chat y código de contexto largo, monetizado por tokens de salida, con énfasis explícito en menos rechazos y mayor control de decodificación [6][7].

El repositorio ha acumulado centenares de likes y decenas de miles de descargas en 2026 [5]. Y no es el único: proyectos paralelos como Huihui-Qwen3.8-27B-abliterated aplican la misma técnica al mismo modelo base, lo que confirma que la abliteration sobre Qwen3.8-27B se está convirtiendo en una práctica estandarizada, no en un experimento aislado [8].

Esto tiene una implicación directa: si construyes un producto que integra modelos de Hugging Face o APIs de terceros, la probabilidad de que en tu cadena de suministro aparezca un modelo abliterado sin que lo sepas está aumentando.


Por qué importa a empresas que usan IA

Para un empresario que está evaluando o ya ha desplegado soluciones de IA, este caso plantea tres preguntas concretas.

1. ¿Confías en los guardrails del modelo como única capa de seguridad?

Si la respuesta es sí, este caso debería cambiarla. Los guardrails entrenados en un modelo open-weight no son inmutables. Cualquier tercero con acceso a los pesos puede eliminarlos. Si tu proveedor de API usa un modelo abliterado sin declararlo, o si alguien en tu equipo descarga un fork de Hugging Face sin verificar su procedencia, los filtros de seguridad del modelo base ya no están ahí.

La seguridad basada exclusivamente en el comportamiento del modelo es, en el contexto open-weight, una ilusión.

2. ¿Qué regulación te aplica?

En la UE, el AI Act y el DSA establecen obligaciones sobre sistemas de IA que generan contenido, especialmente cuando se despliegan hacia usuarios finales. Usar un modelo explícitamente diseñado para eliminar restricciones de seguridad en un producto de cara al cliente no es solo un riesgo técnico: es un riesgo de cumplimiento regulatorio con consecuencias legales y reputacionales concretas [1][2].

Esto no significa que los modelos abliterados no tengan casos de uso legítimos. Significa que esos casos de uso requieren gobernanza explícita, no ignorancia.

3. ¿Hay casos de uso internos donde menos rechazos tiene sentido?

Sí. Un asistente de código interno, un agente de análisis de datos sensibles, una herramienta de investigación en sectores como legal, médico o seguridad, pueden beneficiarse de un modelo que no se bloquea ante terminología técnica o contextos que un modelo de consumo rechazaría por precaución excesiva.

Pero la diferencia entre ese caso de uso legítimo y uno problemático no está en el modelo: está en el entorno de despliegue, los controles de acceso, la trazabilidad de prompts y la moderación externa.


Para desarrolladores: lo que este caso enseña sobre alineamiento

La abliteration es, antes que nada, un caso de estudio sobre la naturaleza de las representaciones internas de seguridad en LLMs.

El hecho de que sea posible identificar y proyectar fuera las direcciones de rechazo sugiere que el comportamiento de seguridad entrenado mediante RLHF o instrucciones está localizado en el espacio de representaciones de una forma relativamente compacta y separable del resto de capacidades. No está distribuido de forma uniforme por todo el modelo; si lo estuviera, eliminarlo destruiría el rendimiento general. Que la pérdida en MMLU sea de solo ~2 puntos confirma esta separabilidad [4].

Esto tiene implicaciones técnicas importantes:

  • El alineamiento basado solo en RLHF o fine-tuning de instrucciones no es robusto frente a edición de pesos. Es una capa de comportamiento, no una propiedad estructural del modelo.
  • La seguridad en sistemas LLM debe diseñarse en capas: modelo + filtros de entrada/salida + políticas de uso + monitorización de prompts + controles de acceso. Ninguna capa sola es suficiente.
  • La abliteration como herramienta de investigación permite estudiar dónde y cómo se representan los valores y restricciones en un LLM, lo que puede informar el diseño de modelos con modos diferenciados (producción vs. laboratorio) mediante cambios controlados de pesos o cabezales específicos.

Para cualquier equipo que trabaje en fine-tuning, RAG o agentes sobre modelos open-weight, entender que los pesos son modificables por terceros obliga a diseñar la arquitectura de seguridad asumiendo que el modelo puede haber sido alterado. La verificación de integridad de los pesos (hashes, checksums, procedencia verificada) pasa a ser una práctica de seguridad básica, no opcional.


Lecciones accionables

  1. Implementa seguridad en capas, no solo en el modelo. Los guardrails entrenados son reversibles. Añade moderación de contenido en la capa de aplicación, filtros de entrada y salida independientes del modelo, y monitorización de prompts. Trata el modelo como una caja que puede haber sido modificada.

  2. Antes de adoptar un modelo uncensored en un entorno empresarial, realiza una evaluación de riesgos explícita. Cubre el plano legal (AI Act, DSA, normativa sectorial), reputacional y de cumplimiento. Documenta la decisión. Si el modelo se despliega hacia usuarios finales, los riesgos son cualitativamente distintos a un uso interno controlado.

  3. Para aplicaciones técnicas avanzadas en entornos controlados, los modelos con menos rechazos tienen sentido. Coding assistants internos, agentes de análisis, herramientas de investigación: estos casos de uso pueden justificar el uso de modelos abliterados. La condición es que estén confinados a intranets o sandboxes, con acceso restringido y trazabilidad completa de las interacciones.

  4. Verifica la procedencia e integridad de los modelos que integras. Cuando descargas un modelo de Hugging Face o usas una API de terceros, confirma que el modelo es el que dice ser. Los forks y cuantizaciones externas pueden introducir modificaciones sin declarar. Comprueba hashes y revisa la ficha del modelo antes de integrarlo en producción.

  5. Monitoriza el ecosistema de servicios que distribuyen este tipo de modelos. NanoGPT, Wiro AI y otros ya ofrecen Qwen3.8-27B-OBLITERATED como servicio comercial [6][7]. La cadena de suministro de IA incluye cada vez más modelos con comportamientos modificados. Saber qué modelos usa tu stack, y qué modificaciones han recibido, es parte de la gestión de riesgos de IA.


Una reflexión final sobre el ecosistema open-weight

El caso de Qwen3.8-27B-OBLITERATED no es una anomalía. Es la consecuencia lógica de distribuir modelos como pesos abiertos: quien tiene los pesos puede modificarlos. Eso es, al mismo tiempo, lo que hace los modelos open-weight valiosos (control, personalización, privacidad) y lo que hace inviable depender de sus guardrails como garantía de seguridad.

La respuesta correcta no es cerrar los modelos ni ignorar el problema. Es diseñar sistemas de IA que asuman desde el principio que el modelo es un componente no confiable en sí mismo, y que la seguridad emerge de la arquitectura completa del sistema, no de las intenciones del laboratorio que entrenó el modelo base.

Si estás construyendo sobre LLMs open-weight y quieres revisar cómo está diseñada tu arquitectura de seguridad, o si estás evaluando si un modelo como este tiene sentido en algún flujo de trabajo de tu empresa, puedes explicarme tu caso en /contacto.


Fuentes

[1] OBLITERATUS/Qwen3.8-27B-OBLITERATED — Hugging Face: https://huggingface.co/OBLITERATUS/Qwen3.8-27B-OBLITERATED

[2] Qwen3.8-27B OBLITERATED: How This Uncensored Model Works — MindStudio: https://www.mindstudio.ai/blog/qwen3-27b-obliterated-uncensored-model

[3] mradermacher/Qwen3.8-27B-OBLITERATED-GGUF — Hugging Face: https://huggingface.co/mradermacher/Qwen3.8-27B-OBLITERATED-GGUF

[4] Qwen3.8-27B OBLITERATED: How V3 Abliteration Cuts Refusals — MindStudio: https://www.mindstudio.ai/blog/qwen38-27b-obliterated-uncensored-model

[5] bzannah/Qwen3.8-27B-OBLITERATED — Featherless: https://featherless.ai/models/bzannah/Qwen3.8-27B-OBLITERATED

[6] Qwen 3.8 27B Obliterated model — NanoGPT: https://nano-gpt.com/models/text/qwen/qwen3.8-27b-obliterated

[7] Wiro AI — referencia a integración de Qwen3.8-27B-OBLITERATED como servicio de inferencia comercial

[8] Huihui-Qwen3.8-27B-abliterated — proyecto paralelo de abliteration sobre el mismo modelo base (Hugging Face)