Escenario ilustrativo. Un equipo de administración automatiza la entrada de facturas: el agente lee, clasifica y concilia. El piloto arranca, el panel dice que funciona. Marta, que llevaba esa tarea ocho años, no se ha quejado de nada. Y, sin embargo, las excepciones llegan tarde, mal explicadas o directamente no llegan. Nadie ha saboteado el proyecto con mala intención. Simplemente nadie le ha dicho a Marta qué va a hacer el lunes siguiente.
La tesis en una línea: decidir qué hace mañana la persona cuyas tareas absorbe el agente es parte del alcance del proyecto, no un anexo de RRHH. Sin esa decisión, el piloto no falla por la tecnología: falla porque la persona que mejor conoce el proceso tiene motivos racionales para no ayudar.
Reubicar empleados al automatizar con IA: por qué es parte del alcance
Un proyecto de IA se define con un proceso, unos sistemas, unos datos y una métrica. La persona que hoy hace el trabajo aparece como «usuaria» o como «stakeholder», y su futuro, si aparece, se despacha con una diapositiva de gestión del cambio al final del documento.
Es un error de diseño, no de sensibilidad. Esa persona es quien conoce las excepciones que no están escritas en ningún sitio, quien valida lo que produce el agente y quien decide cada día, con sus actos, si el sistema vive o no. Es un componente del sistema. Si lo tratas como un efecto secundario, el sistema se comporta como un componente al que nadie ha especificado.
¿Qué es el sabotaje pasivo y por qué aparece?
El sabotaje pasivo es dejar de ayudar sin llegar a oponerse: no hay conflicto, no hay queja, hay fricción. Y aparece por pura racionalidad. Si tu trabajo es lo que va a desaparecer y nadie te cuenta qué viene después, lo prudente es no hacerte tú mismo prescindible. No es maldad; es lo que haría cualquiera.
Se reconoce por síntomas concretos:
- Las excepciones no se documentan. «Eso ya se sabe», dice quien lo sabe, y el agente tropieza con ello una y otra vez.
- El agente se revisa con una lupa que nunca se usó con el trabajo humano. Cada fallo se enseña en la reunión; cada acierto pasa sin comentario.
- El trabajo se sigue haciendo a mano «por si acaso». El agente corre y la persona repite lo mismo en paralelo, así que el ahorro nunca llega a existir.
- Nadie corrige al agente. Si corregirlo es entrenar a quien te sustituye, lo sensato es dejarlo equivocarse.
Es una de las causas más repetidas de que un piloto funcione en la demo y no llegue a producción; el patrón completo está en la guía sobre por qué fracasan los proyectos de automatización con IA. Aquí nos quedamos con el mecanismo: la resistencia no es un problema de actitud, es la respuesta lógica a una pregunta sin contestar.
¿Qué hay que decidir antes de empezar?
Cuatro decisiones, por escrito, antes de aprobar el piloto:
- Qué tareas desaparecen y cuáles se quedan. Hay que mirar tareas, no puestos: un puesto rara vez es una sola tarea. Hacer ese inventario es la mitad del trabajo de elegir qué procesos automatizar con IA, y suele revelar que lo que se absorbe es una parte del puesto, no el puesto entero.
- A dónde va cada persona. Con nombre y con fecha. Los destinos reales son pocos: supervisar al agente (excepciones, calidad, casos dudosos), pasar a trabajo que antes no se hacía porque no había tiempo, o moverse a otro rol de la empresa. «Ya veremos» no es un destino.
- Qué tiene que aprender y quién lo paga. En horario de trabajo, sobre el trabajo real y con alguien que responda dudas. No es un curso genérico: de eso va la partida de formación que nadie presupuesta.
- Qué pasa con el ahorro. Si lo que se libera son horas, ¿se convierten en capacidad, en menos contratación o en menos plantilla? Decirlo con claridad evita que el equipo lo deduzca por su cuenta, y casi siempre deduce lo peor. La diferencia entre horas liberadas y ahorro real está en las horas liberadas no son ahorro.
Lo de supervisar al agente no es un consuelo. Un agente en producción necesita a alguien que decida en las excepciones, y esa es una función real, descrita en la guía sobre el humano en el bucle de una automatización con IA. Quien más sabe del proceso suele ser quien mejor la ocupa, siempre que el rol exista de verdad y no sea una etiqueta.
¿Y si no hay sitio para esa persona?
A veces no lo hay, y prometer lo contrario es peor que no decir nada. Reubicar no significa garantizar que nadie pierda el puesto; significa que la decisión se toma de forma explícita, antes del piloto y no después, y que la persona la conoce por ti y no por el pasillo.
En España, además, no es solo una cuestión de buenas formas. El Estatuto de los Trabajadores regula la modificación sustancial de condiciones (art. 41) y, para el despido por falta de adaptación a cambios técnicos razonables en el puesto, obliga a ofrecer antes un curso de adaptación (art. 52 b). No es asesoramiento legal y cada caso es distinto: antes de hablar con el equipo, habla con quien lleve vuestra parte laboral. Otros países tienen otras reglas; este párrafo vale solo para España.
¿Cuándo no hace falta tanto?
Si lo que el agente absorbe es una fracción pequeña del trabajo de muchas personas —un rato de copiar y pegar a la semana—, no hay nadie «cuyo trabajo desaparezca» y basta con contarlo con claridad. Y si el objetivo declarado del proyecto es reducir plantilla, dilo así: presentarlo como «reubicación» y no cumplirlo es peor que la conversación difícil. La reubicación es un compromiso, no un eufemismo.
La línea para llevarte: antes de aprobar el piloto, escribe una frase por cada persona afectada. «El lunes después de salir a producción, X hará Y». Si no puedes escribirla, el alcance no está cerrado, y el piloto tiene fecha de caducidad aunque la tecnología funcione.
Fuente consultada el 19 de octubre de 2026: Estatuto de los Trabajadores, texto refundido (BOE-A-2015-11430). Para la adopción como palanca del ROI, ver la adopción, no el modelo, decide el ROI de tu IA.