Residencia de datos en la UE para LLM: dónde se procesan tus datos

La residencia de datos en la UE para LLM significa que los prompts, las respuestas generadas, los embeddings y los logs se almacenan y procesan exclusivamente en una región de la UE. Es relevante para la protección de datos porque cualquier tratamiento fuera del EEE constituye una transferencia a un tercer país según el capítulo V del RGPD y, por tanto, requiere una base para la transferencia, como una decisión de adecuación o cláusulas contractuales tipo.

• Residencia de datos = lugar de tratamiento. Si el flujo de datos sale del EEE, se aplica el capítulo V del RGPD: hace falta una decisión de adecuación o un instrumento de transferencia del art. 46, como las cláusulas contractuales tipo (CCT), y en este último caso, además, una evaluación de impacto de la transferencia (TIA).
• El alojamiento en la UE es posible con la mayoría de los grandes proveedores, pero con condiciones y, en parte, solo dando un rodeo. Azure OpenAI a través del EU Data Boundary, Claude solo a través de AWS Bedrock EU o Vertex EU, Vertex mediante endpoints regionales de la UE y Mistral como proveedor de la UE.
• Una región de la UE por sí sola no resuelve el problema. Los proveedores estadounidenses siguen sujetos a la CLOUD Act de EE. UU. aunque usen una región de la UE; los proveedores soberanos de la región DACH (Alemania, Austria y Suiza) evitan por completo la cuestión del tercer país.

Qué es la residencia de datos y por qué importa para el RGPD

La residencia de datos describe el lugar geográfico en el que se almacenan y procesan los datos personales. En un sistema basado en LLM, ese lugar no se limita a la inferencia. Según el art. 4, puntos 1 y 2, del RGPD, cualquier operación con datos personales es un tratamiento. En un stack de agentes, esto afecta como mínimo a:

• Entradas de inferencia: prompts, prompts de sistema, archivos adjuntos, muestras de voz.
• Salidas de inferencia: textos y resúmenes que nombran o describen a personas (incluidos datos personales alucinados).
• Memoria del agente: ventana de contexto, memoria episódica y semántica, bases de datos vectoriales persistentes.
• Embeddings y bases de datos vectoriales: tanto el texto indexado como los propios vectores se consideran datos personales seudonimizados, ya que los ataques de inversión y de inferencia de pertenencia permiten la reidentificación.
• Logs y trazas: logs de prompts, logs de completions, spans de observabilidad.

El punto clave: cada uno de estos elementos puede estar en un lugar distinto. Una inferencia residente en la UE sirve de poco si la base de datos vectorial, el backend de observabilidad o un servidor MCP situado más adelante en la cadena enrutan los datos hacia un tercer país.

La transferencia a terceros países como desencadenante

En cuanto los datos personales salen del EEE, se trata de una transferencia a un tercer país según el capítulo V del RGPD. La referencia clave es la sentencia del TJUE Schrems II (C-311/18, 16 de julio de 2020): declaró inválido el Privacy Shield y dejó claro que las cláusulas contractuales tipo (CCT) solo siguen siendo válidas si van acompañadas de una evaluación de impacto de la transferencia caso por caso, incluidas medidas complementarias cuando sea necesario. La Comisión lo llevó a la práctica con las CCT 2021/914 (4 de junio de 2021), estructuradas en cuatro módulos.

Por eso, la residencia de datos en la UE es el medio más eficaz para que esta problemática de las transferencias ni siquiera llegue a surgir: si todas las capas de tratamiento permanecen en el EEE, la transferencia a terceros países deja de ser un punto de control.

Estado del EU-US Data Privacy Framework (situación en 2026, sujeta a cambios)

Cuando una transferencia a EE. UU. es inevitable, el EU-US Data Privacy Framework (DPF) es el instrumento central. La Comisión adoptó la decisión de adecuación el 10 de julio de 2023 (como sucesora del Privacy Shield). El 3 de septiembre de 2025, el Tribunal General de la UE (TGUE) desestimó en Latombe v Commission (T-553/23) el primer recurso y confirmó la validez del DPF en el momento de su adopción.

