Cómo implementar la supervisión humana del artículo 14 del Reglamento de IA

Guía6 de agosto de 2026· 17 min de lectura

Manual práctico del artículo 14: patrones in-the-loop, on-the-loop e in-command, diseño de la interfaz, controles de parada y evidencias.

Una entidad de crédito compra un modelo de scoring de alto riesgo comercializado como "listo para el artículo 14", pone a un analista delante del panel y da por hecho que la casilla está marcada. No lo está. Implementar la supervisión humana es un trabajo de diseño y operación con cuatro piezas en movimiento: el patrón de supervisión, la interfaz, los controles de parada y anulación, y la competencia y autoridad de quien supervisa, más el rastro de evidencias que los une. Esta página es el manual práctico de esas cuatro piezas; la obligación completa del artículo 14 explicada cubre los cinco apartados del precepto, y qué exige la supervisión humana explica el concepto.

De la obligación al diseño: qué significa "implementar" el artículo 14

El artículo 14(1) del Reglamento (UE) 2024/1689 exige que un sistema de IA de alto riesgo se diseñe y desarrolle, también con herramientas adecuadas de interfaz persona-máquina, de modo que personas físicas puedan supervisarlo de forma efectiva "durante el período en que el sistema de IA esté en uso". Esa frase es todo el trabajo: las decisiones de diseño que vienen a continuación son la labor de cumplimiento, no una capa que se añade después.

El artículo 14(3) reparte el trabajo según la viabilidad técnica. El proveedor integra medidas en el sistema cuando es viable; el resto las implementa operativamente el responsable del despliegue. Toda implementación tiene que responder con claridad a dos preguntas: quién construye qué, y quién opera qué.

Primero, comprueba el ámbito de aplicación. El artículo 14 solo aplica a sistemas de alto riesgo conforme al artículo 6 y el anexo III, así que confirma la clasificación antes de invertir en arquitectura de supervisión. Si tu sistema no es de alto riesgo —analítica de negocio ordinaria, herramientas defensivas de ciberseguridad, un asistente interno de ITSM— nada de esto aplica. Lee antes la clasificación de IA de alto riesgo.

El resto de la página recorre las cuatro piezas en orden: elegir un patrón, diseñar la interfaz, construir los controles y hacer real a quien supervisa, y cierra con los registros que conservas para demostrar que ocurrió.

Elegir un patrón de supervisión: in-the-loop, on-the-loop, in-command

Los tres patrones son vocabulario de diseño que usan los profesionales y las guías de los reguladores. No son términos definidos en el Reglamento (UE) 2024/1689 —la norma no nombra ninguno—. El texto fija requisitos de capacidad en el artículo 14(4) que cualquier patrón debe satisfacer. Elige la arquitectura; luego demuestra que entrega las capacidades.

Persona dentro del bucle (in-the-loop)

Una persona revisa y confirma antes de que el resultado surta efecto. Encaja en decisiones de poco volumen y alta consecuencia —una denegación de crédito, una preselección de candidatos— donde retener la decisión para revisarla cuesta poco y equivocarse cuesta mucho.

Persona sobre el bucle (on-the-loop)

El sistema actúa de forma autónoma mientras una persona monitoriza y puede intervenir. Encaja en flujos de alto volumen donde revisar cada decisión es inviable. El artículo 14 no exige revisar cada resultado, así que la monitorización on-the-loop con revisión activada por anomalías y muestreo es una implementación legítima, no un atajo.

Persona al mando (in-command)

La organización conserva la autoridad para decidir si el sistema se usa y cómo, incluida la facultad de apagarlo. Es el control de máximo nivel y el que satisface la vertiente de "decidir no utilizarlo" del artículo 14(4)(e). Se sitúa por detrás de cualquier patrón que opere en el día a día.

El patrón se elige frente al riesgo para la salud, la seguridad y los derechos fundamentales conforme al artículo 14(2), no por comodidad; y un mismo despliegue puede combinar patrones según el tipo de decisión. Esta elección es el diferenciador: las páginas hermanas explican la obligación y el concepto; aquí eliges una arquitectura.

Matriz de selección de patrón

