Artículo 14 de la Ley de IA de la UE: Supervisión humana de los agentes de IA

Artículo 14 en una página¶

El artículo 14 figura en el capítulo III, sección 2 del Reglamento (UE) 2024/1689. Su alcance son los sistemas de IA de alto riesgo. El sistema debe diseñarse y desarrollarse con herramientas de interfaz hombre-máquina adecuadas para que personas físicas puedan supervisarlo eficazmente durante su uso.

El objetivo es prevenir o minimizar riesgos residuales para la salud, la seguridad o los derechos fundamentales cuando el sistema funciona según lo previsto o bajo un mal uso razonablemente previsible. Las medidas deben coincidir con los riesgos, la autonomía y el contexto del sistema. El proveedor puede incorporar medidas en el sistema, identificar medidas para que las implemente el implementador o utilizar ambas rutas.

El apartado 4 define la prueba de capacidad práctica. La persona asignada necesita suficiente visibilidad y autoridad para comprender, monitorear, interpretar, ignorar, anular, revertir, intervenir e interrumpir. Un propietario designado y un documento de política respaldan la gobernanza. Los controles desplegados todavía tienen que hacer posibles esas acciones.

El diseño del proveedor y la operación del implementador forman un solo control¶

El artículo 14 divide la implementación entre el proveedor y el implementador. El proveedor identifica las medidas, incorpora controles técnicamente viables y los describe en las instrucciones de uso. El artículo 13(3)(d) requiere que esas instrucciones cubran las medidas de supervisión humana y las medidas técnicas que ayudan a los implementadores a interpretar los resultados.

El artículo 26(2) responsabiliza al implementador de asignar la supervisión a personas físicas con la competencia, la capacitación, la autoridad y el apoyo necesarios. El implementador también configura los controles para su propia gente, datos, políticas, flujo de trabajo y entorno operativo.

Elija la intensidad de la supervisión por riesgo de acción¶

El artículo 14 nombra tres variables de proporcionalidad: riesgo, autonomía y contexto de uso. Deja que las organizaciones los conviertan en umbrales de control. Humano en el circuito, humano en el circuito y humano al mando son etiquetas operativas útiles para ese diseño. No son términos definidos en el artículo 14.

Clasifique la acción individual así como el sistema de IA general. Un agente puede redactar un resumen, consultar un registro, actualizar un estado y liberar un pago en la misma ejecución. Cada acción tiene un perfil de consecuencias y reversibilidad diferente.

Construya puertas de aprobación alrededor del efecto secundario¶

El artículo 14(4)(d) otorga al supervisor autoridad en una situación particular para rechazar el uso, ignorar un resultado o anularlo o revertirlo. Para una acción de herramienta irreversible, una puerta de ejecución previa suele ser la implementación más sólida. El sistema construye la acción propuesta, evalúa las reglas aplicables y mantiene el efecto secundario hasta que la persona autorizada decida.

El revisor necesita el contexto de decisión en un solo lugar. Muestre la acción, el objetivo, los parámetros materiales, el agente y el principal solicitante, la regla y el motivo aplicables, la fuente de evidencia, la incertidumbre y las limitaciones conocidas, las consecuencias, el camino de reversión y la fecha límite para la decisión. Un simple botón de aprobación al lado de una oración generada le brinda al revisor muy poca información para ejercer una supervisión significativa.

Trate el tiempo de espera, la indisponibilidad del revisor, la evidencia obsoleta y la evaluación fallida de políticas como estados explícitos. Cada estado necesita un resultado seguro definido. Una solicitud pendiente nunca debe convertirse en una aprobación implícita porque una cola, un webhook o un revisor no están disponibles.

• Antes de la puerta: vincule un identificador de solicitud estable a la acción propuesta exacta y al conjunto de parámetros.
• En la puerta: verificar la elegibilidad del revisor y las reglas de separación de funciones al momento de tomar la decisión.
• Durante la revisión: evidencia actual, limitaciones, motivo de la política, consecuencias y alternativas disponibles.
• En la decisión: registrar aprobar, rechazar, solicitar cambios o escalar con identidad, autoridad, justificación y marca de tiempo.
• Antes de que se reanude la ejecución: confirme que la instantánea de acción, política, evidencia y autoridad permanezca actualizada.
• Después de la ejecución: adjunte el resultado real posterior o el error al mismo registro.

Diseñe la anulación, la inversión y la parada segura como controles separados¶

