Respuesta directa
En pocas palabras
Para hacer una revisión post-incidente de un AI Sales Copilot, define alcance y facilitación; preserva evidencia; reconstruye una cronología con hechos y niveles de confianza; mide el impacto técnico, comercial y humano; distingue el evento desencadenante de las condiciones que permitieron o ampliaron el incidente; evalúa detección, contención, decisiones, recuperación y comunicación; identifica controles que fallaron o no existían; convierte cada hallazgo en una acción con dueño, fecha, prioridad, evidencia de cierre y retest; documenta el riesgo residual; comparte conclusiones según la audiencia; y actualiza playbooks, monitoreo, capacitación y gobierno. El objetivo es mejorar el sistema, no atribuir culpa individual.
El review debe mejorar el sistema, no producir una explicación cómoda
Una revisión post-incidente convierte lo ocurrido en cambios verificables. No es una recapitulación del ticket ni una reunión para señalar a quien ejecutó la última acción. Busca comprender por qué las condiciones técnicas, operativas y organizacionales permitieron el impacto y qué debe cambiar para reducir recurrencia o limitar sus consecuencias.
Incluye incidentes confirmados, recuperaciones difíciles y near-misses con aprendizaje material. NIST AI RMF recomienda documentar errores, incidentes, reparaciones y cambios para sostener mejora continua. El resultado útil no es una causa única: es un conjunto priorizado de decisiones, controles y pruebas con responsables visibles.
Abre la revisión cuando el sistema esté estable y la evidencia siga disponible
No interrumpas contención o recuperación para celebrar la reunión. Inicia la preparación cuando el servicio y las personas afectadas estén razonablemente estables, pero antes de perder logs, memoria operativa, mensajes, versiones o datos de proveedores. Define fecha para el borrador y otra para validar acciones.
Delimita periodo, organizaciones, funciones, versiones, datos, integraciones y recorridos comerciales. Indica qué queda fuera y por qué. Separa el estado del servicio, el cierre de la investigación y la remediación completa: pueden ocurrir en momentos distintos.
Reúne perspectivas del recorrido completo
Incluye a quienes detectaron, respondieron, decidieron, operaron el modo alterno, atendieron clientes y conocen el componente afectado. Según el caso pueden participar Ventas, RevOps, soporte, datos, producto, ingeniería, seguridad, privacidad, legal, riesgo y proveedores. Una sola función suele ver únicamente una parte de la cadena.
Nombra una persona facilitadora que no necesite defender una implementación concreta. Establece reglas: hechos antes que interpretaciones, desacuerdo registrado, lenguaje preciso y ninguna represalia por reportar una señal. Recoge aportes por escrito cuando zona horaria, jerarquía o idioma puedan limitar la conversación.
Construye un inventario de evidencia antes de contar la historia
Referencia alertas, logs, métricas, versiones, cambios, tickets, decisiones, mensajes, propuestas, actividad de Buyer Rooms, registros del CRM y comunicaciones con proveedores. Conserva hora y zona horaria, fuente, responsable, integridad, acceso y retención. No pegues secretos ni datos personales innecesarios en el documento.
Distingue evidencia directa, inferencia e información no disponible. Una apertura no prueba identidad, lectura, aceptación, firma o pago. Un proveedor recuperado no demuestra que las colas y datos propios estén conciliados. Declara las limitaciones para que el informe no convierta ausencia de datos en certeza.
Reconstruye una cronología factual con puntos de decisión
Registra evento inicial conocido, primera señal, detección, clasificación, escalamiento, contención, cambios de alcance, modo manual, recuperación, comunicación y cierre operativo. Para cada punto incluye hora, hecho, fuente, decisión, persona responsable e información disponible en ese momento.
No reescribas decisiones con conocimiento posterior. Pregunta qué señales eran visibles, qué supuestos se usaron y qué alternativa era viable entonces. Marca huecos y conflictos en lugar de resolverlos por consenso. Una cronología honesta muestra también demoras, handoffs y caminos paralelos.
Mide el impacto sin mezclar alcance confirmado y potencial
Describe funciones interrumpidas, organizaciones y personas confirmadas, datos, propuestas, precios, permisos, etapas o comunicaciones afectadas. Separa impacto técnico, operativo, comercial, humano, contractual y reputacional. Mantén monedas separadas y evita atribuir pérdida de ingresos sin una comparación válida.
Registra duración de cada estado y capacidad del proceso alterno. Diferencia lo confirmado, lo estimado y lo todavía desconocido. Si existió una corrección a clientes, indica versiones y destinatarios localizados sin publicar información sensible.
Separa desencadenante, causas contribuyentes y condiciones latentes
El desencadenante es el evento que inició la secuencia; no siempre explica por qué produjo impacto. Analiza cambios de modelo, prompt, código, datos, permisos, integraciones, pruebas, monitoreo, capacidad, documentación, handoffs e incentivos. Evita detenerte en “error humano”: pregunta qué diseño permitió que una acción razonable tuviera ese resultado.
Usa técnicas como cinco porqués o árbol causal como apoyo, no como fórmula para fabricar una causa única. Conserva hipótesis rivales y evidencia que las sostiene o descarta. Si no existe prueba suficiente, escribe causa no determinada y crea una acción para cerrar la observabilidad faltante.
| Criterio | Pregunta | Ejemplo |
|---|---|---|
| Desencadenante | ¿Qué inició la secuencia? | Se activó una nueva configuración |
| Condición contribuyente | ¿Qué permitió o amplió el impacto? | La prueba no cubría el recorrido de propuestas |
| Condición latente | ¿Qué debilidad organizacional permanecía? | No había dueño ni gate para ese cambio |
Evalúa detección, decisiones, contención y recuperación como capacidades
Compara lo ocurrido con playbooks y expectativas aprobadas. Revisa si la alerta llegó a la persona correcta, si la clasificación fue comprensible, si la autoridad de parada funcionó, si la matriz de recuperación ofreció opciones viables y si el modo manual tenía capacidad real.
Registra qué funcionó y debe conservarse. Mide tiempos solo dentro de condiciones comparables; un tiempo menor no demuestra mejor respuesta si el alcance fue distinto. Analiza además comunicaciones, dependencia de terceros, calidad de la evidencia y puntos donde una decisión esperó información o aprobación.
Relaciona cada hallazgo con el control que debía prevenir, detectar o limitar
Para cada condición identifica si existía un control preventivo, detectivo, correctivo o de recuperación; cuál era su objetivo; qué evidencia debía producir; y por qué no evitó o limitó el resultado. Distingue control ausente, diseño insuficiente, ejecución fallida y evidencia incapaz de demostrar eficacia.
No respondas a todos los hallazgos con capacitación. Puede ser apropiada cuando falta competencia, pero no reemplaza límites técnicos, permisos, pruebas, monitoreo o una autoridad clara. Prioriza cambios que reduzcan dependencia de memoria y esfuerzo heroico.
Convierte hallazgos en acciones correctivas pequeñas y comprobables
Cada acción necesita verbo, alcance, dueño, fecha, prioridad, dependencia, evidencia esperada y criterio de cierre. “Mejorar monitoreo” no es ejecutable. “Agregar alerta por escritura fuera del alcance, probarla con tres casos autorizados y vincularla al on-call” permite revisar resultado.
Separa contención ya aplicada, corrección inmediata y prevención estructural. Registra riesgo residual y quién lo acepta. Limita el número de acciones a las que realmente pueden financiarse y seguirse; una lista extensa sin capacidad oculta las decisiones importantes.
Cierra una acción por evidencia y retest, no por cambio de estatus
Define antes de implementar cómo se demostrará el resultado. Reproduce de forma segura la condición, ejecuta casos normales y adversos, valida permisos y datos, observa falsos positivos y confirma que el cambio no rompe otro recorrido. Usa datos sintéticos o entornos aislados cuando corresponda.
La persona que implementa puede aportar evidencia, pero una acción material merece revisión independiente según el riesgo. Si el retest falla, reabre la acción; si descubre otro riesgo, regístralo sin forzar el cierre original. Un ticket en verde no prueba eficacia.
Publica conclusiones adaptadas a la audiencia y protege la evidencia
El equipo necesita detalle para corregir; dirección necesita impacto, decisiones, riesgo residual y recursos; Ventas y soporte necesitan cambios operativos; clientes afectados necesitan hechos y acciones relacionados con su alcance. No copies el documento interno completo a todas las audiencias.
Corrige comunicaciones anteriores si la investigación cambió hechos materiales. Evita atribuir culpa, revelar secretos o prometer que un incidente nunca volverá a ocurrir. Los requisitos legales, contractuales y regulatorios dependen del caso y deben evaluarse por las funciones competentes.
Devuelve el aprendizaje al ciclo de gobierno y comprueba su permanencia
Actualiza registro de riesgos, inventario, evaluación de impacto, pruebas, monitoreo, change management, continuidad, recuperación, comunicación y capacitación. Busca incidentes o near-misses similares en otros componentes y proveedores. Una corrección local puede dejar intacta la misma condición en otra ruta.
Revisa acciones vencidas y eficacia después de un periodo adecuado. Reporta bloqueos y recursos, no solo porcentajes de cierre. En Cerravi, Copilot propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente, no inventa precios y mantiene monedas separadas. La organización conserva responsabilidad sobre investigación, comunicación y acciones.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuándo debe hacerse la revisión post-incidente?
Cuando la contención y recuperación ya no dependan de la reunión, pero antes de perder evidencia y memoria operativa. Deben fijarse fechas para el borrador, la validación y el seguimiento de acciones.
¿Es obligatorio encontrar una sola causa raíz?
No. Un incidente suele combinar desencadenantes, condiciones contribuyentes y debilidades latentes. Si la evidencia no permite una conclusión, debe documentarse la incertidumbre y mejorar observabilidad.
¿Qué diferencia existe entre corrección y acción preventiva?
La corrección resuelve la condición inmediata; una acción preventiva modifica controles, procesos o arquitectura para reducir recurrencia o impacto en escenarios relacionados.
¿Cuándo puede cerrarse una acción?
Cuando el cambio está implementado, existe evidencia reproducible, el retest pasa, se revisan regresiones, el monitoreo tiene responsable y el riesgo residual queda aceptado por la autoridad correspondiente.
¿El informe debe compartirse completo con clientes?
No necesariamente. Cada audiencia recibe el detalle útil y autorizado. La comunicación externa debe basarse en hechos comprobados y requisitos aplicables, sin exponer evidencia sensible ni datos de otras organizaciones.