En los últimos tres años, hemos trabajado con docenas de empresas mid-market en proyectos de automatización con IA. El patrón se repite con una regularidad que ya no sorprende: un POC brillante, entusiasmo ejecutivo, presupuesto aprobado. Y luego, seis meses después, el sistema nunca llegó a producción. O llegó, pero nadie lo usa. O lo usaron dos meses y volvieron a Excel.
No es un problema de tecnología. La tecnología funciona. El problema es metodológico, y se manifiesta en cinco patrones que hemos identificado analizando qué falló en cada caso.
El patrón que se repite
Los proyectos de IA en empresas mid-market tienden a fallar en uno de dos momentos: entre la demo y el primer sprint real, o entre la primera entrega técnica y la adopción operativa. En ambos casos, el código es técnicamente correcto. Lo que falla es todo lo que rodea al código.
Hemos rescatado proyectos, los hemos construido desde cero, y hemos visto fracasar otros desde cerca. En todos los casos de fracaso, encontramos al menos una de estas cinco causas. Con frecuencia, más de una.
Causa 1: Empezar a construir antes de entender el problema
Es la causa más frecuente y también la más cara. Una empresa identifica una oportunidad de automatización, procesar solicitudes de cliente, clasificar documentos, generar informes automáticos, y contrata un equipo para construirla. Sin haber cuantificado el problema.
¿Cuánto tiempo lleva el proceso actual? ¿Cuántas veces al día ocurre? ¿Cuál es el coste de un error? ¿Qué porcentaje del volumen requiere intervención humana por casos edge? Sin estas métricas, no puedes saber si la inversión tiene retorno. Y sin ese diagnóstico inicial, el equipo técnico construye contra un problema mal definido.
Un diagnóstico bien hecho no es un paso que puedas saltarte. Es la diferencia entre construir algo que el negocio adopta y construir un prototipo caro que nadie usa.
En los proyectos donde hemos empezado con un diagnóstico cuantificado (tiempo de proceso, volumen, coste por error, tasa de excepciones) la probabilidad de llegar a producción es significativamente mayor. No porque el diagnóstico haga el proyecto más sencillo técnicamente. Sino porque alinea al equipo técnico y al equipo de negocio sobre qué problema se está resolviendo realmente.
Causa 2: El alcance técnico y el alcance de negocio van por separado
Este patrón aparece en empresas con buenos equipos técnicos internos. Los ingenieros toman decisiones correctas en aislamiento: eligen el modelo, diseñan la arquitectura, definen los endpoints. Pero sin validar continuamente si eso es lo que el equipo de operaciones necesita para trabajar con el sistema el día a día.
A los dos meses de construcción, el sistema hace exactamente lo que el equipo técnico entendió que se pedía. Pero no es lo que operaciones necesitaba para adoptarlo. El coste: reconstruir funcionalidades ya entregadas, alargar plazos, perder la confianza de los stakeholders.
El antídoto es simple pero incómodo: demos cada dos semanas con los responsables de operaciones, no solo con IT. Y la voluntad de cambiar prioridades cuando la demo revela desalineación. Los equipos que evitan las demos frecuentes porque 'ralentizan el desarrollo' son los que más tarde se dan cuenta de que construyeron en la dirección equivocada.
Causa 3: Los datos de demo no son los datos de producción
Este es el más difícil de diagnosticar porque los síntomas aparecen tarde. El agente funciona perfectamente en desarrollo: los prompts dan los resultados esperados, los casos de prueba pasan, la demo al CEO sale bien. Luego se conecta a los datos reales de producción y el rendimiento cae un 40%.
Los datos limpios de un dataset de prueba no representan los datos contradictorios, incompletos y mal formateados que existen en cualquier sistema de producción real. Los agentes evaluados solo contra datos limpios no sobreviven el contacto con la realidad. No porque el modelo sea malo. Porque nunca fue evaluado contra el problema real.
La solución: desde el primer sprint, evaluar contra una muestra real de datos de producción. No en la fase de QA. No en el último mes antes del go-live. Desde el inicio, con los datos más sucios y difíciles que pueda proporcionar el cliente.
Causa 4: No hay nadie que pueda operar el sistema después de la entrega
La entrega formal ocurre. El sistema está en producción. El equipo externo cierra el proyecto. Tres semanas después, el sistema tiene un comportamiento inesperado en un caso edge y nadie en la empresa sabe qué parámetro tocar, dónde mirar las métricas ni cómo interpretar los logs.
Hay tres versiones de este problema. Primera: el sistema no tiene documentación técnica real, solo el código. Segunda: el equipo interno tiene la documentación pero no tiene el contexto de las decisiones de diseño que la hacen interpretable. Tercera: el sistema tiene observabilidad pero nadie fue formado para interpretar las métricas. Las tres versiones acaban igual: el sistema queda congelado en la versión que se entregó, incapaz de evolucionar.
Causa 5: El proyecto no tiene dueño claro dentro de la empresa
El más silencioso de los cinco. El proyecto existe porque el CEO quería explorar IA. IT lo implementó porque se les pidió. Operaciones lo usa porque se les pidió. Pero nadie dentro de la empresa siente que el sistema sea suyo. Nadie tiene incentivo para impulsar su adopción, y cuando aparecen los primeros problemas operativos, no hay nadie que los priorice frente al resto de la agenda.
Los proyectos sin dueño interno no mueren por un fracaso técnico. Mueren de abandono lento. No porque el sistema falle. Porque nadie lo defiende cuando compite por atención con el resto de problemas del negocio.
Lo que se puede hacer
Ninguna de estas cinco causas es inevitable. Todas tienen contramedidas concretas que se aplican desde el inicio del proyecto, no como parches al final:
- Diagnóstico cuantificado antes de comprometerse a construir: tiempo de proceso, volumen, coste por error, tasa de excepciones.
- Sprints de dos semanas con demo al equipo de operaciones en cada ciclo, no solo a IT.
- Evaluación contra datos de producción desde el primer sprint, con los casos más difíciles del cliente.
- Documentación técnica incremental entregada con cada release, no acumulada para el final.
- Identificar al dueño interno (con nombre y apellidos) antes de firmar el proyecto.
Si estás planificando un proyecto de IA y alguno de estos patrones te resulta familiar, es una señal que puedes actuar antes de que ocurra. La diferencia entre los proyectos que llegan a producción y los que no rara vez está en la tecnología elegida. Está en si alguien se hizo estas preguntas antes de empezar a construir.