La API de OpenAI y la Ley de IA de la UE: ¿quién es el proveedor y qué debes hacer?

La Ley de IA de la UE no menciona a OpenAI por su nombre. Plantea una pregunta distinta: ¿qué hace este sistema de IA y quién lo introduce en el mercado? Si integras la API de OpenAI para construir un producto o una funcionalidad que lanzas a los usuarios, eres casi con seguridad el proveedor del sistema de IA resultante con arreglo al artículo 16 del Reglamento (UE) 2024/1689 — no un mero espectador que se beneficia del cumplimiento de otro. Tu clasificación, y por tanto tu conjunto de obligaciones, depende enteramente de lo que tu sistema haga con esa API.

Esta guía explica cómo determinar tu papel, cómo clasificar tu sistema según el uso, qué significa la capa del modelo GPAI para ti como desarrollador posterior, y qué puede hacer Confir para abreviar el trabajo de documentación.

OpenAI es el proveedor de GPAI. Tú eres probablemente el proveedor del sistema de IA.

OpenAI tiene obligaciones de modelo GPAI con arreglo al artículo 53. Estas incluyen: documentación técnica conforme al anexo XI, información para los agentes posteriores conforme al anexo XII (que tú, cliente de la API, recibes), una política de derechos de autor y un resumen de los datos de entrenamiento. Si GPT-4o supera el umbral de 10²⁵ FLOP que activa la clasificación de riesgo sistémico con arreglo al artículo 51, OpenAI también debe realizar evaluaciones de modelos y pruebas adversarias con arreglo al artículo 55. Estas son obligaciones de OpenAI. Tú no las heredas.

Lo que sí heredas es la condición de proveedor del artículo 16 para cualquier sistema de IA que construyas encima. La definición de «proveedor» de la Ley (artículo 3, punto 3) comprende a cualquier persona física o jurídica que desarrolle un sistema de IA o que mande desarrollarlo y lo introduzca en el mercado o lo ponga en servicio con su propio nombre o marca. Si lanzas una herramienta de cribado de currículos, un asistente de evaluación crediticia, un chatbot orientado al cliente o un producto interno de flujo de trabajo bajo el nombre de tu empresa, eres el proveedor de ese sistema. OpenAI es un proveedor de componentes (el proveedor del modelo GPAI), no el proveedor de tu producto.

El artículo 25 lo deja explícito: si pones tu nombre en un sistema, lo modificas sustancialmente o modificas su finalidad prevista, las obligaciones del proveedor se te transfieren. Envolver GPT-4o en una interfaz de producto y venderlo es exactamente eso.

Una excepción: si utilizas la API de OpenAI exclusivamente para operaciones internas — por ejemplo, una herramienta de resumen de textos de la trastienda utilizada solo por tu propio personal, no introducida en el mercado —, tu papel es el de responsable del despliegue con arreglo al artículo 26. Las obligaciones del responsable del despliegue son notablemente más ligeras.

Primer paso: clasificar según lo que hace el sistema

La Ley ordena los sistemas de IA en cuatro niveles. El nivel lo determina el uso del sistema, no el modelo subyacente.

Prohibido (artículo 5) — en vigor desde el 2 de febrero de 2025

Algunas aplicaciones están prohibidas de plano con independencia de la infraestructura tecnológica. Construir sobre la API de OpenAI no te exime. Un sistema que utiliza el reconocimiento de emociones para inferir los estados emocionales de los trabajadores en el lugar de trabajo o en la educación entra dentro de la prohibición del artículo 5, apartado 1, letra f), salvo por motivos médicos o de seguridad. Un sistema que puntúa el comportamiento social de las personas para determinar el acceso a servicios entra dentro del artículo 5, apartado 1, letra c). Un sistema que explota las vulnerabilidades de grupos específicos para distorsionar su comportamiento entra dentro del artículo 5, apartado 1, letra b).

Estas prohibiciones no son aspiracionales — están en vigor. Si tu producto opera actualmente en uno de estos ámbitos, necesitas asesoramiento jurídico antes de continuar, no un marco de cumplimiento.

Alto riesgo (artículo 6 + anexo III) — se aplica a partir del 2 de diciembre de 2027

Un sistema de IA es de alto riesgo si entra dentro de uno de los ocho epígrafes del anexo III y no reúne las condiciones para la exención del artículo 6, apartado 3. Los sistemas autónomos del anexo III deben cumplir antes del 2 de diciembre de 2027 en virtud del Ómnibus Digital (Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026) (la fecha original del 2 de agosto de 2026 se ha aplazado). Para la IA integrada en productos regulados (anexo I), la fecha es el 2 de agosto de 2028.

