Cómo diseñar la conmutación por error entre proveedores de modelos de OpenAI

Cuando una empresa depende de un flujo de trabajo de IA, incluso una falla breve de un proveedor puede retrasar decisiones o interrumpir servicios. Hemos estado trabajando con clientes del sector financiero que desarrollan aplicaciones con agentes y flujos de trabajo de ciberseguridad con modelos de OpenAI. En este artículo explicamos cómo abordamos el enrutamiento y la recuperación de cargas de trabajo críticas en producción. A lo largo del artículo usaremos como ejemplo una evaluación de fraude de solo lectura dentro de un flujo de pagos.

Aquí, el acceso directo (1P) se refiere al uso de la API de OpenAI sin intermediarios. El acceso a través de terceros (3P) se refiere al uso de modelos de OpenAI a través de un proveedor de nube, independientemente de dónde se ejecute la aplicación. Veremos qué aporta el acceso directo para probar modelos y funciones en versión preliminar, cómo influyen los requisitos de la carga de trabajo y la conectividad privada en la elección de la ruta, y qué operaciones pueden cambiar de ruta de forma segura si ocurre una falla. Luego compartiremos un prompt para implementar la política en un gateway existente con Codex y explicaremos qué debes validar antes de habilitar la conmutación por error.

¿Por qué usar ambas rutas?

El acceso directo a OpenAI es valioso incluso cuando la aplicación se ejecuta en producción a través de un proveedor de nube. Una de las principales razones es el acceso a modelos y funciones en versión preliminar. Cuando están disponibles a través de la API directa, los equipos que cumplen los requisitos pueden evaluarlos con sus propios flujos de trabajo antes de que el proveedor de nube que eligieron los ofrezca.

El entorno donde se ejecuta el flujo de trabajo suele influir en la elección de la ruta de producción. Un servicio de nube de terceros puede adaptarse a la infraestructura y los controles operativos existentes de una aplicación, mientras que el acceso directo a OpenAI puede ajustarse mejor a los requisitos de otro flujo de trabajo. Valida los modelos, las funciones y el comportamiento que necesitas en la ruta elegida y usa el acceso directo a OpenAI para seguir experimentando. La disponibilidad depende del proveedor, del punto de acceso, de la región y de tu cuenta.

Para las cargas de trabajo críticas, también consideramos la conmutación por error entre 1P y 3P una vez validada. La conmutación por error entre proveedores consiste en reintentar una solicitud a través de otro proveedor aprobado cuando el principal no puede atenderla. Solo resulta útil si la solicitud puede repetirse de forma segura y la alternativa cumple los requisitos del flujo de trabajo.

Un proveedor global de servicios de pago podría usar la API Responses para realizar una evaluación de fraude independiente y de solo lectura. Si se agota el tiempo de espera de la llamada antes de que se use el resultado, la aplicación puede reintentarla a través de un proveedor secundario validado dentro del plazo de la transacción.

Una sesión en curso de la API Agents requiere otro método de recuperación. El cambio de proveedor por sí solo no permite retomar la conversación ni el trabajo guardado, ni conciliar los resultados de las acciones anteriores. Ese tipo de recuperación es mucho más difícil y queda fuera del alcance de este artículo.

Por esa diferencia, consideramos que el soporte para varios proveedores es una capacidad de la plataforma y que la decisión de cambiar de ruta ante una falla corresponde a cada flujo de trabajo.

Enrutamiento planificado y conmutación por error

Elegir una ruta de producción y aprobar la conmutación por error son decisiones independientes. El enrutamiento planificado puede consistir en distribuir el tráfico entre proveedores o enviar a otra ruta la demanda que exceda la capacidad de la primera. Cada estrategia requiere sus propias pruebas de capacidad, costo, calidad y recuperación.

Algunos clientes usan la API Decisions como fuente de información opcional para tomar decisiones de enrutamiento. Para que el flujo de trabajo pueda seguir funcionando, define cómo se enrutará el tráfico si ese servicio deja de estar disponible.

En los diagramas, 1P es la ruta principal y una ruta 3P aprobada es la secundaria. Cualquiera de las dos puede ser la principal, según la carga de trabajo.

