El go del piloto ya dejó ownership, controles y criterios de escala. El siguiente riesgo operativo no es “falta gobierno en el papel”: es cambiar el modelo, el prompt o un umbral en producción sin change control. En mid-market México, un ajuste “rápido” del viernes suele romper el contrato operativo del lunes. Este artículo es el complemento práctico del marco de gobierno post-go: un checklist de change control corto para actualizaciones que tocan decisión, riesgo o P&L.
Para product owners, dueños técnicos y patrocinadores que ya operan un caso de uso en producción (o están a días de hacerlo) y necesitan un runbook usable —no una política de 40 páginas.
Qué cuenta como “cambio” (y qué no)
Change control no es burocracia para cada typo en un dashboard. Es el filtro cuando el cambio puede alterar el comportamiento del sistema frente al cliente, el riesgo residual o la comparabilidad con la evidencia del go.
- En scope: nueva versión de modelo o prompt, cambio de umbral de score/decisión, inclusión/exclusión de features o campos del contrato de datos, ampliación de segmento/canal, apagado o relajación de HITL, rollback a versión previa.
- Fuera de scope (con registro ligero): fixes de visualización, renombres internos, ajustes de logging que no cambian la decisión, rotación de credenciales sin cambio de lógica.
Regla de oro: si el output que ve operaciones o el cliente puede diferir para el mismo input, es change control. Si solo cambia cómo se observa, basta un ticket y un commit.
Los cinco estados del pipeline
Mantenga un flujo visible (tablero o wiki versionada) con estados fijos. Cada cambio ocupa una sola tarjeta.
- Propuesto: descripción, motivo de negocio, impacto esperado en KPI/guardrails, y vínculo al contrato operativo.
- Revisado: dueño técnico + dueño de proceso validaron datos, pruebas y plan de rollback.
- Aprobado: Accountable del RACI (patrocinador o delegado documentado) firma si toca umbral, segmento o riesgo de clase X.
- Desplegado: versión, timestamp, entorno y evidencia de smoke test en producción controlada.
- Monitoreado: ventana de observación cerrada (verde) o incidente abierto con dueño.
No permita saltos “urgente → desplegado” sin al menos revisión + rollback escrito. La urgencia se acelera en la cola de aprobación, no borrando estados.
Checklist previo al despliegue (15–20 minutos)
Use esta lista como puerta. Si un ítem falla, el cambio no pasa a “Aprobado”.
1. Identidad del cambio
- ID único, título en una línea, tipo (modelo / prompt / umbral / datos / alcance / HITL).
- Versión origen → versión destino (hash, tag o ID de prompt).
- Caso de uso y segmento afectados (exactamente los del contrato operativo).
2. Motivo y métrica
- Problema que resuelve (incidente, drift, mejora de KPI, deuda técnica con dueño).
- Hipótesis falsificable: “esperamos mover X en ±Y sin romper guardrail Z”.
- Referencia a scorecard o bitácora si el cambio nace de un rojo/amarillo.
3. Evidencia de prueba
- Holdout, sombra o replay sobre muestra representativa del segmento autorizado.
- Comparativa vs versión actual: tasa de override, distribución de scores, latencia, tasa de excepciones.
- Casos límite documentados (top 5 fallas conocidas) y resultado esperado.
4. Riesgo y cumplimiento
- ¿Expande perfil de riesgo (datos sensibles, decisión automática de alto impacto)? Si sí, visto bueno de riesgo/cumplimiento.
- ¿Invalida parcial o total la evidencia residual del go? Si sí, plan de re-baseline o ventana de observación extendida.
- ¿Requiere comunicar a operaciones/legal/cliente interno? Canal y mensaje listos.
5. Plan de rollback
- Comando o procedimiento para volver a la versión previa en < N minutos (defina N; típico: 30).
- Criterios automáticos de aborto en las primeras horas (p. ej. override > umbral, incidentes clase X, latencia).
- Dueño on-call nombrado para la ventana de monitoreo.
6. Capacidad HITL y operaciones
- Cola de excepciones dimensionada para el comportamiento esperado post-cambio.
- Guión de operaciones actualizado (qué hacer si el score “se ve distinto”).
- Confirmación de que no se apaga HITL “para compensar” un despliegue dudoso.
Quién aprueba qué (RACI de change control)
Reutilice el RACI de gobierno; no invente otro comité. Solo precise umbrales de firma:
- Dueño técnico (R): prepara paquete, pruebas y rollback; ejecuta el despliegue.
- Dueño de proceso (R/C): valida impacto en flujo, excepciones y comunicación a usuarios internos.
- Patrocinador (A): aprueba cambios de umbral, segmento, modo de decisión (auto vs HITL) o cualquier ítem que toque P&L/riesgo.
- Riesgo/cumplimiento (C): obligatorio si hay clase X, datos sensibles o expansión de alcance.
- Dueño de datos (C): si el cambio altera fuentes, features o contratos ERP/CRM.
Para hotfixes de seguridad o caída total del servicio: el Accountable puede aprobar verbalmente con registro en <2 horas (ticket con hora, motivo y rollback). “Verbal sin ticket” no existe.
Ventana de monitoreo post-despliegue
El cambio no termina en “Desplegado”. Defina una ventana mínima (p. ej. 48–72 h hábiles para mid-market) con tres lecturas:
- Hora 0–4: smoke + alertas de runtime (drift de output, errores, latencia).
- Día 1: override, excepciones y tickets de operaciones vs baseline de la semana previa.
- Cierre de ventana: semáforo vs hipótesis; si amarillo/rojo, rollback o contención documentada —no “esperemos al ritual del viernes”.
Al cerrar en verde, archive el paquete (versión, aprobadores, métricas, incidentes cero o lista) junto al registro de cambios del contrato operativo. Ese archivo es la materia prima de la auditoría mensual ligera.
Plantilla mínima de ticket (copiar/pegar)
- ID / tipo / versiones
- Motivo + hipótesis + KPI/guardrail
- Segmento afectado
- Evidencia de prueba (link)
- Riesgo clase / visto bueno requerido
- Rollback (pasos + dueño on-call)
- Aprobadores (nombres, no cargos)
- Ventana de monitoreo y criterios de aborto
- Estado actual en el pipeline
Si el ticket no cabe en una pantalla, sobra narrativa. Change control bueno es denso y corto.
Anti-patrones que rompen el gobierno post-go
- “Es solo un prompt”: un prompt en producción es lógica de decisión. Trátelo como código versionado.
- Umbral movido en silencio: cambiar el corte para “mejorar el KPI” sin patrocinador es fraude al scorecard.
- Despliegue viernes 19:00 sin on-call: si no hay dueño en la ventana, no hay aprobación real.
- Rollback imposible: si no puede volver atrás, no es release: es apuesta.
- Dos versiones en paralelo sin etiqueta: operaciones no sabe qué está juzgando; la bitácora se vuelve inútil.
Cómo encaja con el gobierno de producción
El artículo de mediodía fijó controles, ownership y criterios de escala. Este checklist operacionaliza el registro de cambios y el contrato operativo: cada release deja traza, cada umbral tiene firma y cada incidente de cambio tiene dueño. Sin change control, el RACI es decoración y la auditoría mensual no tiene de qué hablar.
Empiece con el pipeline de cinco estados y la plantilla de ticket en el próximo cambio —aunque sea “menor”. En dos sprints tendrá un hábito auditable. Si necesita ordenar gobierno, ownership y escala de IA en operación real, en Next Wave México acompañamos a equipos mid-market a convertir el go del piloto en un sistema de producción con controles que sí se usan.
Add comment