Los ámbitos del anexo III más habitualmente implicados al construir sobre la API de OpenAI:

• Empleo y gestión de los trabajadores (anexo III, punto 4): cribado de selección de personal, preselección de currículos, evaluación del rendimiento, asignación de tareas y supervisión. Una empresa de tecnología de RR. HH. de 40 personas que vende un producto de puntuación de currículos construido sobre GPT-4o está plenamente en el punto 4, letra a). Como proveedor, soporta el conjunto completo de obligaciones: sistema de gestión de riesgos (artículo 9), gobernanza de datos (artículo 10), documentación técnica conforme al anexo IV (artículo 11), conservación de registros (artículo 12), instrucciones de transparencia para los responsables del despliegue (artículo 13), supervisión humana desde el diseño (artículo 14), precisión y solidez (artículo 15), sistema de gestión de la calidad (artículo 17), evaluación de la conformidad (artículo 43), declaración UE de conformidad (artículo 47), marcado CE (artículo 48) y registro en la base de datos de la UE (artículo 49).
• Acceso a crédito y seguros (anexo III, punto 5): la evaluación de la solvencia y la calificación crediticia entran dentro del punto 5, letra b) — la detección de fraude queda excluida. El riesgo y la fijación de precios de los seguros de vida y de salud entran dentro del punto 5, letra c). Una fintech que canaliza los resultados de la API de OpenAI hacia un flujo de trabajo de decisión de suscripción es un proveedor de alto riesgo. Las herramientas de roboasesoramiento y de prevención del blanqueo de capitales no son, en general, de alto riesgo por este motivo.
• Educación y formación profesional (anexo III, punto 3): sistemas que determinan la admisión a instituciones educativas, evalúan el rendimiento de los estudiantes o supervisan los exámenes.
• Biometría (anexo III, punto 1): sistemas de categorización biométrica y de reconocimiento de emociones (fuera de las prohibiciones del artículo 5), e identificación biométrica remota dentro de las estrechas excepciones para la garantía del cumplimiento del Derecho.

El filtro del artículo 6, apartado 3: un sistema que entra dentro de un ámbito del anexo III no es automáticamente de alto riesgo. Puedes documentar que no plantea un riesgo significativo de perjuicio — por ejemplo, porque desempeña una tarea procedimental limitada, mejora una actividad humana previamente realizada, detecta patrones de toma de decisiones sin sustituir ni influir en la evaluación humana, o realiza únicamente un trabajo preparatorio. El filtro exige solo una de estas condiciones, no las cuatro. Pero todo sistema que elabore perfiles de personas físicas es siempre de alto riesgo y no puede acogerse a la exención. Los proveedores que se acogen a la exención del artículo 6, apartado 3, deben documentar la evaluación y, aun así, registrar el sistema con arreglo al artículo 49.

Riesgo limitado (artículo 50) — se aplica a partir del 2 de agosto de 2026

Si tu sistema no alcanza el alto riesgo pero incluye una interfaz de chatbot, debes divulgar a los usuarios que están interactuando con un sistema de IA (artículo 50, apartado 1). Si genera audio, imagen, vídeo o texto sintéticos destinados a confundirse con material real (ultrafalsificaciones), se aplican las obligaciones de etiquetado (artículo 50, apartado 4). Los sistemas de reconocimiento de emociones que no entren dentro de la prohibición del artículo 5 deben divulgar su funcionamiento con arreglo al artículo 50, apartado 2.

Un chatbot de atención al cliente de uso general construido sobre la API de OpenAI — uno que no toma decisiones de consecuencias — es probablemente de riesgo limitado. El requisito de transparencia es la obligación, y se aplica a partir del 2 de agosto de 2026.

Riesgo mínimo

Las herramientas internas, los asistentes generales de productividad y las funcionalidades de generación de contenido que no tocan casos de uso del anexo III y no implican interacción mediante chatbot ni medios sintéticos son de riesgo mínimo. No se aplican obligaciones obligatorias.

Qué significa para ti la información para los agentes posteriores del anexo XII

OpenAI, como proveedor del modelo GPAI con arreglo al artículo 53, debe facilitar a los desarrolladores posteriores el paquete de información del anexo XII. Esto incluye: las instrucciones de uso, las capacidades y limitaciones del sistema, los casos de uso previstos e información suficiente para que cumplas tus propias obligaciones de proveedor. En términos prácticos, se trata de las fichas de modelo, las políticas de uso y la documentación del sistema de OpenAI.

