Multas del AI Act de hasta el 7 % de los ingresos: es hora de integrar el cumplimiento normativo en el pipeline de ML

La multa por infringir las prohibiciones del EU AI Act llega a 35 millones de euros o al 7% de la facturación anual mundial; para el resto de infracciones, a 15 millones de euros o al 3%. En este contexto, KDnuggets publica una tesis breve pero reveladora: un modelo puede ser puntero y cumplir la normativa a la vez, siempre que la gobernanza deje de ser la última barrera antes del lanzamiento y se integre en cada etapa del pipeline de ML. El original es un anuncio breve, sin métricas ni casos, así que a continuación analizamos cómo se traduce esta idea en la práctica.

Por qué falla la revisión previa al lanzamiento

El escenario típico le resultará familiar a casi cualquier equipo. Data science entrena el modelo, elige las métricas y lo despliega en staging. Después entran en juego los abogados y los gestores de riesgos. Resulta que el dataset no tiene un origen documentado, que las decisiones del modelo no se registran y que una de las variables guarda correlación con un atributo protegido. El resultado: semanas de rediseño o un proyecto congelado.

Para los sistemas de alto riesgo, el AI Act exige gestión de datos, documentación técnica, logging, supervisión humana y un nivel determinado de precisión y robustez. Parte de todo esto no se puede reconstruir a posteriori: el historial de los datos y las condiciones de entrenamiento que no se registraron no tienen recuperación posible. Los plazos de aplicación de ciertas disposiciones se debaten y se ajustan, pero el conjunto de requisitos se conoce de antemano. No tiene sentido esperar a la auditoría final.

Qué integrar en cada etapa

Ya existe un marco práctico. El NIST AI RMF describe cuatro funciones: Govern, Map, Measure y Manage. La norma ISO/IEC 42001, publicada en diciembre de 2023, fija los requisitos del sistema de gestión de IA en una organización. Solo queda vincularlos a las etapas del pipeline:

• Datos: lineage, licencia y base jurídica para su uso, versión del dataset e informe de sesgos por grupos.
• Entrenamiento: configuraciones y seed registradas, seguimiento de experimentos y build reproducible.
• Validación: métricas de calidad por subgrupos (por ejemplo, la diferencia de TPR y FPR entre ellos), pruebas de robustez y red-teaming para los modelos generativos.
• Despliegue: model card, artefacto firmado y aprobación del lanzamiento por parte de un responsable de riesgo designado.
• Operación: monitorización de drift, logs de decisiones, umbrales de alerta, procedimiento de rollback y una persona en el circuito allí donde se exija.

La clave está en convertir la checklist en automatización. Si el repositorio no contiene una model card actualizada, o el informe de sesgos queda por debajo del umbral fijado, el pipeline de CI falla igual que con unos tests unitarios fallidos. El cumplimiento normativo pasa a formar parte de la disciplina de ingeniería y deja de ser un trámite burocrático.

Dónde están los escollos

La automatización no resuelve las cuestiones de fondo. Las métricas de equidad pueden entrar en conflicto entre sí: en general, no es posible satisfacer a la vez varias de las definiciones más populares si las tasas base de los grupos difieren. Elegir la métrica y el umbral no es una decisión solo técnica, sino también del equipo de negocio y de los abogados, y debe documentarse. Además, hay un coste: el logging, el tracking y las pruebas adicionales encarecen la infraestructura y ralentizan las primeras iteraciones. El beneficio llega después, cuando no hace falta rehacer un producto ya terminado.

Por dónde empezar

Empiece por un inventario: una lista de todos los modelos en producción y en desarrollo, cada uno con un responsable y un nivel de riesgo. Elija un modelo de alto riesgo y recorra con él todo el camino. Introduzca una plantilla única de model card. Añada dos o tres gates automáticos en el CI: presencia de documentación, informe de sesgos y comprobación del logging. Defina quién tiene derecho a detener un lanzamiento. Cuando el proceso funcione con un modelo, escalarlo al resto será más sencillo que redactar un reglamento desde cero para todo el portfolio de golpe.