La necesidad de un relay de OCR suele surgir en tres situaciones: el acceso a modelos de visión extranjeros es inestable, las facturas de varios proveedores de OCR están dispersas, o el reconocimiento por lotes requiere una cola y reintentos unificados. La capa relay reduce el costo de integración, pero también concentra claves, datos, facturación y disponibilidad en una nueva dependencia.

Este artículo explica las formas que adopta un relay de OCR, el procesamiento por lotes y asíncrono, los criterios de facturación, el riesgo de las claves, la privacidad de los datos y cómo verificar el servicio y migrar de forma segura. Los servicios y precios concretos se rigen por los precios de modelos del sitio y por las condiciones del proveedor.

Nota: OpenAI, Claude, Gemini, Baidu AI Cloud, Tencent Cloud y Alibaba Cloud son marcas de sus respectivos titulares; este artículo solo las menciona para una discusión técnica y no implica afiliación ni relación de agencia con dichos proveedores. La transferencia internacional de datos, la protección de la privacidad y la liquidación de pagos deben cumplir la legislación local y los términos de servicio de cada plataforma.

1. Qué retransmite realmente un relay de OCR

Un relay o proxy no produce capacidad de OCR por sí mismo: reenvía la solicitud al proveedor de OCR o al modelo de visión de origen y devuelve el resultado. Su valor está en la capa de acceso: una dirección y autenticación unificadas, gestión centralizada de claves, asignación de cuotas por proyecto, registro de uso y errores, y capacidad de cambiar entre varios proveedores.

Al evaluar un relay no basta con mirar el reconocimiento; también hay que ver si el enlace es más controlable. Cada salto adicional añade un punto de timeout, un registro y un responsable del tratamiento de datos. Los equipos sin personal de operación que necesitan un punto de entrada único encajan bien con un relay; los escenarios con exigencias muy altas de latencia y auditoría encajan mejor con una solución propia o una conexión directa.

2. Formas habituales y límites de uso

Forma Método de acceso Adecuada para Riesgo principal
Conexión directa oficial Abrir una cuenta con el proveedor Un solo motor, uso estable y canal de pago disponible La red transfronteriza y las facturas en divisa corren por tu cuenta
Relay de reventa Comprar cuota o compartir una clave Pruebas rápidas y validación de bajo importe Proveedor y cuota poco transparentes; el servicio puede interrumpirse
Puerta de enlace gestionada Entrada compatible con OpenAI y consola de gestión Facturación unificada de varios modelos y trabajo en equipo Hay que confirmar cláusula por cláusula los términos de datos y los límites
Proxy autoalojado Desplegar un proxy inverso o una puerta de enlace Salida fija, auditoría y personalización profunda Costos de servidor, certificados, actualizaciones y guardias

Un relay de reventa se parece más a "comprar cuota por encargo": conviene preguntar a quién pertenece el saldo y cómo se reembolsa. Una puerta de enlace gestionada se parece más a "un servicio de capa de acceso": interesa confirmar compatibilidad de protocolo, registros, límites y respuesta ante fallos.

3. Lotes y asíncrono: no fuerces la interfaz síncrona

Una sola imagen puede procesarse con una interfaz síncrona; con cientos o miles de imágenes, PDF de varias páginas o envíos concentrados, la interfaz síncrona sufre timeouts, conexiones agotadas y tormentas de reintentos. El reconocimiento por lotes debe separar el "envío" de la "obtención del resultado":

  • Crea una lista de pendientes y calcula un hash de contenido para cada imagen o PDF como clave de idempotencia.
  • Divide según los límites de la interfaz: tamaño por imagen, páginas por solicitud, archivos por tarea y concurrencia máxima, cada uno con su umbral.
  • Envía mediante una interfaz de tareas asíncronas y registra el task_id, la hora de envío, el estado y la dirección del resultado.
  • Obtén los resultados por sondeo o callback, con un intervalo razonable y un tiempo máximo de espera.
  • Descarga los archivos de resultado a disco a tiempo; no dependas a largo plazo de enlaces que caducan.
  • Clasifica las tareas fallidas: las reintentables van a una cola con retroceso exponencial y las no reintentables, a una cola de revisión humana.
  • En cada lote, contrasta el número de éxitos, fallos, imágenes facturadas y registros realmente almacenados, y luego revisa una muestra.

