La Ley de IA de la UE no trata a todas las organizaciones de la cadena de valor de la IA de la misma manera. Tus obligaciones dependen de tu rol — especificamente, de si eres proveedor o implementador de un sistema de IA. Confundir esta distincion significa hacer mucho mas trabajo de cumplimiento del necesario, o mucho menos.

Este articulo explica los dos roles, que debe hacer cada uno, y los escenarios donde la linea entre ambos se difumina.

Definiciones: que dice realmente el reglamento

El Articulo 3 del Reglamento (UE) 2024/1689 define ambos roles:

Proveedor (Articulo 3(3)): Una persona fisica o juridica que desarrolla un sistema de IA o un modelo de IA de proposito general, o que encarga su desarrollo, y lo comercializa o pone en servicio bajo su propio nombre o marca, ya sea de pago o de forma gratuita.

Implementador (Articulo 3(4)): Una persona fisica o juridica que utiliza un sistema de IA bajo su autoridad, excepto cuando el sistema de IA se utiliza en el curso de una actividad personal no profesional.

En terminos sencillos: si lo construiste (o lo mandaste construir y pusiste tu nombre), eres proveedor. Si lo usas en un contexto profesional, eres implementador.

Por que importa la distincion

Las obligaciones son dramaticamente diferentes. Los proveedores soportan la mayor parte de la carga de cumplimiento para sistemas de IA de alto riesgo. Los implementadores tambien tienen responsabilidades significativas, pero son mas ligeras y se centran en el uso adecuado, no en el diseno del sistema.

Si eres ambos — por ejemplo, construiste un sistema de IA y tambien lo usas internamente — tienes ambos conjuntos de obligaciones.

Obligaciones del proveedor (Articulos 16-22)

Los proveedores de sistemas de IA de alto riesgo deben cumplir todo lo siguiente antes de comercializar el sistema en el mercado de la UE:

Requisitos de diseno y desarrollo:

  • Implementar un sistema de gestion de riesgos que se ejecute durante todo el ciclo de vida del sistema (Articulo 9)
  • Cumplir los estandares de gobernanza de datos para datos de entrenamiento, validacion y prueba (Articulo 10)
  • Producir documentacion tecnica detallada segun el Anexo IV antes de comercializar el sistema (Articulo 11)
  • Disenar el sistema para el registro automatico de eventos relevantes (Articulo 12)
  • Garantizar la transparencia — proporcionar instrucciones de uso claras a los implementadores (Articulo 13)
  • Incorporar mecanismos de supervision humana (Articulo 14)
  • Cumplir estandares de precision, robustez y ciberseguridad (Articulo 15)

Requisitos de calidad y administrativos:

  • Implementar un sistema de gestion de calidad (Articulo 17)
  • Realizar una evaluacion de conformidad (Articulo 43) — la mayoria de los sistemas del Anexo III pueden usar el control interno (Anexo VI), pero ciertos sistemas biometricos requieren evaluacion por terceros
  • Redactar una declaracion de conformidad de la UE (Articulo 47)
  • Colocar el marcado CE (Articulo 48)
  • Registrar el sistema en la base de datos de la UE antes de su comercializacion (Articulo 49)

Obligaciones continuas:

  • Operar un sistema de monitorizacion post-comercializacion (Articulo 72)
  • Reportar incidentes graves a las autoridades nacionales (Articulo 73)
  • Tomar acciones correctivas si el sistema deja de cumplir (Articulo 20)

Esta es una lista considerable. La documentacion tecnica por si sola — que cubre la arquitectura del sistema, datos de entrenamiento, resultados de pruebas, gestion de riesgos y mas — es tipicamente el requisito que mas tiempo consume. Nuestro checklist de cumplimiento desglosa cada elemento.

Obligaciones del implementador (Articulo 26)

