La respuesta corta: cuando un equipo no adopta la IA casi nunca es por resistencia al cambio. Es porque se le dio una herramienta en vez de un proceso, porque nadie había escrito cómo se hace el trabajo, o porque la primera vez la IA se inventó algo y ya nadie volvió a fiarse.
Estas son las seis razones que nos encontramos, por orden de frecuencia.
Última revisión: 19 de agosto de 2026.
El panel de licencias
Entras a ver cuánto estás pagando y hay un dato que no esperabas: de las veinte licencias que contrataste en marzo, este mes las han abierto tres personas. Y dos de esas tres son tú y el de sistemas.
Hiciste la formación. Vino alguien, estuvo dos horas, todo el mundo asintió. Hubo hasta entusiasmo el primer par de semanas.
Y sin embargo.
1. Nadie ha escrito cómo se hace el trabajo
Esta es la grande y la que menos se ve.
Le pides a alguien que use la IA para preparar un informe. Esa persona lleva ocho años haciéndolo y lo hace bien, pero nunca ha escrito cómo lo hace. Sabe qué mirar primero, qué ignorar, qué le hace sospechar, a quién preguntar cuando algo no cuadra. Todo eso está en su cabeza.
Cuando le das una herramienta genérica, la herramienta no sabe nada de eso. Devuelve algo plausible y mediocre. La persona lo mira, ve que no es como ella lo haría, y concluye razonablemente que la IA no sirve para esto.
No es que no sirva. Es que no le has dado nada que seguir.
En una agencia de SEO británica de más de veinte personas nos pasó exactamente eso. La solución no fue formación: fue sentarnos con cada uno y escribir cómo trabajaba. Salieron más de ochenta procesos que hasta entonces solo existían en cabezas. A partir de ahí, la misma herramienta que no servía empezó a servir.
2. Le diste una herramienta, no un proceso
Comprar licencias se hace en una tarde. Por eso es lo que se hace.
Pero una licencia no le dice a nadie qué hacer un martes por la mañana. La gente abre la herramienta, se queda mirando la pantalla en blanco, hace una prueba, obtiene algo regular y cierra la pestaña.
La diferencia está entre "tenéis acceso a esto, probadlo" y "esta tarea concreta que odiáis ahora se hace así, mirad". La segunda funciona.
3. La primera vez se inventó algo
Esto hace más daño del que parece, porque la confianza se rompe una vez y se recupera despacio.
Un responsable técnico nos lo contó así: le pidieron explícitamente que no inventara datos, y aun así lo hizo. Cuando le preguntaron cuáles se había inventado, respondió que alrededor de la mitad.
Después de eso, esa persona no va a delegar nada importante. Y tiene razón.
La respuesta no es prometer que no volverá a pasar, porque va a volver a pasar. La respuesta es diseñar el proceso para que dé igual: que la IA prepare pero no envíe, que abra la propuesta pero no la mande. Cuando el error no tiene consecuencias, la gente se atreve.
4. Tienen miedo, y nadie se lo ha desmentido en voz alta
Nadie lo dice en una reunión. Se dice en el pasillo, o no se dice.
Pero está ahí y determina todo lo demás. Si alguien sospecha que el objetivo real es prescindir de gente, no va a enseñarte cómo hace su trabajo. Va a enseñarte una versión simplificada y va a asegurarse de seguir siendo imprescindible.
Y no le culpes: es lo que haría cualquiera.
Esto se arregla diciéndolo al principio y delante de todos. Y sobre todo con hechos: empezando por lo que la gente odia, no por lo que le da orgullo. Cuando un analista ve que su informe pasa de tres horas a una y que ahora dedica ese tiempo a interpretar en vez de recopilar, el miedo se le pasa solo. Uno nos lo dijo así: "y los informes son probablemente mejores, porque ahora me centro en el porqué y en el qué sigue".
5. Empezaste por lo que se ve fuera
Error clásico: el primer proyecto es el chatbot de atención al cliente o el correo automático a clientes.
Es lo peor por donde empezar. Ahí el error es visible, caro y vergonzoso, así que todo el mundo está tenso desde el primer día.
6. No hay nadie a cargo de mantenerlo
Un sistema de IA no se queda quieto. Cambian los procesos, sale un modelo mejor, un proveedor cambia su formato y algo deja de funcionar.
Si nadie tiene el encargo explícito de mantenerlo, se degrada. Y cuando se degrada, la gente vuelve a hacerlo a mano. Nadie avisa: simplemente deja de usarse.
Por eso cada proceso que escribimos tiene un responsable con nombre y apellidos dentro de la empresa. No un comité: una persona.
Qué pasa si lo dejas estar
Lo primero, lo obvio: sigues pagando licencias que no abre nadie. Eso se arregla cancelándolas, y no es el problema.
El problema es el segundo intento. Dentro de un año vas a querer volver a intentarlo, y te vas a encontrar un equipo que ya ha visto esta película. La resistencia de la segunda vez es mucho más dura que la de la primera, porque ya no es miedo a lo desconocido: es memoria.
En una de las agencias con las que trabajamos, automatizar las plantillas de contenido había fracasado tres veces antes de que llegáramos nosotros. Eso no es una anécdota: es una condición del proyecto. Significa que la primera cosa que montes tiene que funcionar sí o sí, porque no hay margen para un cuarto intento.
Y lo tercero, lo que menos se ve: la gente que sí quería, se cansa. En todo equipo hay dos o tres que se han puesto por su cuenta, que han probado cosas, que tienen ideas. Si ven que no pasa nada durante un año, dejan de traerlas. A veces se van a un sitio donde sí pasa.
Cómo lo ajustamos nosotros
La regla de que nada sale al exterior sin aprobación humana no la inventamos: nos la enseñó un cliente que nos dijo que no.
En una agencia alemana, dos personas del equipo se negaron en redondo al agente que iba a ordenar el correo. "¿Y si archiva o manda algo que no toca?" La primera reacción fue explicarles que era seguro. No coló, y hacían bien.
Así que cambiamos el diseño en vez de la explicación. El agente prepara el borrador, lo deja en la bandeja y una persona pulsa enviar. Empezamos solo con procesos internos, solo con quien quería participar, y sin que nada saliera de la empresa. Un mes después eran ellas las que pedían ampliarlo.
Lo que aprendimos ahí lo aplicamos ahora desde el principio, y nos ha cambiado el orden de trabajo: primero preguntamos quién quiere, después montamos para esos, y dejamos que el resto se apunte cuando vea el resultado. Empujar no funciona. Enseñar sí.
No siempre sale bien a la primera. En otro cliente empezamos por un proceso que nos pareció obvio y resultó que era el que una persona concreta consideraba suyo: lo había construido ella, era su valor dentro de la empresa. Tuvimos que parar, hablarlo, y cambiar de proceso. Perdimos dos semanas y aprendimos a preguntar antes de elegir por dónde empezar.
Qué puedes hacer tú, mañana
- Escribe primero. Siéntate con quien hace el trabajo y saca de su cabeza cómo lo hace. Sin esto, lo demás no sirve.
- Empieza por dentro. Procesos internos, donde el error no llega al cliente.
- Empieza por quien quiere. Siempre hay dos o tres. Que lo prueben ellos y que lo enseñen.
- Empieza por lo que odian, no por lo que les da orgullo.
- Que nada salga sin aprobación humana. Esa regla no se negocia.
- Pon un responsable por proceso. Con nombre.
- Mide antes. Si no sabes cuánto costaba, no podrás demostrar que ha mejorado.
Todo esto es lento y no luce. Es sentarse a hablar con doce personas y ponerse de acuerdo en una forma de hacer cada cosa cuando hay ocho. Es la parte que nadie quiere vender porque no se puede enseñar en una demo, y es la que decide si dentro de un año tienes un sistema funcionando o unas licencias que nadie abre.
Si ya te pasó una vez, no fue culpa tuya ni de la herramienta. Faltaba el paso de antes.
Aquí explicamos cómo lo hacemos, y aquí el caso de la agencia con los ochenta procesos.