Seguridad RAG: riesgos y controles para evitar fugas de datos con IA

La seguridad RAG es el conjunto de controles que impide que un sistema de IA conectado a los documentos de tu empresa filtre información a quien no debe, obedezca instrucciones escondidas en esos documentos o guarde datos sensibles donde no toca. Un RAG bien hecho responde con tu documentación y cita la fuente; uno mal protegido es una forma muy cómoda de saltarse los permisos de tu gestor documental. Estos son los riesgos que vemos en la práctica y cómo se controlan.

Por qué un sistema RAG es un riesgo de fuga de datos

Un sistema RAG concentra en un solo punto información que antes estaba repartida y protegida por los permisos de cada sistema. Si no sabes bien cómo funciona, empieza por qué es RAG: los documentos se trocean, se convierten en vectores (embeddings), se guardan en un índice y, ante cada pregunta, se recuperan los fragmentos más relevantes para que el modelo redacte la respuesta.

Cada una de esas fases puede filtrar datos. OWASP dedica una categoría entera de su Top 10 para aplicaciones con modelos de lenguaje a este problema, «Vector and Embedding Weaknesses» (LLM08), y otra a la revelación de información sensible (LLM02). El informe sobre riesgos de privacidad en LLM elaborado dentro del programa de expertos del Comité Europeo de Protección de Datos (que aclara que no refleja necesariamente la posición oficial del CEPD) señala tres riesgos habituales del RAG: registros o cachés inseguros, envío de consultas a terceros y exposición de datos personales o confidenciales almacenados en la base de conocimiento. Si quieres el mapa completo de riesgos, lo tienes en nuestro resumen del OWASP Top 10 para LLM.

Los riesgos de seguridad de un sistema RAG

Permisos mal aplicados: el empleado que ve lo que no debe

Es el riesgo más frecuente y el más fácil de pasar por alto. Si el índice contiene todos los documentos de la empresa y la búsqueda no tiene en cuenta quién pregunta, cualquier empleado puede obtener información de documentos a los que no tiene acceso. Un ejemplo típico: un técnico pregunta «¿cuánto cobra un coordinador?» y la IA responde citando una tabla salarial que estaba en una carpeta de recursos humanos.

OWASP describe exactamente este escenario: controles de acceso débiles que permiten al modelo recuperar y revelar datos personales o confidenciales, y fugas entre grupos de usuarios en bases vectoriales compartidas, donde los fragmentos de un grupo aparecen en las consultas de otro.

Prompt injection indirecta escondida en documentos

Un documento indexado puede contener instrucciones dirigidas al modelo. El NIST define la prompt injection indirecta como el ataque en el que el adversario, sin acceso directo al sistema, inyecta instrucciones en datos que probablemente serán recuperados. OWASP pone un ejemplo muy gráfico: un candidato oculta texto en blanco sobre blanco en su currículum con instrucciones para que el sistema lo recomiende; el RAG de selección lo indexa y el modelo obedece.

En empresa, la vía de entrada puede ser un correo, un PDF de un proveedor, una página web indexada o un documento subido por cualquier empleado. OWASP añade que técnicas como RAG no eliminan por completo la prompt injection. Lo explicamos con más detalle en prompt injection.

Envenenamiento de la base documental

El envenenamiento es la versión persistente del problema: alguien introduce, de forma intencionada o por error, contenido falso o manipulado en la base de conocimiento para sesgar las respuestas. OWASP lo atribuye a personal interno, datos sembrados o proveedores no verificados. No hace falta un atacante sofisticado: un procedimiento obsoleto que nadie retiró también hace que la IA responda mal, solo que sin mala intención.

Exposición de datos personales y de salud

Si la base documental contiene expedientes, historiales, nóminas o datos de clientes, el RAG puede citarlos en una respuesta. En sectores como el sociosanitario esto incluye datos de salud, que el RGPD protege como categoría especial. El riesgo no está solo en la respuesta: los fragmentos viajan al modelo en cada consulta, así que importa dónde se procesa y bajo qué condiciones.

Exfiltración mediante enlaces o imágenes en la respuesta

Si la interfaz muestra enlaces o imágenes que genera el modelo, una instrucción inyectada puede pedirle que incruste datos de la conversación en una URL. OWASP describe un caso en el que unas instrucciones ocultas en una web hacen que el modelo inserte una imagen que apunta a un servidor externo, lo que exfiltra la conversación privada al cargarse. No es teórico: en 2025 Microsoft corrigió una vulnerabilidad crítica en Microsoft 365 Copilot (CVE-2025-32711, puntuación 9,3), bautizada como EchoLeak por sus descubridores. Según Infosecurity Magazine, el ataque empezaba con un correo con instrucciones ocultas que el asistente incorporaba a su contexto, y los datos salían en la URL de una imagen sin que el usuario hiciera clic.

Los embeddings también son datos

Es tentador pensar que la base vectorial solo contiene números. OWASP documenta la inversión de embeddings: un atacante puede recuperar una parte significativa de la información original a partir de los vectores. Por eso la base vectorial merece la misma protección que los documentos de los que procede: control de acceso, cifrado, copias protegidas y borrado cuando se elimina el documento original.

Registros que guardan datos sensibles

Para auditar y mejorar un RAG se registran consultas, fragmentos recuperados y respuestas. Esos registros pueden acabar conteniendo exactamente la información que querías proteger, y el informe del programa de expertos del CEPD cita el registro o la caché inseguros como riesgo típico del RAG. Un log sin retención definida y con acceso amplio es una segunda copia, peor protegida, de tus datos más sensibles.

