EU AI ACT · SUPERVISIÓN HUMANA

Supervisión humana: del artículo 14 al control efectivo

Autoridad, contexto y capacidad de intervención: una lectura técnica de la supervisión humana en sistemas agénticos de alto riesgo.

Edición y fuentes consultadas: · ≈ 3 min · Síntesis técnica asistida por IA

Sin revisión jurídica declarada. Las referencias describen el régimen de los sistemas de alto riesgo cuando corresponda. Las propuestas de ingeniería son interpretación técnica, no certificaciones del producto.

1. Una persona con autoridad efectiva

En sistemas de alto riesgo, la supervisión debe poder ejercerse durante el uso. El artículo 14 trata su diseño; el artículo 26 exige asignarla a personas con competencia, formación, autoridad y apoyo adecuados. Un nombre en un organigrama no demuestra que la intervención sea posible.

Como criterio de ingeniería, describe qué persona puede impedir una acción, qué información recibe y qué sucede si no responde. Separa la propuesta del modelo, la autorización y el efecto observado. Una aprobación tardía no transforma retroactivamente un efecto ya consumado en una acción supervisada.

Referencia normativa: Art. 14 ↗ Art. 26 ↗

2. La interfaz también es una frontera

El artículo 14 incluye comprender capacidades y limitaciones, advertir la dependencia excesiva de resultados automáticos e interpretar e intervenir sobre las salidas. Su proporcionalidad depende de riesgo, autonomía y contexto.

Propuesta de diseño: antes del despacho, mostrar destino, operación, alcance y reversibilidad. La persona debe poder rechazar o pedir aclaración sin que el agente interprete el silencio como consentimiento. La identidad autenticada aporta atribución; no acredita comprensión ni oportunidad real de intervenir.

Referencia normativa: Art. 14 ↗

3. Evitar la carrera entre aprobación y efecto

Si la autorización se refiere a un archivo pero el ejecutor termina actuando sobre otro, el clic deja de describir el efecto. Esa divergencia es un problema de enlace entre intención y ejecución, incluso cuando ambos eventos están firmados.

Una prueba útil cambia el recurso o los parámetros entre autorización y ejecución. El criterio observable debe ser que el efecto distinto no se produzca. Registra también permisos alternativos, descriptores abiertos y rutas fuera del broker: una denegación en el canal nominal no prueba mediación completa.

4. Parar debe tener un resultado observable

Exactitud, robustez y ciberseguridad tienen su propio alcance en el artículo 15. Un mecanismo de parada es un control relacionado; no cubre por sí solo la calidad de las salidas, el sesgo, la resiliencia ni todas las amenazas.

Propuesta de falsación: ordenar la parada durante una operación pendiente y observar por una vía independiente si el recurso cambia. Repetir ante reinicio y pérdida de conexión. Distinguir siempre la parada solicitada, la parada registrada y la ausencia comprobada de efectos posteriores.

Referencia normativa: Art. 15 ↗

5. Evidencia y límites de la integración

BABYLON documenta autorización y parada; su evidencia debe consultarse por versión y configuración en pruebas y límites. Touch ID es una opción de diseño del proyecto, no una tecnología prescrita por el AI Act.

La validación debe incluir a las personas que utilizarán la interfaz y sus condiciones de trabajo. Una firma válida no sustituye esa evaluación. Publicar contraejemplos y canales no cubiertos permite decidir dónde reforzar el sistema y dónde limitar su uso.

Fuentes oficiales y evidencia

Referencias contrastadas con el AI Act Service Desk. El calendario de la guía AI Act incorpora el artículo 113 modificado por el Reglamento (UE) 2026/1744, consultado directamente en EUR-Lex.

Continúa la lectura