Un solo filtro no basta: una defensa por capas para chatbots RAG

¿Qué es esto?

El 17 de junio de 2026 se publicó en arXiv un artículo titulado A Layered Security Framework Against Prompt Injection in RAG-Based Chatbots. Su argumento es sencillo y merece tomarse en serio: la mayoría de las defensas contra la inyección de prompts actúan en un único punto del pipeline, y un único punto nunca basta para un sistema de generación aumentada por recuperación. Un filtro de entrada ve el mensaje del usuario, pero nunca los documentos que el recuperador trae. Un monitor de salida ve la respuesta del modelo, pero solo después de que una carga maliciosa ya llegó al modelo. Cada control tiene un punto ciego, y la inyección indirecta se aloja precisamente en esos puntos ciegos.

La inyección de prompts sigue siendo la entrada número uno — LLM01 — del Top 10 de OWASP para aplicaciones LLM, y el RAG agrava el problema en lugar de resolverlo. En un chatbot común, el texto no confiable se limita a lo que escribe el usuario. En un chatbot RAG, el propio corpus de conocimiento se convierte en superficie de ataque: un solo documento envenenado, indexado una vez, puede comprometer a todos los usuarios cuya consulta lo recupere. El artículo presenta su contribución como el cierre de esa brecha mediante defensa en profundidad, en lugar de un único clasificador más inteligente.

Cómo funciona

Se trata de un diseño defensivo, no de un ataque, por lo que no hay nada operativo que ocultar. El marco coloca tres controles independientes a lo largo de la ruta de inferencia, cada uno responsable de una frontera de confianza distinta.

Capa 1 — filtrado de entrada. Antes que nada, el mensaje del usuario es examinado por una biblioteca de patrones basada en reglas (formulaciones de inyección conocidas, secuencias de control sospechosas) combinada con un clasificador de anomalías semánticas ajustado, que marca las entradas que parecen instrucciones dirigidas al sistema en lugar de preguntas por responder. Esto intercepta la inyección directa en la puerta pero, por diseño, no se confía en que lo detecte todo.

Capa 2 — jerarquía de instrucciones basada en la procedencia. Es la capa más importante para el RAG. Al ensamblar el prompt —política del sistema, documentos recuperados, consulta del usuario— el marco etiqueta cada segmento según su origen e impone un orden: la política del operador prima sobre la entrada del usuario, que prima sobre el contenido recuperado. Un texto proveniente de un documento recuperado nunca puede leerse como una instrucción que anule las reglas del operador. Una entrada envenenada del corpus todavía puede decir «ignora tus instrucciones», pero en el ensamblaje lleva la autoridad más baja y se trata como dato, no como comando. Esto responde directamente a la vía de inyección indirecta que los filtros de entrada estructuralmente no pueden ver.

Capa 3 — auditoría de salida. Tras la generación, la respuesta pasa por un motor de reglas de política y una verificación de deriva semántica que compara la respuesta con la tarea prevista. Si el modelo ha sido desviado —fuga del contenido del prompt del sistema, ejecución de una instrucción incrustada, alejamiento de la pregunta real del usuario— la divergencia se detecta antes de devolver la respuesta.

Las capas son deliberadamente redundantes. La idea no es que alguna sea perfecta, sino que un ataque tenga que vencer a las tres, y que las tres fallen de maneras distintas.

Por qué importa

Las cifras reportadas dan una idea del tamaño del efecto: en la evaluación de los autores, combinar los tres controles redujo la tasa de éxito de los ataques de aproximadamente el 71 % a alrededor del 11 %, manteniendo la tasa de falsos positivos cerca del 5 %. Esas son las dos cifras que deciden si una defensa es desplegable: un filtro que bloquea inyecciones pero también una de cada cinco consultas legítimas nunca sobrevive al contacto con usuarios reales.

Más importante que los porcentajes exactos es la lección estructural, que trasciende este sistema concreto. Los equipos suelen añadir una única barrera a un despliegue RAG —normalmente un clasificador de entrada, porque es el lugar más fácil— y dan el problema por resuelto. No lo está. El paso de recuperación reintroduce silenciosamente texto no confiable después de que el filtro de entrada ha actuado, y ningún ajuste de ese filtro inspeccionará jamás un documento que no ve. El ensamblaje de contexto consciente de la procedencia es la pieza que la mayoría de los despliegues olvida, y es precisamente la que defiende el modo de fallo propio del RAG, donde un documento indexado envenena muchas sesiones. Estudios de caso industriales recientes sobre la protección de chatbots RAG, como el despliegue de turismo inteligente de Hsinchu, llegan a la misma conclusión desde el lado aplicado.

Defensas

No confíe en una sola etapa de filtrado. Un clasificador de entrada por sí solo no puede ver el contenido recuperado; un monitor de salida por sí solo actúa demasiado tarde. Suponga que cada control tiene un punto ciego y coloque verificaciones independientes en la entrada, en el ensamblaje del contexto y en la salida, para que un ataque deba vencerlas a todas.

Etiquete la procedencia e imponga una jerarquía de instrucciones. Marque cada segmento del prompt ensamblado según su origen —sistema, usuario, recuperado— y haga que la autoridad siga al origen: la política del operador prima sobre el usuario, que prima sobre los documentos recuperados. El texto recuperado debe ser estructuralmente incapaz de anular sus reglas, diga lo que diga.

Trate el corpus como una superficie de ataque. En RAG, un solo documento envenenado puede afectar a todos los usuarios que lo recuperan. Verifique y vigile el contenido ingerido, restrinja quién puede escribir en el índice y registre qué documentos contribuyeron a una respuesta marcada para poder rastrear el envenenamiento.

Audite la salida buscando deriva de tarea, no solo palabras prohibidas. Una verificación de deriva semántica que compare la respuesta con la tarea prevista detecta los desvíos que un filtro de palabras clave pasa por alto: fuga del prompt del sistema, una respuesta que sigue discretamente una instrucción incrustada en lugar de la pregunta del usuario.

Mida la tasa de falsos positivos, no solo la de bloqueo. Una defensa que bloquea ataques pero rechaza una parte importante de las consultas legítimas terminará desactivada. Reporte ambas cifras y ajuste el punto de operación para que siga siendo usable antes de ponerla en producción.

Status

Elemento	Referencia	Fecha	Notas
Artículo	arXiv:2606.19660	Junio 2026	Defensa de tres capas para chatbots RAG
Capa 1	Filtrado de entrada: patrones por reglas + clasificador de anomalías ajustado	—	Intercepta la inyección directa en la entrada
Capa 2	Jerarquía de instrucciones basada en procedencia en el ensamblaje	—	El contenido recuperado no puede anular la política — la defensa RAG clave
Capa 3	Auditoría de salida: motor de reglas + deriva semántica	—	Detecta el desvío tras la generación
Efecto reportado	Éxito de ataques ~71 % → ~11 %; falsos positivos ~5 %	—	Evaluación de los autores
Contexto	OWASP LLM01; estudio de caso RAG relacionado arXiv:2509.21367	2025–2026	Inyección de prompts clasificada como el riesgo LLM más crítico

El marco no pretende resolver la inyección de prompts —hoy ninguna defensa lo logra de forma creíble— pero aporta un argumento concreto y comprobable: los despliegues RAG necesitan controles en más de una etapa, y el ensamblaje de contexto consciente de la procedencia es la etapa que más a menudo se omite. Para cualquiera que opere un chatbot de generación aumentada por recuperación, es un cambio de arquitectura barato de evaluar frente a un modo de fallo realmente difícil.