Los implementadores de sistemas de IA de alto riesgo tienen un conjunto de requisitos mas reducido pero igualmente importante:

  • Usar el sistema segun las instrucciones de uso del proveedor. Parece obvio, pero significa leer y seguir la documentacion que acompana al sistema.
  • Asignar la supervision humana a personas fisicas que tengan la competencia, formacion y autoridad necesarias para desempenar ese rol eficazmente.
  • Asegurar que los datos de entrada sean relevantes y suficientemente representativos para el proposito previsto del sistema, en la medida en que el implementador ejerza control sobre los datos de entrada.
  • Monitorizar el funcionamiento del sistema segun las instrucciones de uso. Si identificas un riesgo o incidente grave, informa al proveedor y a la autoridad nacional competente sin demora.
  • Conservar los registros generados automaticamente por el sistema durante al menos seis meses, salvo que la ley exija lo contrario.
  • Realizar una evaluacion de impacto en derechos fundamentales antes de poner el sistema en uso, si eres un organismo publico o una entidad privada que presta servicios publicos.
  • Informar a las personas afectadas de que estan sujetas a un sistema de IA de alto riesgo, cuando sea aplicable.
  • Cooperar con las autoridades nacionales y proporcionar acceso a registros y documentacion cuando se solicite.

La diferencia clave: los implementadores son responsables del uso adecuado, mientras que los proveedores son responsables del diseno adecuado. Un implementador no necesita redactar documentacion tecnica ni realizar una evaluacion de conformidad — el proveedor ya lo hizo.

Cuando un implementador se convierte en proveedor

Aqui es donde se complica. El Articulo 25 especifica que un implementador es reclasificado como proveedor — y asume todas las obligaciones del proveedor — en cualquiera de estas situaciones:

  1. Pones tu nombre o marca en un sistema de IA de alto riesgo que ya esta en el mercado. Aunque otra persona lo haya construido, marcarlo como tuyo te convierte en proveedor.
  2. Realizas una modificacion sustancial a un sistema de IA de alto riesgo. Hacer fine-tuning de un modelo con tus propios datos, cambiar el proposito previsto o alterar significativamente el comportamiento del sistema puede activar esta clausula.
  3. Modificas el proposito previsto de un sistema de IA de modo que se convierta en alto riesgo cuando antes no lo era. Por ejemplo, usar un chatbot de proposito general para seleccion de empleo cambia su clasificacion de riesgo.

Esto tiene implicaciones importantes para empresas que usan servicios de IA de terceros. Si tomas una API de un proveedor de modelos, la envuelves en tu propio producto y la vendes bajo tu marca para un caso de uso de alto riesgo — probablemente eres el proveedor, no un implementador. El hecho de que otra persona haya entrenado el modelo no traslada la carga de cumplimiento.

Matices importantes sobre "modificacion sustancial":

  • El fine-tuning puede activar la reclasificacion, pero hay un umbral: si el fine-tuning usa un computo que excede un tercio del computo de entrenamiento original del modelo, el modificador se convierte en proveedor de un nuevo modelo. Por debajo de ese umbral, probablemente sigues siendo implementador.
  • RAG (Generacion Aumentada por Recuperacion) no constituye una modificacion sustancial. Anadir conocimiento especifico de dominio mediante recuperacion sin alterar la arquitectura o los pesos del modelo te mantiene como implementador.
  • El porcentaje de codigo cambiado es irrelevante — lo que importa es el impacto en la funcionalidad y la postura de cumplimiento.

Ejemplos del mundo real

Escenario 1: Empresa SaaS usando una API de IA de terceros Una startup fintech integra un modelo de scoring crediticio de un proveedor externo en su plataforma de prestamos. La startup vende la plataforma bajo su propia marca.

Rol: La startup es el proveedor — comercializo el sistema bajo su propio nombre para un caso de uso de alto riesgo (el scoring crediticio esta en el Anexo III). El vendedor de la API puede tambien ser proveedor de un modelo de IA de proposito general con sus propias obligaciones separadas.

Escenario 2: Banco implementando una herramienta de seleccion de personal de un proveedor Un banco compra una herramienta de seleccion de CV basada en IA a un proveedor. El banco la usa tal cual, siguiendo las instrucciones del proveedor, para contratacion interna.

