Ataques de bloqueo en RAG: convertir la alineación de seguridad en un arma de denegación

¿Qué es esto?

La mayoría de los ataques contra sistemas RAG (Retrieval-Augmented Generation) buscan que el modelo diga algo incorrecto: inyectar un documento y obtener una respuesta errónea o elegida por el atacante. Un ataque de bloqueo hace lo contrario: consigue que el modelo se niegue a responder a una pregunta perfectamente benigna. El objetivo no es la integridad, sino la disponibilidad. Un usuario formula una consulta legítima, el sistema recupera un documento plantado y el modelo responde con alguna variante de «no puedo ayudarte con eso».

Un estudio publicado en arXiv en marzo de 2026 por investigadores de la University of Electronic Science and Technology of China y de Tencent Hunyuan (un marco que denominan TabooRAG) convierte esta idea en una técnica concreta y transferible. Su observación central es incómoda: la alineación de seguridad del modelo es la vulnerabilidad. Como los modelos alineados están ajustados para sobre-rechazar todo lo que parezca arriesgado, un atacante puede elaborar un documento que rodee una consulta inofensiva de un «contexto de riesgo restringido» —contenido que se lee como sensible— y activar el reflejo de rechazo del modelo. Sin jailbreak, sin sufijo adversario, sin instrucción explícita de «rechaza esto». El tema es actual: los ataques de disponibilidad que instrumentalizan los mecanismos de seguridad son una línea de investigación viva en 2026. Otro artículo de junio de 2026 mostró la misma idea contra barreras basadas en razonamiento, atrapándolas en costosos bucles de «pensamiento» en lugar de inducir un rechazo.

Cómo funciona

Las bases de conocimiento RAG suelen estar parcialmente abiertas: wikis al estilo de Wikipedia, foros comunitarios, sistemas de tickets, cualquier corpus donde terceros puedan contribuir. Esa vía de carga es el punto de inyección. El atacante añade un único documento diseñado para dos cosas a la vez: quedar clasificado lo bastante alto como para ser recuperado en una consulta objetivo, y llevar un encuadre que empuje al generador hacia el rechazo.

Lo interesante es esta segunda propiedad. Los ataques de bloqueo anteriores añadían sufijos adversarios a los documentos o insertaban instrucciones burdas del tipo «olvida la pregunta y rechaza». Esas técnicas fallan cada vez más, porque los modelos recientes están entrenados para separar las instrucciones genuinas del usuario del texto hallado en el contexto recuperado. Así que, en lugar de decirle al modelo que rechace, el documento envenenado hace que el tema parezca peligroso: construye alrededor de la pregunta legítima un escenario relevante pero de alto riesgo, de modo que la capa de seguridad concluye por sí misma que responder sería dañino.

La segunda enseñanza estructural es la homogeneidad de la alineación. Los distintos proveedores entrenan sobre categorías de rechazo que se solapan —daño físico, odio, riesgos de cumplimiento—, de manera que sus modelos rechazan cosas similares por razones similares. Los investigadores lo aprovechan optimizando un documento de bloqueo contra un modelo sustituto accesible en su propio entorno RAG y transfiriéndolo después, en caja negra, a un objetivo desconocido. Como los criterios de rechazo se solapan, el documento que engaña al sustituto tiende a engañar al objetivo. Los resultados reportados abarcan siete modelos recientes y tres conjuntos de datos de preguntas y respuestas, con una tasa de transferencia entre modelos que alcanza el 96 % en una configuración, sin sondeo directo del sistema víctima. Describimos el mecanismo, no una receta de optimización operativa.

Por qué importa

La disponibilidad es la faceta más discreta de la tríada de seguridad y la más fácil de subestimar. Un asistente de soporte respaldado por RAG, un bot de búsqueda documental o un agente de conocimiento interno que de pronto empieza a rechazar una categoría de preguntas legítimas no parece «hackeado»: parece defectuoso o excesivamente cauto. Eso hace que el ataque sea difícil de atribuir y barato de sostener: un solo documento recuperable puede suprimir las respuestas a toda una familia de consultas relacionadas. En contextos críticos para la disponibilidad —manuales de respuesta a incidentes, consulta médica o jurídica, atención al cliente— los rechazos inducidos degradan directamente las decisiones y erosionan la confianza.

La lección de fondo es que la alineación de seguridad forma ahora parte de la superficie de ataque, y no solo de la defensa. Cuanto más conservadoramente se ajusta un modelo para rechazar, y cuanto más converge la industria hacia políticas de rechazo compartidas, mayor y más portable se vuelve esa superficie. Las defensas que suponen que el atacante quiere que el modelo obedezca pasan por alto a un adversario cuyo objetivo es que el modelo rechace.

Defensas

Ningún control único neutraliza por completo esta clase de ataque; el estudio constata que varias defensas existentes ofrecen una protección limitada. Trátelo como un problema por capas.

• Gobierne la base de conocimiento como una entrada no confiable. Restrinja quién puede añadir documentos a los corpus de recuperación y aplique procedencia y moderación al contenido aportado antes de que sea recuperable. Los corpus parcialmente abiertos son el punto de entrada.
• Vigile la tasa de rechazo como señal de disponibilidad. Haga seguimiento de la proporción de consultas que terminan en rechazo, desglosada por tema y por fuente del documento. Un pico de rechazos en consultas antes respondidas es un indicador de compromiso, no una simple molestia de experiencia de usuario.
• Separe la evaluación del riesgo del contexto recuperado. Evalúe la intención del usuario con independencia de la sensibilidad del texto recuperado, para que una pregunta benigna no se reclasifique como dañina solo porque un documento cercano se lea como arriesgado.
• Ajuste deliberadamente el compromiso del sobre-rechazo. Calibre las barreras frente a conjuntos de prueba de falsos rechazos sobre consultas benignas y prefiera rechazos específicos a la evitación en bloque de un tema, para dejar al atacante menos exceso de cautela que explotar.
• Rastree y ponga en cuarentena. Cuando aparezca un grupo de rechazos, identifique qué documentos recuperados coinciden con él, retire el contenido sospechoso y vuelva a probar: el documento de bloqueo es, por diseño, el que se recupera una y otra vez junto a los fallos.

Status

Elemento	Valor
Clase	Ataque de bloqueo / inducción de rechazo en RAG (disponibilidad)
Mecanismo	Documento envenenado que construye un «contexto de riesgo» para provocar el sobre-rechazo
Propiedad clave	Transferencia entre modelos vía homogeneidad de la alineación (caja negra)
Alcance reportado	7 LLM recientes, 3 conjuntos de datos QA; hasta 96 % de transferencia en una configuración
Divulgación	Marzo de 2026 (artículo de investigación); trabajos afines sobre DoS de barreras en junio de 2026
Estado del arreglo	Ninguna mitigación única; las defensas existentes se consideran limitadas

Fechas clave: marzo de 2026 — artículo sobre el ataque de bloqueo TabooRAG (arXiv 2603.03919); abril de 2025 — trabajo previo sobre inducir barreras para una denegación de servicio en RAG (arXiv 2504.21680); junio de 2026 — DoS por extensión del razonamiento contra barreras de IA (arXiv 2606.14517), un ejemplo contemporáneo de mecanismo de seguridad convertido en arma de disponibilidad. Los nombres de modelos citados (p. ej. GPT-5.2, DeepSeek-V3.2) son los reportados en el artículo fuente.