Los artículos 14(4)(d) y 14(4)(e) describen capacidades relacionadas con diferentes efectos. Una anulación cambia cómo se utiliza una salida. Una reversión restaura o compensa una acción que ya ocurrió. Una intervención cambia una operación en ejecución. Una interrupción detiene el sistema mediante un botón de parada o procedimiento similar y lo lleva a un estado seguro.

Un control de detención obtiene esa etiqueta cuando la solicitud llega a cada trabajador, llamada de herramienta, agente delegado, trabajo en cola y ruta de reintento relevantes. El sistema debe definir qué operaciones en vuelo pueden finalizar, cuáles se cancelan, qué credenciales o arrendamientos se revocan y qué datos siguen siendo confiables. También necesita un camino de recuperación controlado.

Pruebe la propagación y el estado final en condiciones de falla realistas. Incluya una API externa lenta, un latido del trabajador perdido, un reintento en cola, una acción de varios pasos parcialmente completada y un servicio de evidencia no disponible. Registre el tiempo desde la acción del operador hasta la contención y cada operación que permaneció en vuelo.

Brindar a los supervisores competencia, capacitación, autoridad y apoyo.¶

El artículo 26(2) proporciona el estándar de personal del lado del implementador. Las personas físicas asignadas necesitan la competencia, capacitación, autoridad y apoyo necesarios para llevar a cabo la supervisión. El considerando 73 también vincula la supervisión eficaz con la competencia, la formación y la autoridad.

La competencia cubre la decisión de dominio y el sistema de IA. Un revisor de crédito puede comprender la política crediticia pero carecer del conocimiento del sistema necesario para reconocer un cambio de distribución, datos fuente faltantes o una solicitud fuera de alcance. Un operador de plataforma puede comprender el sistema pero carecer de autoridad para decidir el resultado del cliente. El diseño de roles debe cerrar ambas brechas.

El artículo 26(2) establece un estándar basado en resultados y no establece un intervalo de entrenamiento fijo. Establezca una cadencia a partir del riesgo de acción, la tasa de cambio del sistema, el volumen operativo, el historial de incidentes y el desempeño del revisor. Activar una capacitación renovada después de cambios en el modelo de material, la política, los datos, la interfaz o el propósito previsto.

• Competencia: reglas de dominio, derechos afectados, capacidades y limitaciones del sistema, calidad de entrada y modos de falla conocidos.
• Capacitación: sesgo de automatización, herramientas de interpretación, criterios de escalamiento, simulacros de parada y recuperación, y manejo de evidencia.
• Autoridad: acceso para rechazar, anular, revertir, interrumpir, escalar y retrasar una acción sin presión operativa para aprobar.
• Soporte: tiempo suficiente, dotación de personal, derivación de especialistas, interfaces utilizables, instrucciones actualizadas y asistencia en caso de incidentes.
• Garantía continua: carga de cola, calidad de las decisiones, tasa de anulación, desacuerdos, solicitudes obsoletas, rendimiento de los ejercicios y renovación de la capacitación.

Diseño contra el sesgo de automatización¶

El artículo 14(4)(b) señala expresamente la tendencia a confiar o confiar excesivamente en los resultados de la IA, especialmente cuando el sistema proporciona información o recomendaciones para una decisión humana. Un revisor que aprueba cada recomendación añade latencia y una apariencia engañosa de control.

La interfaz y el procedimiento operativo deberían permitir un juicio independiente. Presentar fuentes de evidencia y limitaciones materiales antes de fundamentar la recomendación. Distinguir los hechos observados de la inferencia del modelo. Evite valores predeterminados que preseleccionen la aprobación. Rote o muestree casos que expongan a los revisores a errores. Mida el acuerdo y las anulaciones por tipo de acción, revisor, política y versión del sistema, luego investigue tanto la conformidad inusual como el desacuerdo inusual.

• Exigir un motivo vinculado a la evidencia para aprobaciones y anulaciones consiguientes.
• Enmascare la recomendación del modelo durante una revisión independiente de primer paso cuando el riesgo lo justifique.
• Insertar casos de prueba conocidos y contrafactuales controlados en los ejercicios de aseguramiento de los revisores.
• Alerta sobre decisiones rápidas, razonamientos idénticos repetidos, alta carga de revisores y acuerdo casi perfecto sostenido.
• Ofrezca a los revisores una ruta clara para cuestionar los datos de origen, solicitar información de especialistas o suspender el flujo de trabajo.

Reunir evidencia que demuestre el control operado.¶

