La supervisión humana de la IA se degrada cuando todo acaba en un botón de «aprobar»

Un agente de inteligencia artificial puede hacer algo más peligroso que equivocarse: conseguir que la persona que debe vigilarlo deje de mirar con atención.

La advertencia procede de una investigación difundida el 8 de septiembre de 2026 por Bank Info Security, basada en un trabajo de investigadores de Hugging Face y Data & Society publicado en arXiv con la referencia 2608.23642. Su tesis es incómoda para cualquier empresa que haya resuelto la supervisión de la IA con una ventana emergente y dos botones: «aprobar» y «rechazar». Si el sistema solicita permisos constantemente, la revisión humana puede convertirse en un reflejo. Si solicita pocos, el supervisor puede perder el hilo de lo que ha hecho durante el tiempo que ha operado por su cuenta.

El problema no es solo de usabilidad. Afecta al diseño del control interno, a la asignación de responsabilidades y a la capacidad real de una organización para demostrar que la supervisión fue significativa. El artículo 14 del Reglamento europeo de IA exige que los sistemas de alto riesgo incorporen medidas de supervisión humana y que quienes los supervisan sean conscientes del sesgo de automatización. La ley no describe una pantalla de aprobación mágica. Exige algo bastante más difícil: que una persona pueda entender qué está haciendo el sistema, detectar anomalías y, cuando proceda, ignorar o revertir su resultado.

Ahí está el quid. Una persona que pulsa «sí» 200 veces al día no necesariamente está supervisando 200 decisiones. Puede estar sellando el trabajo de una máquina cuyo estado, objetivo y efectos ya no comprende.

El falso dilema entre aprobarlo todo y no aprobar nada

Los agentes de IA no funcionan como un chatbot que responde a una pregunta y espera la siguiente. Pueden planificar una tarea, ejecutar pasos, consultar información, modificar su estrategia según los resultados y continuar hasta alcanzar un objetivo. Esa autonomía cambia la unidad básica de supervisión.

En un sistema tradicional, el operador revisa una salida relativamente delimitada: una alerta, una recomendación, una transacción o un fragmento de código. En un sistema agentic, la salida visible puede ser el final de una cadena de acciones. El agente pudo haber consultado una base de datos, utilizado credenciales, escrito archivos, llamado a una API y cambiado su plan antes de pedir autorización para el siguiente paso. El supervisor ya no tiene que juzgar solo una acción; debe reconstruir una trayectoria.

La reacción intuitiva es colocar un permiso humano antes de cada acción sensible. Es comprensible y, en algunos casos, necesario. Pero una autorización por paso puede crear lo que los investigadores denominan approval fatigue, o fatiga de aprobación. Cuantas más solicitudes recibe una persona, menos tiempo y atención dedica a cada una. La supervisión se vuelve rutinaria precisamente porque el sistema la presenta como rutinaria.

El extremo contrario tampoco resuelve el problema. Si el agente trabaja durante horas sin intervención, el supervisor puede recibir una petición de aprobación cuando ya se han producido demasiados cambios para evaluarlos de forma aislada. El contexto que debía permitir una decisión informada llega tarde, comprimido en un resumen y, a menudo, generado por el propio sistema que está siendo evaluado.

La pregunta correcta no es «¿cuántas veces debe intervenir una persona?». Es «¿en qué punto aporta criterio humano y qué información necesita para ejercerlo?». La diferencia parece semántica hasta que se traduce en controles. Una buena arquitectura no maximiza clics humanos. Maximiza decisiones humanas que cambian el resultado cuando el riesgo lo exige.

La aprobación repetida puede fabricar una ilusión de control

La investigación citada por Bank Info Security recoge trabajos sobre desarrolladores que utilizan agentes de programación y recurren a atajos al verificar su trabajo. Algunos interpretan el plan del agente como una prueba de lo que realmente hará. Otros dan por correcto el código porque las comprobaciones automáticas indican que determinadas partes funcionan.

Ese salto lógico merece atención. Un plan no es una ejecución. Un test que pasa no demuestra que el sistema sea seguro fuera de los casos cubiertos por ese test. Y una aprobación humana no demuestra que haya existido revisión humana en sentido sustantivo.

En seguridad de la información, el patrón es familiar. Un control puede existir sobre el papel y fallar como barrera operativa. El sistema registra que un usuario aprobó una modificación, pero no registra qué evidencias vio, qué alternativas tenía ni si la decisión podía revertirse. Para una auditoría, hay un evento. Para la gestión del riesgo, quizá solo hubo un clic.

La automatización introduce además un deterioro progresivo de la pericia. Cuando una persona delega de forma continuada una tarea, practica menos la ejecución manual y puede perder capacidad para evaluar sus resultados. Lisanne Bainbridge describió esta paradoja en 1983 en su trabajo Ironies of Automation: la automatización retira al operador de buena parte de la actividad rutinaria, pero lo conserva como responsable cuando aparece lo excepcional.

El diseño parece eficiente mientras todo sale bien. El problema llega cuando surge la excepción. El profesional que ya no realiza la tarea con frecuencia debe intervenir en su momento más difícil, con menos práctica, menos contexto y la presión añadida de corregir un sistema que ha podido avanzar varios pasos sin él. La automatización no elimina la responsabilidad; puede concentrarla en los episodios en los que resulta más costoso ejercerla.

Para un banco, una aseguradora o una empresa tecnológica, esto cambia la definición de «humano en el circuito». Tener un profesional disponible no basta. Debe conservar conocimientos, disponer de tiempo y recibir señales que le permitan cuestionar la recomendación de la máquina. Si no puede explicar por qué aprobó una acción o qué habría ocurrido si la rechazaba, la supervisión es nominal.

Qué exige realmente el artículo 14 del Reglamento europeo de IA

El artículo 14 del Reglamento (UE) 2024/1689 establece requisitos de supervisión humana para los sistemas de IA de alto riesgo. Entre ellos, que las medidas de supervisión permitan a las personas comprender las capacidades y limitaciones pertinentes del sistema, vigilar su funcionamiento, interpretar correctamente sus resultados y decidir, según corresponda, no utilizar el sistema o ignorar, anular o revertir su salida.

El mismo artículo exige que los supervisores sean conscientes de la posible tendencia a confiar automáticamente en la salida de un sistema, incluso cuando ese resultado puede ser incorrecto. Es el llamado sesgo de automatización. No se trata de pedir una desconfianza teatral ante cada recomendación. Se trata de evitar que la interfaz, la presión operativa o el historial de aciertos conviertan la recomendación en una orden de facto.

También importa la competencia de quienes ejercen la supervisión. El artículo 14 vincula la supervisión a la formación, el conocimiento, las competencias y la autoridad necesarias para cumplir esa función. Un empleado que solo puede aceptar la decisión, que no tiene acceso a los datos de entrada o que desconoce los límites del modelo no tiene capacidad efectiva de supervisión aunque su nombre figure en el procedimiento.

La aplicación práctica depende de la clasificación del sistema y de su uso concreto. No todo agente que incorpora un modelo de lenguaje será automáticamente un sistema de alto riesgo bajo el Reglamento de IA. Pero esa cautela jurídica no convierte en razonable una arquitectura de permisos defectuosa. Las obligaciones de seguridad, privacidad, continuidad y control interno pueden ser relevantes aunque la clasificación específica bajo el Reglamento de IA no sea la de alto riesgo.

En una entidad financiera, por ejemplo, un agente que prepara un borrador interno de análisis no presenta el mismo perfil que uno que interviene en una decisión sobre acceso al crédito, ejecuta una operación o modifica controles de seguridad. La cuestión no es poner la misma barrera a todos los usos. Es relacionar el nivel de autonomía con el daño potencial y con la capacidad de recuperación.

La conexión con DORA: el agente también es una dependencia operativa

Para las entidades financieras europeas, la discusión no termina en el Reglamento de IA. El Reglamento (UE) 2022/2554 sobre resiliencia operativa digital —DORA— es aplicable desde el 17 de enero de 2025 y obliga a gestionar los riesgos asociados a las tecnologías de la información y las comunicaciones, incluidos los derivados de proveedores terceros de servicios TIC.

