El piloto es el experimento más valioso del proyecto — y lo más arriesgado de hacer mal. Equivocarse en el piloto es barato. Equivocarse en producción, caro. La diferencia está en cómo estructuras el piloto: con criterios de éxito definidos de antemano, alcance mínimo y una persona supervisando el proceso.
Flujo del piloto: el criterio de éxito se define antes, no después de ver los resultados.
🎯 Definir el éxito antes de empezar
Definir el criterio de éxito después de obtener los resultados garantiza un sesgo de confirmación. La la pregunta que responde el piloto debe estar escrita antes de cualquier ejecución.
✓ Criterio definido de antemano
- ✓"El modelo clasifica con >85% de precisión en 200 casos reales"
- ✓"El tiempo promedio de clasificación baja de 4h a <60min"
- ✓Evaluado en 4 semanas con datos de producción
✗ Criterio definido después
- ✗"Creemos que quedó bien"
- ✗"Al equipo le encantó usarlo"
- ✗Sin una cifra, no hay una decisión que se pueda justificar
📝 Plantilla de criterio de éxito
🔬 PoC vs. piloto vs. producción
Tres etapas, tres objetivos, tres conjuntos de datos diferentes. Mezclar las etapas es el origen de expectativas equivocadas que después destruyen el proyecto.
Prueba de concepto — "¿esto es posible?"
Datos de laboratorio, sin integración real y sin usuarios reales. Responde si la tecnología puede resolver el problema en condiciones ideales.
Duración: 1-2 semanas. Resultado: viable / inviable técnicamente.
Piloto: "¿esto funciona aquí?"
Datos reales, usuarios reales, pero con alcance y volumen controlados. Responde si la solución funciona en este contexto operativo específico.
Duración: 4-8 semanas. Resultado: evidencia para go/no-go.
Producción — "escalar con confianza"
Volumen completo, SLA definido, monitoreo en producción. El piloto validó que funciona — ahora escala.
Requisito previo: piloto con go aprobado. SLA y runbook documentados.
💡 Consejo práctico
Cuando presentes el PoC al cliente, deja claro: «Esto demuestra que la tecnología puede hacerlo, pero todavía no lo probamos con tus datos reales y tus usuarios. El piloto lo hace». Así gestionas las expectativas antes de que se conviertan en decepciones.
🔭 Alcance mínimo que aporta aprendizaje
El piloto ideal es el el experimento más pequeño que responde la pregunta más importante. No el más completo, no el más impresionante — el más inteligente.
✓ Alcance mínimo que enseña
- ✓Una categoría de tickets (no las 12)
- ✓Un departamento piloto (no toda la empresa)
- ✓200 casos reales (no 50.000)
- ✓Integración manual OK (la automatización viene después)
✗ Alcance inflado
- ✗Construir toda la integración antes de validar el modelo
- ✗Cubrir todos los casos de uso en el piloto
- ✗Piloto de 6 meses que no tiene fecha de decisión
💡 Pregunta de prueba del alcance
Antes de planear el piloto, pregunta: «¿Cuál es la pregunta más importante?». Luego: «¿Cuál es el experimento más pequeño que responde esa pregunta?». Todo lo que no responda esa pregunta queda fuera del alcance del piloto.
👤 Humano en el loop + plan de fallas
Durante el piloto, toda salida de la IA pasa por revisión humana. Esto no es ineficiencia: es el mecanismo que detecta los errores antes de que lleguen al cliente final y alimenta los datos para mejorar.
🔄 Estructura del humano en el loop
La IA procesa
genera resultados con confianza
Una persona revisa
aprueba, corrige o rechaza
Dato registrado
los errores se convierten en datos para mejorar
🚨 Plan de fallas — obligatorio
El plan de contingencia define qué sucede cuando la IA se equivoca o deja de estar disponible:
- →Quién revierte: responsable identificado por nombre, no por cargo
- →En cuánto tiempo: SLA de reversión (ej.: dentro de 2h)
- →Cómo continúa la operación: proceso manual temporal documentado
- →Cuándo activarlo: criterio claro (ej.: tasa de error >10% durante 1h)
📊 Medir vs. línea de base
La comparación entre antes y después es el único argumento que transforma la percepción en evidencia. La la métrica debe definirse con la misma definición de la línea de base — de lo contrario, estaremos comparando cosas distintas.
📐 Reglas para una comparación válida
Si la línea base midió "tiempo promedio de clasificación por ticket", el piloto mide lo mismo, no "tiempo total de clasificación del día".
Mide en semanas comparables (mismo volumen, misma estacionalidad). Evita comparar el lunes de la línea de base con el viernes del piloto.
Aislar qué cambió por causa de la IA frente a qué cambió por otras razones (equipo diferente, volumen diferente, capacitación).
📊 Qué documentar en el informe del piloto
🚦 Criterios go/no-go: escalar o descartar
La decisión de avanzar o no es la más importante del proceso. ¿Se cumplió el criterio? Go: escala aplicando lo aprendido. ¿No se cumplió? No-go: cancela o cambia de rumbo — sin culpas, con datos y próximos pasos claros.
🟢 GO — criterios cumplidos
Próximos pasos al decidir GO:
- • Actualizar el roadmap con lo que enseñó el piloto
- • Documentar las capacidades reutilizables generadas
- • Definir el SLA y el runbook para producción
- • Comunicar el resultado al sponsor con los datos
- • Planificar la Wave 2 con un alcance ampliado
🔴 NO-GO — criterios no alcanzados
Próximos pasos al decidir NO-GO:
- • Documentar por qué no funcionó (¿datos? ¿tecnología? ¿proceso?)
- • Evaluar si hay un pivot viable (¿alcance menor? ¿nivel diferente?)
- • Cancelar formalmente el proyecto si no hay pivot
- • Registrar los aprendizajes para los próximos pilotos
- • Comunicar al sponsor: "acabar con el proyecto fue la decisión correcta"
💡 Por qué descartar es un éxito
Un piloto que termina en no-go y se cancela cumplió exactamente con su propósito: dar la respuesta «no lo hagas» antes de gastar 10× más en producción. Esto protege el presupuesto, preserva la confianza y libera al equipo para el siguiente caso más prometedor. El consultor que logra cerrar un proyecto que no funciona es más valioso que quien lo deja continuar por inercia.
🎒 Resumen del módulo
Siguiente ruta:
RUTA 5 — Entrega y negocio de la consultoría