Cada vez que una empresa arranca un proyecto de IA, lo primero que hace es sacar el manual mental que ya conoce: el que usó para el CRM, para el ERP, para cualquier software que haya implementado antes. Define un presupuesto fijo, fija una fecha de go-live, capacita al equipo, y espera que el sistema funcione desde el primer día y siga funcionando igual el resto del año. Es una lógica razonable. También es la razón por la que tantos proyectos de IA terminan decepcionando a quien los pagó.
Lo vemos constantemente. No porque las empresas hagan mal su trabajo, sino porque están aplicando el marco correcto a la herramienta incorrecta.
La diferencia de fondo
Un CRM o un ERP son sistemas de reglas fijas. Los configuras una vez, capacitas al equipo, y el sistema hace lo mismo todos los días bajo las mismas condiciones. Si algo cambia en el negocio, alguien entra y ajusta una regla. El sistema no aprende nada por sí mismo, y tampoco se espera que lo haga.
La IA, sobre todo la IA agéntica, opera distinto. Aprende de cada interacción, se ajusta con nueva información, y necesita afinación continua para seguir siendo útil conforme el negocio cambia alrededor de ella. No se instala y se usa. Se entrena, se supervisa y se mantiene.
Tratar ambos sistemas con la misma lógica de proyecto es donde empieza el problema.
El go-live engañoso
En un ERP, el go-live es la línea de meta. El proyecto termina, el sistema queda andando, y el equipo de implementación se retira.
En un proyecto de IA, el go-live es apenas el punto de partida. El modelo empieza a operar con datos reales, empieza a mostrar dónde falla, y ahí es donde arranca el trabajo de verdad: ajustar, corregir, entrenar con lo que el negocio real le está enseñando. Las empresas que celebran el go-live como si fuera el cierre del proyecto son las que después se preguntan por qué el sistema "dejó de funcionar bien" a los pocos meses. Nunca dejó de funcionar. Simplemente nadie siguió entrenándolo.
El error de presupuesto
Ese mismo malentendido se refleja en cómo se presupuestan estos proyectos. Un ERP se cotiza como un gasto único: licencia, implementación, capacitación, y ya. Cuando una empresa aplica esa misma lógica a un proyecto de IA, presupuesta el entrenamiento inicial y se olvida de que el sistema necesita mantenimiento continuo para seguir generando el valor que prometía.
No es un tema de que la IA sea más cara. Es un tema de que el gasto tiene una forma distinta: en vez de un pico grande al inicio y silencio después, requiere una inversión más pequeña pero constante en el tiempo. Esa diferencia se nota más en operaciones donde la información no vive en un solo lugar. Cuando parte del negocio sigue operando por llamadas telefónicas, hojas sueltas o coordinación informal entre personas, un sistema de IA no solo tiene que aprender el proceso una vez, tiene que seguir ajustándose cada vez que esa realidad dispersa cambia de forma. Presupuestarlo como gasto único asume que el negocio se queda quieto después del go-live, y ningún negocio se queda quieto.
Las empresas que presupuestan IA como si fuera un ERP terminan sin margen para esa segunda etapa, justo cuando el sistema más lo necesita. El resultado es previsible: el sistema funciona bien en la demo, pierde precisión con el tiempo, y nadie entendió que perder precisión era parte esperada del proceso, no una falla.
El caso de TRAXION
Un caso reciente ilustra bien este patrón. Cuando Grupo TRAXION llegó a modernizar su sistema de movilidad, el plan original venía pensado con esa lógica de proyecto cerrado: una inversión, un despliegue, un cierre. El diagnóstico que se hizo antes de tocar una sola línea de código mostró algo distinto. Lo que se necesitaba no era un sistema que se instalara y quedara fijo, sino uno que siguiera ajustándose conforme la operación crecía.
Parte de esa operación dependía de información que vivía repartida en llamadas y coordinación manual entre equipos, exactamente el tipo de realidad que un presupuesto de gasto único no alcanza a cubrir. Un sistema entrenado una sola vez sobre esa dispersión habría quedado obsoleto en meses. Por eso el proyecto se planeó distinto desde el inicio: no como una instalación con fecha de cierre, sino como una capacidad que se sigue afinando conforme la operación cambia.
De ahí salió MIND, con 75 oportunidades identificadas y 7 equipos trabajando en paralelo para atenderlas. El sistema no se detuvo en el go-live. Siguió expandiéndose de 3 a 24 unidades de negocio, y esa expansión solo fue posible porque el proyecto se presupuestó y se planeó como una capacidad continua, no como un gasto que se cierra y se olvida.
Repensar el punto de partida
La pregunta que vale la pena hacerse antes de empezar un proyecto de IA no es cuánto va a costar instalarlo. Es cuánto va a costar mantenerlo entrenado, ajustado y útil seis meses después del go-live. Las empresas que se hacen esa pregunta desde el inicio son las que evitan la decepción de ver un sistema que funcionó bien el primer mes y después se quedó atrás.
En Creai partimos de ahí: ayudamos a las empresas a planear sus proyectos de IA con el presupuesto y el timeline que esa tecnología realmente necesita, no con el que heredaron de su último ERP.
Historias similares
.png)
