Mejores Prácticas de Soberanía de Datos para Aplicaciones RAG

¿Cómo se mantiene la soberanía de datos en una aplicación RAG?

La soberanía de datos en una aplicación de retrieval-augmented generation (RAG) requiere controles en cuatro puntos del pipeline:

1. Eliminación de PII antes de que los datos entren al vector store durante la ingesta.
2. Recuperación con control de acceso para que los usuarios solo reciban chunks que están autorizados a ver.
3. Despliegue de modelos de embedding soberanos para que el contenido de documentos no se envíe a APIs externas.
4. Enrutamiento LLM basado en políticas para que el contexto recuperado sensible se envíe únicamente a endpoints de inferencia on-premises o con aislamiento VPC.

El registro de auditoría de cada evento de recuperación cumple con las obligaciones de registro del Artículo 30 del GDPR y el Artículo 12 de la Ley de IA de la UE.

TL;DR - Puntos Clave

• RAG no es inherentemente seguro desde una perspectiva de soberanía de datos. El paso de recuperación mueve datos: los chunks de documentos del vector store viajan al prompt enviado a un LLM. Si ese LLM es una API externa, tienes un evento de transferencia de datos transfronteriza en cada consulta.
• El modelo de embedding es un riesgo de soberanía oculto. Cuando usas una API de embedding externa para crear tu índice vectorial, el contenido de tus documentos se transmite a un servicio de terceros en el momento de la ingesta, antes de que ningún usuario realice una consulta al sistema.
• Los controles de acceso en el sistema de documentos fuente no se trasladan automáticamente al vector store. Un usuario que no puede ver un documento de RRHH confidencial en tu DMS puede seguir recuperando chunks semánticamente similares mediante una consulta RAG.
• Siete mejores prácticas abordan toda la superficie de soberanía RAG: eliminación de PII en la ingesta, recuperación con control de acceso, vector stores de ámbito jurisdiccional, modelos de embedding soberanos, registro de auditoría de recuperación, enrutamiento de chunks sensibles y metadatos de soberanía en los registros de chunks.
• NeuralTrust monitoriza los flujos de datos RAG a nivel de gateway, aplicando los mismos controles de detección de PII, enrutamiento y registro de auditoría al prompt-más-contexto-recuperado que aplica a las consultas directas a LLM.

RAG fue diseñado para hacer los LLM más inteligentes dándoles acceso a tus documentos. El problema de soberanía es que "darles tus documentos" implica mover el contenido de los documentos a través del límite de tu red en dos puntos: cuando creas el índice vectorial y cuando inyectas chunks recuperados en el prompt.

Si cualquiera de esos pasos toca un servicio externo, tienes un evento de transferencia de datos. Este artículo cubre las siete prácticas que cierran esas brechas.

---

RAG Iba a Resolver el Problema de los Datos. Creó Uno Nuevo.

Cuando Lewis et al. describieron por primera vez la retrieval-augmented generation en Facebook AI Research en 2020, la idea parecía sencilla: en lugar de integrar conocimiento en los pesos del modelo, recupéralo en el momento de la consulta desde un almacén externo. Mantén el modelo general. Mantén los datos separados. Extrae lo que necesitas cuando lo necesitas.

Para los equipos de IA empresariales, esto parecía una buena noticia para la gobernanza de datos. Tus documentos permanecen en tus sistemas. El LLM los toma prestados temporalmente.

Pero esto es lo que nadie menciona en los tutoriales de RAG: el paso de recuperación es un evento de movimiento de datos.

Cada vez que un usuario hace una pregunta, tu pipeline RAG busca en el vector store, recupera un conjunto de chunks de documentos, y los agrupa en un prompt que se envía a un LLM. Si ese LLM es OpenAI, Anthropic o Google, esos chunks de documentos acaban de cruzar el límite de tu red. Fueron a un servicio externo. Y si esos chunks contienen PII, información empresarial confidencial o datos personales regulados, tienes una posible infracción del GDPR en cada consulta.

