Muchas empresas llegan a esta conclusión demasiado pronto: “hemos pagado un plan Enterprise” o “el asistente está conectado a nuestra nube privada; por tanto, cumplimos el RGPD”. Puede que el contrato y la configuración sean adecuados. Puede que no. El nombre comercial del plan no responde por sí solo a dónde viaja un prompt, quién lo procesa o qué subencargados intervienen.
El riesgo aparece cuando se conecta una base documental privada a un modelo frontera mediante RAG, un conector o una API. El documento puede estar almacenado en Europa y, aun así, una consulta, sus fragmentos recuperados o la respuesta pueden seguir una ruta distinta según el producto, la región elegida y el tipo de despliegue.
Este artículo no es asesoramiento jurídico. Es una guía para que dirección, IT, seguridad y legal hagan las preguntas correctas antes de usar IA con datos de clientes, empleados, contratos o información cubierta por un NDA.
Una cuenta premium puede mejorar controles. No prueba cumplimiento.
Un plan de pago puede incorporar mejores condiciones de tratamiento, administración, registros, retención o controles de acceso. Eso es relevante. Pero el cumplimiento no se compra con una etiqueta “Enterprise”.
El RGPD exige que, cuando un responsable encarga el tratamiento a un proveedor, utilice encargados que ofrezcan garantías suficientes y que el tratamiento se rija por contrato u otro acto jurídico. También exige autorización previa específica o general por escrito para que el encargado recurra a otro encargado (artículo 28 del RGPD).
Traducido a una implantación de IA: hay que saber qué empresa presta el servicio, qué proveedores auxiliares intervienen, qué datos reciben y con qué autorización. “Es una nube privada” no sustituye esas respuestas.
El dato no tiene que salir entero para que exista riesgo
Un sistema RAG suele dividir documentos en fragmentos, recupera los que parecen relevantes y envía una instrucción al modelo junto con esos fragmentos. Aunque no mandes el PDF completo, un extracto puede contener datos personales, precios, una cláusula de confidencialidad, un identificador de cliente o información estratégica.
Tampoco conviene asumir que “no se usa para entrenar” resuelve toda la cuestión. Que un proveedor no emplee el prompt para entrenar modelos es un control importante, pero no dice por sí solo dónde se procesa, cuánto tiempo se conserva, qué monitorización aplica el servicio ni bajo qué condiciones se produce una transferencia internacional.
Microsoft lo ilustra bien en su documentación de modelos vendidos desde Azure: indica que los prompts y respuestas no están disponibles para otros clientes ni para OpenAI, y que no se usan para entrenar modelos base sin permiso. A la vez, explica que la ubicación del procesamiento depende del tipo de despliegue: un despliegue Global puede procesar prompts y respuestas en cualquier geografía donde esté desplegado el modelo, mientras que otros tipos de despliegue tienen reglas de ubicación distintas (Microsoft Learn). No es un defecto de Azure; es un ejemplo de por qué hay que revisar la configuración concreta y no solo el nombre del producto.
El RGPD no prohíbe toda transferencia. Exige una base y garantías.
El capítulo V del RGPD regula las transferencias de datos personales a terceros países u organizaciones internacionales. El artículo 44 establece que esas transferencias solo pueden producirse si se cumplen las condiciones del capítulo, también para transferencias posteriores, de modo que no se menoscabe el nivel de protección garantizado por el Reglamento.
El Comité Europeo de Protección de Datos publicó sus Recomendaciones 01/2020 sobre medidas que complementan los instrumentos de transferencia. Para una empresa, la consecuencia práctica es sencilla: si hay una transferencia, no basta con marcar una casilla en el alta del proveedor. Hay que identificar la transferencia, el mecanismo aplicable y las medidas técnicas, organizativas o contractuales que correspondan.
No todos los flujos con un proveedor estadounidense implican automáticamente un incumplimiento. Tampoco una región europea garantiza por sí sola que no exista ningún acceso o transferencia relevante. La respuesta sale del contrato, la arquitectura, los subencargados y la configuración real.
El NDA añade otra capa: la autorización contractual
Un NDA puede exigir que la información confidencial se use solo para una finalidad concreta, se comparta únicamente con personas autorizadas y no se entregue a terceros sin consentimiento. Si un empleado pega datos confidenciales en un servicio no aprobado, puede incumplirse el NDA aunque no haya datos personales y aunque la herramienta sea de pago.
Si el servicio sí está aprobado, el contrato con el cliente y el contrato con el proveedor de IA deben encajar. Revisa, como mínimo, si el NDA permite usar subencargados, si el proveedor queda vinculado por obligaciones de confidencialidad equivalentes y si el uso previsto coincide con la finalidad permitida.
La conclusión no es “prohibir toda IA”. Es dejar de asumir que la privacidad de la nube o el precio de la licencia resuelven un compromiso que también es contractual.
Cuatro comprobaciones antes de activar un conector RAG o una API
1. Dibuja el recorrido de una consulta
No preguntes solo dónde vive el repositorio documental. Pregunta dónde se generan embeddings, dónde se recuperan los fragmentos, dónde se ejecuta la inferencia, dónde se guardan los logs y quién puede acceder a ellos. Pide esa información por escrito al proveedor o revísala en la documentación de la versión exacta que vais a contratar.
2. Separa región, residencia y procesamiento
Una región de almacenamiento, una promesa de residencia de datos y la ubicación efectiva del procesamiento no siempre significan lo mismo. Comprueba si el modelo ofrece despliegue regional, de zona de datos o global, y qué dice el proveedor sobre cada uno. Si la respuesta es ambigua, no cargues información protegida hasta aclararla.
3. Revisa el DPA y los subencargados
Localiza el acuerdo de tratamiento de datos, la lista de subencargados, el mecanismo de transferencia que se aplica cuando corresponde, los plazos de retención y la gestión de solicitudes de acceso. No basta con un enlace comercial a “seguridad y privacidad”.
4. Aplica el principio de mínimo dato
El mejor prompt para información sensible es el que no incluye información innecesaria. Anonimiza o seudonimiza cuando el caso lo permita, limita el acceso por roles, excluye repositorios de alto riesgo y define qué clases de documento no pueden entrar en el sistema. Después prueba que esas reglas funcionan.
Un piloto responsable empieza con un inventario, no con un chatbot
Antes de conectar una carpeta de contratos o un CRM a un modelo frontera, prepara una ficha corta: finalidad, tipos de dato, personas con acceso, proveedor, región, subencargados, retención, transferencia internacional, revisión humana y base contractual. Con esa ficha, legal y seguridad pueden detectar pronto los casos que requieren más análisis.
Para empresas de Donostia, Gipuzkoa y Euskadi, esta revisión evita dos errores caros: bloquear un caso útil por miedo genérico o desplegarlo rápido con una confianza que el contrato y la arquitectura no sostienen. La decisión correcta depende de cada flujo y debe revisarse con el responsable de privacidad o asesoría jurídica cuando haya datos personales, secretos comerciales o un NDA de por medio.
Fuentes consultadas
- RGPD, Reglamento (UE) 2016/679, EUR-Lex, en particular artículos 28 y 44.
- Recomendaciones 01/2020 del Comité Europeo de Protección de Datos.
- Data, privacy and security for Models sold by Azure in Microsoft Foundry, Microsoft Learn.
- Data retention, Google Cloud Documentation.
La documentación de proveedores y los contratos cambian. Antes de tratar datos personales o información sometida a confidencialidad, verifica las condiciones vigentes con vuestro equipo legal y de protección de datos.