Usa la tabla como ayuda de diseño, no como atajo de cumplimiento. El patrón que elijas todavía tiene que entregar de forma demostrable las capacidades del artículo 14(4) para tu caso de uso concreto.

Patrón	Cómo funciona	Volumen para el que encaja	Momento de la intervención	Vertiente del art. 14(4) que sirve más directamente	Ejemplo del anexo III
In-the-loop	Una persona revisa y confirma antes de que el resultado surta efecto	Poco volumen, alta consecuencia	Retención previa a la acción	(e) anular / revertir antes de que surta efecto	Solvencia (anexo III, punto 5(b)); selección de personal (punto 4(a))
On-the-loop	El sistema actúa; la persona monitoriza y puede intervenir	Alto volumen	Interrupción en marcha	(b) monitorizar, detectar anomalías	Flujos de monitorización de fraude / anomalías
In-command	La organización decide si el sistema se ejecuta siquiera	Cualquiera	Nivel de gobernanza	(e) decidir no utilizarlo	Respaldo siempre presente en todos los ámbitos

Mapea los patrones a los ámbitos del anexo III: in-the-loop para la solvencia (anexo III, punto 5(b)) y la selección de personal (punto 4(a)); on-the-loop para la monitorización de fraude y anomalías; in-command como respaldo siempre presente, sea cual sea el patrón del día a día.

Hay una capa que se superpone a los tres. La identificación biométrica remota (anexo III, punto 1(a)) lleva la regla adicional del artículo 14(5): no puede adoptarse ninguna medida salvo que la identificación haya sido verificada y confirmada por separado por al menos dos personas físicas competentes, sujeto a una excepción estrecha para las fuerzas del orden. Ese requisito de doble confirmación no es en sí un "patrón": es un control obligatorio que se superpone a cualquiera que uses.

Diseñar la interfaz de supervisión

El artículo 14(4)(a) y (d) guían el diseño de la interfaz: quien supervisa debe comprender adecuadamente las capacidades y limitaciones del sistema e interpretar correctamente su resultado. Un veredicto desnudo no permite ninguna de las dos cosas, así que la interfaz tiene que mostrar algo más que una puntuación.

Información concreta que exponer:

una banda de confianza o incertidumbre, no solo una estimación puntual;
los factores principales que impulsan ese resultado concreto;
los rangos de entrada con los que se entrenó el modelo;
indicadores de datos fuera de distribución y de baja confianza;
el lugar de la decisión en el flujo de trabajo y qué pasa después.

La expresión del artículo 14(1) "herramientas adecuadas de interfaz persona-máquina" es el anclaje explícito de diseño. Los resultados interpretables y las herramientas de explicación —importancia de variables, advertencias sobre el rango de entrenamiento, indicadores en lenguaje claro— son cómo implementas esa frase, no un acabado opcional.

Mostrar registros y métricas de rendimiento casi en tiempo real es lo que permite la detección de anomalías del artículo 14(4)(b). Diseña para detectar en el momento, no solo para una auditoría retrospectiva un trimestre después.

Por último, la maquetación combate el sesgo de automatización. Registrar la valoración provisional de la propia persona antes de revelar el resultado de la IA evita que la puntuación ancle su juicio: una forma, a nivel de interfaz, de operativizar la vertiente del sesgo de automatización que se examina más abajo.

Controles de parada y anulación: construir la intervención

El artículo 14(4)(e) exige la capacidad de hacer caso omiso del resultado, anularlo o revertirlo y, cuando proceda, de intervenir en el funcionamiento del sistema o interrumpirlo mediante un botón de parada o un procedimiento similar. Implementarlo significa una capacidad técnica probada y documentada, no una frase en una política.

De ahí se siguen cuatro reglas de ingeniería:

