Respuesta directa
En pocas palabras
Un runbook operativo para un AI Sales Copilot debe permitir que una persona autorizada identifique el servicio, compruebe su estado, interprete una señal, reúna evidencia mínima, ejecute únicamente acciones seguras y reversibles, active un modo degradado cuando corresponda y escale antes de superar su autoridad. Cada procedimiento necesita precondiciones, pasos verificables, resultado esperado, condición de alto, evidencia, responsable, fecha de prueba y versión. El runbook no sustituye la política, el plan de incidentes ni el plan de continuidad: los conecta en el momento exacto en que deben activarse.
El runbook convierte una señal operativa en una decisión controlada
Un runbook describe cómo ejecutar una tarea repetible bajo condiciones conocidas. Responde qué revisar, con qué acceso, qué resultado esperar, cuándo detenerse y a quién escalar. No pretende explicar toda la arquitectura ni improvisar una solución para cualquier falla. Su valor está en reducir ambigüedad justo cuando hay presión, información incompleta o cambio de turno.
Para un AI Sales Copilot, el alcance cruza aplicación, modelo, recuperación, catálogo, CRM, permisos, herramientas, exportaciones y Buyer Room. NIST AI RMF incluye monitoreo posterior al despliegue, override, respuesta, recuperación y cambio dentro de la gestión del riesgo. Google SRE recomienda preparar procedimientos y rutas de escalamiento antes de necesitarlos. Adapta esas referencias a tu contexto; no implican certificación ni una receta universal.
Separa runbook, playbook, política e incidente
La política define obligaciones y límites; el playbook organiza una respuesta adaptable a un escenario; el runbook detalla una operación concreta; el plan de continuidad mantiene procesos críticos durante una interrupción; y el proceso de incidentes coordina impacto activo, roles y comunicación. Enlázalos, pero evita copiar el mismo contenido en cinco lugares: las copias divergen y alguien termina siguiendo la versión equivocada.
Define la frontera de salida. El runbook puede orientar una comprobación, recopilar evidencia, retirar una fuente aprobada o activar una ruta manual previamente autorizada. Debe transferir el control cuando exista impacto material, propagación, datos sensibles, posible abuso, una acción irreversible, incertidumbre fuera del diagnóstico o participación de varios equipos.
| Criterio | Pregunta | Documento principal |
|---|---|---|
| ¿Qué está permitido? | Obligación, límite y autoridad | Política y matriz RACI |
| ¿Cómo ejecuto esta tarea? | Pasos, verificación y alto | Runbook operativo |
| ¿Cómo coordinamos el impacto? | Mando, prioridades y comunicación | Plan de incidentes |
Empieza con una ficha del servicio que no dependa de conocimiento tribal
Registra nombre, propósito, dueño, criticidad, usuarios, horario, regiones, recorridos críticos, entradas, salidas, componentes, proveedores, integraciones, versiones, dependencias, SLO o expectativas internas, paneles, logs, cola de soporte, repositorio, canal operativo y contactos. Enlaza el inventario de IA y el mapa de datos en vez de reconstruirlos dentro del runbook.
Incluye límites funcionales verificables. En Cerravi, Copilot prepara contexto y sugerencias para revisión humana; no envía mensajes ni cambia etapas por sí solo, usa precios existentes en el catálogo y mantiene monedas separadas. Si tu implementación permite acciones distintas, documenta exactamente quién las aprueba, dónde se aplican los controles y cómo se observa su resultado.
Declara precondiciones y acceso sin guardar secretos
Antes de cada procedimiento indica rol requerido, aprobación, entorno, ventana, herramientas, fuente de verdad, respaldo disponible, riesgo conocido y comprobaciones previas. El operador debe confirmar organización, versión, región, moneda y objeto comercial antes de actuar. Una captura del panel equivocado puede parecer válida y producir un cambio en otra cuenta.
No pegues contraseñas, API keys, tokens, datos personales ni enlaces de sesión en el documento. Enlaza el gestor de secretos por nombre lógico y explica cómo solicitar acceso temporal. Aplica mínimo privilegio y registra la operación. Si el acceso de emergencia no funciona o la identidad no puede comprobarse, detente: el runbook no autoriza a saltarse controles para ahorrar tiempo.
Organiza verificaciones diarias, semanales y posteriores a cambios
La rutina diaria debe concentrarse en señales que cambian decisiones: disponibilidad del recorrido, errores por versión, latencia útil, colas, integraciones, recuperación, permisos anómalos, precios sin fuente, mezcla de moneda, salidas bloqueadas, feedback y alertas abiertas. No conviertas el turno en leer decenas de gráficas sin umbral, población ni acción posible.
La revisión semanal busca tendencias, cobertura, alertas repetidas, deuda operativa, workarounds próximos a vencer, cambios de proveedor, calidad del catálogo y procedimientos que fallaron. Después de un despliegue, comprueba una lista más corta ligada al cambio y a sus riesgos. Registra fecha, versión, resultado, excepción y siguiente acción; un check verde sin evidencia no permite reconstruir nada.
Relaciona cada señal con impacto, contexto y primera acción
Construye una matriz simple: señal, fuente, población, ventana, umbral, posible impacto, falsos positivos conocidos, evidencia mínima, primera comprobación, acción segura, condición de escalamiento y responsable. Separa aviso, ticket y alerta urgente. Una métrica sin destinatario o una alerta sin acción solo aumenta ruido y fatiga.
Nunca interpretes un valor aislado sin denominador y versión. Cinco errores pueden ser materiales en diez propuestas y normales en cien mil intentos fallidos de un bot. Confirma cobertura del detector, volumen elegible, cambio reciente y segmento afectado. Si no puedes estimar el alcance, declara la incertidumbre y escala; no la conviertas en un porcentaje inventado.
Escribe el diagnóstico como un árbol de decisiones observable
Empieza por el síntoma que el operador puede comprobar, no por una causa supuesta. Por ejemplo: la propuesta muestra un precio inesperado. Verifica primero organización y moneda; después producto y versión de catálogo; luego fuente recuperada, permisos de edición, transformación, exportación y cambio reciente. En cada rama indica consulta, resultado esperado y destino siguiente.
Distingue hecho, inferencia e hipótesis. Captura identificadores y tiempos, no conversaciones completas. Si una consulta falla, el resultado contradice el árbol o aparece una condición no contemplada, detén la secuencia y escala con la evidencia disponible. Un buen árbol reduce búsqueda; no obliga a que la realidad encaje en una causa histórica.
Limita las acciones a operaciones aprobadas, reversibles y verificables
Para cada acción documenta objetivo, autoridad, alcance, comando o recorrido, parámetros permitidos, respaldo, efecto esperado, tiempo máximo, verificación, rollback y registro. Separa observar, contener, recuperar y corregir. Reiniciar un proceso puede recuperar disponibilidad, pero también borrar una señal o repetir una acción; no lo presentes como diagnóstico ni como corrección de causa.
Usa barandales: doble confirmación de organización y entorno, vista previa, límite por lote, idempotencia, aprobación para producción y stop conditions. Prohíbe cambios directos de datos, permisos amplios, limpieza de logs, desactivación global de controles y ejecución de comandos no revisados. Si el runbook requiere improvisar una variante, deja de ser una operación preautorizada.
Define un modo degradado que preserve el proceso comercial
El modo degradado no significa mantener todas las funciones a cualquier costo. Puede desactivar sugerencias, congelar una automatización, retirar una fuente, exigir aprobación adicional, ocultar una integración o volver a una plantilla manual. Indica disparador, autoridad, funciones disponibles, mensaje al usuario, capacidad máxima, controles compensatorios, datos que deben conservarse y criterio de salida.
Enlaza el plan de continuidad para objetivos de recuperación, dependencias y conciliación. El runbook solo explica cómo entrar, operar y salir del nivel autorizado. No prometas que el modo manual elimina el riesgo: puede introducir duplicados, etapas desactualizadas o documentos sin vínculo. Mantén un registro de operaciones pendientes y reconcilia antes de normalizar.
Haz que el escalamiento sea una decisión, no una búsqueda de contactos
Define rutas por impacto, sistema y horario: responsable funcional, operación, aplicación, datos, seguridad, privacidad, proveedor y dirección. Para cada ruta incluye canal, respaldo, tiempo de reconocimiento y paquete mínimo: qué ocurre, desde cuándo, población, versión, evidencia, acciones realizadas, cambios recientes, riesgo de continuar y decisión solicitada.
Activa el proceso de incidentes cuando se cumplan criterios acordados: impacto visible, riesgo para datos o dinero, propagación, indisponibilidad material, posible abuso, varios equipos o diagnóstico sin límite temporal. La persona que escala conserva el contexto hasta que la contraparte acepte explícitamente. Enviar un mensaje a un canal no equivale a transferir responsabilidad.
Mantén una bitácora suficiente, protegida y útil para decidir
Registra hora, actor, rol, señal, alcance, versión, consultas, resultados, decisiones, acciones, aprobaciones, verificaciones, estado y enlaces a evidencia. Usa tiempos comparables y una fuente de verdad. Preserva logs relevantes antes de una operación que pueda rotarlos. Marca lo desconocido; completar huecos con memoria horas después produce una cronología limpia pero falsa.
Minimiza datos: utiliza identificadores, fragmentos redactados y repositorios con acceso y retención. No copies prompts, documentos de clientes o tokens en chats de operación. El objetivo es demostrar qué se observó y por qué se decidió, no crear un segundo almacén de información comercial o personal.
Cierra cada turno con una entrega explícita y aceptada
La entrega resume estado del servicio, alertas activas, incidentes o problemas, cambios recientes, acciones en curso, modo degradado, workarounds, riesgos, decisiones pendientes, próximos tiempos y enlaces. Separa lo observado de lo supuesto. La persona entrante revisa accesos y repite las comprobaciones críticas; no hereda una conclusión solo porque aparece en la bitácora.
Nombra quién conserva la responsabilidad y pide aceptación explícita. Si nadie acepta, escala al responsable de la cobertura; no cierres el turno dejando una tarea huérfana. Para una operación sin guardias 24/7, documenta igualmente el estado al final del día, el canal de emergencia y qué puede esperar hasta la siguiente ventana.
Prueba el runbook y retíralo cuando deje de representar la realidad
Ensaya procedimientos en un entorno seguro con una persona que no los escribió. Mide si identifica el documento correcto, cumple precondiciones, interpreta resultados, se detiene a tiempo, conserva evidencia, escala y revierte. Incluye ramas de fallo: acceso ausente, panel sin datos, proveedor caído, versión distinta y resultado ambiguo. Un ensayo que solo recorre el camino feliz valida formato, no operación.
Versiona dueño, aprobador, fecha, cambios, sistemas compatibles, último ensayo, hallazgos y próxima revisión. Revisa después de cambios de arquitectura, permisos, proveedor, política, incidente o workaround. Retira enlaces y copias antiguas. Mide uso, éxito, desvíos, tiempo hasta escalamiento, pasos obsoletos y deuda generada; no premies ejecutar más runbooks si las mismas tareas deberían automatizarse o eliminarse.
Usa una plantilla breve y enlaza el detalle que cambia con frecuencia
La plantilla puede contener: objetivo; alcance; dueño; versión; precondiciones; riesgos; entradas; pasos numerados; resultado esperado por paso; condición de alto; acción segura; rollback; evidencia; escalamiento; modo degradado; comunicación; entrega; referencias; último ensayo; próxima revisión. Coloca al inicio lo que una persona necesita durante los primeros minutos.
Evita manuales interminables. Divide por tarea y utiliza nombres que empiecen con un verbo: verificar recuperación, aislar una fuente, activar revisión manual o conciliar operaciones pendientes. Mantén consultas y automatizaciones junto al código cuando corresponda, con revisión y control de versión. El runbook debe apuntar a la fuente vigente, no convertirse en una captura congelada de ella.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuál es la diferencia entre un runbook y un playbook?
El runbook describe pasos verificables para una tarea conocida y acotada. El playbook organiza decisiones, roles y opciones para un escenario que puede variar. Un playbook de incidentes puede enlazar varios runbooks, pero no debe convertir una respuesta compleja en una secuencia automática sin juicio.
¿Qué tan detallado debe ser un runbook operativo?
Debe permitir que una persona autorizada ejecute la tarea sin depender de la memoria del autor. Incluye precondiciones, pasos, resultados esperados, límites, evidencia, reversión y escalamiento. Si explica toda la arquitectura, divídelo; si exige adivinar parámetros o resultados, complétalo.
¿El runbook debe incluir contraseñas o API keys?
No. Debe indicar el nombre lógico del secreto, el rol que puede solicitarlo y el mecanismo aprobado de acceso temporal. Guardar credenciales, tokens o enlaces de sesión dentro del documento amplía exposición y dificulta rotación, auditoría y revocación.
¿Cuándo debe dejarse el runbook y declararse un incidente?
Cuando se alcance un criterio acordado: impacto material o visible, riesgo para datos o dinero, propagación, posible abuso, acción irreversible, participación de varios equipos o diagnóstico sin límite claro. La transferencia debe ser explícita y conservar evidencia y estado.
¿Con qué frecuencia se debe probar y actualizar?
Define una cadencia según criticidad y cambio, y prueba además después de modificar arquitectura, permisos, proveedores, políticas o recorridos. También revisa tras incidentes y cuando un operador encuentra una rama no contemplada. Cada versión necesita dueño, fecha y evidencia del último ensayo.