Cuestiones abiertas (investigación actualizada a octubre de 2026, sujeta a cambios):

• Latombe interpuso recurso de casación ante el TJUE el 31 de octubre de 2025; el procedimiento está pendiente.
• NOYB/Max Schrems ha anunciado una demanda propia y más amplia. El motivo es la sentencia del Tribunal Supremo de EE. UU. en Trump v. Slaughter, según la cual el presidente de EE. UU. puede destituir a miembros de la FTC sin alegar motivos (beck-aktuell). La FTC es uno de los organismos de supervisión en los que se apoya el DPF. Por eso, a finales de junio de 2026, NOYB instó a la Comisión a retirar de forma ordenada la decisión de adecuación. Ya antes, NOYB había puesto en duda la independencia del Privacy and Civil Liberties Oversight Board (PCLOB) a raíz de órdenes ejecutivas estadounidenses. Así, un escenario «Schrems III» sigue siendo plausible.
• El Tribunal General de la UE dejó constancia expresa de que la Comisión debe supervisar de forma continua el marco jurídico y puede suspender, modificar o derogar la decisión si cambian las condiciones.

Consecuencia operativa: actualmente, una certificación DPF es una base válida para la transferencia. Una transferencia basada en una decisión de adecuación no necesita ninguna autorización específica (art. 45, apartado 1, del RGPD) ni otras garantías (art. 46, apartado 1, del RGPD). Aun así, las empresas deberían tener preparadas las CCT como alternativa de respaldo. Para destinatarios certificados en el DPF no se exige una TIA, pero merece la pena como preparación por si el DPF cae y hay que pasar la transferencia a las CCT. Para Suiza rige el Swiss-US DPF (en vigor desde el 15 de septiembre de 2024). La propia Suiza se considera un país con nivel de protección adecuado desde 2000 (Decisión 2000/518/CE de la Comisión); la Comisión lo confirmó el 15 de enero de 2024 en su revisión de las once decisiones de adecuación más antiguas.

Por qué una región de la UE no elimina el riesgo de la CLOUD Act

Una región de la UE aborda el lugar de almacenamiento, no la jurisdicción a la que está sometido el proveedor. Por eso, en la TIA de los proveedores de IA persisten estos riesgos:

• CLOUD Act de EE. UU.: riesgo de acceso para proveedores estadounidenses y sus filiales en el EEE, con independencia de dónde se encuentren físicamente los datos.
• FISA 702 / EO 12333: exposición de los proveedores de servicios de comunicaciones electrónicas (por ejemplo, Microsoft, Google, AWS).
• Contramedidas: cifrado en reposo y en tránsito como estándar mínimo; cada vez más, cifrado en uso (confidential computing, TEE); BYOK/HYOK, de modo que el proveedor no pueda descifrar sin la intervención del responsable del tratamiento.

Justo aquí está la ventaja de los proveedores soberanos de la región DACH: no están sujetos a la jurisdicción estadounidense y procesan exclusivamente en Alemania/UE o en Suiza.

Opciones de alojamiento en la UE de los grandes proveedores

La siguiente tabla resume las opciones de residencia de datos. Es un resumen de investigación, no asesoramiento jurídico; las condiciones de los proveedores cambian con frecuencia y conviene revisarlas de nuevo al firmar el contrato.

Cómo leer la tabla

Destacan tres patrones. Primero: los hiperescaladores ofrecen regiones de la UE, pero las vinculan a la configuración (region pinning) y, en parte, a recargos, como los endpoints regionales de Vertex. Segundo: Anthropic Claude solo puede tener residencia en la UE de forma indirecta, es decir, a través de AWS Bedrock EU o Vertex EU, no a través de la API directa. Según la documentación de Anthropic (octubre de 2026), la API directa solo conoce las regiones de inferencia «us» y «global». Tercero: los proveedores soberanos de la región DACH (IONOS, STACKIT, Open Telekom Cloud, Aleph Alpha, Swisscom) son la única opción con tratamiento exclusivo en Alemania/UE o Suiza y sin riesgo de jurisdicción estadounidense.