Captura un motivo, no un clic silencioso. Una anulación debe registrar el porqué. Eso satisface a la vez la capacidad de "revertir el resultado" y genera evidencia para el rastro descrito más abajo.
Haz real el interruptor de parada. Una persona designada debe poder detener el sistema, y este debe detenerse de verdad. Prueba el mecanismo y registra la prueba: un botón de parada sin probar es una afirmación, no un control.
Mantén la autoridad ejercitable dentro de su ámbito. Un control que necesita visto bueno de varios niveles antes de que una anulación surta efecto no es supervisión "efectiva" conforme al artículo 14(1). Quien supervisa debe poder actuar dentro de su ámbito asignado sin esperar a un comité.
Ajusta el control al patrón. In-the-loop necesita retenciones previas a la acción: el resultado queda aparcado hasta que una persona lo libera. On-the-loop necesita interrupciones en marcha: la persona puede cortar un proceso en ejecución. Son piezas de ingeniería distintas; no supongas que un mecanismo cubre ambas.

Competencia y autoridad: hacer real a quien supervisa

El artículo 26(2) exige que el responsable del despliegue encomiende la supervisión a personas físicas que tengan la competencia, la formación y la autoridad necesarias, así como el apoyo necesario. Implementarlo significa una persona concreta en una fecha concreta, no un puesto en un organigrama.

La competencia es a la vez específica del sistema y específica del dominio. Quien supervisa necesita suficiente alfabetización técnica para reconocer una anomalía y el conocimiento del dominio para juzgar el resultado: para un modelo de scoring, un analista de crédito que entiende cómo varía la precisión del modelo entre segmentos de solicitantes, no un generalista que pulsa "aprobar".

La formación debe estar documentada, ser específica del sistema y actualizarse cuando el sistema sufra una modificación sustancial conforme al artículo 3(23). La formación genérica en alfabetización en IA del artículo 4 es una obligación de base, no un sustituto de la competencia específica del sistema.

La autoridad debe ser vinculante dentro de su ámbito. Una decisión de anular o detener no puede revertirse de forma rutinaria por una capa de aprobación posterior sin justificación documentada; si puede, la autoridad era nominal. Diseña la vía de escalado como parte de la autoridad: define cuándo escala quien supervisa (por ejemplo, indicadores agrupados de características protegidas) y a quién, alimentando el sistema de gestión de riesgos del artículo 9.

Medidas contra el sesgo de automatización por diseño

El artículo 14(4)(c) nombra el sesgo de automatización de forma explícita: quien supervisa debe seguir siendo consciente de la posible tendencia a confiar automática o excesivamente en el resultado del sistema. La implementación es procedimental y estructural, no una diapositiva en una sesión de acogida.

Medidas concretas:

exigir un razonamiento documentado en lugar de una aprobación pasiva;
muestrear aleatoriamente resultados de alta confianza para una revisión detallada;
auditar periódicamente las tasas de anulación e investigar la infrautilización sistemática;
inyectar casos de error sintéticos: dar a quien supervisa casos ocasionales en los que el sistema se equivoca y medir la tasa de detección, un indicador medible de si la supervisión es real.

Vincula las medidas al patrón. La monitorización on-the-loop necesita umbrales de alerta que fuercen la atención; la revisión in-the-loop necesita las contramedidas de anclaje descritas en la sección de la interfaz. Y vigila la cifra clave: una tasa de anulación cercana a cero es una señal de alarma que la implementación debe mostrar y atender, porque suele significar que quien supervisa ratifica resultados en lugar de supervisarlos.

El rastro de evidencias: demostrar que la supervisión ocurrió

La implementación tiene que producir registros defendibles. Los auditores buscan ambas cosas: quién era el responsable y qué hizo realmente.

Conserva, como mínimo: quién era la persona designada para supervisar en una fecha dada; su registro de formación específica del sistema; los procedimientos escritos; y los registros por decisión de aprobaciones, anulaciones, rechazos y escalados.

El anclaje legal de conservación de registros para los responsables del despliegue es el artículo 26(6): deben conservar los registros generados automáticamente durante un período adecuado de al menos seis meses, salvo que otra disposición del Derecho de la Unión o nacional establezca otra cosa. Trata los seis meses como un suelo, no como una meta.

Por el lado del proveedor, el diseño de la supervisión humana pertenece a la documentación técnica del anexo IV conforme al artículo 11: las interfaces, el mecanismo de parada, los requisitos de competencia y los procedimientos de anulación se ubican ahí. Y cuando se detecta un incidente grave, el artículo 26(5) exige que el responsable del despliegue informe al proveedor (y al distribuidor o a las autoridades pertinentes, según proceda); el registro de supervisión es lo que alimenta esa notificación.

