Problema
Cuando varios equipos usan IA en paralelo, elegir modelo por intuicion genera drift. Un flujo sale bien con un modelo barato, otro se rompe con el mismo, y nadie sabe si el error vino del modelo, del contexto o de una decision improvisada.
Tesis
El model routing deja de ser optimizacion tecnica cuando asigna riesgo, coste y contexto por politica. La ventaja no esta en “acertar el mejor modelo”, sino en que la eleccion sea repetible y explicable.
Framework
Definicion: una routing policy decide que modelo puede tocar cada caso segun criticidad, latencia, reversibilidad y coste por error.
Mini-caso: un equipo de soporte usa un modelo barato para clasificar tickets y otro de mayor calidad para redactar respuestas en casos VIP. El cambio no se decide por preferencias del prompt engineer, sino por impacto economico y riesgo reputacional.
Senal medible: si mas del 15% de incidentes se resuelven cambiando de modelo a mano, no tienes routing; tienes arbitraje informal.
Protocolo (3 pasos)
- Lista las 3 decisiones donde un error de modelo tiene coste real y define el umbral de riesgo aceptable.
- Asigna un modelo por tier con criterios escritos para coste, latencia y fallback humano.
- Revisa semanalmente overrides manuales, rework y coste por outcome para ajustar la policy.
Error comun
El anti-ejemplo tipico es dejar libertad total “para experimentar”. Eso produce dashboards bonitos y una operacion imposible de comparar. Si cada equipo cambia de modelo cuando algo falla, nunca sabes que politica funciona.
Pilar operativo
Esta decision conecta de forma directa con Context Architecture. El routing no vive solo en la eleccion del modelo; vive en como contexto, riesgo, fallback y ownership quedan codificados para que el sistema responda igual bajo presion. Cuando una empresa documenta tiers, excepciones y reglas de override, deja de tener una coleccion de prompts sueltos y empieza a tener arquitectura operativa. El routing gobernado no busca acertar el modelo perfecto cada semana. Busca que la eleccion del modelo sea auditable, repetible y compatible con el resto del stack.
Next action
Si hoy cada equipo elige modelo por sensacion y no por policy, lo primero no es comprar mas capacidad. Es mapear que decisiones merecen routing gobernado y cuales no.
Related
- AI Operating Models en 2026: los 5 patrones que si escalan
- Data Contracts para equipos de IA: sin ellos no hay escala
Si quieres bajar esta policy a casos reales, abre un diagnostico.