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 está 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 más 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 común
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 más capacidad. Es mapear que decisiones merecen routing gobernado y cuales no.
Relacionado
- 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.
Relacionado
- Gemini 3.5 Flash: cuando la latencia deja de ser técnica y se vuelve estrategia — Gemini 3.5 Flash convierte velocidad, coste y acción en variables de operating model. La latencia ya no es solo rendimiento….
- AI Governance Backlog: convertir riesgo en trabajo ejecutable — La gobernanza de IA falla cuando vive como política abstracta. Un governance backlog convierte riesgos, controles y decisiones en….
- Proyecto de Ley de IA en España 2026: la multa no es el problema, el inventario sí — El Proyecto de Ley de IA en España convierte el compliance en operación: inventario, owners, supervisión humana, evidencias y….