Cuando un equipo en China integra la API de Claude, el problema no suele estar en el SDK, sino en el enlace: por dónde salen las peticiones, cómo se paga, cómo se emite la factura, cómo debe retroceder el negocio ante un límite de velocidad y quién investiga cuando hay un fallo. Si se analizan estas cuestiones por separado, la solución queda clara.

Este artículo compara tres rutas habituales —conexión directa oficial, relay propio y gateway de IA local— y ofrece una configuración aplicable de tiempos de espera, reintentos, degradación y monitoreo. Los modelos y precios concretos se rigen por los precios de modelos del sitio; este artículo no constituye asesoría legal ni de cumplimiento.

Nota: Anthropic, Claude y OpenAI son marcas de sus respectivos titulares. Este artículo toma como ejemplo las formas de producto habituales a octubre de 2026; las redes transfronterizas, la salida de datos y la liquidación de pagos deben cumplir la legislación local y los términos de servicio de cada plataforma. Antes de implementar, consulta con el área legal y de cumplimiento.

1. Las tres rutas, en claro

La conexión directa oficial llama directamente a la API que ofrece Anthropic. Es el enlace más corto y el que sincroniza más rápido funciones y documentación; encaja con equipos que ya tienen una entidad en el extranjero, un canal de pago en dólares y una solución madura de red transfronteriza. El costo es que la calidad de red, el pago en dólares, el tipo de cambio y los comprobantes de gasto corren por su cuenta.

El relay propio consiste en desplegar una capa de proxy inverso o un gateway en un servidor extranjero que cumpla la normativa, para centralizar autenticación, logs, límites de velocidad y facturación. Da el mayor control, pero el mantenimiento, los certificados, las actualizaciones y el refuerzo de seguridad son responsabilidad propia; una ubicación de servidor o un tratamiento de datos inadecuados pueden ampliar el riesgo de cumplimiento.

Un gateway de IA local lo ofrece un proveedor del país con punto de entrada compatible con OpenAI, liquidación en moneda local y, normalmente, consola, estadísticas de consumo y factura. El costo de integración es bajo y el cambio entre modelos es sencillo; hay que confirmar la cualificación del proveedor, las cláusulas de datos, el nivel de servicio y la respuesta ante fallos.

Dimensión Conexión directa oficial Relay propio Gateway de IA local
Red y acceso Depende de enlaces transfronterizos; requiere optimización propia Permite elegir la ruta; requiere operación propia Entrada local, normalmente lista para usar
Pago y factura Liquidación en dólares; circuito de reembolso más largo Depende del servidor y de la entidad de la cuenta Liquidación en moneda local y factura
Cumplimiento y datos Hay que evaluar por cuenta propia la salida de datos y los términos La ubicación y retención de datos son responsabilidad propia Hay que revisar los términos y la cualificación del proveedor
Costo de operación Medio, sobre todo red y cuenta Alto: servidores, certificados y actualizaciones Bajo: gestión centralizada en consola
Límites y fallos Reintentos y degradación propios Diseño propio de límites y monitoreo activo El proveedor cubre una parte; hay que probar igualmente
Cobertura de modelos Principalmente Claude Ampliable por cuenta propia Normalmente cubre varios proveedores

2. Red y enlace: medir antes de elegir

No basta con comprobar “si conecta”. En producción hay que medir cuatro cosas: tiempo hasta el primer byte, estabilidad de respuestas largas, pérdida de paquetes en hora pico y reconexión tras cortes. La salida en streaming es más sensible al enlace; conviene hacer pruebas de carga con prompts de longitud real, no solo enviar un “hola”.

En un relay propio hay que distinguir entre “proxy” y “gateway”. Un proxy solo reenvía peticiones; un gateway además hace autenticación, límites, logs y enrutamiento de modelos. Exponer un proxy directamente a internet con una sola clave fija es muy arriesgado; como mínimo, añade control de acceso, límite de tamaño de petición y alertas de anomalías.

Los enlaces transfronterizos deben cumplir la legislación local y los términos de las plataformas. No uses proxies compartidos de origen desconocido ni entregues credenciales de cuenta a terceros no confiables. Cuando haya datos personales o datos importantes, haz primero una clasificación de datos y una evaluación de salida.

3. Pagos, contratos y facturas

El punto que más frena a los equipos locales suele ser la entidad de pago. Las recargas con tarjeta personal, los pagos por terceros y los comprobantes de reembolso inconsistentes a menudo no permiten el registro contable. Antes de elegir una solución, aclara: con quién se firma el contrato, en qué moneda se liquida, qué factura se puede emitir y cuáles son las reglas de reembolso.

Los gateways locales suelen admitir transferencia empresarial en moneda local y factura fiscal, y permiten agrupar el consumo por proyecto o por clave, lo que encaja con equipos que necesitan unificar el gasto multimodelo. La conexión directa oficial encaja con equipos que ya pueden pagar en el exterior. En cualquier ruta, deja por escrito en la orden de compra el precio, el tipo de cambio, los impuestos y las condiciones de reembolso; los costos concretos se rigen por los precios de modelos y por el contrato.

4. Cumplimiento y límites de datos

Como mínimo hay que confirmar: si las entradas y salidas se usan para entrenamiento, cuánto tiempo se conservan los datos, dónde se almacenan, si se puede firmar un acuerdo de tratamiento de datos, qué subencargados existen y cómo se notifican los incidentes de seguridad. Si se ofrecen servicios a usuarios locales, también hay que evaluar los requisitos de protección de datos personales y de salida de datos.

