Tu proveedor de IA va a tener un mal día

Dos pequeñas noticias de esta semana dicen lo mismo. Primero: Anthropic va a retirar Claude Sonnet 4 y Opus 4 de la API el 15 de junio. Si tu código llama a esas versiones fijadas, después de esa fecha las solicitudes simplemente devuelven errores: no hay failover automático a un modelo más nuevo, la llamada sencillamente falla. Segundo: esta mañana, el Gemini de Google se cayó, sirviendo «algo salió mal» a todos los que dependen de él.

Uno es un retiro planificado, el otro una caída no planificada, pero son la misma lección apuntando en dos direcciones: el modelo debajo de tu producto es un servicio de terceros, y te va a fallar en un calendario que no controlas. Hablamos de la IA como si fuera un oráculo mágico que siempre está despierto y nunca cambia. Ahora es infraestructura, y la infraestructura tiene malos días. La pregunta es si la tuya se lleva tu producto por delante cuando los tiene.

La IA es infraestructura, y la infraestructura se cae

Esto no es raro. Un rastreador de estado registró 47 incidentes entre los principales proveedores de IA en un solo mes a finales del año pasado, con Anthropic y OpenAI cada uno con más de 180 horas de impacto total. OpenAI tuvo una caída de 34 horas en 2025. Incluso con un saludable 99.76% de disponibilidad, eso son unas 16 horas al año en que aquello sobre lo que está construido tu producto simplemente no está. Suma retiros como el del 15 de junio, donde un modelo no se cae sino que desaparece, y el panorama queda claro: depender de un único proveedor sin un plan es depender de su mejor día, para siempre.

La mayoría de los productos de IA están construidos exactamente así: un proveedor, una cadena de modelo, llamada directamente, con la suposición optimista de que siempre responde. Eso está bien en la demo. Es una bomba de tiempo en producción.

Conoce tu tipo de falla antes de reaccionar

Lo primero que enseña la ingeniería de resiliencia es que no todas las fallas son iguales, y reaccionar mal empeora las cosas. Una falla transitoria —un límite de tasa 429, un breve corte de red— se resuelve en segundos, y un reintento la arregla. Una falla persistente —una caída completa del proveedor, un modelo que devuelve basura durante veinte minutos— no se va a resolver esperando, y reintentarla solo quema dinero y tiempo para nada. Reintentar a ciegas cada error es como la mala hora de un proveedor se convierte en tu factura descontrolada. Así que las capas se apilan: reintenta la transitoria, ten un respaldo para la persistente, y dispara un cortacircuitos cuando todo se está degradando.

Las cuatro jugadas que te mantienen en pie cuando ellos se caen

No necesitas nada exótico: esto es higiene estándar de sistemas distribuidos, aplicada a la llamada al modelo:

• Reintento con backoff para errores transitorios. Los límites de tasa y los tropiezos de red son normales; un par de reintentos con retraso creciente absorbe la mayoría sin que un humano lo note.
• Un modelo o proveedor de respaldo para los persistentes. Esta es la grande, y la matemática es contundente: dos proveedores independientes con 99.3% de disponibilidad están caídos ambos a la vez solo el 0.0049% del tiempo, alrededor de un 99.995% de disponibilidad efectiva. Un segundo camino convierte una caída en una respuesta algo peor en lugar de ninguna respuesta. (Es también por lo que mantener el modelo detrás de una costura intercambiable rinde a nivel operativo, no solo estratégico.)
• Un cortacircuitos para que, cuando un proveedor está claramente caído, dejes de machacarlo, falles rápido y te recuperes limpiamente en lugar de acumular timeouts.
• Degradación elegante hacia un camino determinista. Si la función de IA se muere, no muestres un spinner para siempre: recurre a algo más tonto que aún funcione: búsqueda por palabras clave en lugar de búsqueda semántica, una respuesta basada en plantilla en lugar de una generada, un formulario simple en lugar del flujo inteligente. Dile al usuario «las funciones avanzadas están fuera de línea brevemente» y mantén el producto usable.

Esa última importa más y es la que más se salta. Una función de IA sin respaldo no-IA significa que la disponibilidad de todo tu producto queda ahora limitada por tu dependencia más frágil.

Y pon las deprecaciones en tu calendario

El retiro del 15 de junio es el modo de falla más silencioso, y atrapa a la gente que pensaba que estaba a salvo. Fijar una versión de modelo se siente responsable: congelaste el comportamiento. Pero una versión fijada es una versión que puede ser retirada, y cuando lo es, tu llamada no se degrada, se muere. Así que o le sigues la pista a los avisos de deprecación de cada modelo que fijas, o no fijes una versión de la que no estés preparado para migrar en el calendario del proveedor. Migrar suele ser un cambio de una sola línea, pero solo si te enteras antes del 15 de junio, no por tus logs de error el 16.

La conclusión

La historia emocionante sobre la IA es todo lo que puede hacer. La historia poco glamorosa, la que esta semana contó dos veces en voz baja, es que es un servicio remoto que va a estar lento, caído o ausente en momentos que no elegiste, y un producto que asume lo contrario está a una mala mañana de un incidente. Ninguna de las soluciones es ingeniosa. Reintenta los tropiezos, ten respaldo para las caídas, degrada a algo determinista y vigila el calendario de deprecaciones. Es el mismo aburrido trabajo de fiabilidad que haríamos para cualquier dependencia crítica, y el modelo ahora es exactamente eso.

Así que antes de lanzar, hazte la pregunta que la demo nunca te obliga a hacer: cuando mi proveedor tenga su mal día —y lo tendrá— ¿qué ve mi usuario? Si la respuesta es «un error y un spinner», no has construido un producto sobre IA. Has construido uno que toma prestada su disponibilidad de alguien más, y ellos no te prometieron su buen día.