Cómo elegir el primer proceso para un piloto de IA

Buscar una fricción concreta

El primer proyecto no necesita representar toda la transformación de la empresa. Necesita resolver una fricción que el equipo pueda describir y medir. Solicitudes que llegan incompletas, consultas repetidas sobre un estado o tareas que pierden contexto entre áreas son buenos puntos de análisis. Antes de elegir, observar casos reales y preguntar qué trabajo se repite. Una demo llamativa puede ocultar que el proceso cambia cada semana o que nadie conoce la fuente correcta de información; esas condiciones dificultan aprender de un piloto.

Evaluar valor y preparación

Comparar candidatos con dos preguntas: cuánto esfuerzo o incertidumbre generan y qué tan preparados están para un cambio. La preparación incluye reglas claras, información disponible, responsables y una salida humana para excepciones. Un proceso valioso pero desordenado puede requerir primero simplificación. Otro menos visible puede ofrecer aprendizaje útil porque tiene inicio, cierre y datos verificables. Evitar elegir únicamente por volumen: una categoría frecuente con situaciones muy distintas puede resultar más compleja que otra donde el mismo recorrido se repite de manera consistente.

Escribir una hipótesis comprobable

La hipótesis debe relacionar un cambio con un resultado observable. Por ejemplo: preparar el contexto antes del traspaso reducirá las preguntas repetidas del equipo receptor. Definir cómo se contará una pregunta repetida y qué casos se compararán. También registrar condiciones que podrían explicar diferencias, como complejidad o canal. No hace falta prometer una cifra antes de tener una referencia. El piloto es una manera de medir, no una confirmación anticipada de que cualquier automatización ahorrará tiempo o producirá el resultado esperado.

Limitar alcance y preparar salida

Especificar categorías incluidas, fuentes, acciones permitidas y decisiones que siguen con el equipo. El plan debe indicar cómo detectar fallas y volver al procedimiento habitual. Un piloto que solo funciona cuando alguien lo vigila sin descanso puede trasladar trabajo en vez de eliminarlo. Registrar la intervención necesaria ayuda a evaluar esa carga. También conviene definir quién revisará resultados y qué evidencia permite ampliar, ajustar o detener el proceso. Así el cierre no depende de una impresión general sobre si la demostración se vio bien.

La entrega del piloto

Entregar casos evaluados, errores encontrados, carga de revisión, cambios necesarios y una recomendación argumentada. Una decisión de no ampliar todavía también es útil si revela qué información, reglas o responsables hacen falta. El aprendizaje debe quedar disponible para el siguiente proceso que se evalúe.

Ejemplo ilustrativo: comparar tres candidatos para el primer piloto

Imagina una empresa hipotética que tiene tres ideas: responder preguntas frecuentes de envíos, calificar solicitudes de cotización y conciliar facturas. El equipo escribe, para cada una, quién es el dueño, qué datos existen, qué decisión sigue siendo humana y cómo se vería un caso bien resuelto.

Las preguntas frecuentes de envíos tienen inicio y cierre claros, la fuente es un sistema consultable y quien las atiende hoy puede revisar excepciones. Las cotizaciones dependen de criterios que todavía discuten dos áreas. La conciliación es valiosa, pero maneja datos sensibles y carece de responsable único. El equipo no elige la más vistosa: elige la que combina valor y preparación, y deja las otras con una tarea previa asignada, por ejemplo aclarar los criterios de cotización antes de pensar en automatizarla.

Errores frecuentes al elegir el primer proceso

Los pilotos suelen tropezar por decisiones tomadas antes de empezar, no por la tecnología. Estas son las más comunes y la señal que permite detectarlas a tiempo.

• Elegir el proceso más visible para impresionar: si nadie puede definir un caso exitoso, no se podrá evaluar.
• Empezar sin dueño. Cuando surge una excepción y nadie decide, el piloto se detiene o improvisa.
• Medir solo con la demostración. Pide casos reales, incompletos y contradictorios.
• No definir cuándo se detiene el piloto. Escribe de antemano qué resultado llevaría a ampliar, ajustar o parar.
• Olvidar la carga de revisión: si alguien vigila todo el día, el trabajo solo cambió de lugar.

Lista para decidir si el proceso está listo para un piloto

Antes de comprometer tiempo, responde estas preguntas con evidencia observable y no con intuiciones. Si dos o tres respuestas son negativas, el siguiente paso probablemente sea preparar el terreno, no lanzar el piloto.

Un proceso con canal de WhatsApp o web necesita además una decisión sobre el horario de atención humana, la forma de traspaso con resumen y las reglas del proveedor para iniciar conversaciones. Esas condiciones se verifican con el proveedor vigente y se anotan en el plan, para que el equipo no descubra un límite a mitad del piloto.

• ¿Puedo describir en una frase qué significa un caso bien resuelto?
• ¿Hay una persona con autoridad para decidir las excepciones?
• ¿Los datos necesarios están en un lugar consultable y actualizado?
• ¿Tengo una referencia del desempeño actual para comparar?