Gestión del cambio en un proyecto de IA: la parte que decide si sirve

El proyecto de IA que se hunde sin que nadie diga que se hundió

En la reunión de arranque el gerente general prometió que la nueva herramienta de IA iba a “liberarle tiempo al equipo para lo importante”. Hubo aplausos tibios, una capacitación de dos horas y una fecha de lanzamiento marcada en el calendario. Seis semanas después el dashboard de uso seguía en verde: la licencia activa, los accesos creados, el proveedor mandando su reporte mensual de “adopción exitosa”. Pero si uno se sentaba al lado de cualquier analista, la pantalla mostraba otra cosa: la hoja de cálculo de siempre, abierta al costado del sistema nuevo, que solo se tocaba cuando el jefe pasaba cerca.

Nadie anunció que el proyecto había fracasado. No hubo una junta para decirlo. El uso real simplemente se apagó, en silencio, mientras el discurso oficial seguía repitiendo que “la adopción iba bien”. Cuando pregunté por qué el equipo no usaba el sistema para lo que se había comprado, la respuesta fue casi siempre la misma: “no tengo tiempo para aprender algo nuevo”. Es la excusa más usada y la menos honesta, porque el tiempo nunca fue el problema real. El problema real es una pregunta que nadie contestó en esa reunión de arranque, y que cada persona del equipo se hizo en silencio la primera semana: “si esto funciona como dicen, ¿yo para qué sirvo aquí?”. Ninguna capacitación resuelve esa pregunta. Y mientras siga sin respuesta, el sistema puede estar prendido y el trabajo real va a seguir pasando por la hoja de cálculo de siempre.

Por qué se resiste, y qué parte de esa resistencia tiene razón

Cuando un equipo se resiste a un sistema de IA, la explicación más cómoda para la gerencia es que “les da miedo la tecnología” o que “son de la vieja escuela”. Esa lectura es casi siempre falsa y además conveniente, porque exime a quien lideró el proyecto de hacerse la pregunta incómoda. La resistencia casi nunca nace del aparato: nace de un cálculo silencioso y razonable que cualquier persona haría en su lugar. Si el sistema hace en minutos lo que a mí me toma un día entero, y nadie me explicó qué hago yo el día que eso pase, lo más racional es frenar la adopción, no acelerarla.

Por eso conviene nombrar esto con precisión, sin el eufemismo genérico de manual que suele usarse:

Dicho así suena simple, y lo es en el diagnóstico, aunque no en la ejecución. Lo legítimo de la resistencia cambia según de dónde venga, y tratarla toda por igual es el primer error de cualquier plan de adopción:

• El que teme perder el puesto: su resistencia es la más racional de todas si nadie le mostró qué tarea nueva ocuparía su tiempo. No se resuelve con un discurso, se resuelve con un rol concreto y nombrado.
• El que teme perder autoridad sobre su área: suele ser un jefe intermedio cuyo valor hoy es ser el único que sabe lo que nadie más sabe. El sistema vuelve pública esa información, y eso también es una pérdida real, no imaginaria.
• El que ya vio fracasar el proyecto anterior: si la última “transformación” fue un sistema que se abandonó a los cuatro meses, la desconfianza no es terquedad, es memoria bien fundada.
• El que no confía en el criterio del sistema para su tipo de decisión: a veces tiene razón, sobre todo cuando la decisión involucra una excepción que el histórico nunca registró.

La conversación que hay que tener antes de instalar nada, y quién tiene que darla

Casi todos los proyectos de IA arrancan por el lado equivocado: se firma la licencia, se agenda la capacitación, se manda el correo anunciando el cambio. La conversación real, la que decide si el proyecto sobrevive al tercer mes, no aparece en ningún cronograma porque no es una tarea de implementación: es una conversación honesta sobre el trabajo de cada persona, y tiene que pasar antes de que el sistema toque un solo dato de producción.