Dónde se ubica el enrutador

Figura 1. La API de OpenAI es la ruta principal y un proveedor externo aprobado es la ruta secundaria. La plataforma opera el enrutador y la aplicación define la política. Los modelos, las funciones, la capacidad, los controles y la disponibilidad pueden variar entre rutas.

Puedes usar tu enrutador de modelos o gateway de LLM existente si permite aplicar reglas distintas a cada ruta. Envía el tráfico normal a la ruta principal. Usa la ruta secundaria que probaste solo cuando se cumplan las condiciones de conmutación por error.

Define quién puede usar cada ruta, en qué regiones y con qué modelos y API. Registra las entidades jurídicas, los equipos, las cuentas o proyectos de los proveedores y las reglas de manejo de datos que se hayan aprobado. La aprobación se aplica únicamente a las cargas de trabajo y las regiones acordadas.

Conectividad privada y elección de la ruta

Muchos clientes de sectores regulados requieren conectividad privada como parte de sus controles de seguridad. Para ellos, elegir una ruta también implica verificar cómo establecer una conexión privada entre la nube donde se ejecuta su aplicación y cada proveedor. El diagrama muestra una aplicación y un gateway en la red privada del cliente, con rutas privadas independientes hacia cada proveedor.

Figura 2. La API de OpenAI (1P) es la ruta principal y un proveedor aprobado (3P), como Amazon Bedrock o Azure OpenAI, es la secundaria. Solo el tráfico de recuperación que cumple los requisitos usa la ruta secundaria.

Al momento de publicar este artículo, las opciones de conectividad privada difieren entre 1P y 3P. Para el acceso directo a OpenAI (1P), OpenAI Private Link usa un punto de acceso privado de Azure. Para que las cargas de trabajo en AWS y Google Cloud puedan usar esta ruta privada hacia la API directa de OpenAI, el cliente debe gestionar la conectividad con Azure.

Para el acceso a través de terceros (3P), Amazon Bedrock usa puntos de acceso de interfaz de VPC específicos de cada API a través de AWS PrivateLink, mientras que Azure OpenAI usa puntos de acceso privados de Azure. Antes de habilitar la conmutación por error, verifica el DNS, el acceso y la disponibilidad regional de los modelos y las API en ambas rutas. OpenAI Private Link no cambia automáticamente de un punto de acceso regional a otro, por lo que la recuperación entre regiones requiere configuración y pruebas específicas. Usar HTTPS público para la recuperación también requiere aprobación explícita.

Las capacidades que ofrece cada proveedor pueden cambiar. Consulta la documentación oficial antes de elegir o habilitar una ruta.

¿Qué operaciones pueden cambiar de ruta si ocurre una falla?

No todas las operaciones tienen una ruta secundaria adecuada. Por ejemplo:

• Funciones no disponibles: un flujo de trabajo podría usar la búsqueda web a través de la API directa de OpenAI para consultar información actualizada. Si la ruta secundaria no admite esa función, no omitas la búsqueda sin avisar. Valida una implementación alternativa o mantén deshabilitada la conmutación por error para esa operación.
• Comportamiento sin validar: no basta con que el modelo tenga el mismo nombre o que la API sea compatible. Ejecuta el arnés de ejecución y las evaluaciones existentes del flujo de trabajo en la ruta secundaria antes de habilitarla.
• Restricciones de residencia de datos o de estado: no cambies a un destino que incumpla los requisitos aprobados de ubicación de los datos o que no pueda acceder al estado necesario para completar la operación de forma segura.

Cuando ninguna ruta secundaria cumpla los requisitos, pon el trabajo en cola sin exceder el plazo acordado, usa una vía aprobada con funcionalidad reducida o intervención manual, o detén la operación de forma segura. Un paso de inferencia que se pueda reintentar podría cumplir los requisitos aunque el flujo de trabajo completo no los cumpla.

Si se agota el tiempo de espera de una evaluación de fraude de solo lectura, se puede considerar otro intento si aún no se ha usado el resultado y queda tiempo suficiente. Una vez que la salida llega a otro sistema, la recuperación requiere un procedimiento de reinicio probado. Si es posible que una acción ya se haya completado, confirma el resultado y evita que la acción se duplique antes de reiniciar.

