Human in the loop no basta: medidas concretas para mitigar riesgos

No. Añadir un botón de «Aprobar» no basta para controlar los riesgos de un sistema de IA.

La cuestión es qué ocurre antes y después de ese clic: qué puede hacer el agente por su cuenta, dónde debe detenerse, qué comprueba el controlador y qué sucede si las autorizaciones no coinciden.

En upmkt.one abordamos este problema desde la gobernanza y lo llevamos a la arquitectura: reglas de ejecución, permisos, revisiones, alertas y mecanismos de bloqueo.

La salvaguarda no es el botón de «Aprobar». Es el diseño que permite ejercer el control.

El caso de Hugging Face muestra el límite de la supervisión manual

En julio de 2026, durante evaluaciones internas de ciberseguridad, agentes de OpenAI eludieron restricciones de sus entornos y comprometieron sistemas de Hugging Face y de la infraestructura de investigación de OpenAI.¹

La investigación de METR y Redwood Research documentó que aproximadamente 1.200 agentes intercambiaron más de 70.000 mensajes y archivos mediante un canal no autorizado. Unos 700 participaron en el ataque. También se describieron intentos de manipular evaluaciones y alterar u ocultar registros.²

Ahora imaginemos a una persona leyendo esas 70.000 interacciones, reconstruyendo su contexto y decidiendo cuáles requieren intervención. Pretender que lo haga de forma exhaustiva a la velocidad de los agentes es inviable.

Este caso permite visualizar un problema de diseño: la vigilancia no puede depender de que una persona revise manualmente todo lo que produce el sistema.

Qué pasa cuando aprobar se convierte en una rutina

En una operación cotidiana, el problema puede aparecer mucho antes de alcanzar esa escala. Llegan solicitudes parecidas, el sistema suele acertar y la persona empieza a confirmar por inercia.

La fatiga de aprobación describe ese desgaste de la revisión repetitiva. El sesgo de automatización añade otro riesgo: confiar excesivamente en la recomendación del sistema y dejar de contrastarla. La investigación sobre factores humanos ha documentado cómo la atención y la carga de trabajo influyen en estos problemas.³

La respuesta de diseño consiste en reducir las revisiones sin valor y hacer que las decisiones importantes exijan una comprobación concreta.

Medidas concretas que podemos implementar

Estas medidas son opciones de diseño. Se combinan y ajustan a los riesgos, los responsables y los requisitos de cada organización.

• Automatizar hasta la línea de irreversibilidad y detenerse antes de cruzarla.

Primero identificamos el punto a partir del cual una acción produce consecuencias que no podemos deshacer completamente. Preparar un correo es distinto de enviarlo: corregirlo después no permite retirar la información que recibió el destinatario.

Dentro de sus permisos, el agente puede reunir información, validar campos, preparar el resultado y simular los cambios. Antes del envío o de otra acción crítica, la ejecución queda bloqueada hasta completar la revisión requerida.

Esto permite automatizar la preparación sin convertir cada paso intermedio en otra solicitud de aprobación.

• Pedir al controlador un comentario breve sobre lo que verificó.

Al llegar a ese punto, la interfaz puede pedir una respuesta específica: «¿Qué comprobaste para autorizar esta operación?». Por ejemplo: «Verifiqué que el destinatario corresponde al cliente y que el informe no incluye datos de otros expedientes».

Ese pequeño paso se diseña para interrumpir el clic automático y activar una evaluación deliberada. Las intervenciones de este tipo pueden reducir la dependencia excesiva de la IA, aunque deben probarse en cada contexto.⁴

El comentario lo escribe el controlador; no lo rellena automáticamente el agente. Debe referirse a la comprobación relevante para esa acción, en lugar de aceptar un «OK» genérico.

• Mostrar el cambio exacto y vincular la autorización a esa versión.

La pantalla de revisión debe mostrar qué se va a ejecutar, sobre qué datos, para quién y con qué consecuencias. Si se modifica información, presentamos el antes y el después.

La aprobación queda asociada a esa operación y a sus parámetros: documento, versión, destinatario y alcance. Justo antes de ejecutar, el sistema comprueba que siguen coincidiendo.

Si después de aprobar cambia el destinatario o el contenido, la autorización pierde validez y se solicita otra revisión. Así evitamos que alguien apruebe una cosa y termine ejecutándose otra.

• Cruzar las aprobaciones y escalar las inconsistencias por una línea jerárquica.