Debes incorporar la documentación del anexo XII que recibes de OpenAI a tu propio expediente de documentación técnica del artículo 11. Para los sistemas de alto riesgo, el anexo IV especifica exactamente lo que debe contener ese expediente: una descripción general del sistema, una descripción de los elementos y del proceso de desarrollo, información sobre los datos utilizados, planes de vigilancia y mantenimiento, y documentación de la gestión de riesgos. La documentación técnica debe conservarse durante diez años después de que el sistema se introduzca en el mercado (artículo 18).

Cambios de papel con arreglo al artículo 25

Tres situaciones convierten a un responsable del despliegue en proveedor — y las obligaciones del proveedor se aplican automáticamente:

1. Pones tu nombre o marca en un sistema de IA desarrollado originalmente por un tercero (incluido un sistema basado en OpenAI que no hayas modificado sustancialmente).
2. Modificas sustancialmente un sistema de IA de alto riesgo.
3. Introduces un sistema de IA de alto riesgo en el mercado o lo pones en servicio con tu propio nombre.

La mayoría de las empresas de SaaS que construyen productos comerciales sobre la API de OpenAI activan la situación 1 o la 3. Si vendes o licencias a otras empresas una funcionalidad de producto que incorpora la API de OpenAI, eres proveedor de un sistema de IA posterior, y la clasificación de riesgo de ese sistema — no del modelo de OpenAI — determina tus obligaciones.

Datos, RGPD y tratamiento de datos por la API

Utilizar la API de OpenAI para el tratamiento empresarial implica datos personales en la mayoría de los casos de uso serios. Los requisitos del RGPD se aplican en paralelo: necesitas una base jurídica para el tratamiento, contratos de tratamiento de datos con OpenAI y una evaluación de impacto relativa a la protección de datos (artículo 35 del RGPD) si tratas datos de categorías especiales o toma decisiones exclusivamente automatizadas (artículo 22 del RGPD).

Sobre la residencia de los datos: OpenAI ofrece una opción de residencia de datos en la UE para los clientes de la API (datos tratados en la UE, no enviados a servidores estadounidenses). Para el cumplimiento de alto riesgo de la Ley de IA — en particular los requisitos de gobernanza de datos del artículo 10 —, la residencia en la UE también simplifica demostrar que los datos de entrenamiento y validación cumplen los requisitos de la Ley. Si tu sistema es de alto riesgo, la obligación del artículo 10 recae sobre los datos de entrenamiento y validación de tu sistema, no sobre los pesos del modelo de OpenAI.

Por defecto, OpenAI no utiliza los datos enviados a través de la API para entrenar o mejorar sus modelos (con sujeción a las condiciones de tu contrato empresarial). Confírmalo con tu contrato. Las obligaciones de calidad de los datos del artículo 10 son tuyas en cualquier caso.

Qué te exige realmente como proveedor el conjunto de obligaciones de alto riesgo

Si tu sistema es de alto riesgo, te incumben todas las siguientes antes de introducirlo en el mercado:

Sistema de gestión de riesgos (artículo 9): un proceso continuo e iterativo — no una auditoría puntual. Debes identificar los riesgos previsibles, evaluar su probabilidad y gravedad, aplicar medidas de mitigación y actualizar la evaluación cada vez que el sistema o su contexto cambien. Para un sistema basado en la API de OpenAI, esto significa documentar el riesgo de alucinación, el riesgo de sesgo en los resultados, la exposición a la inyección de instrucciones y la dependencia de una API de un tercero que no controlas.

Datos y gobernanza de datos (artículo 10): los conjuntos de datos de entrenamiento, validación y prueba deben ser pertinentes, representativos, libres de errores y completos en la medida de lo posible. Si ajustas el modelo con tus propios datos, esa gobernanza de datos recae sobre ti. Si utilizas el modelo base sin ajuste fino, documenta las limitaciones conocidas del modelo de OpenAI (a partir del anexo XII) y cómo las mitiga tu sistema.

Documentación técnica (artículo 11 + anexo IV): el expediente de documentación debe existir antes de la introducción en el mercado. Cubre la descripción del sistema, las decisiones de diseño, la finalidad prevista, las limitaciones conocidas, los resultados de las pruebas, los registros de gestión de riesgos y los planes de vigilancia poscomercialización. Consérvalo durante diez años (artículo 18).

