TL;DR (3 líneas): IBM reemplazó a cientos de personas de RRHH con IA y reinvirtió lo liberado en programadores y vendedores; Cloudflare radicalizó el patrón despidiendo al 20 % mientras crecía un 34 %. Financieramente funciona, pero comunica sustitución — e importa miedo, que es el enemigo de la adopción. A escala mediana el playbook ni siquiera es ejecutable: la unidad de automatización es la tarea, no la persona, y la pregunta correcta es qué hace cada uno con el tiempo que la IA le devuelve.
IBM hizo algo que pocas empresas comunican tan directamente: usaron IA para reemplazar a «varios cientos» de empleados de recursos humanos. El CEO lo confirmó públicamente, sin ambigüedad.
Y luego hicieron algo igualmente revelador: reinvirtieron los recursos liberados en contratar más programadores y vendedores.
Este es un caso sobre qué se reemplaza, qué no, y cómo se comunica la diferencia. Y sobre por qué, si diriges una empresa
mediana, este playbook no te lo puedes copiar — aunque sí puedes aprender de él.
IBM construyó dos agentes principales. AskHR automatiza el 94 % de las tareas rutinarias de RRHH (vacaciones, comprobantes de pago, beneficios, políticas internas), y AskIT redujo llamadas y chats al equipo de IT en un 70 %.
El resultado fueron «varios cientos» de empleados de RRHH reemplazados. Y una mejora de productividad reportada de 3.500 millones de dólares en 2 años usando IA en más de 70 áreas de negocio.
A pesar de los despidos en RRHH, la plantilla total de IBM aumentó.
Los recursos liberados se reinvirtieron en «roles de pensamiento crítico» (programadores, vendedores) en lugar de bajar a la cuenta de resultados como ahorro neto. Son roles que «enfrentan a otros humanos, en vez de solo hacer trabajo de proceso repetitivo».
No es «IA para reducir costes totales». Es «IA para reasignar recursos de bajo valor a alto valor».
Los agentes de IBM se enfocan en un perfil específico de trabajo: alto volumen, bajo juicio humano requerido, lógica determinística. «¿Cuántos días de vacaciones me quedan?» no requiere empatía ni juicio complejo: es transaccional, perfecto para automatización.
El 94 % de automatización en RRHH se refiere a las tareas rutinarias, no a la proporción de trabajadores reemplazables. La diferencia es crítica.
Los roles reforzados comparten dos características:
El primero es el pensamiento crítico: programadores resolviendo problemas complejos, diseñando arquitecturas, tomando decisiones con información incompleta.
El segundo es el contacto humano: vendedores construyendo relaciones, negociando contratos, entendiendo necesidades no articuladas de clientes.
Estas son las áreas donde IBM decidió doblar la apuesta. El flujo es claro: automatizar tareas de bajo valor → liberar recursos → reasignar a roles de alto valor → mantener o aumentar plantilla total.
El modelo suena bien en papel. Pero ¿qué pasa con los cientos de empleados de RRHH reemplazados? ¿Se les ofreció recualificación para convertirse en programadores o vendedores?
IBM no ha compartido detalles públicos. Y esa omisión es reveladora. Es estadísticamente improbable que cientos de roles administrativos de RRHH se convirtieran fluidamente en programadores de IA.
La narrativa de «el empleo total aumentó» es verdadera a nivel agregado. Puede no reflejar la experiencia de las personas directamente afectadas.
El whitepaper de adopción que defendemos en entaina parte de una premisa distinta a la de IBM: la narrativa que sostiene adopción real es de amplificación, no de reducción. Moderna lo formuló como «6.000 empleados con el impacto de 100.000». IBM lo formuló como «varios cientos sustituidos». Ambos encuadres son operacionalmente coherentes, pero generan culturas internas opuestas. En la primera, la IA es palanca; en la segunda, es amenaza.
Y hay una segunda ironía que conviene nombrar: IBM automatizó precisamente el área (Recursos Humanos) que en la mayoría de organizaciones debería ser dueña operativa de la adopción de IA. Cuando RRHH deja de ser actor y pasa a ser objeto de la automatización, alguien tiene que asumir su rol de acompañamiento. IBM no ha contado quién.
Si automatizas todos los roles iniciales en RRHH e IT, ¿dónde aprenden los nuevos? Tradicionalmente, los analistas junior de RRHH hacen trabajo repetitivo mientras aprenden el dominio. Con el tiempo, progresan a roles de mayor juicio.
Si AskHR absorbe todo el trabajo junior, el desarrollo de talento senior se complica. Este es un problema de medio plazo que aún no ha explotado. Pero las organizaciones que automatizan agresivamente roles iniciales podrían descubrir en 3-5 años que tienen brecha de talento.
El dato lo confirma: los CEOs estiman que el 31 % de su plantilla necesitará recualificación en los próximos 3 años. La diferencia entre las que navegan la transición y las que sufren: tratar la recualificación como línea presupuestaria recurrente, no como gasto puntual. En entaina lo decimos así: el cambio es un proceso, no un evento — y los procesos se presupuestan, no se improvisan.
IBM tomó una decisión arriesgada: el CEO confirmó públicamente el reemplazo. Muchas empresas harían esto silenciosamente, llamándolo «reestructuración» u «optimización».
La transparencia tiene ventaja: no hay sorpresas, no hay rumores. Pero genera escrutinio público y potencial resistencia interna.
Lo que está claro: si reemplazáis roles con IA, necesitáis una narrativa coherente sobre por qué, qué viene después, y cómo esto beneficia — o al menos no destruye — a los empleados que quedan.
Mayo de 2026. El CEO de Cloudflare, Matthew Prince, publica en The Wall Street Journal un artículo de opinión titulado «Cómo elijo qué empleados de Cloudflare reemplazar con IA». Más que una nota de prensa eufemística, es un manifiesto operativo.
Los datos: el 20 % de la plantilla despedida (unas 1.100 personas) mientras la empresa crece un 34 % en ingresos y factura 640 M$ en el trimestre. No es un caso conocido en la historia reciente de empresas públicas estadounidenses. Prince predice que será la norma en el próximo año.
El criterio que usa para decidir a quién despedir lo toma de Peter Drucker (1954): toda persona en una organización es builder (crea producto), seller (vende) o measurer (todo lo demás: auditoría interna, finanzas, legal, compliance, mandos intermedios, operaciones, marketing). La mayoría de los despedidos en Cloudflare fueron measurers. Los builders siguen contratándose («si un ingeniero es 10x más productivo, contrataré todos los que encuentre»). Los sellers no se tocan.
Y, como en IBM, el total de plantilla esperado no disminuye: Cloudflare reporta número récord de posiciones abiertas tras el ajuste. La diferencia con IBM es de grado, no de naturaleza: la misma lógica de reasignación, llevada más lejos y comunicada con menos diplomacia.
Lo que Cloudflare añade al caso IBM es honestidad sobre el criterio de selección. IBM dijo «automatizamos RRHH y reinvertimos en programadores». Cloudflare dice «los despedidos eran measurers, toda persona cuyo trabajo es medir, auditar, supervisar o coordinar». Es una categoría amplia, y nombrarla cambia el cálculo personal de muchos empleados que se creían estructuralmente seguros por ser mando intermedio.
Hasta aquí, la crónica. Ahora la traducción, porque es probable que tu empresa no se parezca a IBM ni a Cloudflare.
IBM tiene más de 250.000 empleados; Cloudflare despidió a 1.100 personas de golpe. En una empresa de 200 no hay «varios cientos de empleados de RRHH» que reemplazar: hay dos, y una de ellas también lleva la prevención de riesgos y las nóminas. El reemplazo estratégico exige una masa de puestos homogéneos que una mediana empresa sencillamente no tiene.
La consecuencia es la clave de todo el caso: a escala mediana, la unidad de automatización no es la persona — es la tarea. El 94 % de AskHR sigue siendo verdad para ti, pero se traduce en horas liberadas por rol, no en puestos eliminados. Y eso cambia la pregunta. La pregunta correcta no es «¿a quién reemplazo?», sino «¿qué hace cada persona con el tiempo que la IA le devuelve?».
Por eso la amplificación no es, para una mediana empresa, la versión amable del modelo IBM. Es la única versión ejecutable.
Hay otro detalle del criterio de Cloudflare que en una mediana empresa se vuelve peligroso. Los measurers de Drucker (los que coordinan, supervisan, hacen que las cosas cuadren) son, en una organización de tamaño medio, precisamente quienes saben cómo funciona todo de verdad. Su trabajo diario es repetitivo; su cabeza es la memoria de la empresa.
Prescindir del rol sin haber capturado antes lo que sabe no es optimizar: es amputar memoria organizativa. Y la ironía es que el agente que va a absorber sus tareas necesita exactamente ese conocimiento para funcionar.
De ahí nuestro prerrequisito para cualquier automatización seria: el conocimiento de la organización tiene que vivir en un modelo de conocimiento organizativo (un OKM, legible por las personas y por los agentes) antes de que la IA absorba las tareas. Primero se captura, luego se automatiza. En el orden inverso, lo que se automatiza es la ignorancia.
Dos apuntes que el WSJ no necesita hacer y nosotros sí. El manifiesto de Prince es, tal cual, impublicable en España: un despido colectivo con ese criterio confeso difícilmente sobrevive a una impugnación. Y culturalmente, en empresas donde todos se conocen, el miedo no se diluye en el agregado; cada silla vacía tiene nombre.
No es una queja regulatoria. Es una constatación: aquí el camino de la sustitución está más cerrado, y eso refuerza la conclusión anterior. En Europa, y sobre todo en la empresa mediana europea, la amplificación no es solo la apuesta culturalmente sensata: es la que el terreno permite.
Financieramente, la filosofía IBM-Cloudflare funciona: los números lo dicen. Pero la narrativa elegida tiene consecuencias: las organizaciones que comunican adopción como sustitución importan miedo a su propia plantilla, y el miedo es el enemigo natural de la experimentación que la adopción requiere. Que el empleo total no caiga no neutraliza ese efecto; solo lo enmascara en el agregado.
Así que nuestra apuesta por la amplificación no es blandura. Es ingeniería: a tu escala el reemplazo no es ejecutable, en tu marco legal es difícilmente defendible, y en tu cultura sale carísimo. Lo que sí puedes hacer — hoy, sin despedir a nadie — es lo que IBM hizo bien: identificar las tareas de alto volumen y bajo juicio, dárselas a un agente, y decidir deliberadamente qué hace cada persona con el tiempo liberado.
Esa última decisión es la estrategia. Todo lo demás es tecnología.
Referencias:
