Seguridad y soberanía en arquitecturas RAG: guía de despliegue en entornos de nube privados e híbridos

Por qué la seguridad de un sistema RAG no se resuelve con las mismas reglas que la de una aplicación tradicional

Respuesta rápida:

Una arquitectura RAG (Retrieval-Augmented Generation) introduce riesgos que no existen en una aplicación tradicional: inyección de prompt a través de documentos recuperados, fuga de información entre usuarios o clientes cuando el índice vectorial no aplica permisos de forma estricta, y salida de datos sensibles hacia APIs de terceros en cada llamada de embeddings o de inferencia.

Desplegar el sistema en un entorno de nube privada o híbrida, con aislamiento de datos real a nivel de recuperación y componentes que la organización pueda controlar y auditar, reduce ambos riesgos a la vez: el de seguridad y el de dependencia de un proveedor cerrado.

Un sistema RAG no es seguro porque el modelo sea de confianza. Es seguro cuando es estructuralmente imposible recuperar un documento para el que el usuario no tiene permiso, ocurra lo que ocurra en el prompt.

El patrón se repite en muchos pilotos de RAG corporativo: la demo funciona perfectamente con veinte documentos de prueba, todos con el mismo nivel de confidencialidad. El problema aparece al escalar a producción, cuando el índice pasa a contener miles de documentos procedentes de sistemas distintos (Drive, Confluence, SharePoint, la intranet de RRHH), cada uno con su propio modelo de permisos, y alguien del equipo de soporte descubre, sin buscarlo, que el chatbot interno puede responder preguntas sobre el documento de compensación del comité de dirección.

Por qué la seguridad en arquitecturas RAG es diferente a la de una aplicación tradicional

Una aplicación tradicional tiene una superficie de ataque relativamente bien entendida: la capa de autenticación, la capa de autorización y las consultas a la base de datos. Un sistema RAG añade superficie nueva en tres puntos:

El contenido recuperado se convierte en parte del prompt: un documento indexado puede contener instrucciones diseñadas para manipular el comportamiento del modelo, lo que OWASP clasifica como inyección de prompt indirecta, algo que no tiene equivalente en una consulta SQL tradicional.
El dato atraviesa más saltos y, a menudo, más proveedores: cada llamada al modelo de embeddings y cada llamada de inferencia son un punto potencial de salida de datos fuera del perímetro de la organización, especialmente cuando ambos son servicios comerciales externos.
El modelo de permisos tiende a aplanarse: al unificar documentos de sistemas de origen muy distintos en un único índice vectorial, es fácil perder la granularidad de permisos que cada sistema origen aplicaba por separado.

Qué es una arquitectura RAG y dónde están los puntos de riesgo

Una arquitectura RAG conecta un modelo de lenguaje con una base de conocimiento propia mediante un proceso de varias etapas: ingesta y fragmentación de documentos, generación de embeddings, almacenamiento en una base de datos vectorial, recuperación de los fragmentos más relevantes para una consulta y, finalmente, generación de la respuesta por el modelo a partir de esos fragmentos.

Cada etapa es un punto de riesgo potencial:

Ingesta: si los permisos del documento origen no se sincronizan junto con su contenido, el fragmento queda huérfano de contexto de acceso en el índice.
Base de datos vectorial: un índice compartido sin aislamiento estricto por usuario, cliente o departamento puede devolver fragmentos que el solicitante no debería poder ver.
Llamada al modelo de embeddings: si es un servicio externo, el contenido del documento, incluido el sensible, sale de la organización en cada indexación.
Capa de orquestación: es donde se procesa el prompt final combinando la consulta del usuario con los fragmentos recuperados, y por tanto donde una inyección de prompt indirecta tiene efecto.
Endpoint de inferencia del LLM: el mismo riesgo de salida de datos que en los embeddings, agravado porque aquí viaja tanto la pregunta como el contexto recuperado.

Aislamiento de datos en sistemas RAG: multi-tenant, permisos y fuga de contexto

El error de diseño más habitual, y más peligroso, es recuperar primero y filtrar después: el sistema busca los fragmentos más similares a la consulta en todo el índice, y solo entonces descarta los que el usuario no debería ver. Este patrón falla por dos motivos: es probabilístico en un sistema que necesita garantías deterministas, y además puede sesgar o vaciar los resultados relevantes, ya que los fragmentos descartados por permisos ya han ocupado espacio entre los más similares.

