Cuándo se aplica la supervisión humana y qué hacer a continuación

La supervisión humana en virtud de la Ley de IA de la UE se aplica como requisito legal específico a los sistemas de IA de alto riesgo. No se satisface simplemente porque un empleado puede ver un resultado o porque una política dice que una persona sigue siendo responsable. Los proveedores deben diseñar sistemas de alto riesgo para que personas físicas puedan supervisarlos de manera efectiva, mientras que los implementadores deben asignar la supervisión a personas con la competencia, la capacitación, la autoridad y el apoyo necesarios.

Para un equipo SaaS, la secuencia práctica es: clasificar el sistema, identificar si la empresa actúa como proveedor o implementador, definir lo que el ser humano realmente puede entender y cambiar, probar el camino de intervención y retener evidencia. Si el sistema no es de alto riesgo, la revisión humana aún puede ser un producto apropiado, seguridad, privacidad o control contractual, pero eso es diferente a afirmar que se aplica el Artículo 14.

Por qué la supervisión humana es importante en la práctica

La Ley de IA trata la supervisión como una forma de prevenir o minimizar los riesgos para la salud, la seguridad y los derechos fundamentales que persisten incluso después de que se hayan aplicado otros controles. El artículo 14 dice que las medidas deben ser proporcionadas a los riesgos, la autonomía y el contexto de uso del sistema. También espera que la persona asignada sea capaz, cuando corresponda, de comprender las limitaciones, monitorear el funcionamiento, reconocer el sesgo de automatización, interpretar las salidas, ignorar o revertir una salida y detener el sistema de manera segura.

Eso hace que la supervisión sea una capacidad operativa, no una aprobación ceremonial. Un revisor que carece de tiempo, información del sistema, acceso o autoridad no puede proporcionar una supervisión significativa. Una persona tampoco puede intervenir eficazmente si el producto presenta una recomendación como definitiva, oculta incertidumbre o no ofrece ninguna anulación utilizable.

Esto está estrechamente relacionado con las expectativas de gobernanza de la IA para los proveedores de SaaS. Los compradores preguntan cada vez más no sólo si un ser humano está “al tanto”, sino también dónde se produce la intervención y qué evidencia demuestra que funciona.

Cuándo se aplica el requisito de la Ley de IA

Comience con la clasificación, no con una lista de verificación de supervisión. Según el artículo 6, un sistema puede ser de alto riesgo a través de dos vías principales:

1. Es un producto, o un componente de seguridad de un producto, cubierto por la legislación específica de seguridad de productos de la UE y sujeto a una evaluación de conformidad de terceros.
2. Su finalidad prevista entra dentro de un caso de uso de alto riesgo del anexo III, sujeto al filtro del artículo 6, apartado 3, y sus excepciones.

El Anexo III cubre usos definidos en áreas como biometría, infraestructura crítica, educación, empleo, acceso a servicios esenciales, aplicación de la ley, migración y administración de justicia. Estar “impulsado por IA”, procesar datos personales o influir en un flujo de trabajo comercial ordinario no hace que un sistema sea automáticamente de alto riesgo según el Artículo 6.

Para algunos sistemas del Anexo III, el Artículo 6(3) proporciona una posible ruta para salir de la clasificación de alto riesgo cuando el sistema no plantea un riesgo significativo de daño y cumple con las condiciones enumeradas (por ejemplo, cuando realiza una tarea procesal o preparatoria limitada). La elaboración de perfiles de personas físicas dentro de un caso de uso del Anexo III sigue siendo de alto riesgo. Un proveedor que dependa del filtro debe documentar esa evaluación.

La clasificación depende en gran medida del propósito previsto y de la función real. Una empresa SaaS puede ser el proveedor cuando desarrolla o hace desarrollar un sistema y lo comercializa o pone en servicio bajo su propio nombre. Puede ser un implementador cuando utiliza el sistema de inteligencia artificial de otro proveedor bajo su autoridad. Una empresa también puede crear obligaciones con los proveedores modificando sustancialmente un sistema de alto riesgo o cambiando su propósito previsto de una manera que lo convierta en de alto riesgo. Los equipos deben confirmar las reglas transitorias actuales antes de tratar una obligación futura como ya aplicable.

Lea la descripción práctica de la Ley de IA de la UE para proveedores de SaaS junto con la evaluación de clasificación.

Cuando no se aplica el artículo 14

El artículo 14 no es una regla universal para todos los chatbots, resumidores, funciones de recomendación, señales de fraude o copilotos internos. Si un sistema está fuera del alcance de la Ley de IA, no es un sistema de IA según la Ley o no está clasificado como de alto riesgo, el requisito de sistema de alto riesgo del Artículo 14 no se le aplica.

