Deje de buscar el mejor modelo. La guía de GPT-6 de OpenAI defiende enrutar por tarea

Muchos programas de IA empresarial siguen apoyados en una decisión tomada al principio: “nosotros usamos el modelo X”. Tenía sentido cuando un modelo iba claramente por delante y las diferencias de precio eran pequeñas. Tiene menos sentido ahora que un mismo proveedor ofrece una familia de modelos con fortalezas distintas, razonamiento ajustable y velocidad de pago, y un solo flujo agéntico llama al modelo decenas de veces para trabajos muy diferentes.

La guía de OpenAI para la familia GPT-6, publicada el 2 de octubre, parece un manual de producto. Lo que interesa a quien opera IA en producción es la arquitectura que hay debajo.

Qué dice la guía

OpenAI plantea la elección de modelo y de nivel de razonamiento como un equilibrio entre inteligencia y precio, y asigna tres modelos a tres tipos de trabajo:

• GPT-6 Astra para el razonamiento más difícil, cuando hace falta el máximo de inteligencia.
• GPT-6.1 Sol para código complejo, investigación y computer use. Además admite flujos multiagente en la Responses API, todavía en beta.
• GPT-6 Luna para tareas acotadas y repetidas a escala, con un objetivo claro, como extraer campos de facturas, clasificar solicitudes o generar resúmenes estructurados.

Sobre el modelo se elige un esfuerzo de razonamiento: bajo para extracciones rutinarias o pequeñas ediciones, medio para trabajo que exige criterio, alto para depuración difícil o revisión cuidadosa, y extra alto o máximo solo cuando el alto se queda corto y la mejora compensa el tiempo y el coste. En la API, el esfuerzo puede cambiar a mitad de conversación sin romper la caché.

Después, la velocidad: el modo Fast ofrece respuestas más rápidas y estables a un precio por token mayor, y Ultrafast, disponible para GPT-6 Astra, acelera la generación con un recargo.

La parte de producción es la más práctica. Recorte el contexto que la tarea no necesita. Ejecute en paralelo las tareas independientes. Ponga primero las instrucciones estables y el material de referencia para que funcione la caché de prompts; según OpenAI, los tokens de entrada en caché cuestan hasta un 95% menos, según el modelo, y la estimación de coste debe incluir la escritura de caché y las tarifas de contexto largo. Use la compactación en conversaciones largas. Y antes del despliegue, ejecute tareas representativas y mida la tasa de éxito, la latencia y el coste por tarea resuelta.

La lección de arquitectura: enrutar por paso, no por proveedor

Si se juntan las piezas, la unidad de diseño deja de ser “el modelo” y pasa a ser el paso:

1. Clasificar la solicitud
2. Extraer los campos
3. Planificar o comparar
4. Revisar el caso de riesgo
5. Redactar la respuesta

Modelo pequeño, esfuerzo bajoModelo medio, esfuerzo medio

Eso tiene cuatro consecuencias.

El enrutamiento se convierte en un componente. Alguien tiene que decidir, paso a paso, qué modelo, qué esfuerzo y qué velocidad, y revisar la decisión cuando cambian precios y modelos. Esa lógica vive en un gateway o en la capa de orquestación, no repartida por los prompts. En nuestro análisis del C1 LLM Gateway describimos el gateway como un punto de aplicación de políticas; enrutar por tarea es una de ellas.

La ruta la decide la evaluación, no la reputación. “Use el mejor modelo” es una suposición. “Use la ruta más barata que supera el conjunto de evaluación de este paso” es una decisión que se puede defender ante finanzas y ante un auditor. Además le da el conjunto de regresión que necesitará cuando se retire un modelo, el problema que tratamos en nuestro artículo sobre la retirada de modelos.

La latencia es un presupuesto, no un detalle. Un paso de atención al cliente puede tener un objetivo de dos segundos; una conciliación nocturna tiene horas. Pagar Fast o Ultrafast solo tiene sentido donde existe un objetivo de latencia.

El contexto es una partida de coste. La caché y la compactación no son optimizaciones para más adelante. La estructura del prompt (lo estable primero, lo variable al final) decide si la caché funciona, y la caché decide si un flujo de gran volumen es asumible. En Latinoamérica, donde la API se paga en dólares y el presupuesto se cierra en pesos, esa diferencia de precio de entrada se nota todavía más cuando se mueve el tipo de cambio.

Lo que no ha cambiado

La guía es explícita en algo fácil de pasar por alto: definir qué acciones puede tomar el modelo por su cuenta y cuáles requieren aprobación, sustituyendo reglas genéricas de “pregunta siempre” por límites claros. El enrutamiento optimiza coste y calidad; no resuelve quién tiene autoridad. Un modelo más barato en un paso que puede enviar un correo o modificar un registro necesita los mismos controles que uno caro. En España, además, esos límites son parte de lo que el RGPD exige demostrar cuando hay datos personales en juego.

También es una guía de un solo proveedor. La misma lógica vale entre proveedores, y una capa de enrutamiento neutral mantiene esa puerta abierta. Para las organizaciones que han estandarizado en Microsoft, el patrón se aplica igual a los modelos desplegados en Microsoft Foundry: ruta por paso, conjunto de evaluación y coste por tarea, sean cuales sean los modelos que haya detrás.

Qué hacer ahora

1. Divida cada flujo en producción en pasos y anote, para cada uno, el nivel de calidad, el objetivo de latencia y el coste aceptable.
2. Construya un conjunto pequeño de evaluación por paso, no por aplicación.
3. Mida el coste por tarea resuelta, incluidos reintentos, escrituras de caché y tiempo de corrección humana, no el coste por token.
4. Lleve el nombre del modelo a la configuración de enrutamiento, para que un cambio sea una versión de configuración con evidencia de pruebas y no un cambio de código.
5. Revise la estructura de los prompts pensando en la caché: instrucciones y referencias estables primero, detalles de la tarea al final.
6. Separe autoridad y enrutamiento: la regla de aprobación acompaña a la acción, no al modelo.

En resumen

La pregunta “¿en qué modelo estandarizamos?” está dejando paso a “¿qué ruta merece cada paso?”. Es una pregunta mejor, porque se responde con evidencia y se puede revisar cada vez que cambian precios o modelos. Los equipos que la respondan paso a paso, con evaluaciones y con la métrica de coste por acierto, gastarán menos y romperán menos.