El patrón que se repite
Una empresa de manufactura mediana en España invierte tres meses en un piloto de IA para automatizar la conciliación de facturas con su ERP. El proveedor entrega el agente. El equipo lo prueba. Funciona en el 60% de los casos. El otro 40% genera excepciones que alguien tiene que resolver a mano. El piloto se abandona. La conclusión interna: "la IA no está lista para esto."
Doce meses después, otro proveedor llega con una propuesta similar. El ciclo se repite.
El problema no fue la tecnología. Fue que nadie mapeó el proceso real antes de construir nada.
Este patrón es más común de lo que parece. Y tiene una causa estructural: los proveedores de IA tienen incentivos para llegar rápido a la demo, no para hacer preguntas incómodas sobre cómo funciona realmente el proceso que van a tocar.
Por qué el diagnóstico no ocurre
Cuando un proveedor llega a una reunión de ventas, su objetivo inmediato es mostrar capacidad. La demo impresiona. El caso de uso parece evidente. La propuesta llega en una semana.
Lo que no ocurre en ese ciclo es la pregunta más importante: ¿cómo funciona este proceso hoy, incluyendo todo lo que no está documentado?
Porque la respuesta a esa pregunta suele revelar tres cosas que complican la venta:
1. El proceso tiene más excepciones de las que el equipo recuerda. Lo que parece una regla simple —"si la factura coincide con el pedido, se aprueba"— tiene en la práctica una docena de variantes que el equipo gestiona de forma tácita. Nadie las escribió. Están en la cabeza de dos personas.
2. Los datos de entrada no tienen la calidad que se asume. Los PDFs llegan con formatos distintos. Los campos del ERP tienen valores inconsistentes. Las fechas se registran de tres maneras diferentes según quién lo cargó.
3. El criterio de éxito no está definido. ¿Qué significa que el piloto "funcione"? ¿80% de automatización? ¿Cero errores? ¿Reducción de tiempo del equipo? Sin ese número acordado antes de empezar, cualquier resultado puede interpretarse como fracaso.
Un proveedor que hace estas preguntas antes de proponer está, en efecto, retrasando su propio cierre. Por eso la mayoría no las hace.
Qué debería ocurrir antes de cualquier piloto
El diagnóstico previo no es un ejercicio académico. Es una sesión de trabajo de dos a cuatro horas con las personas que operan el proceso, con el objetivo de responder cuatro preguntas concretas:
¿Cuál es el proceso real, no el documentado? Esto implica seguir una transacción de principio a fin, incluyendo los pasos informales, las correcciones manuales y las decisiones que se toman "por criterio".
¿Dónde están las excepciones y qué volumen tienen? Si el 30% de los casos requiere intervención humana por razones que no se pueden codificar, ese piloto va a tener un techo de automatización del 70% desde el primer día. Saberlo antes permite diseñar el agente de forma realista.
¿Qué calidad tienen los datos de entrada? Un agente que procesa facturas necesita que esas facturas sean legibles, estructuradas y consistentes. Si no lo son, el problema a resolver primero es de datos, no de IA.
¿Cuál es el criterio de éxito medible? No "que funcione bien", sino un número: porcentaje de casos procesados sin intervención, horas de equipo liberadas por semana, reducción de errores en el cierre mensual.
Con esas cuatro respuestas, el diseño del piloto cambia completamente. El alcance se ajusta. Las expectativas se alinean. Y el criterio de éxito existe antes de que se escriba una línea de código.
Un ejemplo con hipótesis de ROI
Considere una empresa de distribución alimentaria con un equipo de administración de cinco personas que dedica entre 15 y 20 horas semanales a conciliar albaranes, facturas y pedidos entre su ERP y las hojas de cálculo que usan los comerciales.
Un diagnóstico previo de tres horas revela que el 65% de esas transacciones son completamente rutinarias y siguen siempre el mismo patrón. El 35% restante tiene excepciones, pero el 20% de esas excepciones responde a tres reglas específicas que sí se pueden codificar.
Resultado esperado del piloto bien diseñado: automatización del 80–85% del volumen total. Liberación estimada de 12 a 16 horas semanales del equipo. A un costo de oportunidad conservador de 25 €/hora, eso representa entre 15.000 y 20.000 € anuales en capacidad recuperada, sin contar la reducción de errores en el cierre mensual.
Sin el diagnóstico previo, ese mismo piloto se habría construido asumiendo que el 100% del proceso era automatizable. El resultado habría sido un agente que falla en el 35% de los casos, un equipo frustrado y una conclusión incorrecta sobre la viabilidad de la IA.
Lo que esto implica para su próxima evaluación
Si está considerando un segundo piloto de IA —o evaluando propuestas para el primero— hay una pregunta que puede hacer antes de avanzar con cualquier proveedor:
¿Qué diagnóstico de proceso hacen antes de proponer el alcance?
Si la respuesta es "la demo cubre eso" o "lo vemos durante la implementación", tiene información relevante sobre cómo va a terminar ese proyecto.
El diagnóstico previo no garantiza el éxito del piloto. Pero su ausencia casi garantiza que los problemas que aparezcan durante la implementación eran predecibles desde el principio.
La diferencia entre un piloto que se abandona y uno que llega a producción suele medirse en horas de trabajo previo, no en la sofisticación de la tecnología.
Conclusión
El segundo piloto falla por las mismas razones que el primero cuando nadie cambia el paso que antecede a la construcción. La tecnología mejora. Los proveedores se multiplican. Pero el proceso de diagnóstico sigue siendo el eslabón que más se omite y el que más determina el resultado.
Si quiere evaluar si su próximo caso de uso de IA tiene las condiciones para funcionar en producción, el punto de partida es un diagnóstico honesto del proceso, no una demo.
Solicite un diagnóstico gratuito con OuroAI. En 15 minutos identificamos si su caso tiene las condiciones para un piloto con resultado medible.
