Cuando hay una caída de ChatGPT, haz este postmortem de 5 preguntas para mantener el trabajo en marcha

La caída fue breve. La dependencia no.

Cuando una herramienta familiar deja de responder, la primera sensación es alivio: la máquina no estaba haciendo el trabajo. Descubres que la máquina estaba cargando un paso que nunca asignaste, un juicio que nunca revisaste, un plazo que nunca protegiste. Ese es el verdadero fallo en una caída de ChatGPT. No es que la IA sea poco fiable. Es que tu flujo de trabajo se convirtió en una caja negra sin interruptor de apagado.

Una caída breve no es una sentencia sobre la IA. Es un postmortem de la dependencia. El modelo puede ser brillante, barato y rápido. El flujo de trabajo alrededor de él puede seguir siendo frágil. Si la herramienta desaparece y tu equipo no puede decir qué hacer a continuación, el problema nunca fue el modelo. El problema fue que externalizaste el pensamiento, la confianza y la rendición de cuentas a un servicio que nadie podía explicar cuando se rompió.

Una caída multiservicio afectó a ChatGPT, Claude, Gemini y Grok, impactando a miles de usuarios durante varios minutos. Down Detector informó de problemas que comenzaron alrededor de las 15:00 hora peninsular española, y la página de estado de OpenAI informó de errores graves en ChatGPT y Codex. Las primeras hipótesis apuntaban a un aumento repentino del tráfico que causó un colapso de una ruta de Cloudflare, aunque ninguna empresa había detallado la razón técnica exacta. ChatGPT fue el primer servicio en recuperar la operación normal.

La autopsia de la dependencia de la IA

Realiza esta autopsia antes de restaurar el flujo de trabajo, no después. El objetivo no es culpar. El objetivo es encontrar dónde se eliminó el bucle humano. Haz cada pregunta en lenguaje claro y escribe la respuesta donde el equipo pueda verla. La secuencia no es una lista de verificación. Es una forma de encontrar el bucle humano que falta.

1. ¿Qué tarea estaba haciendo realmente la IA?

Cuando la tarea no tiene nombre, la caída se convierte en una pelea sobre lo que la máquina debía hacer. La pregunta no es lo que decía el prompt. Es lo que se convirtió la salida: un borrador, un resumen, una clasificación, una respuesta a un cliente, un cambio de código, una recomendación. Si la tarea es vaga, el respaldo también es vago. Nombra la tarea a nivel de trabajo, no como una categoría vaga. Una tarea que no puede nombrarse no puede devolverse a un humano.

2. ¿Qué respaldo existe cuando el modelo no está disponible?

Un respaldo no es “usar otro modelo”. Eso es una segunda dependencia, no una ruta de recuperación. Un respaldo es un procedimiento humano que mantiene el trabajo en marcha a menor velocidad: una plantilla, una cola, una revisión manual, una decisión diferida, una regla simple. Si el respaldo requiere la misma herramienta no disponible, no es un respaldo. Si requiere a una persona senior que no está nombrada, no está listo. Escribe el respaldo y nombra a la persona que lo ejecutará.

3. ¿Quién es responsable del paso cuando el modelo está en silencio?

Cuando la responsabilidad es vaga, nadie detiene la hemorragia; todos improvisan. La responsabilidad no es un rol. Es una persona. Nombra a esa persona. “El editor” no es un responsable. “El analista de guardia” no es un responsable. El responsable debe poder decir: puedo detener el paso, puedo aprobar el respaldo y puedo explicar qué cambió. Si nadie puede decirlo, el paso no tiene responsable. Si el paso no tiene responsable, la caída se convierte en una improvisación de todo el equipo.

4. ¿Qué datos salieron de la sala?

Cada paso de IA mueve información: nombres de clientes, notas internas, cifras financieras, lenguaje legal, planes de producto, código. El postmortem no debería preguntar si los datos estaban “seguros”. Debería preguntar si los datos eran necesarios, si se minimizaron y si el equipo puede decir qué se envió. Escribe qué se envió. Si la respuesta es “no lo sabemos”, el flujo de trabajo tiene un problema de privacidad y confianza que ninguna caída puede arreglar.

5. ¿Qué puede decidir el modelo?

Esta es la pregunta que la mayoría de los equipos evita. Un modelo puede redactar, pero ¿debería enviar? Puede resumir, pero ¿debería clasificar? Puede proponer, pero ¿debería aprobar? El límite debe ser explícito. Escribe el límite. Si se permite al modelo decidir algo que afecte a un cliente, un pago, una publicación o a una persona, el respaldo debe incluir una revisión humana antes de que la decisión salga de la sala.

La regla que mantiene el trabajo en marcha

Ningún paso de IA está en producción hasta que tenga un respaldo humano y un responsable designado.

Esa regla suena estricta. En realidad es el seguro de fiabilidad más barato que puedes comprar. No requiere modelos perfectos. No requiere proveedores perfectos. Requiere una pequeña cantidad de disciplina: escribe el respaldo, nombra al responsable, define el límite de decisión y prueba la ruta antes de la próxima caída. Cuando la herramienta funciona, la regla se siente como sobrecarga. Cuando la herramienta se detiene, la regla es la diferencia entre una pausa y una crisis.

Deberías preguntarte si tu equipo puede seguir haciendo el trabajo sin fingir que la máquina era la única que sabía cómo. Es que tu flujo de trabajo se convirtió en una caja negra sin interruptor de apagado.