Azure OpenAI y la Ley de IA de la UE: ¿de quién es la obligación de cumplimiento?

Azure OpenAI Service es un servicio sobre el que se construye. Llamas a los modelos de OpenAI — GPT-4o, o3 u otros — a través de la infraestructura Azure de Microsoft para construir tu propia funcionalidad o sistema de IA. Los propios modelos quedan detrás de OpenAI y Microsoft; tu aplicación se sitúa delante de los usuarios. Esa estratificación tiene una consecuencia jurídica directa con arreglo a la Ley de IA de la UE (Reglamento (UE) 2024/1689): cuando introduces tu aplicación en el mercado o la pones en servicio con tu propio nombre, eres casi con seguridad el proveedor de ese sistema, con el conjunto completo de obligaciones del proveedor del artículo 16.

Las obligaciones del modelo GPAI subyacente — documentación técnica, política de derechos de autor, resumen de los datos de entrenamiento — recaen sobre OpenAI y Microsoft con arreglo al artículo 53. A ti te incumbe el sistema que has construido encima.

La pregunta central: ¿qué hace tu sistema?

La Ley de IA de la UE clasifica los sistemas de IA por su uso, no por el modelo que los alimenta. Azure OpenAI no es intrínsecamente de alto riesgo, de riesgo limitado ni de riesgo mínimo. El sistema que construyas y despliegues podría ser de cualquiera de los cuatro niveles.

Una lista de comprobación útil para empezar, antes que nada:

• ¿Desempeña el sistema una función enumerada en el anexo III (biometría, calificación crediticia, selección de personal, garantía del cumplimiento del Derecho, etc.)? En tal caso, es presuntamente de alto riesgo con arreglo al artículo 6.
• ¿Interactúa directamente con personas físicas como un chatbot o genera contenido sintético? En tal caso, las obligaciones de transparencia del artículo 50 se aplican a partir del 2 de agosto de 2026.
• ¿Es un componente de seguridad de un producto cubierto por la legislación armonizada de la UE (productos sanitarios, máquinas, aviación civil)? El artículo 6, apartado 1, y el anexo I lo arrastran al nivel de alto riesgo por una vía distinta.
• ¿Es una herramienta interna de productividad — redactar correos electrónicos, resumir documentos, generar código — utilizada por tu propio personal para tareas sin consecuencias? Eso es probablemente de riesgo mínimo, sin obligaciones obligatorias.

La mayoría de las organizaciones que construyen sobre Azure OpenAI tocarán más de una categoría simultáneamente: un chatbot orientado al cliente que además realiza un precribado crediticio se sitúa tanto en el artículo 50 como en el punto 5, letra b), del anexo III.

La lógica del papel: ¿proveedor, responsable del despliegue o ambos?

Eres el proveedor (artículo 16) si desarrollas el sistema y lo introduces en el mercado o lo pones en servicio con tu nombre o marca — con independencia de que el modelo subyacente sea de Azure. La definición del artículo 3 no hace concesión alguna al «solo envolvimos una API»: si tu nombre figura en él y los usuarios lo reciben como tu servicio, las obligaciones del proveedor son tuyas.

Eres el responsable del despliegue (artículo 26) si integras Azure OpenAI en un sistema construido por otra parte y lo utilizas bajo tu propia autoridad en un contexto profesional — por ejemplo, licenciar una herramienta de revisión jurídica de un tercero construida sobre un modelo de IA y ejecutarla sobre tus propios contratos. Las obligaciones del responsable del despliegue son más ligeras: seguir las instrucciones del proveedor, garantizar una supervisión humana significativa, conservar los registros durante al menos seis meses (artículo 26) y realizar una evaluación de impacto relativa a los derechos fundamentales (artículo 27) si eres un organismo público o si despliegas un sistema de solvencia o de seguros de vida/salud.

Los cambios de papel importan. Con arreglo al artículo 25, un responsable del despliegue o un distribuidor pasa a ser proveedor — y hereda el conjunto completo de obligaciones del proveedor — si pone su propio nombre en un sistema, lo modifica sustancialmente o cambia su finalidad prevista. Una empresa que toma una integración de Azure OpenAI de uso general y la reutiliza para cribar candidatos a un empleo ha activado probablemente ese cambio.