La cola debe tener contrapresión: cuando aumentan los errores 429, reduce la velocidad de consumo en lugar de reintentar sin límite. En PDF de varias páginas hay que distinguir entre el fallo del documento completo y el de una página concreta.

4. Transparencia de facturación: por imagen, por página o por token

Los criterios de facturación del OCR varían mucho: el OCR tradicional suele cobrar por imagen o por llamada, y los PDF pueden cobrarse por página; los modelos de visión grandes suelen cobrar por los tokens de las imágenes de entrada más los tokens de salida; algunos servicios ofrecen cuotas mensuales o planes escalonados. Antes de comparar precios, unifica el criterio.

Estos son los detalles que conviene confirmar con el servicio relay:

  • Si las solicitudes fallidas se facturan y si los timeouts y errores 5xx cuentan como uso.
  • Si los reintentos automáticos se cobran dos veces y cómo se distinguen de un reprocesamiento manual.
  • Si el PDF se cobra por archivo o por página, y si las páginas en blanco o de baja calidad se facturan.
  • Si la compresión o el recorte de imágenes afecta el número de imágenes facturadas o los tokens.
  • Si las tareas asíncronas fallidas o agotadas por timeout se reembolsan y si el saldo tiene fecha de caducidad.
  • Si el uso puede exportarse por proyecto, clave y modelo, y si la factura cuadra con los registros.

Si algo no está claro, haz primero una prueba con un lote fijo; no te guíes solo por el precio unitario anunciado ni restes criterios de facturación distintos. El costo real se rige por los precios de modelos y el contrato.

5. Riesgo de claves: el punto único que más se pasa por alto en un relay

Las claves de un relay suelen tener una cuota grande; si se filtran, la pérdida puede ser mayor que con una cuenta directa. Riesgos habituales: claves incluidas en el frontend o en el paquete de una app móvil, claves de prueba que nunca se revocan, una sola clave compartida por todos los proyectos, cuotas sin límite superior y accesos que siguen activos después de que un empleado deja la empresa.

Medidas básicas: separa claves por proyecto y entorno, define cuota y fecha de caducidad, y vincula una lista blanca de IP cuando sea posible; guarda las claves solo en el servidor y haz que el frontend pase por el backend; configura alertas de volumen, tasa de fallos e IP de origen; usa claves distintas para los lotes y para el servicio en línea.

También hay que aclarar el mecanismo de salida: qué ocurre con el saldo si el servicio se detiene, si se pueden exportar los resultados, si la clave puede revocarse de inmediato y si existe confirmación de borrado. No prepagues un periodo demasiado largo solo por un descuento.

6. Privacidad de datos: una imagen es más sensible que un texto

Lo que se sube a un OCR puede ser un documento de identidad, una licencia comercial, una factura, un contrato o una historia clínica; la densidad de información es alta. Antes de firmar, confirma al menos: si las imágenes se guardan en disco y dónde, cuánto tiempo se conservan, si se usan para entrenamiento, qué subcontratistas intervienen, cómo se aplica una solicitud de borrado, si el transporte y el almacenamiento están cifrados y si se puede firmar un acuerdo de tratamiento de datos.

En lo técnico, se puede reducir la exposición: subir solo el recorte que contiene los campos objetivo, ocultar datos personales irrelevantes, usar proyectos y claves independientes para archivos sensibles, y aplicar permisos de acceso y plazos de retención a los resultados. La legalidad de una transferencia internacional y los procedimientos necesarios deben evaluarse según la normativa y, si hace falta, con asesoría legal. Un servicio relay no debe considerarse conforme por defecto: es solo una pieza del enlace.

7. Lista de migración

  1. Inventaría interfaces, nombres de modelo, tamaños de imagen, páginas de PDF, concurrencia pico, llamadas mensuales y factura actual.
  2. Prepara entre 50 y 100 muestras reales que cubran casos nítidos, borrosos, inclinados, manuscritos, tablas, varias columnas y PDF de varias páginas.
  3. Ejecuta la solución nueva y la anterior en paralelo sobre el mismo lote y compara precisión de caracteres, precisión de campos, tasa de éxito estructurada y latencia P95.
  4. Verifica la facturación con un lote fijo: que coincidan las líneas de registro, los éxitos, los fallos y la factura.
  5. Prueba las rutas de error: 401, 403, 404, 413, 429, 5xx, timeouts y enlaces de resultado caducados.
  6. Revisa el contrato y las cláusulas de datos, y confirma el mecanismo de borrado, los subcontratistas y el tipo de factura.
  7. Aumenta el tráfico al 5 %, 20 % y 50 %, y finalmente cambia todo el flujo, manteniendo el enlace anterior como reversión.
  8. Tras dos a cuatro semanas de operación estable, revoca las claves antiguas, archiva los resultados anteriores y ajusta los umbrales de monitoreo.

