30 de septiembre de 2026 · KI · Automatisierung · Regulatorik · Mittelstand

La autorización que nadie ve

Una autorización puede funcionar según lo previsto y aun así esperar mucho sin que nadie lo note. Por qué vigilar las esperas en automatizaciones y agentes de IA.

Quien encarga tareas a automatizaciones o agentes de IA incorpora a una persona en los puntos críticos: antes de que un cambio pase a producción, de que los datos salgan de la empresa o de que algo ya no pueda deshacerse, alguien tiene que dar su aprobación. El principio es correcto, y los marcos normativos lo recogen. De una propiedad de estas autorizaciones se habla, sin embargo, rara vez: son invisibles mientras nadie mira.

Un escenario típico

Supongamos que un proceso automatizado –una sincronización de datos, un despliegue de software, un cambio de permisos– llega a pasos que necesitan una autorización humana. Esperan durante muchas horas sin que nadie lo note. No hay nada roto. La puerta de autorización funciona exactamente como está construida: se detiene y espera. Lo único que falla es su visibilidad.

La razón es estructural. Un proceso que espera de forma bloqueante una autorización, por regla general no da señales por sí mismo: al fin y al cabo, está bloqueado. Desde fuera, un proceso en espera parece uno tranquilo: ningún mensaje de error, ninguna alarma, ninguna salida. Quien no mira de forma deliberada toma el silencio por funcionamiento normal o por un paso de trabajo que simplemente sigue en curso. Y quien tendría que conceder la autorización quizá ni siquiera sabe que está pendiente: la solicitud está en una interfaz que en ese momento nadie tiene abierta.

Estas esperas suelen hacerse visibles solo a posteriori, cuando alguien analiza las marcas de tiempo de los registros. De ello se sigue una segunda cosa: sin esas marcas de tiempo ni siquiera se conocería el orden de magnitud, solo la vaga impresión de que «esta vez ha tardado algo más».

Qué entienden los marcos normativos por supervisión humana

El reglamento europeo de IA (Reglamento (UE) 2024/1689) regula en su artículo 14 la supervisión humana de los sistemas de IA de alto riesgo. Estos deben diseñarse de modo que las personas físicas puedan supervisarlos eficazmente durante su uso. El apartado 4 enumera para qué deben estar capacitadas las personas que ejercen la supervisión. Entre ellas figura vigilar el funcionamiento para detectar anomalías, problemas de funcionamiento y comportamientos inesperados, así como «ser conscientes de la posible tendencia a confiar automáticamente o en exceso en los resultados de salida generados por un sistema de IA de alto riesgo (“sesgo de automatización”)», descartar, invalidar o revertir los resultados de salida, e «intervenir en el funcionamiento del sistema de IA de alto riesgo o interrumpir el sistema pulsando un botón de parada o mediante un procedimiento similar».

Si un sistema concreto entra en el ámbito de esta disposición es una cuestión de clasificación en cada caso. Como criterio, la idea sirve también allí donde el reglamento no se aplica.

El NIST AI Risk Management Framework (AI RMF 1.0, enero de 2023) lo formula como tarea organizativa: los procesos de supervisión humana deben estar definidos, evaluados y documentados (MAP 3.5), y los roles y responsabilidades en la interacción entre personas e IA, claramente delimitados (GOVERN 3.2). El framework señala además que puede ser útil recopilar datos sobre con qué frecuencia y por qué motivos las personas anulan los resultados de los sistemas de IA desplegados.

Ambos textos presuponen que la persona está ahí cuando se la necesita. Cómo se entera a tiempo es cosa de la implementación, y precisamente ahí está la brecha del escenario.

Esperar es un estado que debe vigilarse

Del escenario pueden derivarse cuatro reglas. Valen para scripts, pipelines y herramientas de workflow igual que para agentes de IA, y tanto más cuanto más autónomamente trabaje un proceso, porque con menor frecuencia lo observa alguien.