La lectura práctica para la mayoría de las empresas que construyen sobre Azure OpenAI: si has construido una funcionalidad que los usuarios finales o los clientes reciben como tu producto, eres el proveedor a los efectos de la Ley de IA de la UE para esa funcionalidad.

Cuándo tu aplicación es de alto riesgo

Si el sistema que construiste sobre Azure OpenAI desempeña una función comprendida en el anexo III, soportas el conjunto completo de obligaciones de cumplimiento de alto riesgo. Los ocho ámbitos del anexo III incluyen:

1. Biometría — identificación biométrica remota, categorización, reconocimiento de emociones (cuando esté permitido)
2. Infraestructuras críticas — componentes de seguridad en infraestructuras digitales, tráfico rodado, suministros
3. Educación y formación profesional — decisiones de admisión, evaluación, supervisión de exámenes
4. Empleo y gestión de los trabajadores — contratación, cribado, promoción, despido, asignación de tareas (anexo III, punto 4)
5. Acceso a servicios privados y públicos esenciales — solvencia y calificación crediticia, excluyendo la detección de fraude (punto 5, letra b)); riesgo y fijación de precios de los seguros de salud y de vida (punto 5, letra c)); envío de servicios de emergencia; admisibilidad a prestaciones públicas
6. Garantía del cumplimiento del Derecho — riesgo de delinquir/reincidir, polígrafos, fiabilidad de las pruebas, elaboración de perfiles
7. Migración, asilo y control fronterizo
8. Administración de justicia y procesos democráticos

Se aplica el filtro del artículo 6, apartado 3: un sistema del anexo III no es de alto riesgo si no plantea un riesgo significativo de perjuicio — por ejemplo, desempeña una tarea procedimental limitada, o mejora el resultado de una actividad humana previamente realizada sin influir en el resultado, o realiza únicamente un trabajo preparatorio. Pero todo sistema que elabore perfiles de personas físicas es siempre de alto riesgo con independencia de este filtro. Los proveedores que se acogen a la exención deben documentar esa evaluación y, aun así, registrar el sistema con arreglo al artículo 49.

El conjunto de obligaciones del proveedor para una aplicación de Azure OpenAI de alto riesgo

Una vez clasificado como de alto riesgo, debes completar lo siguiente antes de introducir el sistema en el mercado o ponerlo en servicio. El plazo para los sistemas autónomos del anexo III es el 2 de diciembre de 2027 — aplazado respecto de la fecha original de agosto de 2026 en virtud del Ómnibus Digital (Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026). Para los sistemas de IA integrados como componentes de seguridad en productos del anexo I, el plazo es el 2 de agosto de 2028.

Sistema de gestión de riesgos — artículo 9. Un proceso documentado y continuo: identificar los riesgos previsibles, estimar la probabilidad y la gravedad, aplicar medidas técnicas y de procedimiento, evaluar el riesgo residual y reevaluar a lo largo de todo el ciclo de vida del sistema. No es una auditoría puntual. Para una funcionalidad de cribado de empleo construida sobre Azure OpenAI, los riesgos previsibles incluyen el sesgo demográfico en la clasificación, el impacto desproporcionado sobre grupos protegidos y la manipulación del sistema por parte de los candidatos.

Datos y gobernanza de datos — artículo 10. Los datos de entrenamiento, validación y prueba deben estar sujetos a una gobernanza documentada: pertinencia, representatividad, ausencia de errores en la medida de lo posible y consideración específica del sesgo cuando los datos reflejen patrones históricos discriminatorios. No puedes limitarte a heredar esto de OpenAI; debes documentar cómo cumplen el estándar tus datos de ajuste fino o tus conjuntos de datos de generación aumentada por recuperación.

Documentación técnica — artículo 11 / anexo IV. El paquete de documentación cubre el diseño del sistema, la finalidad prevista, los escenarios de uso indebido previsibles, la composición de los datos de entrenamiento, las métricas de rendimiento entre los subgrupos pertinentes, los registros de gestión de riesgos y los procedimientos de supervisión humana. Es el documento jurídico que inspeccionan los reguladores y los organismos notificados. Debe mantenerse actualizado durante diez años después de que el sistema abandone el mercado (artículo 18).