Controles para un RAG seguro

Ningún control resuelve todo por sí solo. OWASP insiste en que no existe un método conocido que impida por completo la prompt injection, así que el objetivo es combinar capas para que un fallo en una no se convierta en una fuga.

Filtrado por permisos antes de recuperar

La regla de oro: el modelo nunca debe ver un fragmento que el usuario no podría abrir. Cada fragmento se indexa con los permisos de su documento de origen, heredados del gestor documental o del sistema donde vive, y la búsqueda filtra por la identidad del usuario antes de devolver resultados. Filtrar después, en la respuesta, llega tarde. OWASP recomienda bases vectoriales con control de acceso de grano fino y partición estricta entre grupos de usuarios.

Segmentación de índices

Cuando hay grupos de información muy distintos (por ejemplo, empresas de un mismo grupo, centros o departamentos con datos sensibles), es más seguro separar índices que confiar solo en filtros. Un error en un filtro afecta a una consulta; un índice separado evita la mezcla por diseño.

Saneamiento en la ingesta

Los documentos se validan antes de entrar: fuentes autorizadas, extracción de texto que ignora formato y contenido oculto (como recomienda OWASP en el caso del currículum), detección de instrucciones dirigidas al modelo y revisión de lo que llega desde fuera de la empresa. Cada bloque documental tiene un responsable que decide qué entra y qué se retira.

Citas a las fuentes y control de la salida

Que cada respuesta cite el documento de origen permite al usuario comprobar el dato y detectar respuestas extrañas. En la salida, conviene no mostrar imágenes ni enlaces generados por el modelo hacia dominios externos, o limitarlos a una lista permitida, y validar el formato con código, no con instrucciones al modelo.

Minimización y cifrado

Indexa solo lo que hace falta para responder. Si un procedimiento no necesita nombres de residentes o pacientes, se eliminan o seudonimizan en la ingesta. Documentos, embeddings y registros se cifran en tránsito y en reposo, y se borran del índice cuando se borran del origen.

Alojamiento en la UE y control del proveedor

Los fragmentos viajan al modelo en cada consulta. Alojar índice, aplicación y modelo en la Unión Europea, con contratos que excluyan el uso de tus datos para entrenar, reduce el riesgo de transferencias internacionales y de tratamiento por terceros. Para la información más sensible, una IA privada para empresas con modelos abiertos en infraestructura dedicada evita que los datos salgan de un entorno controlado.

Retención de logs

Define qué se registra, quién puede verlo y cuánto tiempo se conserva. Lo habitual es registrar lo necesario para auditar (quién preguntó, qué documentos se recuperaron) y limitar o enmascarar el contenido sensible. OWASP recomienda registros detallados e inmutables de la actividad de recuperación para detectar comportamientos sospechosos; el equilibrio está en que sirvan para auditar sin convertirse en otra copia de los datos.

Pruebas antes y después de producción

Antes de abrir el sistema a la plantilla, se prueba con usuarios de distintos perfiles si alguien obtiene información que no debería, se introducen documentos con instrucciones ocultas y se intenta forzar la exfiltración. Después, se repite con cada cambio relevante. Es lo que explicamos en red teaming de IA. Si tu RAG también ejecuta acciones a través de conectores, revisa además la seguridad MCP.

RAG y RGPD: datos personales y categorías especiales

Un sistema RAG que indexa documentos con datos personales es un tratamiento de datos sujeto al Reglamento general de protección de datos, y los controles anteriores son la forma práctica de cumplir varios de sus principios:

• Minimización (artículo 5): tratar solo los datos adecuados, pertinentes y limitados a lo necesario.
• Limitación del plazo de conservación (artículo 5): aplicable también a registros y copias del índice.
• Protección de datos desde el diseño y por defecto (artículo 25): por defecto, cada usuario solo accede a lo que necesita.
• Seguridad del tratamiento (artículo 32): medidas como la seudonimización y el cifrado, adecuadas al riesgo.

Los datos de salud son una categoría especial según el artículo 9 del RGPD: su tratamiento está prohibido salvo que concurra alguna de las excepciones que el propio artículo enumera. Y el artículo 35 exige una evaluación de impacto cuando se tratan categorías especiales a gran escala. La guía de la AEPD sobre adecuación al RGPD de tratamientos con IA recuerda que la minimización y la evaluación de impacto deben tenerse en cuenta desde el diseño. Si además te preocupa el encaje con el Reglamento de IA, lo tratamos en obligaciones del Reglamento de IA para empresas.

Cómo te ayudamos en Hive Mind Solutions

En Hive Mind Solutions desarrollamos RAG propio con seguridad por diseño: permisos heredados y aplicados antes de recuperar, saneamiento de documentos en la ingesta, citas a la fuente, cifrado, registros con retención definida y todo alojado en la UE cumpliendo el RGPD. Lo tenemos funcionando en grupos de residencias líderes en España, un entorno donde conviven protocolos, datos personales y datos de salud.

Si ya tienes un asistente con tus documentos o estás pensando en montarlo, revisamos su arquitectura y sus permisos y te proponemos controles concretos. Conoce nuestro servicio de seguridad y cumplimiento en IA o cuéntanos qué quieres proteger: trabajamos en remoto con empresas de toda España, con soluciones para todos los presupuestos y precios muy difíciles de batir.