El routing LLM y el RGPD: lo que las gateways estadounidenses no te cuentan
Residencia de datos, subprocesadores, Schrems II y el EU AI Act, un briefing preciso

Este post no es una alarma. Es un briefing. Si eres una empresa europea que usa una gateway LLM, o que envía features de IA al mercado europeo, hay preguntas de compliance precisas que deberías poder responder, y varias no tienen una respuesta limpia cuando tu gateway es US-based.

No soy abogado. Nada de esto es asesoramiento jurídico. Pero he hecho suficientes ciclos de compra con enterprises europeas para saber qué preguntas se hacen, qué respuestas pasan, y qué respuestas matan deals. Déjame ponerlas sobre la mesa.

Los cuatro ángulos que importan

Cuando un equipo de compliance europeo revisa una integración LLM, normalmente mira cuatro cosas:

1. Residencia de datos, dónde se procesan y almacenan físicamente los prompts y completions.
2. Subprocesadores, la cadena de terceros que toca el dato, y bajo qué jurisdicción opera cada uno.
3. Data Processing Agreement (DPA), el documento contractual que gobierna cómo se tratan los datos personales.
4. Implicaciones EU AI Act, según la clasificación del use case, obligaciones adicionales sobre transparencia, gestión de riesgos, control humano.

Cada uno tiene respuesta. Cada uno también es distinto según si tu gateway es US-based o UE-based.

La residencia de datos en la práctica

La pregunta básica: cuando un usuario en París envía un prompt con datos personales vía tu feature de IA, ¿dónde se procesa ese prompt?

• Directo a Anthropic/OpenAI: procesado en la región del proveedor, normalmente US salvo si has configurado una región UE (Anthropic ofrece tratamiento regional UE para algunos modelos; OpenAI tiene opciones zonales europeas en Azure).
• Vía una gateway US-hosted (OpenRouter, Vercel, Portkey, Helicone, Cloudflare AI Gateway en config por defecto): procesado al menos una vez sobre infra US antes de atacar al proveedor de modelo.
• Vía una gateway UE-hosted (HiWay sobre OVH, o un LiteLLM self-hosted en región UE): procesado sobre infra UE, luego forwardeado hacia la región del proveedor que hayas configurado.

El paso por la gateway cuenta porque es un evento de tratamiento distinto. Aunque tu proveedor de modelo subyacente tenga una región UE, pasar primero por una gateway US-hosted añade un eslabón de tratamiento US a la cadena.

Para la mayoría de productos B2C con datos no sensibles, esto no es problema. Para productos B2B que venden a sectores regulados (salud, finanzas, gobierno, legal, educación) lo es con frecuencia.

Subprocesadores: la cadena por la que firmas de verdad

Cuando firmas con una gateway, normalmente aceptas su lista de subprocesadores. Esta es la cadena de vendors adicionales que pueden tocar el dato, CDN, infra de logs, monitoring, auth, cloud provider.

Para una gateway US-hosted típica, la cadena de subprocesadores puede incluir:

• AWS o GCP (cloud US, con regiones UE disponibles)
• Un vendor de observability US (Datadog, New Relic, etc.)
• Un proveedor de email US
• Un proveedor de auth US
• Un CDN US (Cloudflare es un caso mixto)

Cada uno es un flujo de datos separado por el que firmas. Tus propios clientes o equipo de compliance esperan que los listes, o al menos que respondas por la lista de la gateway.

Para una gateway UE-hosted sobre OVH (nuestro caso), la cadena de subprocesadores es más corta y más europea:

• OVH (cloud francés)
• Stripe (procesamiento de pagos, inevitable para pagos con tarjeta, pero minimizado a lo estrictamente necesario)
• Un set limitado de servicios de soporte UE

Las cadenas más cortas son más fáciles de documentar y más fáciles de pasar en review de compliance.

La cuestión del DPA

El RGPD requiere un DPA entre tú (el controlador) y todo procesador que trate datos personales. Cuando firmas con una gateway, firmas un DPA con ellos.

Tres cosas que verificar en cualquier DPA de gateway:

1. ¿Se compromete con una región de tratamiento precisa? Si el DPA es silencioso sobre la región o dice "podemos tratar globalmente", tu equipo de compliance lo flagueará. Quieres un compromiso, "el tratamiento tiene lugar en la región X", o al menos una opción configurable que produzca un compromiso firmado.

