AI Act: cumplimiento sin la abstracción.

Clasifique el sistema antes de hacer cualquier otra cosa

Toda decisión del AI Act parte de una pregunta: en qué nivel recae este sistema. Si se equivoca en la clasificación, o bien sobredimensiona un chatbot, o bien infraprotege una herramienta de cribado de CV que un regulador tratará como de alto riesgo. Los cuatro niveles no son un espectro por el que se desliza; son compartimentos discretos con consecuencias jurídicas distintas, y un solo producto puede situarse en más de uno si agrupa varias funciones.

La clasificación es función de la finalidad prevista, no de la sofisticación técnica. Una simple regresión logística que decide quién obtiene un préstamo es de alto riesgo. Un gran modelo multimodal que recomienda recetas no lo es. El Act analiza para qué se usa el sistema y a quién afecta, de modo que el trabajo de clasificación corresponde a producto y cumplimiento de forma conjunta, no solo al equipo de ciencia de datos.

La mayoría de las disputas en la sala de auditoría no son mínimo frente a alto; son alto frente a limitado en la frontera. Si no puede defender la clasificación por escrito, trátela como el nivel superior hasta que pueda. El curso AI Risk Manager recorre la lógica de clasificación y la evidencia que necesita para respaldar una decisión.

Qué significa realmente "alto riesgo" en las operaciones

El TL;DR enumera las siete áreas de obligación. La realidad operativa es que cada una es un proceso recurrente, no un documento que se redacta una sola vez. El cumplimiento del alto riesgo es un sistema que se opera durante toda la vida del producto, y el Act espera que demuestre que el sistema está activo, no que existió el día del lanzamiento.

1. La gestión de riesgos es continua. Identifica el uso indebido y los daños previsibles, los mitiga, prueba el riesgo residual y repite a lo largo de cada cambio sustancial. Un registro de riesgos congelado desde el lanzamiento es un hallazgo, no un control.
2. La gobernanza de datos abarca los conjuntos de entrenamiento, validación y prueba: representatividad, examen de sesgos, lagunas y procedencia de los datos. Tiene que mostrar qué comprobó y qué encontró, no limitarse a afirmar que los datos eran "buenos".
3. La documentación técnica es la columna vertebral del expediente. Describe el sistema, su finalidad, sus decisiones de diseño, sus métricas de rendimiento y sus limitaciones con suficiente detalle para que un tercero pudiera evaluar la conformidad a partir de ella.
4. El registro de eventos significa registro automático a lo largo de la vida del sistema para que los eventos sean trazables. Si algo sale mal, debe poder reconstruir qué hizo el sistema.
5. La supervisión humana tiene que diseñarse desde el principio, no añadirse después: las personas que supervisan el sistema necesitan la capacidad de comprender, intervenir y anular, y la interfaz tiene que hacerlo posible.
6. La exactitud, la robustez y la ciberseguridad tienen que medirse y declararse, y luego sostenerse en condiciones reales, incluidas las adversarias. "Funciona en la demo" no es una afirmación de robustez.

Estas obligaciones se mapean limpiamente sobre un sistema de gestión, por lo que los equipos combinan el Act con ISO/IEC 42001. El curso ISO 42001 Lead Implementer construye el modelo operativo que convierte estas siete áreas en procesos repetibles con responsables, evidencia y ciclos de revisión.

El flujo de trabajo de la evaluación de la conformidad

La evaluación de la conformidad es la barrera que un sistema de alto riesgo supera antes de introducirse en el mercado de la UE. Para la mayoría de las categorías de alto riesgo se trata de una evaluación por control interno ejecutada por el proveedor frente a los requisitos del Act; ciertas categorías, en particular algunas de biometría, pasan por un organismo notificado. En cualquier caso, la secuencia es la misma, y conviene tratarla como un plan de proyecto y no como una lista de comprobación.

1. Confirme la clasificación y los requisitos aplicables para su caso de uso y categoría específicos.
2. Ponga en marcha los procesos de gestión de riesgos y de gobernanza de datos y ejecútelos, generando evidencia real en lugar de marcadores de posición.
3. Reúna la documentación técnica de modo que esté completa y sea internamente coherente con los registros, los resultados de las pruebas y el registro de riesgos.
4. Ejecute la evaluación de la conformidad (interna, o a través de un organismo notificado cuando sea necesario) y resuelva las brechas que aflore.
5. Redacte la declaración de conformidad de la UE, coloque el marcado CE y registre el sistema en la base de datos de la UE antes de salir al mercado.
6. Pase a la vigilancia poscomercialización desde el primer día, porque la obligación no termina con el lanzamiento.