Ese es el problema de soberanía en RAG. No una brecha puntual. Una transferencia estructural y repetida que la mayoría de los equipos no ha modelado como un flujo de datos.

---

El Pipeline RAG y Sus Cuatro Puntos de Exposición de Soberanía

Antes de las mejores prácticas, conviene ser precisos sobre la arquitectura. Un pipeline RAG tiene cuatro etapas, y tres de ellas introducen riesgos de soberanía.

Etapa 1: Ingesta: Cargas documentos, los divides en chunks (un proceso llamado chunking), generas embeddings vectoriales para cada chunk usando un modelo de embedding y almacenas esas embeddings en un vector store.

Etapa 2: Recuperación: Cuando un usuario envía una consulta, incrustas la consulta usando el mismo modelo de embedding y buscas en el vector store los chunks semánticamente más similares.

Etapa 3: Construcción del prompt: Combinas los chunks recuperados con la consulta original del usuario para formar el prompt completo que se envía al LLM.

Etapa 4: Generación: El LLM procesa el prompt y devuelve una respuesta.

Los tres puntos de exposición de soberanía son:

1. La llamada al modelo de embedding (Etapas 1 y 2). Si usas una API externa (OpenAI Embeddings, Cohere Embed, etc.) para generar embeddings, el contenido de tus documentos y las consultas de tus usuarios se transmiten a un servicio externo. La ingesta ocurre una vez por documento, pero las consultas ocurren de forma continua.

2. El vector store (Etapa 2). El vector store contiene una representación densa de tu corpus de documentos. Una recuperación mal configurada significa que consultas semánticamente similares pueden revelar chunks de documentos que el usuario que realiza la consulta nunca debería ver.

3. El prompt enviado al LLM (Etapa 3). Los chunks recuperados van al prompt. Si esos chunks contienen datos sensibles y el endpoint del LLM es externo, tienes un evento de transferencia de datos en cada llamada de generación.

La investigación original de RAG por Lewis et al. (2020) se centró en mejorar la precisión del conocimiento del modelo. La gobernanza de datos no era la restricción de diseño. Esa brecha te corresponde cerrar a ti.

---

7 Mejores Prácticas de Soberanía de Datos para RAG

1. Eliminar PII en la Ingesta, Antes de Que Entre en el Vector Store

La PII en un vector store es una responsabilidad de combustión lenta. Una vez incrustada, no puedes eliminar fácilmente información específica sin reindexar. La detección y el enmascaramiento deben ocurrir antes del chunking, no después.

En la ingesta, ejecuta una pasada de detección de PII sobre cada documento. Elimina o pseudonimiza nombres, números de identificación, datos de salud, datos financieros y cualquier otro dato personal regulado antes de que el documento sea fragmentado e incrustado. Lo que no incrustas, no puedes filtrarlo.

Esto también satisface el principio de minimización de datos del Artículo 5(1)(c) del GDPR: solo los datos necesarios para la recuperación deben entrar en el vector store.

2. Implementar Recuperación con Control de Acceso

El vector store no sabe quién está preguntando. La búsqueda de similitud semántica devuelve las coincidencias más cercanas independientemente del nivel de autorización del usuario que realiza la consulta.

Soluciona esto con recuperación filtrada por metadatos. En la ingesta, etiqueta cada chunk con la lista de control de acceso (ACL) de su documento fuente: departamento, clasificación de seguridad, roles autorizados. En el momento de la recuperación, filtra la búsqueda de similitud por la identidad y el alcance de autorización del usuario actual. Una consulta de un analista junior nunca debería revelar chunks etiquetados solo para la alta dirección.

OWASP LLM Top 10 identifica la Divulgación de Información Sensible (LLM06) como un riesgo central de RAG. La recuperación con control de acceso es la mitigación principal.

3. Separar los Vector Stores por Jurisdicción