2. ¿Cuál es el plazo de notificación de breach? El RGPD requiere notificación a las autoridades en las 72h tras conocerse el breach. El compromiso de tu gateway en el DPA debe ser lo bastante rápido para que puedas cumplir tu propia ventana de 72h después de que ellos te avisen.

3. ¿Cuál es la notificación de cambio de subprocesador? El DPA debe comprometerse a notificarte por adelantado cuando añaden nuevos subprocesadores, para que tu equipo de compliance pueda evaluar la cadena. Un lenguaje vago como "notificaremos cuando sea razonablemente posible" es un problema.

La mayoría de gateways US tienen DPA. La calidad varía. La precisión sobre la región de tratamiento suele ser el punto más débil.

Schrems II, brevemente

Schrems II es una decisión del TJUE de 2020 que invalidó el anterior marco de transferencia de datos UE-US. El follow-up, el EU-US Data Privacy Framework, adoptado en 2023, está actualmente en vigor pero bajo impugnación judicial.

Lo que esto significa en la práctica: las transferencias de datos personales de la UE a US dependen de mecanismos jurídicos (el DPF, o las Standard Contractual Clauses con medidas suplementarias) que han sido impugnados en tribunales antes y pueden serlo de nuevo. Usar una gateway US-based significa que dependes de estos mecanismos, que son jurídicamente válidos hoy pero no a prueba de bombas.

Para muchas empresas es un riesgo aceptable. Para otras, compradores públicos, salud, finanzas reguladas, servicios jurídicos, es lo bastante preocupante para preferir las alternativas UE-based cuando es posible. El EU AI Act ha amplificado esta preferencia.

La capa EU AI Act

El EU AI Act entró en vigor en 2024, con obligaciones que se escalonan a lo largo de 2026-2027. La parte relevante para los usuarios de gateway LLM:

• Prácticas prohibidas (p. ej. ciertas manipulaciones, categorización biométrica masiva) están directamente prohibidas.
• Sistemas de alto riesgo (scoring de crédito, hiring, evaluación educativa, uso de fuerzas del orden, y otros) tienen obligaciones obligatorias: gestión de riesgos, gobernanza de datos, control humano, transparencia, logging.
• Modelos de IA de uso general (los grandes modelos de fundación) tienen obligaciones de transparencia y documentación del lado proveedor.
• Obligaciones de transparencia se aplican ampliamente: los usuarios deben saber cuándo interactúan con un sistema de IA.

La capa gateway no está directamente regulada, pero tu uso de una gateway forma parte de tu cuadro de compliance. Si operas un sistema de alto riesgo, necesitarás documentación que muestre cómo circulan los datos, dónde se procesan, y quién tiene acceso. Esa documentación es significativamente más fácil de producir si tu cadena de tratamiento es corta y UE-based.

Para use cases de alto riesgo, la combinación infra UE-hosted + DPA explícito + cadena de subprocesadores corta + sin prompt logging por defecto se acerca a una respuesta checklist para la mitad del documento de compliance.

La checklist de compliance

Para evaluar cualquier gateway LLM en el ángulo compliance, esta es la checklist que usaría:

Residencia de datos

• ¿La región de tratamiento primaria de la gateway está documentada por escrito?
• ¿Puedes comprometerte a una región de tratamiento UE-only si hace falta?
• ¿El DPA refleja el compromiso regional?
• ¿Los backups se procesan en la misma región?

Subprocesadores

• ¿La lista de subprocesadores es pública?
• ¿La jurisdicción de cada subprocesador está documentada?
• ¿Hay mecanismo de notificación para los cambios?
• ¿Puedes vetar subprocesadores precisos si son inaceptables para tus clientes?

Tratamiento de prompts

• ¿El prompt logging está activado o desactivado por defecto?
• Si el logging está activado, ¿cuál es la retención?
• ¿El prompt logging puede desactivarse por clave API?
• ¿Los logs son accesibles solo dentro de la región comprometida?

Calidad del DPA

• ¿El DPA especifica una región de tratamiento?
• ¿La notificación de breach es ≤ 72h?
• ¿Requiere notificación de cambio de subprocesador?
• ¿Los plazos de tratamiento de las solicitudes data subject están especificados?

Alineamiento EU AI Act

• ¿La gateway publica una lista de modelos de fundación soportados con sus proveedores?
• ¿Hay documentación adaptada para compliance de sistemas de alto riesgo?
• ¿Hay una declaración de transparencia hacia la que puedas linkear?

