Obligaciones del proveedor conforme a la Ley de IA de la UE para las empresas SaaS que lanzan una funcionalidad de alto riesgo
Obligaciones del proveedor SaaS conforme al Art. 16 de la Ley de IA de la UE: gestión de riesgos, expediente técnico, conformidad del Art. 43, declaración de conformidad del Art. 47, registro del Art. 49. Plazo: 2 dic 2027.
El Artículo 16 del Reglamento (UE) 2024/1689 designa al proveedor — la entidad que desarrolla o introduce un sistema de IA en el mercado bajo su propio nombre — como la parte que soporta la carga de cumplimiento más pesada. Si su producto SaaS incluye una funcionalidad de IA que se clasifica como de alto riesgo en virtud del Artículo 6 y del Anexo III, usted es ese proveedor. La pila de obligaciones no es una lista de comprobación que se marca una sola vez. Va desde el diseño del sistema hasta la vigilancia poscomercialización y culmina en una evaluación formal de la conformidad, una Declaración de conformidad firmada, el marcado CE y el registro en la base de datos de la UE antes de lanzar. El plazo para los sistemas autónomos del Anexo III es el 2 de diciembre de 2027 en virtud del Ómnibus Digital acordado en mayo de 2026 (la fecha original del 2 de agosto de 2026 se ha aplazado).
Esta página recorre las obligaciones del Artículo 16 en el orden en que las encuentra en la práctica. El mapa general de obligaciones para todos los roles de proveedor está en ai-compliance/provider-obligations; la cuestión previa — si su SaaS es proveedor o responsable del despliegue — se responde en ai-compliance/for-saas. Aquí el rol está resuelto: usted lanza la funcionalidad, usted soporta las obligaciones.
Primero: confirme que es el proveedor, no el responsable del despliegue
El Artículo 3, apartado 3, define al proveedor como una entidad que desarrolla un sistema de IA o hace que se desarrolle y lo introduce en el mercado o lo pone en servicio bajo su propio nombre o marca comercial. Si integra un modelo de un tercero (pongamos, una API de GPAI) en una funcionalidad y la lanza a sus clientes bajo el nombre de su producto, usted es el proveedor de esa funcionalidad. Sus clientes que utilizan la funcionalidad son responsables del despliegue.
Hay una complicación específica de las empresas SaaS que construyen sobre modelos fundacionales: la trampa del Artículo 25. El Artículo 25 establece que un responsable del despliegue de un modelo de GPAI que lo integra en un producto y lo lanza bajo su propio nombre asume las obligaciones del proveedor para el sistema resultante. Esa es casi con seguridad la situación en la que usted se encuentra. El proveedor del modelo de GPAI sigue siendo el proveedor del propio modelo y debe suministrar documentación del Anexo XII a los constructores posteriores en virtud del Artículo 53. Ese resumen técnico del Anexo XII es una prueba útil para su propio expediente técnico — pero no sustituye a su documentación del Artículo 11, que abarca el sistema de alto riesgo que ha construido encima.
Una modificación sustancial activa un reinicio del rol de proveedor. Si toma un sistema de IA de un tercero que ya se había introducido en el mercado de la UE y lo modifica de un modo que afecta a su perfil de riesgo o a su finalidad prevista, el Artículo 3, apartado 23, lo define como una modificación sustancial — y en virtud del Artículo 25, el sistema modificado se trata como un nuevo sistema introducido en el mercado por usted.
La pila de obligaciones del Artículo 16, artículo por artículo
Artículo 9 — Sistema de gestión de riesgos
Debe establecer, implementar, documentar y mantener un sistema de gestión de riesgos a lo largo de todo el ciclo de vida del sistema. El sistema es un proceso iterativo: identificar y analizar los riesgos conocidos y previsibles; estimar y evaluar los riesgos en el uso normal y en el uso indebido razonablemente previsible; adoptar medidas de mitigación de riesgos; evaluar el riesgo residual tras la mitigación.
El Artículo 9, apartado 7, vincula el sistema de gestión de riesgos a los datos de entrenamiento, validación y prueba: las medidas relativas a los datos del Artículo 10 forman parte de lo que debe abordar su sistema de gestión de riesgos del Artículo 9. En la práctica, el sistema de gestión de riesgos no es un documento puntual — es un registro continuo de identificación de riesgos, decisiones de mitigación y resultados de vigilancia que constituye la columna vertebral de su expediente técnico. En virtud del SGC del Artículo 17 (véase más abajo), sus procedimientos de gestión de riesgos deben estar documentados.
Artículo 10 — Datos y gobernanza de datos
Todo sistema de IA de alto riesgo que utilice datos de entrenamiento debe cumplir los requisitos del Artículo 10. Los conjuntos de datos de entrenamiento, validación y prueba deben estar sujetos a prácticas adecuadas de gobernanza de datos: deben ser pertinentes, suficientemente representativos y, en la medida de lo posible, libres de errores, teniendo en cuenta la finalidad prevista. Es importante destacar que el Artículo 10, apartado 5, permite el tratamiento de datos personales de categorías especiales (datos de salud, datos biométricos) cuando sea estrictamente necesario para detectar y corregir sesgos — pero solo con salvaguardias adecuadas.
El Artículo 10 trata de los datos sobre los que se construyó su sistema, no de la competencia del personal (eso es el Artículo 4, alfabetización en IA, que se aplica desde el 2 de febrero de 2025). Confundir ambas cosas es un error de cumplimiento habitual.
Artículo 11 y Anexo IV — Documentación técnica
El Artículo 11 le exige elaborar la documentación técnica antes de introducir el sistema en el mercado y mantenerla actualizada. El Anexo IV especifica nueve áreas de contenido, que incluyen: una descripción general del sistema y su finalidad prevista; una descripción de los elementos del sistema y del proceso de desarrollo; información sobre el entrenamiento, la validación y la prueba; información sobre la vigilancia poscomercialización; y una declaración de conformidad.
Este es el documento que una autoridad de vigilancia del mercado pedirá ver. Debe estar sujeto a control de versiones. El período de conservación es de diez años en virtud del Artículo 18. Si utiliza un modelo de GPAI, la documentación del Anexo XII que su proveedor del modelo proporciona en virtud del Artículo 53 es una aportación a su expediente del Anexo IV — le indica las capacidades, las limitaciones y los riesgos conocidos del modelo que debe abordar en su propia gestión de riesgos.
Artículo 13 — Transparencia e instrucciones de uso
El Artículo 13 exige que los sistemas de alto riesgo se diseñen y desarrollen de un modo suficientemente transparente para que los responsables del despliegue (sus clientes) puedan interpretar el resultado del sistema y utilizarlo adecuadamente. Las instrucciones de uso deben abarcar: la identidad, la finalidad y el nivel de rendimiento del sistema; los tipos de personas o grupos sobre los que se pretende utilizar; qué supervisión humana se requiere; y cualquier limitación, sesgo o circunstancia conocidos en los que el rendimiento pueda degradarse.
Las instrucciones de uso no son un documento de marketing. Son un artefacto de cumplimiento que acompaña al producto e indica al responsable del despliegue qué debe hacer para mantener un uso lícito. Si un responsable del despliegue infringe las instrucciones, la responsabilidad se desplaza: tanto el Artículo 25 como el Artículo 26 contemplan cambios de rol cuando se cruza el límite del uso previsto.
Artículo 14 — Supervisión humana desde el diseño
El Artículo 14 no es un requisito de política. Es un requisito de diseño. Debe construir el sistema de modo que las personas físicas puedan supervisarlo eficazmente durante el despliegue — lo que significa que el sistema debe diseñarse para permitir la supervisión incluso cuando funciona en un contexto SaaS en el que sus ingenieros no están físicamente presentes. Eso requiere: una interfaz que permita a los responsables del despliegue comprender los resultados e identificar anomalías; la capacidad de ignorar, anular o revertir el resultado del sistema; y, cuando el sistema pueda funcionar con una supervisión humana reducida, mecanismos adecuados para detectar y gestionar las situaciones que requieran intervención humana.
El Artículo 14, apartado 4, introduce una capacidad de «parada»: los responsables del despliegue deben poder interrumpir el sistema con un botón de parada o un procedimiento equivalente. Si su funcionalidad SaaS alimenta decisiones automatizadas aguas abajo, debe diseñar para ese punto de interrupción.
Artículo 15 — Exactitud, robustez y ciberseguridad
El Artículo 15 exige que los sistemas de alto riesgo se diseñen para alcanzar niveles adecuados de exactitud, robustez y ciberseguridad. La robustez aquí es el propio término del texto legal — significa resiliencia frente a errores, fallos e incoherencias en las entradas, incluidas las entradas adversarias. Esta es una especificación de ingeniería, no una descripción de producto. Su sistema de gestión de riesgos del Artículo 9 debe contener el modelo de amenazas, y su documentación del Anexo IV debe registrar la metodología de prueba y los resultados.
Para los proveedores SaaS, la ciberseguridad es especialmente material: usted conserva datos de clientes, ejecuta infraestructura de inferencia y los resultados de su sistema pueden informar decisiones que afectan a personas. El Artículo 15, apartado 3, menciona específicamente la resiliencia frente a los intentos de terceros de alterar el uso, el comportamiento, el rendimiento o la integridad.
Artículo 17 — Sistema de gestión de la calidad
El Artículo 17 exige a los proveedores que implanten un sistema de gestión de la calidad que abarque: una estrategia para el cumplimiento normativo; técnicas y procedimientos para la evaluación de la conformidad; procedimientos de examen para los incidentes graves; procedimientos de gestión de datos; conservación de registros; mapas de rendición de cuentas y responsabilidad; y procedimientos de auditoría interna. Para una empresa SaaS en fase temprana, el SGC no necesita ser elaborado — pero sí debe existir como política documentada, sujeta a control de versiones y de la que sea responsable una persona o un equipo nombrados.
La norma ISO/IEC 42001:2023 (la norma de sistemas de gestión de la IA) se corresponde bien con el Artículo 17 y proporciona un andamiaje de gobernanza que también genera pruebas para los Artículos 9, 10 y 11. La certificación ISO 42001 es voluntaria y no es lo mismo que la evaluación de la conformidad del Artículo 43 — pero una empresa que haya construido conforme a la norma encontrará el montaje del expediente técnico significativamente más fácil.
Artículo 19 — Registros generados automáticamente
El Artículo 19 exige a los proveedores que garanticen que sus sistemas de alto riesgo generen registros automáticamente en la medida en que sea técnicamente factible. Los proveedores deben conservar estos registros durante un mínimo de seis meses, cuando los registros estén bajo su control. Los registros respaldan tanto el sistema de vigilancia poscomercialización del Artículo 72 como cualquier investigación de incidentes en virtud del Artículo 73.
Artículo 43 — Evaluación de la conformidad (control interno del Anexo VI)
Antes de introducir un sistema de alto riesgo del Anexo III en el mercado de la UE, debe completar una evaluación de la conformidad en virtud del Artículo 43. Para la mayoría de los sistemas del Anexo III — categorías 2 a 8 (infraestructuras críticas, educación, empleo, servicios esenciales, garantía del cumplimiento del Derecho, migración, justicia/democracia) —, se trata de una autoevaluación interna siguiendo el procedimiento del Anexo VI. No necesita un organismo notificado.
El procedimiento del Anexo VI tiene tres partes: (1) verificar que su sistema cumple todos los requisitos de los Artículos 9 a 15; (2) examinar la documentación técnica para confirmar la conformidad; (3) mantener la documentación disponible durante diez años. El resultado es la Declaración UE de conformidad del Artículo 47 firmada y el derecho a colocar el marcado CE del Artículo 48.
La excepción es el punto 1 del Anexo III (biometría): para los sistemas de identificación biométrica remota en los que no se hayan aplicado normas armonizadas, se exige la vía del organismo notificado del Anexo VII.
Artículo 47 — Declaración UE de conformidad
La Declaración de conformidad es un documento formal en el que usted (el proveedor) afirma que el sistema de alto riesgo es conforme con la Ley. El Artículo 47 especifica qué debe contener: la identificación del sistema, los datos del proveedor, una declaración de conformidad y referencias a la documentación técnica. Una sola Declaración puede abarcar varios sistemas si son suficientemente similares. La Declaración debe redactarse en la lengua oficial de cada Estado miembro de la UE en el que introduzca el sistema — el inglés por sí solo no basta a menos que venda exclusivamente en jurisdicciones de habla inglesa.
Artículo 48 — Marcado CE
Una vez completada la evaluación de la conformidad y firmada la Declaración de conformidad, coloca el marcado CE en el sistema, o en su embalaje o en la documentación que lo acompaña cuando no sea factible colocarlo en el propio sistema. El Artículo 48, apartado 4, prohíbe colocar el marcado CE antes de que se complete la evaluación del Artículo 43.
Artículo 49 — Registro en la base de datos de la UE
Antes de introducir el sistema en el mercado de la UE, los proveedores deben registrarlo en la base de datos de la UE para sistemas de IA de alto riesgo en virtud del Artículo 71. El Artículo 49 establece qué debe abarcar el registro: la información enumerada en el Anexo VIII, que incluye la finalidad del sistema, las capacidades, la vía de evaluación de la conformidad seguida y la referencia de la Declaración de conformidad. El registro es independiente de la evaluación de la conformidad — ambos deben realizarse, en ese orden.
Artículo 72 — Vigilancia poscomercialización
El Artículo 72 le exige mantener un sistema de vigilancia poscomercialización durante toda la vida útil del sistema. El sistema debe recopilar, documentar y analizar activamente datos sobre el rendimiento, los cuasiincidentes y los incidentes en producción. Para los proveedores SaaS, los registros automáticos del Artículo 19 son la principal fuente de datos de este sistema. Su sistema de vigilancia debe ser capaz de detectar la degradación del rendimiento, los comportamientos inesperados y los nuevos riesgos que no se identificaron en el momento de la evaluación de la conformidad. Cuando el sistema lo utilizan varios responsables del despliegue, necesita un mecanismo estructurado de retroalimentación para recibir de ellos los informes de incidentes.
Artículo 73 — Notificación de incidentes graves
El Artículo 73 le exige notificar los incidentes graves a la autoridad de vigilancia del mercado del Estado miembro en el que se produjo el incidente. Plazos en virtud del Artículo 73:
- 15 días desde que se tiene conocimiento de un incidente (regla general, Art. 73, apdo. 2)
- 2 días para una infracción generalizada o un perjuicio grave e irreversible para una infraestructura crítica (Art. 73, apdo. 3)
- 10 días cuando una persona ha fallecido (Art. 73, apdo. 4)
Se permite un informe inicial incompleto; debe ir seguido de un informe completo (Art. 73, apdo. 5). El «incidente grave» se define en el Artículo 3, apartado 49: un incidente que causa o puede causar, directa o indirectamente, la muerte, un perjuicio grave o una perturbación significativa de infraestructuras o servicios críticos, o que afecta a los procesos democráticos o vulnera los derechos fundamentales.
El deber del responsable del despliegue está relacionado pero es distinto: en virtud del Artículo 26, los responsables del despliegue deben vigilar y señalarle los incidentes y riesgos a usted como proveedor. La notificación a las autoridades en virtud del Art. 73 es su obligación, no la de ellos.
La trampa del Artículo 25: construir sobre una API de GPAI
Una empresa SaaS que invoca una API de un modelo fundacional para alimentar una funcionalidad de alto riesgo afronta una geometría de cumplimiento específica. El proveedor del modelo es el proveedor del modelo de GPAI; en virtud del Artículo 53, le debe a los constructores posteriores (usted) documentación técnica — en forma de Anexo XII — que abarca las capacidades, las limitaciones y los riesgos conocidos del modelo. También le debe una política de cumplimiento de la legislación sobre derechos de autor y un resumen de los datos de entrenamiento.
Esa documentación del Anexo XII es su punto de partida, no su punto final. Usted es el proveedor del sistema de IA de alto riesgo. Sus obligaciones en virtud de los Artículos 9 a 15, 17, 19, 43, 47, 48, 49, 72 y 73 se aplican todas al sistema que ha construido — que incluye el modelo subyacente, pero no se limita a él. Si el Anexo XII del proveedor del modelo revela un sesgo conocido o una limitación de capacidad, su sistema de gestión de riesgos del Artículo 9 y su expediente técnico del Artículo 11 deben abordarlo.
La trampa es esta: algunas empresas dan por hecho que, si el modelo fundacional cumple los requisitos de GPAI, ellas heredan ese cumplimiento. No lo heredan. El cumplimiento de GPAI abarca la capa del modelo. La capa de aplicación — la funcionalidad de alto riesgo que ha construido — requiere su propia pila completa.
Plazos y sanciones
El plazo para los sistemas autónomos de alto riesgo del Anexo III es el 2 de diciembre de 2027. Para los sistemas de IA de alto riesgo integrados en productos del Anexo I (componentes de seguridad de máquinas, productos sanitarios, etc.), el plazo es el 2 de agosto de 2028. Estas son las fechas confirmadas en virtud del acuerdo político del Ómnibus Digital de 7 de mayo de 2026; se espera la adopción formal antes de la fecha original del 2 de agosto de 2026.
El incumplimiento de la mayoría de las obligaciones del proveedor — Artículos 9 a 15, 17, 43, 47, 48, 49, 72, 73 — se rige por el Artículo 99, apartado 4: un máximo de 15 000 000 EUR o el 3 % del volumen de negocios anual mundial total del ejercicio financiero anterior, si esta última cifra es mayor. En virtud del Artículo 99, apartado 6, para las pymes y las empresas emergentes la multa se limita al menor de los dos importes — una protección de proporcionalidad genuina, pero no un motivo para demorarse.
Cómo ayuda Confir
Montar la pila del Artículo 16 desde cero consume mucho tiempo. Confir genera el paquete de documentación técnica del Artículo 11 / Anexo IV, produce la Declaración de conformidad del Artículo 47 / Anexo V y ejecuta la evaluación estructurada en las cuatro áreas de cumplimiento que se corresponden con los Artículos 9, 10, 11, 13, 14, 15, 43, 72 y 73. El motor es basado en reglas y determinista: la misma admisión produce la misma conclusión, cada regla que se activa es legible para un humano y el resultado es defendible en una auditoría. La evaluación de la conformidad se ejecuta en menos de tres sesiones. Sin consultores, sin proyecto de implantación.
Preguntas frecuentes
Si construyo una funcionalidad de IA de alto riesgo utilizando una API de un tercero, ¿soporto las obligaciones del proveedor del Artículo 16?
Sí. En virtud del Artículo 25, cuando desarrolla un sistema de IA sobre un modelo de GPAI y lo introduce en el mercado de la UE bajo su propio nombre, pasa a ser el proveedor de ese sistema. El proveedor del modelo de GPAI soporta las obligaciones del Artículo 53 para la capa del modelo y debe suministrarle documentación del Anexo XII. Usted soporta los Artículos 9 a 15, 17, 19, 43, 47, 48, 49, 72 y 73 para la funcionalidad de alto riesgo que ha construido. No hay traspaso de cumplimiento del modelo fundacional a la aplicación construida sobre él.
¿Cuál es la diferencia entre la evaluación de la conformidad del Artículo 43 y la certificación ISO/IEC 42001?
La evaluación de la conformidad del Artículo 43 es un requisito legal: debe completarla antes de introducir un sistema de alto riesgo del Anexo III en el mercado de la UE. Para la mayoría de las categorías del Anexo III (puntos 2 a 8), es una autoevaluación interna en virtud del procedimiento del Anexo VI — sin organismo notificado. La certificación ISO/IEC 42001 es voluntaria y demuestra que su sistema de gestión de la IA cumple los controles de la norma. Genera pruebas útiles para los Artículos 9, 11 y 17, pero no sustituye a la evaluación del Artículo 43. Las dos son complementarias, no intercambiables.
Mi funcionalidad SaaS puntúa a los candidatos a un empleo. El cliente (un equipo de RR. HH.) revisa cada decisión. ¿Significa esa supervisión compartida que soy responsable del despliegue, no proveedor?
No. El hecho de que su cliente ejerza la supervisión humana hace de su cliente el responsable del despliegue en virtud del Artículo 26 — no cambia su rol. Usted desarrolló la funcionalidad y la introduce en el mercado bajo su nombre; usted es el proveedor en virtud del Artículo 3, apartado 3, y soporta todas las obligaciones del Artículo 16. Las obligaciones del Artículo 26 del responsable del despliegue corren en paralelo a las suyas, no en lugar de ellas. Sus instrucciones de uso del Artículo 13 deben indicar al responsable del despliegue qué supervisión se requiere.
¿Qué es un «incidente grave» en virtud del Artículo 73, y cuáles son los plazos de notificación?
El Artículo 3, apartado 49, define un incidente grave como aquel que causa o puede causar la muerte, un perjuicio grave para las personas, una perturbación significativa de infraestructuras o servicios críticos, o la vulneración de los derechos fundamentales. Lo notifica a la autoridad de vigilancia del mercado del Estado miembro en el que se produjo el incidente: en un plazo de 15 días desde que tiene conocimiento, con carácter general; 2 días para un perjuicio generalizado o a infraestructura crítica; 10 días cuando una persona ha fallecido. Se permite un informe inicial incompleto que debe ir seguido de uno completo. Esta es una obligación del proveedor. Sus responsables del despliegue (clientes) le notifican los incidentes a usted en virtud del Artículo 26 — no los notifican directamente a las autoridades.
¿Cuál es la obligación de registro en virtud del Artículo 49, y es independiente de la evaluación de la conformidad?
Sí — son requisitos secuenciales. Tras completar la evaluación de la conformidad del Artículo 43 y firmar la Declaración de conformidad del Artículo 47, registra el sistema en la base de datos de la UE en virtud del Artículo 71 antes de introducirlo en el mercado. El registro requiere la información del Anexo VIII, incluida la finalidad prevista del sistema, la vía de evaluación de la conformidad y una referencia a la Declaración. El registro no sustituye a la evaluación de la conformidad, y la evaluación de la conformidad no sustituye al registro.
¿Cuándo surte efecto el cambio de plazo del Ómnibus Digital, y cuál era la fecha original?
El plazo original de alto riesgo del Anexo III era el 2 de agosto de 2026. En virtud del Ómnibus Digital — una propuesta de la Comisión de noviembre de 2025 que alcanzó un acuerdo político entre el Parlamento y el Consejo el 7 de mayo de 2026, con adopción formal prevista antes de agosto de 2026 —, el plazo para los sistemas autónomos del Anexo III pasa al 2 de diciembre de 2027 y para los sistemas integrados en productos del Anexo I al 2 de agosto de 2028. Este aplazamiento se aplica únicamente a las obligaciones de alto riesgo; las normas de transparencia de riesgo limitado del Artículo 50 siguen aplicándose desde el 2 de agosto de 2026.
Guías relacionadas
- obligaciones de las empresas SaaS
- niveles de riesgo de los Artículos 6 a 11
- requisitos de cumplimiento para empresas
- lista de comprobación de cumplimiento de los Artículos 6 a 29
- definiciones del Artículo 3
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 →