Bitácora de evidencia del piloto de IA: qué registrar cada semana hasta el go/no-go

El plan de evidencia del piloto ya fijó baseline, métricas líderes y retrasadas, y umbrales go/no-go a 30 días. Aun así, el día 30 llega y el comité improvisa: faltan capturas semanales, el baseline “se actualizó” sin traza y nadie puede armar el decision pack en 48 horas. Este artículo es el complemento operativo de ese plan: la bitácora de evidencia —un ritual semanal corto que convierte el marco del día 0 en registro continuo hasta la decisión.

Para equipos mid-market en México que ya tienen charter y criterios falsificables, y necesitan que la evidencia no dependa de la memoria del sponsor ni de un folder suelto en Drive.

Del plan de evidencia a la bitácora semanal

El plan responde qué se medirá y con qué umbral se decide. La bitácora responde qué se registró cada semana, quién lo firmó y qué anomalía obligó a intervenir. Sin bitácora, el go/no-go se vuelve narrativa; con bitácora, se vuelve expediente.

Tres reglas para que no se diluya:

• Una fuente de verdad (hoja, ticket o wiki versionada). No “versión del área” vs “versión del partner”.
• Cierre semanal en 30–45 minutos, no un reporte de 20 slides. Si tarda más, sobran campos.
• Dueño nombrado por campo: proceso, datos, modelo/controles y sponsor. Cargos genéricos no firman.

La bitácora no reescribe el plan de evidencia ni el one-pager: los consume. Tampoco sustituye el scorecard semanal de P&L; lo alimenta con hechos del piloto.

Campos que registrar cada semana

Use un bloque fijo. Si un campo no se puede llenar, eso ya es señal: o el instrumento de medición falló, o el alcance se movió sin gobernanza.

1. Identificación y ventana

Semana del piloto (S1–S4/S5), fechas de inicio/fin, versión del one-pager y del plan de evidencia. Sin esto, mezclan corridas y el baseline pierde validez.

2. Volumen y cobertura

Casos procesados (sombra o producción controlada), % del segmento in-scope cubierto y exclusiones justificadas. Si el volumen cae sin explicación, el go/no-go del día 30 no es comparable al baseline.

3. Métricas líderes (leading)

Las mismas del plan: precisión en holdout o sombra, tasa de override, latencia de cola de excepciones, completitud de campos críticos. Capture valor de la semana, delta vs semana previa y vs baseline. Un número sin delta no sirve para intervenir a tiempo.

4. Métricas retrasadas (lagging) disponibles

Solo las que ya existen en el horizonte del piloto (ciclo, reclamos, rework, costo por caso). Si aún no maduran, registre “N/D + fecha esperada”; no invente proxies ad hoc cada viernes.

5. Incidentes y excepciones

Conteo por clase (datos, modelo, proceso, riesgo), top 3 causas y si cerraron o siguen abiertas. Amárrelo a la cola de excepciones y al cierre del loop: excepción resuelta sin aprendizaje no entra como mejora.

6. Cambios de alcance, datos o modelo

¿Se movió el in/out? ¿Cambió el feed? ¿Hubo redeploy? Cada cambio debe citar fecha, dueño y si invalidó parcial o total la comparabilidad con baseline. El plan de evidencia ya advirtió esto; la bitácora lo hace auditable.

7. Semáforo vs umbrales go/no-go

Para cada umbral del plan: verde / amarillo / rojo + una frase de causa. Amarillo dos semanas seguidas sin plan de corrección es rojo disfrazado.

8. Acciones de la semana siguiente

Máximo cinco. Dueño, fecha y métrica que deben mover. Si la lista crece, priorice: la bitácora no es backlog de producto.

Dueños y ritual de cierre (45 minutos)

RACI mínimo de la bitácora:

• Dueño de proceso (R): llena volumen, excepciones de negocio y acciones.
• Dueño de datos (R): valida cobertura, completitud y cambios de feed.
• Responsable de modelo/controles (R): leading metrics, overrides, redeploys.
• Sponsor (A): valida semáforo y desbloquea si hay rojo en umbral crítico.

Agenda sugerida: 10 min lectura del bloque numérico, 15 min excepciones y cambios, 10 min semáforo vs umbrales, 10 min acciones. Congelar el archivo al cerrar (timestamp + versión). Sin freeze, el decision pack del día 30 se arma con números “movidos”.

Plantilla mínima de bitácora (copia y adapta)

Una fila por semana basta. Columnas recomendadas:

• Semana / fechas / versión charter
• Volumen & cobertura %
• Leading #1, #2, #3 (valor, Δ semana, Δ baseline)
• Lagging disponibles
• Incidentes abiertos / cerrados
• Cambios que afectan baseline (sí/no + nota)
• Semáforo por umbral go/no-go
• Acciones (dueño, fecha)
• Firmas (proceso, datos, modelo, sponsor)

Ejemplo hipotético mid-market (triaje L1, semana 2): volumen 1 240 tickets web retail (82% del in-scope); precisión sombra 91% (baseline 88%, umbral go 90%); override 7% (techo 10%, amarillo la semana previa en 9%); un cambio de mapeo de canal documentado el martes sin invalidar holdout; acciones: reforzar regla de mayoreo mal etiquetado (Ops, viernes).

Red flags a mitad del piloto

Intervenga antes del día 30 si aparece cualquiera de estas señales:

• Bitácora vacía o “se llenará el viernes” dos semanas seguidas: no hay operación de evidencia; pause el relato de avance.
• Baseline reescrito sin change log: el go/no-go pierde validez; vuelva al plan de evidencia y reaplique umbrales o reinicie reloj con transparencia al sponsor.
• Leading en rojo y lagging “aún no” eterno: o el horizonte del piloto es irreal, o están midiendo vanity. Ajuste alcance o instrumentación, no el discurso.
• Cambios de modelo/datos sin congelar métricas: comparan peras con manzanas; marque la semana como no comparable.
• Cola de excepciones creciendo sin cierre del loop: el HITL se volvió depósito; active el ritual de aprendizaje antes de pedir go.
• Sponsor ausente del semáforo: el día 30 será teatro. Escalone una revisión corta en S2 y S3.

Cómo armar el decision pack para el go/no-go

Setenta y dos horas antes de la reunión, el dueño de proceso ensambla un paquete corto a partir de la bitácora —no un deck nuevo:

1. One-pager vigente (alcance y umbrales sin reescribir).
2. Plan de evidencia con baseline original y definición de métricas.
3. Serie semanal (tabla o gráfica simple) de leading/lagging y semáforos.
4. Log de cambios que afectaron comparabilidad.
5. Top excepciones y aprendizajes cerrados (cierre del loop).
6. Recomendación: go / no-go / go condicionado, con la evidencia que la sostiene y los riesgos residuales.

En la reunión: 20 minutos de hechos, 20 de decisión, 10 de next steps. Si alguien pide “una demo más”, recuerde el contrato: el piloto se juzga por umbrales, no por narrativa. Un go condicionado exige dueño, fecha y métrica; no es un “sí emocional”.

Disciplina hasta el día 30 sin improvisar

El plan de evidencia define el tribunal. La bitácora semanal llena el expediente. Con campos fijos, dueños, semáforo vs umbrales y un decision pack armado desde el registro —no desde la memoria—, el go/no-go deja de ser una sorpresa de calendario.

En Next Wave AI acompañamos a equipos en México a operar pilotos con evidencia: del one-pager y el plan de baseline/umbrales a la bitácora semanal y el decision pack. Si quiere instalar este ritual en su piloto actual, escríbanos a contacto@nextWaveAI.AI o llame al +52 (33) 3126 6969.