La evidencia de efectividad vence al papeleo. Los auditores quieren registros que demuestren que las anulaciones ocurrieron de verdad y que se ejecutaron auditorías de sesgo de automatización, no un diseño bellamente documentado que nadie operó.

Ejemplo práctico: Meridian Kredit, una entidad de crédito de 280 empleados

Meridian Kredit es una entidad regional de préstamo al consumo con 280 empleados que opera un modelo de solvencia de alto riesgo (anexo III, punto 5(b)). Fíjate en el tamaño: con 280 empleados supera el umbral de pyme, así que el tope de multa "el menor de" del artículo 99(6) no le aplica. Conforme al artículo 99(4), el incumplimiento de las obligaciones de alto riesgo, incluido el artículo 14, conlleva multas de hasta 15 M€ o el 3 % del volumen de negocios anual mundial total, lo que sea mayor.

Elección de patrón: combinada por tipo de decisión. Las decisiones adversas funcionan in-the-loop: cada denegación se retiene a la espera de la revisión del analista antes de surtir efecto. El flujo de aprobaciones funciona on-the-loop, monitorizado con revisión activada por anomalías y muestreo, porque la revisión por decisión de las aprobaciones paralizaría la cartera. Un interruptor de parada documentado da a la dirección de riesgo de crédito la autoridad in-command para suspender el modelo por completo.

Interfaz. Cada puntuación adversa muestra los factores principales, una banda de confianza, una advertencia de segmento de entrenamiento (solicitantes con expediente escaso y autónomos, donde la precisión es menor) y un indicador de fuera de distribución. El analista que revisa registra una opinión provisional antes de que se revele la puntuación, contrarrestando el anclaje.

Competencia, autoridad, evidencia. Una Analista Sénior de Riesgo de Crédito designada cuenta con formación documentada y específica del sistema y con autoridad vinculante para revocar una denegación. Meridian ejecuta una auditoría mensual de la tasa de anulación, conserva los registros por decisión durante al menos seis meses conforme al artículo 26(6) y recoge el diseño de supervisión en su documentación del anexo IV.

La estructura se reduce para un responsable del despliegue más pequeño y se amplía para un banco sistémico con una función dedicada de riesgo de modelo. Las cuatro piezas —patrón, interfaz, controles, competencia— se mantienen constantes; solo cambia su peso.

Cómo ayuda Confir

Confir asigna cada capacidad del artículo 14(4) a un registro de supervisión estructurado: el patrón que elegiste, la evidencia de la interfaz, el procedimiento de parada y anulación, la persona designada para supervisar y su formación, y el histórico de auditorías de la tasa de anulación, todo en un mismo lugar que alimenta el paquete documental del artículo 11 / anexo IV. El motor de síntesis es determinista y basado en reglas —sin inferencia de modelo, sin alucinaciones—, de modo que la misma entrada produce el mismo hallazgo cada vez, la propiedad que le importa a un auditor cuando lee un registro de supervisión.

Preguntas frecuentes

¿Cuál es la diferencia entre in-the-loop, on-the-loop e in-command?

Describen tres arquitecturas de supervisión, no categorías jurídicas: el Reglamento (UE) 2024/1689 no nombra ninguna. In-the-loop significa que una persona revisa y confirma cada resultado antes de que surta efecto, apropiado para decisiones de poco volumen y alta consecuencia. On-the-loop significa que el sistema actúa de forma autónoma mientras una persona monitoriza y puede intervenir, apropiado para flujos de alto volumen. In-command significa que la organización conserva la autoridad sobre si el sistema se ejecuta y cómo, incluida la facultad de apagarlo. Elijas el que elijas, todavía tiene que entregar las capacidades que exige el artículo 14(4).

¿Exige el artículo 14 revisar cada resultado de la IA?

