Ya explicamos en qué es un playbook de un agente de IA el manual de comportamiento que le dice a un agente cómo actuar en su día a día: qué tono usar, qué pasos seguir, cuándo escalar un caso normal a una persona. Este artículo trata de algo distinto y complementario: qué pasa cuando ese comportamiento normal se rompe. Un playbook de incidentes no es el manual de "cómo trabaja el agente", es el protocolo de "qué hacemos cuando el agente falla".
Qué es un playbook de incidentes
Un playbook de incidentes es el conjunto de pasos predefinidos que se activan cuando un agente de IA se comporta de forma incorrecta, inesperada o dañina: responde con información falsa a un cliente, accede a datos que no debería, deja de funcionar en mitad de un proceso crítico, o toma una acción que no tenía que tomar (por ejemplo, confirmar un pedido con un precio erróneo). Igual que un hospital tiene un protocolo distinto para una urgencia que para una consulta rutinaria, una empresa que opera agentes de IA necesita un protocolo distinto para cuando algo va mal que para el funcionamiento normal.
La pregunta que responde este documento no es "¿qué debe hacer el agente ante un cliente enfadado?" (eso lo cubre el playbook de comportamiento), sino "¿qué debe hacer la empresa cuando el agente ha hecho algo que no debía?".
Por qué muchas empresas no tienen uno, y por qué eso es un riesgo
Es habitual que una empresa dedique semanas a definir cómo debe responder su agente en situaciones normales, y ni un minuto a definir qué pasa si el agente falla. La razón es comprensible: durante el diseño del proyecto, todo el foco está en que funcione bien, no en prepararse para que falle. El problema aparece cuando el fallo ocurre sin nadie preparado, y las primeras decisiones se toman de forma improvisada, bajo presión y con el cliente ya afectado.
Sin un playbook de incidentes, las preguntas básicas —¿quién se entera primero de que algo ha ido mal?, ¿se puede apagar el agente sin tumbar todo el sistema?, ¿quién avisa al cliente afectado y con qué mensaje?— se responden sobre la marcha, y sobre la marcha es el peor momento para decidir bien.
Qué debe incluir un playbook de incidentes
Definición de qué cuenta como incidente. No todo error merece el mismo nivel de respuesta. Conviene clasificar de antemano qué tipo de fallo activa el protocolo completo (una acción irreversible incorrecta, una filtración de datos, un daño reputacional potencial) y qué tipo de fallo se corrige en el flujo normal de mejora continua (una respuesta mejorable pero sin consecuencias reales).
Mecanismo de detección. ¿Cómo se entera la empresa de que algo ha ido mal? Puede ser una alerta automática (el sistema detecta un patrón anómalo), un reporte de un cliente, o una revisión periódica de conversaciones. Cuanto más dependa la detección de que un cliente se queje, más tarde se entera la empresa y más daño se acumula antes de reaccionar.
Capacidad de contención inmediata. Debe existir una forma de limitar el daño sin necesidad de apagar todo el sistema: pausar un flujo concreto, desactivar una acción específica (por ejemplo, que el agente deje de poder confirmar pedidos automáticamente mientras se revisa el problema) o escalar a revisión humana el tipo de caso afectado.
Cadena de responsables. Quién decide qué se hace, en qué orden se avisa (el equipo técnico, el responsable del área afectada, en los casos graves los clientes implicados) y quién tiene autoridad para reactivar el sistema una vez resuelto. Esto conecta directamente con el principio de mantener supervisión humana en procesos automatizados: la supervisión no es solo revisar cómo trabaja el agente en el día a día, es también saber quién tiene la última palabra cuando hay que pararlo.
Comunicación con los afectados. Si el incidente ha afectado a un cliente (una respuesta incorrecta, un dato erróneo, una acción no autorizada), debe estar decidido de antemano cómo y cuándo se le informa, en lugar de improvisar un mensaje bajo presión.
Análisis posterior y corrección de raíz. Cerrar el incidente no es solo "ya funciona de nuevo", es entender qué falló en el playbook de comportamiento, en los datos o en la integración, y corregirlo para que no se repita el mismo tipo de fallo.
Un ejemplo simplificado
Un agente de atención al cliente empieza a ofrecer un descuento que no existe, por una interpretación incorrecta de una promoción antigua que seguía en su base de conocimiento. Con un playbook de incidentes definido, la secuencia sería: una alerta detecta un patrón de menciones a ese descuento fuera de lo habitual; se pausa automáticamente la capacidad del agente de mencionar promociones hasta revisar la base de conocimiento; el responsable de atención al cliente revisa cuántos clientes han recibido esa información y decide si hay que honrar el descuento o comunicar el error; se corrige la base de conocimiento; se reactiva el agente. Sin ese protocolo, lo habitual es que el problema se descubra días después, cuando ya ha afectado a muchos más clientes.
Cómo empezar si no tienes ninguno
No hace falta un documento extenso desde el primer día. Basta con responder por escrito a tres preguntas para cada agente que tengas en producción: qué tipos de fallo consideramos graves, cómo nos enteraríamos si ocurrieran, y quién tiene autoridad para pausar el sistema. Esa base mínima ya reduce buena parte del riesgo de improvisar en el peor momento, y se puede ampliar con el tiempo a medida que el agente gana en autonomía y en volumen de operaciones.
Conclusión
El playbook de comportamiento le dice al agente cómo actuar cuando todo va bien; el playbook de incidentes le dice a la empresa qué hacer cuando algo va mal. Los dos son necesarios, y el segundo se olvida con mucha más frecuencia que el primero, normalmente hasta que el primer incidente real obliga a improvisarlo sobre la marcha.
En MG Solutions incluimos el diseño de protocolos de incidentes en cualquier proyecto de agentes de IA que gestionamos. Si quieres revisar si el tuyo tiene uno, reserva una primera reunión.