• Qué tarea puntual va a hacer el sistema en lugar de la persona, nombrada con precisión, no en abstracto (“la IA les va a ayudar”).
• Qué pasa con el tiempo que esa tarea liberaba: a qué se dedica ahora esa persona, con el nombre de la tarea nueva, no una promesa vaga de “trabajo de mayor valor”.
• Qué pasa si la persona no logra hacer esa transición: la empresa tiene que decir esto en voz alta, por incómodo que sea, porque el silencio se interpreta siempre como la peor respuesta posible.
• Qué no va a cambiar, porque nombrar solo lo nuevo sin nombrar lo que se mantiene intacto alimenta la sensación de que todo el puesto está en juego.

Esta conversación no la puede dar un consultor externo ni un correo de Recursos Humanos, por más bien escrito que esté. Tiene que darla la persona con autoridad real sobre el puesto de quien escucha: el jefe directo, respaldado por quien lidera el proyecto de IA dentro de la empresa. Un consultor puede diseñar el proceso y hasta sugerir el guion, pero si la voz que promete algo sobre el puesto de alguien no tiene poder real para sostener esa promesa, el equipo lo nota en la primera semana y deja de creer en cualquier otra cosa que se le diga después.

Postergar esta conversación hasta que el sistema ya esté funcionando es uno de los errores más caros al implementar IA en una empresa: para cuando alguien decide hablar de puestos, el rumor ya construyó su propia versión de la historia, y casi siempre es peor que la realidad que se quería explicar.

Cómo se ve la adopción real, y en qué se diferencia de la que sale en el reporte

El reporte que un proveedor manda cada mes mide lo que le conviene medir: licencias activas, sesiones iniciadas, usuarios que entraron alguna vez durante el periodo. Ese número siempre sale bien, porque basta con que alguien abra la pestaña una vez para contar como “usuario activo”. La adopción real es otra cosa: es que la decisión que antes se tomaba con la hoja de cálculo ahora se toma con el sistema, todos los días, sin que nadie tenga que recordárselo a nadie.

• Login contra decisión: que alguien entre al sistema no dice nada; que la decisión final (aprobar el crédito, priorizar el lead, cerrar el ticket) salga del sistema y no de la planilla paralela, lo dice todo.
• Frecuencia sin recordatorio: usar el sistema porque el jefe lo pidió esa semana es reporte; usarlo la semana en que nadie preguntó nada es adopción.
• El dato que ya no se pide dos veces: cuando el equipo deja de pedirte el mismo número por correo porque ya confía en lo que muestra el sistema, ahí hay adopción real.

Medir esto en serio exige mirar más allá del dashboard del proveedor, algo que desarrollo con más detalle en cómo medir la adopción real de un sistema de IA: la métrica que importa nunca es cuántos entraron, es cuántas decisiones del negocio dependen hoy del sistema y ya no de la planilla de respaldo que todos guardan por si acaso.

Qué hacer con la persona que sabotea el sistema en silencio

Sabotear no es lo mismo que resistirse. La persona que se resiste dice, con más o menos incomodidad, que no confía o que no entiende para qué sirve el cambio. La que sabotea dice que sí en la reunión y en privado hace todo lo posible para que el sistema falle: carga datos a propósito mal, encuentra una excusa nueva cada semana para “no haber tenido tiempo”, o le cuenta al resto del equipo una versión del proyecto distinta a la que se acordó en la reunión de arranque.

El primer error es tratar el sabotaje como un problema de actitud que se arregla con un correo más firme. Casi siempre es la versión silenciosa de una resistencia legítima que nadie escuchó a tiempo: la persona intentó decir que temía por su puesto, nadie le dio una respuesta concreta, y dejó de intentarlo por las buenas. Por eso, antes de sancionar nada, corresponde repetir la conversación honesta del punto anterior, esta vez uno a uno, y preguntar sin rodeos qué le preocupa realmente del sistema.

Distinto es el caso, más raro de lo que se cree, de alguien que ya tuvo esa conversación, ya recibió una respuesta concreta sobre su rol y sigue boicoteando de forma deliberada. Ahí ya no es un problema de gestión del cambio, es un problema de desempeño, y tratarlo como si fuera lo primero solo alarga la agonía del proyecto y le enseña al resto del equipo que sabotear en silencio no tiene costo. La empresa le debe a esa persona una conversación honesta primero. No le debe una segunda oportunidad indefinida después de dársela.

