Skip to main content

Cumplimiento del reglamento IA en su pipeline CI/CD

Qué exige el Reglamento que un pipeline CI/CD puede probar, tres fases de pipeline, cómo funciona el merge gate de GitHub de Scanara y dónde terminan los análisis basados en reglas.

El Reglamento no exige CI/CD. Los proveedores de sistemas de IA de alto riesgo deben mantener actualizada la documentación técnica (artículo 11). Deben también probar antes de la comercialización o puesta en servicio (artículo 9(8)). Deben, además, gestionar un sistema de gestión de la calidad (artículo 17). Un pipeline puede aportar pruebas de estos deberes.

Estos deberes se aplican desde el 2 de diciembre de 2027 (anexo III) y desde el 2 de agosto de 2028 (anexo I). El artículo 2 enumera exclusiones. Las multas pueden alcanzar 15 millones de EUR o el 3 % del volumen de negocios anual mundial, si esta cuantía es superior (artículo 99(4)). Siguiente paso: asigne cada fase del pipeline al artículo que prueba.

Un pipeline puede aportar pruebas de estos deberes; no decide el cumplimiento

  • La documentación técnica se mantiene actualizada (artículo 11)

    La documentación técnica se elabora antes de la comercialización o puesta en servicio y se mantiene actualizada. Contiene como mínimo los elementos del anexo IV. Un paso del pipeline puede comprobar que los documentos exigidos existen y cambian junto con el código.

  • Las pruebas se hacen antes de la comercialización o puesta en servicio (artículo 9(6) a (8))

    Las pruebas se realizan en cualquier momento del desarrollo y, en todo caso, antes de la comercialización o puesta en servicio, con métricas y umbrales probabilísticos definidos previamente y adecuados a la finalidad prevista. Las fases de prueba del pipeline con umbrales fijos producen resultados fechados.

  • La gestión de la calidad incluye el control de cambios (artículo 17(1))

    El sistema de gestión de la calidad documenta el control del diseño, el control de calidad del desarrollo, los procedimientos de examen, prueba y validación y la gestión de las modificaciones. Los registros del pipeline y las reglas de revisión pueden dejar constancia de estos pasos.

  • Las modificaciones sustanciales exigen una nueva evaluación de la conformidad (artículo 43(4))

    Un cambio en un sistema tras la comercialización que la evaluación de la conformidad inicial no había previsto, y que afecta al cumplimiento de los requisitos de la sección 2 o cambia la finalidad prevista, es una modificación sustancial (artículo 3, punto 23). Un pipeline puede señalar cambios en el modelo o en la finalidad prevista para revisión humana. No decide si un cambio es sustancial. En los sistemas que siguen aprendiendo tras la comercialización, los cambios predeterminados en la evaluación inicial y documentados conforme al anexo IV, punto 2, letra f), no son modificaciones sustanciales (artículo 43(4)).

Tres fases de pipeline que encajan con estos deberes (nuestra propuesta)

El Reglamento no nombra fases de pipeline. Esta división pone comprobaciones rápidas en cada pull request y el análisis completo antes de la publicación.

Fase 1: comprobaciones en la pull request

Se ejecutan en cada pull request y dan respuesta rápida a los desarrolladores.

  • Análisis de código: El análisis estático basado en reglas señala componentes de IA y patrones ausentes, por ejemplo operaciones de IA sin registro. Solo detecta patrones estándar de marcos de ML.
  • Comprobación de documentos: Las reglas de políticas comprueban que existan los documentos exigidos y que contengan las secciones exigidas. Comprueban que el contenido esté presente, no que sea veraz ni bueno.
  • Registro de la clase de riesgo: Compruebe que la clasificación de riesgo del sistema está registrada y se revisa cuando cambian el código o la finalidad prevista. La clasificación en sí es una decisión humana (artículo 6).

Fase 2: merge gate

Una comprobación antes del merge que puede frenar cambios no conformes.

  • Límites de hallazgos: Fije límites para hallazgos críticos y altos. En modo bloqueante, un análisis que supere los límites hace fallar la comprobación.
  • Hallazgos de los artículos 5 y 14: Un análisis de código no muestra intención ni contexto. Una persona revisa cada hallazgo que apunte a una práctica prohibida (artículo 5) o a la falta de supervisión humana (artículo 14).
  • Cambios en la documentación: Compruebe que la documentación del anexo IV cambia en la misma pull request que el código que describe.

Fase 3: análisis previo a la publicación

Un análisis completo de la versión candidata.

  • Análisis completo: Un análisis completo de código y documentos. El análisis de documentos admite ocho idiomas: EN, DE, FR, IT, ES, NL, PL y PT.
  • Borrador de dossier: Scanara redacta borradores de documentos alineados con los anexos IV y V a partir de sus datos y respuestas de evaluación. El rellenado automático es parcial; usted escribe y verifica el resto.
  • Instantánea de pruebas: Guarde el informe del análisis junto al registro de la versión, para poder demostrar qué se comprobó y cuándo.

Cómo funciona el merge gate de GitHub de Scanara

Scanara recibe los eventos de pull request de GitHub, analiza el cambio e informa del resultado como una ejecución de comprobación de GitHub. En el modo solo informe, una comprobación fallida se notifica como neutral. En el modo bloqueante, la comprobación falla.

El merge gate solo funciona con GitHub. Los análisis programados aún no están disponibles; los análisis se ejecutan bajo demanda y en las pull requests.

