Artículo 17 de la Ley de IA de la UE: sistema de gestión de la calidad para proveedores de IA de alto riesgo
El Artículo 17 del Reglamento (UE) 2024/1689 exige a los proveedores de IA de alto riesgo documentar un SGC que cubra 13 elementos obligatorios. Plazo: 2 de diciembre de 2027.
El Artículo 17 del Reglamento (UE) 2024/1689 exige a todo proveedor de un sistema de IA de alto riesgo establecer, aplicar, documentar y mantener un sistema de gestión de la calidad (SGC) antes de introducir ese sistema en el mercado o ponerlo en servicio. El SGC es la columna vertebral operativa que vincula su proceso de gestión de riesgos (Artículo 9), su documentación técnica (Artículo 11), su plan de vigilancia poscomercialización (Artículo 72) y sus procedimientos de incidentes graves (Artículo 73) en un único marco auditable.
No se trata de un documento puntual ni de un ejercicio de archivador. Un SGC con arreglo al Artículo 17 debe estar incorporado en la forma en que su equipo construye, prueba, modifica y vigila realmente la IA. Los reguladores y los organismos notificados pedirán verlo funcionar —no solo verlo por escrito—.
El incumplimiento del Artículo 17 se sitúa en el nivel de 15 millones de euros o el 3 % del volumen de negocios anual mundial con arreglo al Artículo 99, apartado 4 (si esta última cifra es mayor). En virtud del Ómnibus Digital acordado en mayo de 2026, las obligaciones de alto riesgo del Anexo III se aplican a partir del 2 de diciembre de 2027 para los sistemas autónomos —aplazando la fecha original de agosto de 2026—. Es un margen útil. No es una excusa para empezar tarde, porque solo la documentación del SGC, hecha como es debido, lleva meses de elaboración.
Qué exige realmente el Artículo 17
El Artículo 17, apartado 1, establece una lista mínima de trece elementos que el SGC debe abordar, por escrito:
- Una estrategia de cumplimiento normativo — que incluya cómo piensa cumplir los requisitos, gestionar las evaluaciones de la conformidad (Artículo 43) y tratar las modificaciones del sistema.
- Técnicas de diseño y de control del diseño — procedimientos documentados sobre cómo se diseña el sistema y cómo se revisan y aprueban los cambios de diseño.
- Técnicas de desarrollo y de garantía de la calidad — procedimientos que rigen cómo se construye el sistema y cómo se mantiene la calidad durante el desarrollo.
- Procedimientos de examen, prueba y validación — que cubran las pruebas antes, durante y después del desarrollo; no solo una comprobación única previa al lanzamiento.
- Especificaciones técnicas y normas aplicadas — incluido cómo se cumplen los requisitos en cualquier ámbito en el que las normas armonizadas no se apliquen plenamente.
- Sistemas de gestión de datos — procedimientos documentados que cubran la adquisición, la recopilación, el análisis, el etiquetado, el almacenamiento, el filtrado y todo lo demás que se haga con los datos antes de introducir el sistema en el mercado.
- El sistema de gestión de riesgos — es decir, el marco del Artículo 9 se incorpora por remisión; no es algo separado del SGC.
- El establecimiento, la aplicación y el mantenimiento de un sistema de vigilancia poscomercialización — con arreglo al Artículo 72; de nuevo, esto se retroalimenta al SGC como una entrada viva.
- Procedimientos para notificar incidentes graves — con arreglo al Artículo 73, incluido quién es responsable y en qué plazo.
- La gestión de las comunicaciones con las autoridades competentes y los organismos notificados — quién responde, cómo y cómo se conservan los registros de esas comunicaciones.
- La conservación de registros — qué se conserva, durante cuánto tiempo y quién puede recuperarlo.
- La gestión de recursos, incluida la seguridad del suministro — garantizando la continuidad de las competencias y los recursos necesarios para mantener el cumplimiento.
- Un marco de rendición de cuentas — que defina las responsabilidades de la dirección y demás personal respecto de cada elemento del SGC.
El Reglamento no le otorga discrecionalidad para omitir ninguno de ellos. Lo que sí es proporcionado es la profundidad y la formalidad de cada elemento —un proveedor de 30 personas no necesita el mismo aparato burocrático que una gran empresa, y el Artículo 17, apartado 4, dice exactamente eso—. Pero el elemento debe existir, por escrito, y debe reflejar cómo opera realmente la organización.
La regla de proporcionalidad — y sus límites
El Artículo 17, apartado 4, reconoce explícitamente que un SGC debe ser proporcionado al tamaño de la organización del proveedor. Esto es una concesión genuina para los proveedores más pequeños: una empresa emergente que construye una herramienta de cribado de selección de personal puede documentar su SGC de forma más ligera que un gran banco que despliega un sistema de calificación crediticia en múltiples mercados.
Lo que la proporcionalidad no significa:
- Que pueda omitir por completo cualquiera de los trece elementos.
- Que una «política de calidad» de una sola página cuente como un SGC.
- Que pueda utilizar procedimientos ligeros para procesos de alto riesgo (p. ej., la vigilancia poscomercialización de un sistema que afecta a la solvencia debe ser sustantiva con independencia del número de empleados de la empresa).
La línea práctica es esta: ajuste la carga de documentación a la realidad organizativa, pero ajuste los controles reales al riesgo real. Un proveedor de tecnología de RR. HH. de 25 personas que opera una herramienta de cribado de candidatos para clientes empresariales opera con un riesgo significativo. El SGC debe reflejarlo —aunque esté redactado de forma más concisa que un marco corporativo certificado según la norma ISO 9001—.
El Artículo 17, apartado 3, añade que, si el proveedor ya está sujeto a un SGC con arreglo a otra normativa sectorial de la UE (por ejemplo, un fabricante de productos sanitarios que opera con arreglo al MDR de la UE), las obligaciones del Artículo 17 pueden satisfacerse integrando los elementos específicos de la IA en ese sistema existente. Usted documenta la integración; no construye una estructura paralela.
ISO/IEC 42001 e ISO 9001: útiles, no suficientes
La norma ISO/IEC 42001:2023 —la norma de sistema de gestión de la IA (AIMS)— se corresponde estrechamente con muchos elementos del Artículo 17 y proporciona un marco estructural creíble. Si su organización posee o persigue la certificación 42001, le da un punto de partida defendible y un vocabulario que se alinea con el Reglamento.
Advertencia importante: la certificación según la norma ISO/IEC 42001 no equivale al cumplimiento del Artículo 17. La norma es agnóstica respecto del sector tecnológico y no cubre automáticamente todos los elementos que exige el Reglamento. En particular:
- Las obligaciones de vigilancia poscomercialización del Artículo 72 y los requisitos de notificación de incidentes del Artículo 73 necesitan documentación procedimental explícita que un AIMS genérico puede no abordar plenamente.
- La integración de la gestión de riesgos del Artículo 9 debe ser verificable, no solo referenciada.
- El marco de rendición de cuentas (elemento 13 anterior) debe nombrar funciones reales, no solo describir la gobernanza en abstracto.
La norma ISO 9001 es una norma de gestión de la calidad más antigua, pero aún muy extendida. Si su SGC se basa en la ISO 9001, puede ampliarlo para cubrir los elementos específicos de la IA. Documente la ampliación con claridad —un auditor de la evaluación de la conformidad querrá ver que los controles específicos de la IA están incorporados, no añadidos como un anexo que nadie lee—.
La respuesta honesta para la mayoría de los proveedores: una base de 42001 o 9001 ahorra tiempo, pero un SGC construido por un consultor de calidad sin conocimiento de la Ley de IA de la UE seguirá teniendo lagunas. Los trece elementos del Artículo 17, apartado 1, son la lista de comprobación.
El SGC como documento vivo: versionado y gestión del cambio
El requisito del Artículo 17 de «mantener» un SGC no es un evento de cumplimiento puntual —es una obligación continua que sigue el ciclo de vida del sistema—. Los proveedores subestiman con frecuencia esta dimensión. Construyen un SGC para la evaluación inicial de la conformidad, reciben el marcado CE y luego tratan el documento como cerrado. Ese enfoque falla la primera vez que se actualiza el sistema.
El concepto de modificación sustancial de la Ley (Artículo 3, apartado 23) es el motor clave. Cualquier cambio que afecte al cumplimiento por parte del sistema de los requisitos de la sección 2, o que modifique su finalidad prevista, activa una evaluación de la conformidad nueva o actualizada con arreglo al Artículo 43. El SGC debe diseñarse desde el principio para captar y procesar los cambios —no para registrar el sistema tal como estaba en el lanzamiento—.
En concreto, sus procedimientos de control del diseño (elemento 2) y su estrategia de cumplimiento normativo (elemento 1) deben responder juntos a tres preguntas para cada cambio propuesto del sistema:
- ¿Altera este cambio la finalidad prevista del sistema o el caso de uso del Anexo III en el que entra?
- ¿Afecta este cambio a alguno de los requisitos técnicos de la sección 2 —perfil de riesgo, datos de entrenamiento, métricas de exactitud, diseño de la supervisión humana o arquitectura de registro—?
- ¿Requiere este cambio un expediente técnico actualizado del Artículo 11, una repetición de la evaluación de la conformidad, o ambas cosas?
El registro de la decisión para cada cambio —incluida la decisión de que un cambio determinado no es sustancial— debería conservarse. Esta es la base de pruebas si una autoridad de vigilancia del mercado argumenta más adelante que el proveedor debería haber vuelto a evaluar.
Un procedimiento práctico de control de cambios para un proveedor de tamaño medio tiene este aspecto: se plantea un ticket de cambio en el sistema de desarrollo; un revisor designado (normalmente el responsable de cumplimiento o el director técnico) aplica la prueba de las tres preguntas; el resultado se documenta en el registro de cambios del SGC; el expediente técnico se actualiza para reflejar el estado actual del sistema; y la línea de base de registro para la vigilancia poscomercialización se restablece a la nueva versión. Esto lleva quizá de dos a cuatro horas para un cambio menor y bastante más para un reentrenamiento del modelo o una ampliación del ámbito. Adquirir el hábito antes del lanzamiento es mucho menos perturbador que readaptarlo bajo escrutinio regulatorio.
El SGC y el expediente técnico del Artículo 11
El SGC y el paquete de documentación técnica del Artículo 11 / Anexo IV son obligaciones distintas, pero profundamente interdependientes. Los proveedores que los tratan como proyectos separados tienden a acabar con una documentación internamente incoherente —una evaluación de riesgos en el expediente técnico que no coincide con el registro de riesgos del SGC, o una sección de metodología de pruebas en el expediente técnico que referencia un procedimiento que ya no figura en el SGC—.
La relación es estructural. El expediente técnico del Anexo IV debe incluir: una descripción del proceso de desarrollo del sistema; los conjuntos de datos de entrenamiento, validación y prueba utilizados; la metodología de gestión de riesgos; el plan de vigilancia poscomercialización; y una descripción de cómo se diseñaron las medidas de supervisión humana. Todos ellos son resultados —o referencias directas— del SGC. El SGC es donde esos procesos se poseen y gobiernan; el expediente técnico es donde se registran para la evaluación externa.
Esto significa que el control de versiones importa en ambos documentos simultáneamente. Cuando reentrena el modelo con un nuevo conjunto de datos, el registro de gestión de datos del SGC cambia —y también lo hace la sección de datos de entrenamiento del expediente del Anexo IV—. Cuando revisa sus umbrales de vigilancia poscomercialización, el procedimiento del SGC cambia —y también lo hace el plan de VPC del expediente técnico—. Un proveedor que mantiene ambos documentos de forma aislada los verá divergir a los pocos meses del lanzamiento.
Un enfoque práctico: trate el SGC como el registro operativo autorizado y el expediente técnico como una instantánea de un momento concreto derivada de él. Utilice referencias de documento (números de versión, fechas de exportación) para vincular ambos de forma explícita. Cuando el auditor de la evaluación de la conformidad pida ver ambos, deberían ser rastreables entre sí.
El marco de rendición de cuentas en la práctica
El elemento 13 —el marco de rendición de cuentas— es el elemento más comúnmente subespecificado en los primeros borradores de los documentos del SGC. No basta con escribir «la dirección es responsable del cumplimiento». El marco de rendición de cuentas del Artículo 17, apartado 1, letra m), debe definir, específicamente, qué personas físicas o funciones dentro de la organización son responsables de cada elemento del SGC.
Para un proveedor pequeño, esto no requiere una gran burocracia. Una matriz de gobernanza de dos páginas es suficiente, siempre que cubra:
- Responsable del SGC: la persona (nombrada o por función) responsable de mantener el SGC global, programar las revisiones internas y activar las actualizaciones cuando el sistema cambie. Para la mayoría de los proveedores pequeños, es el director técnico o un responsable técnico sénior.
- Responsable de la gestión de riesgos: la persona responsable de mantener y actualizar el registro de riesgos del Artículo 9. Debería ser alguien con suficiente comprensión técnica del sistema como para evaluar si un nuevo contexto de despliegue crea nuevos riesgos.
- Responsable de la gobernanza de datos: responsable de los procedimientos de gestión de datos y de garantizar que cada versión del modelo se entrena y valida frente a conjuntos de datos documentados y aprobados.
- Responsable de la vigilancia poscomercialización: responsable de revisar los informes de vigilancia, escalar las anomalías y activar el procedimiento de notificación de incidentes cuando se alcance el umbral del Artículo 73.
- Contacto regulatorio: la persona que gestiona las comunicaciones con las autoridades competentes y los organismos notificados. Para los proveedores establecidos fuera de la UE, esta función la desempeña en parte el representante autorizado con arreglo al Artículo 22, pero también debe haber una contraparte interna.
¿Qué ocurre cuando la persona que ocupa una de estas funciones se marcha? El Artículo 17 no especifica explícitamente un procedimiento de sucesión, pero los elementos de gestión de riesgos y de gestión de recursos (7 y 12) exigen juntos que el SGC contemple la continuidad. Documente la función; no documente solo a la persona. El SGC debería sobrevivir a los cambios de personal —y la organización debería tener un procedimiento para actualizar la matriz de rendición de cuentas cuando las funciones cambien o las ocupen personas nuevas—.
Para los proveedores que son a la vez proveedores de modelos de IA de uso general (GPAI) y proveedores de sistemas de alto riesgo (un escenario menos común pero real), el marco de rendición de cuentas debe ser claro sobre qué procesos de gobernanza se aplican a qué obligaciones. Las obligaciones del Artículo 53 para todos los proveedores de GPAI —documentación técnica para los integradores posteriores, política de cumplimiento de los derechos de autor, resumen de los datos de entrenamiento— se sitúan en una parte distinta de la Ley respecto de los requisitos del SGC del Artículo 17. Necesitan una titularidad diferenciada aunque el mismo equipo pequeño asuma ambas.
La gestión de riesgos y la interfaz con el Artículo 9
El SGC es el contenedor; el Artículo 9 es uno de sus contenidos más importantes. El Artículo 17, apartado 1, letra g), exige que el sistema de gestión de riesgos establecido con arreglo al Artículo 9 se incorpore al SGC —lo que significa que ambos deben ser coherentes y referenciarse de forma cruzada—.
El Artículo 9 exige:
- Un proceso continuo e iterativo a lo largo de todo el ciclo de vida del sistema (no una evaluación única previa al lanzamiento).
- La identificación de los riesgos conocidos y previsibles —incluidos el uso indebido, los usos no previstos razonablemente previsibles y las interacciones con otros sistemas—.
- La estimación y evaluación de los riesgos que pueden surgir cuando el sistema se utiliza conforme a su finalidad prevista y en condiciones de uso indebido razonablemente previsibles.
- La adopción de medidas de gestión de riesgos y la verificación de que esas medidas funcionan.
- La prueba del sistema con las medidas de gestión de riesgos adecuadas aplicadas, en condiciones que reflejen el despliegue en el mundo real.
Para un proveedor de tecnología jurídica de 40 personas cuya herramienta de análisis de contratos utilizan los bufetes de abogados para evaluar la exposición a litigios: el proceso del Artículo 9 debe documentar el riesgo previsible de que el sistema se utilice en tipos de contrato fuera de su ámbito de entrenamiento, qué ocurre si sus predicciones son sistemáticamente erróneas para una jurisdicción determinada y qué mecanismo de supervisión humana detecta ese fallo. El SGC debe demostrar que ese proceso existe, se sigue y se actualiza cuando el sistema se modifica o surgen nuevos riesgos.
La gestión de datos dentro del SGC
El elemento 6 —la gestión de datos— suele recibir la menor atención, aun cuando el Artículo 10 impone por separado requisitos detallados de gobernanza de datos para los conjuntos de datos de entrenamiento, validación y prueba. El Artículo 17 exige que el SGC contenga procedimientos documentados que cubran la cadena de datos desde la adquisición hasta el mercado.
Esto significa:
- De dónde proceden los datos (origen), qué contratos o licencias rigen su uso y si son adecuados para la tarea prevista.
- Cómo se etiquetan, depuran y filtran los datos —y quién es responsable de la calidad en cada etapa—.
- Qué pasos de detección de sesgos se aplican antes del entrenamiento y la validación, y qué mostraron los resultados.
- Cómo se almacenan los datos, quién tiene acceso y qué versión del conjunto de datos se utilizó para cada versión del modelo.
Para un proveedor de calificación crediticia, «utilizamos un conjunto de datos abierto estándar y un preprocesamiento estándar» no es documentación —es una laguna—. Los reguladores preguntarán qué conjunto de datos, qué versión, cuál era la composición demográfica y si los resultados de la validación estaban estratificados.
Vigilancia poscomercialización y notificación de incidentes
El Artículo 17, apartado 1, letras h) e i), exigen que el SGC incluya tanto la vigilancia poscomercialización (VPC) como los procedimientos de incidentes graves. Estos son operativamente distintos pero están estrechamente conectados.
La vigilancia poscomercialización (Artículo 72) significa un plan sistemático para recopilar y analizar datos del sistema desplegado. El plan debe ser proporcionado al nivel de riesgo del sistema de IA y especificar:
- Qué datos se recopilan (métricas de rendimiento, reclamaciones de usuarios, anomalías detectadas).
- Con qué frecuencia se revisan y por quién.
- Qué umbrales activan una acción correctiva.
- Cómo se retroalimentan las conclusiones al sistema de gestión de riesgos.
Un proveedor de 20 personas de una herramienta de IA que evalúa la admisibilidad a prestaciones públicas no puede basarse en una vigilancia ad hoc. El plan debe estar documentado. Si la vigilancia revela errores sistemáticos que afectan a un grupo protegido, eso no es un fallo de producto —es un evento de cumplimiento con arreglo tanto al Artículo 72 como al Artículo 9—.
La notificación de incidentes graves (Artículo 73) exige a los proveedores notificar, sin demora indebida, cualquier incidente grave a la autoridad de vigilancia del mercado del Estado miembro en el que se produjo el incidente. «Sin demora indebida» no se define como un número fijo de días en el propio Artículo 73 —el plazo de notificación depende de la naturaleza del incidente, y el SGC debería especificar su cronología interna de escalado para que la notificación externa cumpla la obligación—.
El SGC debe asignar responsabilidad nominal a ambos procesos. Un plan de vigilancia poscomercialización que diga «el equipo vigila el rendimiento» no es conforme. El plan debe decir quién, cómo y qué activa la acción.
Un ejemplo trabajado: un proveedor de tecnología de selección de personal de 35 personas
Una empresa con 35 empleados construye una herramienta de cribado de candidatos que clasifica a los solicitantes para clientes del sector de los servicios financieros. La herramienta entra en el Anexo III, punto 4 (empleo, gestión de los trabajadores, acceso al autoempleo). Es de alto riesgo. El proveedor está sujeto al Artículo 17 a partir del 2 de diciembre de 2027.
Un SGC proporcionado pero conforme para este proveedor incluiría:
Gobernanza: una política de dos páginas que nombra al director técnico como responsable del SGC, al responsable de producto como responsable de los controles de diseño y al responsable de cumplimiento como responsable de la notificación regulatoria. Responsabilidades documentadas; actualizadas cuando cambian las funciones.
Controles de diseño: un registro de cambios basado en tickets en el sistema de desarrollo (ya en uso), con un paso de revisión documentado antes de que cualquier cambio del modelo pase a producción. El paso de revisión comprueba: cambio en el uso previsto, cambio en el perfil de riesgo, necesidad de pruebas actualizadas.
Gestión de riesgos: un registro de riesgos del Artículo 9 que cubre los diez riesgos previsibles más significativos, con una mitigación documentada para cada uno. Revisado trimestralmente, o inmediatamente después de una actualización sustancial del modelo. Vinculado al protocolo de pruebas.
Gestión de datos: un registro de gobernanza de datos de dos páginas para cada versión del conjunto de datos utilizada en el entrenamiento y la validación —procedencia, composición, pasos de preprocesamiento, resultados de la comprobación de sesgos, fecha de la versión—. Almacenado en el sistema de gestión documental junto con la versión del modelo.
Prueba y validación: un plan de pruebas por escrito que especifica los segmentos demográficos en los que se validan las tasas de rechazo falso, los umbrales de aprobación/suspenso y quién da el visto bueno. Informes de prueba conservados por versión del modelo.
Vigilancia poscomercialización: informes mensuales a partir de los registros del sistema, revisados por el responsable de producto. Alertas automáticas si la tasa de rechazo falso para cualquier grupo demográfico supera el umbral fijado en el plan de pruebas. Vía de escalado documentada: responsable de producto → director técnico → asesor jurídico → notificación a la autoridad si se activa el Artículo 73.
Notificación de incidentes: un procedimiento de una página que identifica qué constituye un incidente grave (cualquier resultado que cause o que previsiblemente cause un perjuicio a los derechos de un candidato), quién decide si se notifica a la autoridad y el plazo interno objetivo para esa decisión (48 horas desde la identificación).
Conservación de registros: calendario de conservación documental. Los registros del SGC se conservan durante la vida útil del sistema más cinco años. Las versiones del modelo y los informes de prueba asociados se conservan con arreglo al mismo calendario.
Esto no es un marco de 200 páginas. Está documentado, es proporcionado, tiene titularidad y está vinculado a procesos reales. Eso es lo que exige el Artículo 17.
Anexo VI frente a Anexo VII: dos vías de conformidad, distinto escrutinio del SGC
El Artículo 43 ofrece a la mayoría de los proveedores de sistemas de IA de alto riesgo autónomos del Anexo III la posibilidad de elegir la vía de evaluación de la conformidad. Comprender qué vía se aplica a su sistema —y qué significa eso para el escrutinio del SGC— afecta a cómo construye y documenta el sistema.
El Anexo VI (control interno) es la vía de autoevaluación disponible para la mayoría de las categorías del Anexo III. El proveedor reúne la documentación técnica, aplica el SGC, realiza su propia verificación de que el sistema cumple los requisitos de la sección 2 y redacta la declaración UE de conformidad. Ningún auditor externo examina el SGC directamente como parte de la evaluación de la conformidad. El SGC debe existir y ser conforme de todos modos —pero en la vía del Anexo VI, la calidad de ese SGC no la verifica un tercero independiente en el momento de la evaluación de la conformidad—. Las autoridades de vigilancia del mercado pueden examinarlo después del lanzamiento si surge una preocupación.
El Anexo VII (evaluación por terceros) se aplica a categorías específicas de mayor escrutinio del Anexo III —principalmente los sistemas de identificación biométrica remota destinados a utilizarse en espacios de acceso público por parte de las fuerzas y cuerpos de seguridad, y la IA de alto riesgo integrada en productos regulados cuando la legislación de productos aplicable requiere la intervención de un organismo notificado—. Con arreglo al Anexo VII, un organismo notificado evalúa el SGC directamente antes de emitir un certificado de conformidad, como se describe en la sección anterior.
La implicación práctica es esta: si su sistema entra en la vía del Anexo VI, la ausencia de un escrutinio externo del SGC en el momento de la evaluación de la conformidad no reduce su obligación de tener un SGC conforme —simplemente significa que el escrutinio llegará más tarde, y según el calendario de la autoridad y no el suyo—. Un SGC bien documentado construido para el Anexo VI debería ser capaz de resistir un examen de nivel del Anexo VII si se activa una investigación de vigilancia del mercado.
Un matiz más: cuando un proveedor ya ha obtenido la certificación del Anexo VII y luego realiza una modificación sustancial del sistema, el Artículo 43, apartado 4, exige al proveedor notificar al organismo notificado y, o bien obtener la aprobación de la modificación, o bien someterse a una nueva evaluación. El procedimiento de control de cambios del SGC (elementos 1 y 2) debe incluir un paso que determine si un cambio propuesto alcanza ese umbral de notificación. Los proveedores que se saltan este paso —dando por sentado que el certificado existente sigue cubriendo el sistema modificado— se enfrentan tanto a un fallo de conformidad como a una posible responsabilidad con arreglo al Artículo 20 si la no conformidad se descubre más adelante.
Qué audita un organismo notificado en un SGC
Para los sistemas de IA de alto riesgo que requieren una evaluación de la conformidad por organismo notificado con arreglo al Artículo 43 —los de los ámbitos del Anexo III en los que se aplica el procedimiento del Anexo VII—, el organismo notificado auditará el SGC directamente. Comprender qué examinan le ayuda a construir una documentación que aguante el escrutinio.
La auditoría suele tener tres fases. Primero, una revisión documental: el auditor lee el SGC por escrito y comprueba que están presentes los trece elementos del Artículo 17, apartado 1, que el marco de rendición de cuentas nombra funciones reales y que la estrategia de cumplimiento normativo es coherente con la clasificación y la finalidad prevista del sistema. Un SGC en el que la sección de estrategia de cumplimiento diga únicamente «cumplimos la Ley de IA de la UE» no superará esta fase.
Segundo, una entrevista de proceso: los auditores hablan con las personas que realmente hacen el trabajo —el desarrollador que ejecuta las pruebas de validación, el jefe de producto que revisa los informes de vigilancia, el ingeniero que gestiona una actualización del modelo—. Comprueban la coherencia entre lo que dicen los documentos y lo que hace realmente el equipo. La laguna más habitual es un procedimiento de vigilancia bien redactado que nadie ha seguido nunca en la práctica.
Tercero, una comprobación de muestra: el auditor selecciona una versión del modelo y pide ver los informes de prueba, el registro de gobernanza de datos, la entrada de evaluación de riesgos y la entrada del registro de cambios —todo para la misma versión—. Si falta alguno de ellos, o si los identificadores de versión no coinciden, eso es una constatación.
Una constatación de auditoría que requiera una acción correctiva antes de la emisión del certificado no es un desastre —es habitual—. Lo peligroso es iniciar el proceso de evaluación de la conformidad sin un SGC que pueda sobrevivir a una revisión documental, porque la subsanación bajo presión de tiempo es cara y perturbadora.
Cómo ayuda Confir
Construir un SGC desde cero, frente a una lista de comprobación legal de trece elementos, es la tarea de cumplimiento que la mayoría de los proveedores pequeños más posponen. Confir le da el andamiaje: el módulo de Gobernanza y Vigilancia Poscomercialización de la IA (AIGM) se corresponde directamente con los Artículos 9, 72 y 73, y el motor basado en reglas genera la estructura de registro de su registro de riesgos, su plan de vigilancia poscomercialización y su procedimiento de escalado de incidentes —referenciados de forma cruzada a los Artículos específicos, proporcionados al nivel de riesgo del sistema, listos para auditoría desde el primer día—. El paquete de documentación del Artículo 11 / Anexo IV cubre los registros de gestión de datos y la documentación de diseño que alimentan los elementos 5 y 6 del Artículo 17, apartado 1. Autoservicio —sin consultores, sin una implementación de seis meses—.
El plazo de cumplimiento
En virtud del Ómnibus Digital (acuerdo político alcanzado el 7 de mayo de 2026, adopción formal prevista antes del 2 de agosto de 2026), los proveedores de sistemas de IA de alto riesgo autónomos del Anexo III deben cumplir antes del 2 de diciembre de 2027. La IA de alto riesgo integrada en productos regulados del Anexo I tiene hasta el 2 de agosto de 2028.
Para los proveedores que actualmente construyen sistemas que estarán en el mercado antes de esas fechas: el SGC del Artículo 17 debe estar implantado antes de que el sistema se introduzca en el mercado. Si lanza en el tercer trimestre de 2027, su SGC debe existir y estar operativo antes del lanzamiento —no para diciembre de 2027—.
No interprete el plazo ampliado como permiso para empezar más tarde. El trabajo de documentación y de proceso interno que requiere un SGC suele llevar de tres a seis meses completarlo como es debido. Empiece ahora y el plazo será cómodo. Empiece a mediados de 2027 y estará construyendo infraestructura de cumplimiento en paralelo con el lanzamiento de un producto.
Guías relacionadas
- soluciones de software de cumplimiento del Artículo 17
- herramientas de gestión de inventario de sistemas de IA
- niveles de clasificación de riesgo
- gobernanza de la IA para el cumplimiento de la Ley de IA de la UE
- comparación de soluciones de software de SGC
Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar
Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 7 días.
Empieza la prueba gratuita →