Una práctica realista es clasificar los datos: la información pública puede usar el canal general; el código, los contratos y los datos de clientes deben anonimizarse primero; los escenarios con datos personales sensibles o datos importantes requieren una evaluación específica y documentación por escrito. No sustituyas el juicio de cumplimiento por “primero usémoslo y ya veremos”.

5. Límites, tiempos de espera y degradación

Los límites de la API de Claude suelen calcularse por número de peticiones, tokens de entrada y tokens de salida. Un pico de tráfico, un contexto largo y reintentos concurrentes pueden provocar 429; cuando el servidor está ocupado también puede aparecer 529. Lo correcto es definir tiempos de espera razonables, retroceso exponencial con jitter aleatorio, un máximo de reintentos y operaciones de escritura idempotentes.

import os, random, time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ZSQH_API_KEY"],
    base_url="https://api.zhongshangqihang.com/v1",
    timeout=60.0,
    max_retries=0,
)

def chat(messages, model, fallback):
    for name in [model, fallback]:
        for attempt in range(4):
            try:
                return client.chat.completions.create(
                    model=name,
                    messages=messages,
                    max_tokens=1024,
                    timeout=60,
                )
            except Exception as exc:
                status = getattr(exc, "status_code", None)
                if status not in (429, 500, 502, 503, 504, 529):
                    raise
                if attempt == 3:
                    break
                time.sleep(min(2 ** attempt + random.random(), 8))
    raise RuntimeError("fallaron tanto el modelo principal como el de respaldo")

El tiempo de espera debe ajustarse a la tarea: las preguntas y respuestas normales pueden ser más cortas, mientras que la generación de documentos largos necesita más margen. No es cierto que cuanto más largo mejor; una espera prolongada ocupa el grupo de conexiones. Los reintentos solo deben aplicarse a errores recuperables; 401, 400 y el contexto excedido no deben reintentarse.

El orden de degradación recomendado es: modelo ligero del mismo proveedor, modelo equivalente de otro proveedor y, por último, reglas o resultados en caché. El interruptor de degradación debe estar en el centro de configuración, sin necesidad de modificar código y volver a desplegar; registra cada degradación con el nombre del modelo y el motivo.

6. Aislamiento de claves y monitoreo

  1. Usa claves distintas para producción y pruebas, y sepáralas además por proyecto.
  2. Guarda las claves solo en variables de entorno del servidor o en un gestor de secretos; no las pongas en frontend, repositorios ni logs.
  3. Define cuotas o umbrales de alerta para cada clave y rótalas con regularidad.
  4. Registra volumen de peticiones, tasa de error, latencia P95, consumo de tokens y número de degradaciones.
  5. Configura alertas separadas para 401, 429 y 5xx, para que una sola “tasa de error” no oculte el problema.
  6. Conserva el ID de petición y el nombre del modelo para conciliar con el proveedor y diagnosticar.

El monitoreo debe cubrir el resultado del negocio, no solo si la interfaz devuelve 200. Por ejemplo, la tasa de fallos al analizar JSON, la tasa de éxito de llamadas a herramientas y la proporción de respuestas vacías suelen revelar antes que los códigos HTTP un problema de modelo o de prompt.

7. Lista de verificación para el lanzamiento

  1. Definir la ruta de acceso y la entidad del contrato, y completar la revisión legal y financiera.
  2. Hacer una prueba de carga con tráfico real en el entorno de red objetivo.
  3. Configurar tiempos de espera, reintentos, retroceso y número máximo de reintentos.
  4. Preparar al menos un modelo de degradación disponible y ensayar el cambio.
  5. Completar la clasificación de claves, la configuración de cuotas y el plan de rotación.
  6. Conectar el monitoreo de consumo, tasa de error, latencia y degradaciones.
  7. Guardar las cláusulas de datos, las facturas, los comprobantes de pago y los registros de aceptación.
  8. Hacer un despliegue gradual con poco tráfico y ampliar el volumen después de observar una semana.

Preguntas frecuentes

¿Se puede conectar directamente a la API de Claude desde China?

La disponibilidad depende del entorno de red, la elegibilidad de la cuenta y los términos de la plataforma. Este artículo no ofrece métodos para eludir restricciones; el equipo debe elegir una forma de acceso que cumpla la ley y los términos de servicio, y dar prioridad a gateways locales con contrato y factura.

¿Cuál es la diferencia entre un gateway y un proxy?

Un proxy normalmente solo reenvía peticiones; un gateway además hace autenticación, límites, logs, facturación y enrutamiento de modelos. En producción se recomienda centralizar con un gateway y no exponer un proxy sin protección a internet.

¿Qué hay que tener en cuenta en un relay propio?

La ubicación del servidor, la retención de datos, el control de acceso, la actualización de certificados y la respuesta ante fallos son responsabilidad propia. Antes de desplegar en el extranjero, haz una evaluación de cumplimiento para no poner datos sensibles en un enlace sin control.

¿Hay que reintentar un 429 indefinidamente?

No. Usa retroceso exponencial con jitter aleatorio y limita el número de intentos; un 429 persistente indica que la cuota o la configuración de concurrencia son insuficientes, así que conviene degradar, encolar o ajustar la cuota en lugar de acumular reintentos.

¿Un gateway multimodelo reduce la estabilidad?

Cada capa añade un punto de fallo, pero también añade capacidad de conmutación y degradación. Lo clave es confirmar el nivel de servicio, el monitoreo, las notificaciones de fallo y las reglas de reembolso del proveedor, y hacer por cuenta propia una comprobación activa de extremo a extremo.

Próximos pasos

Crea primero una clave de prueba en ZSQH AI Gateway y valida el enlace, la latencia y la degradación con un lote de tareas reales; después separa las claves definitivas por entorno. La cobertura de modelos y los costos se rigen por precios de modelos.

Lecturas relacionadas: