PARTE XLII · Inteligencia artificial y automatización
470
Automatización y colaboración entre personas y sistemas
Automatizar una función no elimina el trabajo humano: cambia qué debe vigilarse, cuándo intervenir y quién responde por el resultado
En este capítulo
Un sistema ordena solicitudes y deja a una persona los casos «difíciles». La pantalla muestra una recomendación, pero no el dato que la hizo dudosa. El operador debe decidir rápido, recibe sólo excepciones raras y su aprobación queda registrada como si fuera independiente. Hay un humano en el circuito; no hay supervisión efectiva.
Automatizar es asignar a una máquina parte de la percepción, el análisis, la decisión o la acción dentro de un proceso. El resultado depende de la coordinación completa. La pregunta guía es: ¿cómo distribuir funciones y autoridad para mejorar el resultado sin crear una responsabilidad nominal, una vigilancia imposible o nuevos fallos silenciosos?
470.1. Tareas, procesos y responsabilidades#
Una ocupación contiene tareas, y una tarea contiene pasos, información, criterios y excepciones. Decir que «se automatiza un empleo» mezcla niveles. Conviene describir qué entrada recibe cada actor, qué transformación realiza, qué salida produce y quién usa esa salida.
El proceso incluye trabajo invisible: recopilar datos, corregir formatos, resolver casos fronterizos, explicar decisiones, reparar fallos y atender apelaciones. Una medición de ahorro que excluye ese trabajo desplaza costes sin eliminarlos.
La asignación de funciones no debe basarse en una lista fija de lo que «humanos» y «máquinas» hacen mejor. Capacidad depende del diseño, entrenamiento, carga, contexto y cooperación. Automatizar una etapa cambia las restantes y puede degradar habilidades que luego se necesitan en una emergencia.
Responsabilidad requiere correspondencia entre autoridad, información y recursos. No es razonable responsabilizar a quien no puede inspeccionar ni detener. Tampoco basta afirmar que «decide el sistema»: una organización selecciona objetivos, datos, umbrales, permisos y respuesta a incidentes.
Antes de implantar se dibuja el proceso actual, su alternativa y el proceso propuesto. Esto permite preguntar si la automatización resuelve la causa del problema o acelera una secuencia defectuosa.
470.2. Asistencia, delegación y supervisión#
Un sistema puede recordar, ordenar, recomendar, ejecutar con confirmación o actuar y notificar. Esos modos conceden autoridad distinta. La clasificación debe describir la actividad y su efecto, no un número general de «autonomía».
Asistir conserva la decisión humana sólo si la interfaz no predetermina de hecho la respuesta. Mostrar primero una recomendación puede anclar; exigir justificar cada desacuerdo encarece contradecir; ocultar alternativas convierte la confirmación en trámite.
Delegar exige condiciones de operación y límites. Qué casos puede resolver, cuáles debe escalar, con qué incertidumbre y durante cuánto tiempo. La abstención es una conducta diseñada; si todos los casos reciben salida, la supervisión hereda incluso lo que el sistema desconoce.
Supervisar requiere atención, comprensión y capacidad de actuar. Una persona que vigila demasiados flujos o recibe alarmas frecuentes pierde discriminación. La ratio adecuada depende de frecuencia, tiempo disponible, severidad y facilidad de diagnóstico.
La intervención debe practicarse. Si el sistema opera casi siempre, la persona puede quedar fuera del circuito: observa menos, pierde modelo mental y enfrenta sólo situaciones anómalas. Formación, simulacros, exposición a variedad y traspasos graduales mantienen competencia.
470.3. Errores de automatización y pérdida de contexto#
El sesgo de automatización aparece cuando una recomendación recibe peso excesivo. Convive con el rechazo excesivo: después de fallos visibles, usuarios pueden ignorar incluso alertas útiles. La meta es confianza calibrada, no confianza máxima.
La confusión de modo ocurre cuando la persona cree que el sistema está en un estado o persigue un objetivo distinto del real. Etiquetas ambiguas, transiciones automáticas y retroalimentación tardía la favorecen. Mostrar modo, objetivo, restricciones y acción en curso reduce la discrepancia.
Una sorpresa de automatización no es simplemente que la máquina falle; puede comportarse según diseño de una manera que el operador no anticipó. Esto revela una coordinación deficiente entre modelos mentales, procedimientos e interfaz.
Comprimir información mejora legibilidad, pero puede eliminar contexto necesario para reconocer excepciones. Un puntaje sin evidencia, procedencia o intervalo hace difícil detectar cuándo una regla general no aplica.
La automatización puede volver más difíciles los momentos más difíciles: realiza lo rutinario y entrega a la persona una anomalía compleja, con poco tiempo y habilidades poco practicadas. Evaluar sólo la carga promedio oculta el pico decisivo.
470.4. Diseño de interfaces y límites de autonomía#
Una interfaz operacional debe responder: qué ocurre, por qué importa, qué hará el sistema, con qué límites y qué puede hacer la persona. La explicación debe apoyar una acción; una lista técnica de variables no sustituye comprensión situacional.
Estados y cambios necesitan señales persistentes. Una notificación efímera no basta para una transición crítica. Alarmas se priorizan por urgencia y consecuencia, se agrupan por causa y permiten reconocer cuál fue atendida.
Los controles de intervención deben ser accesibles y tener efecto predecible. «Apagar IA» puede dejar un proceso en estado inconsistente. Son preferibles modos degradados definidos, retorno manual practicable y registro de quién controla qué.
Los límites de autonomía combinan permisos, zonas, montos, tipos de caso y tiempo. Deben aplicarse técnicamente cuando sea posible. Una política escrita que el sistema puede saltar no es una frontera.
La trazabilidad registra entradas relevantes, versión, recomendación, acción humana y resultado, respetando privacidad y seguridad. No debe convertirse en vigilancia indiscriminada. Su propósito es reconstruir, aprender y reparar, no fabricar una ilusión de culpabilidad individual.
470.5. Evaluación de resultados en organizaciones reales#
La métrica local —tiempo por solicitud, exactitud o producción— no basta. Se miden resultados del proceso: calidad, seguridad, acceso, demoras totales, apelaciones, carga distribuida y efectos por grupo. Una mejora media puede empeorar el caso de quienes más dependen del servicio.
La comparación necesita alternativa. El sistema nuevo puede superar un procedimiento malo sin ser aceptable; también puede tener menor precisión aislada y mejorar el equipo al ordenar evidencia. Ensayos escalonados y pilotos con criterios de parada permiten aprender sin universalizar de inmediato.
Los indicadores cambian cuando se vuelven objetivos. Personas adaptan conducta, casos difíciles se excluyen y errores pueden reclasificarse. Combinar datos, revisión cualitativa e incidentes reduce ese cegamiento.
La participación de quienes realizan y reciben el trabajo descubre excepciones, cargas y daños que no aparecen en especificaciones. Consultar no equivale a ceder toda decisión, pero aporta conocimiento operativo y legitimidad.
La revisión continúa tras el despliegue. Se definen responsables, cadencia, umbrales, canal de apelación y capacidad de suspender. Automatización responsable no es una compra terminada: es una configuración organizativa que debe demostrar su valor y conservar la posibilidad de corrección.
Síntesis#
La unidad de diseño es el proceso sociotécnico. Hay que descomponer tareas, reconocer trabajo invisible y alinear autoridad con información. Asistencia, delegación y ejecución son relaciones distintas. Sesgo, confusión de modo y pérdida de competencia nacen de la coordinación, no sólo de errores individuales. Interfaces y límites deben hacer visible el estado y permitir intervención real. El éxito se juzga por resultados del sistema completo, incluidos daños, carga, acceso y capacidad de apelar.
Preguntas de transferencia#
1. ¿Poner una confirmación humana después de cada recomendación garantiza responsabilidad?#
No. Si la persona carece de tiempo, evidencia o autoridad, la confirmación es nominal y puede aumentar la ilusión de control.
2. ¿Automatizar tareas rutinarias siempre reduce la carga humana?#
No. Puede dejar sólo excepciones complejas, crear vigilancia y reparación, o aumentar el pico de carga durante fallos.
3. ¿Qué debe mostrar una interfaz además de la recomendación?#
Estado, objetivo, límites, evidencia pertinente, incertidumbre y acciones disponibles, en una forma útil para decidir.
4. ¿Qué demuestra una mejora de productividad?#
Sólo una dimensión. Deben examinarse calidad, seguridad, distribución de carga, acceso, apelaciones y efectos a largo plazo.
Clave de lectura. Mover una caja al carril humano no crea control. El traspaso debe incluir contexto y una intervención que cambie efectivamente la acción.
Fuentes y lecturas del capítulo#
- NIST. Mary Frances Theofanos, Yee-Yin Choong y Theodore Jensen. AI Use Taxonomy: A Human-Centered Approach. 2024.
- NASA. R. Eric Chancey. A Human-Autonomy Teaming Framework for Flight Operations. 2020.
- NASA. David D. Woods y Nadine B. Sarter. Learning from Automation Surprises and “Going Sour” Accidents. 1998.
- Federal Aviation Administration. Human Factors in Aviation Safety. Informes de uso operacional y diseño de interfaces; actualización consultada: 7 de octubre de 2026.
- International Labour Organization. Effects of digitalization on the human centricity of social security administration and services. 2023.
- International Labour Organization. Revolutionizing health and safety: the role of AI and digitalization at work. 2025.