RAG local para datos empresariales: IA conforme al RGPD para documentos sensibles (2026)

Datos rápidos

• 6 controles obligatorios para cualquier RAG regulado: air-gap, RBAC, registros de auditoría, cifrado, trazabilidad de datos, procedimiento de eliminación.
• 3 patrones de despliegue: portátil de un solo usuario (profesionales individuales), servidor on-prem (5–50 usuarios), nube privada en la UE (multi-entidad).
• La EIPD es obligatoria en virtud del artículo 35 cuando se ingieren datos de categorías especiales (salud, jurídicos, biométricos) a gran escala.
• Ley de IA de la UE: la mayoría de los RAG locales = riesgo limitado; pasa a alto riesgo cuando la recuperación alimenta decisiones automatizadas (crédito, empleo, prestaciones).
• El derecho al olvido debe propagarse a documentos de origen, índices vectoriales, embeddings en caché Y el historial de respuestas.
• Co-determinación del comité de empresa (Betriebsrat) en virtud del §87 BetrVG requerida para cualquier RAG sobre contenido generado por empleados en Alemania.
• Los modelos de embedding de código abierto solo son conformes al RGPD si los pesos están fijados, la inferencia es completamente local y la licencia ha sido revisada.

Comparación de patrones de despliegue

Elegir un patrón de despliegue

Por qué RAG local para datos sensibles

• Transferencia transfronteriza (artículos 44–49). Enviar datos personales a un encargado del tratamiento fuera de la UE requiere cláusulas contractuales tipo, una evaluación del impacto de la transferencia y una respuesta creíble sobre si la jurisdicción receptora tiene poderes de citación que alcancen esos datos. El RAG local no transfiere datos — la pregunta no surge.
• Proliferación de subencargados del tratamiento (artículo 28). Los proveedores de LLM en la nube suelen depender de infraestructura de hiperescalador, servicios de moderación de contenido y proveedores de observabilidad. Cada uno es un subencargado que debe ser listado, contratado y auditado. El RAG local tiene cero subencargados por defecto.
• Filtración de datos de entrenamiento. Muchos términos de LLM en la nube se reservan el derecho de usar los prompts de los clientes para mejorar el modelo, a menos que se use un nivel enterprise de pago y se verifique la cláusula de no entrenamiento. El RAG local ejecuta modelos con pesos que tú controlas; nada sale del host.
• Cláusulas de confidencialidad en contratos con clientes. Los acuerdos con asesoría externa, los NDA de M&A y los acuerdos sobre datos de pacientes frecuentemente prohíben la transmisión del material protegido a encargados del tratamiento externos. El RAG local sortea la cláusula por completo.
• Exposición a citaciones judiciales y procesos legales. Los documentos almacenados con un proveedor en la nube pueden ser requeridos mediante un proceso legal dirigido al proveedor, con obligaciones de divulgación de las que el responsable del tratamiento puede ni siquiera ser notificado a tiempo. Los documentos que nunca salen de tus instalaciones solo pueden ser requeridos a ti.

Los seis controles que todo despliegue necesita

1. 1
   Air-gap o control de egress estricto
   Why it matters: Confirma que los documentos y embeddings no pueden filtrarse mediante llamadas salientes — SDK de telemetría, sondas de actualización del modelo, informadores de fallos, callbacks de moderación de contenido, CDN de terceros para fuentes. O bien deshabilita el acceso a la red por completo (air-gap real) o ejecuta una lista de egress permitido que solo autorice servidores de actualización firmados.
2. 2
   Autenticación por usuario con acceso basado en roles
   Why it matters: Necesitas poder responder "quién accedió a qué documento" antes de que un regulador lo pregunte. Inicio de sesión único contra un proveedor de identidad, acceso por grupos a colecciones y ACL por documento donde el asunto lo requiera. Las cuentas compartidas no son un control — son un fallo de auditoría esperando a suceder.
