Cierre de acciones del postmortem de IA: checklist de seguimiento en 14 días

Es jueves, 16:40 CT. El postmortem blameless del incidente de clasificación ya está firmado: timeline claro, causas en modelo/prompt/datos, y una lista de nueve “acciones”. Tres semanas después, seis siguen en “investigar más”, dos no tienen dueño y una se cerró sin verificar el criterio de done. El aprendizaje operativo no falló en el documento; falló en el cierre.

Este texto es el complemento práctico del marco de postmortem blameless de incidentes de IA. No redefine qué es blameless ni reescribe la plantilla. Asume que el postmortem ya existe. Aquí el foco es convertir hallazgos en acciones con dueño, fecha, verificación y cierre en un horizonte de 14 días —y conectarlas con change control, SLOs y error budget.

De hallazgo a acción: la ficha mínima (5 campos)

Cada acción del postmortem debe caber en una ficha que el on-call y producto entiendan sin contexto extra. Si no puedes completar estos cinco campos, aún no es una acción: es una intuición.

• Dueño único. Una persona con mandato (no un canal, no “el equipo de IA”). Puede delegar ejecución; no puede delegar accountability.
• Fecha de compromiso. Día concreto dentro de la ventana de 14 días (o un hito intermedio a día 7). Sin fecha, la acción se diluye.
• Criterio de done. Qué evidencia cierra el ítem: merge + canary verde, umbral actualizado en change control, runbook publicado, métrica X ≥ Y por N días.
• Verificación. Quién confirma el done (preferible: alguien distinto al dueño) y con qué artefacto (dashboard, ticket, diff, muestreo).
• Vínculo de riesgo. Qué causa raíz o modo de falla mitiga, y si afecta SLO, error budget o change control.

Regla corta: si no hay criterio de done, no abras el ticket. “Investigar más” sin hipótesis y sin fecha de corte no entra a la lista de cierre.

Checklist de seguimiento a 14 días (día 0 → 7 → 14)

Día 0 (cierre del postmortem, <24 h):

• Publicar la lista de acciones con los cinco campos; archivar en el mismo ticket/canal del incidente.
• Marcar qué acciones son bloqueantes (evitan recurrencia inminente) vs mejoras (reducen riesgo residual).
• Si una acción toca modelo, prompt, umbral o retrieval, abrir ítem de change control antes de desplegar.
• Actualizar el board de error budget: ¿la acción reduce burn, endurece guardrails o solo documenta?

Día 7 (review intermedio, 20–30 min):

• Estado por acción: en curso / bloqueada / lista para verificar / cerrada.
• Desbloquear: ¿falta acceso, decisión de producto, capacidad? Asignar desbloqueador con fecha.
• Recortar o reformular acciones eternas: partir en un entregable verificable a día 14 y un backlog explícito.
• Si el burn del SLO sigue alto, priorizar solo acciones que reduzcan exposición (contención, umbral, HITL) antes que refactors.

Día 14 (cierre formal):

• Verificar cada done con evidencia; cerrar o rechazar (no “casi listo”).
• Registrar residual: qué quedó abierto, con nuevo dueño/fecha fuera de la ventana si aplica.
• Una línea de aprendizaje al board o ritual de gobierno: qué cambió en el sistema, no solo en el ticket.

Anti-patrones que matan el cierre

• Acciones eternas. “Mejorar la calidad del modelo” sin métrica, sin fecha y sin alcance. Sustituye por: “subir precision@k en segmento X de A→B con canary 10% para el día 10”.
• “Investigar más” como destierro. La investigación es válida si tiene hipótesis, dueño, artefacto de salida y fecha de corte. Si no, es procrastinación documentada.
• Dueño colectivo. “Data + ML + producto” = nadie. Un nombre; el resto colabora.
• Cerrar por actividad, no por evidencia. Un PR mergeado sin canary ni muestreo no es done si el criterio pedía verificación en producción.
• Lista inflada. Más de 5–7 acciones activas en 14 días suele indicar falta de priorización. Parquea el resto con etiqueta “backlog post-incidente”.
• Desconectarse de SLOs. Si la acción no mueve latencia, calidad o burn —ni endurece un control— cuestiona por qué está en la ventana crítica.

Ritual de review a 7 y 14 días (agenda mínima)

Misma cadencia, distinta profundidad. Dueño del ritual: el owner del servicio (no el facilitador del postmortem, salvo que sea la misma persona).

1. Contexto (3 min). Incidente, SLO tocado, estado del error budget, freeze activo o no.
2. Tablero de acciones (10–12 min). Una frase por ítem: estado, evidencia, riesgo si se atrasa.
3. Decisiones (5–8 min). Cancelar, partir, reasignar o escalar. Nada de “seguimos viendo” sin fecha.
4. Change control / producción (3 min). Qué se desplegará antes del día 14 y con qué guardrails.
5. Cierre del ritual (2 min). Próxima cita; dueño de actualizar el ticket en <1 h.

En el review de día 14, añade un minuto de “¿aprendimos algo que deba vivir en runbook, umbral o checklist de deploy?”. Ese minuto es el puente entre postmortem y gobierno continuo.

Plantilla de acción (cópiala al ticket)

• Acción: [verbo + objeto + alcance] — ej. “Endurecer umbral de auto-aprobación del flujo B de 0.72 a 0.80 en prod con canary 15%”.
• Dueño / verificador: [nombre] / [nombre distinto].
• Fecha compromiso / review: día 7 checkpoint; done ≤ día 14.
• Criterio de done: [métrica o artefacto] — ej. “canary sin regresión de falsa aceptación > baseline; change control aprobado; muestreo n=200 verde”.
• Mitiga: [causa raíz del postmortem] → impacto esperado en SLO/error budget.
• Estado: abierta | bloqueada (motivo) | en verificación | cerrada (enlace evidencia).

Tip operativo: mantén el tablero de acciones del postmortem en el mismo lugar donde vive el freeze y el change control del servicio. Si el seguimiento queda en un doc paralelo que nadie abre, el ritual de día 7 se convierte en arqueología. Un enlace fijo en el canal on-call y un recordatorio automático bastan para que el cierre compita en atención con el siguiente deploy.

Cierre

Un postmortem blameless sin cierre de acciones es teatro operativo: alivia la culpa y deja intacto el riesgo. La disciplina de 14 días —fichas con dueño y done, reviews a día 7 y 14, anti-patrones explícitos y vínculo con change control y SLOs— es lo que convierte el aprendizaje en menor probabilidad de repetición. Si todavía estás armando el marco del postmortem, empieza por el artículo de mediodía; si ya lo tienes, toma el incidente más reciente y fuerza la lista a cinco acciones verificables antes del próximo jueves a las 16:40.

En NextWave (de Punto Reactivo) ayudamos a equipos mid-market en México y LatAm a cerrar el loop entre incidentes, acciones y gobierno de IA en producción. Si quieres revisar el tablero de seguimiento de un flujo concreto, escríbenos en nextwave.mx.