Presencia business

• ¿La gateway está operada por una entidad legal UE (o US con filial UE propia)?
• ¿Dónde están basadas las personas que responden a las solicitudes data subject?
• ¿Hay un representante UE (Artículo 27 RGPD) si la entidad es no-UE?

Si no puedes responder a la mayoría para tu gateway actual, eso ya es info útil.

Cómo se ven las respuestas honestas

Por transparencia, así responde HiWay a cada bucket:

Residencia de datos. Todo el tratamiento sobre infra francesa OVH. Configurable a UE-only cuando se requiere contractualmente. Los backups se quedan en región.

Subprocesadores. Lista corta, publicada. Principalmente UE-based con excepciones limitadas (Stripe para los pagos). Notificación por adelantado para los cambios.

Tratamiento de prompts. Cero prompt logging por defecto. Logging debug opcional por clave API con retención acotada. Los logs se quedan en región.

DPA. Especifica la región francesa OVH. Notificación de breach 72h. Compromiso de notificación de cambio de subprocesador. Incluido en los tiers de pago.

EU AI Act. Catálogo de modelos publicado con atribución de proveedor. Plantilla de documentación para clientes que construyen sistemas de alto riesgo. Página de transparencia.

Presencia business. Operada por Mytm-Group, SARL francesa. Las personas que responden a las solicitudes data subject están basadas en Francia.

Esto no es para decir que HiWay es la única opción que hace esto bien. Un LiteLLM self-hosted en región UE bajo tu propia entidad puede producir respuestas equivalentes. El punto es que las gateways US-hosted no pueden estructuralmente, ni siquiera cuando los elementos individuales son configurables.

Lo que las gateways US-hosted te dicen a veces

Por ser justos: algunas gateways US han hecho inversiones reales en compliance. Portkey tiene tiers enterprise con opciones regionales. Helicone tiene una opción OSS self-host que te deja desplegar en tu propia región UE. Cloudflare AI Gateway se beneficia de la sofisticación regulatoria global de Cloudflare.

Lo que normalmente no pueden ofrecer es "somos una entidad UE bajo ley UE con personal UE-based en primera línea de respuesta". Esa es una diferencia estructural entre gateways US y UE, y para algunas conversaciones de compliance, es el factor decisivo.

Qué hacer si ya estás en una gateway US

Si lees esto y te das cuenta de que tu stack actual es US-hosted de cabo a rabo, sin pánico. Los pasos:

1. Documenta lo que tienes. Escribe tu flujo de datos actual, los subprocesadores y los compromisos del DPA. No puedes arreglar lo que no has mapeado.
2. Habla con tu equipo de compliance. Pregunta cuáles son sus exigencias duras frente a preferencias. La respuesta sorprende a menudo en las dos direcciones.
3. Evalúa el riesgo para tu use case preciso. Una app B2C de gran público sirviendo datos no sensibles tiene un perfil de riesgo distinto de un B2B de salud.
4. Si la migración está justificada, empieza por los flujos de datos de mayor riesgo. No tienes que mover todo de golpe. Mueve los workloads regulados primero.
5. Actualiza tu doc pública. Si dices "RGPD-compliant" en tu sitio marketing, tu arquitectura real debe sostenerlo.

La migración de una gateway US a una UE, asumiendo que ambas son compatibles OpenAI, es un cambio de base_url. Mira nuestro post de migración.

El takeaway honesto

Las gateways LLM US-hosted no son inutilizables por las empresas europeas. Muchas trabajan con ellas hoy. Pero tienen características estructurales que crean fricciones de compliance precisas, y esa fricción empeora a medida que las obligaciones del EU AI Act se activan y los equipos de compliance maduran.

Si tu use case es sensible, sectores regulados, clasificaciones de alto riesgo del AI Act, clientes con compra estricta, una gateway UE-based reduce la superficie de compliance materialmente. Si tu use case es poco sensible, las opciones US-hosted están bien y a menudo son más feature-rich hoy.

La pregunta no es "¿es legal el hosting US?". Mayoritariamente lo es, por ahora. La pregunta es "¿hace mis conversaciones de compliance más difíciles?". Para muchos compradores europeos, la respuesta honesta es sí.

---

Próximo: la guía honesta para elegir un router LLM en 2026, un framework de decisión.