Blog Tecnología

Caída de ChatGPT, Claude y Gemini a la vez: plan B para tu empresa

7 sep 2026 7 min de lectura Por Miguel Ángel Jiménez · Mediacore

El jueves 3 de septiembre de 2026 muchas empresas descubrieron de golpe cuánto dependen de la inteligencia artificial. En cuestión de horas, ChatGPT, Claude, Gemini, Grok y Copilot sufrieron interrupciones casi simultáneas en más de 70 países. Mensajes que no cargaban, respuestas que nunca llegaban, plataformas inaccesibles. No fue un proveedor con un mal día: fueron los cinco grandes, en una ventana muy estrecha, y además el mismo día del lanzamiento de GPT-6 Astra.

Para un directivo de pyme lo relevante no es la causa técnica, sino lo que se paró. Estos son ejemplos del tipo de procesos que se quedaron a medias ese día en empresas de todos los tamaños:

  • Atención al cliente automatizada: chatbots web y de WhatsApp que dejaron de responder o devolvieron errores genéricos a clientes que esperaban una respuesta.
  • Generación de presupuestos: flujos que redactan ofertas a partir de un formulario y que se quedaron en cola sin salida durante horas.
  • Agentes de ventas: cualificación de leads y seguimientos por email interrumpidos a mitad de conversación.
  • Informes y reporting: resúmenes diarios y cuadros de mando que no se generaron o llegaron vacíos a la bandeja del director.

La mayoría de los servicios se recuperó en unas horas. Pero el mensaje quedó claro: la disponibilidad de la IA ha dejado de ser un problema de un proveedor concreto y se ha convertido en un riesgo sistémico. Quien tenía un plan de contingencia lo notó mucho menos. Quien no, perdió una mañana y, en algunos casos, clientes.

Por qué esto va a volver a pasar

Las páginas de estado de cada compañía no señalaron una causa común. Técnicamente fueron incidentes independientes. Pero ocurrieron en una ventana tan estrecha que los expertos apuntan a un factor compartido: la infraestructura sobre la que corren todos. En el mismo periodo se dispararon los reportes de fallos en Microsoft Azure, y no es ningún secreto que los grandes modelos se ejecutan sobre un puñado de nubes y centros de datos que comparten proveedores de red, energía y hardware.

Hay tres razones para asumir que una caída de ChatGPT, Claude o Gemini se repetirá, y que volverá a ser en cadena:

  1. Concentración de infraestructura. Cinco compañías de IA no son cinco cadenas de suministro distintas. Detrás hay tres nubes, dos o tres fabricantes de chips y una lista corta de operadores de red. Un fallo en la capa de abajo arrastra a varias marcas de arriba.
  2. Dependencia de muy pocos proveedores. La mayoría de las pymes que han automatizado con IA lo han hecho sobre una única API, normalmente la primera que probaron. No hay redundancia porque nadie la pidió al montar el proceso.
  3. Agentes always-on. Desde finales de agosto muchas herramientas activan agentes por defecto. Como explicamos en nuestro análisis de los agentes always-on, eso significa que hay más procesos de negocio en producción dependiendo de la IA que en ningún otro momento. Cuando el modelo se cae ya no se cae una herramienta: se cae una parte de la operativa.

La pregunta no es si habrá otra caída. Es cuánto te costará a ti la próxima.

Autodiagnóstico: ¿cuánto depende tu negocio de un único proveedor de IA?

Antes de gastar un euro en resiliencia conviene saber en qué punto estás. Esta tabla resume tres niveles de riesgo y los síntomas que los delatan. Sé honesto: la mayoría de las pymes que auditamos se sitúan en el nivel medio creyendo que están en el bajo.

Nivel de riesgoQué significaSíntomas habituales
BajoLa IA es una ayuda, no una pieza del procesoSe usa para redactar, resumir o investigar. Si falla, alguien lo hace a mano y el cliente no lo nota.
MedioLa IA está dentro de procesos que tocan al cliente, pero existe alternativa manualChatbot de primera línea, generación de presupuestos, clasificación de tickets. Si falla, se acumula trabajo y se alargan los tiempos de respuesta.
AltoLa IA decide o ejecuta sin humano en el bucleAgentes que responden, cobran, agendan o aprueban de forma autónoma. Un único proveedor. Nadie sabe qué pasa si la API devuelve error.

Si tienes tres o más procesos en el nivel alto y todos usan el mismo proveedor, tu plan de contingencia de IA no es opcional: es urgente.

Plan B en 6 capas

Un plan de contingencia de IA no consiste en contratar dos ChatGPT. Consiste en diseñar la automatización para que degrade con elegancia. Estas son las seis capas que aplicamos en Mediacore, ordenadas de la más barata a la más técnica.