Transparencia e información a los responsables del despliegue — artículo 13. Si suministras tu sistema de alto riesgo a responsables del despliegue posteriores, debe ir acompañado de un conjunto de instrucciones claro y legible por máquina: para qué sirve el sistema, sus limitaciones, las medidas de supervisión humana exigidas y los datos que espera. Los responsables del despliegue no pueden cumplir sus propias obligaciones (artículo 26) sin esta información.

Supervisión humana — artículo 14. El sistema debe diseñarse de modo que una persona física pueda supervisar eficazmente su funcionamiento, comprender los resultados, intervenir, anularlos y negarse a actuar conforme a ellos. Para una herramienta de precribado crediticio impulsada por Azure OpenAI, esto significa que el analista de riesgos debe poder ver por qué se generó una puntuación, anularla y documentar esa anulación — no limitarse a refrendar una recomendación.

Precisión, solidez y ciberseguridad — artículo 15. Niveles adecuados de precisión para la finalidad prevista; resiliencia frente a entradas adversarias y errores; medidas de ciberseguridad documentadas. La seguridad a nivel de infraestructura de Azure no satisface esto para tu capa de aplicación.

Evaluación de la conformidad — artículo 43. Antes de la introducción en el mercado, debes demostrar la conformidad con los artículos 9 a 15. La mayoría de las categorías del anexo III (fuera de la biometría, donde por lo general se exige un organismo notificado con arreglo al anexo VII) pueden evaluarse mediante autoevaluación interna con arreglo al anexo VI. Interna no significa superficial: la documentación debe resistir el escrutinio externo.

Declaración UE de conformidad — artículo 47. Una declaración firmada de que el sistema cumple todos los requisitos aplicables. Una vez confirmada la clasificación de alto riesgo, esta acompaña al sistema al mercado.

Registro — artículo 49. Antes de introducir un sistema de alto riesgo en el mercado o ponerlo en servicio, debes registrarlo en la base de datos de la UE para sistemas de IA (la propia base de datos se establece con arreglo al artículo 71). El registro recoge la descripción del sistema, la finalidad prevista, el nivel de riesgo y tus datos de contacto.

Vigilancia poscomercialización — artículo 72. Debes supervisar activamente el rendimiento del sistema en el mundo real tras el despliegue y retroalimentar las conclusiones al sistema de gestión de riesgos. Para las aplicaciones de empleo o de crédito, eso significa hacer seguimiento de la calidad de los resultados y de los resultados adversos, no solo de las métricas de disponibilidad.

Notificación de incidentes graves — artículo 73. Si el sistema causa o contribuye a un incidente grave — fallecimiento (notificar en un plazo de diez días), infracción generalizada o perturbación de infraestructuras críticas (dos días), u otros incidentes graves (quince días) —, notificas a la autoridad de vigilancia del mercado del Estado miembro en el que se produjo el incidente.

Cuándo tu aplicación es de riesgo limitado: artículo 50

Si construyes un chatbot sobre Azure OpenAI, o cualquier sistema que interactúe directamente con personas físicas y pueda confundirse de forma verosímil con un humano, se aplican las obligaciones de transparencia del artículo 50. Los usuarios deben ser informados de que están interactuando con un sistema de IA de forma clara, oportuna e inteligible. Si el sistema genera audio, vídeo, imágenes o texto sintéticos destinados a su difusión pública, debe etiquetarse como generado por IA.

El artículo 50 se aplica a partir del 2 de agosto de 2026 — no aplazado por el Ómnibus Digital. Ya está cerca.

La obligación de transparencia recae sobre quien pone el sistema en manos de los usuarios. Si eres tú, debes incorporar el mecanismo de notificación en la interfaz, no apoyarse en una cláusula de exención genérica de Azure sepultada en las condiciones del servicio.

Los chatbots que además desempeñan una función del anexo III — un asistente virtual que, en segundo plano, califica la solvencia de un usuario — soportan tanto las obligaciones del artículo 50 como el conjunto completo de obligaciones de alto riesgo.

Las propias obligaciones de Azure y la capa GPAI

