Problema
Cuando varios equipos usan IA en paralelo, elegir modelo por intuición 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 decisión improvisada.
Tesis
El model routing deja de ser optimización técnica cuando asigna riesgo, coste y contexto por política. La ventaja no esta en “acertar el mejor modelo”, sino en que la elección sea repetible y explicable.
Framework
Definición: una routing policy decide que modelo puede tocar cada caso según 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 económico y riesgo reputacional.
Señal 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 típico es dejar libertad total “para experimentar”. Eso produce dashboards bonitos y una operación imposible de comparar. Si cada equipo cambia de modelo cuando algo falla, nunca sabes que política funciona.
Pilar operativo
Esta decisión conecta de forma directa con Context Architecture. El routing no vive solo en la elección del modelo; vive en como contexto, riesgo, fallback y ownership quedan codificados para que el sistema responda igual bajo presión. Cuando una empresa documenta tiers, excepciones y reglas de override, deja de tener una colección de prompts sueltos y empieza a tener arquitectura operativa. El routing gobernado no busca acertar el modelo perfecto cada semana. Busca que la elección del modelo sea auditable, repetible y compatible con el resto del stack.
Next action
Si hoy cada equipo elige modelo por sensación 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 diagnóstico.