Una empresa decide desplegar un LLM sobre sus documentos internos. El departamento de TI configura la clave API, un desarrollador escribe el wrapper, y la gente empieza a introducir en el modelo ofertas, contratos y actas de reuniones. La primera semana todo parece fantástico. Entonces llega el DPO y hace una sola pregunta: «¿Adónde van a parar esos datos?» Y nadie sabe responder.
Este escenario no es la excepción — es la norma en muchas empresas europeas. El GDPR en los despliegues de LLM no es un problema académico. Es un checklist concreto que o tienes o no tienes. Este artículo lo desglosa de forma práctica: dónde fluyen los datos exactamente, qué debes tener firmado, cuándo procede una DPIA, y cómo el responsable de la decisión puede apoyarse en un marco estructurado en lugar de en la intuición.
Dónde fluyen los datos — mapa de flujos
Antes de resolver cualquier cuestión legal, debes saber qué ocurre a nivel técnico. Un LLM en producción no es un sistema único — es una cadena de componentes, y cada eslabón es un punto potencial de fuga.
El flujo típico con un LLM en la nube es el siguiente:
- Documento de entrada (contrato, email, informe) → chunking → embedding → base de datos vectorial
- Consulta del usuario → recuperación desde la base vectorial → contexto + consulta se envían a la API del LLM
- API del LLM (p. ej. OpenAI, Anthropic, Google) → procesa el prompt → devuelve la respuesta
- Logs y trazas → observabilidad (Langfuse, LangSmith, logging propio) → posible almacenamiento adicional
Cada uno de estos pasos puede contener datos personales (Personal Identifiable Information — PII): el nombre de un cliente en un contrato, el email de la persona de contacto, información médica en un informe, un IBAN en un justificante de pago. Si esos datos salen de tu perímetro — y con una API en la nube salen — eres responsable del tratamiento de datos personales con obligaciones concretas.
Otro flujo que suele olvidarse: el entrenamiento y el fine-tuning. Algunos proveedores cloud especifican explícitamente que los datos enviados a través de la API no se utilizan para entrenamiento (OpenAI en el tier enterprise, Anthropic a través de la API). Pero los ajustes por defecto varían — y lo que es válido hoy puede cambiar con una actualización de las condiciones. Verifica siempre los Terms of Service actuales y refléjalo contractualmente.
API cloud vs. on-prem — una decisión con impacto en el GDPR
Esta es la elección arquitectónica más importante desde el punto de vista del compliance.
API cloud (OpenAI, Anthropic, Gemini, Azure OpenAI…)
Las ventajas son evidentes: los modelos más potentes, infraestructura cero, arranque rápido. Problemas con el GDPR:
- Los datos salen de tu perímetro — estás obligado a tener un Data Processing Agreement (DPA) con el proveedor en calidad de encargado del tratamiento
- Al transferir datos fuera del EEE (p. ej. datos en servidores de EE. UU.) necesitas un mecanismo de transferencia — cláusulas contractuales tipo (SCC) o una base jurídica equivalente
- Debes saber dónde están físicamente los servidores; la respuesta «en la nube» no le basta al DPO ni a la autoridad de control
La mayoría de los grandes proveedores ofrecen DPA — pero debes suscribirlo activamente, no limitarte a marcar una casilla. Azure OpenAI dispone de regiones europeas, lo que simplifica las transferencias fuera del EEE. Consulta las condiciones vigentes directamente con cada proveedor.
LLM on-prem / self-hosted
Los datos no salen de tu perímetro. Si el modelo corre en tus servidores (o en servidores dentro del EEE con un contrato claro), la exposición al GDPR es considerablemente menor. Esta opción tiene especial sentido en sectores regulados — sanidad, derecho, finanzas — donde se tratan datos personales sensibles. Puedes encontrar un análisis más detallado en LLM on-premise para sectores regulados.
El trade-off está en la calidad y el coste: los modelos open-weight self-hosted (Llama, Qwen, Mistral, DeepSeek en sus variantes open-weight) alcanzan hoy calidad de producción para la mayoría de casos de uso empresariales, pero requieren infraestructura GPU y capacidad de ingeniería para su gestión. Para hacer inferencia de un modelo de 7B–14B con una latencia razonable basta aproximadamente con un servidor con GPU y VRAM suficiente; los modelos más grandes exigen más recursos.
DPA — qué debe contener y por qué no basta con un clic
El Data Processing Agreement es un requisito legal conforme al artículo 28 del GDPR cuando cedes datos personales a un tercero para su tratamiento. El proveedor de LLM al que envías documentos con datos personales es el encargado del tratamiento. Tú eres el responsable. Sin DPA estás incumpliendo la ley.
Qué debe contener un DPA (según el art. 28.3 del GDPR):
- Objeto y duración del tratamiento — concretos, no vagos
- Naturaleza y finalidad del tratamiento — «inferencia para un chatbot interno» es más concreto que «servicios de IA»
- Tipo de datos personales y categorías de interesados — ¿clientes? ¿empleados? ¿pacientes?
- Obligaciones y derechos del responsable — incluido el derecho de auditoría
- Medidas técnicas y organizativas (TOO) — cifrado, control de acceso, respuesta a incidentes
- Prohibición de subencargados sin consentimiento o autorización general con mecanismo legal
Atención a un detalle que las empresas suelen subestimar: el DPA debe cubrir también los subencargados del proveedor — la infraestructura cloud, el servicio de logging, las herramientas de monitorización. Los proveedores de mayor tamaño publican listas de subencargados; revísalas.
Base jurídica — en qué fundamento tratas los datos
El GDPR exige que todo tratamiento de datos personales tenga una base jurídica (art. 6). En los despliegues empresariales de LLM las más habituales son:
- Interés legítimo (art. 6.1.f) — la base más frecuente para herramientas corporativas internas; requiere una LIA (Legitimate Interest Assessment) en la que documentes que el interés de la empresa prevalece sobre los derechos de los interesados
- Ejecución de un contrato (art. 6.1.b) — relevante cuando el LLM sirve directamente al cumplimiento del contrato con el cliente
- Consentimiento (art. 6.1.a) — poco práctico para la mayoría de herramientas internas; el consentimiento debe ser libre, informado y revocable
Si tratas categorías especiales de datos (datos de salud, genéticos, biométricos, políticos, religiosos, sindicales, orientación sexual) — art. 9 del GDPR — la base jurídica es más exigente y el consentimiento es prácticamente imprescindible, o bien debes acreditar otra base del listado taxativo del art. 9.2.
En la práctica: si tu LLM trabaja sobre documentación de RR. HH., historiales médicos o escritos judiciales, no podrás avanzar sin un abogado. De lo contrario, no solo arriesgas una sanción, sino que podrías verse obligado a detener y desmantelar todo el proyecto.
PII scrubbing — cuándo y cómo
El PII scrubbing (depuración de datos personales antes de enviarlos al LLM) es una medida técnica que reduce la exposición. No sustituye a una base jurídica adecuada ni a un DPA, pero estrecha significativamente la superficie de riesgo.
Cuándo tiene sentido:
- Documentos en los que el LLM no necesita conocer el nombre concreto — necesita comprender el contexto, la estructura, el contenido
- Registros de logs — la PII nunca debe estar en los logs; es una exigencia legal y también higiene técnica
- Datasets de entrenamiento — si realizas fine-tuning del modelo sobre datos internos, la PII en los datos de entrenamiento puede ser «memorizada» por el modelo (problema de memorization) y liberada posteriormente
Cómo funciona técnicamente:
- Detectores basados en regex — emails, números de teléfono, IBAN, DNI/NIE, direcciones IP; rápidos, deterministas, baja tasa de falsos negativos para formatos estructurados
- Detectores basados en NER (Named Entity Recognition) — nombres de personas, empresas, direcciones; capturan textos no estructurados; requieren modelo, mayor tasa de error
- Combinación — regex para formatos estructurados + NER para texto libre; estándar de producción
Advertencia importante: la seudonimización no es anonimización conforme al GDPR. Si sustituyes un dato por un token pero existe una clave para reconstruirlo, sigue siendo un dato personal. El EDPB (Comité Europeo de Protección de Datos) ha confirmado reiteradamente que los LLM rara vez alcanzan el estándar de anonimización real. El scrubbing reduce el riesgo — no lo elimina.
Para inspirarte en la implementación del pipeline de depuración, puedes ver cómo se resuelve esta capa en guardrails para agentes de IA, donde la validación de entrada y la detección de PII son la primera capa de defensa antes del LLM.
Data minimization — nada de más
La data minimization es uno de los principios clave del GDPR (art. 5.1.c): trata únicamente los datos personales que sean necesarios para la finalidad perseguida.
En el contexto de un LLM, esto significa en la práctica:
- Al prompt solo llegan los chunks relevantes, no los documentos completos — un pipeline RAG correctamente configurado para una recuperación precisa es, al mismo tiempo, una herramienta de compliance
- Política de retención para logs y trazas — ¿cuánto tiempo conservas el historial de conversaciones? ¿30 días? ¿90 días? Sin una política definida, dura «para siempre»
- Vectores de embedding — incluso la representación vectorial de un documento puede ser un dato personal si permite reconstruir el original o identificar a una persona; trátala igual que los datos fuente
- Logs del sistema de inferencia — si registras el prompt completo incluida la consulta del usuario, estás registrando potencialmente datos personales; implanta logging selectivo o log scrubbing
DPIA — cuándo es obligatoria y qué debe contener
La Data Protection Impact Assessment (DPIA) es obligatoria cuando el tratamiento «pudiera entrañar un alto riesgo para los derechos y libertades de las personas físicas» (art. 35 del GDPR). En los despliegues de LLM esto suele significar:
- Tratamiento sistemático y a gran escala de categorías especiales de datos (datos de salud, financieros, de RR. HH.)
- Toma de decisiones automatizada con efectos jurídicos o análogos sobre las personas
- Monitorización a gran escala de espacios de acceso público
En la práctica: si tu LLM contribuye a tomar decisiones sobre empleados, clientes o pacientes, la DPIA es procedente. Si se trata de un chatbot interno sobre documentación técnica sin categorías especiales de datos, probablemente no sea obligatoria — pero recomendamos realizar al menos una evaluación interna de riesgos.
Qué debe contener una DPIA:
- Descripción de la operación de tratamiento — qué, por qué, quién, dónde
- Evaluación de la necesidad y proporcionalidad — ¿puede alcanzarse el objetivo con menor intromisión en la privacidad?
- Evaluación de riesgos para los derechos y libertades de los interesados
- Medidas para gestionar los riesgos — técnicas y organizativas
- Si el riesgo residual sigue siendo alto → consulta con la autoridad de control (p. ej. la AEPD en España o la autoridad competente en cada Estado miembro)
EU AI Act y GDPR — dos capas de compliance
Desde agosto de 2025 están en vigor las obligaciones para los modelos GPAI (General Purpose AI) en el marco del EU AI Act. Para las empresas que despliegan sistemas de IA (deployers) se aplican las obligaciones del artículo 26 — especialmente en los sistemas de IA de alto riesgo.
Punto importante: el EU AI Act y el GDPR no se duplican, sino que se complementan. El GDPR regula la protección de datos personales. El EU AI Act regula los riesgos de los sistemas de IA — incluidas las situaciones en las que la IA toma o influye en decisiones sobre personas. Si tu sistema LLM contribuye a tomar decisiones sobre RR. HH., créditos, acceso a servicios o clasificaciones de seguridad, puede ser clasificado como IA de alto riesgo — y entonces tendrás obligaciones derivadas de ambos reglamentos simultáneamente.
Puedes encontrar un análisis más detallado de las obligaciones concretas para las empresas en el artículo sobre el EU AI Act y las obligaciones de las empresas.
Checklist práctico de compliance
Resumen en forma de lista de verificación antes de desplegar un LLM sobre datos empresariales:
- DPA con cada proveedor de LLM — firmado, no solo marcado; cubre también a los subencargados
- Base jurídica documentada — LIA para interés legítimo, consentimiento si procede; guardado, no en la memoria de nadie
- Transferencia de datos fuera del EEE resuelta — SCC o equivalente si el proveedor opera en servidores de EE. UU.
- PII scrubbing — implantado al menos para los logs; para los documentos donde sea técnicamente posible
- Política de data minimization — períodos de retención para logs, conversaciones y embeddings definidos y aplicados
- DPIA — realizada para los casos de uso de alto riesgo; resultados documentados
- Medidas técnicas y organizativas — cifrado en tránsito y en reposo, control de acceso, plan de respuesta a incidentes
- Registro de actividades de tratamiento (art. 30 del GDPR) — el sistema LLM debe estar incluido en el Records of Processing Activities
- Evaluación EU AI Act — ¿es tu sistema de alto riesgo? Si es así, obligaciones conforme al art. 26
Preguntas frecuentes
¿Es necesario un abogado o podemos gestionarlo internamente?
Depende del alcance. Para un chatbot interno sencillo sobre documentación técnica pública sin datos personales, basta con una evaluación interna junto al DPO. Cuando se tratan categorías especiales de datos, se gestiona una transferencia fuera del EEE o el sistema influye en decisiones sobre personas, un abogado externo especializado en privacidad de datos e IA resulta rentable — las sanciones por infracción del GDPR pueden alcanzar el 4 % del volumen de negocio global o 20 millones de euros.
¿Puedo utilizar datos anonimizados y evitar el GDPR?
Si has alcanzado una anonimización real — es decir, los datos no pueden atribuirse a una persona física ni siquiera indirectamente — el GDPR no se aplica. En la práctica resulta difícil. Los LLM rara vez alcanzan el estándar de anonimización real; la seudonimización (sustitución por un token que puede reconstruirse) no es suficiente. Consulta con tu DPO si tu método cumple verdaderamente el estándar de anonimización.
¿Debemos realizar una DPIA para cada proyecto de LLM?
No para todos. La DPIA es obligatoria cuando existe un alto riesgo para los derechos de las personas — típicamente con categorías especiales de datos, toma de decisiones automatizada con impacto en personas, o monitorización a gran escala. Para un helpdesk interno sobre manuales técnicos sin datos personales, la DPIA no es obligatoria. Recomendamos realizar al menos una breve evaluación interna de riesgos y documentar la decisión.
¿Qué sucede si el proveedor de LLM cambia sus condiciones y empieza a entrenar con nuestros datos?
Es un riesgo real. Por eso el DPA debe incluir la prohibición de usar tus datos para entrenamiento y el derecho de auditoría. Monitoriza los cambios en los Terms of Service y establece un proceso de revisión al menos una vez al año. Si el proveedor modifica las condiciones en contra del DPA, tienes derecho a rescindir el contrato y solicitar la supresión de los datos.
¿Un LLM on-prem es automáticamente conforme al GDPR?
No de forma automática. El on-prem elimina el riesgo de transferencia de datos a un tercer encargado, pero igualmente debes tener definida una base jurídica, una política de data minimization, períodos de retención y medidas técnicas. La diferencia es que los problemas los gestionas internamente — no a través de un DPA con un proveedor externo.
*El GDPR y el LLM sobre datos empresariales no es un proyecto para un fin de semana, pero tampoco puede ser el motivo para bloquear el arranque. La mayoría de las empresas con las que trabajamos necesitan ante todo una visión estructurada de qué tienen cubierto y qué no — no decenas de horas de consultoría legal. Si quieres revisar este checklist sobre un despliegue concreto en tu empresa, estamos disponibles para una consulta inicial.*