Implementa un primer flujo de IA en 15 días sin convertirlo en un proyecto eterno

Días 1 y 2: elige una fricción, no una tecnología. Reúne a las personas que ejecutan el trabajo y pregunta qué tarea se repite, tarda demasiado o pierde información. Describe el problema con una unidad concreta: responder consultas, preparar propuestas, clasificar documentos o confirmar citas. Evita empezar con “necesitamos un agente”. Define cuánto volumen existe, cuánto tiempo consume y qué error es frecuente. El caso ideal ocurre varias veces por semana, tiene datos accesibles y permite comprobar si el resultado fue correcto sin una discusión interminable.

Días 3 y 4: dibuja el flujo actual. Registra entrada, pasos, decisiones, excepciones y salida. Identifica qué información usa cada persona y dónde la encuentra. El objetivo no es crear un manual perfecto, sino descubrir ambigüedades antes de codificarlas. Marca en verde lo que puede automatizarse con reglas, en amarillo lo que necesita interpretación y en rojo lo que requiere aprobación humana. El primer piloto debería incluir pocos puntos amarillos y mantener los rojos bajo control. La claridad del mapa reduce cambios posteriores.

Días 5 al 7: construye la versión mínima. Usa una sola fuente de datos, una plantilla de instrucción y una salida definida. No conectes cinco sistemas si puedes probar el valor con uno. Crea ejemplos correctos y ejemplos difíciles. Define qué debe hacer el sistema cuando faltan datos o la confianza es baja. Incluye un registro de lo que recibió y produjo. La versión mínima no necesita parecer terminada; necesita demostrar que el flujo puede repetirse con suficiente calidad y que una persona puede revisar el resultado.

Días 8 al 11: prueba con trabajo real. Ejecuta el flujo en paralelo con el proceso actual. No uses únicamente casos seleccionados. Incluye variaciones, errores de escritura, documentos incompletos y solicitudes fuera de alcance. Registra tiempo total, cantidad de correcciones, casos escalados y resultado final. Pregunta a los usuarios qué parte genera desconfianza o trabajo adicional. Ajusta instrucciones y campos, pero evita ampliar el alcance. Si aparece un caso nuevo, anótalo para una siguiente versión en lugar de convertir el piloto en un proyecto infinito.

Días 12 al 14: decide con evidencia. Compara el piloto contra la línea base. Calcula minutos ahorrados, porcentaje de resultados aceptados y costo mensual estimado. Revisa riesgos: privacidad, acceso, dependencia del proveedor y continuidad cuando el sistema falla. Define quién será responsable de mantenerlo. La decisión puede ser ampliar, ajustar o detener. Detener un piloto que no aporta valor también es un buen resultado porque evita una inversión mayor basada en entusiasmo. Documenta lo aprendido aunque no continúe.

Día 15: publica la siguiente versión del proceso. Si el caso funcionó, establece un responsable, una revisión semanal y límites de uso. Capacita con ejemplos reales y explica cuándo escalar. Escribe una página con objetivo, entrada, salida, métricas y cambios permitidos. Después elige la siguiente mejora, no el siguiente juguete. Un proyecto corto debe dejar una capacidad operativa y una forma de evaluar futuras automatizaciones. La velocidad sirve cuando produce aprendizaje y una decisión clara, no cuando solo genera una demostración atractiva.