Reglamento de IA de la UE: Proveedores vs. Operadores — ¿Quién Es Responsable de Qué?

El Reglamento de IA de la UE divide las obligaciones entre proveedores (que construyen sistemas de IA) y operadores (que los ponen en práctica). Entender qué papel ocupa determina su carga de cumplimiento — y si puede trasladar la responsabilidad a otra parte.

La Arquitectura de Dos Actores del Reglamento de IA de la UE

El Reglamento de IA de la UE no crea una obligación universal única para todos los interesados en IA. Distingue sistemáticamente entre dos roles principales en la cadena de valor de la IA:

• Proveedores — entidades que desarrollan, entrenan o afinan sistemas de IA y los comercializan
• Operadores — entidades que operan sistemas de IA en un contexto profesional sin haberlos construido

Esta distinción no es semántica. Determina qué obligaciones se aplican, quién tiene qué documentación, quién se registra en la base de datos de IA de la UE, quién realiza la evaluación de la conformidad y quién es responsable cuando algo sale mal. Identificar correctamente su papel es el primer paso en cualquier programa de cumplimiento del Reglamento de IA de la UE.

Un tercer papel — representante autorizado — se aplica a los proveedores establecidos fuera de la UE que deben designar un representante con sede en la UE para llevar sus obligaciones regulatorias en territorio de la UE.

Definición del Proveedor (Art. 3(3))

Un proveedor es cualquier persona física o jurídica, autoridad pública, agencia u otro organismo que:

1. Desarrolla un sistema de IA o lo encarga desarrollar, y
2. Lo comercializa o pone en servicio bajo su propio nombre o marca — ya sea a título oneroso o gratuito

Los indicadores clave del estatus de proveedor son la responsabilidad de desarrollo y la comercialización. Un laboratorio de IA que construye y licencia un modelo de puntuación crediticia es un proveedor. Una consultora que diseña y construye una herramienta de cribado de contratación personalizada para un cliente y luego la entrega también es proveedora (siempre que comercialice el sistema bajo su propio nombre; si se construye bajo la marca del cliente, el cliente puede ser el proveedor).

La definición cubre:

• Empresas emergentes de IA y proveedores de software que venden productos de IA empaquetados
• Empresas que construyen sistemas de IA para despliegue interno
• Instituciones de investigación que publican sistemas de IA para uso general
• Proveedores de nube que ofrecen IA como servicio bajo su propia marca

Los proveedores asumen la mayor carga de cumplimiento en virtud del Reglamento. Para los sistemas de alto riesgo, esto incluye realizar evaluaciones de la conformidad, preparar la documentación técnica, registrarse en la base de datos de IA de la UE, colocar el marcado CE y mantener un sistema de vigilancia poscomercialización.

Definición del Operador (Art. 3(4))

Un operador es cualquier persona física o jurídica, autoridad pública, agencia u otro organismo que utiliza un sistema de IA bajo su autoridad con fines profesionales — excepto cuando el uso es en una actividad personal no profesional.

Los operadores no construyen sistemas de IA. Usan sistemas construidos por otros — ya sea adquiridos como producto estándar, licenciados a través de API o integrados en un producto SaaS. La gran mayoría de las organizaciones europeas que «usan IA» son operadores: empresas que usan ChatGPT o Claude a través de API, departamentos de RRHH que usan seguimiento de candidatos impulsado por IA, hospitales que usan herramientas de diagnóstico asistidas por IA, bancos que usan modelos de crédito proporcionados por proveedores.

Obligaciones clave del operador (para sistemas de IA de alto riesgo):

• Usar el sistema solo de acuerdo con las instrucciones proporcionadas por el proveedor (Art. 26(1))
• Asignar a una persona con competencia, autoridad y recursos para realizar la supervisión humana (Art. 26(2))
• Garantizar que los datos de entrada sean relevantes y representativos para el fin previsto (Art. 26(5))
• Supervisar el funcionamiento del sistema para detectar anomalías (Art. 26(5))
• Retener los registros producidos por el sistema durante el período requerido (Art. 26(6))
• Notificar al proveedor y a la autoridad competente cualquier incidente grave (Art. 26(8))
• Llevar a cabo una Evaluación de Impacto sobre la Protección de Datos donde lo exija el RGPD (Art. 26(9))

Los operadores de sistemas de reconocimiento de emociones y categorización biométrica también deben cumplir con las obligaciones de transparencia del Art. 50 independientemente de la clasificación de riesgo.

La Frontera Proveedor-Operador en la Práctica