«En espera de autorización» se convierte en un estado propio y vigilado. Con el momento en que se planteó la solicitud, un umbral acordado y una alarma cuando se supera. La alarma va a un destinatario nombrado con suplente, no a un buzón que nadie lee. Como un proceso que espera de forma bloqueante, por regla general, no da señales por sí mismo, otro tiene que consultar el estado: la vigilancia viene de fuera. El umbral depende de lo que espera detrás del paso: una tarea rutinaria nocturna tolera horas; un cambio que un equipo está esperando, no.

Los pasos sujetos a autorización se anuncian antes de activarse. Quien sabe que en pocos minutos se necesitará su aprobación, mira. Un mensaje breve a la persona que autoriza no cuesta nada, y es el último aviso que el proceso todavía puede enviar por sí mismo antes de bloquearse.

El paso sujeto a autorización va al final. Si está en mitad del proceso, todo lo que viene después espera con él, también trabajo que no necesita ninguna autorización. Al final solo se bloquea a sí mismo. Donde eso no sea posible, los pasos independientes deberían completarse antes o continuar en paralelo.

Los tiempos de espera se miden, no se estiman. El inicio de la solicitud y el momento de la decisión figuran en los registros; la diferencia es un indicador que puede analizarse. Esto coincide con la indicación del framework del NIST de recopilar datos sobre las intervenciones humanas: quien no mide cómo tiene lugar realmente la supervisión no sabe si tiene lugar.

Demasiadas autorizaciones tampoco son supervisión

La reacción obvia ante una autorización pasada por alto sería incorporar más control. Eso solo desplaza el problema. Quien tiene que confirmar diez veces al día acaba confirmando sin mirar. La autorización se convierte en un mero trámite y la supervisión solo existe ya sobre el papel: esa es la forma de sesgo de automatización que describe el artículo 14, solo que un nivel más arriba.

El patrón es conocido en el ámbito de las alarmas. El BSI describe en el módulo DER.1 del IT-Grundschutz como amenaza que, con una configuración de alarmas incorrecta, pueden producirse más falsas alarmas; los responsables pueden entonces «quizá ya no distinguir entre una falsa alarma y un evento relevante para la seguridad» y posiblemente no perciban los avisos con suficiente rapidez. Para las autorizaciones vale lo mismo. El libro de SRE de Google formula para las alarmas un principio que puede trasladarse: «Every page should be actionable» (cada aviso debe permitir actuar). Una autorización en la que la persona que autoriza no tiene nada que decidir no es una autorización.

El otro extremo –ninguna autorización– tampoco es una solución. El objetivo son pocas autorizaciones, pero significativas. Candidatos para ello son los pasos que no pueden deshacerse de forma fiable, cuyo efecto va más allá del propio ámbito de responsabilidad, en los que los datos salen de la empresa o en los que se conceden permisos. Lo que puede revertirse limpiamente y cuyo resultado se comprueba automáticamente no suele necesitar a una persona delante, sino un control después.

Lista de comprobación para autorizaciones en automatizaciones

  • Cada autorización tiene una persona responsable nombrada, con suplente.
  • El estado «en espera de autorización» es visible, tiene un umbral y dispara una alarma.
  • La autorización se anuncia antes de que el proceso se bloquee.
  • El paso sujeto a autorización está lo más tarde posible en el proceso.
  • Los tiempos de espera y las decisiones se registran y se analizan periódicamente.
  • La alarma de autorizaciones pendientes se ha disparado al menos una vez a modo de prueba y ha llegado realmente.
  • La lista de autorizaciones se revisa periódicamente para comprobar si cada una sigue cumpliendo su finalidad.

Cómo apoya sector7

Analizamos con usted lo que su uso de la IA implica según el EU AI Act y establecemos la clasificación de riesgos, las obligaciones de documentación y responsabilidades claras; más información en IA soberana. Nuestro NOC supervisa de forma automatizada, las 24 horas, los entornos que atendemos; las anomalías detectadas se tratan según los procesos acordados contractualmente, tal como se describe en Servicios gestionados y soporte.

Fuentes

Hablemos de su situación.

Concertar una conversación+49 212 240915 0