Cuando la IA devuelve el control, ¿puede la persona retomarlo?

Una automatización puede trabajar bien durante horas y devolver una tarea en el peor momento: cuando aparece una excepción que exige entender lo ocurrido, decidir y actuar. Para quien recibe el caso, un botón de «tomar control» no basta. Hace falta saber qué cambió, qué sigue ocurriendo y qué se puede detener sin agravar el problema.

Imaginemos un sistema que gestiona pedidos y deriva una operación a una analista porque detecta una dirección incompatible con la entrega. La pantalla muestra «revisión humana requerida», pero no aclara si ya cobró, si reservó inventario ni si otro proceso continúa enviando mensajes al cliente. La persona puede tener experiencia y aun así comenzar a ciegas. Esta escena es hipotética; permite reconocer una dificultad de diseño sin atribuirla a una empresa concreta.

El problema no consiste únicamente en que el sistema haya encontrado un límite. También importa la calidad del relevo. Una organización puede declarar que mantiene a una persona al mando y, al mismo tiempo, no darle las condiciones necesarias para ejercer ese mando. Revisar el traspaso obliga a mirar tres recursos juntos: información para comprender, tiempo para reconstruir y autoridad para intervenir.

La excepción no es una tarea pequeña

En Ironies of Automation, Lisanne Bainbridge explicó en 1983 una paradoja que sigue siendo útil: automatizar la operación habitual puede dejar a las personas las situaciones anormales, precisamente aquellas que requieren más conocimiento y destreza. Si la práctica cotidiana desaparece, no cabe suponer que la capacidad de recuperación permanezca intacta. Su análisis se refiere especialmente al control de procesos industriales; trasladarlo al trabajo administrativo exige prudencia, no una equivalencia automática entre riesgos.

Bainbridge también distinguió conocer un proceso en general de comprender su estado actual. La segunda comprensión se construye con información sobre lo que viene ocurriendo y sobre las consecuencias de intervenciones anteriores. Por eso, entregar datos aislados no equivale a entregar contexto. Una lista de eventos puede ser correcta y, sin embargo, obligar al receptor a reconstruir por su cuenta la historia que vuelve esos eventos significativos.

La consecuencia organizativa es importante: el trabajo de excepción no debe estimarse como el tiempo de pulsar una opción. Incluye orientarse, comprobar lo irreversible, elegir una respuesta y verificar su efecto. Si el procedimiento mide solo la velocidad de aceptación, puede premiar que alguien asuma formalmente un caso antes de estar en condiciones de resolverlo.

Antes de devolver el control, hay que saber qué control se devuelve

Raja Parasuraman, Thomas Sheridan y Christopher Wickens propusieron en 2000 distinguir cuatro funciones: adquirir información, analizarla, seleccionar decisiones o acciones y ejecutar acciones. Cada función admite diferentes niveles de automatización. Su modelo no prescribe que todo deba automatizarse ni que una persona deba intervenir siempre; ofrece una manera de evaluar la distribución del trabajo considerando el desempeño humano y las consecuencias de las decisiones.

Esta distinción ayuda a desarmar una expresión demasiado amplia: «pasar a manual». En el ejemplo del pedido, la analista puede recibir autoridad para cambiar una dirección mientras el sistema sigue cobrando o liberando mercancía. Eso no es necesariamente incorrecto, pero debe ser visible. El receptor necesita identificar qué función asume, qué automatismos siguen activos y quién resuelve un conflicto entre ambos.

Una regla práctica, propuesta aquí como síntesis editorial, es describir el relevo con verbos: la persona consulta y modifica la dirección; el sistema conserva la reserva; el cobro queda suspendido; logística no recibe una nueva orden hasta que exista confirmación. Esa frase aporta más que un indicador genérico de «modo humano», porque expone las fronteras operativas que después pueden comprobarse.

El paquete mínimo de contexto

La guía People + AI de Google, en su capítulo sobre errores y recuperación, indica que devolver el control exige facilitar la comprensión de la situación, el siguiente paso y la manera de ejecutarlo. También advierte que volver al control manual puede ser arriesgado en algunos contextos. No se trata, por tanto, de añadir un botón como salida universal, sino de diseñar una continuación que resulte practicable.

Para un proceso de oficina, un paquete de contexto puede comenzar por el objetivo del caso y la razón concreta del traspaso. Debe distinguir hechos confirmados de inferencias y mostrar la hora de actualización. «El cliente solicitó cambiar la entrega» no significa lo mismo que «el modelo infiere una posible dirección incorrecta». Si ambas afirmaciones aparecen con la misma apariencia, la persona puede intervenir sobre una certeza que nunca existió.

Después conviene presentar las acciones realizadas y sus efectos: qué se envió, qué se comprometió, qué se puede revertir y qué necesita otro procedimiento. El historial completo puede permanecer disponible, pero el resumen inicial debe responder a la decisión inmediata. Ocultar la evidencia sería problemático; obligar a buscarla entre cientos de registros también puede volver inservible el relevo.

El tiempo para comprender forma parte del diseño

No existe un plazo universal para recuperar contexto. Depende de la complejidad, de la familiaridad con el proceso, de la calidad del resumen y de las consecuencias de equivocarse. Un trámite corregible admite una organización distinta de una operación que afecta seguridad o derechos. Las fuentes consultadas no justifican convertir una cantidad fija de segundos en garantía general de control humano.

Lo que sí puede hacerse es comprobar si el tiempo disponible alcanza para la tarea concreta. Una prueba debe observar cuándo llega el aviso, cuándo alguien está realmente disponible, cuánto tarda en identificar la situación y qué ocurre antes de su primera acción. Esos momentos no son equivalentes. Una confirmación de recepción prueba que se vio el mensaje, no que ya se comprendió el problema.