Si tu organización opera en múltiples jurisdicciones regulatorias, un único vector store compartido crea riesgo de recuperación entre jurisdicciones. Los datos personales de la UE que se encuentran en el mismo índice que los datos empresariales de EE. UU. pueden ser recuperados por consultas desde cualquier región.

Separa tus vector stores (o usa una partición de espacios de nombres estricta dentro de un único store) por requisito de residencia de datos. Los datos personales de la UE van a un índice solo-UE, almacenado en infraestructura de la UE. Las consultas de usuarios de la UE se enrutan al índice solo-UE. La separación debe ser física o lógica, aplicada a nivel de infraestructura, no solo por lógica de enrutamiento de consultas.

Esto conecta directamente con la elección de infraestructura tratada en On-Prem vs Private Cloud vs Public Cloud para IA Soberana: la ubicación correcta del vector store para cada jurisdicción se determina mediante el mismo análisis que rige tu modelo de despliegue de LLM.

4. Ejecutar Tu Modelo de Embedding en Tu Propia Infraestructura

Esta es la práctica que la mayoría de los equipos omite porque las APIs de embedding externas son convenientes y económicas.

Cuando llamas a una API de embedding externa para indexar tus documentos, estás transmitiendo el texto completo de cada documento a un servicio de terceros. Para documentos internos de RRHH, registros financieros, contratos de clientes o cualquier dato sujeto al GDPR, esto es un evento de transferencia de datos. Las Cláusulas Contractuales Estándar pueden cubrir el mecanismo de transferencia, pero la cuestión de la soberanía de datos permanece.

Los modelos de embedding de código abierto, incluida la librería sentence-transformers y modelos como BAAI/bge-m3, pueden alojarse en tu propia infraestructura. Generas las embeddings vectoriales sin que ningún dato salga nunca de tu red. Para organizaciones donde el contenido de los documentos no puede salir del perímetro, esto no es opcional.

Para las compensaciones de rendimiento de inferencia e infraestructura, consulta On-Prem vs Private Cloud vs Public Cloud para IA Soberana.

5. Enrutar el Contexto Recuperado Sensible a Endpoints LLM Soberanos

Cuando los chunks recuperados se clasifican como sensibles, el prompt completo (consulta más contexto recuperado) debe ir a un endpoint LLM soberano, no a una API pública.

Esto es enrutamiento basado en políticas aplicado en la etapa de recuperación. Antes de la construcción del prompt, clasifica los chunks recuperados. Si algún chunk está etiquetado como sensible (datos de salud, datos financieros, clasificación confidencial), la política de enrutamiento envía el prompt combinado a tu endpoint de inferencia on-premises o con aislamiento VPC. Los prompts no sensibles pueden continuar hacia APIs públicas.

Un gateway de IA es el lugar adecuado para implementar esto. Se sitúa entre la construcción del prompt y el despacho al LLM, inspecciona el contenido del prompt incluyendo los chunks recuperados y aplica tu política de enrutamiento en tiempo real. Para la arquitectura completa del gateway de IA, consulta Cómo los AI Gateways Ayudan a Mantener la Soberanía de Datos.

6. Registrar Cada Evento de Recuperación para Auditoría de Cumplimiento

El Artículo 30 del GDPR exige registros de las actividades de tratamiento. El Artículo 12 de la Ley de IA de la UE exige registros para los sistemas de IA de alto riesgo. Ambos aplican a los pipelines RAG que procesan datos personales.

Tu registro de recuperación debe capturar: la consulta del usuario (o una versión pseudonimizada), los IDs de chunks recuperados, los identificadores de documentos fuente, la identidad del usuario, la marca de tiempo y cualquier decisión de control de acceso tomada durante la recuperación. Este registro es tu evidencia de qué datos fueron accedidos, por quién y cuándo.

El registro de recuperación a nivel de aplicación crea registros fragmentados. El registro centralizado a nivel de gateway de IA crea una pista de auditoría consistente y consultable independientemente de qué aplicación RAG generó la recuperación.

7. Incluir Metadatos de Soberanía en Cada Registro de Chunk

