En esta nota
En resumen
- Tres causas distinguibles: miedo al puesto, desconfianza por un error visible, y la sospecha de que es más trabajo.
- La tercera suele ser cierta. Medí la tasa de corrección antes de discutir la actitud del equipo.
- Obligar produce uso aparente: el indicador mejora y nada cambia.
- Lo que pase con el tiempo liberado en las primeras semanas es el mensaje que el equipo va a leer.
La resistencia a la inteligencia artificial en una empresa se explica casi siempre con la misma frase: "hay gente que le tiene miedo a la tecnología". Es cómoda porque ubica el problema en la personalidad de otros y no en cómo se implementó.
En la práctica hay tres causas, son bastante distinguibles y cada una se trata de una manera. Ninguna se resuelve insistiendo.
Causa 1: el miedo al puesto
Es la más frecuente y la que menos se dice en voz alta. Nadie va a una reunión a decir que teme quedarse sin trabajo: lo que aparece son objeciones técnicas, hallazgos de errores, comentarios sobre que "así tardamos más".
Cómo se reconoce: la resistencia viene de las personas cuya tarea es justamente la que se está automatizando, y las objeciones cambian cada vez que resolvés una.
Cómo se trata: hablándolo de frente, porque el silencio confirma el miedo. Si la intención no es reducir gente, hay que decirlo explícitamente y sostenerlo con hechos.
Y acá hay una prueba que el equipo mira con atención: qué pasa las primeras semanas con las horas liberadas. Si se convierten en más volumen del mismo trabajo, el mensaje fue que se buscaba exprimir. Si se convierten en cosas que antes no se alcanzaban a hacer, el mensaje fue otro.
Si la intención sí es reducir personal, ninguna estrategia de comunicación lo va a tapar. El equipo lo descubre antes de lo que pensás, y la resistencia que aparece después es racional, no emocional.
Causa 2: la desconfianza después de un error
Alguien vio al sistema inventar un dato con total seguridad, o mandar algo mal escrito, y esa escena se cuenta en el pasillo durante meses. Un error visible pesa mucho más que cincuenta aciertos invisibles.
Cómo se reconoce: hay una anécdota puntual que se repite, y en general es la misma para todos.
Cómo se trata: mostrando el control, no negando el error. Explicar por qué pasó (completa con lo más probable cuando no tiene el dato), en qué tareas eso no ocurre, y qué revisión se agregó para que no vuelva a salir.
Un equipo que entiende dónde está el límite vuelve a usar la herramienta con criterio. Un equipo al que le dicen "ya está arreglado, no va a pasar más" desconfía del que lo dijo la próxima vez que pase.
Causa 3: la sospecha de que es más trabajo
La objeción más honesta de las tres, y muchas veces tienen razón.
Si el sistema produce borradores que hay que corregir siempre, no sacó trabajo: lo cambió por otro, y encima agregó el paso de revisar. El equipo lo nota en la primera semana, mucho antes que cualquier tablero.
Cómo se reconoce: la queja es concreta y con ejemplos. "Tardo más corrigiendo esto que escribiéndolo yo."
Cómo se trata: midiendo la tasa de corrección y tomándola en serio. Si es alta y no baja, la objeción es correcta y el problema es el sistema, no la actitud. Puede ser que el proceso elegido no fuera buen candidato, o que le falte contexto del negocio.
Reconocer eso en voz alta hace mucho por la credibilidad del próximo intento.
Por qué obligar no sirve
La reacción instintiva ante la baja adopción es hacerlo obligatorio. Produce un resultado específico: uso aparente.
La gente abre la herramienta, la usa para lo trivial, deja rastro suficiente para que el indicador dé bien, y sigue haciendo como antes lo que de verdad importa. El tablero mejora y nada cambia.
Lo que sí funciona es elegir una tarea que al equipo le moleste de verdad. No la más estratégica ni la más visible para la dirección: la más odiada. Cargar datos a mano, buscar información en cuatro lugares, responder la misma pregunta por vigésima vez.
Cuando esa tarea desaparece, la adopción no hay que empujarla. Y el equipo empieza a traer ideas de qué más se podría resolver, que es el punto en el que el proyecto se sostiene solo.
La mejor pregunta para arrancar no es dónde podemos aplicar IA. Es: qué parte de tu trabajo te da bronca hacer.
Seba Chuffer · LAB AI
El rol de las primeras personas
En todo equipo hay alguien con curiosidad que ya probó por su cuenta. Esa persona vale más que cualquier capacitación formal, por una razón simple: cuando explica algo, no hay sospecha de que esté vendiendo.
Conviene darle tiempo explícito para ayudar a otros, y reconocerlo. No convertirlo en un cargo nuevo: darle un par de horas por semana y que se sepa que ese es el lugar donde preguntar sin quedar mal.
Las preguntas que la gente no hace en la capacitación formal (porque no quiere parecer que no entiende) se hacen en el escritorio de al lado. En el LAB pasa lo mismo: las preguntas que alguien arranca diciendo "esto va a sonar muy básico" suelen ser las que ordenan la clase entera.
Hacé explícito que preguntar no tiene costo. Si preguntar expone, nadie pregunta, y el desconocimiento se disimula usando la herramienta mal o no usándola.
Una secuencia que funciona
1Preguntá qué les da bronca
Individualmente, no en reunión abierta. En grupo la gente nombra lo que suena estratégico; en privado nombra lo que le arruina los lunes.
2Elegí una de esas tareas
La más frecuente, y resolvela bien. Una sola.
3Que la persona afectada participe
Es la que sabe dónde están los casos raros, y además deja de ser algo que le hacen para ser algo que ayudó a armar.
4Dos semanas con revisión
Antes de soltarlo, para que el equipo vea cómo se comporta y corrija lo que falla.
5Mostrá qué pasó con el tiempo liberado
Es la prueba que todos miran, aunque nadie la mencione.
Es más lento que anunciar una transformación completa, y es la diferencia entre que se use o no.
El resumen
- Casi nunca es miedo a la tecnología. Son tres causas distintas y se distinguen.
- El miedo al puesto se habla de frente; el silencio lo confirma.
- La desconfianza se resuelve mostrando el límite, no negando el error.
- "Es más trabajo" suele ser cierto: medí antes de discutir.
- Obligar produce uso aparente.
- Lo que pase con el tiempo liberado es el mensaje que se lee.
En el LAB trabajás con tu equipo adentro
Doce semanas en vivo sobre los procesos reales de tu negocio, eligiendo los que de verdad molestan y saliendo con tres funcionando. Con mentores que ayudan a ordenar la conversación interna, que suele ser la parte más difícil.
Conocer el LAB AI ›Preguntas frecuentes
¿Por qué mi equipo se resiste a usar IA?
Casi nunca por rechazo a la tecnología. Las tres causas reales son el miedo a que el puesto peligre, la desconfianza tras un error temprano que alguien vio, y la sospecha de que la herramienta suma trabajo en vez de sacarlo. Cada una se trata distinto y ninguna se resuelve insistiendo.
¿Conviene hacerlo obligatorio?
No. La obligación produce uso aparente: la gente abre la herramienta, la usa para lo trivial y sigue trabajando como antes en lo que importa. Funciona mucho mejor elegir una tarea que de verdad moleste al equipo y resolverla bien, porque ahí la adopción no hay que empujarla.
¿Qué hago si alguien teme por su puesto?
Responderlo de frente, porque el silencio confirma el miedo. Si la intención no es reducir gente, hay que decirlo explícitamente y sostenerlo con hechos: qué pasa con el tiempo que se libera. Si la intención sí es esa, no hay estrategia de comunicación que lo tape.
¿Cómo se recupera la confianza después de un error público?
Mostrando el control, no negando el error. Explicar por qué pasó, qué tarea sí es confiable y qué revisión se agregó. Un equipo que entiende dónde está el límite vuelve a usar la herramienta; uno al que le dicen que no va a pasar más, no.
Escrito a partir de lo que vemos en las sesiones del LAB AI, el programa en vivo donde cada participante implementa IA en los procesos reales de su negocio.