Realiza una auditoría de dependencia de IA de 30 minutos antes de la próxima caída de ChatGPT

La caída es la auditoría

El momento que importa es cuando un modelo desaparece y el equipo tiene que decidir lo que ve el cliente. En ese minuto, alguien tiene que elegir si degradar la función, derivar el trabajo a personas o comunicar la carencia. La pregunta no es si la API vuelve. Es si tu producto aún puede hacer lo que prometió, y si el mensaje que envías no suena a una nota de pánico.

Una breve auditoría de dependencia de IA es la herramienta para ese momento. No es una revisión de seguridad. No es una negociación con el proveedor. Es un mapa operativo de dónde tu empresa está acoplada a inteligencia de terceros y qué ocurre cuando ese acoplamiento falla.

La caída reciente lo dejó claro. La caída comenzó alrededor de las 17:00. Los usuarios informaron que la caída impidió el uso tanto del sitio web como de la aplicación móvil. Se informó que ChatGPT y Codex estaban afectados. OpenAI dijo que había aplicado medidas correctivas y que estaba monitoreando la recuperación, mientras que el estado de Claude indicaba que los modelos afectados incluían Mythos 5.1, Fable 5.1, Opus 5, Opus 4.8 y Opus 4.6. El ChatGPT de OpenAI fue informado como el primer servicio en volver a la operación normal. No es el drama. Si tu producto, flujo de soporte u operaciones internas dependen de un modelo que puede desaparecer de una página de estado, necesitas saber lo que ve el cliente, quién puede activar el respaldo y si el respaldo se ha ejecutado antes de que el cliente lo pida.

Ejecuta la auditoría en cinco campos

No empieces con una hoja de cálculo de cada prompt. Empieza con el cliente. Para cada lugar donde un LLM tiene contacto con un usuario, un agente de soporte, un representante de ventas o un operador interno, registra cinco campos. El objetivo es completar una pasada que te diga lo que ve el cliente, quién es responsable de la carencia y si el respaldo ha sido probado.

No necesitas una sala de guerra. Necesitas una pasada breve y repetible. El objetivo es hacer visibles las dependencias que importan, no catalogar cada prompt ingenioso en la base de código.

1. Impacto en el cliente. Mapea la superficie de contacto con el cliente. Lista cada función donde un modelo genera, resume, clasifica, redacta o enruta salida visible para el cliente. Incluye macros de soporte, prospección de ventas, incorporación, búsqueda y herramientas internas que finalmente afectan a los clientes. Para cada elemento, escribe lo que ve el cliente cuando el modelo falla: qué se rompe, se degrada o se vuelve más lento; si el usuario está bloqueado, retrasado o recibiendo una salida de menor calidad; y si el fallo es visible para el cliente o solo para tu equipo. Si la respuesta es 'nada', verifícalo. Si la respuesta es 'un error genérico', mejóralo. Si la respuesta es 'no lo sabemos', esa es la primera cosa por probar.
2. Respaldo. Registra qué ocurre cuando el modelo no está disponible: una cola humana, una respuesta en caché, una función reducida, una revisión manual o una espera cortés. Si el respaldo es 'lo intentaremos de nuevo', eso no es un respaldo. El respaldo debe ser lo suficientemente claro para que un suplente lo ejecute si el responsable no está disponible.
3. Responsable. Asigna a una persona que pueda tomar la decisión de cambiar, pausar o comunicar. No un equipo. No 'ingeniería'. Un nombre. El responsable debería poder decidir si degradar la función, derivar a personas o pausar el flujo de trabajo.
4. Mensaje de estado. Escribe el mensaje exacto mostrado a los clientes o agentes cuando la función está degradada. No esperes a la caída. Un buen mensaje nombra la función afectada, dice qué sigue funcionando y da un siguiente paso. Debe ser calmado, específico y no prometer un plazo que no puedes cumplir. No debe sonar a un comunicado de prensa ni a una confesión.
5. Fecha de la última prueba. Registra cuándo verificaste realmente que el respaldo funciona. No cuándo lo escribiste. No cuándo lo discutiste. ¿Cuándo lo ejecutaste? Para respaldos manuales de alto impacto, ejecuta un escenario realista: modelo no disponible, el cliente pregunta, el agente responde. Cronometra. Anota dónde se detiene el proceso. Si no puedes recordar cuándo lo probaste, trátalo como no probado. La fecha no es burocracia. Es la diferencia entre un respaldo y una esperanza.

El punto no es crear un documento que impresione a un inversor. El punto es crear un documento que permita a un líder de soporte cansado tomar una decisión en el peor momento posible. Si el modelo está caído, el equipo no debería estar debatiendo si el respaldo existe. Debería estar ejecutándolo.

Hay una regla simple de triaje. Si el impacto en el cliente es alto y el respaldo es manual, programa una prueba dentro de una semana. Los respaldos manuales son donde las caídas se convierten en incidentes. Requieren personas, juicio y velocidad, y son lo primero que se rompe cuando aumenta el volumen.

La auditoría debe ser lo suficientemente breve para completarse en una sesión y lo suficientemente específica para actuar sobre ella. Si toma más tiempo, probablemente estás auditando el modelo en lugar de la dependencia. El modelo no es tu problema. El acoplamiento sí.

Es la capacidad de decir lo que ve el cliente, quién puede activar el respaldo y si el respaldo se ha ejecutado. La elección calmada es degradar, derivar a personas o comunicar, y hacerlo antes de que el cliente lo pida. Ese es el beneficio: una decisión tomada en el momento del fallo, no un caos después de que el cliente se da cuenta.

También evita que la decisión se convierta en una discusión grupal. El responsable puede decir lo que ve el cliente, qué sigue funcionando y qué ocurre a continuación. El mensaje de estado puede ser calmado porque fue escrito antes de la caída. El respaldo puede ser confiable porque fue probado, cronometrado y se anotó dónde se detiene. En ese momento, el equipo no está descubriendo la dependencia; está ejecutando la elección.