Vigilancia poscomercialización y el calendario por fases

Introducir un sistema en el mercado es el punto intermedio de la obligación, no el final. Los proveedores deben ejecutar un plan de vigilancia poscomercialización que recopile activamente datos de rendimiento e incidentes durante la vida desplegada del sistema, y los incidentes graves tienen que notificarse a las autoridades dentro de plazos definidos. Las modificaciones sustanciales pueden volver a desencadenar la evaluación de la conformidad, de modo que su proceso de gestión del cambio y su proceso del AI Act tienen que estar conectados.

El calendario es por fases, lo que hace tropezar a los equipos que leen "agosto de 2027" y suponen que tienen hasta entonces para todo. Las prohibiciones sobre prácticas inaceptables ya se aplican. Las obligaciones GPAI y varias disposiciones de gobernanza llegan antes en el calendario, y las obligaciones de alto riesgo se incorporan por fases a lo largo del periodo hasta agosto de 2027 según la categoría. La postura correcta es mapear cada uno de sus sistemas a su propia fecha aplicable en lugar de planificar para un único precipicio.

Operar el bucle de vigilancia e incidentes es donde los roles de auditor de IA y de riesgos demuestran su valía. El curso de auditor de IA (AAIA) cubre cómo auditar un sistema de gestión de IA frente a esta evidencia, y el curso de auditor de IA avanzado (AAIR) profundiza en el trabajo de prueba y aseguramiento que sustenta un expediente poscomercialización defendible.

IA de uso general: una obligación separada que puede heredar

Las reglas de los modelos GPAI se sitúan junto a los niveles de riesgo, no dentro de ellos. Si construye o ajusta un modelo de uso general, asume obligaciones de proveedor: documentación técnica del modelo, información para los implementadores posteriores, una política de derechos de autor y un resumen público del contenido de entrenamiento. Los modelos que se considera que conllevan un riesgo sistémico asumen deberes más estrictos, incluidas la evaluación del modelo, las pruebas adversarias y la notificación de incidentes.

La trampa para la mayoría de los equipos está en el otro lado de esa relación. Si integra un modelo fundacional de terceros en su propio sistema de alto riesgo, no escapa del Act apuntando al proveedor del modelo. Hereda el riesgo de la integración y sigue siendo responsable de que su sistema alcance la conformidad. Trate la documentación del proveedor del modelo como una entrada para su expediente, no como un sustituto de este, y establezca las cláusulas contractuales de traspaso antes de lanzar.

Errores frecuentes y la decisión que tiene delante

• Tratar la clasificación como algo puntual. Una función que empezó como motor de recomendación se vuelve de alto riesgo en el momento en que condiciona una decisión de contratación o de crédito. Reclasifique en cada cambio material de finalidad.
• Redactar la documentación como un artefacto de lanzamiento. El expediente tiene que mantenerse sincronizado con el sistema en funcionamiento; un expediente obsoleto es peor que uno incompleto porque induce activamente a error.
• Confundir el sistema de gestión con la regulación. ISO 42001 organiza su prueba, pero por sí solo no hace que un sistema cumpla el AI Act. Sigue teniendo que clasificar, evaluar y registrar frente al Act.
• Suponer que las obligaciones de proveedor GPAI cubren su integración. No lo hacen. Su sistema de alto riesgo necesita su propia historia de conformidad.
• Planificar para un único plazo. Las fechas por fases significan que algunas obligaciones ya están vigentes mientras otras están a años de distancia; planifique por sistema, por categoría.

La decisión que tienen delante la mayoría de los equipos no es si cumplir, sino cómo construir la capacidad de cumplir de forma repetida. Si parte de cero, el curso ISO 42001 Foundation da al equipo un vocabulario compartido, y el curso de gestión de la seguridad de la IA (AAISM) conecta las obligaciones de ciberseguridad y robustez del Act con el programa de seguridad que ya opera. Elija el rol más cercano a su brecha y construya hacia fuera desde ahí.