Cuándo y cómo cambiar de ruta ante una falla

En el ejemplo de pagos, si un modelo está ocupado o no está disponible, se podría usar otro modelo aprobado como respaldo. Reintentar la evaluación a través de otro proveedor es una conmutación por error entre proveedores. En ocasiones cambian tanto el modelo como el proveedor.

Primero evaluamos si cambiar de proveedor ayudaría. Un gateway, un servicio de recuperación de información o un sistema de identidad compartidos pueden afectar ambas rutas. Prueba la conectividad, el acceso y la capacidad de la ruta secundaria. Comprueba que la recuperación regional sea compatible con tus modelos, tus herramientas alojadas y tus requisitos de ubicación de datos.

Si persisten las fallas o las respuestas lentas, un disyuntor puede suspender el envío de nuevas solicitudes a la ruta afectada. Define límites de errores y tiempos de respuesta por proveedor, modelo, región y flujo de trabajo. Cada solicitud debe cumplir los requisitos de conmutación por error.

Antes de reintentar una solicitud, comprueba que sea seguro repetirla y que pueda completarse dentro del plazo del flujo de trabajo. La ruta secundaria debe estar aprobada, habilitada y operativa. Debe haberse probado con la carga adicional y debe quedar presupuesto disponible. Consulta la documentación de OpenAI sobre códigos de error y límites de solicitudes. Revisa también las reglas de los demás proveedores sobre errores, reintentos, cuotas y facturación.

La siguiente tabla propone criterios conservadores para empezar a aplicar la conmutación automática por error. Ten en cuenta los detalles del error que proporciona cada proveedor, además del código de estado HTTP.

Una sola capa debe controlar los reintentos de la aplicación, el SDK y el gateway para que no se multipliquen. Usa un presupuesto compartido de reintentos y sigue las indicaciones de Retry-After cuando sean válidas. En los demás casos, usa esperas exponenciales acotadas con variación aleatoria: aumenta la espera entre intentos, introduce variación aleatoria y limita la cantidad de intentos. Reintenta únicamente las llamadas de inferencia que sea seguro repetir y respeta tanto el plazo de la solicitud como el del flujo de trabajo.

Limita el tráfico de conmutación por error para evitar que la ruta secundaria se sature. Restablece gradualmente el tráfico hacia la ruta principal una vez que las solicitudes representativas se mantengan dentro de los límites de errores y tiempos de respuesta durante un período definido. Si se superan esos límites, suspende el aumento de tráfico. Si ambas rutas tienen restricciones, aplica la política de recuperación acordada para el flujo de trabajo.

Implementa la política de conmutación por error con Codex

Ahora podemos usar Codex para implementar estas reglas de recuperación en un gateway de LLM existente. En el ejemplo de pagos, limitamos el trabajo al paso de evaluación de fraude, que es independiente y de solo lectura. La ruta principal se conserva y la conmutación por error permanece deshabilitada hasta que se apruebe y valide la ruta secundaria.

Abre en Codex el repositorio donde se gestiona la configuración del gateway o el enrutamiento de la aplicación. Luego adapta el siguiente prompt a tu flujo de trabajo y a las rutas que planeas usar.

Agrega la conmutación por error entre proveedores para [workflow’s self-contained, read-only inference step] en [repository/gateway] y déjala deshabilitada de forma predeterminada. Conserva la ruta principal y reutiliza el gateway existente, las rutas aprobadas de la plataforma y la política del flujo de trabajo.

Revisa las versiones del gateway, del SDK y de los adaptadores, la configuración de despliegue, las API y la documentación oficial vigente. Separa los cambios de la aplicación y los del gateway según quién sea responsable y qué revisión requieran. Para las dependencias que estén a cargo de otros equipos, proporciona la configuración y las pruebas de integración. Señala los controles que no sean compatibles. No des por supuesta ninguna aprobación ni ningún límite. Hasta verificarlos, mantén deshabilitadas las rutas de conmutación por error que dependan de ellos.

