Checklist de deploy para pasar un piloto a producción

Muchos pilotos funcionan en la demo y nunca llegan a operar. Esta guía reúne lo que debe estar listo antes del deploy y un plan semanal de ejemplo para ordenar el trabajo.

Mateo Pizaialabs.app · publicado 15 oct 2026

Qué significa "en producción"

Un agente está en producción cuando cumple tres condiciones:

1. Procesa casos reales sin que el equipo del proyecto lo vigile.
2. Tiene un dueño en la operación que responde por él.
3. Si falla, alguien se entera y hay un plan para volver atrás.

Si falta una, sigue siendo piloto.

Criterios de salida del piloto

Defínelos antes de empezar el piloto. Ejemplo de criterios, con valores que debes fijar tú:

• Tasa de errores críticos igual a cero en las últimas dos semanas.
• Tasa de resolución autónoma por encima de la meta acordada.
• Costo por tarea por debajo del costo manual.
• Tiempo de aprobación humana dentro del límite acordado.
• El dueño de la operación firma que el flujo le sirve.

Sin criterios escritos, el piloto se extiende sin fecha.

Checklist técnico

Datos e integraciones

• Conexiones a sistemas con cuentas de servicio de mínimo permiso
• Credenciales en gestor de secretos
• Manejo de límites de tasa, paginación y timeouts
• Escrituras idempotentes
• Mapa de datos con fuente de verdad

Comportamiento del agente

• Prompts y configuración versionados
• Herramientas acotadas y tipadas
• Política de aprobaciones en código
• Set de pruebas con casos reales anonimizados
• Set de pruebas de seguridad, incluida inyección de instrucciones
• Resultado de pruebas como condición del pipeline

Observabilidad

• Log por tarea con los campos de medición
• Tablero con las cinco métricas del agente
• Alertas por errores, colas detenidas y tareas que no corrieron
• Registro de costos de modelo y APIs

Operación

• Botón de pausa global, probado
• Plan de rollback a la versión anterior o al proceso manual
• Bandeja de excepciones con responsable y suplente
• Manual corto para el equipo: qué hace el agente, qué no, a quién escalar
• Horario de soporte acordado

Datos personales y cumplimiento

• Inventario de datos que trata el agente
• Finalidad y autorización revisadas con tu asesor
• Tabla de retención y borrado implementada
• Términos del proveedor del modelo revisados

El lanzamiento gradual

No pases de cero a cien. Ejemplo de escalones:

1. Modo sombra. El agente procesa casos reales y propone, pero no ejecuta. Comparas sus propuestas con lo que hizo tu equipo.
2. Porcentaje pequeño. El agente ejecuta en un segmento acotado, por ejemplo 10% de los casos o un tipo de cliente.
3. Ampliación. Subes el porcentaje cuando las métricas se mantienen.
4. Total. El proceso manual queda como respaldo.

Cada paso hacia adelante requiere que las métricas estén dentro de umbral. Cada paso atrás es una decisión normal del proceso.

Plan semanal de ejemplo: tres semanas

Este es un plan de referencia para un flujo acotado, con accesos y datos disponibles desde el día uno. Es un ejemplo. El plazo real depende de tus sistemas, tus datos y la disponibilidad de tu equipo.

Semana 1 de ejemplo: build y pruebas

• Accesos y cuentas de servicio.
• Herramientas y flujo principal.
• Set de pruebas con casos históricos.
• Log y tablero básicos.

Semana 2 de ejemplo: modo sombra

• El agente propone sobre casos reales.
• Revisión diaria de diferencias con el equipo.
• Ajuste de reglas, umbrales y textos.
• Pruebas de seguridad y de rollback.

Semana 3 de ejemplo: lanzamiento gradual

• Segmento pequeño en ejecución real.
• Monitoreo diario de métricas.
• Capacitación del equipo y entrega del manual.
• Revisión de criterios de salida con el dueño.

Si una semana no cierra sus puntos, la siguiente no empieza. Mover la fecha es mejor que lanzar sin controles.

Señales de que no estás listo

Revisa estas señales antes de fijar la fecha:

• Nadie del equipo de operación ha visto el agente funcionando con casos reales.
• Las métricas existen solo en una hoja que alguien actualiza a mano.
• El rollback depende de una sola persona del proyecto.
• Las pruebas de seguridad se corrieron una vez y no están en el pipeline.
• Hay accesos pendientes de aprobación en algún sistema.

Cada señal se convierte en una tarea con responsable. La fecha se fija cuando la lista queda vacía.

Después del deploy

La fase de medir y mejorar empieza aquí:

• Revisión semanal de métricas durante el primer mes.
• Revisión mensual de motivos de escalamiento.
• Muestra de casos para control de calidad.
• Registro de cambios de configuración con fecha y responsable.

Errores comunes

• Criterios de salida definidos al final.
• Lanzar al 100% el primer día.
• Sin dueño en la operación.
• Rollback nunca probado.
• Prometer una fecha antes de conocer los accesos y los datos.

Preguntas frecuentes