IBM detecta una brecha entre la adopción de IA y el criterio para supervisarla

La preocupación no es solo perder empleos. IBM publicó el 2 de octubre resultados de un estudio desarrollado con Oxford Economics, basado en 1.500 responsables de recursos humanos y 8.800 empleados de 28 países. En Canadá, 62% de los trabajadores encuestados dijo temer que la IA erosione sus habilidades. El hallazgo desplaza la conversación desde cuántas tareas se automatizan hacia qué capacidad humana se conserva mientras cambia el proceso. Conviene probar la afirmación con una muestra representativa y documentar lo que queda fuera. Los promedios esconden colas y los casos exitosos esconden condiciones de fallo. Una revisión honesta muestra tanto el resultado esperado como el comportamiento ante datos incompletos, permisos revocados y herramientas temporalmente indisponibles.

El criterio aparece como capacidad operativa. Entre los CHRO canadienses, 68% consideró esencial que las personas puedan supervisar, validar y anular resultados de IA, pero solo 29% de empleados ubicó el juicio entre sus prioridades. Al mismo tiempo, 54% de empleados y 55% de CHRO destacaron pensamiento crítico y formulación de problemas. La diferencia muestra que reconocer una habilidad no garantiza practicarla dentro del workflow. La métrica debe conectarse con una consecuencia de negocio: tiempo ahorrado, error evitado, exposición reducida o decisión acelerada. Contar solicitudes, prompts o usuarios no demuestra valor por sí mismo. Medir antes y después permite corregir el sistema y también decidir con serenidad cuándo detener una iniciativa que no funciona.

La verificación crea trabajo invisible. El estudio describe una carga que muchos tableros de productividad no registran. Un 87% de CHRO canadienses cree que la IA genera trabajo invisible: revisar recomendaciones, corregir errores, aportar contexto y gestionar excepciones. Además, 51% de empleados afirma que su carga aumenta o que ese esfuerzo no se reconoce. Automatizar sin medir revisión puede trasladar el costo, no eliminarlo. El paso final siempre es confirmar el estado real. Una respuesta exitosa de una herramienta no prueba que el cambio persistió ni que otro sistema lo respetó. El readback debe consultar el destino, comparar identificadores y registrar diferencias. Esa disciplina separa intención de resultado y evita reportes de éxito prematuros.

La responsabilidad todavía está fragmentada. Cuando algo sale mal, 39% de empleados canadienses reporta que la culpa recae sobre ellos, mientras 32% de CHRO señala que la rendición de cuentas poco clara complica el despliegue. El problema es estructural: una persona puede recibir responsabilidad sin autoridad para cambiar el modelo, bloquear una acción o corregir la fuente de datos que originó el fallo. Conviene probar la afirmación con una muestra representativa y documentar lo que queda fuera. Los promedios esconden colas y los casos exitosos esconden condiciones de fallo. Una revisión honesta muestra tanto el resultado esperado como el comportamiento ante datos incompletos, permisos revocados y herramientas temporalmente indisponibles.

El diseño del trabajo produce resultados. IBM indica que las organizaciones que definen con claridad tareas humanas, asistidas y ejecutadas por IA logran globalmente 18% de reducción de riesgo y 20% de mejora de calidad. Donde Recursos Humanos comparte la responsabilidad sobre qué decisiones permanecen humanas, 76% de empleados se siente seguro cuestionando o anulando recomendaciones, frente a 43% cuando RR. HH. es solo asesor. La métrica debe conectarse con una consecuencia de negocio: tiempo ahorrado, error evitado, exposición reducida o decisión acelerada. Contar solicitudes, prompts o usuarios no demuestra valor por sí mismo. Medir antes y después permite corregir el sistema y también decidir con serenidad cuándo detener una iniciativa que no funciona.

Lectura Goatify. Para Goatify, la oportunidad está en rediseñar trabajo antes de vender automatización. Un taller puede clasificar decisiones, identificar verificaciones ocultas, asignar autoridad de override y establecer métricas de calidad, carga y confianza. El resultado debe ser una matriz operativa: quién decide, quién valida, qué evidencia ve y en qué condiciones el sistema se detiene. El paso final siempre es confirmar el estado real. Una respuesta exitosa de una herramienta no prueba que el cambio persistió ni que otro sistema lo respetó. El readback debe consultar el destino, comparar identificadores y registrar diferencias. Esa disciplina separa intención de resultado y evita reportes de éxito prematuros.