Usa reglas probadas de clasificación de errores específicas de cada proveedor. Permite la conmutación ante fallas transitorias del servicio o de la red, o ante una limitación de frecuencia confirmada como temporal, solo si es seguro repetir la solicitud. La ruta secundaria debe estar aprobada, habilitada y operativa, ofrecer las funciones y los controles de datos requeridos, tener capacidad comprobada y contar con presupuesto y tiempo suficientes para terminar. Bloquea la conmutación ante solicitudes no válidas, fallas de acceso, rechazos, agotamiento de la cuota, los créditos o el presupuesto, errores desconocidos y errores 429 de causa ambigua.

Usa un solo controlador de reintentos para el cliente, el gateway y el SDK. Deshabilita las cadenas de reintentos o de conmutación por error que entren en conflicto. Aplica un único límite al total de intentos y respeta tanto el plazo de la solicitud como el del flujo de trabajo. Usa el tiempo de espera configurado para cada intento sin exceder el plazo total. Acepta un solo resultado por solicitud lógica e ignora las respuestas tardías de intentos anteriores. Respeta Retry-After cuando su valor sea válido. En caso contrario, usa esperas exponenciales acotadas con variación aleatoria. Si hay una salida parcial o una acción de resultado incierto, nunca repitas la operación a ciegas. Tampoco des por hecho que el estado se transfiere entre proveedores. Aplica la política aprobada para poner la solicitud en cola, devolver un resultado reducido o detener la operación. Incluye la opción de deshabilitar la conmutación manualmente, un disyuntor y el retorno gradual a la ruta principal.

Prueba el recorrido real de la solicitud con servicios HTTP simulados locales y con el acceso a redes externas bloqueado. Incluye aserciones para verificar el orden de las rutas, la cantidad de llamadas y el tiempo transcurrido en cada caso: éxito, fallas que permiten la conmutación, cada clase de error bloqueada, incumplimiento de los requisitos de conmutación, salida parcial, acciones de resultado incierto, presupuestos agotados, falla de ambas rutas y activación de los controles de recuperación. En los casos bloqueados no debe hacerse ninguna llamada a la ruta secundaria. Mantén los límites sintéticos en los datos de prueba y protege los secretos. No hagas llamadas a servicios reales ni realices despliegues sin autorización.

Entrega parches mínimos, las pruebas con los requisitos que verifica cada una, los resultados, las instrucciones para revertir los cambios y la lista de comprobaciones pendientes en las rutas reales. Deja deshabilitadas todas las rutas de conmutación por error que no se hayan verificado.

El prompt le pide a Codex un cambio acotado en el gateway, pruebas que muestren cuándo se debe llamar a la ruta secundaria y cuándo se debe evitar esa llamada, y una lista de las comprobaciones pendientes en las rutas reales. Revisa primero el parche y los resultados de las pruebas locales. Luego valida el comportamiento del modelo, los controles de datos, la capacidad y la recuperación bajo carga antes de habilitar la conmutación por error.

Valida las rutas y la recuperación

El ejemplo de pagos ilustra comprobaciones que también se aplican a otras cargas de trabajo críticas. Prueba ambas rutas con los criterios de aceptación del flujo de trabajo relativos a la calidad, la seguridad, el formato de salida, el uso de herramientas y los límites de contexto. Registra la configuración probada, la disponibilidad y los requisitos de acceso, incluidos los niveles de procesamiento y las funciones alojadas. Define cuándo se deben repetir las pruebas.

Las restricciones de datos de la evaluación, incluidos los límites sobre el registro de prompts y salidas, se aplican tanto durante el funcionamiento normal como durante la recuperación. Antes de habilitar cualquiera de las rutas, revisa las credenciales, las rutas de red, la recuperación de información, las herramientas, el estado almacenado y los registros con los responsables de asuntos legales, privacidad, seguridad y gobernanza de datos.

Para esa revisión se necesitan la documentación y los contratos del servicio. Con ellos se debe confirmar dónde se procesan y almacenan los datos, cuánto tiempo se conservan, cómo se cifran y quién controla las claves y el acceso. Ni la ubicación de un punto de acceso ni una conexión privada bastan por sí solas para confirmar esos aspectos. Los controles, los requisitos de elegibilidad y las responsabilidades varían según el punto de acceso. Consulta los controles de datos de OpenAI.