Qué comprueban los análisis y dónde terminan

La cobertura es parcial. En la instantánea del 24 de agosto de 2026, 77 de 174 obligaciones mapeadas tienen reglas de código, en 43 artículos, y 23 tienen reglas de documentos, en 23 artículos. El mapeo es anterior a los cambios del Reglamento (UE) 2026/1744, por ejemplo los artículos 4a, 60a y 75a a 75d. Las demás obligaciones requieren evaluaciones y trabajo humano.

Reglas de código

  • Artículo 5: prácticas prohibidas

    Las reglas señalan patrones de código que pueden indicar una práctica prohibida. Que una práctica esté prohibida depende de la finalidad y del contexto, que el código no muestra.

  • Artículo 9: gestión de riesgos

    Las reglas señalan puntos de decisión de IA sin código reconocible de evaluación de riesgos o de validación.

  • Artículo 10: datos y gobernanza de datos

    Las reglas señalan pipelines de entrenamiento sin comprobaciones reconocibles de calidad de datos.

  • Artículo 12: registro

    Las reglas señalan operaciones de IA sin registro reconocible.

  • Artículo 14: supervisión humana

    Las reglas señalan rutas de decisión sin un punto de intervención humana reconocible, como una anulación o un procedimiento de parada.

  • Artículo 15: precisión y robustez

    Las reglas señalan la falta de validación del modelo y de métricas de precisión.

Reglas de documentos

  • Secciones de la documentación técnica (artículo 11)

    Las reglas de Scanara definen ocho secciones obligatorias de la documentación técnica, basadas en el anexo IV, y comprueban que estén presentes. Comprueban que hay contenido, no que sea bueno.

  • Instrucciones de uso (artículo 13)

    Comprueba que existen instrucciones de uso y que contienen las secciones exigidas.

  • Declaración UE de conformidad

    Comprueba que la declaración contiene los elementos enumerados en el anexo V.

  • Ocho idiomas

    El análisis de documentos admite EN, DE, FR, IT, ES, NL, PL y PT.

Lista de comprobación de la implantación

  • Añada un análisis de código y documentos al flujo de trabajo de las pull requests.
  • Empiece en modo solo informe y revise los hallazgos.
  • Fije límites para hallazgos críticos y altos y después pase al modo bloqueante.
  • Exija la revisión humana de cada hallazgo que afecte al artículo 5 o al artículo 14.
  • Guarde el informe del análisis con cada registro de versión.
  • Señale para revisión los cambios en el modelo, los datos de entrenamiento o la finalidad prevista como posibles modificaciones sustanciales (artículo 43(4)).
  • Repita el análisis completo antes de cada versión y actualice la documentación del anexo IV.
  • Mantenga la documentación técnica en el repositorio junto al código y actualícela en la misma pull request.

Exclusiones, sistemas anteriores y límites de las multas

El Reglamento no se aplica a los sistemas de IA usados exclusivamente con fines militares, de defensa o de seguridad nacional (artículo 2(3)). No se aplica a los sistemas de IA desarrollados y puestos en servicio específicamente y con el único fin de la investigación y el desarrollo científicos (artículo 2(6)), ni a la investigación, las pruebas o el desarrollo previos a la comercialización o puesta en servicio, salvo las pruebas en condiciones reales (artículo 2(8)). Quedan excluidos los sistemas con licencias libres y de código abierto, salvo que se comercialicen o pongan en servicio como sistemas de alto riesgo o entren en el artículo 5 o 50 (artículo 2(12)). Las personas físicas que usan un sistema en una actividad personal de carácter no profesional no están obligadas como responsables del despliegue (artículo 2(10)). Para los sistemas de alto riesgo ligados a productos de la legislación del anexo I, sección B, como vehículos de motor, aviación, ferrocarril, equipos marinos, vehículos agrícolas y maquinaria, solo se aplican el artículo 6(1), el artículo 60a y los artículos 102 a 112. Los artículos 57 a 59 se aplican solo en la medida en que esa legislación integre los requisitos (artículo 2(2)).

Los sistemas de alto riesgo comercializados o puestos en servicio antes de la fecha de aplicación solo quedan cubiertos tras cambios significativos de diseño. En cualquier caso, los proveedores y los responsables del despliegue de sistemas de IA de alto riesgo destinados a ser utilizados por autoridades públicas deben adoptar las medidas necesarias para cumplir a más tardar el 2 de agosto de 2030 (artículo 111(2)).

Para las pymes, cada multa llega como máximo al porcentaje o la cuantía que sea inferior (artículo 99(6)). Para las pequeñas empresas de mediana capitalización (artículo 3, punto 14b), el mismo límite se aplica a las multas de los apartados 4 y 5 del artículo 99 (artículo 99(6a)). El nivel de 15 millones de EUR abarca también las obligaciones de proveedores y operadores del artículo 25, apartados 2 y 4 (artículo 99(4), letra da).

Siguiente lectura: pistas de auditoría, análisis basado en reglas y documentación técnica

Scanara prepara pruebas a partir de sus repositorios

Scanara lee sus repositorios de GitHub conectados y ejecuta análisis basados en reglas de patrones habituales de IA y aprendizaje automático. Puede pasar por alto código no estándar. Por separado, genera borradores de documentación a partir de plantillas y de sus respuestas en las evaluaciones, como pruebas para su trabajo de cumplimiento. Usted decide la clasificación.