1. Inventario de procesos críticos con IA

Una hoja de cálculo basta. Columnas: proceso, proveedor de IA, qué ocurre si falla, quién lo asume, impacto en euros por hora. Este ejercicio de dos horas suele ser el más revelador de todo el plan: aparecen automatizaciones que nadie recordaba y dependencias que nadie había documentado.

2. Arquitectura multi-modelo con fallback automático

Es el corazón técnico. En lugar de que tu sistema llame directamente a OpenAI, llama a una capa intermedia que decide a qué modelo enviar cada petición. Si OpenAI no responde en unos segundos, la misma petición va a Anthropic; si tampoco, a Google. El cliente no percibe nada. Estándares como el Model Context Protocol (MCP) facilitan mucho este trabajo, porque desacoplan tus herramientas y tus datos del modelo concreto que los consume.

3. Modos degradados

Qué hace el sistema cuando no hay ningún modelo disponible. Hay tres respuestas válidas según el proceso: encolar (la petición espera y se procesa cuando vuelva el servicio), respuesta estándar (un mensaje predefinido que informa y ofrece una vía alternativa) o humano (la conversación salta a una persona con todo el contexto). Lo inaceptable es la cuarta opción, que es la más frecuente: el silencio.

4. Alertas y monitorización de status pages

Todos los proveedores publican páginas de estado. Suscríbete a ellas y conéctalas a tu canal de Slack o Teams. Añade una alerta propia cuando la tasa de errores de la API supere un umbral. El 3 de septiembre muchas empresas se enteraron del problema por las quejas de los clientes, no por sus sistemas.

5. Datos y prompts fuera del proveedor

Tus prompts, tus instrucciones de sistema, tus ejemplos y tu histórico de conversaciones deben vivir en tu repositorio o tu base de datos, no dentro del panel de un proveedor. Es lo que hace posible cambiar de modelo en minutos en lugar de en semanas. La portabilidad no es un lujo técnico: es la diferencia entre un incidente y una crisis.

6. Runbook de incidentes de una página

Un documento que cualquiera del equipo pueda seguir a las nueve de la mañana sin llamar a nadie: cómo saber que la IA se ha caído, qué mensaje se publica, quién asume qué proceso, cómo se activa el fallback manual si el automático no basta y cómo se comunica la vuelta a la normalidad. Una página. Si ocupa más, nadie lo leerá durante la caída.

Qué procesos nunca deben depender de un único modelo

Hay áreas en las que la redundancia no se discute. Si alguno de estos procesos corre hoy sobre un solo proveedor, sin humano ni fallback, es tu primera prioridad:

  • Cobros y facturación. Cualquier paso que mueva dinero, emita una factura o modifique un pedido.
  • Atención 24/7 comprometida por SLA. Si has firmado tiempos de respuesta con un cliente, tu cumplimiento no puede depender de la página de estado de un tercero.
  • Seguridad y control de accesos. Verificaciones de identidad, detección de fraude, aprobaciones de acceso a sistemas.
  • Decisiones irreversibles. Cancelaciones, envíos, comunicaciones masivas, borrado de datos. Aquí la regla es doble: multi-modelo y confirmación humana.

Para el resto (redacción, clasificación interna, resúmenes, informes) un modo degradado bien diseñado suele ser suficiente y bastante más barato.

Coste real de la resiliencia

La objeción habitual es el coste. Las cifras de esta tabla son orientativas para una pyme con entre tres y ocho automatizaciones en producción y un volumen medio de peticiones; sirven para dimensionar la decisión, no como presupuesto cerrado.

ConceptoUn solo proveedorMulti-modelo con fallback
Coste extra mensual0 €40-150 € (capa de abstracción, monitorización y consumo del modelo secundario, que solo se paga cuando se usa)
Horas de implantación0 h12-30 h la primera vez; después, cada automatización nueva nace ya con fallback
Tiempo de recuperaciónEl que tarde el proveedor: de minutos a varias horasSegundos (fallback automático) o el tiempo de activar el modo degradado
Impacto en el clienteVisible: errores, silencios, esperasImperceptible o comunicado de forma controlada
Coste de una caída de 3 horasLeads sin atender, presupuestos sin enviar, horas de equipo apagando fuegosPrácticamente nulo

Haz la cuenta con tus datos: número de conversaciones o presupuestos por hora multiplicado por su valor medio. En la mayoría de los casos una sola caída como la del 3 de septiembre cuesta más que un año entero de resiliencia.

Que la próxima caída no sea tu problema

