Hay un patrón que se repite con frecuencia en empresas medianas de manufactura, servicios o retail que deciden “implementar IA”: contratan a alguien, arrancan un piloto, y seis meses después el proyecto está congelado. No porque la tecnología fallara, sino porque nadie en la operación lo adoptó. El sistema existe, pero nadie lo usa.
Según Gartner, alrededor del 70% de los proyectos de IA no llegan a producción. En LatAm el porcentaje no es mejor — y las razones son más operativas que técnicas.
El fallo más común no es el modelo, es el contexto
Cuando un proyecto de IA muere, la conversación suele derivar hacia la herramienta: “el modelo no era preciso”, “la API era cara”, “el proveedor no entregó”. Pero si revisas el historial, casi siempre hay algo anterior: nadie definió qué significaba “funcionar”.
Una distribuidora de Monterrey con 180 empleados puede contratar un agente de IA para atender cotizaciones por WhatsApp. Si el objetivo es “reducir el tiempo de respuesta de 48 horas a menos de 2 horas en el 80% de los casos”, tienes una métrica. Si el objetivo es “modernizar la atención al cliente”, no tienes nada — tienes una intención, que no es lo mismo.
El segundo problema es la propiedad. En proyectos que sí funcionan, hay una persona de la operación — no de TI, no del director general — que tiene su nombre en el resultado. Alguien que pierde o gana en función de si el sistema funciona. Sin ese dueño, el proyecto flota entre áreas hasta que nadie lo reclama.
Por qué el equipo operativo sabotea sin querer
No es mala voluntad. Es que nadie los involucró en el diseño.
El escenario típico: el área directiva aprueba el proyecto, el proveedor construye el sistema, y el día del “lanzamiento” le explican al equipo operativo cómo usar la herramienta nueva. Para ese momento, el equipo ya tiene sus propias soluciones — un Excel, un grupo de WhatsApp, un proceso manual que conocen bien. La herramienta de IA les genera trabajo extra sin que vean el beneficio directo.
El comportamiento resultante no es resistencia activa — es inercia. Siguen usando lo que conocen. El sistema de IA genera outputs que nadie revisa, y en tres meses el dashboard está vacío.
Lo que vemos en Eurema con clientes de servicios profesionales es que los proyectos con mayor adopción son aquellos donde el equipo operativo participó en al menos dos sesiones de diseño antes de que se escribiera una sola línea de código. No para que “compren” el proyecto, sino porque saben cosas del proceso que el director general ignora y que el proveedor externo nunca va a descubrir solo.
Cómo se ve un proyecto que sí funciona
No se parece a una demo. Se parece a un proceso aburrido que antes tomaba 4 horas y ahora toma 40 minutos.
Cuatro señales concretas de que la adopción va bien:
- El equipo operativo reporta el problema cuando el sistema falla, no cuando funciona. Si nadie nota que el agente estuvo caído un día, nadie lo está usando.
- La métrica de negocio se mueve en las primeras 8 semanas. No necesita ser dramática — una reducción del 30% en tiempo de respuesta o 15 horas/semana liberadas del equipo ya justifica el proyecto.
- El sponsor ejecutivo deja de pedir demos y empieza a pedir el reporte semanal. Eso indica que el sistema ya es parte de la operación, no un experimento.
- Aparecen solicitudes de expansión desde abajo. El equipo empieza a preguntar “¿esto también se puede hacer con el agente?”. Eso no pasa si el sistema no les resuelve algo real.
El criterio que usamos en Eurema para evaluar si un piloto tiene condiciones para escalar es simple: ¿el equipo operativo lo usa sin que nadie se los recuerde? Si la respuesta es sí después de 30 días, el proyecto tiene futuro. Si no, hay que revisar el diseño antes de invertir más.
El rol de la capacitación (y lo que no es)
Capacitación de IA no es enseñarle a tu equipo a usar ChatGPT. Eso es un taller de 2 horas, no una estrategia.
Capacitación real es que el equipo entienda qué tipo de tareas la IA hace bien, cuáles hace mal, y cómo detectar un output incorrecto. Una persona de contabilidad que sabe que un modelo de lenguaje puede alucinar fechas y montos va a revisar el output con criterio. Una que solo sabe que “la IA es muy lista” va a confiar ciegamente — y eso es un riesgo operativo, no una ventaja.
En proyectos de Capacitación AI bien estructurados, la secuencia importa: primero el equipo entiende los límites del sistema, luego aprende a usarlo, luego aprende a mejorarlo. Saltarse el primer paso es el error más caro.
Para empresas que están evaluando si sus equipos tienen la base para adoptar IA, el punto de partida no es un curso — es un diagnóstico de qué procesos ya están documentados y cuáles dependen de conocimiento tácito que nadie ha escrito. La IA no puede automatizar lo que no está definido.
Qué hacer si tu proyecto ya está atorado
Si tienes un piloto de IA que lleva más de 3 meses sin uso real, hay tres preguntas que vale la pena responder antes de seguir invirtiendo:
- ¿Quién pierde algo concreto si el sistema no funciona? Si la respuesta es “nadie directamente”, el problema es de gobernanza, no de tecnología.
- ¿El proceso que automatizaste estaba documentado antes del proyecto? Si no, el sistema probablemente automatizó el caos, no el proceso.
- ¿El equipo operativo puede describir en dos oraciones qué hace el sistema? Si no pueden, no lo adoptaron — lo toleran.
Esas respuestas suelen señalar dónde está el problema real. A veces es rediseñar el flujo. A veces es cambiar el caso de uso. Y a veces es reconocer que el proceso en cuestión no era el candidato correcto para automatizar — y elegir otro.
Si quieres revisar si tu operación tiene las condiciones para una adopción que dure, la página de Capacitación AI de Eurema describe cómo trabajamos ese diagnóstico con equipos B2B en LatAm.