Gobernanza de IA de alto riesgo bajo la EU AI Act

Si opera IA que puede afectar la seguridad de las personas, la ley trata la gobernanza como una disciplina continua del ciclo de vida, no como una casilla de cumplimiento que se marca una sola vez. En esta publicación desglosaremos lo que la Ley espera, cómo luce una "buena práctica" en la realidad, cómo encajan las auditorías y cuánto tiempo necesita conservar sus registros. Haremos referencia a artículos de la EU AI Act para que también pueda consultar el texto legal. Cuando la Ley delega detalles a futuros actos de implementación o normas armonizadas, señalaremos los puntos pendientes.

Introducción rápida: ¿qué es un sistema de IA de alto riesgo?

Los sistemas de alto riesgo se dividen en dos categorías principales:

• Productos que ya se someten a regímenes de seguridad de productos de la UE (piense en dispositivos médicos, maquinaria, juguetes con funciones de seguridad, ascensores, sistemas ferroviarios, etc.). Cuando la funcionalidad de IA es relevante para la seguridad dentro de un producto cubierto por la legislación existente de la UE con conformidad de terceros (Anexo II, Sección A), el componente de IA se convierte en alto riesgo una vez que esa ley de seguridad del producto se vincula con la Ley de IA.
• Casos de uso de IA independientes enumerados en el Anexo III (p. ej., identificación biométrica, operación de infraestructura crítica, educación/evaluación que impacta el acceso, decisiones de empleo incluyendo filtrado de CV y promoción, puntuación crediticia, análisis de aplicación de la ley, triaje de migración/asilo, etc.). La lista es actualizable por la Comisión.

Si su sistema cae en cualquiera de las dos categorías, las obligaciones de gobernanza que se describen a continuación se aplican a usted (con algunas diferencias basadas en roles para proveedores vs. implementadores).

Pilares centrales de gobernanza que debe construir

A continuación se presenta una traducción práctica del texto legal en flujos de trabajo que realmente puede ejecutar. Hemos mapeado las referencias principales de los artículos entre paréntesis.

1. Sistema de gestión de riesgos (Art. 9)

Continuo, documentado e iterativo. Cubra las fases de diseño, desarrollo, validación, despliegue y post-comercialización. Identifique riesgos conocidos y razonablemente previsibles para la salud, la seguridad y los derechos fundamentales. Califique la gravedad + probabilidad. Defina mitigaciones. Incorpore datos del mundo real y aprendizajes de incidentes. Actualice cuando el contexto, los datos o el comportamiento del modelo cambien.

Consejos prácticos

• Construya un registro de riesgos vivo indexado a escenarios de daños, derechos impactados, poblaciones afectadas, controles implementados, riesgo residual y responsable de aprobación.
• Use análisis de peligros pre-despliegue (estilo FMEA), red teaming, pruebas adversarias, pruebas de sesgo y robustez, y pruebas de estrés específicas del dominio.
• Vuelva a ejecutar el análisis de riesgos siempre que cambie materialmente los pesos del modelo, las clases de datos de entrenamiento, el entorno operativo o el propósito previsto.

2. Controles de datos y gobernanza de datos (Art. 10)

Los datos de entrenamiento, validación y prueba deben ser relevantes, representativos, libres de errores en la medida de lo posible y completos para el propósito previsto. Debe comprender la procedencia de los datos, las condiciones de recolección y los sesgos conocidos.

Consejos prácticos

• Mantenga un paquete de ficha de datos / tarjeta de modelo que registre las fuentes, condiciones de consentimiento/legalidad, alcances geográficos, brechas demográficas, pasos de preprocesamiento y métricas de calidad. Puede usar VerifyWise para este propósito.
• Rastree la trazabilidad de los datos para poder responder rápidamente a las preguntas de reguladores y clientes.

3. Documentación técnica (Art. 11)

Necesita preparar y mantener documentación suficiente para que los reguladores y organismos notificados evalúen el cumplimiento. Piense en esto como el "archivo de historial de diseño" para la IA.

Qué incluir