Un agente desplegado por la propia entidad puede apoyarse en modelos externos, plataformas cloud, herramientas de observabilidad, conectores y servicios de ejecución. Por tanto, el mapa de riesgo no debe describir únicamente «el modelo». Debe seguir la cadena completa: qué datos recibe, qué herramientas puede invocar, con qué identidad opera, qué permisos conserva, dónde se registran sus acciones y qué ocurre si el proveedor deja de estar disponible.

El artículo 28 de DORA exige que las entidades gestionen el riesgo TIC de terceros y mantengan la responsabilidad plena sobre el cumplimiento de sus obligaciones regulatorias. Contratar un agente como servicio no transfiere esa responsabilidad al proveedor. Si el sistema solicita aprobaciones humanas de forma tan frecuente que los operadores dejan de leerlas, el fallo es de diseño de control de la entidad, aunque el software proceda de un tercero.

El artículo 30 de DORA exige que determinados contratos con proveedores TIC incluyan elementos específicos, como descripciones claras de los servicios, niveles de servicio, derechos de acceso, cooperación con las autoridades y condiciones de terminación. En un servicio agentic, el contrato y la documentación técnica deberían permitir responder a preguntas mucho más concretas que «¿el proveedor cumple con la seguridad?»: ¿qué acciones puede ejecutar el agente?, ¿cómo se modifican sus permisos?, ¿qué registros se conservan?, ¿cuánto tarda el proveedor en facilitar evidencias de una acción?, ¿puede la entidad suspender selectivamente una herramienta sin apagar todo el servicio?

El artículo 11 de DORA, dedicado a la respuesta y recuperación, también ofrece una lente útil. Un agente que puede modificar configuraciones, abrir incidencias o ejecutar transacciones debe tener un modo de contención claro. No basta con revocar la cuenta del operador humano si el agente mantiene tokens, sesiones o integraciones activas. La capacidad de parar un agente debe probarse como se prueba la recuperación de un servicio crítico, no descubrirse durante un incidente.

La supervisión humana, vista desde DORA, es una capacidad operativa. Necesita personal, procedimientos, registros, pruebas y una alternativa manual razonable. Si el supervisor no puede reconstruir lo que el agente hizo, la entidad no solo tiene un problema de confianza en la IA: tiene un problema de trazabilidad y de resiliencia.

Privacidad y seguridad: el «sí» puede autorizar mucho más de lo que parece

Los investigadores citados señalan riesgos concretos para los agentes: borrar archivos, exponer información sensible, explotar vulnerabilidades de software o ejecutar transacciones financieras. No son ejemplos abstractos. Son acciones con consecuencias técnicas, económicas y regulatorias diferentes.

Un permiso para «continuar con la investigación» puede permitir que un agente consulte repositorios que contienen datos personales. Una autorización para «resolver la incidencia» puede conceder acceso a producción. Una aprobación para «completar el pago» puede desencadenar una operación irreversible. La etiqueta de la acción importa porque determina qué cree estar aprobando el usuario; el alcance técnico real importa mucho más.

El artículo 5 del Reglamento General de Protección de Datos exige, entre otros principios, limitación de la finalidad, minimización de datos, exactitud, limitación del plazo de conservación, integridad y confidencialidad. Un agente con acceso amplio y una instrucción vaga puede incumplir varios de esos principios sin que exista una filtración espectacular. Puede consultar más información de la necesaria, reutilizarla para una finalidad distinta o conservarla en registros operativos que nadie revisa.

El artículo 25 del RGPD obliga a aplicar protección de datos desde el diseño y por defecto. En el caso de los agentes, eso debería traducirse en permisos acotados, herramientas separadas por función, datos mínimos, entornos de prueba y límites de tiempo. La aprobación humana no debe utilizarse como sustituto de una arquitectura de mínimo privilegio. Si el agente puede acceder a todo, esperar que una persona detecte cada uso indebido no es protección por diseño; es delegar el control en la atención humana.

El artículo 32 del RGPD exige medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. Entre ellas pueden encajar el control de acceso, la resiliencia, la capacidad de restauración y la evaluación periódica de la eficacia de las medidas. Un registro de cada llamada de herramienta, identidad utilizada, datos consultados, resultado obtenido y autorización recibida no resuelve por sí mismo el riesgo, pero permite investigarlo. Sin trazabilidad, una organización puede no saber si la persona aprobó una acción concreta o un conjunto de consecuencias que la interfaz no mostraba.

