El 20 de abril, ChatGPT sufrió una gran interrupción a nivel mundial.
Alrededor de las 10 a.m., hora del este de EE. UU., los informes de fallos en Down Detector comenzaron a dispararse. El pico de informes en el Reino Unido superó los 8.700, y en EE. UU., más de 1.900. Además de la interfaz principal de ChatGPT, las funciones Codex, la plataforma API y Projects también quedaron fuera de servicio. Algunos usuarios informaron que las tareas de trabajo en curso fueron eliminadas debido a la interrupción del servicio.
Hacia la 1 p.m., OpenAI implementó una corrección; alrededor de la 1:30 p.m., el servicio volvió a la normalidad. La interrupción total duró aproximadamente 3 horas.
Cómo respondió OpenAI
Durante todo el proceso, la página de estado de OpenAI mostró las siguientes declaraciones:
"Continuamos investigando los problemas con los servicios enumerados."
Y:
"Hemos implementado medidas de mitigación y estamos monitoreando la recuperación."
Sin explicación de la causa raíz, sin detalles técnicos, sin informe de revisión.
Esta no es la primera vez. En varias interrupciones importantes de ChatGPT en el pasado, OpenAI no ha proporcionado análisis detallados posteriores al fallo como lo hacen AWS o Google Cloud – esos informes aclararían: qué componente falló, por qué afectó a tantos usuarios y cómo prevenirlo la próxima vez. OpenAI siempre proporciona la información mínima.
Qué significan estas 3 horas para las empresas
3 horas pueden sonar poco, pero para los equipos que ya han integrado la IA en sus flujos de trabajo, el impacto es concreto:
- Las tareas de Codex en ejecución se interrumpieron, perdiendo el progreso
- Las funciones de los productos conectados a la API de OpenAI quedaron completamente inoperativas
- Los equipos que usan ChatGPT para procesar solicitudes de clientes en tiempo real se detuvieron por completo
- Algunos usuarios perdieron contenido de trabajo que fue eliminado por el sistema debido a la falla
Antes de que las empresas tomen en serio la confiabilidad de la infraestructura de IA, el costo de estos incidentes seguirá siendo subestimado.
Por qué los servicios de IA son más propensos a problemas que el SaaS tradicional
Varias razones estructurales:
Alta concentración de tráfico: ChatGPT es uno de los productos de IA más visitados del mundo. Cualquier punto único de falla tiene un alcance extremadamente amplio.
Cadena de inferencia compleja: La inferencia de modelos grandes no es como la simple solicitud-respuesta de las API tradicionales. Los mecanismos de equilibrio de carga y tolerancia a fallos son más difíciles de diseñar, y las fallas son más difíciles de localizar rápidamente.
Velocidad de iteración demasiado rápida: Las actualizaciones de modelos y las iteraciones de funciones son frecuentes. Cada implementación puede introducir nuevos factores de inestabilidad. AWS y Google Cloud tienen décadas de acumulación en ingeniería de confiabilidad; los sistemas de ingeniería de los proveedores de servicios de IA todavía están poniéndose al día.
Problema de SLA: La industria de la IA aún no ha respondido seriamente
La mayoría de los SaaS maduros ofrecen un SLA (Acuerdo de Nivel de Servicio) del 99,9 %, lo que corresponde a un tiempo de inactividad anual no superior a 8,7 horas; un nivel más estricto del 99,99 % reduce el tiempo de inactividad anual a 52 minutos.
OpenAI actualmente no tiene un compromiso público de SLA empresarial. Anthropic tampoco.
Esto significa que: Una gran cantidad de empresas están colocando sus procesos comerciales centrales en un servicio sin un compromiso claro de confiabilidad, y los contratos no tienen cláusulas de compensación por interrupciones. Este no es un problema pequeño, especialmente cuando la IA ya ha entrado en la ruta crítica del entorno de producción.
Si su negocio depende de la IA, debe considerar estos puntos
Estrategia de múltiples proveedores: Los procesos críticos deben conectarse simultáneamente a dos conjuntos de API, por ejemplo, OpenAI y Anthropic. Si uno falla, el otro aún funciona. El costo de implementación no es alto, pero la lógica de enrutamiento debe prepararse con anticipación.
Copia de seguridad de modelo local: Las tareas que no son en tiempo real pueden usar modelos de código abierto implementados localmente como solución de respaldo. Los escenarios con alta tolerancia a la latencia pueden almacenar en caché las solicitudes y procesarlas después de que el servicio se recupere.
Cláusulas contractuales: Al firmar contratos empresariales con proveedores de IA, incluya los requisitos de confiabilidad en el contrato – incluso si el proveedor actualmente no tiene un SLA estándar, debe haber acuerdos claros sobre mecanismos de notificación de fallas y compensación.
Diseño de resiliencia a nivel de código: Manejo de tiempos de espera, lógica de reintento, rutas de respaldo – estos no son opcionales, son requisitos básicos de ingeniería al integrar API de IA externas.
Esta interrupción no fue la primera de OpenAI y no será la última. En el camino hacia la madurez de la infraestructura de IA, estos incidentes seguirán ocurriendo. Solo hay una pregunta: ¿Los equipos que ya usan IA en producción han diseñado seriamente planes de contingencia?
Fuente de referencia: CocoLoop, ChatGPT was down — Live updates on the massive AI outage (Tom's Guide); ChatGPT was down for many — as OpenAI says it's 'monitoring the recovery' (TechRadar); OpenAI's ChatGPT Down for Thousands of Users (GV Wire); ChatGPT Down: Thousands of Users Hit by Major Outage on April 20 (TechGenyz)