Transparencia e instrucciones para los responsables del despliegue (artículo 13): si vendes tu sistema de IA de alto riesgo a otras empresas (B2B), debes facilitar instrucciones de uso claras, información sobre el rendimiento del sistema y qué supervisión humana se exige. Esto es distinto del requisito de transparencia hacia el usuario final del artículo 50.

Supervisión humana (artículo 14): el sistema debe diseñarse de modo que una persona física pueda supervisarlo eficazmente, comprender sus resultados y anularlo o detenerlo. Es un requisito de diseño, no solo una política.

Evaluación de la conformidad (artículo 43): antes de introducir un sistema de alto riesgo en el mercado, debes evaluar su conformidad con los requisitos de la Ley. Para la mayoría de las categorías del anexo III, se trata de una autoevaluación interna con arreglo al anexo VI. Para el punto 1 del anexo III (biometría), por lo general se exige la vía del organismo notificado del anexo VII.

Registro (artículo 49): registra el sistema en la base de datos de la UE para sistemas de IA de alto riesgo establecida con arreglo al artículo 71, antes de la introducción en el mercado.

Vigilancia poscomercialización (artículo 72): debe existir un plan de vigilancia desde el primer día. Haz seguimiento de los datos de rendimiento, recopile comentarios de los usuarios y actualice el sistema de gestión de riesgos en consecuencia.

Notificación de incidentes graves (artículo 73): si se produce un incidente grave — definido en el artículo 3, apartado 49 —, notifica a la autoridad competente del Estado miembro afectado en un plazo de 15 días tras tener conocimiento (o 2 días si hay una infracción generalizada o un riesgo grave para infraestructuras críticas; 10 días si se ha producido un fallecimiento).

Cómo ayuda Confir

El motor de clasificación y documentación de Confir es basado en reglas y determinista — las mismas entradas producen los mismos resultados, mostrando en lenguaje sencillo la regla que se activa. Sin alucinaciones, sin conjeturas, defendible ante una auditoría desde el primer día.

Para un despliegue de la API de OpenAI, Confir hace tres cosas: registra el sistema en tu inventario de IA, lo clasifica mediante escenarios en lenguaje sencillo frente a los artículos 5 y 6 con la lógica completa del anexo III para derivar el nivel de riesgo y tu papel (proveedor con arreglo al artículo 16 o responsable del despliegue con arreglo al artículo 26), y a continuación impulsa una evaluación estructurada a través de cuatro áreas de cumplimiento — AIRC (clasificación de riesgo y conformidad: artículos 5, 6, 43, 50), AITR (datos y robustez técnica: artículos 10, 11, 15), AITO (transparencia y supervisión humana: artículos 13, 14, 27, 50) y AIGM (gobernanza y vigilancia poscomercialización: artículos 9, 72, 73).

El resultado es un paquete de documentación técnica del anexo IV listo para imprimir, una declaración UE de conformidad del artículo 47 y — cuando se exige — una evaluación de impacto relativa a los derechos fundamentales del artículo 27. Sin consultores, sin proyecto de implementación.

Preguntas frecuentes

¿Integrar la API de OpenAI me convierte en proveedor de GPAI con arreglo a la Ley de IA de la UE?

No. Un proveedor de GPAI es la entidad que entrena y pone a disposición un modelo de IA de uso general — en este caso, OpenAI. Cuando integras la API para construir un producto, pasas a ser el proveedor del sistema de IA posterior con arreglo al artículo 16. Las obligaciones del artículo 53 de OpenAI (documentación técnica del anexo XI, información para los agentes posteriores del anexo XII, política de derechos de autor, resumen de los datos de entrenamiento) siguen recayendo sobre OpenAI. Recibes la información para los agentes posteriores del anexo XII como parte de tu acceso a la API y la incorporas a tu propia documentación técnica del artículo 11.

Mi producto utiliza GPT-4o para un chatbot orientado al cliente. ¿Es de alto riesgo?

Probablemente no, pero depende de lo que haga el chatbot. Un chatbot general de atención o de información es de riesgo limitado con arreglo al artículo 50 — debes informar a los usuarios de que están hablando con un sistema de IA. Esa obligación se aplica a partir del 2 de agosto de 2026. Si el chatbot toma o influye sustancialmente en decisiones de consecuencias (admisibilidad crediticia, derecho a prestaciones, preselección en selección de personal), el caso de uso necesita un análisis completo del anexo III. La clasificación sigue a la función, no al nombre del modelo.

¿Cuál es el plazo de cumplimiento de alto riesgo si construyo sobre la API de OpenAI?

