“¿Qué modelo deberíamos usar?” solía sonar como una pregunta sobre API. En un número cada vez mayor de organizaciones, se acerca más a una cuestión de adquisiciones, ingeniería de rendimiento y arquitectura.
Ese cambio responde a una evolución sencilla: ahora hay muchos modelos, ofrecidos por muchos proveedores, con diferencias sustanciales en fortalezas, precios, perfiles de latencia, opciones de implementación y condiciones contractuales. El acuerdo anunciado por Stripe para adquirir OpenRouter es una señal útil. La API única de OpenRouter abarca más de 400 modelos de más de 80 proveedores, con criterios de enrutamiento que incluyen la complejidad de la tarea, el precio, la velocidad, la fiabilidad, la latencia, el rendimiento y los costes específicos de cada proveedor.
El puesto emergente no tiene necesariamente un título nuevo. Puede abarcar la ingeniería de plataformas de IA, la arquitectura, las adquisiciones, las operaciones de inferencia o la ingeniería de producto. Pero su responsabilidad empieza a resultar reconocible: decidir qué modelo debe encargarse de cada trabajo, bajo qué restricciones, con qué alternativa de respaldo y basándose en qué pruebas.
El enrutamiento es una decisión de política disfrazada de infraestructura
Un enrutador ingenuo pregunta: “¿Qué modelo es el más barato?”. Un enrutador útil plantea una pregunta más específica: “¿Cuál es el modelo menos costoso que cumple los requisitos de calidad, latencia, fiabilidad, privacidad y operación de esta solicitud?”
Esos requisitos varían según la tarea. Un clasificador de atención al cliente puede necesitar una salida estructurada predecible y baja latencia. Una tarea de programación difícil puede justificar un modelo más lento y capaz. Una canalización de resumen de gran volumen puede favorecer un modelo más pequeño, especialmente si su calidad es adecuada después de las pruebas. Un flujo de trabajo regulado puede requerir una región concreta, una política de conservación o un acuerdo con un proveedor específico, independientemente del precio por token.
Por eso el enrutamiento debe formar parte de las revisiones de arquitectura, no solo del código de la aplicación. La ruta determina más que una factura. Puede afectar a la residencia de los datos, la exposición a interrupciones, la observabilidad, la coherencia de las respuestas, el comportamiento en el uso de herramientas y la cantidad de revisión humana necesaria posteriormente.
Las cuatro disciplinas que sustentan una función de enrutamiento seria
1. Adquisiciones: comparar el servicio completo, no el precio anunciado por token
Es fácil comparar mal los precios de los modelos. Los tokens de entrada y salida pueden tener tarifas distintas. La entrada almacenada en caché, el procesamiento por lotes, el servicio prioritario y las solicitudes de contexto largo pueden alterar el cálculo. El precio nominal de un proveedor también dice poco sobre los reintentos, los límites de tasa, el soporte, los compromisos mínimos, la salida de datos o el coste de ingeniería de cambiar de proveedor.
El responsable del enrutamiento debería mantener un inventario de modelos y proveedores con campos como:
- precios de entrada, salida, caché y procesamiento por lotes;
- límites de contexto y de salida;
- límites de tasa documentados y rendimiento observado;
- distribuciones de latencia, no solo la latencia media;
- disponibilidad y comportamiento ante tiempos de espera agotados;
- condiciones de uso de datos, conservación, residencia y contrato;
- capacidades compatibles, incluidas las llamadas a herramientas, la salida estructurada, la visión y la transmisión en tiempo real;
- opciones de respaldo y migración.
El resultado se parece más a una lista de materiales tecnológicos que a una lista de nombres de modelos. Debe revisarse cuando cambien los precios, las políticas, las versiones de los modelos o los volúmenes de negocio.
2. Ingeniería de rendimiento: medir la tarea, no la clasificación comparativa
Los benchmarks generales pueden ayudar a orientarse, pero las decisiones de enrutamiento necesitan pruebas específicas de la carga de trabajo. Un modelo que funciona bien en un benchmark público de programación puede no ser la mejor opción para los repositorios internos, las convenciones de nombres, los esquemas de herramientas o los controles de seguridad de una organización.
Construya un conjunto de evaluación representativo a partir de solicitudes reales, eliminando o controlando el material sensible. Etiquete los resultados que importan: corrección factual, JSON válido, selección correcta de herramientas, éxito de las pruebas de código, comportamiento de rechazo, necesidad de escalamiento y estilo aceptable. Después registre el coste, el tiempo hasta el primer token, la latencia total, la tasa de tiempos de espera agotados, la tasa de reintentos y la longitud de la respuesta.
No reduzca el resultado a una sola puntuación demasiado pronto. Una puntuación ponderada puede ocultar un modo de fallo grave. Por ejemplo, un modelo con una calidad media excelente, pero con llamadas a herramientas malformadas frecuentes, puede no ser adecuado para un flujo de trabajo automatizado. Un modelo más lento puede ser preferible desde el punto de vista económico si sus respuestas reducen la costosa revisión humana.
Utilice un proceso de campeón y retador: mantenga una ruta aprobada actualmente, pruebe alternativas con el mismo corpus y promueva a un retador solo cuando supere umbrales explícitos de calidad y operación. Las afirmaciones comunicadas por los proveedores deben tratarse como elementos de un plan de pruebas, no como una prueba de que un modelo tendrá un rendimiento similar en su entorno.
3. Arquitectura: hacer que la elección del modelo sea reemplazable
El enrutamiento se vuelve costoso cuando las suposiciones específicas del modelo se filtran por toda una aplicación. Un diseño resiliente separa la tarea empresarial de la llamada al proveedor.
Define un contrato interno de capacidades. Podría especificar que una operación de «clasificación» devuelva un esquema fijo, campos de confianza o abstención, un identificador del modelo y un identificador de trazabilidad. Una operación de «respuesta preliminar» podría especificar restricciones de tono, requisitos de citación y un presupuesto máximo de latencia. Después, los adaptadores del proveedor traducen ese contrato a las API individuales.
Mantén versionados los prompts, los esquemas, las definiciones de herramientas, las reglas de seguridad y las políticas de enrutamiento. Registra qué instantánea del modelo y qué proveedor atendieron cada solicitud. Conserva la información suficiente para reproducir una decisión sin retener innecesariamente contenido sensible del usuario.
Diseña las alternativas de respaldo deliberadamente. Una alternativa puede ser otro proveedor, un modelo más pequeño, un flujo de trabajo en cola o una vía de revisión humana. No debería cambiar silenciosamente el significado de la tarea. Si la salida estructurada es obligatoria, la alternativa debe admitir el mismo contrato o activar una escalada controlada.
4. Gobernanza: decidir cuándo no enrutar automáticamente
Algunas solicitudes no deberían enviarse al modelo disponible más barato —ni a ningún modelo externo—. La política de enrutamiento necesita reglas de exclusión para datos confidenciales, decisiones de alto impacto, idiomas no compatibles, contextos inusualmente largos o acciones que requieren un paso de aprobación humana.
Los equipos también deberían distinguir entre que un modelo esté técnicamente disponible y que esté aprobado para un uso concreto. Los requisitos de compras y legales pueden variar según la unidad de negocio. Un modelo puede ser excelente en una evaluación y, aun así, resultar inutilizable para un flujo de trabajo cuyos términos de gestión de datos no encajen con la organización.
Una tabla práctica de enrutamiento
Una política inicial puede ser sencilla y explícita:
| Clase de tarea | Objetivo principal | Ruta posible | Activador de escalada |
|---|---|---|---|
| Extracción de gran volumen | Esquema válido y bajo coste unitario | Modelo pequeño o mediano con validación estricta de la salida | Fallo del esquema o baja confianza |
| Análisis complejo | Calidad y gestión de evidencias | Modelo más capaz con un presupuesto de latencia mayor | Evidencia insuficiente, ambigüedad o señalamiento de una política |
| Asistencia interactiva | Rapidez percibida de la respuesta | Modelo de baja latencia, posiblemente seguido de un refinamiento | Baja confianza o solicitud del usuario de mayor profundidad |
| Flujo de trabajo sensible | Gestión de datos aprobada y auditabilidad | Proveedor aprobado por contrato o implementación controlada | Datos, acción o jurisdicción no aprobados |
La tabla exacta variará según la organización. Lo importante es que las reglas de enrutamiento sean legibles para las partes interesadas de producto, seguridad, finanzas e ingeniería, y no queden ocultas en una declaración condicional.
Qué significa esto para quienes están construyendo su carrera
Los candidatos más sólidos para este trabajo combinarán varios tipos de dominio. Entenderán lo suficiente de aprendizaje automático para razonar sobre las capacidades y la degradación; lo suficiente de ingeniería de sistemas para gestionar la latencia, los reintentos, los límites de frecuencia y los modos de fallo; lo suficiente de finanzas para modelar el coste total; y lo suficiente de compras y gobernanza para evaluar los compromisos y las restricciones de los proveedores.
También se sentirán cómodos redactando registros de decisiones. Un registro útil explica por qué se seleccionó una ruta, qué pruebas la respaldan, qué riesgos persisten y qué evento debería activar una reevaluación. Eso es más valioso que memorizar los nombres de los modelos más recientes, porque los nombres y los precios de los modelos seguirán cambiando.
Un proyecto de portafolio compacto podría demostrar esta capacidad sin requerir un sistema de producción grande. Toma una carga de trabajo, crea un conjunto de evaluación con datos confidenciales eliminados, conecta tres proveedores de modelos o modelos locales mediante una interfaz común y compara la calidad, la validez del esquema, los percentiles de latencia, las tasas de fallo y el coste mensual estimado con varios volúmenes. Añade reglas de políticas para entradas sensibles y una ruta de respaldo. Publica la metodología de prueba y sus limitaciones.
Sé preciso sobre lo que demuestra el proyecto. No demuestra que un modelo sea universalmente el mejor. Demuestra que puedes convertir un problema ambiguo de elección de modelos en una política operativa medible.
La señal profesional
El enrutamiento de modelos está adquiriendo importancia estratégica porque la inteligencia ya no es una única dependencia fija. Es una cartera de servicios con diferentes compensaciones y una economía cambiante. Los equipos que tratan esa cartera como infraestructura intercambiable pueden reducir costes, pero también pueden crear problemas ocultos de calidad, cumplimiento y fiabilidad. Los equipos que lo tratan como un compromiso permanente con un único modelo pueden perderse opciones mejores.
La disciplina emergente se sitúa entre esos extremos: lo bastante abstracta para cambiar de proveedor, lo bastante específica para preservar la calidad de la tarea y lo bastante basada en pruebas para justificar la elección. Esa es la oportunidad profesional del enrutamiento de modelos: no elegir una API una sola vez, sino construir el sistema de decisión que siga eligiendo bien.
Tom Whitfield es el editor humano responsable de AI Career Brief, donde aborda las habilidades, los puestos y las decisiones inteligentes para trabajar en la era de la IA.
