Mantén el trabajo real en marcha cuando ChatGPT está caído: una auditoría de respaldo de 5 minutos

La caída es una prueba de continuidad

Si el flujo de trabajo de tu equipo depende de un solo asistente de IA, la primera señal de problemas no es un banner de estado. Es un borrador que no termina, un ticket que no se clasifica, una revisión de código que se estanca y un gerente preguntando por qué el pipeline está en silencio. La caída hizo visible esa dependencia de la manera menos halagadera: varios chatbots de IA importantes experimentaron una caída casi simultánea. Los usuarios reportaron problemas al usar tanto el sitio web como la aplicación móvil, por lo que la falla no fue una sola pestaña del navegador, una VPN defectuosa ni un pasante agotado. La página de estado de OpenAI reportó errores graves en ChatGPT y Codex, lo cual importa porque la misma dependencia puede estar detrás de la redacción para clientes y del trabajo interno de ingeniería. Los primeros reportes hipotetizaron que un aumento repentino de tráfico colapsó una ruta de Cloudflare que servía a las empresas afectadas, un recordatorio de que la infraestructura compartida puede convertir un problema de un proveedor en un problema de múltiples proveedores. A la fecha de los reportes, ninguna empresa había detallado la causa técnica exacta de los errores, y ChatGPT/OpenAI fue reportado como el primer servicio en regresar a la operación normal.

Ese último detalle no es un consuelo. Es una advertencia. Si tu equipo solo puede trabajar cuando un servicio está en verde, tu plan de continuidad es una esperanza, no un diseño. Los equipos que mantienen el trabajo en marcha no son los que tienen más prompts. Son los que preconfiguran respaldos específicos por tarea antes de que la caída los encuentre.

La auditoría: cinco pasos, cinco minutos

La auditoría no es un simulacro de desastre. Es un inventario de cinco minutos de dónde el asistente soporta la carga. Hazlo para cada flujo de trabajo que afecta ingresos, confianza del cliente, velocidad de ingeniería o cumplimiento. El objetivo es simple: cuando la herramienta esté caída, debes saber qué hacer, quién lo hace y qué estándar de calidad aplica.

1. Clasifica la tarea por capacidad, no por herramienta. Una tarea de redacción puede necesitar estructura, tono y restricciones de dominio. Una tarea de codificación puede necesitar contexto del repositorio, pruebas y revisión. Una tarea de investigación puede necesitar calidad de fuentes, citación y síntesis. Una tarea de soporte puede necesitar política, empatía y escalado. Si el respaldo es “usar el otro asistente”, no has clasificado la tarea; solo has renombrado la dependencia.
2. Mapea la dependencia. Pregunta dónde entra el asistente en el flujo de trabajo: ingreso, redacción, resumen, generación de código, clasificación de tickets o revisión final. Luego pregunta qué se rompe si ese paso desaparece. Si la respuesta es “nada”, puedes estar sobreestimando la herramienta. Si la respuesta es “todo”, necesitas un respaldo antes del próximo incidente.
3. Elige un respaldo por capacidad. Para redacción, una plantilla humana con secciones obligatorias puede preservar la calidad. Para codificación, una lista de verificación de revisión manual y una suite de pruebas pueden mantener seguros los cambios. Para investigación, una lista de fuentes y un esquema de síntesis pueden prevenir una confianza alucinada. Para soporte, una matriz de políticas y una ruta de escalado pueden proteger a los clientes. El respaldo debe ser lo suficientemente aburrido para usarse bajo estrés.
4. Define una transferencia humana. Nombra a la persona o rol responsable del respaldo. Define el estándar de calidad: qué es aceptable, qué necesita revisión y qué debe escalar. Si nadie es responsable del respaldo, el respaldo es un rumor.
5. Pruébalo antes de la caída. Elige una tarea recurrente y hazla sin el asistente durante una ventana corta. No un sprint completo. No una evaluación de desempeño. Solo lo suficiente para ver si el respaldo produce trabajo utilizable, dónde se ralentiza y qué necesita ajustarse. Si la prueba es demasiado dolorosa, el respaldo no está listo.

Qué mantener en el runbook

Después de la auditoría, escribe el resultado en un lugar donde la gente pueda encontrarlo bajo presión. Una página compartida está bien. Una página de wiki está bien. Una nota en el sistema de tickets está bien. El formato importa menos que el contenido. Cada entrada debe responder cuatro preguntas: qué tarea está afectada, cuál es el respaldo, quién es responsable y cuál es el estándar de calidad. Si la respuesta requiere una reunión, no es un runbook; es una negociación.

• Redacción: plantilla, responsable, estándar de revisión y una lista de frases o afirmaciones que requieren verificación humana.
• Codificación: comando de prueba, lista de verificación de revisión y el mínimo para fusionar sin el asistente.
• Investigación: lista de fuentes, regla de citación y la diferencia entre un resumen y una afirmación.
• Soporte: matriz de políticas, ruta de escalado y el punto donde un humano debe tomar el control.

Cuando el servicio vuelve

No trates la restauración como el final del ejercicio. La pregunta útil no es si el servicio está disponible de nuevo, sino si el respaldo mantuvo el trabajo honesto; si produjo una salida más lenta pero defendible, mantenlo. Si produjo pánico, corrige la transferencia. Si no produjo nada, la dependencia era mayor de lo que el equipo admitía. La próxima caída no se preocupará por tu lealtad al proveedor. Se preocupará por si tu flujo de trabajo tiene columna vertebral.