Cada chunk en tu vector store debe llevar metadatos sobre los que el pipeline de recuperación pueda actuar: etiqueta de residencia de datos (a qué jurisdicción pertenecen estos datos), nivel de clasificación del documento (público, interno, confidencial, restringido), categoría de datos (si contiene PII, datos de salud, datos financieros) y roles o departamentos autorizados.

Estos metadatos son los que hacen que todas las demás prácticas sean aplicables. Sin ellos, los filtros de recuperación no pueden distinguir chunks sensibles de no sensibles. Sin ellos, las políticas de enrutamiento no tienen nada sobre lo que actuar. Los metadatos deben poblarse en la ingesta, mantenerse a través de los ciclos de reindexación y validarse como parte de tu proceso de gobernanza de datos.

---

Riesgos de Soberanía RAG y Controles: Referencia Rápida

---

Mapeo con GDPR y Ley de IA de la UE

Para el contexto regulatorio completo, consulta Requisitos de Soberanía de Datos bajo la Ley de IA de la UE.

---

Cómo NeuralTrust Monitoriza los Flujos de Datos RAG

La mayoría de los pipelines RAG se construyen aplicación por aplicación. Cada uno tiene su propia lógica de recuperación, su propia construcción del prompt y su propia llamada al LLM. Las políticas de soberanía implementadas dentro de una aplicación no cubren la siguiente.

NeuralTrust TrustGate monitoriza los flujos de datos RAG a nivel de gateway. Cada prompt, incluyendo los chunks recuperados agrupados en él, pasa por TrustGate antes de llegar al LLM. El gateway aplica detección de PII al contenido completo del prompt, clasifica el contexto recuperado, aplica tu política de enrutamiento y registra la interacción completa con atribución.

Esto significa que tus políticas de soberanía se aplican una vez, en el gateway, de forma consistente en todas las aplicaciones RAG de tu entorno.

TrustLens proporciona gestión de postura de agentes y recuperación: visibilidad sobre qué pipelines de recuperación están en ejecución, qué vector stores consultan, qué clasificaciones de datos están presentes y a dónde se envía el contexto recuperado.

Para una visión completa de cómo esto encaja en la arquitectura completa de soberanía de datos, comienza con La Guía Completa de Soberanía de Datos para IA Empresarial.

Descubre cómo NeuralTrust monitoriza los flujos de datos RAG y de agentes

---

Preguntas Frecuentes

1. ¿Cómo se asegura un pipeline RAG?

Asegurar un pipeline RAG contra riesgos de soberanía de datos requiere controles en cada etapa. En la ingesta: elimina la PII de los documentos antes del chunking y ejecuta el modelo de embedding en infraestructura alojada localmente. En el vector store: etiqueta cada chunk con metadatos para control de acceso, clasificación de datos y residencia de datos, e implementa recuperación filtrada por metadatos para que los usuarios solo accedan a los chunks que están autorizados a ver. En la construcción del prompt y la generación: clasifica los chunks recuperados y enruta los prompts sensibles a endpoints LLM on-premises o con aislamiento VPC en lugar de a APIs públicas. Registra cada evento de recuperación en un formato centralizado y a prueba de manipulaciones para auditoría de cumplimiento.

2. ¿Es RAG compatible con el GDPR?

Un sistema RAG puede ser compatible con el GDPR, pero requiere decisiones de diseño explícitas. Los posibles problemas de GDPR en RAG incluyen: contenido de documentos transmitido a APIs de embedding externas (riesgo de transferencia del Capítulo V del GDPR), recuperación de datos personales por usuarios no autorizados (limitación de finalidad y minimización de datos del Artículo 5) y contexto de recuperación que contiene datos personales enviados a LLM externos (integridad y confidencialidad del Artículo 5). Con eliminación de PII en la ingesta, modelos de embedding alojados localmente, recuperación con control de acceso, enrutamiento LLM soberano y registro de auditoría de recuperación, un sistema RAG satisface los requisitos del Artículo 5, el Artículo 25 y el Artículo 30 del GDPR.