El rol del referente interno, y por qué no puede ser quien lo compró

Todo proyecto de IA que sobrevive el primer semestre tiene, en algún punto del organigrama, a una persona que el resto del equipo consulta antes de rendirse con el sistema. No es el gerente que aprobó el presupuesto ni el consultor que lo implementó: es alguien del mismo nivel que sus colegas, que usa el sistema todos los días, que sabe dónde falla de verdad y que tiene autoridad informal, no jerárquica, para decir “así sí funciona” sin que suene a discurso de la gerencia.

A esa figura la desarrollo con más detalle en qué es un Champion de IA y por qué la empresa necesita uno, pero el punto que importa aquí es más simple: ese rol no puede recaer en quien firmó la compra. El comprador tiene un incentivo evidente para decir que el proyecto va bien, y el equipo lo sabe. El referente interno solo tiene credibilidad si su opinión es independiente del presupuesto, y eso significa que a veces va a decir, en voz alta, que una parte del sistema todavía no sirve. Ese momento de honestidad pública es justamente lo que le da autoridad para el resto.

Elegir mal a esa persona (por antigüedad, por simpatía con la gerencia, o porque “tiene tiempo”) es una forma silenciosa de matar el proyecto, porque el equipo detecta al instante si el referente repite el guion oficial o si de verdad usa el sistema en su trabajo del día a día.

Las tres señales de que el equipo ya volvió a su hoja de cálculo

El regreso a la hoja de cálculo casi nunca se anuncia. Pasa despacio, y para cuando alguien lo nota en una reunión de resultados ya lleva semanas instalado. Estas son las tres señales que reviso primero, porque aparecen antes que cualquier caída visible en el dashboard del proveedor:

• El archivo paralelo reaparece “por si acaso”: alguien sigue llevando la planilla de siempre “de respaldo”, y ese respaldo termina siendo la fuente real de la decisión mientras el sistema queda de adorno.
• Las preguntas de duda dejan de hacerse: al principio el equipo preguntaba cómo usar el sistema; cuando esas preguntas desaparecen no es porque ya lo dominan, es porque dejaron de intentarlo y ya no vale la pena preguntar por algo que no van a usar.
• El referente interno empieza a hablar en pasado: cuando la persona que antes defendía el sistema frente al resto empieza a decir frases como “cuando lo usábamos” o “se suponía que con esto”, el proyecto ya perdió a su único defensor creíble y el conteo regresivo se acelera.

Ninguna de las tres se arregla con una nueva capacitación. Se arreglan retomando la conversación sobre el trabajo de cada quien, la misma que debió darse antes de instalar nada, y revisando si lo prometido sobre los roles se cumplió de verdad, algo que desarrollo en cómo capacitar a tu equipo para adoptar IA sin que el uso se apague en un mes.

Mi criterio sobre dónde falla esto de verdad

La gestión del cambio no es un capítulo del proyecto, es la condición para que exista

La gestión del cambio no es la fase blanda que se agrega al final del proyecto de IA para que Recursos Humanos tenga algo que hacer. Es la condición sin la cual el resto del proyecto (el dato limpio, el modelo bien entrenado, la integración técnica) no llega a producción de verdad, porque nadie lo usa. Una empresa puede tener el mejor sistema del mercado y perderlo por completo si nunca se sentó a decir, persona por persona, qué cambia en su trabajo.

Lo que distingue a una empresa AI Native de una que solo compró licencias no es la tecnología que instaló: es que tuvo esa conversación antes de instalar nada y la sostuvo cuando se puso incómoda. La resistencia que apareció en el camino no se “gestionó” con una técnica de comunicación: se escuchó, se respondió con hechos concretos sobre el trabajo de cada persona, y solo entonces se pidió adopción. Ese orden no es opcional, y cualquier atajo que lo salte se paga después, en la hoja de cálculo que vuelve a aparecer sin que nadie la haya invitado.