El 90 % de las organizaciones que usan IA son operadores que integran modelos de terceros — OpenAI, Anthropic, Azure AI o herramientas de IA como SaaS. Comprenda sus obligaciones: qué debe darle el proveedor, qué debe hacer usted y cuándo se convierte en proveedor.
La Realidad de la IA de Terceros: La Mayoría de las Organizaciones Son Operadores
La mayoría de las organizaciones europeas que usan IA no son OpenAI, ni Mistral, ni un laboratorio de investigación. Integran modelos existentes — a través de una API, una plataforma SaaS, un componente de Azure AI o un plugin de herramienta empresarial. Salesforce Einstein, Copilot para Microsoft 365, un chatbot de RRHH impulsado por un modelo de lenguaje de gran tamaño, una solución de puntuación crediticia adquirida a un proveedor especialista: en todos estos casos, usted es un operador de un sistema de IA construido por otra persona.
Esta posición la ocupa la gran mayoría de las organizaciones afectadas por el Reglamento de IA de la UE. Conlleva obligaciones precisas — distintas de las del proveedor, pero no despreciables. También puede evolucionar: si modifica el sistema o lo revende, su estatus jurídico cambia.
Comprender su posición en la cadena de valor de la IA es el primer paso en cualquier esfuerzo de cumplimiento.
Sus Obligaciones como Operador
Las obligaciones del operador difieren dependiendo del nivel de riesgo del sistema de IA que está usando.
Para Sistemas de IA de Alto Riesgo (Anexo III)
Si despliega un sistema de IA de terceros que se califica como de alto riesgo (evaluación de la solvencia crediticia, identificación biométrica, cribado de contratación, gestión de infraestructuras críticas, etc.), sus obligaciones en virtud del Art. 26 son:
1. Siga las instrucciones de uso Use el sistema solo para su fin previsto y de acuerdo con las instrucciones que el proveedor está obligado a suministrar. Usar un sistema de IA de alto riesgo fuera de su ámbito validado es un incumplimiento incluso si solo es operador.
2. Asigne supervisión humana Designe a una persona física con la competencia, autoridad y recursos para realizar una supervisión humana significativa sobre los resultados del sistema de IA. Esta persona debe ser capaz de comprender lo que hace el sistema, detectar anomalías y anular o detener el sistema cuando sea necesario.
3. Garantice la calidad de los datos de entrada Garantice que los datos que introduce en el sistema sean relevantes, suficientemente representativos y apropiados para el fin previsto en su contexto específico de despliegue. Un sistema validado en una población puede funcionar de manera diferente en la suya — ese es su riesgo a gestionar.
4. Supervise la operación y detecte anomalías Supervise activamente la operación del sistema en busca de anomalías, resultados inesperados o degradación del rendimiento. Esto no es responsabilidad del proveedor en el despliegue — es la suya.
5. Retenga los registros Active y retenga los registros automáticos producidos por el sistema durante el período requerido por el Reglamento (y cualquier regulación sectorial que pueda aplicarse). No desactive el registro para ahorrar en almacenamiento.
6. Notifique los incidentes graves Si tiene conocimiento de un incidente grave o mal funcionamiento — uno que causó o podría causar muerte, daño grave, violaciones de derechos fundamentales o daños materiales significativos — notifique al proveedor sin demora injustificada. En algunos casos (particularmente cuando el despliegue implica servicios de cara al público o actividades adyacentes a la aplicación de la ley), también puede ser necesaria la notificación directa a la autoridad nacional de vigilancia del mercado.
7. Evaluación de impacto sobre los derechos fundamentales (organismos públicos) Si es un organismo público o una entidad privada que despliega sistemas de IA en áreas que probablemente afecten a los derechos fundamentales (atención sanitaria, servicios sociales, educación, aplicación de la ley), debe realizar una Evaluación de Impacto sobre los Derechos Fundamentales antes del despliegue (Art. 27).
Para Sistemas de IA de Solo Transparencia (Art. 50)
Si despliega un chatbot, un sistema de contenido generado por IA o una herramienta de reconocimiento de emociones que no es de alto riesgo pero está sujeto a las obligaciones de transparencia del Art. 50, debe:
- Informar a los usuarios que están interactuando con un sistema de IA (Art. 50(1))
- Garantizar que el contenido generado por IA esté marcado técnicamente (Art. 50(4)) cuando proceda
- Informar a las personas expuestas cuando se use el reconocimiento de emociones o la categorización biométrica (Art. 50(2)–(3))
Estas obligaciones se aplican incluso cuando se usa una API o herramienta SaaS de terceros. El proveedor es responsable de incorporar la capacidad técnica; usted es responsable de activarla y garantizar que la divulgación llegue efectivamente a los usuarios.
Para Sistemas de IA de Riesgo Mínimo
No hay obligaciones legales específicas en virtud del Reglamento de IA. Se aplican códigos de conducta voluntarios. Las buenas prácticas de gobernanza siguen recomendando documentación básica de los sistemas de IA en uso y revisión periódica de su rendimiento.
Qué Exigir a Su Proveedor de IA de Terceros
Su capacidad para cumplir las obligaciones del operador depende directamente de lo que le dé el proveedor. El Reglamento de IA exige a los proveedores de sistemas de IA de alto riesgo que suministren información específica — y los proveedores de modelos GPAI tienen obligaciones de documentación paralelas. Use esta lista de verificación al adquirir IA de terceros:
Para Cualquier Sistema de IA
- Descripción del sistema: ¿Qué hace el sistema, qué entradas toma, qué salidas produce y qué decisiones puede influir?
- Fin previsto: ¿Para qué casos de uso ha sido diseñado, validado y aprobado el sistema con exactitud?
- Limitaciones conocidas: ¿En qué condiciones funciona mal el sistema? ¿Qué poblaciones, idiomas o tipos de datos están fuera de su ámbito validado?
- Instrucciones de uso: El conjunto completo de instrucciones que el proveedor está obligado a suministrar en virtud del Art. 13 para los sistemas de alto riesgo
Específicamente para Sistemas de Alto Riesgo
- Declaración de Conformidad o resumen de los resultados de la evaluación de la conformidad
- Documentación de gestión de riesgos — ¿qué riesgos se identificaron y cómo se mitigaron?
- Resultados de pruebas de sesgo y equidad — ¿qué características protegidas se probaron, qué métricas se utilizaron y qué resultados se encontraron?
- Métricas de rendimiento — exactitud, tasas de falsos positivos/negativos y rendimiento desagregado por grupos demográficos pertinentes
- Capacidad de registro — confirmación de que el sistema genera los registros requeridos por el Art. 12 e instrucciones para acceder y retenerlos
- Proceso de notificación de incidentes — a quién contactar, en qué plazo y por qué canal cuando ocurra un incidente grave
- Política de actualización — ¿cómo le notifica el proveedor de las actualizaciones materiales y qué revalidación se requiere después de las actualizaciones?
Para Modelos GPAI (APIs y Acceso a Modelos de Base)
- Tarjeta de modelo o resumen técnico — capacidades, limitaciones, resumen de los datos de entrenamiento, resultados de la evaluación
- Declaración de cumplimiento de derechos de autor — cómo aborda el proveedor la legislación de derechos de autor para los datos de entrenamiento y los resultados
- Política de uso aceptable — ¿qué casos de uso prohíbe el proveedor y qué ocurre si los incumple?
- Términos de procesamiento de datos — ¿cómo gestiona el proveedor sus datos de entrada? ¿Se usan para entrenamiento adicional?
Cuándo Se Convierte en Proveedor
El Art. 25 del Reglamento de IA es crucial para los usuarios de IA de terceros: define cuándo un operador pasa a ser proveedor y asume todas las obligaciones del proveedor.
Se convierte en proveedor cuando:
1. Modifica Sustancialmente un Sistema de IA de Alto Riesgo
Si toma un sistema de IA de alto riesgo y realiza cambios sustanciales que van más allá de lo que el proveedor pretendía — cambiando el modelo, volviendo a entrenarlo con sus datos, alterando la lógica central — ahora es proveedor de un sistema nuevo o sustancialmente modificado. Se aplican todas las obligaciones del proveedor: evaluación de la conformidad, documentación técnica, marcado CE, registro en la base de datos de la UE.
Pregunta clave: ¿Es su personalización «uso dentro de los parámetros previstos» o «desarrollo de una nueva capacidad»? El ajuste fino de un modelo con sus datos de dominio puede o no ser una modificación sustancial dependiendo del grado de cambio y si afecta al perfil de riesgo.
2. Cambia el Fin Previsto a de Alto Riesgo
Si toma un sistema no clasificado como de alto riesgo y lo despliega para un caso de uso de alto riesgo — usando un clasificador de texto general para tomar decisiones de empleo, por ejemplo — ha cambiado el fin previsto de una manera que desencadena la clasificación de alto riesgo. Se convierte en proveedor de un sistema de IA de alto riesgo y debe cumplir con todas las obligaciones del proveedor para ese despliegue.
3. Comercializa el Sistema Bajo Su Propio Nombre
Si adquiere o licencia un sistema de IA y lo revende u ofrece a otros como su propio producto (marca blanca), lo comercializa bajo su propio nombre y se convierte en proveedor. Esto es habitual en el sector SaaS: integrar un modelo de terceros en su propia oferta de productos le convierte en proveedor de ese producto.
4. Realiza Cambios Importantes en un Modelo GPAI
Si toma un modelo GPAI y realiza modificaciones importantes en sus capacidades o caso de uso — más allá del ajuste fino dentro de los parámetros previstos del proveedor — puede convertirse en proveedor de un nuevo modelo GPAI con sus propias obligaciones del Capítulo V.
Protecciones Contractuales para los Operadores
Dado que su cumplimiento depende de lo que le dé el proveedor, sus contratos con proveedores de IA de terceros son una herramienta crítica de cumplimiento. Cláusulas clave a incluir:
Derechos de Información
- Derecho a recibir y a una versión regularmente actualizada de las instrucciones de uso
- Derecho a acceder a la declaración de conformidad y al resumen de la evaluación de la conformidad
- Derecho a recibir los resultados de las pruebas de sesgo y las métricas de rendimiento
- Derecho a recibir documentación de las actualizaciones materiales del modelo antes del despliegue
Gestión de Incidentes
- Obligación del proveedor de notificarle cualquier incidente grave o vulnerabilidad del que tenga conocimiento, dentro de un plazo definido
- Canal y proceso claros para que usted notifique incidentes al proveedor
- Compromiso del proveedor de cooperar con sus investigaciones de incidentes e investigaciones regulatorias
Derechos de Auditoría
- Derecho a auditar o recibir informes de auditoría sobre el cumplimiento del proveedor de las obligaciones del Reglamento de IA
- Derecho a solicitar documentación actualizada cuando se produzcan cambios significativos
Obligaciones de Actualización
- El proveedor debe notificarle antes de desplegar actualizaciones materiales al sistema de IA
- El proveedor debe informarle si una actualización constituye una modificación sustancial que requiere revalidación
- Continuidad de la documentación — se debe proporcionar documentación técnica actualizada con cada actualización material
Asignación de Responsabilidad
- Claridad sobre qué parte es responsable de qué obligaciones en virtud del Art. 25
- Indemnización por pérdidas derivadas del incumplimiento del proveedor de sus obligaciones de proveedor
- Disposiciones de limitación de responsabilidad que no socaven su capacidad de cumplir las obligaciones regulatorias
El Mercado de IA de Proveedores: Qué Vigilar
El mercado de herramientas y servicios de IA está evolucionando rápidamente, y la postura de cumplimiento del Reglamento de IA de los proveedores varía significativamente:
- Los principales proveedores de nube e IA (Microsoft, Google, AWS, OpenAI, Anthropic) han invertido fuertemente en gobernanza de IA y documentación de cumplimiento GPAI. Sus términos de servicio y tarjetas de modelos proporcionan más información que la mayoría de los demás proveedores.
- Los proveedores de IA vertical especializados (tecnología de RRHH, tecnología jurídica, tecnología financiera, tecnología de salud) se encuentran en diferentes etapas de preparación para el Reglamento de IA de la UE. Muchos son pymes que aún no han mapeado completamente sus obligaciones.
- La IA integrada en herramientas SaaS (funciones de IA en CRM, ERP, herramientas de productividad) puede no comercializarse como «productos de IA» — pero si toman o influyen en decisiones importantes sobre los individuos, se aplican las obligaciones del Reglamento de IA de la UE.
Los equipos de adquisición deben añadir el cribado de cumplimiento del Reglamento de IA a la diligencia debida con proveedores — solicitando a los proveedores que certifiquen su estado de cumplimiento, proporcionen documentación de conformidad para los sistemas de alto riesgo y se comprometan a compartir información de forma continua a medida que evoluciona el panorama regulatorio.
Official AI Act Compliance Deadline Calendar
Updated · Sources: Regulation (EU) 2024/1689 and the 2026 Digital Omnibus on AI.
| Obligation | Applies to | Original date | New date | Status | Countdown | Legal basis |
|---|---|---|---|---|---|---|
| Prohibited Practices (Art. 5) | All providers and deployers | active | — | AI Act Art. 5 | ||
| GPAI Rules (Chapter 5) | GPAI model providers | active | — | AI Act Art. 51-56 | ||
| High-risk AI — Annex III (standalone) | Providers of standalone Annex III systems | deferred | — | AI Omnibus 2026 Art. 6(2) | ||
| High-risk AI — Annex I (embedded) | AI embedded in Annex I regulated products | deferred | — | AI Omnibus 2026 Art. 6(1) | ||
| AI-Generated Content Marking | Providers of generative GPAI systems | active | — | AI Act Art. 50(2) | ||
| Regulatory Sandboxes | National competent authorities | active | — | AI Act Art. 57 |
⬇ Download JSON · CC BY 4.0
AI Act meets DORA and NIS2
Is your organisation subject to both the AI Act and DORA? The two regulations intersect on the operational resilience of financial AI systems. Our sister site regulation-dora.eu covers DORA in depth.
Explore regulation-dora.eu ↗Frequently Asked Questions
Sí, como operadores. El proveedor de API (OpenAI, Anthropic) es el proveedor del modelo GPAI y asume las obligaciones GPAI. Si construye una aplicación sobre su API y la pone a disposición de los usuarios, se convierte en proveedor de esa aplicación (un sistema de IA). Tiene obligaciones de operador respecto al modelo GPAI subyacente y obligaciones de proveedor para su propio sistema de IA.
Para sistemas de IA de alto riesgo: el proveedor (como proveedor) debe suministrar instrucciones de uso (Art. 13) y un resumen de la evaluación de la conformidad o la declaración de conformidad. Para modelos GPAI: los proveedores deben suministrar documentación técnica e información necesaria para el cumplimiento de los intermediarios. Solicite contractualmente: descripción del sistema, limitaciones conocidas, resultados de pruebas de sesgo, métricas de rendimiento y procedimientos de notificación de incidentes.
Contractualmente, puede asignar la responsabilidad entre las partes — pero la responsabilidad regulatoria no puede transferirse contractualmente. Si despliega un sistema de IA de alto riesgo, tiene obligaciones de operador independientemente de su acuerdo. Use los contratos para garantizar que el proveedor le dé lo que necesita para cumplir sus obligaciones, no para escapar de ellas.
El Reglamento de IA de la UE se aplica a los sistemas de IA comercializados en el mercado europeo independientemente de dónde esté establecido el proveedor. Los proveedores no pertenecientes a la UE deben designar un representante autorizado en la UE (Art. 22) que tiene las mismas obligaciones legales que un proveedor establecido en la UE. Verifique que el proveedor tenga un representante autorizado antes de desplegar su sistema de IA.
Stay ahead of AI Act changes
Get compliance alerts when deadlines or obligations change.
No spam. One-click unsubscribe.