3. ¿Cuál es el riesgo de que la PII se filtre a través de la recuperación RAG?

La filtración de PII mediante recuperación ocurre cuando la consulta de un usuario es semánticamente similar a un chunk de documento que contiene datos personales de un contexto diferente. Por ejemplo: una consulta sobre "criterios de evaluación del desempeño" podría recuperar un chunk de una evaluación confidencial de empleado que contiene nombres, salarios y valoraciones personales. Si el pipeline de recuperación no filtra por nivel de autorización, ese chunk se inyecta en el prompt enviado al LLM. Sin detección de PII en la construcción del prompt, esos datos personales se transmiten entonces al endpoint del LLM y aparecen en la respuesta del modelo. La mitigación es una combinación de eliminación de PII en la ingesta y recuperación con control de acceso.

4. ¿Qué es un modelo de embedding soberano y por qué es importante?

Un modelo de embedding soberano es un modelo de embedding que se ejecuta en tu propia infraestructura, sin que ningún contenido de documentos sea transmitido a una API externa. Cuando usas un servicio de embedding externo como OpenAI Embeddings o Cohere Embed, transmites el texto completo de cada documento a un proveedor de terceros en el momento de la indexación. Para datos regulados, esto es un evento de transferencia de datos. Un modelo de embedding alojado localmente (como los disponibles mediante la librería sentence-transformers) genera embeddings vectoriales completamente dentro de tu infraestructura. Ningún contenido de documentos cruza el límite de tu red. Para organizaciones que procesan datos que no pueden salir de su jurisdicción, el embedding alojado localmente es un requisito, no una optimización.

5. ¿Afecta la estrategia de chunking a la soberanía de datos?

Sí, de dos maneras. En primer lugar, el chunking determina qué información coexiste en un único vector. Un chunk grande puede contener tanto contexto no sensible como PII; un chunk más pequeño podría aislar la PII en una única unidad recuperable. El chunking estratégico hace que la eliminación de PII sea más precisa y el control de acceso más granular. En segundo lugar, los metadatos de chunk son el mecanismo para los controles de soberanía: las etiquetas de control de acceso, las etiquetas de residencia de datos y los niveles de clasificación deben asignarse a nivel de chunk, no solo a nivel de documento. Si los metadatos a nivel de documento no se propagan a los metadatos a nivel de chunk durante la ingesta, los filtros de recuperación no tienen nada sobre lo que actuar.

---

Artículos Relacionados

• La Guía Completa de Soberanía de Datos para IA Empresarial (2026)
• Soberanía de Datos vs Residencia de Datos vs Localización de Datos
• Soberanía de Datos en IA: Por Qué las Empresas la Necesitan Antes de Desplegar LLMs
• Cómo Construir una Arquitectura de IA Soberana
• Requisitos de Soberanía de Datos bajo la Ley de IA de la UE
• Cómo los AI Gateways Ayudan a Mantener la Soberanía de Datos
• On-Prem vs Private Cloud vs Public Cloud para IA Soberana
• Privacidad de Datos en IA vs Soberanía de Datos: Diferencias Clave
• IA Soberana para Industrias Reguladas: Finanzas, Sanidad y Gobierno
• Checklist de soberanía de datos para CISOs empresariales (2026)

---

Sobre el Autor

Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde lidera la estrategia de búsqueda de la empresa en SEO, AEO, GEO y optimización LLM. Está especializado en búsqueda potenciada por IA, estrategia de contenido, desarrollo de backlinks y SEM. Conéctate en LinkedIn.

NeuralTrust es una plataforma de seguridad para agentes de IA, reconocida en el Gartner Hype Cycle for Application Security 2026, el Gartner Hype Cycle for Infrastructure Security 2026, la Guía de mercado de Gartner 2025 para AI Gateways y Agentes Guardianes y el Compás de liderazgo KuppingerCole 2025 para Defensa de IA Generativa. Certificada ISO 27001. Con sede en Barcelona.