Cómo cinco documentos pueden romper un sistema RAG y convertir una base de conocimiento en un vector de ataque

Los sistemas RAG se perciben frecuentemente como una forma de reducir alucinaciones y obligar a los LLMs a basarse en documentos corporativos. Pero si la base de conocimiento se considera confiable por defecto, puede convertirse en el canal más conveniente para la inyección de prompts y la sustitución silenciosa de respuestas.

Dónde está el punto débil

El problema no es que el modelo "lea" mal los documentos, sino que no distingue entre hechos e instrucciones de la manera en que lo hacen los humanos. Si una base de conocimiento recibe varios archivos especialmente preparados, la capa de recuperación de RAG puede incluir consistentemente estos documentos en el contexto de consultas relevantes. Entonces el LLM ve los fragmentos como parte de su entorno de trabajo y comienza a seguir instrucciones ocultas: ignorar el prompt del sistema, cambiar prioridades, insertar conclusiones falsas o dirigir el diálogo en una dirección favorable para el atacante.

Para un equipo, esto es especialmente peligroso porque el ataque se disfraza como operación normal de la base de conocimiento. Un usuario hace una pregunta legítima, la recuperación devuelve fragmentos "relevantes", y la respuesta parece confiada y conectada a la consulta. Los registros también pueden parecer normales: el modelo no se quiebra, no entra en jailbreak evidente y no muestra nada sospechoso.

Pero la calidad de la solución cae, y con ella—la confianza en el producto, que debería basarse en documentos verificados.

Por qué cinco documentos son suficientes

El riesgo principal es que la seguridad de RAG se sobreestima frecuentemente debido a los embeddings. Parece que la búsqueda vectorial transforma textos de origen en abstracciones matemáticas seguras, pero no es así. Los embeddings ayudan a encontrar fragmentos similares, no neutralizan su significado.

Si cinco documentos se escriben para coincidir con consultas populares de usuarios e incluyen instrucciones maliciosas en los lugares correctos, el sistema incluirá repetidamente estos documentos en el contexto. El ataque no requiere control total de la base de conocimiento: a veces, algunos apuntes, preguntas frecuentes o políticas internas que terminan en el índice sin verificación son suficientes. El efecto se amplifica por la propia mecánica de recuperación.

El sistema rara vez suministra el documento completo al modelo—normalmente lo divide en chunks y selecciona los mejores resultados. Esto significa que el atacante no necesita escribir un texto malicioso largo: fragmentos cortos pero semánticamente "pegajosos" que aparecen en los resultados top-k son suficientes. Como resultado, el LLM recibe no una referencia neutral, sino un conjunto preseleccionado de prompts influyentes, y el operador del sistema puede no notar durante mucho tiempo que las respuestas se están desviando en la dirección establecida por estos fragmentos.

Qué necesita protección

En producción, RAG no puede protegerse con un único filtro en la entrada. Se necesita un esquema multicapa que verifique documentos, chunks extraídos y la respuesta final del modelo. De lo contrario, un equipo puede limpiar la consulta del usuario, pero dejar pasar la misma inyección en la base de conocimiento. Un problema separado son los ataques "silenciosos", donde el sistema no falla ni muestra un error obvio—simplemente comienza a aconsejar con confianza acciones incorrectas, sustituir prioridades o revelar lo que no debería mostrar.

• Verificación de documentos antes de la indexación en busca de instrucciones ocultas y patrones sospechosos
• Aislamiento de datos por fuente, rol y nivel de confianza
• Políticas de recuperación: límites en la dominancia de fuente única y control de diversidad
• Filtrado de contexto antes de alimentar el LLM y guardrails separados para la respuesta
• Logs, pruebas de red-team y reevaluación regular del corpus después de actualizaciones

Los escenarios de demostración normalmente ocultan este problema porque el corpus es pequeño, las fuentes se conocen de antemano y las consultas son predecibles. En un sistema funcional, todo es diferente: los documentos se cargan en lotes, se actualizan sin moderación manual, provienen de diferentes departamentos y frecuentemente mezclan hechos, consejos, plantillas e instrucciones de servicio. En tal ambiente, RAG debe diseñarse no como "búsqueda + LLM", sino como un pipeline sensible a la seguridad con zonas de confianza claras, auditorías de cambios y reglas separadas para diferentes tipos de contenido.

Qué significa esto

La vulnerabilidad principal en RAG no está solo en el modelo, sino en la confianza depositada en el contexto suministrado por la infraestructura. Si el sistema funciona con datos comerciales reales, la protección debe comenzar mucho antes de la generación de respuestas: en las fases de carga de documentos, recuperación y postprocesamiento. De lo contrario, incluso un pequeño conjunto de archivos envenenados puede distorsionar sistemáticamente el resultado.