RGPD y Copilot RAG: checklist para empresa

Desplegar un copilot interno con RAG cumpliendo el RGPD exige más que aceptar un acuerdo de tratamiento: hay que controlar qué documentos se indexan, quién accede a qué y cómo se auditan las respuestas. La conversación suele empezar así: ?Queremos conectar SharePoint y que el asistente responda sobre nuestros documentos?. La idea es buena. El problema aparece cuando ?nuestros documentos? significa, en la práctica, contratos, nóminas, correos, expedientes, anexos legales, PDFs duplicados y carpetas a las que hoy ya accede más gente de la que debería. Un sistema RAG o un copilot interno no arregla ese desorden: lo hace más visible y más rápido.

Desde el punto de vista del RGPD, el error más caro no es usar IA. Es conectar un corpus documental sin decidir qué datos deben entrar, quién puede ver qué, qué base legal sostiene el tratamiento y cómo vas a evitar que el asistente devuelva información que el usuario no debería conocer. El proyecto técnico puede ser muy bueno y seguir siendo un problema de privacidad si el diseño de acceso y minimización está mal resuelto.

El error más habitual: indexarlo todo ?y luego ya afinaremos?

Eso casi siempre sale mal. Cuando metes todo el repositorio en el índice desde el primer día, arrastras duplicados, versiones antiguas, carpetas sin gobierno y documentos que nunca debieron entrar. Además, fuerzas al equipo a resolver el problema de permisos en el momento más delicado: cuando el asistente ya está respondiendo y la gente asume que si el sistema lo devuelve es porque ?se podía verá.

• Normalmente sí tiene sentido empezar con políticas, procedimientos, manuales internos, FAQs y documentación funcional vigente.
• Normalmente no conviene empezar por nóminas, expedientes laborales, documentación médica, buzones personales o carpetas históricas sin depurar.
• Los documentos con datos personales pueden entrar, pero solo si el caso de uso lo justifica, los permisos están bien heredados y el riesgo se ha evaluado de verdad.
• Si no sabes quién es el propietario de una carpeta o cómo se actualiza, esa carpeta no está lista para alimentar un copilot.

Las 6 preguntas que deberías responder antes de conectar el corpus

1. 1?Qué datos personales van a entrar en el sistema? No ?en teoría?, sino colecciones, carpetas y tipos documentales concretos.
2. 2?Cuál es la finalidad exacta del tratamiento? Un asistente para responder dudas operativas no justifica indexar cualquier documento de la empresa.
3. 3?Qué usuarios podrán consultar qué contenido? El sistema debe heredar permisos o aplicar controles equivalentes, no crear una vía paralela de acceso.
4. 4?Qué información debe quedar fuera desde el primer día? Especialmente datos sensibles, documentación disciplinaria, información muy privada o carpetas sin propietario claro.
5. 5?Cómo se gestionan la retención, la actualización y el borrado? Si el documento cambia o deja de ser válido, el índice debe reflejarlo.
6. 6?Qué terceros intervienen? Modelo, hosting, vector store, logs, soporte y cualquier transferencia o acceso que deba revisarse contractualmente.

Controles mínimos que esperamos ver en un proyecto serio

• Permisos por documento o colección heredados del sistema fuente o replicados de forma fiable.
• Exclusión explícita de carpetas o bibliotecas fuera de alcance, en lugar de ?meter todo y filtrar luego?.
• Logs de acceso y trazabilidad básica: quién consulta, sobre qué corpus y con qué resultado.
• Versionado y política de actualización del índice para no responder con documentos obsoletos.
• Revisión humana o escalado en consultas sensibles, ambiguas o que puedan exponer datos personales de forma indebida.
• Pruebas de fuga de permisos antes del despliegue: usuarios de distintos perfiles validando que el sistema no devuelve contenido cruzado.

Cuándo deberías elevar el nivel y hacer una evaluación de impacto de verdad

No todos los copilots internos exigen el mismo nivel de análisis, pero sí hay señales claras de que debes parar y profundizar más. Por ejemplo: si el sistema trata datos de empleados a gran escala, si entra en categorías especiales de datos, si puede facilitar monitorización o profiling, si se conecta a varias fuentes con permisos heterogéneos o si sus respuestas influyen en decisiones relevantes. En esos escenarios, el proyecto ya no se gestiona bien con un simple checklist.

El papel del DPO y del equipo legal en el proyecto

En muchos proyectos de RAG o copilot interno, el equipo técnico arranca la implementación sin involucrar al DPO o a la asesoría legal hasta que el sistema ya está funcionando. Eso es un error que se paga caro: si el DPO detecta un problema una vez que el sistema está en uso, la corrección es mucho más costosa (técnica y organizativamente) que haberlo resuelto en la fase de diseño.

