AIREITEREl enrutamiento regional de OpenRouter en EE. UU. es un control relevante de residencia de datos, no una simple preferencia por proveedores estadounidenses. Tiene una contrapartida importante: solo está disponible en los planes Business y Enterprise, y si no hay un endpoint elegible en EE. UU., la solicitud falla en lugar de salir de la región.
La decisión, en 30 segundos
El enrutamiento regional de OpenRouter en EE. UU. merece la pena cuando una organización debe mantener el procesamiento de prompts dentro de Estados Unidos sin renunciar al acceso a varios proveedores de modelos. Para cargas de trabajo corrientes con datos públicos no suele ser necesario, y tampoco sustituye las opciones de retención cero de datos ni la revisión de las condiciones de cada proveedor.
| Pregunta | Respuesta |
|---|---|
| URL base regional de la API | https://us.openrouter.ai/api/v1 |
| Planes elegibles | Business y Enterprise |
| Cambios en la clave de API y el ID de modelo | Ninguno |
| Si ningún endpoint de EE. UU. sirve el modelo | La solicitud devuelve un 404 en lugar de enrutarse globalmente |
| Aplicación de políticas en el espacio de trabajo | Guardrails puede restringir las regiones de datos permitidas |
| ¿Garantiza retención cero? | No; ZDR es un control independiente |
| ¿Funciona con todos los modelos de OpenRouter? | No; el catálogo regional es un subconjunto |
OpenRouter anunció el enrutamiento en EE. UU. el 9 de septiembre de 2026, junto a su endpoint ya existente para la UE. Según la publicación oficial de lanzamiento, las solicitudes enviadas al hostname estadounidense se descifran y procesan en EE. UU. durante todo el ciclo de vida de la petición.
Puedes reservar el enrutamiento de EE. UU. para servicios sensibles y mantener el tráfico de menor riesgo en la ruta global; la migración puede hacerse de forma gradual.
Qué controla realmente el endpoint regional
El hostname regional determina dónde descifra y procesa OpenRouter una solicitud, además de qué endpoints de proveedores pueden atenderla. OpenRouter también indica que evalúa las herramientas de servidor según la jurisdicción: si una herramienta enviara datos fuera de la región seleccionada, se desactiva en vez de recurrir silenciosamente a infraestructura global.
La nacionalidad del creador del modelo no determina dónde descifra los datos un gateway ni dónde se ejecuta la inferencia.
OpenRouter describe este recorrido:
- La solicitud llega a
us.openrouter.ai. - La terminación TLS, el descifrado, el procesamiento del gateway y el procesamiento de herramientas de servidor elegibles tienen lugar en EE. UU.
- El enrutamiento solo considera endpoints de proveedores que operan en EE. UU.
- Un proveedor elegible ejecuta la inferencia en EE. UU.
- Si no existe una ruta elegible, OpenRouter devuelve
404 No endpoints found supporting your data region.
Este comportamiento de fallo cerrado es clave. Una alternativa global mejoraría la disponibilidad, pero invalidaría una política estricta de residencia; para las solicitudes regionales, OpenRouter prioriza la residencia sobre la finalización.
«La nacionalidad del proveedor importa menos que la ruta real de los datos, la política de registros, los subprocesadores, la región de alojamiento y si se puede aplicar una retención cero de datos». — u/MembershipEmergency7 en r/openrouter
Esa preocupación de un usuario plantea el enfoque correcto para compras. El enrutamiento regional responde a la cuestión de la ubicación de procesamiento según lo que afirma OpenRouter, pero aún deben revisarse contratos, retención, subprocesadores, exportaciones de auditoría y procedimientos ante incidentes.
Cómo enviar solicitudes por la ruta de EE. UU.
Para configurar el enrutamiento regional de OpenRouter en EE. UU. normalmente basta con cambiar la URL base de la API, sin reescribir la solicitud. Se mantienen la misma clave de API, el cuerpo de la petición, el ID de modelo, las preferencias de proveedor, los fallbacks y los ajustes de privacidad.
1. Comprueba el acceso de tu plan
OpenRouter incluye el enrutamiento regional en sus planes Business y Enterprise. La página pública de precios muestra una tarifa de plataforma del 5,5 % para el uso de pago por uso, pero no publica un recargo independiente de autoservicio para el enrutamiento en EE. UU.; confirma el precio de Business o el precio contractual antes de presupuestarlo.
2. Localiza los modelos disponibles en EE. UU.
Consulta el endpoint de modelos desde el hostname regional. El catálogo devuelto refleja los modelos que tienen al menos un endpoint de proveedor elegible en EE. UU.
curl https://us.openrouter.ai/api/v1/models \
-H "Authorization: Bearer $OPENROUTER_API_KEY"El catálogo regional puede variar a medida que cambian los proveedores y los despliegues. Por eso, el descubrimiento de modelos debe formar parte de las comprobaciones de despliegue, no depender de una hoja de cálculo actualizada una sola vez.
3. Envía la solicitud a través de la URL base de EE. UU.
curl https://us.openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "meta-llama/llama-3.3-70b-instruct",
"messages": [
{"role": "user", "content": "Summarize this internal policy."}
]
}'El modelo del ejemplo procede de la documentación de IA soberana de OpenRouter. Antes de usarlo en producción, compruébalo frente al catálogo activo de EE. UU.
4. Fuerza la región con Guardrails
La configuración de una aplicación puede desviarse con el tiempo. Según la documentación de IA soberana de OpenRouter, Guardrails permite establecer allowed_data_regions en us para un espacio de trabajo, equipo, miembro o clave de API; una solicitud enviada a un hostname no permitido se rechaza con HTTP 403 antes de procesarse.
Para una aplicación regulada, el valor predeterminado a nivel de espacio de trabajo es el punto de partida más seguro, ya que no depende de que cada desarrollador recuerde el hostname regional. Las reglas por clave permiten endurecer las condiciones de los servicios sensibles respecto al valor predeterminado del espacio de trabajo.
5. Prueba el fallo, no solo el éxito
Haz una prueba con un modelo compatible y otra con un modelo que no figure en el catálogo de EE. UU. Configura alertas específicas para el 404 regional, de modo que el equipo de operaciones no «resuelva» la incidencia cambiando la URL base al endpoint global.
Los controles de privacidad que suelen confundirse
El enrutamiento regional en EE. UU. controla la geografía; ZDR, el filtrado de recopilación de datos y las condiciones de los proveedores cubren riesgos distintos. Un diseño conforme puede requerir los cuatro, y activar uno no implica activar los demás.
| Control | Qué controla | Qué no acredita |
|---|---|---|
| Enrutamiento regional en EE. UU. | El descifrado, procesamiento, herramientas y endpoints de proveedores elegibles permanecen en EE. UU. según el diseño declarado por OpenRouter | Retención cero, ausencia de entrenamiento o todas las categorías de metadatos de cuenta |
Zero Data Retention (zdr: true) | Enruta hacia proveedores que cumplen la condición ZDR de OpenRouter | La geografía de procesamiento o la disponibilidad universal de modelos |
data_collection: "deny" | Excluye proveedores cuyas políticas permiten el comportamiento de recopilación no autorizado | Residencia geográfica o auditoría independiente |
| Revisión de condiciones y retención del proveedor | Normas contractuales sobre registros, retención y tratamiento de datos | Aplicación técnica por sí sola |
| Guardrails | Aplica la política aprobada de hostname o región en las claves o espacios de trabajo cubiertos | Obligaciones contractuales del proveedor |
La documentación sobre registros de proveedores de OpenRouter establece una distinción importante: los usuarios pueden filtrar proveedores según sus políticas de entrenamiento o recopilación, pero los requisitos de retención no se convierten automáticamente en reglas de enrutamiento. Los equipos siguen siendo responsables de evaluar las condiciones de cada proveedor.
Una solicitud estricta puede combinar el enrutamiento regional con parámetros de privacidad:
{
"provider": {
"zdr": true,
"data_collection": "deny"
}
}Cada condición adicional reduce el conjunto de proveedores elegibles. Un 404 resultante o una menor variedad de modelos es consecuencia de la política, no necesariamente un fallo del enrutamiento.
Valida la carga de trabajo antes de aprobarla
Una revisión para producción debe comprobar la ruta activa y su comportamiento ante errores; considerar suficiente que sea un «proveedor de EE. UU.» no basta. El vacío práctico está en la auditabilidad: OpenRouter documenta la garantía geográfica, pero el material público no ofrece en un único lugar una matriz universal de modelo por proveedor con latencia, condiciones de retención, comportamiento de caché y pruebas contractuales.
Utiliza esta secuencia de aprobación:
- Consulta el catálogo de modelos de EE. UU. con la misma cuenta y los mismos ajustes de privacidad que se usarán en producción.
- Selecciona el modelo necesario y registra los endpoints de proveedor elegibles que muestra OpenRouter.
- Aplica Guardrails de EE. UU. a nivel de espacio de trabajo o de clave de API.
- Activa ZDR y deniega la recopilación de datos si la carga de trabajo requiere ambos.
- Confirma mediante compras las condiciones de retención y los subprocesadores actuales del proveedor.
- Registra el modelo, el proveedor que atiende la petición, el ID de solicitud, el estado, la latencia y los errores relacionados con políticas.
- Prueba un modelo no disponible y verifica que ninguna ruta de código reintente a través de
openrouter.ai. - Repite la comprobación cuando cambie un modelo, una preferencia de proveedor o una regla de privacidad.
Los informes de la comunidad explican por qué conviene observar la ruta tras el lanzamiento. En una conversación de Reddit, u/Cooperman411 afirmó: «No pude encontrar Deepseek como proveedor porque tengo activado ZDR (Zero Data Retention)». Es una anécdota, no una referencia de rendimiento, pero muestra cómo un control de privacidad puede eliminar una ruta que se esperaba disponible.
No extrapoles cifras comunicadas de aciertos de caché o latencia desde otra carga de trabajo. La selección de proveedor, los filtros de privacidad, la forma del prompt, el despliegue del modelo y las condiciones de tráfico pueden alterar el resultado; mide en su lugar la solicitud con características de producción.
Cuándo tiene sentido contratar el enrutamiento regional de EE. UU.
El enrutamiento regional de OpenRouter en EE. UU. encaja en organizaciones que necesitan un límite de procesamiento en EE. UU. con fallo cerrado y valoran el acceso multimodelo lo suficiente como para aceptar un catálogo más reducido. Los desarrolladores individuales y los equipos sin un requisito formal de residencia normalmente deberían seguir usando el endpoint global, ya que esta función regional exige un plan superior y puede reducir la disponibilidad.
| Carga de trabajo | Recomendación | Motivo |
|---|---|---|
| Datos regulados de clientes estadounidenses | Preseleccionar y validar | El descifrado, procesamiento y enrutamiento de proveedores regionales, junto al fallo cerrado, responden directamente a los requisitos de residencia |
| Documentos internos sensibles | Considerar con ZDR y revisión contractual | La geografía por sí sola no resuelve la política de retención o entrenamiento |
| Generación de contenido público | Usar normalmente el endpoint global | Las restricciones de residencia añaden coste de plan y reducen rutas sin un beneficio claro de reducción de riesgo |
| Modelo chino de pesos abiertos bajo una política estadounidense | Caso de uso sólido si aparece en el catálogo regional | OpenRouter afirma que proveedores de EE. UU. sirven modelos como DeepSeek V4 Pro, Kimi K3 y GLM 5.2 desde centros de datos estadounidenses. |
| Experimentación de consumo o gratuita | No encaja | El enrutamiento regional está limitado a los planes Business y Enterprise |
| Carga de trabajo que requiere un modelo ausente del catálogo de EE. UU. | No desplegar sin cambios | La solicitud fallará en lugar de salir de la región |
Elígelo por residencia, no por una velocidad supuesta: OpenRouter no ha publicado un benchmark general de latencia para el endpoint estadounidense, y los grupos regionales de proveedores pueden ser distintos.
Preguntas frecuentes sobre OpenRouter US In-Region Routing
¿Las herramientas también se mantienen en EE. UU.?
OpenRouter indica que evalúa las herramientas de servidor por jurisdicción y desactiva las que enviarían datos fuera de la región seleccionada. Antes de desplegar, verifica la herramienta concreta que necesita la carga de trabajo.
¿La garantía cubre todos los metadatos?
El material de lanzamiento habla expresamente de prompts, completaciones, procesamiento de solicitudes, enrutamiento de proveedores y herramientas de servidor. Solicita a OpenRouter detalles contractuales sobre registros de facturación, telemetría de abuso, logs, copias de seguridad y otros metadatos que exija la política de la organización.
¿Una cuenta personal puede usar el endpoint de EE. UU.?
El enrutamiento regional está documentado para los planes Business y Enterprise, no para los niveles Free ni los de pago por uso ordinario. Un desarrollador sin acceso al plan aún puede utilizar controles de privacidad y de enrutamiento de proveedores, pero no sustituyen la garantía de procesamiento regional.
Apruébalo solo si superan la revisión el catálogo regional, el bloqueo de Guardrails, el conjunto de proveedores filtrado por privacidad y las condiciones de los proveedores. Si falla una comprobación, cambia el modelo o el diseño de la carga de trabajo; una alternativa global invalida el límite de residencia.