El Anexo IV incluye medidas de supervisión humana, incluidas medidas de interpretación técnica, en la documentación técnica del proveedor. El artículo 13 incluye las medidas en las instrucciones de uso. El Artículo 12 requiere que los sistemas de alto riesgo admitan el registro automático de eventos durante su vida útil, mientras que el Artículo 19 y el Artículo 26 asignan tareas de retención para los registros bajo el control del proveedor y del implementador.

Por lo tanto, un paquete práctico de evidencia del Artículo 14 se basa en varias tareas relacionadas. Debe mostrar el diseño, las personas asignadas, las decisiones e intervenciones en vivo, el estado resultante y las pruebas de control. La integridad criptográfica puede mostrar si un registro exportado cambió. No puede establecer que se capturaron todos los eventos relevantes o que el control elegido fue legalmente suficiente.

Cómo implementa KLA la ruta de control gobernado¶

El Plano de control KLA gobierna las acciones de los agentes instrumentados en los puntos de decisión. El motor de políticas KLA evalúa una llamada de herramienta propuesta según las reglas publicadas y devuelve permitir, advertir, require_approval o bloquear. Un resultado require_approval retiene la llamada propuesta y crea una Solicitud de decisión para Decision Desk. Un bloque impide que la llamada gobernada llegue a la herramienta.

Para las Solicitudes de decisión del plano de control, Decision Desk verifica el permiso de decisión, el rol de revisor requerido, el estado pendiente, la identidad del solicitante y del creador, y el tiempo de vencimiento. Impide que los solicitantes y creadores registrados decidan su propia solicitud y rechaza aprobar o rechazar acciones después del plazo establecido. Un verificador elegible puede escalar una solicitud vencida. Registra el actor de la decisión, la instantánea del rol, la decisión, el motivo y el tiempo. Estos controles de separación y vencimiento se basan en que la solicitud incluya las identidades actuales del fabricante y una fecha de vencimiento. Asegúrese de que cada ruta de producción los suministre y pruebe la ruta de control total. Lineage Explorer y Audit Trail muestran los registros de políticas y decisiones humanas adjuntos a la ejecución gobernada. Evidence Room puede empaquetar registros seleccionados en un Sealed Evidence Bundle cuyas firmas de servicios y inquilinos, hashes de artefactos y raíz de Merkle del paquete se pueden verificar sin conexión.

Estas capacidades implementan partes de un modelo operativo del Artículo 14. La organización todavía posee la clasificación legal, la proporcionalidad, la asignación de proveedor-implementador, la competencia de los revisores, la dotación de personal, los procedimientos operativos y la ingeniería de estado seguro específica del sistema. Un bloqueo de acción previa en un puesto de control no detiene a todos los trabajadores ni revierte todos los efectos secundarios externos. Instrumente cada ruta consiguiente y pruebe la interrupción en todo el sistema implementado.

Una secuencia de implementación de 14 del artículo de pasos 10¶

Comience con una acción importante del agente y pruebe el camino completo. Ampliar después de que el control funcione en condiciones nominales, de falla y de recuperación.

• 1. Confirme el alcance. Registre la clasificación del sistema, su rol de proveedor o implementador, el propósito previsto, el contexto y la fecha aplicable.
• 2. Acciones de inventario. Enumere cada lectura, recomendación, escritura, comunicación externa, acción financiera, cambio de permiso, delegación y acción de recuperación.
• 3. Riesgo de acción de puntuación. Consecuencia de uso, reversibilidad, derechos afectados, volumen, detectabilidad, autonomía y mal uso previsible.
• 4. Asigne supervisión. Elija revisión previa a la ejecución, monitoreo activo con intervención u operación limitada con muestreo y escalamiento.
• 5. Diseñar la vista del revisor. Presentar la acción propuesta, evidencia, política, incertidumbre, limitaciones, consecuencias, alternativas y fecha límite.
• 6. Implementar autoridad. Hacer cumplir la elegibilidad de los revisores, la separación de funciones, el escalamiento, el comportamiento de tiempo de espera y la invalidación de solicitudes obsoletas.
• 7. Intervención del ingeniero. Cree rutas de desestimación, anulación, reversión, interrupción, estado seguro y reinicio controlado.
• 8. Prepare a las personas. Evaluar la competencia, capacitar sobre el sistema y el sesgo de automatización, otorgar autoridad y brindar soporte operativo.
• 9. Capture el registro. Correlacione la solicitud, el resultado del control, la acción humana, el resultado posterior y la evidencia de integridad.
• 10. Eficacia de la prueba. Ejecutar ejercicios de derivación, interrupción, sobrecarga, acción parcial, pérdida de trabajadores, evidencia obsoleta, detención de propagación y recuperación; remediación de pistas.