Ejemplo de cálculo: residencia de datos en el stack de subencargados

Un stack típico de despliegue agéntico abarca de cinco a ocho capas de subencargados: proveedor del modelo fundacional, hosting/nube, orquestación, base de datos vectorial, proveedor de memoria, servidor MCP, observabilidad y evaluación.

Tomemos una configuración concreta: una empresa austriaca opera un agente de atención al cliente con Claude a través de AWS Bedrock en una región de la UE (capas 1 + 2, residentes en la UE). La base de datos vectorial está en la UE (capa 4, residente en la UE). Pero la herramienta de observabilidad (capa 7) envía trazas de prompts a un backend en EE. UU., y un servidor MCP conectado (capa 6) de un proveedor estadounidense procesa globalmente los payloads de las llamadas a herramientas.

El cálculo: de 8 capas, 6 son residentes en la UE y 2 enrutan hacia un tercer país. Eso no basta para tener residencia de datos en la UE. Basta una sola capa en un tercer país para que todo el flujo de datos se convierta en una operación sujeta a las normas de transferencia del capítulo V, con base para la transferencia (DPF o CCT con TIA) y riesgo residual derivado de la CLOUD Act. Los hallazgos de auditoría más frecuentes afectan precisamente a estas capas invisibles: flujos de servidores MCP no declarados y proveedores de observabilidad sin contrato de encargo del tratamiento.

Para dimensionar las multas con datos concretos: Clearview AI fue sancionada por tratamiento ilícito de datos en Italia con 20 millones de euros (10 de febrero de 2022) y en Francia con 20 millones de euros (17 de octubre de 2022); el Garante italiano impuso a OpenAI una multa de 15 millones de euros (resolución del 2 de noviembre de 2024). La disciplina en los flujos de datos no es, por tanto, un ejercicio teórico.

Consecuencias prácticas para elegir proveedor

• Fijar el region pinning por contrato. El enrutamiento global por defecto y el failover del proveedor a regiones fuera de la UE son hallazgos de auditoría frecuentes. La residencia debe quedar establecida en el contrato de encargo del tratamiento, no solo ser configurable.
• Revisar todas las capas, no solo la inferencia. Comprobar por separado la residencia y el contrato de encargo de la base de datos vectorial, la memoria, los servidores MCP y la observabilidad; garantizar una cadena ininterrumpida conforme al art. 28, apartado 4.
• Con proveedores estadounidenses, doble protección. Verificar la certificación DPF, tener las CCT como alternativa de respaldo y documentar la TIA.
• Valorar opciones soberanas en sectores sensibles. En ámbitos muy regulados (por ejemplo, los servicios financieros sujetos al secreto bancario del art. 47 de la Ley de Bancos suiza, BankG), las soluciones de nube soberana y on-premise pasan en la práctica a primer plano.

Para agencias y decisores B2B

La residencia de datos no es un simple detalle de TI, sino una cuestión contractual y de arquitectura que debe entrar pronto en la selección de proveedores. Para las agencias que desarrollan agentes de IA para clientes en Europa, una arquitectura conforme a la residencia es un rasgo de calidad que se puede vender: un flujo de datos documentado en la UE a través de todas las capas de subencargados reduce de forma medible el riesgo de terceros países de tus clientes. Para los decisores B2B, la regla es esta: exige al proveedor un mapa completo de subencargados con la ubicación y la función de cada capa antes de pasar a producción. Blck Alpaca ayuda a evaluar las opciones de residencia en la UE, a documentar la TIA y a montar stacks de agentes conformes a la residencia.

Nota: este artículo tiene carácter meramente informativo y no constituye asesoramiento jurídico. Para valorar de forma vinculante tu caso concreto, consulta a una abogada o un abogado, o a tu delegada o delegado de protección de datos.