Eso no significa que "no se necesita revisión humana". Otras obligaciones pueden surgir en virtud de normas de protección de datos, de consumo, laborales, sectoriales, de seguridad o contractuales. Una evaluación de riesgos también puede mostrar que la aprobación humana es el control más proporcionado incluso sin un mandato legal específico.

Utilice un lenguaje preciso en los registros y respuestas de los clientes:

• Requisito legal: “El sistema es de alto riesgo y estas medidas implementan los artículos 14 y 26”.
• Control de riesgos: “El sistema no está actualmente clasificado como de alto riesgo, pero nuestra política interna de riesgos exige una revisión humana”.
• Pregunta abierta: "La clasificación depende del propósito final previsto y del contexto de implementación; el lanzamiento está bloqueado hasta que se apruebe esa evaluación".

Esta distinción evita que los equipos exageren el cumplimiento y facilita la gestión de los cambios posteriores.

Responsabilidades del proveedor y del implementador

Los proveedores y los implementadores tienen trabajos conectados pero diferentes.

Proveedores: supervisión del diseño del sistema

Un proveedor debe traducir la evaluación de riesgos en medidas técnicas y procesales utilizables. Dependiendo del caso de uso, eso puede incluir:

• mostrar confianza, limitaciones y contexto de entrada relevantes;
• hacer visibles las anomalías y el rendimiento inesperado;
• impedir que la interfaz fomente la aceptación ciega;
• permitir que personas autorizadas ignoren, anulen, inviertan o interrumpan salidas;
• definir qué medidas de supervisión debe implementar el implementador; y
• explicar claramente dichas medidas en las instrucciones de uso.

El diseño debe corresponder a las condiciones de trabajo previsibles. Una anulación oculta detrás del flujo de trabajo de un administrador puede resultar inútil cuando un revisor de primera línea debe actuar de inmediato.

Implementadores: hacer operativa la supervisión

El artículo 26 exige que quienes implementen sistemas de alto riesgo asignen la supervisión a personas físicas con la competencia, la capacitación, la autoridad y el apoyo necesarios. Los implementadores deben utilizar el sistema de acuerdo con sus instrucciones, monitorear su funcionamiento, actuar ante riesgos identificados o incidentes graves y mantener los registros generados automáticamente bajo su control durante un período apropiado de al menos seis meses, a menos que otra ley aplicable disponga lo contrario.

Operacionalmente, eso significa elegir roles con nombre, proteger el tiempo de revisión, controlar el acceso, definir la escalada y verificar si las instrucciones del proveedor se ajustan a la implementación real. Un empleado no puede ser responsable de una anulación que no está autorizado a realizar.

Un flujo de trabajo práctico de supervisión humana

1. Escriba un registro de clasificación con alcance

Registre el sistema, el propósito previsto, los usuarios, las personas afectadas, los insumos, los resultados, el impacto de las decisiones, las funciones del proveedor/implementador y la ruta del Artículo 6 considerada. Vincule la conclusión con la versión del producto y el contexto de implementación. Vuelva a evaluarlo cuando cualquiera de los dos cambie.

2. Decisiones de mapas y modos de falla

Identifique dónde la salida de la IA puede afectar a una persona, la seguridad, el acceso, la priorización o un proceso regulado. Para cada punto, describa errores realistas: una coincidencia falsa, una excepción omitida, una clasificación sesgada, un resumen engañoso, una recomendación insegura o una desviación del rendimiento.

3. Definir la acción del ser humano, no solo su presencia

Para cada decisión importante, especifique:

• qué información ve el revisor;
• lo que deben verificar de forma independiente;
• cuándo deben rechazar o intensificar;
• si pueden pausar, anular o revertir el resultado;
• la rapidez con la que deben actuar; y
• quién tiene la autoridad final.

Evite controles vagos como “un gerente revisa cuando es necesario”. Un desencadenante y una regla de decisión hacen que el control sea comprobable.

4. Capacítese para la tarea real

La capacitación debe cubrir el propósito previsto del sistema, las limitaciones conocidas, las señales relevantes, el sesgo de automatización, los usos prohibidos, las herramientas de intervención, el mantenimiento de registros y la escalada. Confirme la competencia a través de escenarios, no solo la asistencia. Esto complementa las preguntas más amplias que los equipos deberían plantearse antes de adoptar nuevas herramientas de IA internamente.

5. Pruebe la ruta completa

Realiza ejercicios realistas. ¿Puede el revisor detectar un mal resultado? ¿Tienen suficiente contexto? ¿Funciona la anulación? ¿Detener el sistema lo deja en un estado seguro? ¿Se registra el evento? ¿La escalada llega a alguien que pueda actuar?

Registre los defectos y vuelva a realizar pruebas después de corregirlos. Una captura de pantalla de una pantalla de aprobación demuestra mucho menos que un escenario completo con los resultados esperados y observados.

6. Monitorear y mejorar

