Marcos normativos de cumplimiento / Artículo 14 del Reglamento de Inteligencia Artificial de la UE
Artículo 14 del Reglamento de Inteligencia Artificial de la UE — supervisión humana de los sistemas de IA de alto riesgo
Esta página se genera a partir de la tabla de requisitos que el motor de AiSSAY incluye para este marco. Cuando el motor produce un paquete de evidencias, cada fila de abajo recibe un estado calculado a partir de los propios registros del operador en ese momento. Esta página muestra la tabla, no los resultados de nadie.
Lea esto primero
Correspondencia informativa preparada con las propias herramientas del operador. No es un dictamen jurídico, ni una certificación, ni sustituye el asesoramiento de un abogado. Organiza los registros del operador en relación con los requisitos citados; determinar si esos registros cumplen los requisitos corresponde al operador, a su asesor jurídico y al examinador.
La tabla de requisitos
9 filas: 9 de mecanismo
| Requisito | Mecanismo, obligación o carencia | Tipo |
|---|---|---|
| Medidas de supervisión integradas en el sistema, que permitan a una persona física supervisar su funcionamiento | las llamadas irreversibles se retienen a mitad de la ejecución, se clasifican por patrones y se analizan en busca de instrucciones inyectadas, y quedan en espera hasta que llega la respuesta de una política; la retención queda registrada en la traza como un paso de decisión | mecanismo |
| La persona puede decidir no utilizar los resultados, o descartarlos, invalidarlos o revertirlos | una llamada retenida solo se libera mediante un token explícito, y tanto la retención como la liberación son registros separados; una llamada liberada y una invalidada constan ambas en la cadena | mecanismo |
| La persona puede intervenir o interrumpir el sistema | el agente pide permiso al broker en lugar de informar después, así que una solicitud sin respuesta detiene la ejecución en lugar de completarla | mecanismo |
| Se permite a la persona ser consciente del sesgo de automatización | el registro indica lo que el agente no pudo verificar, lo que supuso y dónde siguió adelante pese a una ambigüedad, y marca las ejecuciones que necesitan revisión; se publica evidencia medida de que un modelo que revisa un trabajo presentado como propio pasa por alto las alteraciones | mecanismo |
| La persona puede interpretar correctamente los resultados del sistema | el relato se coteja con la traza y las discrepancias se exponen en lugar de resolverse; el registro declara qué límites estaban instrumentados, para que el lector sepa lo que no cubre | mecanismo |
| La supervisión la ejerce una persona física, no otro sistema automatizado | los refrendos humanos se cuentan siempre por separado de las ejecuciones de agentes, y la atribución de lecturas distingue una identidad firmada de un nombre que alguien escribió | mecanismo |
| Artículo 14, apartado 1 — medidas de supervisión proporcionales a los riesgos del sistema | cada ejecución se sella con la configuración de supervisión con la que se ejecutó: el modo de cumplimiento, lo que ocurre cuando el mecanismo de enclavamiento no puede evaluar una llamada y si se cargaron los patrones de acciones irreversibles. Si esas medidas son proporcionales para un despliegue concreto es una evaluación que corresponde al responsable del despliegue, y que ningún software aporta. | mecanismo |
| Artículo 14, apartado 4 — la persona que supervisa tiene la competencia, la formación y la autoridad necesarias | el operador da de alta a cada persona supervisora: nombre, rol, la autoridad que tiene, la formación que se le atribuye, la clave con la que firma y el nombre de quien lo certificó; todo ello sellado en la cadena, revocable y nunca autocertificado. Después, el paquete indica si las claves que firmaron las lecturas pertenecen a esa lista. La competencia en sí sigue siendo una afirmación del operador. | mecanismo |
| Recuentos de retenciones y de invalidaciones por ejecución | se cuentan cuando se sella cada ejecución y se guardan junto a ella solo como números enteros: las retenciones, las invalidaciones y los pases de los pasos de decisión de la barrera dentro del proceso, y las retenciones realizadas por el proxy de grabación. Los motivos, las personas y las horas siguen sellados en el registro. Una ejecución sellada antes de que existiera el recuento figura como "no contado", nunca como cero; el proxy no registra las llamadas que deja pasar, así que sus pases figuran como "no registrado". | mecanismo |
Cómo se obtiene un estado
- Acreditado
- se ejecutó una comprobación determinista sobre sus registros y los recuentos respaldan la fila. Un almacén que no contiene registros pertinentes figura como no acreditado: una afirmación verdadera, no un aprobado. Vacío nunca cuenta como limpio.
- Delegado
- el mecanismo lo hace cumplir un sistema en el que usted ya confía: un almacén sellado por su propio gestor de claves le delega a este el control de acceso, y el paquete indica que el registro que lo hace cumplir es el de su gestor de claves, no el nuestro. El paquete nombra el endpoint en el que se contactó con el gestor de claves. Un endpoint de AWS distinto del predeterminado de AWS para la región figura como delegado a ese endpoint, con una solicitud para que usted confirme que es su servicio de gestión de claves. Un backend —AWS KMS— se ha ejecutado contra el servicio real de AWS KMS; ningún otro backend lo ha hecho.
- Punto de integración de prueba
- sellado por un backend de prueba dentro del proceso —un stub, o un sustituto del cliente de AWS— y el estado indica cuál. Ningún gestor de claves controla el acceso. El punto de integración está construido y probado, y el paquete se niega a llamar a eso delegación.
- Parcialmente acreditado
- el mecanismo está construido y algunas de sus ejecuciones llevan su evidencia, pero no todas, normalmente porque se sellaron antes de que existiera el mecanismo. El paquete indica cuántas ejecuciones hay en cada grupo y nunca cuenta como aprobadas las que faltan.
- Organizativo
- el requisito es un procedimiento que solo pueden llevar a cabo personas. El paquete lo señala como responsabilidad suya en lugar de disfrazar una política de mecanismo.
- Carencia señalada
- el paquete no puede acreditarlo —o bien el mecanismo no está construido, o bien ningún software puede aportarlo— y dice cuál de los dos casos es. La carencia se imprime, porque un revisor debería leerla aquí y no descubrirla después.
Ningún estado se introduce a mano: cada estado se recalcula a partir del almacén cada vez que se produce un paquete, el texto de los requisitos y de los mecanismos se redacta y revisa como parte del motor, y la evidencia sobre dependencias procede de nuestro análisis de cada versión. Un mecanismo que falla nunca puede interpretarse como evidencia de que el control funciona.