Lo recomendable es involucrar al DPO (o al responsable de privacidad, sea interno o externo) desde el momento en que se define el alcance del corpus. No necesita participar en cada decisión técnica, pero sí debe validar tres cosas: qué datos entran, con qué base legal y qué controles de acceso se aplican. Si esas tres preguntas están resueltas antes de empezar a indexar, el proyecto tiene mucho menos riesgo regulatorio.

El DPO valida el tratamiento, pero hay una decisión que sigue siendo de dirección: la norma interna de uso, es decir, qué puede hacer cada persona con la IA en su día a día, incluidas las herramientas que ya está usando por su cuenta y que no pasan por el copilot. Es lo que se trabaja en la mentoría en IA para dirección.

Terceros y encargados del tratamiento: qué revisar en los contratos

Un sistema RAG o copilot interno rara vez se ejecuta exclusivamente con infraestructura propia. Normalmente intervienen terceros: el proveedor del LLM (OpenAI, Azure OpenAI, Anthropic), el servicio de hosting del vector store, el integrador que implementa el sistema y, en muchos casos, un servicio de OCR o procesamiento de documentos. Cada uno de estos terceros puede tener acceso a los datos que se indexan o que se pasan como contexto al modelo.

• Revisa si el proveedor del LLM procesa los datos fuera del Espacio Económico Europeo. Azure OpenAI permite seleccionar la región de procesamiento; otras APIs pueden no ofrecer esa garantía.
• Verifica que el contrato de encargado del tratamiento (DPA) cubre el uso específico que vas a hacer. Un DPA genérico de un servicio cloud puede no cubrir el tratamiento de datos personales dentro de un flujo RAG.
• Confirma que los datos no se usan para entrenar el modelo del proveedor. La mayoría de proveedores enterprise lo garantizan, pero conviene tenerlo por escrito en el contrato, no solo en la página de FAQ.
• Documenta la cadena de subencargados. Si tu integrador usa un servicio de OCR de un tercer proveedor que a su vez procesa en servidores de otro país, la cadena de responsabilidades debe estar clara.

Esta cautela no nace solo del RGPD: trabajar antes con CRM, ERP y datos financieros ya obliga a tener claro qué información no debe salir hacia una herramienta externa, nombres de esquema, datos de cliente, credenciales. Aplicar ese mismo criterio al conectar documentos corporativos a un LLM es lo que evita muchos de los problemas que este artículo describe.

Escenarios habituales y nivel de riesgo

No todos los copilots internos tienen el mismo perfil de riesgo desde la perspectiva del RGPD. El nivel de análisis y control necesario varía mucho según qué datos se indexan y quién accede al sistema.

Qué pasa cuando un usuario hace una pregunta que no debería poder responder

Este es uno de los riesgos más sutiles de un sistema RAG en empresa. Un usuario hace una pregunta aparentemente inocua y el sistema, al recuperar fragmentos de documentos, incluye información de un documento al que ese usuario no debería tener acceso. El usuario no pidió ver ese documento, pero el sistema se lo ha mostrado como parte de la respuesta. Desde la perspectiva del RGPD, eso puede constituir una brecha de confidencialidad.

Para prevenir esto, el sistema debe filtrar los documentos recuperados según los permisos del usuario antes de pasarlos al LLM como contexto. No basta con filtrar la respuesta final: si el documento llega al prompt del modelo, ya ha sido «procesado» en el sentido técnico. El filtrado debe ocurrir en la fase de recuperación (retrieval), no después de la generación.

Un enfoque pragmático por fases suele funcionar mejor

1. 1Fase 1: corpus pequeño y de bajo riesgo. Procedimientos, FAQs, documentación operativa y fuentes bien gobernadas.
2. 2Fase 2: revisión de permisos y ampliación selectiva. Se añaden nuevas fuentes solo cuando el modelo de acceso está validado.
3. 3Fase 3: hardening. Logs, exclusiones avanzadas, métricas de respuesta, pruebas de fuga y gobierno continuo del corpus.
4. 4Fase 4: extensión a casos más sensibles solo si el valor de negocio compensa claramente el esfuerzo de compliance y control.

Si estás preparando el proyecto, te conviene leer también qué necesita tu empresa para implementar RAG y qué cambia al conectar SharePoint, Drive o Confluence. Y si además te preocupa el marco regulatorio más amplio, enlázalo con AI Act para pymes.

Si necesitas orientacion sobre como implementar un copilot con RAG en tu empresa, en nuestra página de copilot RAG empresarial explicamos el proceso completo.

Si te interesa profundizar, en qué documentos alimentan un copilot interno exploramos este tema en detalle.

Para más contexto, puedes consultar la guía del RGPD de la AEPD.