Microsoft y OpenAI, como proveedores del modelo GPAI subyacente con arreglo al artículo 53, deben mantener la documentación técnica del modelo, informar a los proveedores posteriores sobre las capacidades y limitaciones, publicar una política de derechos de autor y facilitar un resumen de los datos de entrenamiento. Si GPT-4 se designa como modelo GPAI con riesgo sistémico con arreglo al artículo 51, OpenAI también debe satisfacer las obligaciones más exigentes del artículo 55 — evaluaciones de modelos, pruebas adversarias, notificación de incidentes a la Oficina de IA, medidas de ciberseguridad.

Nada de eso transfiere tus obligaciones de cumplimiento a Microsoft. La capa GPAI y tu capa de aplicación se regulan por separado. Las certificaciones de cumplimiento de Azure AI de Microsoft cubren las obligaciones de Microsoft como proveedor de infraestructura en la nube y de GPAI; no constituyen una evaluación de la conformidad del sistema que has construido encima.

La residencia de los datos y el Límite de Datos de la UE de Azure (Azure EU Data Boundary) importan para el cumplimiento del RGPD y, por derivación, para los requisitos de gobernanza de datos de la Ley de IA de la UE con arreglo al artículo 10. El compromiso del Límite de Datos de la UE de Azure trata los datos de los clientes de la UE dentro de la UE — relevante al documentar por dónde fluyen los datos de entrenamiento o de inferencia. No obstante, confirma los servicios concretos incluidos; no todas las regiones o capacidades de Azure OpenAI están cubiertas en todas las configuraciones contractuales.

Uso interno de productividad: el caso de riesgo mínimo

No todo lo que se construye sobre Azure OpenAI es de alto riesgo, ni siquiera de riesgo limitado. Un sistema que ayuda a tus desarrolladores a escribir código, resume las transcripciones de reuniones internas o redacta versiones iniciales de informes internos — y que opera únicamente dentro de tu organización sin resultados de consecuencias que afecten a terceros — es probablemente de riesgo mínimo. No se aplican obligaciones obligatorias con arreglo a la Ley de IA de la UE.

La advertencia: la ampliación gradual del alcance. Si una herramienta interna de redacción empieza a producir decisiones orientadas al cliente, o si los resultados se introducen en un proceso de crédito o de RR. HH. sin intervención humana, el nivel de riesgo cambia y tu clasificación debe revisarse.

Cómo ayuda Confir

La cuestión de la clasificación — en qué nivel está este sistema y en qué papel estamos — es donde el trabajo de cumplimiento o bien empieza correctamente o bien va mal. El motor de clasificación basado en reglas de Confir te guía a través de los escenarios del anexo III y el filtro del artículo 6, apartado 3, deriva tu papel (proveedor o responsable del despliegue) y traza el conjunto exacto de obligaciones que se deriva.

Para cada sistema basado en Azure OpenAI que registres, Confir genera el paquete de documentación técnica del artículo 11 / anexo IV y la declaración de conformidad del artículo 47, ejecuta la evaluación de impacto relativa a los derechos fundamentales del artículo 27 cuando se exige, y mantiene un registro de auditoría con marca de tiempo. La clasificación, la delimitación del alcance y las conclusiones son deterministas y reproducibles — la misma admisión produce la misma conclusión, y la regla que se activó es legible por humanos. Eso importa para un documento de cumplimiento que puede necesitar resistir una inspección regulatoria.

Registra el sistema, clasifícalo y deja que la evaluación estructurada identifique las lagunas. Sin necesidad de consultor.

Preguntas frecuentes

¿La certificación de cumplimiento de Azure AI de Microsoft cubre mi aplicación?

No. Las certificaciones de cumplimiento de Microsoft — SOC 2, ISO 27001 y similares — cubren la infraestructura de Azure y la capa del modelo GPAI. No constituyen una evaluación de la conformidad del sistema que has construido sobre Azure OpenAI. Con arreglo a la Ley de IA de la UE, eres el proveedor de tu aplicación; el proveedor soporta la obligación de evaluación con arreglo al artículo 43. La documentación de Microsoft es una aportación útil a tu documentación técnica del artículo 11, pero no la sustituye.

¿Es de alto riesgo un despliegue interno de Azure OpenAI?