El patrón correcto invierte el orden: primero se resuelve la identidad y el contexto de permisos del usuario, después se restringe el espacio de búsqueda vectorial a lo que esa identidad puede ver, y solo entonces se ejecuta la búsqueda por similitud y el reordenamiento de resultados. La búsqueda nunca llega a “ver” un fragmento fuera del alcance autorizado, en lugar de verlo y descartarlo después.

RBAC a nivel de documento sincronizado desde el origen: los permisos de cada fragmento se heredan de su sistema fuente (Drive, Confluence, SharePoint) y se mantienen como metadato del propio fragmento en el índice, no como una capa de reglas independiente que hay que mantener sincronizada a mano.
Aislamiento por silo o por metadato: según el nivel de sensibilidad, cada cliente o departamento puede tener su propio índice físicamente separado (silo) o compartir un índice con un filtro de metadato estricto por identificador de tenant (pool). El primero es más seguro; el segundo, más eficiente en coste y mantenimiento.
Seguridad a nivel de fila para agentes que consultan datos estructurados: cuando un agente de IA ejecuta consultas directamente sobre una base de datos relacional, la seguridad a nivel de fila (RLS) debe aplicarse en la propia base de datos, no confiando en que el agente construya la consulta correctamente.
Sincronización de bajas: cuando un documento se elimina o pierde acceso en el sistema origen, su embedding debe eliminarse o revocarse en el índice vectorial; de lo contrario, el contenido sigue siendo recuperable aunque ya no debería existir.
Auditoría de cada recuperación: registrar qué usuario recuperó qué fragmento y cuándo es lo que permite investigar un incidente después, no solo prevenirlo antes.

Si la seguridad de tu sistema RAG depende de instruir al modelo para que “solo use los documentos del departamento correcto”, no tienes seguridad: tienes una petición educada a un sistema probabilístico.

Despliegue de RAG en entornos privados e híbridos: opciones arquitectónicas

RAG completamente en nube privada o VPC propia

Modelo de embeddings, base de datos vectorial y modelo de inferencia se despliegan dentro del perímetro de red de la organización, típicamente con modelos open-weight autoalojados. Es la opción con mayor control y menor superficie de exposición externa, adecuada para datos altamente sensibles o sectores muy regulados, a cambio de asumir la operación de la infraestructura de inferencia.

RAG híbrido: modelos comerciales vía endpoint privado y datos on-premise

El índice vectorial y los datos permanecen en infraestructura propia, mientras que la inferencia se realiza contra un modelo comercial expuesto a través de un endpoint privado, dentro de una VPC o red virtual del proveedor cloud, sin salir a internet público. Es un punto intermedio habitual: mantiene el dato bajo control mientras se aprovecha la capacidad de modelos comerciales de mayor rendimiento.

Cuándo evitar los modelos comerciales cerrados por riesgo de vendor lock-in

Cuando el prompt, el sistema de orquestación y el formato de los embeddings dependen por completo de las convenciones propietarias de un único proveedor, migrar a otra opción más adelante implica reescribir buena parte del sistema, no solo cambiar una variable de configuración. Este riesgo es mayor cuanto más crítico es el caso de uso y más rápido evoluciona (y encarece o cambia sus condiciones) el mercado de modelos comerciales.

Control del código y mitigación del vendor lock-in en arquitecturas RAG

Modelos open-weight autoalojados (familias como Llama o Mistral, entre otras) servidos mediante motores de inferencia propios como vLLM, Ollama o TGI, que eliminan la dependencia de una API comercial para el componente más crítico del sistema.
Frameworks de orquestación abiertos como LangChain, LlamaIndex o Haystack, que evitan acoplar la lógica de la aplicación a las convenciones propietarias de un único proveedor de IA generativa.
Bases de datos vectoriales open-source como Weaviate, Milvus, Qdrant o la extensión pgvector sobre PostgreSQL, frente a servicios gestionados propietarios que dificultan la portabilidad del índice.
Formatos de embeddings portables: evaluar desde el diseño inicial qué coste tendría cambiar de proveedor de embeddings, ya que los vectores de dos modelos distintos no son intercambiables entre sí y una migración puede requerir reindexar toda la base de conocimiento.
Documentación y transferencia de conocimiento como entregable, no como añadido: el equipo interno debe poder operar, auditar y modificar cada pieza de la arquitectura sin depender de que el proveedor que la construyó siga disponible.