No. El artículo 14(4) exige que quienes supervisan puedan monitorizar, interpretar e intervenir, no que cada decisión reciba revisión manual. Para sistemas de alto volumen, un patrón on-the-loop con revisión activada por anomalías, muestreo basado en riesgo y auditorías periódicas es una implementación legítima. Lo que el Reglamento prohíbe es abdicar de la supervisión, no operar con eficiencia. El patrón correcto depende del riesgo para la salud, la seguridad y los derechos fundamentales conforme al artículo 14(2): las decisiones adversas y de alta consecuencia suelen justificar una revisión previa a la acción, mientras que los flujos rutinarios de alto volumen pueden supervisarse on-the-loop.

¿Qué información debe mostrar realmente la interfaz de supervisión?

La suficiente para que quien supervisa comprenda e interprete correctamente el resultado, como exigen el artículo 14(4)(a) y (d). En la práctica, eso significa más que un veredicto: una banda de confianza o incertidumbre, los factores principales que impulsan el resultado, los rangos de entrada con los que se entrenó el modelo e indicadores de casos fuera de distribución o de baja confianza. El artículo 14(1) los llama "herramientas adecuadas de interfaz persona-máquina". Un sistema que devuelve una clasificación desnuda sin explicación hace imposible la interpretación correcta y suspende la prueba de diseño, por muchos botones de aprobación que tenga encima.

¿Cómo se diseñan controles de parada y anulación efectivos?

El artículo 14(4)(e) exige la capacidad de hacer caso omiso del resultado, anularlo o revertirlo y de interrumpir el funcionamiento mediante un botón de parada o un procedimiento similar. Implementarlo significa una capacidad técnica probada y documentada: una persona designada puede detener el sistema y este se detiene. Las anulaciones deben capturar un motivo registrado en lugar de un clic silencioso, lo que a la vez satisface el requisito y construye tu rastro de evidencias. Un control que necesita visto bueno de varios niveles antes de que una anulación surta efecto no es supervisión efectiva conforme al artículo 14(1): quien supervisa debe poder actuar dentro de su ámbito asignado.

¿Cómo se implementan medidas contra el sesgo de automatización?

El artículo 14(4)(c) nombra directamente el sesgo de automatización, así que la formación de concienciación por sí sola no basta: el diseño debe contrarrestarlo. Entre las medidas efectivas figuran exigir un razonamiento documentado en lugar de una aprobación pasiva, muestrear aleatoriamente resultados de alta confianza para una revisión detallada, auditar las tasas de anulación e investigar la infrautilización sistemática, e inyectar periódicamente casos de error sintéticos para medir las tasas de detección. Las contramedidas de anclaje, como registrar la propia opinión de la persona antes de revelar el resultado de la IA, funcionan a nivel de interfaz. Una tasa de anulación cercana a cero es una señal de aviso de que quienes supervisan ratifican en lugar de supervisar.

¿Quién es responsable de implementar la supervisión: el proveedor o el responsable del despliegue?

Ambos, repartido por viabilidad técnica conforme al artículo 14(3). El proveedor integra la capacidad de supervisión en el sistema cuando es viable —resultados interpretables, herramientas de monitorización, el mecanismo de parada— y la documenta en la documentación técnica del anexo IV. El responsable del despliegue hace operativa la supervisión conforme al artículo 26(2): designa a una persona competente, formada y autorizada, redacta procedimientos y conserva registros. Ninguno puede librarse de su deber señalando al otro. Un responsable del despliegue no puede confiar en un sistema comercializado como "listo para el artículo 14"; un proveedor no puede cerrar el círculo entregando un manual.

¿Qué evidencia demuestra que la supervisión humana se implementó de verdad?

Los auditores esperan evidencia tanto de diseño como operativa. Por el lado del diseño: la arquitectura de supervisión documentada en la documentación técnica del anexo IV conforme al artículo 11, incluidas las interfaces, el mecanismo de parada y los procedimientos de anulación. Por el lado operativo: la persona designada para supervisar y su registro de formación específica del sistema, los procedimientos escritos, los registros por decisión de aprobaciones, anulaciones, rechazos y escalados, y las auditorías de sesgo de automatización que ejecutaste. Los responsables del despliegue deben conservar los registros generados automáticamente durante al menos seis meses conforme al artículo 26(6). Un diseño documentado que nadie opera de verdad no pasará.

Guías relacionadas

Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar

Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 14 días.

Empieza la prueba gratuita →