Durante la migración, no cambies al mismo tiempo el modelo de reconocimiento y la lógica de análisis; de lo contrario, será difícil localizar el origen de los problemas.

8. Cómo verificar un servicio relay

Primero envía una imagen de prueba fija y confirma la estructura de respuesta, los campos de uso y los códigos de error; después repite la solicitud con la misma imagen y observa si la latencia y la facturación son coherentes. El ejemplo usa una solicitud de visión compatible con OpenAI; el nombre del modelo y los parámetros dependen de la documentación del proveedor:

import os
import requests

base = os.environ["ZSQH_BASE_URL"].rstrip("/")
headers = {"Authorization": f"Bearer {os.environ['ZSQH_API_KEY']}"}

resp = requests.post(
    f"{base}/chat/completions",
    headers=headers,
    json={
        "model": os.environ["VISION_MODEL"],
        "messages": [{
            "role": "user",
            "content": [
                {"type": "text", "text": "Reconoce todo el texto de la imagen y devuélvelo en el orden original."},
                {"type": "image_url", "image_url": {"url": "https://example.com/test.png"}},
            ],
        }],
    },
    timeout=90,
)
resp.raise_for_status()
data = resp.json()
print(data["choices"][0]["message"]["content"][:200])
print("usage:", data.get("usage"))

Además de la funcionalidad, hay que mirar indicadores no funcionales: una observación de tres a siete días con poco tráfico, la proporción de errores 429 y 5xx, el tiempo de respuesta a tickets, si el detalle de facturación puede exportarse y el ciclo de facturación. Conviene probar también con una clave errónea y con una solicitud fuera de límite, para confirmar que los mensajes de error son claros y no revelan detalles internos. Si necesitas un punto de entrada unificado, puedes crear una clave de prueba en ZSQH AI Gateway y validar primero con un lote pequeño de imágenes antes de migrar.

Lecturas relacionadas:

Preguntas frecuentes

¿Qué diferencia hay entre un relay de API OCR y comprar la interfaz oficial directamente?

En la conexión directa, el proveedor presta el servicio y mantiene la documentación sincronizada; el relay añade una capa de acceso y gana en punto de entrada unificado, liquidación en moneda local y gestión centralizada, pero suma un punto de timeout, un responsable del tratamiento y una dependencia. La elección depende de las restricciones de red, pago, operación y cumplimiento.

¿El servicio relay guarda mis imágenes?

Depende de la arquitectura y de las condiciones del servicio; no se puede generalizar. Confirma si se almacenan, dónde, durante cuánto tiempo, si se usan para entrenamiento, qué subcontratistas participan y cómo se ejecuta una solicitud de borrado. Para imágenes sensibles, conviene recortar y ocultar datos antes de subirlas.

¿Para el reconocimiento por lotes conviene una interfaz síncrona o asíncrona?

Con pocas imágenes sirve la síncrona; con lotes grandes, PDF de varias páginas o envíos concentrados conviene la asíncrona, separando el envío de la obtención del resultado y registrando el task_id, el estado de sondeo y la caducidad del resultado.

¿Por qué la facturación del relay no coincide con la oficial?

La causa habitual es un criterio distinto: por imagen, por página, por solicitud o por token; si se cuentan los fallos y los reintentos; si el PDF se divide por páginas. Unifica primero el criterio y luego contrasta registros y factura con un lote fijo.

¿Cuánto código hay que cambiar para migrar a un relay?

Si se usa un protocolo compatible con OpenAI, normalmente basta con cambiar base_url, la clave y el nombre del modelo; aun así hay que ajustar el formato de imagen, los timeouts, los reintentos y el análisis del resultado. Conviene ejecutar en paralelo, cambiar el tráfico por etapas y conservar una ruta de reversión.