Estos riesgos, especialmente los relacionados con inyección de prompt y debilidades en el uso de embeddings, están recogidos de forma más amplia en el OWASP Top 10 para aplicaciones LLM, una referencia útil como checklist de seguridad al diseñar o auditar cualquier sistema RAG en producción.

¿Tu sistema RAG confía en el prompt para respetar permisos que deberían aplicarse antes de la búsqueda?

En Galde diseñamos arquitecturas RAG con aislamiento de datos real, control del código y despliegue en entornos privados o híbridos según el nivel de sensibilidad de cada organización.

Agenda una sesión de diagnóstico técnico y revisa si tu arquitectura RAG aplica permisos antes o después de la búsqueda vectorial.

Cómo puede ayudar Galde a desplegar arquitecturas RAG seguras y soberanas

Desde la IA generativa, diseñamos e implementamos sistemas RAG y agentes con recuperación consciente de permisos desde el primer diseño, evitando el patrón de filtrar después de buscar.

Desde data platforms, construimos la infraestructura de despliegue (privada, híbrida o en VPC dedicada) y seleccionamos los componentes open-source o autoalojados adecuados para minimizar el riesgo de vendor lock-in sin sacrificar rendimiento.

Y a través de la gobernanza de datos, garantizamos que los permisos del sistema RAG estén siempre sincronizados con los de los sistemas de origen, en lugar de vivir como una capa de reglas independiente que se desactualiza con el tiempo.

Conclusión

La seguridad de una arquitectura RAG no se consigue añadiendo instrucciones al prompt para que el modelo se comporte bien: se consigue diseñando el sistema para que sea estructuralmente imposible recuperar lo que un usuario no debería ver, y desplegando cada componente (embeddings, índice vectorial, inferencia) en un entorno cuyo nivel de control y soberanía sea coherente con la sensibilidad real de los datos. La alternativa a los modelos comerciales cerrados no es siempre construirlo todo desde cero: es entender exactamente qué se está cediendo a cambio de la comodidad de una API, y decidirlo de forma consciente en lugar de por defecto.

Preguntas frecuentes

¿Es seguro usar un índice vectorial compartido para varios clientes o departamentos?

Puede serlo si se aplica un filtro de metadato estricto por tenant en el propio motor de búsqueda, antes de que se ejecute la búsqueda por similitud, y no como un paso de filtrado posterior. Para datos muy sensibles, un índice físicamente separado por cliente sigue siendo la opción más segura.

¿Qué es la inyección de prompt indirecta en un sistema RAG?

Es la manipulación del comportamiento de un modelo mediante instrucciones ocultas dentro de un documento que el sistema recupera y añade al prompt, sin que el usuario haya escrito esas instrucciones directamente. Es uno de los riesgos que recoge el marco OWASP para aplicaciones LLM.

¿Es obligatorio autoalojar el modelo para tener una arquitectura RAG soberana?

No necesariamente. Un modelo comercial expuesto mediante un endpoint privado dentro de una VPC puede ser una opción razonable en un despliegue híbrido. Lo importante es que los datos y el índice permanezcan bajo control de la organización y que el acoplamiento al proveedor esté minimizado en el resto de la arquitectura.

¿Cómo se evita que un documento eliminado del sistema origen siga siendo accesible a través del chatbot?

Sincronizando las bajas y los cambios de permisos del sistema origen con el índice vectorial mediante un proceso de actualización continuo, de forma que el embedding correspondiente se elimine o se marque como no recuperable en el mismo momento en que el documento deja de estar disponible o accesible en origen.

¿Qué ventaja tiene un despliegue híbrido frente a uno completamente en nube pública?

Permite mantener los datos más sensibles y el índice vectorial bajo control directo de la organización, mientras se sigue aprovechando la capacidad de modelos comerciales de alto rendimiento para la generación, reduciendo tanto el riesgo de fuga de datos como la dependencia total de un único proveedor.