Un agente de IA en producción no depende solo del código que lo hace funcionar, depende también de un modelo de lenguaje que corre en los servidores de un tercero: Anthropic, OpenAI, Google o quien sea el proveedor elegido. Ese tercero puede sufrir una caída, una degradación de rendimiento o un cambio inesperado en su servicio, y cuando ocurre, tu agente se para, aunque tu propio software no tenga ningún error. Este es un tipo de fallo distinto al que tratamos en con quién hablo si algo no funciona como espero, que se centra en qué hacer cuando el problema está en tu propio agente ya implantado. Aquí hablamos específicamente de cuando el problema está un nivel más abajo: en la infraestructura del modelo que tu agente usa para pensar.
Por qué este fallo es distinto a un error de tu propio sistema
Cuando tu propio software falla, normalmente puedes diagnosticarlo, revertir un cambio reciente o contactar con quien lo mantiene y obtener un tiempo estimado de solución razonable. Cuando falla el proveedor del modelo, no tienes ese control: no puedes ver sus logs internos, no puedes acelerar su solución y, en la mayoría de los casos, ni siquiera tienes un canal de soporte directo si no eres un cliente de gran volumen. Dependes de su página de estado público y de que el problema se resuelva en su plazo, no en el tuyo.
Esto no es un motivo para desconfiar de usar IA en procesos de negocio, es un motivo para diseñar el sistema sabiendo que este tipo de interrupción, aunque infrecuente, puede pasar.
Qué tipos de fallo puede tener un proveedor de modelos
No todos los fallos son iguales ni tienen el mismo impacto. Una caída total del servicio impide cualquier llamada al modelo durante un período de tiempo, normalmente de minutos a pocas horas. Una degradación de rendimiento es más sutil: el servicio sigue respondiendo, pero mucho más lento de lo habitual, lo que puede hacer que tu agente incumpla tiempos de respuesta razonables sin llegar a estar caído del todo. Y existe un tercer tipo, menos visible pero relevante: un cambio de comportamiento del modelo tras una actualización silenciosa del proveedor, que hace que las mismas peticiones empiecen a dar resultados ligeramente distintos sin que haya habido ninguna caída formal.
Cada uno de estos tres escenarios exige una respuesta distinta, y conviene tenerlos identificados antes de que ocurran, no durante la crisis.
Cómo se nota que el problema viene del proveedor y no de tu sistema
La primera señal suele ser que las llamadas al modelo empiezan a fallar o a tardar de forma anómala sin que se haya hecho ningún cambio reciente en tu propio código, tus prompts o tu configuración. La segunda señal, más fiable, es consultar la página de estado pública del proveedor —la mayoría de los grandes proveedores de modelos la ofrecen— para confirmar si hay un incidente reportado. La tercera señal es comprobar en foros o canales de la comunidad de desarrolladores si otras empresas están reportando el mismo problema al mismo tiempo: si el fallo es generalizado y no solo tuyo, casi con seguridad viene del proveedor.
Tener este proceso de diagnóstico documentado y conocido por el equipo antes de que ocurra un incidente ahorra tiempo valioso en el momento en que realmente se necesita.
Cómo diseñar tu agente para que un fallo del proveedor no pare tu negocio
Un mecanismo de reintento con espera progresiva. Muchas caídas de proveedor son breves e intermitentes; un sistema que reintenta la llamada automáticamente tras unos segundos, en lugar de fallar a la primera, resuelve solo una parte importante de las interrupciones sin que nadie lo note.
Una respuesta de contingencia clara para el usuario final. Si un cliente hace una consulta a un chatbot y el modelo no responde, es mejor mostrar un mensaje honesto de "estamos teniendo un problema técnico, inténtalo en unos minutos o contacta por este otro canal" que dejar que la interfaz se quede colgada sin explicación.
Un proveedor alternativo para las funciones más críticas. Para los procesos de negocio donde una interrupción tiene un coste alto, tiene sentido diseñar el sistema para poder cambiar a un segundo proveedor de modelo si el principal falla. Esto añade complejidad y coste, así que solo se justifica quirúrgicamente, en los puntos donde de verdad importa.
Un canal de comunicación interna definido. Cuando ocurre una caída, el equipo que atiende a los clientes debe enterarse por un canal interno antes de que empiecen a llegar quejas, no al revés. Un simple aviso automático que compruebe la página de estado del proveedor cada pocos minutos y alerte al equipo cubre esta necesidad sin gran complejidad.
Qué NO merece la pena hacer
No tiene sentido construir una infraestructura multi-proveedor completa para cada función de tu agente si el coste de una interrupción ocasional de minutos es bajo. La redundancia total tiene un coste de mantenimiento constante, y aplicarla donde no aporta valor real es un error tan común como no aplicarla donde sí hace falta. La clave está en clasificar qué funciones de tu agente son verdaderamente críticas para el negocio y reservar la redundancia para esas, aceptando el riesgo residual en el resto.
Conclusión
Un fallo del proveedor del modelo de IA no es un fallo de tu proyecto, es una circunstancia externa con la que cualquier sistema que dependa de un servicio de terceros tiene que convivir, igual que ya conviven con caídas de proveedores de hosting o de pasarelas de pago. Lo que marca la diferencia entre una empresa que lo gestiona bien y otra que no es si el escenario se ha pensado antes de que ocurra.
En MG Solutions diseñamos los agentes de IA de nuestros clientes con mecanismos de reintento y planes de contingencia desde el primer despliegue, no como un añadido posterior. Si quieres revisar cómo está preparado el tuyo, reserva una primera reunión.