Cómo evitar que tu agente se caiga cuando falla un modelo de IA

Tu app promete responder a clientes, pero el modelo principal devuelve un error justo cuando alguien termina un formulario. Un segundo proveedor puede salvar la petición, siempre que no cambie silenciosamente la calidad, el costo o el formato de salida. Vercel AI Gateway permite declarar modelos de respaldo en orden; la decisión útil no es activar el fallback, sino definir qué comportamiento tolera tu producto.

La documentación oficial de Vercel, actualizada el 2 de octubre de 2026, indica que providerOptions.gateway.models contiene los modelos de respaldo. El gateway prueba primero el modelo principal y, si fallan sus proveedores, pasa al siguiente. Esta guía se basa en esa documentación consultada el 25 de octubre; no afirmamos haber provocado una caída real en una cuenta de producción.

Un caso concreto: respuestas de soporte

Imagina un agente que redacta una primera respuesta a tickets en español. Su salida debe contener tres campos: resumen, respuesta sugerida y si debe escalar a un humano. Si cambias de modelo en un fallo, esos campos deben seguir presentes. Antes de configurar nada, define el contrato: nunca enviar automáticamente una respuesta si falta la bandera de escalamiento; mostrar un mensaje de espera si todos los modelos fallan; registrar qué modelo respondió.

No elijas el modelo de respaldo solo por su nombre. Comprueba que acepta la modalidad que usas —texto, herramientas o archivos—, que tiene acceso en tu cuenta y que su costo máximo cabe en el presupuesto. Un respaldo más caro puede ser correcto para tickets críticos, pero mala elección para miles de resúmenes de baja prioridad.

Configuración mínima con AI SDK

La documentación de Vercel muestra este patrón con AI SDK 7. Sustituye los IDs por modelos que estén disponibles en tu catálogo y prueba con tu propia clave AI_GATEWAY_API_KEY. El siguiente ejemplo ilustra la estructura, no una ejecución medida por SoyJB:

import { generateText } from 'ai';

const result = await generateText({
  model: 'anthropic/claude-fable-5',
  prompt: 'Resume este ticket en dos frases: no llega el correo de acceso.',
  providerOptions: {
    gateway: {
      models: [
        'anthropic/claude-opus-5',
        'google/gemini-3.1-pro-preview',
      ],
    },
  },
});

console.log(result.text);

El valor de models es una lista ordenada de respaldos, no un conjunto para votar ni para comparar calidad. Según Vercel, el gateway intenta los proveedores del modelo principal; cuando todos fallan, pasa al primer modelo de la lista. Una respuesta exitosa detiene la cadena. Si además especificas order, ese campo controla preferencia de proveedor para cada modelo; no lo confundas con el orden entre modelos.

Haz una prueba que detecte el riesgo real

Prepara tres tickets de prueba: uno normal, uno que exige escalamiento y uno con datos insuficientes. Ejecútalos con el modelo principal y con cada respaldo de forma explícita, sin esperar a una caída. Compara si los tres campos aparecen, si el idioma se mantiene y si el agente se niega a inventar una solución. Si el respaldo falla este contrato, no debería formar parte de la cadena aunque responda más rápido.

Después prueba el fallo del servicio en un entorno de desarrollo controlado. No basta con pasar un ID inválido y llamar a eso resiliencia: ese error puede representar una configuración incorrecta, no una interrupción del proveedor. Registra código de error, modelo elegido, latencia y respuesta. Vercel documenta modelAttempts en los metadatos del proveedor y los logs del gateway para ver cada intento. Así puedes medir cuánto tráfico usó el respaldo en lugar de asumir que nunca se activó.

Define límites de producto

Un fallback puede aumentar latencia porque primero espera intentos fallidos. También puede cambiar estilo, precisión, contexto disponible o precio. Para un agente que realiza acciones, añade una confirmación humana antes de enviar mensajes, cobrar o modificar datos. Si todos los modelos fallan, responde con un estado explícito de «pendiente» y conserva el trabajo para reintento idempotente. No uses la misma operación varias veces sin una clave de idempotencia.

Decisión práctica: activa fallback para tareas donde una respuesta tardía y revisable vale más que un error inmediato. Mantén un único modelo o una cola de reintento cuando el formato, los datos o el costo no sean equivalentes entre proveedores. Revisa los logs después de la primera semana y ajusta la cadena con fallos reales, no con una promesa de “100 % uptime”.

Fuente: Vercel AI Gateway: Model Fallbacks, consultada el 25 de octubre de 2026. Disponibilidad, IDs y precios deben confirmarse en la cuenta antes de desplegar.