Vercel AI Gateway estrena routing rules: el cambio útil es migrar modelos sin redeploy

Vercel publicó el 2 de julio de 2026 una mejora pequeña en superficie y grande en operación: routing rules para AI Gateway. La idea es que el equipo pueda reescribir una solicitud de un modelo hacia otro, o bloquear un modelo, desde el gateway y no desde cada aplicación.

Para un chatbot simple, eso suena cómodo. Para un agente, es más serio. Los agentes suelen correr loops, reintentos, herramientas, colas y tareas en paralelo. Si el modelo que usan se cae, cambia de precio o queda fuera de una política interna, esperar a que alguien haga redeploy puede ser demasiado lento.

Qué cambia frente al ruteo en código

Hasta ahora, muchos equipos resolvían cambios de modelo con lógica dentro de la app: un if, una variable de entorno, un fallback en el SDK o una lista de proveedores. Eso funciona hasta que tienes varias apps, varios agentes y varias llaves.

Vercel lo plantea como reglas tipo firewall para modelos. Hay dos acciones:

• Rewrite: la app pide un modelo, pero AI Gateway sirve otro.
• Deny: la solicitud a un modelo queda bloqueada y devuelve error.

La diferencia práctica es el lugar donde vive el control. Si la regla vive en el gateway, cada request con credenciales del equipo queda cubierto. Eso incluye agentes internos, demos, scripts de evaluación y apps que todavía no han sido redeplegadas.

El caso más fuerte: modelo retirado o degradado

La señal de demanda aquí no viene de volumen SEO inventado. Viene de una realidad operativa visible en los changelogs: los modelos aparecen, cambian, se retiran y se reemplazan cada pocas semanas.

Cuando un proveedor anuncia una deprecación, el equipo tiene dos trabajos distintos:

1. migrar rápido para no romper producción;
2. medir con calma si el reemplazo realmente mantiene calidad, costo y latencia.

Las routing rules separan esas dos urgencias. Puedes reescribir tráfico de un modelo retirado hacia un candidato seguro para mantener continuidad, mientras preparas una evaluación más formal.

Dónde lo usaría primero

El primer uso sano no es optimizar cada request. Es cubrir incidentes y políticas obvias:

• bloquear modelos que legal o seguridad no aprobó;
• mover tráfico fuera de un modelo con errores de disponibilidad;
• estandarizar equipos que todavía llaman IDs viejos;
• degradar tareas de bajo riesgo hacia un modelo más barato;
• crear una ventana de migración antes de limpiar código.

Lo que no conviene delegar al gateway

Una routing rule no decide si tu agente resolvió bien la tarea. Tampoco reemplaza evals, trazas ni revisión humana. Si reescribes un modelo caro hacia uno barato sin medir, puedes bajar costo y subir retrabajo al mismo tiempo.

También hay un detalle de gobernanza: Vercel dice que el resto de configuración sigue aplicando, incluyendo BYOK, fallbacks por request, only, provider options, Zero Data Retention y provider allowlist. Eso es bueno, pero obliga a documentar el orden mental de las reglas. Si nadie entiende qué capa manda, el gateway se vuelve una caja negra.

Checklist para builders

Antes de activar routing rules en un agente real, revisaría esto:

• qué modelos están hardcodeados en apps, colas y scripts;
• qué tareas pueden tolerar degradación de modelo;
• qué modelos están prohibidos por política interna;
• qué métricas definen una migración exitosa;
• cómo se avisará al equipo cuando una regla cambie producción;
• quién puede crear, editar o borrar reglas.

La conclusión corta: routing rules convierte AI Gateway en una capa de cambio operativo, no solo en un proxy de modelos. Para equipos que ya tienen varios agentes, eso vale porque separa respuesta rápida de despliegue de código.

Si todavía estás ordenando la base de tools, permisos y evaluación, empieza por el curso gratis. Si ya operas varios modelos, esta noticia conversa bien con Provider Allowlist en Vercel AI Gateway: una pieza decide qué proveedores pueden existir; la otra decide cómo mover tráfico cuando producción cambia.