Uso interno vs. uso comercial de modelos de IA Open Source de acuerdo con el Reglamento Europeo de IA

Contexto

Una empresa apuesta por el uso de modelos de IA Open source adaptados para su uso en tareas administrativas internas, pero también para realización de actividades comerciales, en la elaboración de entregables y prestación de servicios a clientes.

La cuestión es si aplica en este contexto el RIA o no.

Estás leyendo ZERO PARTY DATA. La newsletter sobre actualidad, tecnopolios y derecho de Jorge García Herrero y Darío López Rincón.

En los ratos libres que nos deja esta newsletter, estamos especializados en resolver movidas complicadas en protección de datos personales. Si tienes de alguna de esas, haznos así con la manita. O contáctanos por correo en jgh(arroba)jorgegarciaherrero.com

¡Gracias por leer Zero Party Data! Apúntate!

1 Premisas clave

1.1 “Deployer” y “Provider” en el RIA: la delgada (y móvil) línea roja

El RIA califica como Deployer a cualquier empresa que utiliza un modelo open source —ya sea como componente de un producto propio, como herramienta interna de productividad o como motor de un servicio dirigido a terceros-.

Además el Deployer puede incluso acabar siendo también Provider o proveedor cuando modifica sustancialmente el sistema o lo introduce en el mercado bajo su propio nombre (art. 25), como veremos.

1.2 Alcance de la exención “open source”

El artículo 2.12 establece que el RIA no se aplicará a los componentes de IA suministrados con licencias libres y de código abierto, salvo que:

• se comercialicen o pongan en servicio como sistemas de IA de alto riesgo (Anexo III) o como sistemas sujetos a las obligaciones de transparencia;

• el proveedor del componente open source sea un modelo de IA de propósito general (GPAI) con riesgo sistémico.

Pero esta exención opera sólo para el proveedor del componente, no para el Deployer que integra dicho componente en un sistema y lo utiliza - interna o externamente- como se ha dicho.

Las obligaciones del Deployer nacen del uso efectivo del sistema y de su clasificación de riesgo, con independencia de la licencia bajo la que se distribuya el modelo subyacente (open o comercial).

2 Uso interno (fines administrativos, productividad)

En este escenario, la empresa despliega el modelo open source exclusivamente para optimizar procesos internos, como por ejemplo: generación de borradores de documentos, resúmenes, análisis de datos, automatización de tareas de back-office, clasificación de correos electrónicos, asistencia a departamentos (RRHH, finanzas, legal), etc.

Es decir, no existe interacción directa del sistema con clientes o usuarios externos.

Sin embargo, el RIA no entiende de ámbitos internos o externos: las obligaciones anudadas a cada clasificación de riesgo, aplican en cualquier caso.

2.1 Uso interno en finalidades de “Alto riesgo”

Si el sistema de IA se utiliza en alguno de los ámbitos del Anexo III —por ejemplo, para seleccionar internamente candidatos en procesos de contratación (Anexo III, punto 4), evaluar el rendimiento de empleados, asignar tareas de trabajo o tomar decisiones que afecten a las condiciones laborales—, el Deployer queda sujeto al régimen de obligaciones de alto riesgo.

Entonces: obligaciones principales del Deployer:

• Uso conforme a instrucciones del Provider (art. 26.1). El Deployer debe utilizar el sistema de conformidad con las instrucciones de uso facilitadas por el proveedor, incluyendo la supervisión humana prescrita. En el caso de modelos open source, esto implica que la empresa debe documentar internamente qué instrucciones del proveedor ha aplicado y, si las ha adaptado, justificarlo.

• Supervisión humana efectiva (art. 26.2). El Deployer debe garantizar que las personas físicas encargadas de supervisar el sistema tengan la competencia, formación y autoridad necesarias. Y la ejerzan, vaya. Nada fácil.

• Monitorización y reporte de incidentes (art. 26.5). Cuando el Deployer detecte que el sistema puede presentar un riesgo, debe informar sin demora al proveedor y, en su caso, a la autoridad competente. Los incidentes graves deben notificarse.

• Evaluación de impacto en derechos fundamentales (art. 27). Como ocurre con las PIAs de protección de datos, no siempre es obligatorio, pero siempre es recomendable.

• Conservación de logs o registros automáticos (art. 26.6). El Deployer debe conservar los registros generados automáticamente por el sistema durante un periodo mínimo de seis meses, salvo que la legislación sectorial disponga otra cosa.

• Evaluación de impacto en protección de datos personales (EIPD/DPIA) (art. 26.9). Cuando el sistema de alto riesgo trate datos personales, el Deployer debe utilizar la información proporcionada por el proveedor para cumplir con su obligación de realizar una evaluación de impacto relativa a la protección de datos.

• Información a personas afectadas (art. 26.11-12). El Deployer debe informar a las personas afectadas de que están sujetas a la utilización de un sistema de IA de alto riesgo. En estos momentos, lo más probable es que estas personas sean los empleados, y, en el contexto laboral, esta obligación se refuerza: los trabajadores y sus representantes deben ser informados previamente (art. 26.7).

2.2 Uso interno en finalidades de Riesgo limitado

Si el sistema no encaja en ninguna de las categorías de alto riesgo del Anexo III pero interactúa directamente con personas (p. ej., un chatbot interno para empleados) o genera contenido sintético, las obligaciones del Deployer se centran en la transparencia (art. 50):

• Notificación de interacción con IA (art. 50.1). Si el sistema interactúa con personas físicas, el Deployer debe garantizar que dichas personas sean informadas de que están interactuando con un sistema de IA, salvo que resulte evidente de acuerdo con el contexto.