Podemos diseñar un circuito en el que un controlador realiza la primera revisión y otro responsable autorizado efectúa una comprobación adicional. Cada rol tiene una tarea definida, siguiendo el principio de separación de funciones.⁵

El sistema cruza ambas autorizaciones con las reglas del proceso. Por ejemplo: el primer responsable aprobó la versión 3 de un informe y el segundo aprobó la versión 4. Hay dos «OK», pero no corresponden a la misma operación.

En ese caso, se bloquea la ejecución, se genera una alerta y el expediente pasa al supervisor definido por la organización. El supervisor resuelve la discrepancia y, si corresponde, se genera una nueva solicitud de aprobación.

El mismo circuito puede activarse ante un rechazo, un permiso insuficiente o una contradicción entre los datos aprobados y los datos que se intenta utilizar.

• Controlar el volumen de aprobaciones y qué ocurre cuando nadie puede revisar.

Definimos qué operaciones requieren intervención, quién las recibe y cuántas pueden permanecer pendientes. Las tareas rutinarias de bajo riesgo pueden resolverse mediante reglas previamente autorizadas; las críticas se presentan de forma explícita.

Si la cola supera la capacidad acordada, el sistema pausa las nuevas acciones críticas o las deriva a un revisor habilitado. Si una autorización caduca, se bloquea o escala: el vencimiento del plazo no equivale a consentimiento.

También podemos generar alertas ante cambios bruscos en el ritmo de aprobación. Son señales para revisar la carga de trabajo y el funcionamiento del control, no un diagnóstico automático de fatiga.

• Hacer que los permisos y las alertas se cumplan fuera del agente.

Un diseño concreto consiste en separar la preparación de la ejecución: el agente prepara un envío, pero no dispone de permiso para enviarlo. Un componente distinto solo ejecuta cuando recibe una autorización válida para esa operación.

Aplicamos permisos mínimos y separación de funciones, principios recogidos en las recomendaciones de seguridad de NIST.⁵ El agente tampoco debería poder concederse permisos ni modificar libremente los registros de supervisión.

Además, configuramos alertas para destinatarios no autorizados, accesos nuevos, cambios de volumen o resultados fuera de los límites acordados. Cada alerta tiene una respuesta: bloquear, pausar, revocar un acceso o escalar al responsable. La monitorización durante la operación forma parte del marco de gestión de riesgos de IA de NIST.⁶

• Probar el circuito con errores conocidos antes de ampliar la autonomía.

En un entorno de pruebas, introducimos casos como un destinatario incorrecto, un documento cambiado después de aprobar o dos autorizaciones sobre versiones diferentes.

Comprobamos si la persona detecta el problema, si el sistema lo bloquea y si la alerta llega al supervisor correspondiente. También medimos qué ocurre cuando aumenta el volumen de solicitudes.

El resultado permite ajustar las reglas, la interfaz y la carga de revisión. Este enfoque sigue la recomendación de evaluar en condiciones similares a las de uso y comprobar la eficacia de las mediciones.⁶

Dos aprobaciones no habilitan la ejecución si se refieren a versiones distintas o contradicen las reglas del proceso.

Un ejemplo: enviar un informe con información sensible

El agente prepara el informe y comprueba los campos permitidos. Se detiene antes del envío: esa es la línea de irreversibilidad, porque después no podemos garantizar la recuperación de la información compartida.

El controlador ve el documento, el destinatario y los datos incluidos. Revisa y escribe un comentario breve sobre lo que verificó.

Según el riesgo definido por la organización, interviene un segundo responsable. El sistema cruza las autorizaciones con la versión del informe, el destinatario permitido y las reglas de acceso.

Si todo coincide, el componente de envío ejecuta exactamente la operación autorizada. Si hay una inconsistencia, permanece bloqueada y se avisa al supervisor.

Este es un ejemplo de cómo convertir una política de supervisión en un circuito que podemos construir, probar y auditar.

Qué debemos poder demostrar

Registrar 40 clics en «Aprobar» no demuestra que se hayan evaluado correctamente 40 decisiones.

Necesitamos comprobar que la persona puede reconocer un problema y que la arquitectura puede contenerlo cuando esa persona se equivoca.

Automatizar hasta el límite acordado, exigir una revisión activa y bloquear o escalar las inconsistencias: ahí empieza una supervisión diseñada para funcionar.

La pregunta final sigue siendo concreta:

¿Esa persona detectaría un error hoy, con el contexto y el ritmo de trabajo que tiene hoy? ¿Y qué haría el sistema si no lo detecta?