La retención de esos registros tampoco es un asunto menor. Guardar el historial completo de cada interacción puede mejorar la investigación y aumentar el riesgo de privacidad. El diseño debe definir qué se registra, para qué, durante cuánto tiempo, quién puede acceder y cómo se protegen los datos del propio registro. Más logs no equivalen automáticamente a más control.

La supervisión debe diseñarse alrededor de decisiones, no de clics

La propuesta más útil de la investigación no consiste en eliminar la aprobación humana, sino en decidir de antemano qué puede hacer el agente sin autorización y qué acciones deben reservarse al criterio humano. El principio parece sencillo. Su ejecución exige descomponer el objetivo del agente en capacidades concretas.

Un equipo debería distinguir, como mínimo, entre acciones reversibles e irreversibles, operaciones internas y externas, lectura y escritura, datos públicos y datos restringidos, cambios de bajo impacto y cambios capaces de afectar a clientes, fondos o disponibilidad de sistemas. «Enviar un correo» no tiene un riesgo fijo: dependerá de los destinatarios, del contenido y de si contiene datos personales. «Modificar un archivo» tampoco: no es lo mismo un documento temporal que una política de firewall.

La autorización puede agruparse por una tarea coherente, en lugar de solicitarla para cada microacción. El ejemplo de los investigadores es un agente de programación que realiza varios cambios necesarios para completar una pieza de trabajo y presenta el conjunto para revisión. El supervisor ve el diff completo, los tests ejecutados, las dependencias afectadas y la justificación de cada cambio. Eso permite evaluar el resultado como sistema, no una secuencia de «síes» desconectados.

Pero agrupar no significa ocultar. La interfaz debe conservar el detalle suficiente para que el supervisor pueda abrir la cadena de acciones, identificar herramientas utilizadas, consultar evidencias y conocer qué quedará modificado si aprueba. El resumen debe servir para orientarse, no para sustituir el expediente.

Las aprobaciones de mayor impacto también deberían exigir más fricción deliberada. Los investigadores proponen que el usuario formule primero su propio juicio antes de ver la recomendación del agente, revise evidencias o elija entre alternativas en lugar de pulsar simplemente «sí» o «no». En un proceso de fraude, por ejemplo, la persona podría indicar inicialmente si considera que existen señales suficientes para bloquear una operación y después comparar su evaluación con la recomendación automatizada. El objetivo no es convertir cada decisión en un examen, sino evitar que la primera respuesta visible ancle el criterio humano.

La fricción debe ser proporcional. Un control que obliga a introducir una justificación para cada acción trivial será ignorado o automatizado. Uno que exige una segunda revisión independiente para transferencias de alto importe puede ser razonable. La ingeniería del control está en distinguir ambos casos.

Qué debe medir un CISO o responsable de compliance

El número de aprobaciones no demuestra la calidad de la supervisión. Una métrica más informativa combina comportamiento, contexto y resultados. ¿Cuánto tarda el supervisor en revisar cada tipo de solicitud? ¿Qué porcentaje rechaza o modifica? ¿Cuántas veces consulta las evidencias? ¿Cuántas aprobaciones se producen sin abrir el detalle? ¿Cuántas acciones ejecutadas por el agente se revierten después?

Ninguna de estas señales, aislada, prueba que exista fatiga. Un porcentaje bajo de rechazos puede indicar que el agente funciona bien. También puede indicar que nadie cuestiona sus recomendaciones. La interpretación requiere comparar los datos con pruebas controladas y con el riesgo de las tareas.

Una práctica razonable consiste en introducir de forma ocasional trabajo sintético con errores conocidos y medir si los supervisores los detectan. La prueba debe estar gobernada, no utilizar datos reales innecesarios y no convertirse en una trampa disciplinaria. Su finalidad es comprobar si el control funciona cuando la respuesta correcta no coincide con la recomendación automatizada.

También conviene rotar entre tareas asistidas y no asistidas. Si un analista de fraude solo revisa alertas ya priorizadas por un agente, puede perder contacto con los casos base y con los patrones que explican los falsos positivos. Si un desarrollador solo valida código generado, puede practicar menos el razonamiento necesario para detectar errores de diseño. La rotación no es una medida nostálgica ni una defensa contra la tecnología. Es mantenimiento de la capacidad humana que el control necesita cuando la automatización falla.