Realice un seguimiento de anulaciones, reversiones, escalaciones, quejas, detecciones perdidas, desacuerdos de revisores y desempeño anormal. Las tendencias pueden revelar una capacitación deficiente, una interfaz inutilizable, entradas modificadas o un sistema que funciona fuera de su propósito aprobado. Definir umbrales que desencadenan la investigación, suspensión o reevaluación.

Errores comunes

• Clasificación por etiqueta del producto. El nombre de una característica no determina si el uso previsto es de alto riesgo.
• Usar “humano en el circuito” como control total. La presencia sin información, tiempo o autoridad no es una supervisión efectiva.
• Revisar después de que la consecuencia es irreversible. El punto de intervención debe ocurrir mientras la persona aún puede cambiar el resultado.
• Dejar que el mismo resultado se valide a sí mismo. La verificación independiente requiere evidencia adicional, no una segunda lectura de la explicación de la IA.
• Ignorar el sesgo de automatización. Los resultados repetidamente precisos pueden hacer que sea menos probable que los revisores cuestionen el error excepcional.
• Dejar la propiedad en manos de “la empresa”. Nombra una función responsable y un respaldo operativo.
• Sin guardar evidencia. Las políticas por sí solas no muestran que los revisores hayan sido capacitados, que las anulaciones hayan funcionado o que los problemas hayan escalado.

Ejemplo: selección de candidatos asistida por IA

Supongamos que un proveedor de SaaS ofrece software que clasifica a los candidatos para un puesto de trabajo para un empleador. Los usos de la IA relacionados con el empleo enumerados en el Anexo III pueden ser de alto riesgo, por lo que el proveedor debe completar y documentar la evaluación del Artículo 6 en lugar de asumir que un reclutador que haga clic en “aprobar” resuelve el problema.

Una supervisión significativa podría requerir que el reclutador vea los factores relevantes para la recomendación, verifique la fuente de información, identifique datos faltantes o engañosos, ignore la clasificación, restaure a un candidato y aumente la sospecha de sesgo sistemático. El empleador, como implementador, asignaría personas capacitadas con autoridad y controlaría el sistema de acuerdo con las instrucciones.

Por el contrario, una herramienta interna que reformatea un correo electrónico escrito por un reclutador sin clasificar a los candidatos ni influir en una decisión laboral puede no entrar en ese caso de uso de alto riesgo. El equipo aún puede prohibir entradas sensibles y requerir la aprobación humana antes de enviarlas, pero debe documentarlo como un control interno en lugar de describirlo automáticamente como cumplimiento del Artículo 14.

Preguntas frecuentes

¿Cuál es el propósito práctico de la supervisión humana?

Su objetivo es permitir que personas competentes comprendan, supervisen e intervengan para prevenir o reducir los riesgos residuales para la salud, la seguridad o los derechos fundamentales. El flujo de trabajo debe brindarles información, tiempo, herramientas y autoridad reales.

¿Cuándo se aplica la supervisión humana a los equipos SaaS?

Los deberes específicos de la Ley de IA se aplican cuando el equipo proporciona o implementa un sistema de IA de alto riesgo. Es posible que otros sistemas de IA aún necesiten revisión humana debido a otra ley, contrato, evaluación de riesgos o política interna.

¿Es suficiente una aprobación humana final?

No automáticamente. La aprobación es significativa sólo si el revisor puede comprender las limitaciones relevantes, detectar problemas, cuestionar el resultado y cambiar o detener el resultado antes de que ocurra daño.

¿Qué deberían documentar primero los equipos?

Comience con el registro de clasificación y el propósito previsto. Luego documente a las personas responsables, revise los desencadenantes, la información mostrada, las intervenciones permitidas, la ruta de escalada, la capacitación, los resultados de las pruebas y la evidencia operativa.

¿Todas las decisiones de la IA deben ser verificadas por dos personas?

No. El artículo 14 incluye una regla específica de verificación por dos personas para ciertos sistemas de identificación biométrica remota, con excepciones definidas. No es una regla general para todos los sistemas de IA de alto riesgo.

Qué hacer ahora

Clasifique el caso de uso antes de prometer que la “supervisión humana” lo resolverá. Si el sistema es de alto riesgo, conecte las medidas técnicas del proveedor con las personas, los permisos y los procedimientos reales del implementador. Luego pruebe el camino y conserve evidencia de que un humano puede reconocer los problemas y actuar a tiempo.

Ésa es la diferencia entre una persona cercana al sistema y una supervisión humana eficaz.

Fuentes

• Reglamento (UE) 2024/1689 (Ley de Inteligencia Artificial)
• Artículo 6: Reglas de clasificación para sistemas de IA de alto riesgo
• Artículo 14: Supervisión humana
• Artículo 26: Obligaciones de los implementadores de sistemas de IA de alto riesgo