• Descripción del sistema, propósito previsto, grupos de usuarios y entorno operativo. De nuevo, VerifyWise es una excelente opción aquí.
• Arquitectura del modelo, enfoque de entrenamiento, historial de versiones.
• Resumen de gobernanza de datos (ver arriba).
• Métricas de rendimiento (precisión, tasas de error, métricas de sesgo, resultados de pruebas de robustez). VerifyWise tiene una función de verificación de sesgo/equidad para MLs y LLMs.
• Registros de gestión de riesgos y decisiones de mitigación.
• Diseño e instrucciones de supervisión humana.
• Plan de monitoreo post-comercialización.

Asegúrese de controlar las versiones de todo y también congele un paquete base para cada evaluación de conformidad, luego registre los deltas.

4. Mantenimiento de registros / registro automático (Art. 12 + referencias de registro a lo largo de la Ley)

Los sistemas de alto riesgo deben poder registrar eventos automáticamente. El objetivo es la trazabilidad: qué entrada llegó, qué versión del modelo la procesó, qué salida se produjo, más eventos clave del sistema y señales de rendimiento.

Consejos prácticos

• Almacén de registros centralizado y a prueba de manipulaciones con retención alineada a los mínimos legales (ver sección de retención más abajo).
• Etiquete los registros con IDs de versión del modelo e IDs de segmento de datos.
• Capture eventos de anulación cuando los humanos intervienen.

5. Transparencia e instrucciones de uso (Art. 13)

Los usuarios deben recibir instrucciones claras, incluyendo capacidades del sistema, limitaciones, requisitos de datos, acciones de supervisión humana, características de rendimiento y condiciones de riesgo conocidas. Si se necesita una calidad mínima de datos, dígalo. Si el rendimiento se degrada fuera de las especificaciones, adviértales.

6. Supervisión humana (Art. 14)

Diseñe su sistema para que personas debidamente capacitadas puedan comprender cuándo se necesita intervención y puedan realmente intervenir. La supervisión puede significar revisión en tiempo real, umbrales de confianza que derivan a humanos, capacidad de detener la operación automatizada, o flujos de trabajo para apelación / segunda revisión.

Consejos prácticos

• Defina roles de supervisión: operador, revisor, autoridad de escalamiento.
• Proporcione paneles de control con bandas de confianza, alertas de deriva y señales de anomalías.
• Capacite al personal. Documente la finalización de la capacitación. Actualice la capacitación cuando el sistema cambie.

7. Precisión, robustez y ciberseguridad (Art. 15)

Debe cumplir con umbrales de vanguardia apropiados para el caso de uso, resistir el uso indebido razonablemente previsible y proteger contra ataques a la integridad de datos/modelos. Monitoree la deriva del modelo, el envenenamiento de datos, la inyección de prompts (para modelos interactivos) y ejemplos adversarios cuando sea relevante.

8. Sistema de gestión de calidad (SGC) (Art. 17)

Piense en estilo ISO. El SGC envuelve sus políticas, procedimientos, roles, controles, auditorías internas, gestión de proveedores, acciones correctivas y prácticas de documentación a lo largo de todo el ciclo de vida de la IA.

Elementos a cubrir:

• Estructura organizacional y responsabilidades.
• Procedimientos operativos estándar para el desarrollo de modelos.
• Controles de proveedores / componentes de terceros (modelos, conjuntos de datos, herramientas, etc.).
• Control y versionado de documentación.
• Acciones correctivas y preventivas.
• Auditoría interna y revisión de la dirección.

9. Declaración de conformidad de la UE y marcado CE (Arts. 48‑51; muestra del Anexo V)

Antes de colocar un sistema de IA de alto riesgo en el mercado de la UE o ponerlo en servicio, usted declara que cumple con la Ley. Debe mantener la declaración y el archivo técnico de respaldo disponibles para las autoridades de la UE durante todo el período de retención.

Evaluación de conformidad: cuándo llegan las auditorías

No puede desplegar un sistema de IA de alto riesgo en la UE sin pasar por una vía de evaluación de conformidad establecida en los Artículos 43‑47 (y mapeada a los Anexos). La vía depende de si existen normas que cubran su sistema y si usted está bajo regímenes existentes de seguridad de productos.

Vías de evaluación

