Durante veinte años, la transformación digital tuvo un aliado discreto: el tiempo. Un ERP tardaba dieciocho meses en implantarse, un CRM seis, un portal de clientes un año. Mientras la tecnología avanzaba despacio, las personas se acostumbraban. Había reuniones, formaciones, pilotos, versiones beta. La adopción ocurría por el camino, casi sin que nadie la gestionara.
La IA acabó con ese aliado. Un equipo puede tener un asistente resumiendo correos, un agente clasificando solicitudes de soporte o un modelo extrayendo datos de facturas en una semana — a veces en una tarde. Lo que antes era el cuello de botella (construir) pasó a ser rápido. Lo que antes era invisible (que las personas cambien su forma de trabajar) pasó a ser el cuello de botella.
Por eso la gestión del cambio, esa disciplina que durante décadas fue un capítulo al final del plan de proyecto, se ha convertido en el propio proyecto. Este artículo explica qué ha cambiado, cuáles son las resistencias específicas de la IA, dónde suelen morir los proyectos y qué funciona cuando se quiere que el cambio arraigue.
Qué ha cambiado: la tecnología dejó de ser el camino crítico
En un proyecto tecnológico clásico, el cronograma lo dominaba la construcción. La gestión del cambio tenía meses para ocurrir en paralelo y, cuando el sistema entraba en producción, la gente ya había oído hablar de él veinte veces.
Con la IA, el orden se ha invertido. El modelo ya existe, la integración se hace en días, y la organización recibe una capacidad nueva antes de haber tenido tiempo de discutir qué significa. El resultado es una herramienta lista para usar en una empresa que aún no ha decidido quién la usa, para qué, con qué límites y con qué responsabilidad.
BCG lo resume en una regla que merece estar en la pared: solo alrededor del 10% del valor de una transformación con IA proviene del algoritmo en sí, otro 20% de los datos y la tecnología, y el 70% restante del rediseño del trabajo, la cultura, la gobernanza y la colaboración entre personas e IA. Si el 70% del valor está en las personas y los procesos, el 70% del esfuerzo tiene que estar ahí también — y rara vez lo está.
Las tres resistencias específicas de la IA
La resistencia al cambio no es nueva. Pero la IA trae tres formas que no existían con la tecnología anterior, y que los métodos clásicos no contaban con encontrar.
Miedo a la sustitución. Cuando una empresa implantaba un CRM, nadie pensaba que el CRM se quedaría con su puesto. Con la IA, es la primera pregunta que todo el mundo se hace, aunque no la diga. Y es legítima: la herramienta hace parte del trabajo que hacía la persona. Un plan de cambio que no responde a esto con honestidad — qué cambia en el papel de cada uno, qué deja de hacerse, qué empieza a hacerse — está pidiendo sabotaje silencioso.
Desconfianza del resultado. Los sistemas anteriores eran deterministas: si el número estaba mal, era un bug. La IA generativa se equivoca de forma plausible, con seguridad, y a veces no se nota. Quien ha visto a un modelo inventar una referencia o cambiar un valor tiene razón en desconfiar. La resistencia aquí no es emocional, es epistémica: "¿cómo sé cuándo esto está bien?" Sin una respuesta práctica — dónde está la verificación, quién la hace, qué pasa cuando falla — la gente hace el trabajo dos veces o deja de usarla.
Pérdida de estatus. En muchos equipos, el valor de una persona está en conocer el proceso antiguo: los atajos del sistema, dónde están las excepciones, ser la única que entiende aquel Excel. Cuando la IA absorbe parte de ese conocimiento, esa persona pierde influencia. Y suele ser la misma persona de la que más depende el proyecto para funcionar.
Ninguna de estas resistencias se resuelve con una sesión de formación sobre prompts.
El error clásico: el piloto que funcionó y nadie usa
El patrón se repite en empresas de todos los tamaños. Un equipo pequeño construye un piloto — un asistente, una automatización, un agente. Técnicamente funciona: la demo va bien, la dirección se entusiasma, se aprueba la extensión al resto de la organización.
Seis meses después, el uso es residual. No porque la herramienta sea mala, sino porque:
- la diseñó quien sabe de tecnología, no quien hace el trabajo cada día;
- resuelve el caso medio y falla en las excepciones, que son precisamente lo que ocupa a la gente;
- no tiene dueño después del piloto: nadie responde por ella, nadie la afina;
- se midió el despliegue (está instalada) y no la adopción (se usa, y el resultado cambió).
El informe DORA de 2024, sobre equipos de ingeniería, da un aviso que se aplica mucho más allá del software: la adopción de IA aumentó la productividad individual, el flow y la satisfacción, pero empeoró la estabilidad y el rendimiento de las entregas. Es decir, cada persona se sintió más rápida y el sistema en conjunto empeoró. Es el retrato de un cambio hecho a nivel individual sin rediseñar el proceso a su alrededor.
Qué funciona: empezar por el proceso, no por la herramienta
Los métodos clásicos siguen siendo válidos. El modelo ADKAR de Prosci — conciencia, deseo, conocimiento, capacidad, refuerzo — describe bien las etapas por las que pasa cada persona. Los ocho pasos de Kotter — crear urgencia, formar una coalición, definir la visión, comunicar, eliminar barreras, generar victorias rápidas, consolidar, institucionalizar — siguen siendo un buen mapa para la organización. Lo que cambia con la IA es el ritmo al que tienen que ocurrir y dónde se pone el peso. En la práctica, lo que hemos visto funcionar:
Empezar por el proceso. Antes de elegir la herramienta, mapear el proceso real — no el del manual, el que ocurre. Por dónde entra la solicitud, quién decide, dónde quedan las excepciones, cuánto tarda cada paso, dónde se pierde información. La IA entra después, en un punto concreto, con un objetivo medible. Un asistente "para ayudar al equipo" no tiene criterio de éxito; un asistente que reduce el tiempo de respuesta al cliente de 48 a 4 horas sí lo tiene.
Diseñar con quien hace el trabajo. Las personas que ejecutan el proceso conocen las excepciones que harán fracasar el piloto. Involucrarlas en el diseño no es una cortesía, es la única forma de que la herramienta funcione en la segunda semana. Y resuelve parte de la resistencia de estatus: quien ayuda a diseñar el proceso nuevo no pierde influencia, la gana.
Entregas pequeñas y visibles, cada semana. Un proyecto de IA de seis meses con una gran entrega al final es una apuesta contra las personas. Entregas semanales — una etapa automatizada, un informe que ahora sale solo, una cola que dejó de existir — dan a las personas pruebas de que el cambio les sirve, y a la dirección pruebas de que la inversión produce. Las "victorias rápidas" de Kotter, en ciclos de días en vez de trimestres.
Medir adopción, no instalación. Cuántas personas la usaron esta semana. Cuántas solicitudes pasaron por el proceso nuevo en vez del antiguo. Cuánto cambió el tiempo. Cuántas excepciones tuvieron que salir al camino manual. Si estas métricas no existen, el proyecto se gestiona por la sensación de quien lo patrocina.
Reglas claras sobre quién decide. En cada punto donde entra la IA, escribir negro sobre blanco: qué hace la herramienta sola, qué propone y una persona aprueba, qué no hace nunca. Esto responde a la desconfianza del resultado (hay verificación, y se sabe dónde) y al miedo a la sustitución (el papel de la persona está definido, no es lo que sobra).
El papel de la dirección: usar antes de mandar usar
Hay una prueba sencilla para saber si una transformación con IA va a arraigar: ¿la dirección usa la herramienta? No para una demo — en su trabajo, cada día.
Una dirección que pide a la organización adoptar IA mientras sigue trabajando como antes está comunicando, sin querer, que eso es para los demás. Lo contrario — un director que resume las reuniones con un asistente, que pide a la herramienta la primera versión de un documento y lo dice — legitima el cambio más que cualquier plan de comunicación.
El Work Trend Index de Microsoft de 2026 plantea la cuestión de forma directa: a medida que la IA y los agentes asumen la ejecución, lo que queda y crece es la capacidad de decidir, y la pregunta es si las organizaciones están construidas para aprovecharla. Es una pregunta para la dirección, no para el departamento de TI.
Tres cosas concretas que corresponden a la dirección y a nadie más:
- Decir qué pasa con los puestos de trabajo. Si la respuesta es "nadie sale, el trabajo cambia", decirlo, por escrito, pronto. Si la respuesta es otra, también — la incertidumbre es peor que cualquiera de las dos.
- Decidir qué puede y qué no puede hacer la IA con datos de clientes, con decisiones que afectan a personas, con dinero. Estas reglas no se delegan.
- Aceptar que la primera versión habrá que afinarla y dar tiempo y presupuesto para ello, en vez de tratar el primer error como prueba de que "la IA no funciona".
Formación que no es formación
La mayor parte de la formación en IA en las empresas es un curso genérico de dos horas sobre cómo escribir prompts. Sirve de poco: la gente sale sabiendo pedir una receta a ChatGPT y sigue sin saber cómo se aplica eso a la factura que tiene delante.
Lo que funciona se parece más al aprendizaje en el puesto de trabajo:
- Casos de la propia empresa. Sesiones cortas con los documentos, los correos y los procesos reales del equipo. "Esta es la solicitud que llegó ayer; vamos a hacerla con la herramienta."
- Pares, no instructores. La persona del equipo que ya usa bien la herramienta enseña a la de al lado. Es más creíble y resuelve las dudas que un instructor externo ni sabe que existen.
- Un lugar para preguntar. Un canal donde se pregunta "¿esto se puede hacer con IA?" y alguien responde en horas. La mayoría de las oportunidades de adopción mueren porque la persona no sabía que era posible.
- Tiempo protegido. Media hora a la semana para experimentar, sin robársela al trabajo. Sin esto, la adopción queda reservada a quien ya tenía margen.
Una formación así es el "conocimiento" y la "capacidad" de ADKAR hechos en serio, y es lo que convierte una herramienta instalada en una herramienta usada.
Señales de alarma
Una lista corta para revisar en un proyecto en curso. Dos o más señales son motivo para parar y corregir antes de continuar.
- La herramienta se eligió antes de mapear el proceso.
- Quien hace el trabajo no participó en el diseño.
- La métrica de éxito es "estar en producción" o "número de licencias".
- Nadie sabe decir qué decide la IA sola y qué pasa por una persona.
- La dirección no usa la herramienta.
- La formación fue un curso genérico, una vez.
- El piloto no tiene dueño después del arranque.
- No hay fecha fijada para revisar qué funciona y qué no.
- La gente hace el trabajo "a la antigua" en paralelo, por si acaso.
Cómo lo abordamos en Scalor
Nuestro trabajo es decidir qué necesita cambiar la operación y quedarnos hasta que funcione, con entregas cada semana. En una transformación con IA, eso significa que empezamos por el mapa del proceso y por las personas que lo ejecutan, no por la herramienta; que cada semana hay algo nuevo en producción que el equipo puede ver; y que medimos adopción y resultado, no instalación. Cuando la tecnología es la parte fácil, el valor está en hacer la parte difícil con método. Así trabajamos en la optimización de procesos y en la formación en IA; para empezar por tu cuenta, la guía de adopción de IA resume los pasos.
Preguntas frecuentes
¿La gestión del cambio es diferente con la IA o es la de siempre? Los principios son los mismos — conciencia, implicación, capacidad, refuerzo. Lo que cambia es el ritmo (la tecnología ya no da tiempo) y tres resistencias nuevas: miedo a la sustitución, desconfianza de resultados no deterministas y pérdida de estatus de quien dominaba el proceso antiguo.
¿Por dónde empezar en una pyme sin departamento de gestión del cambio? Por un solo proceso, mapeado con quien lo ejecuta, con una métrica de resultado definida antes de elegir la herramienta. Una persona responsable, entregas semanales y una revisión fijada al cabo de un mes.
¿Cómo responder al miedo a perder el empleo? Con una respuesta escrita y temprana, de la dirección, sobre qué cambia en el papel de cada persona. La incertidumbre es peor que cualquier respuesta concreta y alimenta la resistencia silenciosa.
¿Cuánto tarda en arraigar la adopción? En un equipo pequeño, con el proceso bien elegido y entregas semanales, las primeras señales de adopción real aparecen en dos a cuatro semanas. Lo que lleva meses es recuperar un piloto que arrancó sin involucrar a las personas.
¿Qué métricas usar? Uso semanal (quién la usó, cuántas veces), porcentaje de solicitudes que pasan por el proceso nuevo, tiempo de ciclo antes y después, número de excepciones que salen al camino manual, y el resultado de negocio que justificó el proyecto.
Fuentes
Escribe sobre IA aplicada, operación, GEO/SEO y cómo transformar empresas en máquinas que siguen funcionando incluso cuando nadie mira.