Incluso una ruta adecuada necesita capacidad disponible para el tráfico de recuperación. Un panel con datos agregados de todo el proveedor puede ocultar las limitaciones de frecuencia que afectan al modelo de evaluación de fraude. Por eso, monitorea la cantidad de solicitudes y tokens por unidad de tiempo, las solicitudes simultáneas, las limitaciones de frecuencia, los tiempos de respuesta y el presupuesto aprobado restante, desglosados por modelo, cuenta o proyecto y región de cada ruta.

Para determinar si la ruta secundaria tiene capacidad suficiente, haz una prueba de carga que combine su carga de trabajo habitual con el tráfico previsto de evaluaciones de fraude y sus reintentos. Usa los resultados para fijar el límite de tráfico de conmutación por error y decidir qué solicitudes pueden esperar, cuáles se pueden atender con funcionalidad reducida y cuáles se deben detener. La cuota por sí sola no garantiza que una solicitud se complete antes de que venza el plazo.

Cambiar la ruta de la evaluación también puede afectar su costo y su tiempo de respuesta. Compara el costo por evaluación completada con éxito. Incluye los costos por fallos de caché, los cargos por transferencia de datos y los costos de conectividad. Mide también los retrasos adicionales cuando un dato no está en caché o cuando las solicitudes pasan de una nube a otra.

Por último, prueba bajo carga los escenarios de falla de la tabla. Incluye casos en los que falten funciones o la ruta secundaria esté ocupada o no esté disponible. Comprueba que la política de recuperación funcione según lo previsto, incluidos los límites de tráfico, la detención manual y el retorno gradual a la ruta principal.

Para evaluar la recuperación, mide cuánto tarda en restablecerse el servicio, cuántas evaluaciones terminan dentro del plazo, qué calidad tienen los resultados, cuánto cuesta la recuperación y cuántas acciones se duplican. Los ejercicios periódicos mantienen vigentes estas comprobaciones a medida que vencen las credenciales, cambian las configuraciones o varía la capacidad.

Quién se encarga de la recuperación

Una forma práctica de organizar el trabajo es asignar por separado la responsabilidad del servicio de enrutamiento y la de la aplicación. Un equipo de plataforma podría gestionar las integraciones con los proveedores, el enrutador, el monitoreo y los registros de auditoría. Se encargaría de que el servicio de enrutamiento estuviera listo para producción y aplicaría controles de destino, identidad, datos, tráfico y gasto. Habría responsables de guardia designados para deshabilitar rutas y gestionar el retorno a la principal.

En este modelo, los responsables de la aplicación definen qué operaciones pueden cambiar de ruta ante una falla, cuáles son los objetivos de servicio y calidad y qué reducciones de funcionalidad son aceptables. También responden por los resultados de negocio, el contexto guardado para la recuperación, los permisos de las herramientas, la verificación de las respuestas y la protección contra acciones duplicadas, incluso cuando se comparten el estado o las herramientas.

Tu equipo puede combinar estas funciones o distribuirlas de otra manera. Antes de habilitar la conmutación por error, acuerda con tu equipo quién aprueba los controles, quién se encarga de las pruebas de las rutas y de los procedimientos operativos, y quién tiene autoridad para actuar durante un incidente.

Conclusión

Considera el acceso directo a OpenAI como una de tus opciones, incluso cuando la aplicación se ejecute en producción a través de un proveedor de nube. Permite que los equipos que cumplen los requisitos evalúen modelos y funciones en versión preliminar y ofrece una posible ruta de recuperación para cargas de trabajo críticas. Elige 1P o 3P para producción según las capacidades del flujo de trabajo, el entorno de alojamiento y los controles, incluida la conectividad privada cuando sea necesaria.

Para las cargas de trabajo críticas, empieza con un solo paso de inferencia que sea independiente y de solo lectura. Codex puede ayudarte a implementar la política del gateway y las pruebas locales para ese paso. La validación en las rutas reales permite determinar si la ruta secundaria cumple los requisitos del flujo de trabajo. Así, el equipo cuenta con un plan de recuperación concreto que especifica cuándo cambiar de ruta, cuándo detenerse y quién toma la decisión.