• Control interno (el proveedor realiza la autoevaluación) cuando aplica completamente las normas armonizadas relevantes y no hay señales de alerta que requieran un organismo notificado.
• Evaluación por terceros por un organismo notificado cuando las normas armonizadas no están (aún) disponibles, cuando se desvía de ellas o cuando lo requiere la ley de seguridad del producto vinculada.
• Sistema de GC + revisión de documentación técnica híbridos para algunas categorías vinculadas a la ley de productos.

¿Cuándo necesita una evaluación nueva/actualizada?

• Primera colocación en el mercado o primera puesta en servicio en la UE.
• Cualquier modificación sustancial que cambie el propósito previsto, la arquitectura, el enfoque de aprendizaje o el rendimiento de maneras que afecten el cumplimiento.
• Un implementador reutiliza el sistema fuera del uso previsto declarado por el proveedor. En ese caso, el implementador puede convertirse en "proveedor" a los ojos de la ley y activar una nueva obligación de evaluación.

¿Cuánto dura una auditoría?

La regulación no establece un número fijo de días. La duración puede depender de lo siguiente:

• Complejidad del sistema.
• Completitud de su paquete de documentación técnica.
• Si aplican normas armonizadas (más rápido) o si el evaluador debe profundizar en evidencia personalizada (más lento).
• Necesidad de inspecciones in situ, muestreo de gobernanza de datos de entrenamiento o pruebas del sistema en vivo.

En dominios de productos regulados (médico, maquinaria), las revisiones de organismos notificados hoy típicamente van desde unos pocos días (solo revisión de documentos) hasta varias semanas o meses (sistemas complejos, ciclos de acciones correctivas).

Monitoreo post-comercialización y respuesta a incidentes (Arts. 72‑74)

Pasar la evaluación no es el final. Los proveedores deben operar un sistema de monitoreo post-comercialización para recopilar, analizar y actuar sobre datos de rendimiento y seguridad del uso en el mundo real. Los incidentes graves y las tendencias de mal funcionamiento deben reportarse a las autoridades nacionales.

Ciclo de monitoreo

1. Recopilar telemetría, métricas de precisión, patrones de error, señales de deriva.
2. Correlacionar con cambios en el entorno (cambios en datos, comportamiento de usuarios, intentos adversarios).
3. Retroalimentar los hallazgos al sistema de gestión de riesgos y CAPA del SGC.
4. Actualizar la documentación técnica y las instrucciones para el usuario.

Retención: cuánto tiempo conservar sus documentos

Las reglas de retención aparecen en varios lugares y aquí está la vista consolidada:

Períodos mínimos de retención

• Documentación técnica de la declaración de la UE: Conservar durante 10 años después de que el sistema de IA se coloque en el mercado o se ponga en servicio. (Mencionado en el Art. 18 con referencias cruzadas a artículos de conformidad; consulte la ley sectorial del producto si es más largo.)
• Registros del SGC e historial de cambios: Alinearse con la ventana de 10 años, pero si la norma de su industria es más larga (los registros médicos suelen ser más largos), deberá seguir la regla más larga.
• Registros automáticos: La Ley no fija un número único en el texto base, pero la orientación que surge de las discusiones de políticas y los borradores de comentarios sugiere al menos 6 meses de retención base para respaldar la trazabilidad e investigación. Muchos proveedores apuntan a 12‑24 meses para estar seguros, más tiempo si es crítico para la seguridad.
• Informes de incidentes y acciones correctivas: Conservar durante 10 años en el archivo técnico para poder demostrar su historial.

¿Cómo debería verse su calendario de gobernanza de IA?

Si está iniciando un programa de cumplimiento, mapee las acciones recurrentes en un calendario para que el trabajo nunca se desvíe. Aquí hay una cadencia inicial que puede ajustar según el nivel de riesgo.

Antes del lanzamiento del sistema de IA;

• Completar el taller de análisis de riesgos.
• Ejecutar pruebas de sesgo, robustez y seguridad.
• Finalizar el paquete de documentación técnica.
• Autocomprobación interna de conformidad o contacto con organismo notificado.

Haga esto trimestralmente:

• Revisar métricas de deriva vs. umbrales de aceptación.
• Auditoría de muestra de registros para anomalías y calidad de datos.
• Actualizar el registro de riesgos con aprendizajes de incidentes.
• Confirmar la dotación de personal de supervisión humana y la vigencia de la capacitación.

