Los sistemas RAG filtran datos: la IA es tarea de seguridad

Un modelo de lenguaje que responde sobre sus documentos internos es para muchas empresas la primera utilidad tangible de la IA: ofertas, manuales, cláusulas contractuales, tickets, respondidos a demanda en lugar de buscados en estructuras de carpetas. La técnica que hay detrás se llama Retrieval-Augmented Generation (RAG): para responder a una pregunta, el modelo recibe adjuntos los fragmentos adecuados de sus documentos y a partir de ellos formula la respuesta. El atractivo es evidente. El riesgo suele pasarse por alto.

Porque RAG es, en su núcleo, un motor de búsqueda con un modelo de formulación antepuesto. Y un motor de búsqueda sobre datos de empresa solo es tan fiable como los permisos que aplica. Si se construye un sistema RAG sin arrastrar los derechos de acceso del sistema de origen, ocurre exactamente lo que tiene que ocurrir: a un usuario se le sirven contenidos que nunca habría debido ver. Esto no es un caso especial exótico, sino la disfunción de RAG más frecuente y más costosa.

El fallo estándar: los permisos se quedan atrás

En un repositorio de archivos bien gestionado, una lista de control de acceso decide quién puede abrir un documento. El comercial ve sus ofertas, no la lista de salarios de la dirección. Sin embargo, al construir un sistema RAG estos documentos se descomponen, se convierten en vectores y se depositan en una base de datos vectorial, y es en este punto donde con frecuencia se pierde el permiso. La base de datos vectorial ya solo conoce contenidos, no derechos de acceso. Quien pregunta obtiene como respuesta lo que encaja por contenido, no lo que tiene permiso de ver.

El proyecto OWASP revalorizó expresamente esta clase de fallos en 2025. En la actualizada OWASP Top 10 for LLM Applications, «Sensitive Information Disclosure» ascendió al puesto 2, y con «Vector and Embedding Weaknesses» (LLM08) se incorporó una categoría completamente nueva que nombra precisamente estas debilidades específicas de RAG: búsqueda manipulada, acceso a través de tenants y permisos, la reconstrucción del texto en claro a partir de embeddings. El mensaje es inequívoco: quien emplea RAG ha abierto un nuevo campo de ataque y fuga, autónomo.

Dos patrones reales: Copilot como objeto de estudio

Cómo se ve esto en la práctica puede estudiarse con Microsoft 365 Copilot, uno de los sistemas RAG desplegados de forma más amplia que existen.

El primer patrón es el simple exceso de permisos compartidos (oversharing). Copilot responde sobre la base de aquello a lo que un usuario puede acceder según su permiso. Si estos permisos se han concedido con generosidad durante años en la empresa —el infame recurso compartido de SharePoint «para todos en la empresa»—, la IA vuelve de repente visible y consultable esa carga heredada. El proveedor de análisis Concentric halló que el 15 por ciento de los recursos críticos para el negocio estaban afectados por exceso de permisos y podían ser consultados por personas que no deberían tener acceso. La IA no creó el problema. Solo lo sacó a la luz.

El segundo patrón es el ataque dirigido contra la cadena RAG. Bajo el nombre de «EchoLeak» (CVE-2025-32711, CVSS 9.3), el equipo de seguridad de Aim Labs describió en 2025 un ataque zero-click contra Microsoft 365 Copilot: bastaba un único correo electrónico preparado —sin que el destinatario tuviera que abrirlo ni hacer clic en él— para inducir a Copilot a recopilar contenidos internos de SharePoint, OneDrive y Teams y filtrarlos a un servidor ajeno. Microsoft cerró el fallo del lado del servidor y no comunicó explotación alguna en libertad (in the wild). El caso sigue siendo instructivo: una entrada no confiable —aquí un correo electrónico— pudo cruzar la frontera hacia datos internos confiables. Un resultado de investigación relacionado de la University of Texas («ConfusedPilot», 2024) mostró además cómo documentos introducidos de forma encubierta pueden llevar a un sistema RAG a afirmaciones falsas y explotar en ello configuraciones erróneas de control de acceso.

Multi-tenant: la fuga más costosa

Lo más grave se da cuando un sistema RAG utiliza la misma base de datos vectorial para varios tenants (mandantes), por ejemplo un proveedor de servicios que hace accesible conocimiento para varios clientes. Sin una separación estricta, los documentos de distintos clientes comparten el mismo espacio de búsqueda, y la búsqueda por similitud no conoce fronteras entre clientes. Una consulta del cliente A puede entonces devolver contenidos del cliente B, no por un hackeo espectacular, sino porque la base de datos nunca aprendió que existe una frontera.