También hace falta definir el comportamiento durante la espera. En un caso puede ser apropiado mantener una reserva sin enviar el pedido; en otro, detener nuevas acciones y conservar el estado. La respuesta debe acordarse con quienes conocen sus consecuencias. Si nadie recibe el caso, el proceso necesita una salida prevista: no convertir el silencio en aceptación ni continuar como si la transferencia hubiese sido completada.

Autoridad real, no responsabilidad decorativa

Las Guidelines for Human-AI Interaction difundidas por Microsoft incluyen facilitar la invocación, el descarte y la corrección del sistema. Son orientaciones de interacción, no una demostración de que cualquier implementación cumple esos objetivos. Su valor aquí es recordar que el control debe poder ejercerse con acciones comprensibles y disponibles, no únicamente mediante una política escrita.

La autoridad exige permisos técnicos y respaldo organizativo. Si la analista puede detectar un problema pero necesita una aprobación inaccesible para detenerlo, el relevo está incompleto. Si dispone del botón, pero se le penaliza automáticamente por usarlo, también. Diseñar la intervención requiere aclarar qué decisiones puede tomar, cuáles debe escalar y bajo qué condiciones se revisará posteriormente lo que hizo.

El AI Risk Management Framework del NIST sitúa roles, responsabilidades y documentación dentro de la gestión de riesgos de IA. No establece el protocolo específico de esta página, pero apoya la necesidad de distribuir responsabilidades de manera explícita y contextual. La persona que recibe un caso no debería cargar por defecto con decisiones de diseño, permisos o dotación que no controla.

Hay además una segunda mitad del relevo: devolver la tarea a la automatización. Antes de hacerlo, deben quedar visibles las modificaciones humanas, el estado desde el que continúa el proceso y las condiciones que ya no aplican. De lo contrario, un sistema puede repetir la misma acción que la persona acaba de corregir, o tratar un caso excepcional como si nunca hubiese sido revisado.

Ensayar la recuperación, no solo la operación normal

Una demostración comercial suele mostrar el recorrido exitoso. Para evaluar el relevo hace falta ensayar excepciones plausibles con datos de prueba: una señal incompleta, una demora, una acción parcialmente ejecutada o un receptor que no está disponible. Estas pruebas no deben poner en riesgo a clientes o trabajadores ni sustituir los controles especializados de ámbitos críticos.

Conviene pedir a una persona competente, que no haya construido la solución, que explique qué cree que ocurrió y qué hará después. Si necesita que el desarrollador complete verbalmente la historia, el producto todavía depende de contexto que no entrega. El ensayo permite identificar ese vacío antes de interpretar la dificultad como resistencia al cambio o falta de capacitación.

Los indicadores también deben mirar la recuperación. Puede registrarse el tiempo hasta comprender el estado, las acciones incompatibles, la necesidad de buscar información fuera del sistema y la recurrencia de la misma excepción. Son propuestas de evaluación, no métricas universales validadas por las fuentes. Deben leerse junto con la calidad de la solución: resolver deprisa un caso de manera incorrecta no constituye un buen relevo.

La práctica necesita mantenimiento. Una persona que solo recibe excepciones muy infrecuentes puede necesitar simulaciones y oportunidades de repasar el procedimiento. El argumento de Bainbridge no equivale a exigir vigilancia constante; invita a no construir la operación sobre una capacidad humana que la propia automatización deja de ejercitar y que la organización después supone disponible.

Una revisión que puede empezar con un solo caso

No hace falta rediseñar toda la plataforma para comenzar. Seleccionen una excepción recurrente y documenten su recorrido desde el disparador hasta la reanudación. Anoten dónde se pierde información, quién espera a quién y qué acciones siguen ejecutándose. Luego preparen una ficha de relevo breve y pruébenla con el equipo que realmente atenderá esos casos, incluidas las personas del siguiente turno.

El criterio de éxito no es producir una ficha más extensa, sino reducir las preguntas que impiden decidir sin ocultar incertidumbre. Si el receptor puede explicar el estado, reconocer el margen disponible y ejecutar una intervención autorizada, existe una base para mejorar. Si no puede, la siguiente inversión quizá no deba ser un modelo más sofisticado, sino una transición mejor diseñada.

Una automatización útil no demuestra su calidad solo mientras funciona sola. También la demuestra cuando encuentra su límite y permite que alguien continúe sin reconstruir toda la historia desde cero. Devolver el control debería significar entregar condiciones para actuar, no transferir el problema junto con la culpa.

¿Qué tarea automatizada de tu equipo podría volver mañana a una persona, y qué información, tiempo y autoridad encontraría realmente al recibirla?

Elaborado por Ricardo Gaibor.

Este artículo fue elaborado por Ricardo Gaibor con ayuda de sistemas de inteligencia artificial en tareas de investigación, organización y edición. La selección, interpretación y responsabilidad editorial del contenido corresponden al autor.

Referencias

• Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779. DOI: 10.1016/0005-1098(83)90046-8. Texto completo de la misma obra.
• Parasuraman, R., Sheridan, T. B., y Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics—Part A, 30(3), 286–297. DOI: 10.1109/3468.844354. Texto completo de la misma obra.
• Google PAIR (s. f.). Errors + Graceful Failure. People + AI Guidebook. Capítulo sobre errores y recuperación.
• Microsoft Research (2019). Guidelines for Human-AI Interaction. Cartel de las 18 directrices, síntesis del trabajo de Amershi y colaboradores. Directrices de interacción.
• National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. DOI: 10.6028/NIST.AI.100-1. Marco completo del NIST.