3. 3
   Registros de auditoría inmutables que cubran la ingesta y la recuperación
   Why it matters: Para cada documento: quién lo subió, cuándo, ruta de origen, hash. Para cada consulta: quién preguntó, qué se preguntó (si el logging lo permite), qué chunks se recuperaron, de qué IDs de documentos procedían, qué respuesta se devolvió. Los registros deben ser a prueba de manipulaciones — solo de adición, firmados, con una retención suficiente para cubrir la ventana de investigación de la autoridad supervisora. Para el rastro de auditoría a nivel de prompt — control de versiones, registros de cambios y reversiones — consulta [flujos de trabajo de control de versiones de prompts](https://www.promptquorum.com/es/prompt-engineering/prompt-version-control-workflows).
4. 4
   Cifrado en reposo y en tránsito
   Why it matters: Cifrado de disco completo en el host, TLS para cualquier llamada interna entre servicios, y gestión de claves que sobreviva a un portátil robado o una cuenta de administrador comprometida. Claves gestionadas por el cliente para despliegues en la nube. Sin estas medidas, el robo de un dispositivo se convierte en una violación de datos notificable en virtud del artículo 33.
5. 5
   Trazabilidad determinista de datos del chunk a la fuente
   Why it matters: Cada chunk recuperado debe rastrearse hasta su documento de origen, página, sección y versión. Esto es lo que permite (a) verificar la respuesta, (b) atender una solicitud de eliminación, (c) defender el sistema ante un tribunal cuando se cuestiona un resumen generado. "No podemos reproducir qué chunk causó qué respuesta" no es una respuesta aceptable para una autoridad supervisora.
6. 6
   Procedimiento de eliminación por escrito que incluya el índice vectorial y los embeddings en caché
   Why it matters: Una solicitud de derecho al olvido debe propagarse desde el almacén de origen, a través del índice vectorial, hasta cualquier embedding en caché, y a través de la retención de registros de recuperación. La mayoría de los despliegues gestionan la eliminación del origen correctamente y olvidan el resto. Documenta el procedimiento de eliminación antes de la puesta en producción; practícalo con datos sintéticos.

Air-gap y control de egress

• Air-gap real — sin DHCP, sin resolución DNS a destinos públicos, sin TCP de salida. Las actualizaciones se realizan mediante medios firmados que un administrador conecta físicamente. Este es el modelo correcto para trabajo clasificado, determinadas redes hospitalarias y cualquier despliegue cuyo modelo de amenazas incluya una dependencia maliciosa.
• Lista de egress permitido — la red de salida solo se permite a una pequeña lista de destinos nombrados (servidores de actualización del modelo, tu proveedor de identidad, reenviadores de logs a colectores internos). Todo el demás tráfico se descarta en el cortafuegos. Este es el valor predeterminado práctico para la mayoría de los despliegues departamentales regulados.
• Qué buscar en la plataforma: cero telemetría por defecto, sin llamadas de salida durante la inferencia, sin CDN de fuentes en la interfaz de usuario, sin informadores de fallos que envíen cargas útiles. Verifica con una captura de paquetes o una herramienta como Little Snitch en el banco de pruebas antes de pasar a producción.
• Gobernanza de actualizaciones — los pesos del modelo, los pesos del embedder, el código de la aplicación y los parches del SO pasan todos por una ventana de actualización controlada. El administrador que promueve una actualización lo firma por escrito; el cambio se registra.
• Ruptura de air-gap frecuente: un SDK de analítica incluido con un componente de interfaz de terceros, una referencia a CDN de fuentes en el chrome de la aplicación, o una sonda de "comprobar actualizaciones" que se ejecuta al iniciar. Por eso el paso de verificación importa — no asumas nada sobre los valores predeterminados.

Registro de auditoría que supere una revisión

• Eventos de ingesta: ID de documento, hash (SHA-256), nombre de archivo, ruta de origen, subido por, marca de tiempo, etiqueta de clasificación, tamaño, número de páginas, grupo propietario, clase de retención. Etiqueta cada documento en la ingesta — la clasificación retroactiva de corpus grandes es difícil y rara vez está completa.
• Eventos de recuperación: ID de consulta, ID de usuario, marca de tiempo, IDs de chunks recuperados (e IDs de documentos de los que proceden), puntuaciones de recuperación, hash de la respuesta final, identificador del modelo, identificador del embedder, top-K utilizado. El texto de la consulta en sí es sensible — regístralo solo si tu base jurídica de tratamiento lo cubre; de lo contrario, registra el hash y la marca de tiempo.
• Eventos administrativos: promoción del modelo, cambio de embedder, reconstrucción del índice, cambios de usuario/grupo, cambios de ACL, cambios de política de acceso. Cada evento firmado por el administrador responsable.
• Resistencia a manipulaciones: registro de solo adición, cadena de hashes (cada entrada hace referencia al hash de la entrada anterior), clave de firma fuera de banda, reconciliación periódica con una copia separada mantenida por un administrador diferente o en un medio de escritura única.
• Retención: se alinea con la ventana de investigación de la autoridad supervisora — como mínimo el período de retención del asunto; comúnmente seis a siete años para industrias reguladas; más donde se apliquen normas sectoriales.
• Pipeline: la aplicación emite eventos estructurados; un reenviador los envía a un almacén de logs separado con acceso de escritura restringido. El servidor de aplicaciones nunca debe tener permiso para eliminar o reescribir entradas de logs — la separación de funciones es lo que hace que el log sea creíble.

Trazabilidad de datos del chunk a la fuente

• Trazabilidad a nivel de documento: cada documento tiene un ID interno estable, un hash de contenido, una marca de tiempo de ingesta, un propietario, una clasificación y una clase de retención. El archivo original permanece en el almacén de origen; el sistema RAG mantiene una referencia, no el original.
• Trazabilidad a nivel de chunk: cada chunk hace referencia a su ID de documento padre, página (para PDFs), sección (para documentos estructurados), desplazamiento de caracteres, longitud y versión de la estrategia de chunking. Cuando vuelvas a hacer chunking (lo harás), los chunks antiguos se marcan como obsoletos, no se eliminan in situ — para que los logs de recuperación antiguos sigan siendo resolubles.
• Trazabilidad a nivel de embedding: cada vector de embedding hace referencia a su ID de chunk e identificador de embedder. Cuando cambies de embedder, los vectores antiguos se conservan hasta que los nuevos sean validados y cualquier asunto que los referenciara esté cerrado; solo entonces se purgan.
• Trazabilidad a nivel de respuesta: cada respuesta generada hace referencia a los IDs de chunks que la produjeron, el identificador del modelo, la versión de la plantilla de prompt y la marca de tiempo. Cuando un usuario pregunta "¿de dónde vino esta respuesta?", el sistema resuelve chunk → documento → página con un clic.
• Reindexación sin romper la trazabilidad: las reconstrucciones preservan los IDs de documentos e incrementan las versiones de la estrategia de chunking. Los IDs de chunks antiguos siguen siendo resolubles en los registros de recuperación incluso después de que el índice activo haya avanzado.

Cifrado y control de acceso

• Cifrado en reposo — cifrado de disco completo en el host (LUKS en Linux, BitLocker en Windows, FileVault en macOS para portátiles). Para servidores, cifra también las particiones que alojan el almacén vectorial y la etapa de ingesta. Claves gestionadas por el cliente para cualquier despliegue en la nube, con rotación de claves según tu política.
• Cifrado en tránsito — TLS para cualquier salto entre servicios, incluso en localhost. Política de cifrado alineada con tu línea base sectorial. TLS mutuo donde el modelo de amenazas lo justifique — típicamente servidor a servidor en despliegues en la nube.
• Autenticación — inicio de sesión único contra tu proveedor de identidad existente (OIDC, SAML). Sin cuentas locales en producción. MFA obligatorio para cualquier usuario con acceso administrativo o a colecciones sensibles.
• Autorización — acceso basado en grupos a nivel de colección; ACL a nivel de documento donde el asunto lo requiera (p. ej., salas de datos de M&A, investigaciones de empleo). El pipeline de recuperación debe aplicar las ACL en el momento de la consulta — no solo la interfaz de usuario. Un usuario que no puede ver un documento tampoco debe recibir sus chunks en la respuesta.
• Acceso administrativo — gestión de acceso privilegiado para cualquier cuenta que pueda leer o reconstruir índices, ver registros de auditoría o cambiar ACL. La elevación justo a tiempo con justificación registrada supera a los derechos de administrador permanentes.
• Seguridad de endpoint — dispositivos gestionados para despliegues con portátil (registrados en MDM, cifrados, política de bloqueo de pantalla aplicada). Un portátil de profesional individual con el almacén de documentos descifrado y desatendido en una cafetería es la violación del RGPD que no quieres reportar.

Patrón de portátil de un solo usuario

• Hardware — un portátil de categoría workstation con cifrado de disco completo, una GPU discreta (o una máquina reciente de memoria unificada) y al menos 32 GB de RAM. El modelo y el embedder deben caber en memoria junto con la caché del almacén vectorial. Para requisitos de hardware y selección de modelos por VRAM, consulta la guía de hardware para LLM locales.
• Software — una aplicación RAG de escritorio autocontenida que se ejecuta localmente; un LLM de código abierto con pesos descargados una vez y fijados a un hash; un embedder de código abierto; un almacén vectorial local en el disco cifrado. Para una comparación de modelos de código abierto adecuados para RAG local, consulta los mejores modelos de código abierto para Ollama.
• Postura de red — con air-gap durante el trabajo; reconectado solo para actualizaciones firmadas explícitas. Configura el cortafuegos del SO para descartar todas las conexiones de salida por defecto y crea excepciones explícitas para el flujo de actualización.
• Manejo de documentos — documentos de origen en el disco cifrado; una estructura de carpetas por asunto; copias de seguridad semanales cifradas en un disco externo almacenado en un lugar diferente.
• Postura de auditoría — el registro de auditoría a nivel del SO (inicio de sesión, acceso a archivos, eventos de periféricos) es el suelo mínimo. Los eventos a nivel de aplicación son más sencillos con el patrón de servidor on-prem; para el patrón de portátil, trata el log del SO como el registro principal y complementa con notas manuales por asunto.
• Limitaciones — un portátil de un solo usuario no es una plataforma multiusuario. Compartir el portátil, compartir cuentas o copiar el almacén de documentos al portátil de un compañero rompe la postura de auditoría y la evaluación de la base jurídica.

Patrón de servidor on-prem

• Hardware — un servidor con una o dos GPU de nivel empresarial (las GPU de categoría workstation son aceptables para corpus más pequeños), discos redundantes, memoria ECC y un SAI. Planifica 2–4× el almacenamiento de tu corpus de documentos sin procesar para cubrir vectores, índices, logs y copias de seguridad.
• Red — una VLAN dedicada detrás del cortafuegos corporativo; lista de egress permitido o air-gap completo según el modelo de amenazas. Acceso interno solo a través de la red corporativa, sin ingreso público.
• Pila de software — una plataforma RAG autoalojada (una imagen de servidor independiente o un despliegue en contenedores), un LLM de código abierto como modelo de chat, un embedder de código abierto y un almacén vectorial apropiado para el tamaño del corpus. El servidor de aplicaciones, el almacén vectorial y el reenviador de logs se ejecutan como procesos separados con cuentas de servicio separadas.
• Identidad — federada con el proveedor de identidad corporativo; la pertenencia a grupos controla el acceso a las colecciones. Las colecciones sensibles requieren flujos de aprobación adicionales.
• Copia de seguridad y recuperación ante desastres — copias de seguridad incrementales nocturnas del almacén de documentos y el índice vectorial; copias de seguridad completas semanales; copia externa mantenida por TI. Procedimiento de restauración documentado y probado al menos anualmente.
• Operaciones — ventana de parcheo según la política de gestión de cambios; revisiones de acceso trimestrales; procedimiento de eliminación para solicitudes de derecho al olvido ensayado; ruta documentada de actualización del modelo y el embedder que preserve la trazabilidad.
• Planificación de capacidad — unos pocos miles de documentos y 5–50 usuarios concurrentes caben cómodamente en un servidor GPU de gama media. Más allá de eso, planifica un host más potente o pasar al patrón de nube privada.

Opciones de bases de datos vectoriales para RAG on-prem

Patrón de nube privada en la UE

• Selección del proveedor — la oferta soberana en la UE de un hiperescalador o un proveedor de nube europeo. El DPA debe listar cada subencargado del tratamiento; los mecanismos de transferencia deben abordarse si algún subencargado está fuera del EEE. El análisis del impacto de la transferencia al estilo Schrems II forma parte del expediente incluso cuando el encargado inmediato tiene sede en la UE.
• Región — exclusivamente en la UE, con garantías explícitas de residencia de datos. Replicación entre regiones solo hacia otras regiones de la UE. Sin región de EE.UU. como failover, ni siquiera temporalmente, ni siquiera para copias de seguridad.
• Cifrado — claves gestionadas por el cliente con rotación; bring-your-own-key donde el proveedor lo admita; eventos de acceso a claves registrados separadamente de los logs operativos del proveedor de nube.
• Red — VPC privada sin ingreso público; acceso solo a través de conectividad privada (enlace dedicado o VPN) desde tu red corporativa; lista de egress permitido para cualquier dependencia de salida.
• Identidad — federada con tu IdP corporativo; IAM nativo de la nube vinculado a identidades de usuario, no a cuentas de servicio compartidas; ACL por colección aplicadas en el pipeline de recuperación.
• Logging — log de auditoría nativo de la nube alimentado en tu SIEM existente; ingesta separada para eventos de auditoría de la aplicación; retención a prueba de manipulaciones que cumpla las expectativas del supervisor.
• Contratos — el DPA debe cumplir el artículo 28, listar subencargados, abordar las cláusulas contractuales tipo donde sea necesario e incluir una cláusula explícita de no entrenamiento con datos del cliente que cubra tanto los pesos del LLM como cualquier servicio auxiliar (búsqueda, telemetría, soporte).

Clasificación según la Ley de IA de la UE: riesgo limitado frente a alto riesgo

• Riesgo limitado (la mayoría de los RAG locales) — el sistema recupera y resume documentos para asistir a un humano; el humano toma la decisión. Las obligaciones son principalmente de transparencia: los usuarios deben saber que están interactuando con una IA, el contenido generado debe ser identificable como tal, y sin diseño manipulador o engañoso.
• Alto riesgo — la recuperación alimenta una decisión automatizada en dominios que la Ley enumera: puntuación de solvencia, selección de personal, admisiones educativas, servicios públicos esenciales, aplicación de la ley, migración, justicia, identificación biométrica, infraestructura crítica. Un RAG de apoyo a la decisión clínica que recomienda tratamientos es de alto riesgo; un RAG que resume protocolos clínicos para ayudar a un médico a leer directrices más rápido no lo es.
• Obligaciones de alto riesgo — sistema de gestión de riesgos a lo largo del ciclo de vida, gobernanza de datos (datos de entrenamiento, validación y prueba documentados), documentación técnica, registro automático de eventos, transparencia e información a los usuarios, supervisión humana, medidas de precisión y robustez, evaluación de conformidad antes de la comercialización, supervisión post-comercialización.
• Consideraciones sobre la IA de propósito general — usar un LLM de propósito general (de código abierto o no) no transfiere las obligaciones de alto riesgo al proveedor del modelo. El implantador (tu organización) lleva las obligaciones de alto riesgo para el sistema que construyes con ese modelo.
• Prácticas prohibidas — puntuación social, rastreo no selectivo de imágenes faciales, reconocimiento de emociones en lugares de trabajo y centros educativos, determinada categorización biométrica en tiempo real. Estas quedan descartadas independientemente de lo localmente que las ejecutes.
• Documentación como artefacto de auditoría — el expediente técnico requerido para sistemas de alto riesgo no es un entregable único; es un documento vivo. Vincúlalo a tu proceso de gestión de cambios para que cada promoción de modelo, cambio de embedder y cambio de ACL quede reflejado.

Requisitos de la EIPD

• Cuándo es obligatoria — evaluación sistemática y exhaustiva que incluya elaboración de perfiles con efectos jurídicos; tratamiento a gran escala de datos de categorías especiales (salud, datos jurídicos, biométricos, raciales, políticos, religiosos, sindicales); monitoreo sistemático de zonas de acceso público. Las autoridades supervisoras nacionales publican listas de operaciones que siempre requieren una EIPD — consulta la tuya.
• Alcance de la EIPD — finalidad y base jurídica; descripción de las operaciones de tratamiento; evaluación de necesidad y proporcionalidad; evaluación de riesgos para los interesados; mitigaciones y riesgo residual; consulta con el DPD y (donde el riesgo residual sea alto) con la autoridad supervisora antes de iniciar el tratamiento.
• Riesgos específicos del RAG a abordar: reidentificación de individuos a partir de chunks recuperados; generación de información inexacta que afecte a una persona; filtración a través de logs o copias de seguridad; completitud de la eliminación en solicitudes de derecho al olvido; contaminación cruzada entre colecciones; acceso demasiado amplio para usuarios con muchos privilegios.
• Mitigaciones a documentar — los seis controles anteriores, más redacción o seudonimización a nivel de chunk donde la base jurídica sea el consentimiento o el interés legítimo; procedimiento de eliminación con evidencia de ensayo; revisiones de acceso en una cadencia establecida.
• Revisores — el DPD lo aprueba; la autoridad supervisora es consultada donde el riesgo residual tras la mitigación siga siendo alto. La EIPD firmada va en el expediente técnico junto con la documentación de conformidad con la Ley de IA de la UE si el sistema también es de alto riesgo.
• Documento vivo — vuelve a ejecutar la EIPD cuando el corpus se amplíe materialmente, cuando el modelo o el embedder cambie, cuando los límites de acceso cambien, o anualmente como base. Vincula esto a tu proceso de gestión de cambios.

Notas específicas para Alemania (Datenschutz)

• Co-determinación del comité de empresa (Betriebsrat) — en virtud del §87 BetrVG, cualquier sistema que monitoree el rendimiento o el comportamiento de los empleados requiere un acuerdo del comité de empresa antes del despliegue. Un RAG sobre contenido generado por empleados (correos electrónicos, documentos internos) típicamente lo activa. Involucra al comité de empresa en el momento del diseño; el acuerdo (Betriebsvereinbarung) pasa a formar parte del expediente de base jurídica.
• Confidencialidad sectorial — el §203 StGB penaliza la violación de la confidencialidad profesional (abogados, médicos, asesores fiscales, auditores). Desplegar un RAG de forma que exponga datos de clientes protegidos a personal no vinculado o a encargados del tratamiento externos puede constituir un delito penal, no solo un asunto civil. El patrón on-prem o con air-gap es la opción más segura en estos sectores.
• Telemediengesetz (TTDSG) y telemetría — la telemetría de salida que toca los dispositivos de los usuarios finales está regulada no solo por el RGPD sino también por el TTDSG. El air-gap elimina la cuestión; los despliegues con control de egress deben verificar que cualquier llamada de salida esté consentida, sea necesaria o sea estrictamente técnica.
• Expectativas de transparencia — las normas de transparencia federales y estatales ocasionalmente requieren la divulgación de la toma de decisiones asistida por IA a los interesados. Incluso donde no sea estrictamente requerido, la divulgación en lenguaje claro de que la recuperación es asistida por IA y que el revisor humano sigue siendo responsable de la decisión es el valor predeterminado defendible.
• Aufsichtsbehörden (autoridades supervisoras estatales) — la supervisión del Datenschutz está organizada a nivel estatal para el sector privado. Contacta con el Landesbeauftragte für Datenschutz relevante donde se necesite consulta en virtud del artículo 36. Los documentos de posición de los principales Landesbeauftragte sobre herramientas de IA son insumos útiles para la EIPD.
• Idioma de la documentación — las autoridades supervisoras alemanas aceptan documentación en inglés, pero los artefactos clave dirigidos a los usuarios (avisos de privacidad, divulgaciones de transparencia, acuerdos del comité de empresa) deben estar en alemán por razones tanto legales como prácticas.

Lista de verificación de cumplimiento antes de la puesta en producción

• ☐ Base jurídica documentada para cada categoría de datos de origen — consentimiento, contrato, obligación legal, interés vital, tarea pública o interés legítimo con una prueba de ponderación en el expediente.
• ☐ EIPD aprobada por el DPD, con un procedimiento de eliminación ensayado adjunto.
• ☐ Registro de actividades de tratamiento (artículo 30) actualizado para incluir el sistema RAG, las categorías de datos, la retención, los destinatarios y los mecanismos de transferencia (típicamente ninguno para RAG local).
• ☐ Seis controles verificados de extremo a extremo: air-gap o lista de egress permitido, RBAC, registros de auditoría, cifrado, trazabilidad, procedimiento de eliminación.
• ☐ Captura de paquetes de salida limpia durante una prueba de saturación de 24 horas; repetida tras cada actualización de la aplicación.
• ☐ Integración del proveedor de identidad probada con un usuario real de cada nivel de acceso; el acceso a colecciones sensibles requiere elevación separada.
• ☐ Copias de seguridad realizadas y una restauración realmente probada en hardware aislado, no solo verificada en un panel de estado.
• ☐ Procedimiento de derecho al olvido ensayado con datos sintéticos que cubra el almacén de origen, el índice vectorial, los embeddings en caché y la retención del registro de recuperación.
• ☐ Clasificación según la Ley de IA de la UE confirmada (riesgo limitado frente a alto riesgo); expediente técnico en su lugar si es de alto riesgo.
• ☐ Contratos de proveedores (si los hay) revisados: DPA conforme al artículo 28, subencargados listados, cláusula de no entrenamiento que cubra los datos del cliente.
• ☐ Acuerdo del comité de empresa establecido donde el contenido generado por empleados esté en el ámbito de aplicación (Alemania; normas similares en otros lugares de la UE).
• ☐ Aviso de transparencia redactado en lenguaje comprensible para el usuario que explique la asistencia de IA, el humano en el bucle y el flujo de datos.
• ☐ Procedimiento de respuesta a incidentes actualizado para incluir escenarios específicos del RAG: filtración del índice, manipulación de logs, fallo de eliminación, cambio de modelo con ruptura de trazabilidad posterior.
• ☐ Revisión de acceso trimestral programada y asignada; primera revisión en el calendario antes de la puesta en producción.
• ☐ Actualización anual de la EIPD programada y vinculada al proceso de gestión de cambios.

Errores frecuentes

• Error 1: Tratar "local" como sinónimo de "conforme". Ejecutar on-prem resuelve las preguntas de transferencia y de encargado del tratamiento; no resuelve la base jurídica, la EIPD, el registro de auditoría ni los derechos de los interesados. El cumplimiento es un programa por capas, no una elección de despliegue.
• Error 2: Saltarse la EIPD porque el sistema es "solo una herramienta de búsqueda". Una herramienta de búsqueda que ingiere datos de categorías especiales a gran escala es exactamente lo que cubre el artículo 35. Saltarse la EIPD significa saltarse la defensa en auditoría.
• Error 3: Registrar el texto de la consulta sin verificar la base jurídica. Las propias consultas son datos personales cuando hacen referencia a individuos. Decide en el momento del diseño si tu base jurídica de tratamiento cubre el registro de consultas; si no, registra solo el hash y los metadatos.
• Error 4: Olvidar los embeddings en caché en el procedimiento de eliminación. La eliminación del origen funciona. La reconstrucción del índice vectorial funciona. La capa de caché que tu plataforma añadió para el rendimiento, las huellas de embedding en el registro de recuperación y el historial de respuestas en el almacén de chat son las partes que se pasan por alto.
• Error 5: Permitir a los usuarios con muchos privilegios saltarse las ACL de colección. "Los administradores pueden verlo todo" es conveniente y muy común; también es la razón más frecuente por la que las auditorías salen mal. El acceso privilegiado debe estar a su vez controlado, limitado en el tiempo y justificado por uso.
• Error 6: Reutilizar un espacio de trabajo para varios asuntos o clientes. La contaminación cruzada de citas y contexto es un fallo de confidencialidad incluso antes de que ninguna parte externa lo vea. Un asunto o cliente por colección; ACL separadas; retención separada.
• Error 7: Comprar air-gap y luego conectar un teléfono personal para las pruebas. El perímetro de air-gap debe incluir a las personas que pueden transportar datos a través de él. La política de endpoints es parte del control, no una preocupación separada.
• Error 8: Tratar la elección de modelo y embedder como "configurar y olvidar". Cada actualización es un evento de gestión de cambios con implicaciones para la EIPD, la trazabilidad y el rastro de auditoría. Planifica el flujo de trabajo de actualización antes del primer despliegue en producción.

Fuentes

• Texto completo del RGPD (Oficial) — Texto completo del Reglamento General de Protección de Datos con comentario artículo por artículo.
• Texto completo de la Ley de IA de la UE — Texto completo del reglamento con el marco de clasificación de riesgos.
• Marco de Gestión de Riesgos de IA del NIST — Marco de gobernanza federal de EE.UU. aplicable a la evaluación de riesgos de IA.
• BDSG-Neu (Ley Federal Alemana de Protección de Datos) — Implementación alemana del RGPD con adiciones sectoriales.
• Directrices del CEPD sobre EIPD — Orientación del Comité Europeo de Protección de Datos sobre cuándo y cómo realizar EIPDs.
• BfDI (Comisionado Federal Alemán para la Protección de Datos) — Documentos de posición del Comisionado Federal Alemán para la Protección de Datos sobre despliegues de IA.

FAQ

Lecturas relacionadas

• AnythingLLM vs PrivateGPT vs Open WebUI: el mejor RAG local — qué plataformas autoalojadas se adaptan a cada postura de cumplimiento, con notas sobre telemetría y licencias.
• Agentes de IA locales para flujos de trabajo empresariales y cumplimiento en la UE — tema de cumplimiento adyacente cuando la recuperación alimenta pasos de flujo de trabajo automatizados en lugar de un lector humano.
• Automatización local de correo electrónico y calendario con LLM — patrones de automatización empresarial adyacentes donde se aplica el mismo conjunto de controles.
• RAG local en tus PDFs paso a paso — guía de implementación práctica para los patrones on-prem y de portátil.
• Chatea con 1.000 PDFs localmente — orientación operativa para corpus más grandes que presionan el techo del on-prem.
• Hub de Power Local LLM — la biblioteca completa de guías para despliegues de LLM autoalojados.