Rol: El banco es el implementador. El proveedor es el proveedor. El banco debe asignar supervision humana, asegurar la calidad de los datos de entrada, conservar registros y realizar una evaluacion de impacto en derechos fundamentales. Pero el banco no necesita producir documentacion del Anexo IV — eso es responsabilidad del proveedor.

Escenario 3: Consultoria que hace fine-tuning de un modelo para un cliente Una consultoria de IA toma un modelo de codigo abierto, le hace fine-tuning con datos medicos de un cliente y entrega una herramienta de soporte diagnostico bajo la marca del cliente.

Rol: El cliente es el proveedor (su nombre esta en el producto). Pero la consultoria tambien puede tener responsabilidades similares a las de un proveedor dependiendo del acuerdo contractual. Esta es una zona gris — el enfoque mas seguro es definir las responsabilidades de proveedor/implementador explicitamente en el contrato.

Y los modelos de IA de proposito general?

La Ley de IA de la UE introduce una categoria separada para proveedores de modelos de IA de proposito general (GPAI) (Articulos 51-56). Empresas como OpenAI, Google, Meta y Mistral entran aqui si ponen modelos fundacionales a disposicion del publico.

Los proveedores de GPAI tienen sus propias obligaciones — principalmente en torno a documentacion tecnica, transparencia y cumplimiento de derechos de autor. Pero estas son separadas del marco proveedor/implementador para sistemas de IA de alto riesgo.

Si construyes una aplicacion de alto riesgo sobre un modelo GPAI, eres el proveedor del sistema de alto riesgo. El proveedor de GPAI tiene sus propias obligaciones, pero no sustituyen las tuyas.

Desarrollos recientes

El 13 de marzo de 2026, el Consejo de la UE acordo una posicion negociadora sobre la propuesta "Omnibus Digital", que podria extender el plazo para las reglas de sistemas de IA de alto riesgo hasta 16 meses — potencialmente trasladando las obligaciones de sistemas de alto riesgo independientes a diciembre de 2027. Sin embargo, esto es una posicion negociadora, no legislacion final. El Parlamento Europeo aun necesita estar de acuerdo, y el calendario para llegar a un acuerdo es incierto.

Hasta que se adopte una enmienda formal, el plazo del 2 de agosto de 2026 sigue vigente. Las empresas no deberian pausar sus esfuerzos de cumplimiento basandose en una propuesta que puede o no convertirse en ley.

Como determinar tu rol

Hazte estas preguntas en orden:

  1. ¿Desarrollaste el sistema de IA (o encargaste su desarrollo)?
    • Si → probablemente eres proveedor
  2. ¿El sistema se comercializa o pone en servicio bajo tu nombre o marca?
    • Si → eres proveedor, aunque otra persona lo haya construido
  3. ¿Realizaste una modificacion sustancial a un sistema de IA de alto riesgo?
    • Si → eres reclasificado como proveedor (Articulo 25)
  4. ¿Cambiaste el proposito previsto de un sistema de IA para que se convierta en alto riesgo?
    • Si → eres reclasificado como proveedor (Articulo 25)
  5. ¿Ninguna de las anteriores — usas el sistema bajo tu autoridad segun lo proporcionado por el proveedor?
    • Eres implementador

Si no estas seguro de si tu sistema de IA es de alto riesgo, el triaje de riesgo gratuito de Annexa puede clasificarlo en minutos — y ayudarte a determinar si necesitas cumplir obligaciones de proveedor o de implementador.

Que hacer ahora

Ya seas proveedor o implementador, el momento de actuar es ahora. El checklist de cumplimiento cubre cada obligacion del proveedor paso a paso. Los implementadores deben empezar auditando que sistemas de IA usan, confirmando que sus proveedores estan gestionando las obligaciones de proveedor, y estableciendo procesos de supervision humana y registro.

Las empresas que hagan esto bien sabran exactamente que sombrero llevan puesto — y se prepararan en consecuencia.