• Identificación de contenidos sintéticos (art. 50.4-5). En relación con outputs de texto, audio, imagen o vídeo sintéticos, el Deployer debe divulgar que el contenido ha sido generado o manipulado artificialmente. En contextos internos, esta obligación podría materializarse, por ejemplo, en marcar como «generado por IA» los borradores producidos por el sistema para consumo interno.

• Sistemas de reconocimiento de emociones o categorización biométrica (art. 50.3). Si se desplegasen internamente sistemas de este tipo, el Deployer deberá informar a las personas expuestas. No obstante, es interesante recordar aquí que determinados usos de reconocimiento de emociones en el lugar de trabajo están directamente prohibidos (art. 5.1.f).

Los asistentes de redacción sin interacción con terceros, motores de análisis de datos no biométricos) pueden no encuadrarse siquiera en la categoría de riesgo limitado, quedando como sistemas de sin obligaciones específicas bajo el RIA.

Pero mejor que te lo mire alguien.

3 Uso externo (entregables a clientes / servicios a usuarios)

En este caso, el modelo open source alimenta productos, servicios o entregables que se dirigen a clientes, consumidores o usuarios externos. (plataformas SaaS basadas en LLMs open source, informes generados automáticamente para clientes, chatbots de atención al público, generación de contenido para terceros, etc.)

Detalle clave: El Deployer puede adquirir simultáneamente la condición de proveedor (Provider) si :

a. Coloca en el mercado o pone en servicio el sistema bajo su propio nombre o marca (art. 25.1.a), o si

b. modifica sustancialmente un sistema ya colocado en el mercado (art. 25.1.b), o si

c. modifica la finalidad prevista de un sistema de alto riesgo (art. 25.1.c).

En tales casos, le corresponderían las obligaciones íntegras de proveedor además de las de Deployer.

3.1 Uso externo en finalidades de alto riesgo

Cuando el servicio o producto ofrecido a clientes encaje en alguna de las categorías del Anexo III, el régimen aplicable es el más exigente del Reglamento. Además de las obligaciones ya detalladas en la Sección 2.1 anterior (que se aplican íntegramente), el Deployer en contexto externo debe atender especialmente a:

• Evaluación de impacto en derechos fundamentales reforzada (art. 27). Cuando el sistema se dirige a usuarios o afecta a terceros, la FRIA cobra mayor relevancia práctica. Deben evaluarse los riesgos específicos para los grupos de personas que puedan verse afectadas, las medidas de supervisión humana, los planes de acción ante resultados adversos, y el mecanismo de gobernanza. Los resultados deben notificarse a la autoridad de vigilancia del mercado.

• Información a las personas afectadas por el output (art. 26.11). Cuando las decisiones del sistema afecten a personas físicas externas (clientes, solicitantes, usuarios), el Deployer debe informarles de manera oportuna, concisa e inteligible.

• Cooperación reforzada con el proveedor del modelo (art. 26.4). En el ecosistema open source, donde el soporte del proveedor suele ser inexistente, el Deployer debe asumir proactivamente la responsabilidad de verificar que el sistema funciona según lo previsto. Si el Deployer ha modificado el modelo, puede haber asumido obligaciones de proveedor (art. 25).

• Obligación de conformidad con el sistema de gestión de calidad del proveedor (art. 26.1). En la práctica, la mayoría de modelos open source carecen de un sistema de gestión de calidad formalizado conforme al artículo 17. El Deployer deberá implementar controles compensatorios propios o asumir la posición de proveedor si dichos controles no existen.

• Registro en la base de datos de la UE (art. 49.3). Determinados Deployers de sistemas de alto riesgo están obligados a registrar el uso del sistema en la base de datos de la UE. Esto aplica particularmente a Deployers que sean autoridades públicas o entidades privadas prestadoras de servicios públicos.

El deployer que asume también la condición de provider tendrá que lidiar con el sistema de gestión de calidad, gestión de riesgos, documentación técnica, evaluación de conformidad, marcado CE, y declaración de conformidad UE.

3.2 Uso externo en finalidades de riesgo limitado

Este será probablemente el escenario más frecuente en Agosto 2026, cuando todo esto entra en vigor: chatbots de atención al cliente, generadores de contenido, herramientas de resumen o traducción ofrecidas como servicio, asistentes virtuales, etc.

Las obligaciones del Deployer se centran en la transparencia (art. 50):

• Información sobre la interacción con IA (art. 50.1). Los usuarios / clientes deben saber que interactúan con un sistema de IA. La comunicación debe ser clara, oportuna (antes o al inicio de la interacción) y accesible.

• Marcado de contenido sintético generado para clientes (art. 50.4-5). Todo contenido de texto, imagen, audio o vídeo generado por IA y entregado a terceros debe identificarse como artificialmente generado o manipulado. Esto tiene implicaciones directas para empresas que generan informes, análisis, textos creativos, imágenes o vídeos para sus clientes mediante modelos open source.

• Deepfakes (art. 50.4). Si el sistema genera o manipula contenido de imagen, audio o vídeo que se asemeje notablemente a personas, objetos, lugares u otras entidades o acontecimientos reales, y pueda parecer auténtico (deepfake), el Deployer tiene la obligación específica de informar que el contenido ha sido generado o manipulado artificialmente.

• Marcado técnico de contenido (art. 50.2, obligación del proveedor). Aunque el marcado técnico (watermarking, metadatos) es obligación primaria del proveedor del modelo, el Deployer debe asegurarse de que no elimina ni desactiva dichos marcadores. En el ecosistema open source, es probable que el modelo no incorpore estos mecanismos, lo que puede generar una laguna práctica que el Deployer debería subsanar mediante medidas propias.

Dejamos lo de los modelos de propósito general (GPAI) para otro día.

Jorge García Herrero

Abogado y Delegado de Protección de datos