Haga esto semestralmente:

• Simulacro de respuesta a incidentes en mesa.
• Revalidación de gobernanza de datos: representatividad, estado de licencias y solicitudes de eliminación.

Haga esto anualmente

• Auditoría interna completa a lo largo de los Artículos 9‑15, 17.
• Reevaluación de contratos + proveedores (modelos, APIs, fuentes de datos).
• Re-emitir instrucciones actualizadas de uso si las capacidades cambiaron.

Active revisiones no programadas cuando:

• Reentrene o ajuste materialmente el modelo.
• Expanda a una nueva población de usuarios o geografía.
• Observe degradación del rendimiento más allá de las tolerancias documentadas.
• Los reguladores emitan nuevas normas armonizadas.

Plan de implementación: establecer un programa de gobernanza de IA de alto riesgo en 90 días

No terminará todo en 90 días, pero puede poner muchas cosas en su lugar.

Días 0‑15: Alcance e inventario

• Inventariar los sistemas de IA. Mapear a las categorías del Anexo III y los vínculos con la ley de productos. Si las herramientas no aprobadas son un punto ciego, la detección de shadow AI puede revelar el uso de IA desde los registros de red existentes.
• Identificar proveedores, implementadores, importadores, distribuidores a lo largo de la cadena de suministro.
• Señalar los sistemas candidatos de alto riesgo.

Días 15‑30: Diseño de gobernanza

• Establecer un grupo de trabajo multifuncional (legal, riesgos, ingeniería, datos, producto, operaciones, ética).
• Redactar taxonomía de riesgos y rúbrica de puntuación alineada con los derechos fundamentales.
• Seleccionar herramientas (registro de riesgos, repositorio de tarjetas de modelo, pipeline de registro, portal de documentación).

Días 30‑60: Construcción de controles

• Crear plantillas de registro de riesgos y lista de verificación pre-despliegue.
• Implementar seguimiento de procedencia de datos y documentación de conjuntos de datos.
• Configurar registro automatizado con etiquetado de versión del modelo.
• Redactar SOPs de supervisión humana y manual de escalamiento.

Días 60‑90: Evidencia y preparación para auditoría

• Completar el esqueleto de documentación técnica para cada candidato de alto riesgo.
• Pilotear un simulacro de evaluación de conformidad interna.
• Cerrar las principales brechas correctivas.
• Establecer políticas de retención y clases de almacenamiento.

Preguntas frecuentes

a. ¿La Ley me dice exactamente cuánto durará una auditoría externa?

No. Define cuándo debe someterse a una evaluación de conformidad y qué evidencia debe proporcionar. La duración depende de la complejidad del sistema y la carga de trabajo del evaluador.

b. ¿Son suficientes 6 meses de registros?

Es un piso que surge de los comentarios de políticas, no un techo. Las industrias reguladas y las aplicaciones críticas para la seguridad deberían conservar mucho más tiempo, especialmente si los incidentes pueden surgir lentamente.

c. Si ajusto un modelo fundacional para puntuación crediticia, ¿soy el proveedor?

Si coloca ese sistema ajustado en el mercado de la UE o lo pone en servicio para ese caso de uso del Anexo III, es probable que los reguladores lo traten como proveedor para ese despliegue. Eso significa obligaciones completas, incluyendo evaluación de conformidad y retención de documentación durante 10 años.

d. ¿Qué pasa si mi startup cierra?

Los Estados miembros definirán mecanismos para preservar la documentación técnica de modo que los reguladores puedan continuar la supervisión. Incorpore cláusulas de custodia o transferencia en los contratos ahora.

Conclusión final

La gobernanza para IA de alto riesgo bajo la EU AI Act es un sistema vivo. La ley vincula la seguridad con una gestión disciplinada del ciclo de vida. Si construye estas prácticas temprano, las evaluaciones de conformidad serán más fluidas y los clientes confiarán más en usted. Si desea un espacio de trabajo listo para usar que mapee estos requisitos en plantillas configurables, explore plataformas de gobernanza de código abierto como VerifyWise o integre flujos de trabajo similares en su stack GRC existente.