ChatGPT, Claude y Grok fallaron casi a la vez: lo que se sabe y lo que no

Las principales plataformas de IA tuvieron problemas con pocas horas de diferencia el 3 de septiembre de 2026. ChatGPT y Codex, de OpenAI; los productos Claude, de Anthropic; y Grok, de xAI, registraron incidencias que afectaron a usuarios. Sin embargo, la conclusión más sólida es más limitada que decir que «se cayó toda la IA»: la información pública disponible describe incidentes distintos y con causas declaradas diferentes, no una caída común demostrada. 334148

Qué ocurrió y cuándo

Los horarios no encajan de forma perfecta porque los proveedores y los medios que siguieron las incidencias usaron actualizaciones en momentos diferentes. Aun así, las ventanas reportadas explican por qué muchos usuarios percibieron que todo fallaba a la vez.

• Grok: el registro de incidencia de xAI habría comenzado a las 13:30 UTC y finalizado a las 17:05 UTC. Posteriormente, xAI atribuyó la interrupción a una caída en su centro de cómputo de Memphis. 48
• Claude: Anthropic informó de un aumento de errores en solicitudes a través de modelos y productos de Claude, incluidos Claude.ai, su API, Claude Code y Claude Cowork. La incidencia quedó resuelta a las 16:16 UTC, tras cerca de tres horas de afectación. 104148
• ChatGPT y Codex: OpenAI indicó que un error interno de enrutamiento, iniciado a las 07:43 PT, dejó ChatGPT y Codex sin servicio para algunos usuarios en distintas plataformas. La solución se implementó aproximadamente a las 08:17 PT y quedó bajo supervisión. 41

Los usuarios notificaron fallos de inicio de sesión, conversaciones no disponibles, consultas que no se enviaban y problemas de acceso desde la web o las aplicaciones. Los reportes recopilados por Downdetector superaron los 43.000 para ChatGPT alrededor de las 20:00 IST, mientras que en Claude la afectación alcanzó tanto herramientas para particulares como para desarrolladores. 2339

Las causas comunicadas por cada proveedor

Las explicaciones divulgadas son importantes porque desaconsejan presentar el episodio como una única caída confirmada.

OpenAI: un portavoz de la compañía describió la interrupción de ChatGPT y Codex como un error de enrutamiento dentro de la infraestructura de OpenAI. 41

Anthropic: su información pública de estado calificó el problema de Claude como una incidencia de infraestructura y confirmó errores elevados en varios modelos y servicios. El material disponible no identifica qué componente concreto falló. 3948

xAI: la cobertura posterior indicó que xAI vinculó la caída de Grok con su centro de cómputo de Memphis y pidió disculpas a los socios de cómputo afectados. 48

Estas explicaciones no descartan por completo que existiera alguna dependencia compartida, pero tampoco establecen una causa raíz común.

¿Fue Azure u otro proveedor compartido el responsable?

No. La evidencia pública aportada no confirma que Microsoft Azure, un proveedor de red, una CDN, un servicio de identidad u otro suministrador común provocara todas las incidencias del 3 de septiembre.

La cobertura de ese momento señaló a Azure como un posible punto de interés porque presta servicios cloud a las compañías involucradas, pero eso no prueba causalidad. 42 Que varios problemas coincidan en el tiempo puede ocurrir cuando sistemas independientes fallan por separado, especialmente si las incidencias se miden a través de avisos de usuarios y no mediante un único registro técnico compartido.

Por tanto, el veredicto adecuado es claro: la hipótesis de una causa en infraestructura compartida no está confirmada. No debe tratarse como un hecho la afirmación de que un fallo regional de Azure causó todos los incidentes, salvo que los proveedores publiquen una confirmación directa o un informe técnico posterior.

¿El supuesto acceso de Anthropic a Colossus 1 explica la caída de Claude?

La información disponible no basta para establecer ni el alcance de un eventual acceso de Anthropic a la instalación Colossus 1 de xAI/SpaceXAI ni si la ruta de servicio de Claude dependía de esa capacidad en el momento de la incidencia. Que un fallo en Memphis afectara a Grok no demuestra, por sí solo, que causara la interrupción de Claude. 48

La distinción es relevante para analizar la fiabilidad: incluso si se verificara un acuerdo comercial de capacidad de cómputo, eso no demostraría que un servicio orientado al usuario estuviera ejecutándose sobre esa infraestructura justo cuando falló.

Qué se sabía de los nuevos reportes de ChatGPT en India el 7 de septiembre

El 7 de septiembre se publicaron reportes separados sobre problemas en ChatGPT concentrados principalmente en la generación de contenido; algunos usuarios también notificaron fallos en el navegador y la aplicación. Uno de esos informes contabilizó unas 261 notificaciones de usuarios y señaló que la generación de contenido concentraba la mayor parte de las quejas. 19

Eso no demostraba una caída sostenida en toda India, una causa raíz confirmada ni una relación con lo ocurrido el 3 de septiembre. Un monitor externo indicó que ChatGPT era accesible sin errores inusuales a las 03:07 UTC de ese día, algo compatible con un problema parcial, intermitente o desigual según la zona, pero no con la prueba de una interrupción nacional continua. 22

La lección para las empresas: varios proveedores no equivalen automáticamente a resiliencia

Las incidencias del 3 de septiembre muestran con qué rapidez puede interrumpirse el trabajo que depende de IA: atención al cliente, desarrollo de software, investigación, procesamiento documental o flujos de agentes. Contratar varios servicios de IA ayuda ante un fallo de un proveedor concreto, pero no garantiza continuidad si comparten capas de infraestructura o si los usuarios dependen de los mismos navegadores, sistemas de identidad, redes e integraciones.

Un flujo de trabajo más resiliente debería contemplar:

• Alternativas manuales y colas persistentes: el trabajo crítico debe poder recuperarse, en vez de desaparecer cuando una solicitud falla.
• Conmutación entre proveedores: las tareas aptas pueden dirigirse a otro proveedor de modelos, entendiendo que aún pueden producirse fallos correlacionados.
• Gestión defensiva de API: aplicar tiempos de espera limitados, reintentos con espera progresiva, disyuntores de circuito y trabajos idempotentes para evitar duplicados durante una interrupción temporal.
• Un modo degradado de operación: definir qué puede continuar sin un modelo de IA avanzado, por ejemplo, reglas de enrutamiento, respuestas en caché, entregas diferidas o revisión humana.
• Monitorización independiente y registros de incidencias: seguir las páginas de estado de los proveedores junto con comprobaciones propias y conservar registros que indiquen qué proveedor, modelo e integración fallaron.

La idea central no es que toda caída simultánea esconda una causa común. Es que las empresas deben prepararse para esa posibilidad y comprobar que sus planes de contingencia funcionan antes de la próxima interrupción.