Un agente de IA que gestiona pedidos empieza de repente a clasificar mal la mitad de las solicitudes que llegan. Son las siete de la tarde de un viernes. La persona que lo configuró está de vacaciones. ¿Quién decide si hay que apagarlo, quién tiene permiso para hacerlo, y qué se hace con los pedidos que ya ha procesado mal? Si la respuesta a estas preguntas es "ya se verá", la empresa no tiene un plan de incidentes; tiene una improvisación pendiente de ocurrir. Un runbook de incidentes con IA es precisamente el documento que evita que ese viernes por la tarde se convierta en un caos sin nadie al mando.
Qué es un runbook de incidentes con IA, en términos sencillos
Un runbook de incidentes es un documento operativo que describe, paso a paso, qué hacer cuando un sistema de IA falla o se comporta de forma anómala: quién debe enterarse primero, cómo se detiene o se limita el sistema, cómo se evalúa el daño causado, y cómo se comunica lo ocurrido tanto internamente como, si corresponde, a los clientes afectados. No es un manual técnico sobre cómo funciona el sistema por dentro; es una guía de acción para el momento de la crisis, escrita con antelación y con calma, precisamente para no tener que improvisar decisiones importantes bajo presión y con información incompleta.
La diferencia entre tener un runbook y no tenerlo se nota exactamente en el peor momento posible: cuando algo ya ha fallado. Sin runbook, el primer incidente real se convierte en el momento en que la empresa descubre, sobre la marcha, quién debería haber sido avisado, qué permisos hacen falta para desactivar el sistema, y qué mensaje dar a un cliente que ha recibido una respuesta incorrecta. Con runbook, esas decisiones ya están tomadas de antemano, y lo único que queda por hacer es ejecutarlas.
¿Qué diferencia hay entre un runbook y simplemente "apagar el sistema si algo va mal"?
La diferencia está en que "apagar si algo va mal" da por hecho que alguien detecta el fallo a tiempo, sabe que tiene autoridad para apagarlo, y entiende las consecuencias de hacerlo, tres supuestos que en la práctica fallan con frecuencia. Un runbook elimina esa incertidumbre definiendo de antemano los umbrales exactos que indican que algo va mal, quién tiene autoridad para actuar sin necesidad de escalar la decisión, y qué pasos concretos hay que seguir según el tipo de fallo, porque no todos los incidentes se resuelven apagando el sistema: algunos requieren limitar su alcance, otros revertir acciones ya ejecutadas, y otros simplemente avisar a un supervisor humano para que revise antes de que el sistema siga actuando.
Las partes que debe tener un runbook de incidentes con IA
Un runbook útil no necesita ser un documento extenso ni burocrático; necesita cubrir con precisión las decisiones que de verdad hay que tomar bajo presión.
Señales que definen un incidente
Describe con claridad qué comportamientos concretos cuentan como incidente: un porcentaje de errores por encima de cierto umbral, una queja de cliente relacionada directamente con una acción del sistema, un acceso a datos fuera de su alcance previsto, o una caída del servicio.
Cadena de responsabilidad
Indica quién debe ser avisado primero, en qué orden, y quién tiene autoridad para tomar decisiones como detener el sistema, sin depender de que una persona concreta esté disponible en ese momento exacto.
Pasos de contención inmediata
Detalla las acciones concretas para limitar el daño mientras se investiga la causa: desactivar el sistema por completo, restringir su acceso a ciertos datos, o pasar temporalmente a un modo con supervisión humana obligatoria en cada decisión.
Evaluación del alcance del daño
Explica cómo identificar qué acciones concretas del sistema pueden haberse visto afectadas por el fallo —qué pedidos, qué clientes, qué comunicaciones—, de forma que se pueda corregir lo ya ejecutado, no solo detener lo que viene.
Comunicación interna y externa
Define quién redacta y aprueba cualquier comunicación a clientes afectados, y qué información mínima debe incluir esa comunicación, evitando que cada incidente genere un debate improvisado sobre qué decir y a quién.
¿Quién debe tener acceso al runbook y cuándo se debe probar?
El runbook debe estar accesible para cualquier persona que pueda encontrarse con el incidente en primera línea, no solo para quien lo diseñó, porque de poco sirve un documento perfecto que solo conoce una persona que puede estar de vacaciones, enferma o simplemente desconectada en el momento en que ocurre el fallo. Además, un runbook que nunca se ha probado es, en la práctica, una teoría: conviene simular al menos una vez un incidente ficticio y ejecutar los pasos del documento tal como están escritos, para descubrir en un entorno controlado los pasos ambiguos, los permisos que en realidad no tiene quien debería tenerlos, o los contactos desactualizados, antes de que esos fallos aparezcan durante un incidente real con consecuencias de verdad.
Cómo mantener el runbook actualizado a medida que el sistema cambia
Un runbook escrito una vez y guardado sin volver a tocarlo pierde utilidad con rapidez, porque los sistemas de IA cambian: se añaden nuevas capacidades, se conectan a más datos, o cambian las personas responsables de cada parte del proceso. Conviene revisar el runbook cada vez que el sistema sufre un cambio relevante en su alcance o en sus permisos, no solo de forma periódica y desconectada de la realidad del proyecto. También conviene actualizarlo después de cada incidente real, por pequeño que sea, incorporando lo aprendido sobre qué pasos funcionaron bien y cuáles generaron confusión durante la respuesta, de forma que el documento mejore con la experiencia en lugar de quedarse congelado en la versión inicial que nadie ha vuelto a revisar desde que se escribió.
Aplicación práctica en una pyme
Imagina una empresa que ha implantado un agente de IA para generar y enviar automáticamente recordatorios de pago a clientes con facturas pendientes. Un runbook de incidentes para este caso definiría, por ejemplo, que si más del 5% de los recordatorios enviados en un día generan una respuesta de cliente disputando el importe, el responsable de administración recibe una alerta automática y tiene autoridad para pausar los envíos sin necesidad de esperar a nadie más; que en ese caso se revisan los últimos envíos para identificar cuántos clientes han recibido un importe incorrecto; y que se prepara una comunicación breve de disculpa para los afectados antes de reactivar el sistema. Con este plan escrito de antemano, un fallo que de otra forma generaría horas de indecisión se resuelve en minutos, con las personas adecuadas actuando desde el primer aviso.
Preparar un runbook antes de que el primer incidente ocurra, en lugar de escribirlo después como lección aprendida, es lo que distingue a una empresa que gestiona la IA con criterio de una que simplemente confía en que nada falle.
MG Solutions puede ayudarte a prepararlo
En MG Solutions diseñamos, junto a cada agente de IA que implantamos, el runbook de incidentes correspondiente, con roles, umbrales y pasos de contención claros desde el primer día. Si tu empresa ya tiene sistemas de IA en marcha sin un plan claro para cuando algo falle, pide un diagnóstico gratuito y lo preparamos juntos.