La frontera entre proveedor y operador es sencilla en teoría pero difusa en la práctica. Tres escenarios ilustran las zonas grises más habituales:

Escenario 1: SaaS estándar sin personalización

Una empresa se suscribe a la plataforma de cribado de RRHH impulsada por IA de un proveedor sin ninguna modificación. El proveedor es el proveedor. La empresa es el operador. El proveedor debe a la empresa instrucciones de uso, documentación de conformidad y capacidad de registro. La empresa debe a sus empleados transparencia y supervisión humana.

Escenario 2: Integración de API con ingeniería de prompts significativa

Una empresa integra un modelo GPAI a través de API, añade un mensaje de sistema personalizado, construye una interfaz de usuario y lanza la aplicación a los clientes. Para el modelo GPAI subyacente, el desarrollador original es el proveedor. Para la aplicación construida encima, la empresa es el proveedor: ha desarrollado un sistema de IA y lo ha comercializado bajo su propia marca. Se aplican obligaciones de proveedor y GPAI en diferentes capas.

Escenario 3: Construcción interna personalizada

Un banco construye su propio modelo de evaluación de la solvencia crediticia, lo entrena con datos propietarios y lo despliega internamente para decisiones de préstamos. El banco es simultáneamente el proveedor (construyó y desplegó el sistema) y el operador (opera el sistema para sus propios fines). Se aplican todas las obligaciones del proveedor en virtud del Reglamento — incluida la evaluación de la conformidad para este caso de uso de alto riesgo del Anexo III — así como todas las obligaciones del operador.

Cuándo los Operadores se Convierten en Proveedores (Art. 25)

El Art. 25 establece desencadenantes claros por los que un operador asume el estatus de proveedor y hereda todas las obligaciones del proveedor:

1. Modificación sustancial — el operador realiza una modificación sustancial en un sistema de IA de alto riesgo más allá de lo que el proveedor original pretendía
2. Cambio de fin que desencadena la clasificación de alto riesgo — el operador usa un sistema no de alto riesgo de una manera que cumple los criterios de alto riesgo del Anexo III
3. Comercialización con nombre propio — el operador comercializa el sistema de IA o lo pone en servicio bajo su propio nombre o marca
4. Modificación de modelo GPAI — un operador que realiza un cambio importante en un modelo GPAI de una manera que altera su caso de uso de uso general

Cuando se activa el Art. 25, las obligaciones del proveedor original se transfieren al nuevo proveedor. El proveedor original queda exento de obligaciones para el sistema modificado o repropuesto. Este es un mecanismo importante de asignación de responsabilidad: las organizaciones que simplemente personalizan un sistema deben entender dónde termina la personalización y comienza la modificación sustancial.

Tabla Comparativa de Obligaciones

Cómo Determinar Su Papel

Tres preguntas establecen su papel en virtud del Reglamento de IA de la UE:

1. ¿Desarrolló el sistema de IA, o lo encargó desarrollar bajo su dirección? Si sí — y lo comercializó o puso en servicio — usted es un proveedor.

2. ¿Usa un sistema de IA construido por otra persona con fines profesionales? Si sí, usted es un operador.

3. ¿Ha modificado sustancialmente, repropuesto o cambiado de marca un sistema de IA? Si sí, puede haberse convertido en proveedor de ese sistema modificado en virtud del Art. 25.

Para las organizaciones que son ambas cosas — construcción interna para uso interno — todas las obligaciones se acumulan. No hay reducción para las operaciones integradas.

Asignación Contractual de Responsabilidades

El Reglamento permite a los proveedores y operadores asignar contractualmente obligaciones específicas. El Art. 25(1) lo permite explícitamente para ciertas obligaciones. Sin embargo, se aplican dos límites:

• La responsabilidad regulatoria no puede transferirse contractualmente. Si el operador opera un sistema de alto riesgo, sigue siendo responsable de las obligaciones del operador independientemente de lo que diga el contrato. Los contratos pueden establecer recursos internos, pero no pueden transferir la responsabilidad regulatoria a la otra parte.
• El flujo de información debe preservarse. Cualquier asignación debe garantizar que el operador tenga la información necesaria para cumplir sus obligaciones — instrucciones de uso, acceso a registros, canales de notificación de incidentes. Los contratos que cortan este flujo de información son problemáticos para el cumplimiento, no solo comercialmente.

Los equipos de adquisición deben usar los contratos de proveedores de IA para garantizar que los proveedores suministren lo que los operadores necesitan: instrucciones, documentación de conformidad, canales de notificación de incidentes, compromisos de actualización y términos de gobernanza de datos para cualquier dato compartido para el ajuste fino.