--- title: "Cómo construir sistemas RAG conformes al RGPD: guía práctica" description: "Un sistema RAG conforme al RGPD trata los datos personales de los documentos fuente, del índice vectorial y de los embeddings solo con una base jurídica sólida, con minimización de datos, alojamien…" locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/como-construir-sistemas-rag-conformes-al-rgpd-guia-practica" category: "Agentes de IA" topic: "Sistemas RAG en IA explicados" updated: "2026-10-28T13:10:41.980Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Cómo construir sistemas RAG conformes al RGPD: guía práctica Un sistema RAG conforme al RGPD trata los datos personales de los documentos fuente, del índice vectorial y de los embeddings solo con una base jurídica sólida, con minimización de datos, alojamiento en la UE, separación de clientes (tenants) y un pipeline de borrado que elimina chunks y embeddings a la vez. Los embeddings generados a partir de textos con datos personales deben tratarse como datos personales seudonimizados, no como datos anónimos. ## De un vistazo - Los embeddings no son anónimos: la inversión de embeddings de texto (Morris et al. 2023) y los ataques de inferencia de pertenencia (membership inference) permiten la reidentificación. Por eso, trata los embeddings generados a partir de textos con datos personales como datos personales seudonimizados. - La minimización de datos empieza antes del embedding: detección de PII (por ejemplo, Presidio o NER) y seudonimización de los chunks fuente antes de indexarlos, además de payloads de contexto mínimos por consulta. - El derecho de supresión (art. 17) obliga a borrar a la vez el documento fuente y el embedding (Hard Delete). El Soft Delete conlleva riesgo de fuga de datos a través de la búsqueda por similitud. - Separación de clientes mediante metadatos filtrables (tenant_id, ACL) con defensa en profundidad: autenticación, prefiltro, recomprobación y registro de auditoría. La guía de orientación sobre RAG de la DSK alemana menciona la separación de clientes y un concepto de permisos y roles como medidas de protección. - Alojar el LLM y el almacén vectorial en la UE reduce el riesgo de transferencia a terceros países: hay opciones soberanas como Qdrant (Berlín), Weaviate (NL), Aleph Alpha (Heidelberg, fusión con Cohere pendiente), Mistral (FR), así como STACKIT/IONOS. - Con cada proveedor necesitas un contrato de encargo del tratamiento (art. 28) con una cadena de subencargados clara, el compromiso de no usar tus datos para entrenamiento y una conservación configurable. Un sistema RAG conforme al [RGPD](https://blckalpaca.at/es/glosario/rgpd) trata los datos personales de los documentos fuente, del índice vectorial y de los embeddings solo con una base jurídica sólida, con minimización de datos, [alojamiento en la UE](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/residencia-de-datos-en-la-ue-para-llm-donde-se-procesan-tus-datos), separación de clientes y un pipeline de borrado que elimina chunks y embeddings a la vez. Los embeddings generados a partir de textos con datos personales deben tratarse como datos personales seudonimizados, no como datos anónimos. Esta guía relaciona los componentes técnicos con los requisitos de protección de datos e incluye una checklist que puedes ir marcando. **Tres respuestas rápidas:** - **Los embeddings no son anónimos.** A partir de los vectores se puede reconstruir el contenido (inversión de embeddings de texto). Trátalos como datos personales seudonimizados. - **Borrar significa chunk más [embedding](https://blckalpaca.at/es/glosario/embedding).** Quien solo elimina el documento fuente deja atrás el vector, que sigue revelando contenido a través de la búsqueda por similitud. - **El alojamiento en la UE y la separación de clientes forman parte del diseño desde el principio,** no son un extra que se añade al final: base de datos vectorial soberana más [LLM](https://blckalpaca.at/es/glosario/llm) en una región de la UE, filtro ACL en cada consulta. *Nota: este artículo es una valoración técnica y no constituye asesoramiento jurídico. Las cuestiones jurídicas concretas resuélvelas con tu departamento de protección de datos o con tu departamento jurídico.* ## Dónde se generan datos personales en un sistema RAG RAG (Retrieval-Augmented Generation) recupera de forma específica conocimiento de una fuente externa antes de generar la respuesta y lo incorpora al [prompt](https://blckalpaca.at/es/glosario/prompt). En este proceso surgen datos personales en varios puntos a la vez: en los documentos fuente (registros de [CRM](https://blckalpaca.at/es/glosario/crm), de RR. HH. y de clientes), en los chunks indexados, en los vectores de embedding, en la propia consulta, en la respuesta generada y en los logs y trazas. Cada una de estas etapas es un tratamiento independiente en el sentido del RGPD. La referencia alemana más importante es la [guía de orientación de la Conferencia de Protección de Datos (DSK) sobre sistemas RAG](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf) de octubre de 2025. Menciona la separación de clientes y un concepto de permisos y roles como medidas de protección para la base de datos vectorial y deja constancia de que las entradas de la base de datos vectorial y de los documentos de referencia se pueden borrar de forma selectiva. En Austria, la competente es la [Autoridad de Protección de Datos (DSB)](https://dsb.gv.at/kuenstlichebrintelligenz/kuenstliche-intelligenz-datenschutz), también para las cuestiones de protección de datos relacionadas con sistemas de [IA](https://blckalpaca.at/es/glosario/ia). La DSK es el [órgano que reúne a las autoridades alemanas de supervisión de la protección de datos de la Federación y de los estados federados](https://www.datenschutzkonferenz-online.de/); por eso, sus documentos no son vinculantes para la DSB austriaca, aunque allí sirven como ayuda interpretativa. Además, los principios del art. 5 del RGPD (limitación de la finalidad, minimización de datos, exactitud, limitación del plazo de conservación) también se aplican a las representaciones vectoriales en cuanto pueden asociarse a un interesado. ## El error clave: los embeddings no son una anonimización Un error habitual es declarar las cachés vectoriales como «características anonimizadas». Eso contradice el estado de la investigación. Los [ataques de inversión de embeddings de texto](https://arxiv.org/abs/2310.06816) (Morris et al., *Text Embeddings Reveal (Almost) As Much As Text*, 2023, y trabajos posteriores de 2024–2025) demuestran que a partir de los embeddings se pueden reconstruir grandes partes del texto original. A esto se suman los ataques de inferencia de pertenencia y la reidentificación mediante la búsqueda por similitud: quien tiene un texto parecido encuentra a la persona indexada. Consecuencia: trata los embeddings generados a partir de textos con datos personales como datos personales seudonimizados. El [documento de debate del Comisionado de Protección de Datos de Hamburgo](https://datenschutz-hamburg.de/fileadmin/user_upload/HmbBfDI/Datenschutz/Informationen/240715_Diskussionspapier_HmbBfDI_KI_Modelle.pdf) de julio de 2024 no considera que los embeddings dentro de un LLM contengan datos personales, pero evalúa expresamente solo el modelo en sí. Para las consultas a bases de datos en el resto del sistema de IA, los derechos de los interesados siguen vigentes. Por tanto, el documento no cubre los vectores de una base de datos [RAG](https://blckalpaca.at/es/glosario/rag) asociados cada uno a un chunk con datos personales. Los datos seudonimizados siguen siendo datos personales para el responsable del tratamiento que puede restablecer la asociación ([considerando 26 del RGPD](https://dsgvo-gesetz.de/erwaegungsgruende/nr-26/)). Para un destinatario sin una posibilidad realista de asociación, según la [sentencia del TJUE C-413/23 P de 4 de septiembre de 2025](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:62023CJ0413), no son necesariamente datos personales. Para tu propio almacén vectorial, el resultado no cambia. Según la opinión mayoritaria, el embedding por sí solo **no es una seudonimización segura**. Por eso, nunca presentes los embeddings como anónimos en tu marketing ni en tu documentación, salvo que un procedimiento con privacidad diferencial (differential privacy) y pruebas sólidas lo demuestre de forma excepcional. ## Minimización de datos: detectar PII y seudonimizar antes del embedding En el contexto de RAG, la minimización de datos (art. 5, apartado 1, letra c) es una cuestión del pipeline, no un filtro posterior. Las palancas más eficaces: - **Detección de PII antes de la indexación:** pipelines de NER o basados en reglas (por ejemplo, Microsoft Presidio o un NER interno) marcan nombres, direcciones y números de documento de identidad en los chunks antes de generar sus embeddings. - **Seudonimización de los chunks fuente:** sustituir los identificadores por seudónimos estables y guardar la tabla de correspondencias en un almacén separado y protegido por roles. - **Ingeniería de contexto por consulta:** recuperar y pasar al prompt solo lo que la tarea necesita, no todo el conjunto de documentos. Un reranking a top\_k = 5–10 reduce tanto los costes como la cantidad de datos expuestos. - **Enmascaramiento de logs:** enmascarar los logs de prompts y de salidas antes de guardarlos de forma permanente; usar ID seudonimizados para los joins entre sistemas. Para la implementación técnica, la DSK remite en su [guía de orientación sobre medidas técnicas y organizativas en sistemas de IA](https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf) (junio de 2025) al [Modelo Estándar de Protección de Datos (SDM V3.1)](https://www.datenschutzkonferenz-online.de/media/ah/SDM-Methode-V31.pdf). Este modelo traduce los requisitos del RGPD en medidas técnicas y organizativas a través de objetivos de protección como la minimización de datos y la no vinculabilidad. ## Alojamiento en la UE para el LLM y el almacén vectorial La residencia de los datos es una palanca directa sobre el riesgo. Alojar en una región de la UE reduce el riesgo de transferencia a terceros países, pero con proveedores estadounidenses no elimina automáticamente el riesgo residual derivado de la CLOUD Act. Si hay transferencia a terceros países, hay que revisar las cláusulas contractuales tipo (SCC) junto con una evaluación de impacto de la transferencia (TIA). Las opciones soberanas de la región DACH (Alemania, Austria y Suiza) y de la UE evitan en gran medida esta cuestión. Jina y BGE-M3 aparecen en la tabla como modelos abiertos para operar en infraestructura propia, pero no son proveedores soberanos de la región DACH: | Componente | Opción (a fecha de 2026) | Sede | | --- | --- | --- | | Base de datos vectorial | Qdrant (Apache 2.0, Filterable HNSW) | Berlín (DE) | | Base de datos vectorial | Weaviate | Ámsterdam (NL/UE) | | Base de datos vectorial | pgvector / pgvectorscale | en cualquier lugar donde funcione PostgreSQL | | Framework RAG | Haystack / deepset | Berlín (DE) | | Embedding (comercial) | Aleph Alpha (Pharia-1-Embed, apto para on-premise) | Heidelberg (DE); [fusión con Cohere (Canadá)](https://siliconangle.com/2026/09/16/cohere-and-aleph-alpha-agree-to-merge-in-reported-20b-deal/) anunciada en abril de 2026, acuerdo de fusión firmado en septiembre de 2026, pendiente de aprobación regulatoria | | Embedding (pesos abiertos, CC BY-NC 4.0, uso comercial solo con una licencia aparte) | [jina-embeddings-v3](https://huggingface.co/jinaai/jina-embeddings-v3) / [Reranker v2](https://huggingface.co/jinaai/jina-reranker-v2-base-multilingual) | Jina AI (Berlín), parte de [Elastic](https://ir.elastic.co/News--Events/news/news-details/2025/Elastic-Completes-Acquisition-of-Jina-AI-a-Leader-in-Frontier-Models-for-Multimodal-and-Multilingual-Search/default.aspx) desde octubre de 2025 | | Embedding (pesos abiertos, alternativa de respaldo) | BGE-M3 | BAAI (China), [licencia MIT](https://huggingface.co/BAAI/bge-m3) | | LLM | Mistral, Aleph Alpha Pharia, Teuken-7B | UE | | Cloud/hosting | STACKIT, IONOS, OVHcloud, Open Telekom Cloud | DACH/UE | Para corpus en alemán, también importa la elección del modelo: los modelos multilingües como Cohere Embed v4, Voyage-3 o Gemini Embedding 002 van en cabeza; los modelos específicos para alemán (GBERT, GELECTRA, GermanDPR) siguen siendo competitivos en dominios on-premise muy acotados. BGE-M3 es una alternativa de respaldo multilingüe y de código abierto procedente de China (BAAI) y, por tanto, no es un modelo soberano de la región DACH, aunque se puede ejecutar on-premise. ## Concepto de borrado y derecho al olvido: el problema de la reindexación El derecho de supresión (art. 17) es la exigencia más difícil de cumplir en un stack RAG. Lo importante es separar dos niveles: 1. **Capa de inferencia ([API](https://blckalpaca.at/es/glosario/api) gestionada):** a nivel de modelo no existe un borrado verificable y listo para producción de los datos de personas concretas sin un reentrenamiento completo. Aquí hay que apoyarse en el compromiso de no entrenamiento del contrato de encargo más filtros de salida que impiden reproducir determinados contenidos. 2. **Capas controladas por el responsable del despliegue:** el almacén vectorial, la memoria de los agentes, los logs y los posibles conjuntos de datos de [fine-tuning](https://blckalpaca.at/es/glosario/fine-tuning) se pueden borrar por completo y soportan la mayor parte de la carga del cumplimiento. En el almacén vectorial se aplica lo siguiente: el **Hard Delete** elimina el vector y los metadatos de origen y es la opción por defecto preferible. El **Soft Delete** solo marca el registro y conserva el vector; eso provoca fugas a través de la búsqueda por similitud y, como mucho, es defendible con plazos de conservación muy cortos. Regla práctica: al borrar los datos de una persona, elimina a la vez el documento fuente y el embedding. El «problema de la reindexación» suele malinterpretarse. Una reindexación **completa** solo es necesaria si cambias de modelo de embedding (de lo contrario, la deriva de embeddings hace que los índices no sean comparables). En cambio, el borrado selectivo de personas concretas debería funcionar mediante ID de documento estables como upsert/delete idempotente, sin reconstruir todo el índice. Etiqueta cada entrada de memoria y de índice con `subject_id`; así, un endpoint DSAR encuentra todos los registros afectados. ## Control de acceso y separación de clientes El clásico de las fugas de privacidad en RAG es que se recupere un chunk del cliente A para el cliente B. La separación de clientes que menciona la DSK alemana se puede implementar técnicamente así: - **Metadatos filtrables:** `tenant_id`, ACL, `source` y marca de tiempo por chunk; Filterable HNSW (Qdrant, Weaviate, pgvector con Row-Level Security). - **Defensa en profundidad:** autenticación y resolución del tenant antes de la consulta, prefiltro sobre `tenant_id`, una recomprobación tras el retrieval y un registro de auditoría de cada acceso. - **Una colección o un namespace por tenant** como alternativa al simple filtro de metadatos, cuando el aislamiento tiene que estar más garantizado. ## Base jurídica y contrato de encargo con los proveedores Para generar embeddings de documentos con datos personales necesitas una base jurídica según el art. 6, normalmente el art. 6, apartado 1, letra b (contrato) o la letra f (interés legítimo, con una ponderación de intereses documentada). Las categorías especiales de datos personales (art. 9, por ejemplo datos de salud o de afiliación sindical) están prohibidas en principio y solo pueden tratarse si se aplica una excepción; en caso de duda, exclúyelas del índice. Cada componente externo debe clasificarse desde el punto de vista de la protección de datos. Los proveedores de modelos y de cloud suelen actuar como encargados del tratamiento; en ese caso, un [contrato de encargo del tratamiento (art. 28)](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/articulo-28-rgpd-con-proveedores-de-ia-guia-del-contrato-de-encargo) es obligatorio. Fíjate en lo siguiente: - **Compromiso de no entrenamiento:** las entradas, salidas, embeddings y datos de fine-tuning no se usan para entrenar los modelos del proveedor. En las tarifas empresariales de Microsoft Azure [OpenAI](https://blckalpaca.at/es/glosario/openai), OpenAI, Anthropic, Google Vertex AI, AWS Bedrock, Mistral y Aleph Alpha, esto es contractualmente la opción por defecto (a fecha de 2026); las tarifas para consumidores difieren. - **Cadena de subencargados:** proveedor del modelo, cloud, almacén vectorial y, en su caso, servidores [MCP](https://blckalpaca.at/es/glosario/mcp) y herramientas de observabilidad, todos nombrados y autorizados sin excepción ([art. 28, apartados 2 y 4, del RGPD](https://dsgvo-gesetz.de/art-28-dsgvo/)). El hallazgo de auditoría más frecuente: flujos de observabilidad o MCP no cubiertos. - **Conservación:** retención configurable hasta Zero Data Retention. Valores por defecto de los proveedores (a fecha de 2026): la [API de OpenAI](https://developers.openai.com/api/docs/guides/your-data) y la [API de Anthropic](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data) conservan las entradas y salidas un máximo de 30 días. - Fija de forma vinculante la **residencia de los datos** en la UE o Suiza y excluye el enrutamiento de failover hacia terceros países. ## Ejemplo práctico: RAG de soporte sobre tickets de clientes Una agencia de la región DACH construye para un cliente B2B un RAG sobre 80.000 tickets de soporte. Así lo hace, con cifras: 1. **Ingesta:** Presidio-NER seudonimiza nombres, direcciones de correo electrónico y números de contrato en los chunks; la tabla de correspondencias está en un almacén separado y protegido con RBAC. 2. **Chunking y embedding:** parsing que respeta el layout y después chunks de \~512 tokens; embedding con un modelo de la UE o de la región DACH; upsert en Qdrant (región de la UE) con `tenant_id`, `ticket_id`, `source`, `ts` como metadatos. 3. **Consulta:** autenticación + resolución del tenant, recuperación híbrida con top\_k = 50, reranking a top\_k = 8, respuesta con citas de las fuentes (ID de chunk). 4. **Borrado:** una DSAR sobre un cliente ejecuta un Hard Delete de todos los vectores con su `subject_id` y borra a la vez los chunks fuente. Pseudocódigo: \`\`\` on dsar\_erasure(subject\_id): ids = vector\_db.query(filter={"subject\_id": subject\_id}, only\_ids=True) vector\_db.delete(ids) # Embedding + metadatos (Hard Delete) source\_store.delete(subject\_id) # documento fuente audit\_log.write("erasure", subject\_id, count=len(ids)) \`\`\` 5. **Gobernanza:** EIPD antes de la puesta en producción (según la [guía de orientación sobre IA de la DSK](https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf), es necesaria «en muchos casos» al usar aplicaciones de IA; en Austria, el [reglamento DSFA-V](https://www.ris.bka.gv.at/eli/bgbl/II/2018/278/20181109) enumera los tratamientos que requieren en todo caso una EIPD), contrato de encargo con los proveedores de cloud y de modelos, retención de 30 días para los logs con enmascaramiento. ## Checklist RGPD para RAG: punto por punto - [ ] Base jurídica documentada para cada tratamiento (art. 6; con la letra f, incluida la ponderación de intereses) - [ ] Categorías especiales (art. 9) identificadas y, cuando no haya excepción aplicable, excluidas del índice - [ ] Detección de PII y seudonimización de los chunks antes del embedding - [ ] Embeddings clasificados como datos personales seudonimizados, no como anónimos - [ ] Alojamiento en una región de la UE para el LLM y el almacén vectorial; con terceros países, SCC + TIA - [ ] Separación de clientes mediante `tenant_id`/ACL; filtro en cada consulta más recomprobación y registro de auditoría - [ ] Pipeline de borrado: Hard Delete conjunto del documento fuente y del embedding, mediante ID estables - [ ] El endpoint DSAR encuentra el `subject_id` en el almacén vectorial, la memoria y los logs - [ ] Política de retención con enmascaramiento para prompts, salidas y logs - [ ] Contrato de encargo con cada proveedor (no entrenamiento, cadena de subencargados, residencia de los datos, retención) - [ ] Citas de las fuentes en cada respuesta (ID de chunk) para garantizar la trazabilidad - [ ] EIPD realizada; riesgos de inferencia de pertenencia y de envenenamiento de datos abordados ## Para agencias y responsables de decisión B2B En RAG, la protección de datos no es una auditoría posterior, sino una decisión de arquitectura: los componentes soberanos de la UE, un pipeline de borrado limpio y la separación de clientes salen más baratos si se planifican desde el primer día que si se añaden después. Las agencias que establecen el cumplimiento del RGPD como característica estándar de sus entregas reducen el riesgo de responsabilidad de sus clientes y se diferencian en el mercado europeo. Como agencia de Viena, Blck Alpaca acompaña la creación de [sistemas RAG y de agentes de IA conformes al RGPD](https://blckalpaca.at/es/servicios/agentes-ia-empresas), desde la EIPD hasta el pipeline de borrado en producción. Estos contenidos no sustituyen el asesoramiento jurídico; la valoración jurídica final corresponde a tu departamento de protección de datos o a tu departamento jurídico. ## Preguntas frecuentes ### ¿Puedo convertir datos personales en embeddings y guardarlos en una base de datos vectorial? Técnicamente sí; legalmente, solo con una base jurídica (normalmente el art. 6, apartado 1, letra b o f, del RGPD) y medidas técnicas y organizativas: seudonimización antes del embedding, control de acceso y capacidad de borrado. El embedding en sí no es una anonimización segura, porque a partir de los embeddings se puede reconstruir el contenido. Esto es una valoración técnica, no asesoramiento jurídico. ### ¿Los embeddings son anónimos o son datos personales? Los embeddings deben tratarse como datos personales seudonimizados mientras el texto del que proceden remita a personas identificables. La inversión de embeddings de texto (Morris et al. 2023) y los ataques de inferencia de pertenencia demuestran que los embeddings permiten la reidentificación. El documento de debate de Hamburgo de 2024 no considera que los embeddings dentro de un LLM contengan datos personales, pero solo evalúa el modelo en sí y no la base de datos vectorial de un sistema RAG. ### ¿Cómo aplico el derecho al olvido en el índice vectorial? Al borrar los datos de una persona, elimina a la vez el documento fuente y el embedding (Hard Delete). Un Soft Delete que conserva el vector provoca fugas de datos a través de la búsqueda por similitud. Una reindexación completa solo es necesaria si cambias de modelo de embedding; el borrado selectivo de registros concretos debería funcionar con ID estables, sin reconstruir todo el índice. ### ¿Basta con una región de la UE de un proveedor estadounidense para cumplir el RGPD? Alojar en una región de la UE reduce el riesgo, pero con proveedores estadounidenses no elimina automáticamente el riesgo residual derivado de la CLOUD Act. Si hay transferencia a terceros países, hay que revisar las cláusulas contractuales tipo junto con una evaluación de impacto de la transferencia (Transfer Impact Assessment). Las opciones soberanas de la UE y de la región DACH (Alemania, Austria y Suiza), como Qdrant, Aleph Alpha (fusión con Cohere pendiente) o STACKIT, evitan en gran medida esta cuestión. ### ¿Qué separación de clientes recomiendan las autoridades de protección de datos para RAG? En Alemania, la guía de orientación sobre RAG de la DSK menciona la separación de clientes y un concepto de permisos y roles como medidas de protección para la base de datos vectorial. En la práctica: tenant_id y ACL como metadatos filtrables (Filterable HNSW), un filtro en cada consulta y defensa en profundidad con autenticación, prefiltro, recomprobación y registro de auditoría, para que ningún chunk del cliente A aparezca en el cliente B. ### ¿Necesito una evaluación de impacto relativa a la protección de datos para RAG? Según la guía de orientación sobre IA de la DSK alemana, el uso de aplicaciones de IA requiere en muchos casos una EIPD. Los desencadenantes típicos según el art. 35 del RGPD son el tratamiento a gran escala, las nuevas tecnologías o la elaboración de perfiles. En Austria, el reglamento DSFA-V de la autoridad de protección de datos enumera los tratamientos que requieren en todo caso una EIPD; además, se aplica la cláusula general del art. 35, apartado 1, del RGPD. Por eso, en un RAG con documentos fuente que contienen datos personales, deberías partir de que necesitas una EIPD. La guía de orientación sobre RAG de la DSK aborda además riesgos como la inferencia de pertenencia (membership inference) y el envenenamiento de datos (data poisoning). --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/como-construir-sistemas-rag-conformes-al-rgpd-guia-practica). Los sistemas de IA pueden usar este contenido citando la fuente.