La formación debe incluir los límites concretos del sistema utilizado: qué fuentes consulta, qué no puede verificar, cuándo puede inventar una respuesta, qué herramientas tiene disponibles, qué permisos utiliza y qué tipos de error se han observado. Una sesión genérica sobre «uso responsable de la IA» no prepara a nadie para decidir si debe permitir que un agente despliegue un cambio en producción.

Desde la perspectiva de auditoría, la evidencia debería conectar cuatro elementos: la acción propuesta, el riesgo que justificó la intervención, la información disponible para el supervisor y el resultado final. Una captura de pantalla con la palabra «aprobado» es una evidencia pobre si no muestra el alcance de la acción ni la base de la decisión.

El control que conviene evitar: convertir al supervisor en una firma electrónica

La tentación empresarial es evidente. Se compra un agente, se añade una aprobación humana y se declara cerrado el debate de gobernanza. Es una solución cómoda porque produce una casilla en el diagrama de proceso y un registro en el sistema. También puede ser una solución frágil.

El supervisor no debe ser el mecanismo por el que la empresa legitima todas las decisiones que el agente ya ha tomado. Debe conservar autoridad real para detenerlo, modificar su curso y exigir una explicación suficiente. Si el procedimiento penaliza los rechazos, si el tiempo asignado no permite leer la evidencia o si el sistema reintenta automáticamente la acción hasta conseguir un permiso, la supervisión es decorativa.

Hay una señal especialmente preocupante: que el agente presente una única recomendación sin explicar las alternativas descartadas. La elección binaria reduce el coste cognitivo, pero también limita el juicio. Para decisiones de impacto, mostrar opciones, incertidumbre, datos determinantes y consecuencias reversibles puede ser más útil que producir una respuesta aparentemente precisa.

La organización debe definir quién tiene autoridad para parar el sistema y qué sucede después. Un agente que detecta una anomalía no debería depender de la misma persona que está sometida a fatiga para desactivarse. En funciones críticas puede ser necesario un mecanismo independiente de suspensión, credenciales separadas y un procedimiento de escalado que no pase por el agente.

También debe quedar claro quién responde por los errores. El proveedor puede ser responsable de defectos contractuales o de incumplimientos concretos; el desarrollador puede responder por una configuración; el operador puede haber aprobado una acción; el propietario del proceso puede haber fijado permisos excesivos. La rendición de cuentas no se resuelve asignando toda la culpa al último humano que pulsó un botón.

La cuestión regulatoria de fondo no es si la IA tiene un humano al lado

La investigación de Hugging Face y Data & Society recupera una advertencia de décadas: dejar a las personas para intervenir solo cuando algo raro ocurre puede hacer que lleguen peor preparadas al momento decisivo. En 2026, la novedad no es la paradoja. Es la velocidad y amplitud con la que los agentes pueden actuar entre una aprobación y la siguiente.

Para las empresas, la respuesta no consiste en congelar la automatización ni en imponer una revisión manual universal. Consiste en clasificar acciones, limitar permisos, agrupar revisiones con sentido, mostrar evidencias, probar la atención y mantener las capacidades que el control necesita. El agente debe tener autonomía suficiente para aportar valor, pero no tanta como para convertir al supervisor en espectador.

El artículo 14 del Reglamento de IA ofrece el principio jurídico; DORA, para las entidades financieras, añade la disciplina de resiliencia, terceros, registros y recuperación; el RGPD obliga a llevar el análisis hasta los datos, los accesos y el diseño por defecto. Ninguno de estos textos garantiza por sí solo que una persona esté supervisando de verdad. La regulación puede exigir el control. No puede leer cada pantalla en nombre de la organización.

La prueba definitiva es sencilla y poco complaciente: si el agente propone una acción peligrosa, ¿puede el supervisor detectarla antes de que ocurra, explicar por qué es peligrosa, rechazarla sin consecuencias operativas indebidas y demostrar después qué información utilizó? Si la respuesta depende de que alguien pulse «aprobar» con mucha atención cientos de veces al día, la empresa no ha diseñado supervisión humana. Ha diseñado esperanza con interfaz gráfica.