Las bases de datos vectoriales, en muchos casos, no se diseñaron con el control de acceso a nivel de documento como función central. Los profesionales informan de fugas entre tenants en casi todas las consultas de prueba en cuanto la búsqueda se realiza sin filtrar. Y las consecuencias no son abstractas: un fallo de control de acceso en una base de datos vectorial extendida dejó al descubierto más de 200.000 registros de datos de salud. La fuga entre tenants (cross-tenant) no es, por tanto, solo un defecto técnico, sino un incidente de protección de datos, de responsabilidad y de reputación.

La solución no es magia de IA, sino oficio

La buena noticia: las contramedidas son conocidas. Son los mismos principios que también fuera de la IA conforman una arquitectura de seguridad sólida, aplicados con rigor a la cadena RAG.

Limpiar primero los permisos. Antes de que los datos fluyan a un sistema RAG, hay que ordenar el caos de recursos compartidos. RAG vuelve visibles los excesos de permisos existentes; quien no los depura antes, exporta el problema al modelo.
Arrastrar el control de acceso hasta el nivel de documento. Cada fragmento depositado en la base de datos vectorial lleva sus metadatos de permisos —usuarios y grupos autorizados— como parte integrante. En el momento de la consulta se filtra en dos fases: antes de la búsqueda mediante metadatos, después de la búsqueda mediante una verificación real de permisos contra el sistema de origen. Si los derechos cambian, el nuevo permiso surte efecto de inmediato, no solo tras la siguiente reindexación.
Separar los tenants con dureza. En escenarios multi-tenant, la frontera de tenant se impone a nivel del índice vectorial, no solo en la lógica de la aplicación por encima.
Registrar sin lagunas. Cada recuperación deja una línea: quién, qué consulta, qué fragmentos entregados, cuáles denegados. Sin este registro no puede esclarecerse un incidente ni superarse una auditoría.
Tratar la entrada no confiable como tal. Los correos electrónicos, los archivos subidos, los contenidos web externos no deben cruzar sin control la frontera de confianza hacia los datos internos: la lección de EchoLeak.

Esto es, visto con sobriedad, control de acceso clásico, clasificación de datos, registro y segmentación de red. La capacidad de construir una arquitectura RAG que supere una auditoría no es una competencia de IA. Es una competencia de seguridad.

Por qué esto es una tarea de seguridad, no un juego de IA

Quien trata un sistema RAG como un proyecto de datos —«volcamos nuestros documentos dentro y ponemos un modelo delante»— construye de forma fiable una fuga. Quien lo trata como un proyecto de seguridad se plantea, antes de la primera respuesta, las preguntas correctas: ¿qué permiso tiene quien consulta? ¿Qué metadatos lleva cada fragmento? ¿Por dónde pasa la frontera de tenant? ¿Qué consta en el registro? Estas preguntas deciden si la ganancia de productividad se convierte en un incidente de protección de datos.

Justo aquí se bifurca el camino. La IA soberana sobre los datos propios no surge de que un modelo sea especialmente potente, sino de que la arquitectura en torno al modelo aplica las reglas de acceso de la empresa, de forma sólida, demostrable y auditable.

Cómo apoya sector7

Operamos modelos de lenguaje privados protegidos y RAG gestionado en nuestro propio parque de servidores en Alemania: los datos no abandonan el entorno controlado por nosotros. La diferencia decisiva está en nuestra procedencia: sector7 viene de la práctica de seguridad y de redes. Construimos la cadena RAG como construimos perímetros y backups, con control de acceso a nivel de documento, separación estricta de tenants, registro sin lagunas y una arquitectura que resiste un examen. Esto conecta nuestra IA soberana directamente con nuestra práctica de ciberseguridad existente y con nuestra experiencia de ingeniería certificada por el fabricante en Juniper, Cisco, HPE, F5, Fortinet y Palo Alto Networks. No entrenamos modelos base propios ni prometemos una plantilla de IA autónoma; la gran capacidad de GPU la obtenemos a través de socios soberanos. Lo que entregamos es lo que hace segura a RAG: oficio de seguridad. Desde una casa de gestión propia en Solingen.

La IA sobre sus datos es una tarea de seguridad: por qué los sistemas RAG filtran datos