Lo ocurrido el 3 de septiembre no es un argumento contra la IA. Es un argumento contra la IA mal integrada. Las empresas que habían diseñado sus automatizaciones con redundancia siguieron trabajando con normalidad; las que dependían de un único modelo se enteraron por sus clientes.

En Mediacore diseñamos automatizaciones que no se caen cuando se cae la IA: arquitectura multi-modelo, fallbacks y modos degradados desde el día uno. Si no sabes en qué nivel de riesgo está tu negocio o quieres revisar lo que ya tienes en producción, solicita una auditoría gratuita de tus automatizaciones. Te diremos qué se pararía mañana si vuelve a ocurrir y cuánto cuesta evitarlo.

Preguntas frecuentes
¿Qué pasó exactamente el 3 de septiembre de 2026 con ChatGPT, Claude y Gemini?

El 3 de septiembre de 2026 ChatGPT, Claude, Gemini, Grok y Copilot sufrieron interrupciones casi simultáneas en más de 70 países. Los usuarios veían mensajes que no cargaban, respuestas que no llegaban y plataformas inaccesibles. Coincidió con el día de lanzamiento de GPT-6 Astra. La mayoría de los servicios se recuperó en unas horas, pero durante ese tiempo se pararon chatbots de atención al cliente, generadores de presupuestos, agentes de ventas e informes automáticos en miles de empresas que dependían de estas APIs en producción.

¿Por qué se cayeron todos los modelos de IA a la vez si son empresas distintas?

Las páginas de estado no señalaron una causa común y, técnicamente, los incidentes fueron independientes. Sin embargo, ocurrieron en una ventana tan estrecha que los expertos apuntan a la infraestructura compartida: en el mismo periodo aumentaron los reportes de fallos en Microsoft Azure. Los grandes modelos se ejecutan sobre un puñado de nubes, fabricantes de chips y operadores de red. Cuando falla una capa inferior, arrastra a varias marcas a la vez. Por eso la disponibilidad de la IA se ha convertido en un riesgo sistémico y no solo por proveedor.

¿Cómo sé si mi empresa está en riesgo por depender de un único proveedor de IA?

Haz un inventario de todos los procesos donde interviene la IA y responde tres preguntas por cada uno: ¿toca al cliente?, ¿hay un humano en el bucle?, ¿qué pasa si la API devuelve error? Si la IA solo te ayuda a redactar o resumir, el riesgo es bajo. Si está dentro de procesos que tocan al cliente pero existe alternativa manual, es medio. Si la IA decide o ejecuta de forma autónoma (responde, cobra, agenda, aprueba) sobre un único proveedor y nadie sabe qué ocurre si falla, estás en riesgo alto y necesitas un plan de contingencia cuanto antes.

¿Qué es una arquitectura multi-modelo con fallback?

Es una forma de diseñar tus automatizaciones para que no dependan de un único modelo de IA. En lugar de llamar directamente a la API de OpenAI, Anthropic o Google, tu sistema llama a una capa intermedia de abstracción que decide a qué proveedor enviar cada petición. Si el modelo principal no responde en unos segundos, la misma petición se redirige automáticamente al secundario, y si este también falla, al tercero. El cliente no percibe nada. Estándares como el Model Context Protocol (MCP) facilitan este enfoque porque desacoplan tus datos y herramientas del modelo concreto que los usa.

¿Cuánto cuesta hacer que mis automatizaciones con IA sean resilientes?

Para una pyme con entre tres y ocho automatizaciones en producción, el sobrecoste orientativo de una arquitectura multi-modelo con fallback está entre 40 y 150 euros al mes, que cubre la capa de abstracción, la monitorización y el consumo del modelo secundario, que solo se paga cuando se activa. La implantación inicial supone entre 12 y 30 horas de trabajo; después, cada nueva automatización nace ya con fallback. Comparado con lo que cuesta una única caída de tres horas en leads sin atender y presupuestos sin enviar, la resiliencia suele amortizarse con el primer incidente.

¿Qué debo hacer durante una caída de ChatGPT u otro proveedor de IA?

Primero, confirma el alcance en la página de estado del proveedor y en tus propias alertas de errores. Segundo, activa el modo degradado previsto para cada proceso: encolar peticiones, publicar una respuesta estándar que informe al cliente y ofrezca una vía alternativa, o derivar las conversaciones a una persona con el contexto completo. Tercero, si tienes fallback automático, verifica que ha conmutado al modelo secundario. Cuarto, comunica internamente quién asume qué. Todo esto debería estar en un runbook de una página que cualquiera del equipo pueda seguir sin llamar a nadie.

Conoce Mediacore Consulting

Te ayudamos a identificar dónde la IA puede aportar más valor a tu negocio.

Conoce Mediacore Consulting
¿Hablamos?
WhatsApp Auditoría gratis