Depende de la función, no del modo de despliegue. Una herramienta interna que resume documentos o genera texto en borrador para tareas sin consecuencias es probablemente de riesgo mínimo. Si el sistema interno produce decisiones o recomendaciones que afectan a los empleados — evaluación del rendimiento, asignación de tareas, supervisión —, entra dentro del punto 4 del anexo III (empleo y gestión de los trabajadores) y es de alto riesgo. La distinción interno/externo no es el eje de la clasificación; lo son la función y las personas afectadas.

¿Cuál es el plazo para las aplicaciones de Azure OpenAI de alto riesgo?

Para los sistemas autónomos del anexo III: 2 de diciembre de 2027, aplazado respecto de la fecha original de agosto de 2026 en virtud del Ómnibus Digital (Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026). Para los sistemas integrados como componentes de seguridad en productos del anexo I (productos sanitarios, máquinas, aviación civil): 2 de agosto de 2028. Las obligaciones de transparencia del artículo 50 para los chatbots y el etiquetado de contenido sintético se aplican a partir del 2 de agosto de 2026 y no se aplazaron.

Si utilizamos Azure OpenAI para construir una funcionalidad para nuestro producto de SaaS, ¿somos proveedores?

Casi con seguridad, sí. Cuando introduces una funcionalidad en el mercado con tu propio nombre o marca — aunque el modelo subyacente sea de Azure —, eres el proveedor de esa funcionalidad a los efectos de la Ley de IA de la UE (artículo 3; artículo 16). Las obligaciones de los artículos 9 a 15, 43, 47, 49 y 72 a 73 recaen sobre ti, no sobre Microsoft. Tus clientes de SaaS posteriores que utilicen esa funcionalidad son los responsables del despliegue y soportan las obligaciones del responsable del despliegue con arreglo al artículo 26.

¿Qué ocurre si modificamos sustancialmente una integración de Azure OpenAI que licenciamos de un tercero?

Con arreglo al artículo 25, la modificación sustancial de un sistema de IA de alto riesgo, o un cambio de finalidad prevista que lo lleve a una nueva categoría del anexo III, convierte a quien lo modifica en el proveedor del sistema modificado. Heredas el conjunto completo de obligaciones del proveedor a partir de ese momento. Lo que cuenta como «modificación sustancial» se define en el artículo 3, punto 23: un cambio que afecta a la conformidad con los requisitos aplicables, o un cambio de finalidad prevista. Reutilizar una integración de Azure OpenAI de uso general para calificar solicitudes de crédito cumpliría esa condición.

¿Cuáles son las multas por incumplimiento?

Con arreglo al artículo 99, apartado 4, el incumplimiento de las obligaciones del proveedor para los sistemas de alto riesgo (artículos 9 a 15, 16, etc.) puede dar lugar a multas de hasta 15 millones de euros o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor. Para las pymes y las empresas emergentes, la multa se limita al menor de los dos importes, el del porcentaje y el de la cantidad fija — una protección de proporcionalidad legal con arreglo al artículo 99, apartado 6. Las infracciones de las prácticas prohibidas del artículo 5 conllevan el nivel más alto, de hasta 35 millones de euros o el 7 %.

¿Tenemos que preocuparnos nosotros mismos por las obligaciones de GPAI?

Las obligaciones del artículo 53 para los proveedores de GPAI — documentación técnica, información para los agentes posteriores, política de derechos de autor, resumen de los datos de entrenamiento — recaen sobre OpenAI y Microsoft, no sobre ti. Tu aplicación está construida sobre su modelo; tú no eres el proveedor del modelo. No obstante, si ajustas un modelo GPAI de forma significativa y lo introduces en el mercado, puedes pasar a ser proveedor de GPAI por derecho propio para ese modelo derivado. Para la mayoría de las integraciones de Azure OpenAI que utilizan la API sin ajuste fino, las obligaciones de GPAI siguen recayendo sobre OpenAI/Microsoft.

Guías relacionadas

• guía de cumplimiento para empresas
• requisitos de alto riesgo del artículo 8
• vías de clasificación de riesgo del artículo 6
• marco de implementación paso a paso
• registro en la base de datos del artículo 49
• lista de comprobación de obligaciones del proveedor
• vías de clasificación del artículo 6
• evaluación de IA de prestaciones sociales del anexo III
• sistema de gestión de riesgos del artículo 9
• lista de comprobación de cumplimiento de los artículos 6 a 29