El protocolo de emergencia cuando un output de IA llega al cliente con error
El protocolo de emergencia para outputs de IA con error era el documento de gobernanza que el equipo más esperaba no necesitar y que con mayor claridad necesitaba existir. La paradoja de los protocolos de emergencia es que su valor es máximo en el momento en que se necesitan y ese momento no es el adecuado para diseñarlos. Diseñar un protocolo de emergencia en el momento de la emergencia produce decisiones reactivas, inconsistentes y frecuentemente más costosas de lo que hubieran sido con un proceso definido de antemano. El protocolo que diseñé con calma en el mes que siguió al incidente de los datos incorrectos sobre el producto fue el que el equipo pudo aplicar con serenidad en los incidentes posteriores.
El protocolo tenía 5 pasos en secuencia que debían completarse dentro de plazos específicos desde el momento en que se identificaba el error. El primer paso era de contención inmediata, dentro de los primeros 30 minutos: retirar o corregir el output incorrecto de todos los canales donde había sido distribuido, sin esperar a entender la causa o a diseñar la comunicación de corrección. La contención del daño activo era prioritaria sobre cualquier otra actividad del protocolo.
El segundo paso era de notificación interna, dentro de las primeras 2 horas: informar al CEO, al director de marketing y al equipo de customer success sobre el incidente con el output específico, el canal de distribución y el volumen de personas que lo habían recibido. La notificación interna establecía quién era responsable de cada paso del protocolo y activaba los recursos necesarios para ejecutarlo. El tercer paso era de diagnóstico, dentro de las primeras 4 horas: identificar la causa raíz del error y determinar si el mismo error podría estar presente en otros outputs de IA producidos por el mismo sistema o proceso.
El cuarto paso era de comunicación externa, dentro de las primeras 24 horas: notificar a los destinatarios del output incorrecto con un mensaje que reconocía el error, explicaba brevemente qué había ocurrido, compartía la versión correcta y se disculpaba por cualquier confusión generada. El tono del mensaje era de responsabilidad sin dramatismo: reconocer el error de forma directa sin amplificarlo con una disculpa exagerada que comunicara más gravedad de la que el incidente merecía. El quinto paso era de mejora del sistema, dentro de los primeros 7 días: documentar el incidente en el registro de decisiones, ajustar el protocolo de revisión para prevenir la repetición del mismo tipo de error y comunicar la mejora al equipo.
El protocolo fue ejecutado de forma completa en 2 incidentes durante el año siguiente a su creación. En ambos casos, el feedback de los clientes o prospectos que recibieron la comunicación de corrección fue positivo: el proceso de reconocimiento y corrección había sido manejado de forma profesional y habían valorado la transparencia sobre el error. El daño de confianza que un error de IA sin protocolo de corrección puede generar es significativamente mayor que el de un error gestionado con un protocolo claro. El protocolo no previene los errores. Previene que los errores se conviertan en crisis.