Del go/no-go a producción: controles de gobierno, ownership y criterios de escala para IA

El comité dijo go. Hay baseline, umbrales y una bitácora que sobrevivió al día 30. El riesgo ahora no es “falta evidencia”: es pasar a producción sin controles de gobierno, sin dueños claros y sin criterios de escala. En mid-market México, ese salto suele convertirse en un segundo piloto eterno o en un modelo en vivo que nadie audita. Este artículo cierra el arco del piloto y abre el pilar de gobierno operativo: qué congelar el día después del go/no-go.

Para patrocinadores, líderes de operaciones y TI que ya tienen un go (o un pivot con alcance reducido) y necesitan un marco práctico de ownership, auditoría y escala —sin reinventar políticas abstractas de ética.

Por qué el go no es un permiso para “encender y olvidar”

El plan de evidencia responde: ¿valió la pena en el segmento del piloto? La producción responde: ¿podemos sostenerlo, auditarlo y crecerlo sin romper el negocio? Tres fallas típicas post-go:

• Ownership difuso: el data scientist “cuida el modelo”, operaciones “usa el output” y nadie firma incidentes, drifts ni cambios de umbral.
• Controles de piloto que no migran: modo sombra, cola de excepciones y scorecard semanal se aflojan “porque ya salimos a prod”.
• Escala por entusiasmo: se abre un segundo canal o región sin checklist de datos, riesgo ni capacidad HITL.

Gobierno post-piloto no es un comité nuevo cada viernes. Es un sistema mínimo: dueños nombrados, controles que viajan con el caso de uso, registro auditable y criterios de escala escritos antes de pedir más tráfico.

Los cuatro controles que deben viajar del piloto a producción

Si el go se basó en evidencia, estos cuatro bloques ya existían en germen. En producción se vuelven obligatorios y versionados.

1. Contrato operativo del caso de uso

Una página viva (no un PDF olvidado) con: problema, segmento, KPI primario, guardrails, fuentes de datos, modo de decisión (automático / HITL / sombra residual) y techos de riesgo. Es el one-pager del piloto convertido en contrato de producción. Toda excepción permanente al contrato requiere cambio controlado, no un chat de Slack.

2. Controles de calidad en runtime

Defina umbrales de alerta que no dependan de “cuando alguien note algo raro”:

• Drift de input (mix de casos, completitud de campos del contrato de datos).
• Drift de output (distribución de scores, tasa de override humano, latencia).
• Guardrails de negocio (reclamos, retrabajo, costo por caso, incidentes de clase X).

El ritual semanal del scorecard sigue siendo el foro de lectura; en producción añade un canal de alerta temprana (día 1–2) para no esperar al viernes si un guardrail se rompe.

3. Cola de excepciones y cierre de loop

El human-in-the-loop no se apaga con el go: se dimensiona. Producción exige SLA de cola, criterios de escalamiento y un dueño que convierta excepciones resueltas en mejoras de modelo o de proceso. Sin eso, la automatización se come el margen en retrabajo invisible.

4. Registro de cambios y evidencia residual

Guarde versión de modelo/prompt/reglas, fecha de despliegue, umbrales activos y el paquete de evidencia del go. Cuando legal, auditoría interna o un cliente pregunte “¿por qué el sistema decidió X en septiembre?”, la respuesta no puede ser una captura de pantalla del notebook del piloto.

Ownership: RACI mínimo que sí se usa

Evite organigramas de 12 roles. Para un caso de uso en mid-market basta un RACI corto y nominativo (nombre + respaldo):

• Patrocinador de negocio (A): dueño del KPI y de la decisión de escala/pausa. Firma cambios de umbral que toquen riesgo o P&L.
• Product owner / dueño del proceso (R): mantiene el contrato operativo, prioriza excepciones y coordina el ritual semanal.
• Dueño técnico del modelo (R): despliegues, monitoreo de drift, rollback y calidad de scoring.
• Dueño de datos (C/R): integridad del contrato ERP/CRM u otras fuentes; valida que el segmento de producción sigue siendo el del go.
• Riesgo / cumplimiento (C): revisa incidentes de clase X y cambios que expandan perfil de riesgo (datos sensibles, decisiones automatizadas de alto impacto).

Regla práctica: si un incidente no tiene un Accountable con teléfono, no hay gobierno —hay esperanza. Publique el RACI junto al contrato operativo y actualícelo cuando cambie de persona, no “cuando haya tiempo”.

Auditoría ligera: qué revisar cada mes (sin teatro)