Los sistemas de IA de alto riesgo autónomos enumerados en el anexo III deben cumplir antes del 2 de diciembre de 2027, en virtud del Ómnibus Digital (Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026) (la fecha original de agosto de 2026 se ha aplazado). Si tu sistema es un componente de seguridad de un producto regulado del anexo I, la fecha es el 2 de agosto de 2028. El requisito de transparencia de riesgo limitado del artículo 50 para los chatbots y el contenido sintético se aplica a partir del 2 de agosto de 2026 — esa fecha no se ha movido.

¿Cuáles son las sanciones si no cumplo?

Las multas del artículo 99 vienen en tres niveles. Infringir las prohibiciones del artículo 5: hasta 35 millones de euros o el 7 % del volumen de negocios anual mundial total, si esta última cifra es mayor. El incumplimiento de la mayoría de las demás obligaciones — incluidos los deberes del proveedor y del responsable del despliegue, los requisitos de alto riesgo y la transparencia del artículo 50 —: hasta 15 millones de euros o el 3 % del volumen de negocios anual mundial. Facilitar información incorrecta o engañosa a las autoridades o a los organismos notificados: hasta 7,5 millones de euros o el 1 % del volumen de negocios anual mundial. Para las empresas por debajo del umbral de pyme, el artículo 99, apartado 6, limita las multas al menor de los dos importes, el de la cantidad fija o el del porcentaje — una verdadera protección de proporcionalidad, pero no un salvoconducto.

¿Cambian las obligaciones del RGPD cuando utilizo la API de OpenAI?

El RGPD se aplica junto con la Ley de IA de la UE, no en su lugar. Si tratas datos personales a través de la API, necesitas una base jurídica, un contrato de tratamiento de datos con OpenAI y — para el tratamiento de alto riesgo o de categorías especiales — una evaluación de impacto relativa a la protección de datos con arreglo al artículo 35 del RGPD. El artículo 22 del RGPD también limita las decisiones exclusivamente automatizadas que produzcan efectos jurídicos o significativos de modo similar sobre las personas; si tu sistema toma tales decisiones sin revisión humana, necesitas o bien el consentimiento explícito o bien una de las excepciones del artículo 22 del RGPD. Los dos regímenes son complementarios, y un sistema de alto riesgo de la Ley de IA que trate datos personales activa obligaciones con arreglo a ambos.

Utilizo la API de OpenAI solo internamente, no en un producto que vendo. ¿Se aplica la Ley?

El uso exclusivamente interno significa que eres un responsable del despliegue con arreglo al artículo 26, no un proveedor. Las obligaciones del responsable del despliegue son más ligeras: utilizar el sistema conforme a las instrucciones del proveedor, supervisar el rendimiento, conservar registros, garantizar la supervisión humana cuando se exija y — si eres un organismo público que despliega un sistema de alto riesgo o un responsable del despliegue de determinados sistemas de solvencia o de seguros — realizar una evaluación de impacto relativa a los derechos fundamentales con arreglo al artículo 27. Si modificas sustancialmente el sistema o pones tu nombre en él, el artículo 25 te traslada a la condición de proveedor.

¿Cómo se relaciona la opción de residencia de datos en la UE de OpenAI con la Ley de IA de la UE?

Son marcos distintos pero vinculados en la práctica. La residencia de datos en la UE significa que OpenAI trata el tráfico de tu API dentro de la infraestructura de la UE, lo que simplifica el cumplimiento del RGPD en materia de transferencias de datos. Para la Ley de IA de la UE, lo que importa es la gobernanza de datos del artículo 10 de tu sistema: los datos de entrenamiento, validación y prueba del sistema que estás construyendo deben cumplir los requisitos de calidad y gobernanza de la Ley. Si ajustas el modelo o construyes un sistema aumentado por recuperación sobre datos residentes en la UE, documentar esa gobernanza de datos resulta sencillo. La información para los agentes posteriores del anexo XII de OpenAI también especificará el alcance de los datos de entrenamiento del modelo base, que incorporas a tu propia documentación técnica.

Guías relacionadas

• exenciones de código abierto con arreglo al artículo 6, apartado 1
• requisitos de cumplimiento de alto riesgo del artículo 8
• obligaciones del responsable del despliegue por papel en el mercado
• marco de cumplimiento para SaaS
• requisitos del responsable del despliegue del artículo 26
• obligaciones de transparencia del artículo 13
• herramientas de clasificación de alto riesgo frente a uso general
• evaluación de IA de prestaciones sociales del anexo III
• lista de comprobación de obligaciones del proveedor
• definiciones clave del artículo 3
• marcos sistemáticos de clasificación de riesgo