Una auditoría de IA en producción no necesita un framework de 80 controles el primer trimestre. Necesita un paquete mensual que el patrocinador pueda leer en 30 minutos:

1. Desempeño vs umbrales del go: ¿el KPI y los guardrails siguen en verde en el segmento autorizado?
2. Cambios del mes: modelos, prompts, umbrales, fuentes; con motivo y aprobador.
3. Excepciones e incidentes: volumen, tiempo de resolución, temas recurrentes y acciones de cierre de loop.
4. Cobertura HITL: ¿la cola está dimensionada o se está “apagando” por presión de costo?
5. Alcance real vs autorizado: ¿alguien metió otro canal, región o tipo de cliente sin pasar el checklist de escala?

Documente hallazgos con dueño y fecha. Si el mismo hallazgo reaparece tres meses, el problema ya no es el modelo: es el sistema de gobierno.

Criterios de escala: del segmento del go al siguiente bloque

Escalar no es “subir el porcentaje al 100%”. Es abrir un nuevo bloque de riesgo y de datos. Use un checklist go-to-scale (sí/no) antes de cada expansión:

• Evidencia estable: al menos N semanas post-go con KPI y guardrails en umbral (defina N en el contrato; típico mid-market: 4–6 semanas hábiles).
• Datos listos: contrato de datos del nuevo segmento validado; sin campos críticos nulos por encima del techo.
• Capacidad HITL: cola y turnos dimensionados para el volumen proyectado, no para el del piloto.
• Controles de runtime activos: alertas y dashboard del nuevo bloque, no solo del original.
• Riesgo revisado: perfil de decisión (impacto al cliente/empleado/caja) no empeora sin mitigación.
• Rollback listo: procedimiento de volver a modo sombra o a humano-only en < X horas, ensayado al menos una vez.

Si falla un ítem, la respuesta correcta es no escalar aún o escalar con canario más chico —no “prometer que lo arreglamos en vuelo”. El mismo rigor del go/no-go del piloto aplica a cada salto de escala; solo cambia el tamaño del bloque.

Mini ejemplo: post-go en triaje L1 (retail web Norte)

Suponga go en triaje L1 web Norte con HITL en excepciones. El día 1 de producción el equipo congela:

• Contrato operativo v1.0 (segmento, umbrales, techo de override).
• RACI: patrocinador de CX, PO de operaciones, dueño técnico, dueño de datos CRM.
• Alertas: override > techo 3 días seguidos; completitud de campos < piso; latencia p95 fuera de banda.

Semana 6 piden “meter también WhatsApp Sur”. El checklist de escala falla en datos (campos distintos) y en capacidad HITL (turno noche). Decisión: canario 10% WhatsApp Norte primero, no Sur; nuevo contrato de datos; revisión de riesgo en 2 semanas. Eso es gobierno aplicado: frena el entusiasmo sin matar el roadmap.

Errores comunes al “profesionalizar” el go

• Crear un comité de ética sin dueños de incidente: reuniones sin RACI ni alertas no reducen riesgo operativo.
• Apagar el modo sombra residual demasiado pronto: pierdes la señal de acuerdo modelo-humano justo cuando el mix de casos empieza a cambiar.
• Medir solo accuracy del modelo: en producción manda el KPI de negocio y los guardrails; la métrica de laboratorio es insumo, no veredicto.
• Escalar por slide de sponsor: sin checklist de datos/HITL/rollback, el siguiente incidente define tu política de IA.
• No versionar umbrales: si nadie sabe qué techo estaba activo el martes, la auditoría se vuelve narrativa.

Checklist de las primeras 2 semanas post-go

1. Publicar contrato operativo v1 y RACI nominativo.
2. Migrar controles del piloto (scorecard, excepciones, alertas) al entorno de producción.
3. Definir paquete mensual de auditoría ligera y calendario.
4. Escribir checklist go-to-scale y bloquear expansiones que no lo pasen.
5. Ensayar rollback (aunque sea en mesa) una vez.
6. Agendar la primera revisión de evidencia residual vs umbrales del go.

Cierre

El go/no-go demuestra valor en un segmento. La producción exige gobierno operativo: controles que viajan, ownership nominativo, auditoría ligera y criterios de escala falsificables. Sin eso, el piloto exitoso se diluye en excepciones, drifts y expansiones improvisadas. Con eso, cada nuevo bloque de tráfico se gana con el mismo rigor con el que se ganó el día 30.

Si su equipo ya tiene un go (o un pivot) y quiere bajar a tierra controles, RACI y checklist de escala para mid-market en México, escriba a contacto@nextWaveAI.AI o llame al +52 (33) 3126 6969.