Nuevos modelos de negocio en el mercado de la inteligencia artificial generativa: cómo capturar valor

Resumen

El objetivo de este trabajo es ofrecer a los abogados un marco operativo para comprender los principales modelos de negocio surgidos tras la popularización de la IA generativa. A partir de esa base, se propone identificar sus dependencias estructurales y elaborar un mapa de los activos jurídicamente relevantes a lo largo de su ciclo de vida. Definido el entorno de mercado y sus condicionantes, será posible diseñar estrategias de protección y de asignación de riesgos mediante derechos de propiedad intelectual, secreto empresarial y medidas tecnológicas, entre otros instrumentos. En este proceso resulta igualmente esencial prestar atención a la arquitectura contractual. Aunque la capacidad de negociación con los proveedores tecnológicos sea en ocasiones limitada, las restricciones derivadas de las capas de infraestructura deben trasladarse a lo largo de toda la cadena de valor, evitando así asumir compromisos comerciales que no puedan cumplirse en fases posteriores. Todo ello exige además una atención especial a la dimensión probatoria y a la trazabilidad de los procesos. El análisis presta particular atención a la licitud y trazabilidad de los datos de entrenamiento en la Unión Europea, al problema de la memorización en modelos generativos y a los efectos regulatorios derivados de la modificación de modelos o sistemas de terceros conforme al Reglamento de IA. En última instancia, el objetivo es proporcionar al abogado un marco práctico para identificar dónde se captura realmente el valor, qué riesgos deben anticiparse y qué instrumentos permiten hacer jurídicamente defendible el modelo de negocio frente a clientes, inversores y autoridades.

Palabras clave

Inteligencia artificial generativa; cadena de valor; captura de valor; propiedad intelectual; propiedad industrial; medidas tecnológicas de protección; datos de entrenamiento; fine-tuning; RAG; secreto empresarial; cumplimiento normativo.

Abstract

The aim of this article is to provide lawyers with an operational framework for understanding the main business models that have emerged following the widespread adoption of generative AI. Building on this foundation, the article seeks to identify their structural dependencies and to map the legally relevant assets across their lifecycle. Once the market environment and its constraints are defined, it becomes possible to design protection and risk-allocation strategies through intellectual property rights, trade secrets and technical safeguards, among other instruments.

Particular attention must also be paid to contractual architecture. Even where the ability to negotiate with technology providers is limited, constraints stemming from infrastructure layers must be reflected throughout the value chain, in order to avoid assuming downstream commitments that cannot realistically be fulfilled. This also requires careful consideration of evidentiary aspects and the traceability of processes.

The analysis focuses in particular on the legality and traceability of training data within the European Union, the problem of memorisation in generative models, and the regulatory implications of modifying third-party models or systems under the AI Act. Ultimately, the article seeks to provide lawyers with a practical framework to identify where value is actually captured, which risks must be anticipated, and which mechanisms make the business model legally defensible vis-à-vis clients, investors and regulators.

Keywords

Generative AI; value chain; value capture; intellectual property; industrial property; technical safety measures; training data; fine-tuning; RAG; trade secrets; regulatory compliance.

1. INTRODUCCIÓN

La expansión de la inteligencia artificial (“IA”) generativa ha introducido una nueva clase de productos y servicios en los que la propuesta de valor depende, de forma material, de sistemas capaces de producir contenidos o de transformar información compleja en resultados nuevos. En la práctica, la mayoría de los operadores, especialmente los europeos, no entrenan grandes modelos desde cero, sino que construyen sobre modelos de terceros, los integran en un sistema y los adaptan a un sector o caso de uso concreto. Este dato, la existencia de una cadena de suministro compleja y de una arquitectura técnica por capas, tiene un impacto determinante a la hora de saber capturar adecuadamente el valor competitivo de estos modelos de negocio, sus dependencias y el control de los activos que generan el auténtico valor. 

El objetivo de este trabajo es ofrecer un marco operativo para abogados que facilite la comprensión de los principales modelos de negocio surgidos tras la popularización de la IA generativa. A partir de esa base, se pretende ayudar a identificar sus dependencias estructurales y, con ello, elaborar un mapa de los activos jurídicamente relevantes a lo largo del ciclo de vida del sistema. Una vez definido el entorno de mercado y sus condicionantes, será posible proponer estrategias de protección y de asignación de riesgos mediante derechos de propiedad intelectual e industrial, secreto empresarial y el diseño de medidas tecnológicas, entre otros instrumentos. En este proceso también resulta esencial atender a la arquitectura contractual. Aunque en muchos escenarios la capacidad de negociación con proveedores sea limitada, las restricciones que derivan de las capas de infraestructura deben trasladarse a lo largo de toda la cadena de valor, para evitar que el proveedor asuma compromisos comerciales que en realidad no puede cumplir. Todo ello exige, además, prestar especial atención a la capa probatoria y a la trazabilidad de los procesos. 

Junto con lo anterior, se analizan ciertos aspectos del Reglamento de Inteligencia Artificial (“RIA”) que tienen un impacto directo en la gestión de los intangibles, incluyendo exigencias relacionadas con la transparencia. Este marco no elimina la incertidumbre (p.ej., sobre mecanismos de reserva de derechos o sobre el alcance de determinadas obligaciones en cadenas complejas), pero sí reconfigura la gestión del riesgo. Entendemos que las empresas que pueden documentar qué datos utilizan, qué controles aplican y cuáles son sus medidas de mitigación de riesgos, compiten con una base más sólida frente a clientes, inversores y autoridades de control.

En ese contexto, las categorías clásicas de propiedad intelectual e industrial siguen siendo relevantes, pero cambia su lógica tradicional. Parte de este cambio se debe a que los resultados que se obtienen mediante el uso de sistemas de IA generativa, el output, no suelen ser protegibles a través de la normativa de propiedad intelectual. La consecuencia práctica es un desplazamiento en el que la ventaja competitiva de los proveedores de servicios de IA se decide con mayor frecuencia en activos infraestructurales y organizativos, como los datos de entrenamiento, los procesos, la adaptación a cliente, la capa de cumplimiento y, muy especialmente, la forma en la que se gobiernan contractualmente las dependencias del stack tecnológico.

2. DELIMITACIÓN CONCEPTUAL Y ECONÓMICA

2.1. Modelos de negocio basados en IA generativa

A los efectos de este artículo, por modelo de negocio basado en IA generativa entendemos aquél en el que la propuesta de valor depende de manera material de un sistema capaz de generar contenidos (p. ej., texto, imagen, audio, vídeo o código) y/o de transformar inputs complejos en outputs nuevos mediante modelos de aprendizaje automático de propósito general, incluyendo los populares LLMs y los modelos multimodales. En la práctica, muchos de estos sistemas se construyen sobre un modelo fundacional o, en términos del RIA, modelo de IA de uso general (“modelo GPAI”). Lo habitual es adaptar estos modelos GPAI a un campo o caso de uso concreto mediante técnicas como el fine-tuning y/o una integración con fuentes de datos específicas (p. ej., RAG).

Esta delimitación es importante porque la IA generativa introduce una estructura de cadena de valor más compleja que la del software tradicional. En particular, es frecuente que intervengan entidades distintas en la obtención y preparación de datos, el desarrollo y el preentrenamiento del modelo, el diseño del sistema que lo integra, la adaptación del modelo a un campo específico, las pruebas de evaluación y, finalmente, el despliegue frente a los usuarios y la monitorización post-market. Desde la óptica de cómo obtener una ventaja competitiva, esto implica que los activos relevantes y, por tanto, las palancas de protección se distribuyen a lo largo del stack y no se concentran necesariamente en el resultado final.

Sobre esta base, podemos encontrar los siguientes patrones recurrentes de negocio, no necesariamente excluyentes entre sí:

2.1.1. Proveedores de modelos y capacidades (upstream)

Incluye a quienes entrenan modelos de uso general y los monetizan vía licencias, servicios API, “model-as-a-service” o de distribución de pesos bajo determinadas condiciones. Su ventaja competitiva suele residir en la capacidad de cómputo e infraestructura, el acceso a datos a gran escala, el talento y know-how de entrenamiento y/o evaluación, y su posicionamiento de mercado. En la Unión Europea, esta capa se ve condicionada por barreras de entrada, principalmente capacidad de cómputo, talento y capital, y por dependencias geopolíticas que explicaremos de forma breve más adelante. 

2.1.2. Integradores y orquestadores (midstream)

Son empresas que no entrenan el modelo GPAI, pero construyen sobre él un servicio empaquetado para uso empresarial. Su aportación consiste en seleccionar y combinar modelos de terceros, integrarlos con los sistemas del cliente y añadir capas de control, como instrucciones o prompts de sistema, guardarraíles, registro de actividad (logging), evaluación y gestión de riesgos, etc. En esta capa, la ventaja competitiva suele expresarse menos en un derecho de exclusiva y más en una correcta gestión del entramado contractual, donde cobra especial importancia el correcto establecimiento de niveles de servicio (SLA), reglas de cambio de versión, procesos de auditoría, portabilidad de datos, límites de uso y reparto de responsabilidad. Quien consigue cerrar ese paquete de manera atractiva, reducen fricción de compra y aceleran la adopción.

2.1.3. Soluciones verticales (downstream) 

En las soluciones verticales la IA generativa no se ofrece como herramienta general, sino como una solución integrada para un sector o función concreta (p. ej., legal, financiero, sanitario, etc.). El modelo base suele ser sustituible y de hecho es habitual que estas soluciones utilicen varios modelos GPAI entre los que el usuario final puede escoger. Por lo tanto, lo que genera valor es el encaje del servicio con un campo concreto. En la búsqueda de este encaje los activos esenciales pueden estar en el acceso a datos sectoriales de calidad (p.ej. compilaciones de sentencias, de artículos doctrinales, de datos médicos, etc.), integración con sistemas y procesos reales del cliente o capacidad de operar bajo estándares regulatorios muy elevados. En entornos altamente regulados, el cliente necesita una solución defendible ante el regulador, por lo que la capa de cumplimiento del servicio se vuelve un activo esencial. 

2.1.4. Generación de contenido con limpieza de derechos

Incluye servicios cuyo diferencial es que entrenan o ajustan modelos sobre corpus licenciados o depurados, lo que les permite ofrecer garantías adicionales a los clientes. Un ejemplo paradigmático fue el lanzamiento por Getty Images de herramientas propias de IA generativa entrenadas sobre su librería fotográfica mediante un sistema de concesión de licencias ofrecidas por suscripción a través de API. Aquí la ventaja competitiva se apoya precisamente en el acceso autorizado a datos de calidad lo que, a su vez, se traduce en la posibilidad de ofrecer escenarios contractuales muy favorables para los usuarios, incluyendo garantías de goce pacífico. 

2.1.5. Transformación interna (IA como capacidad organizativa) 

Se trata de los supuestos en los que las empresas no ofertan IA, sino que se limitan a incorporarla dentro de sus procesos productivos con la finalidad de optimizarlos (p. ej. marketing, soporte, programación, análisis documental, etc.). Aquí no disponemos de un servicio de IA propio, sino de una mejora estructural de la organización. Esta ventaja no suele articularse mediante la generación de nuevos derechos de exclusiva dirigidos al mercado y se apoya, en su caso, en la protección del know-how y los secretos empresariales mediante una correcta gestión de la confidencialidad y el establecimiento, en su caso, de acuerdos de no competencia. 

2.1.6. El desplazamiento del valor a lo largo de la cadena de la IA

Como queda patente en este breve análisis sobre los distintos modelos de negocio basados en la IA, la ventaja competitiva se desplaza hacia activos infraestructurales (p. ej. datos, pipelines, adaptación, cumplimiento, etc.). Por ello, antes de discutir qué derechos de propiedad intelectual o industrial son adecuados para capturar valor, debemos comenzar por ubicar el modelo de negocio en su posición real dentro de la cadena de valor, porque de ahí dependerán sus dependencias de terceros, la posibilidad de generar derechos de exclusiva valiosos, y los condicionantes contractuales a los que debe sujetarse. 

2.2. Geopolítica del cómputo y barreras de entrada

Aunque sea de forma breve, no queremos dejar de apuntar a la importancia de la capacidad de cómputo en el mercado de la IA generativa. El entrenamiento y la operación de modelos GPAI, especialmente de los más avanzados, exige acceso a hardware especializado, infraestructuras de alto rendimiento, energía y talento altamente concentrados. Ese conjunto configura una geografía desigual de capacidades que, a su vez, condiciona quién puede producir modelos y quién, en la práctica, los adopta, integra y despliega. Así, el stack de la IA generativa tiene una dimensión geopolítica que se traduce en barreras de entrada y dependencias contractuales muy relevantes para empresas europeas.

2.2.1. El cómputo como recurso estratégico: de la carrera tecnológica a la estructura de mercado.

Parte de la literatura sobre economía política de la regulación de la IA distingue entre Estados proveedores y adoptantes. Son proveedores los Estados capaces de producir modelos GPAI y aprovechar esa capacidad. Por el contrario, son Estados Adoptantes aquellos que, no contando con las capacidades necesarias para desarrollar sus propios modelos GPAI, se orientan a capturar valor mediante el uso. 

En la Unión Europea, aun contando con capacidades científicas notables, no contamos con modelos GPAI relevantes. Así, una parte sustancial del tejido empresarial compite aguas abajo a través de datos, integración sectorial y cumplimiento. La consecuencia es que el cómputo y el acceso a los modelos más avanzados actúan como cuello de botella, de forma que quien controla esa capa puede imponer condiciones técnicas y contractuales al resto de la cadena de valor, incluyendo restricciones de uso, cambios de versión, límites de responsabilidad y, en definitiva, trasladando del riesgo.

2.2.2. Dependencias del stack y riesgo de bloqueo del ecosistema.

Para parte de la literatura económica, estas dinámicas pueden producir un efecto lock-in o de bloqueo del ecosistema debido a la concentración de poder en unos pocos operadores que controlan recursos esenciales de la IA generativa. Lo que denuncian es que, si no se corrige, un número reducido de actores puede consolidar su dominio sobre la capacidad de cómputo, los modelos GPAI y los canales de acceso al mercado.

Para una empresa europea, este bloqueo no es sólo un problema técnico, sino riesgo jurídico y económico. El proveedor de la infraestructura puede tratar de condicionar el contenido del contrato, modificar unilateralmente las condiciones de uso, limitar determinadas funcionalidades, restringir el acceso a los datos generados o alterar las políticas de cumplimiento. En términos operativos, estas dependencias suelen manifestarse respecto de la infraestructura, del modelo GPAI, de datos y herramientas y de canales de distribución. Huelga decir que, cuanto más crítica sea la dependencia, más importante es mitigar el riesgo, como vamos a exponer a continuación. 

2.2.3. Construir sobre modelos e infraestructura no UE: implicaciones y medidas de mitigación

Aun siendo plenamente conscientes de la dependencia tecnológica, para muchas empresas europeas el camino más realista pasa por construir sobre infraestructura y modelos de terceros, modelos frontera que con frecuencia se encuentran fuera de la Unión Europea. Esta dependencia presenta desventajas evidentes, pero al mismo tiempo puede ser la única vía para acceder a tecnología de última generación, reducir costes de entrada y acelerar la innovación. 

Desde una perspectiva jurídica, los riesgos más habituales se manifiestan en varios planos. En primer lugar, existe el riesgo de cambios unilaterales en las condiciones del servicio: el proveedor puede modificar precios, límites de uso, funcionalidades o versiones del modelo, afectando directamente a la continuidad del producto o servicio desarrollado por el operador downstream. En segundo lugar, aparece el riesgo de falta de portabilidad, no solo de los datos, sino también de la integración técnica y de los flujos de trabajo construidos sobre un proveedor concreto, lo que puede dificultar o encarecer una eventual migración. En tercer lugar, deben considerarse los problemas asociados a la localización de los datos y al posible acceso por autoridades de terceros Estados, especialmente cuando la estructura corporativa del proveedor o la arquitectura del servicio dispersan el tratamiento entre distintas jurisdicciones. Finalmente, existe una asimetría probatoria relevante ya que, quien responde frente al cliente, al inversor o al regulador no siempre controla la información necesaria para acreditar el cumplimiento normativo o reconstruir técnicamente lo sucedido.

Ahora bien, la existencia de estos riesgos no significa que construir sobre modelos o infraestructura no europeos sea inviable. Lo que exige es incorporar la dependencia al propio diseño del producto y de la estrategia jurídica. En la práctica, deben evitarse dependencias absolutas de un único proveedor, incorporar criterios de sustitución razonable, diseñar arquitecturas técnicas que faciliten la migración y trasladar esas cautelas también al plano contractual. Desde esta perspectiva, la portabilidad deja de ser una cláusula de estilo y pasa a convertirse en un instrumento central de gestión del riesgo.

En este contexto, cobran especial importancia las cláusulas relativas a continuidad del servicio, cooperación técnica, gestión de cambios, disponibilidad de registros, auditoría y planes de salida. La dependencia no desaparece, pero puede transformarse en una relación jurídicamente estructurada y, hasta cierto punto, gobernada. Es decir, la posición competitiva no depende únicamente de acceder al mejor modelo disponible, sino de evitar que esa dependencia nos impida cumplir aguas abajo con los compromisos asumidos frente a clientes o autoridades.

No obstante, tampoco conviene adoptar una visión ingenua. En la actualidad, Muchas empresas europeas siguen dependiendo de un mercado fuertemente concentrado en Estados Unidos y China, tanto en modelos frontera como en infraestructura crítica. Ello limita la capacidad real de negociación y obliga a reconocer que, en numerosos casos, la mitigación jurídica solo puede reducir parcialmente una asimetría económica y tecnológica mucho más profunda.

2.3. Transformación estructural de los intangibles en la economía de la IA generativa: desplazamiento del eje de exclusividad hacia activos infraestructurales

Como acabamos de comprobar, los modelos de negocio basados en IA generativa obligan a replantear dónde se localiza el valor y qué activos permiten capturarlo de forma sostenible. 

En la UE, y en la mayoría de los países de nuestro entorno, los outputs generados de forma autónoma por un sistema de IA no son susceptibles de protección por el Derecho de autor, que requiere una aportación creativa humana. Por lo tanto, si el resultado individual del servicio no es apropiable por defecto, el valor tiende a fijarse en otras capas del stack y, sobre todo, en activos infraestructurales y organizativos donde el control sí es técnica y jurídicamente posible.

2.3.1. El dato como input estratégico

En los últimos años, el entrenamiento de modelos de IA generativa se ha basado, en gran medida, en la recopilación masiva de contenidos disponibles en internet mediante técnicas de rastreo y extracción automatizada (scraping). Esta práctica ha generado una fricción creciente entre desarrolladores de sistemas de IA y titulares de derechos ya que, en muchos casos, los contenidos utilizados para el entrenamiento no han sido autorizados. 

El núcleo del debate jurídico en la Unión Europea reside en determinar si estos actos de recopilación y análisis pueden quedar amparados por las excepciones de minería de textos y datos (“TDM” por sus siglas en inglés) previstas en la Directiva sobre los derechos de autor en el mercado único digital (“DMUD”), o si, por el contrario, constituyen actos de reproducción y/o extracción no autorizados. La respuesta no es uniforme y depende de factores como el acceso lícito a los contenidos, la existencia de reservas de derechos (opt-out) o la finalidad del uso. La situación es similar en Estados Unidos, donde los desarrolladores están buscando el amparo de las excepciones de uso justo o fair use. 

En este contexto, el dato deja de ser un mero insumo técnico y pasa a convertirse en un input estratégico en sentido pleno, ya que se vuelve un factor de producción que condiciona las capacidades del modelo. Pero, al mismo tiempo, supone un foco de fricción jurídica no resuelta, porque su obtención y uso pueden activar responsabilidad y las decisiones judiciales son escasas y heterogéneas. 

Una parte relevante de la literatura económica insiste en que las políticas públicas no deberían centrarse en compensar el pasado, sino en preservar incentivos para el flujo futuro de datos de alta calidad, porque es ese flujo el que sostiene el valor de los modelos a lo largo del tiempo. Ahora bien, en un contexto de incertidumbre jurídica y competencia global, este diagnóstico admite dos posibles lecturas. 

Por un lado, la visión del riesgo como desventaja competitiva. En este escenario se plantea que, si en determinadas jurisdicciones el entrenamiento finalmente queda cubierto por excepciones amplias (p. ej., bajo lógicas de fair use en Estados Unidos o de minería de textos y datos en la UE), un sistema de licencias costoso y complejo puede convertir el cumplimiento en un coste asimétrico, de forma que quien sí paga por los datos de entrenamiento puede quedar en desventaja frente a quien entrena con menores costes. Un sector de la doctrina entiende que la proliferación de sistemas de remuneración muy estrictos puede perjudicar a la industria europea frente a otros marcos normativos más flexibles, e incluso empujar el entrenamiento hacia regiones más favorables, dando lugar a un escenario donde todos pierden, ya que no se produce entrenamiento ni, en consecuencia, remuneración. 

La visión opuesta es la del cumplimiento como condición de mercado. Desde esta perspectiva, se asume que la UE puede exportar sus estándares en una suerte de nuevo “Efecto Bruselas”. Así, si el acceso al mercado de la UE depende de cumplir reglas estrictas (p. ej. reservas de derechos, políticas de propiedad intelectual, mecanismos de transparencia, etc.), el incentivo puede acabar siendo el alineamiento con los estándares más estrictos para evitar la exclusión de los mercados con elevados estándares de cumplimiento. En este sentido, parte de la doctrina entiende que el marco regulador de la UE puede desencadenar una nivelación en la cúspide, en el sentido de que los proveedores acaben adoptando las normas más exigentes. 

Siendo este el debate, toca gestionar incertidumbre y riesgos. En escenarios de alta exposición, propios de entornos altamente regulados, los mecanismos de licencia y remuneración pueden ser una forma valiosa de convertir el dato en un activo diferencial que otorga un plus de seguridad a los usuarios. Por el contrario, en escenarios de competencia por coste y baja diferenciación, un sistema de clearance muy costoso puede acabar siendo un lastre si el mercado premia la escala y otros competidores operan con menores fricciones. La propia OCDE se ha hecho eco de esta tensión como un problema estructural, donde el scraping activa riesgos de infracción, las excepciones varían ampliamente entre jurisdicciones y las opciones de políticas públicas tienen impactos difusos sobre incentivos e innovación. 

En este contexto, puede ser prudente establecer una estructura por capas que combine datos propios o licenciados cuando aporten calidad o seguridad jurídica con una gobernanza que permita demostrar cómo se obtuvieron y usaron. Para ello la trazabilidad y conservación de evidencias es clave, ya que el desarrollador debe estar en posición de acreditar cuál es el origen de sus datasets y, de poder hacerlo, tratar de capitalizar este activo. 

2.3.2. La regulación como activo y como barrera

En los mercados de la IA generativa el cumplimiento normativo puede verse como un coste o como una capacidad organizativa que habilita el acceso al mercado, reduce riesgos legales y reputacionales, y permite operar en sectores altamente regulados, pudiendo funcionar como propuesta de valor diferencial. De nuevo, no debemos ignorar que este activo puede ser relevante en mercados que requieren de elevados estándares de cumplimiento pero que, en otros, masivos, puede situar a las empresas europeas en una clara situación de desventaja. 

En el marco UE esta lógica se intensifica por dos factores. Primero, por la propia estructura del régimen aplicable a los modelos GPAI, que combina obligaciones de transparencia y obligaciones conectadas con los Derechos de propiedad intelectual, pero deja abiertos puntos interpretativos relevantes (p. ej., escenarios open-source, efectos del fine-tuning en la cadena de valor, etc.). Segundo, porque esa incertidumbre convierte en diferencial la capacidad de cumplir y de acreditar el cumplimiento. Quien puede explicar qué hizo, con qué datos, qué medidas adoptó y qué controles aplica, puede competir con ventaja.

En este contexto, el Código de Buenas Prácticas para modelos GPAI cumple una función práctica de normalización y crea un lenguaje común sobre cumplimiento. La Comisión ha subrayado que, aunque voluntario, forma parte del sistema de aplicación del RIA. Así, aunque el Código no vincula a la Comisión en la interpretación del Reglamento ni prejuzga evaluaciones futuras, resulta un instrumento extremadamente útil para demostrar diligencia en materia de cumplimiento.

Por lo tanto, si la perspectiva de negocio pasa por ver el cumplimiento como una ventaja competitiva, la documentación y la trazabilidad asumen un rol principal. Si este es el valor del servicio, no basta con afirmar que se cumple, sino que hay que poder acreditarlo con políticas, inventarios de datos, registros de decisiones y evidencias técnicas, especialmente ante clientes sofisticados o en sectores regulados. 

2.3.3. El margen de creación y captura de valor para las empresas europeas

Con este marco, puede formularse una conclusión operativa para el tejido empresarial europeo, y es que no todas las empresas necesitan ni podrán competir en el entrenamiento de modelos propios. En la práctica, una parte sustancial del valor se capturará en capas posteriores, como la verticalización por sector, el ajuste a procesos empresariales y cumplimiento o la posibilidad de integración con sistemas de terceros.

Esta estrategia tiene, por otro lado, una derivada de riesgo que debemos apuntar, ya que quien adapta o modifica modelos de terceros puede alterar su comportamiento, lo que puede a su vez desplazar su responsabilidad en la cadena de valor. Por ello, el margen de creación y captura de valor en la UE pasa también por profesionalizar la capa de adaptación, documentarla, evaluarla y gobernarla, de modo que sea defendible frente a clientes, inversores y autoridades competentes. 

3. MAPA DE ACTIVOS JURÍDICAMENTE RELEVANTES Y ESTRATEGIAS DE PROTECCIÓN

En el apartado segundo hemos descrito un desplazamiento de valor característico en los modelos de negocio basados en IA generativa, analizando cómo en muchos de ellos la ventaja competitiva se decide menos en el output individual y más en activos infraestructurales. El objetivo de esta sección tercera es traducir ese diagnóstico en un mapa de activos jurídicamente relevantes y, sobre esa base, en estrategias de protección y asignación del riesgo.

3.1. Dataset de entrenamiento

Económicamente, la calidad, cobertura y actualización de los datos de entrenamiento condiciona de forma directa las capacidades del modelo y su rendimiento en campos específicos. En la práctica, la obtención de datos mediante scraping es un método central para alimentar modelos de IA, y en torno a él se concentran fricciones crecientes entre desarrolladores y titulares. En modelos GPAI, esta fase se realiza a escala masiva y con frecuencia intervienen terceros como proveedores de datasets o agregadores, que recopilan y preparan los datos antes de que el desarrollador del modelo entrene o adquiera el conjunto de entrenamiento, lo que desplaza parte del riesgo jurídico hacia la cadena de suministro.

Jurídicamente, la obtención y preparación de datos suele implicar actos de reproducción y/o extracción sobre contenidos potencialmente protegidos, como noticias, imágenes, contenidos audiovisuales, libros, o código. En escenarios donde el scraping se produce en abierto, sin autorización de los titulares, este proceso activa un entramado complejo de normas de acceso a los contenidos y de exclusión al acceso y extracción de datos para el entrenamiento de modelos de IA.

Desde la perspectiva de la normativa de propiedad intelectual de la Unión Europea, gran parte de las operaciones necesarias para construir un dataset y entrenar modelos, que suelen incluir la copia técnica temporal de contenidos y su análisis automatizado, se encuadran en la noción de TDM, actividad definida en el art. 2.2 DMUD como “toda técnica analítica automatizada destinada a analizar textos y datos en formato digital a fin de generar información que incluye, sin carácter exhaustivo, pautas, tendencias o correlaciones”. 

Esta definición es relevante porque el entrenamiento de modelos suele requerir, como paso previo, la realización de actos de explotación protegidos por la normativa de propiedad intelectual. Por ejemplo, reproducciones de contenidos literarios o fotografías protegidas, incluyendo la realización de copias temporales o permanentes para procesar el material y, en su caso, extracciones cuando se trabaja sobre bases de datos protegidas por el llamado derecho sui generis sobre bases de datos. Es decir, antes de que se proceda al entrenamiento del modelo ya se han producido actos de explotación que, en ausencia de autorización o de una excepción que los justifique, podrían suponer actos de infracción. Por lo tanto, la pregunta clave en la UE pasa por determinar si los actos de reproducción y extracción necesarios para construir un dataset, en ausencia de autorización, pueden quedar amparados por una excepción legal como la excepción de TDM. 

En este punto, la DMUD combina dos regímenes distintos. Por un lado, el artículo 3 de la Directiva reconoce una excepción de TDM muy amplia a los organismos de investigación e instituciones del patrimonio cultural, con finalidad de investigación científica, sometida a condiciones específicas de acceso lícito, seguridad y conservación de copias. Por otro lado, el artículo 4 establece una excepción general de TDM para cualquier beneficiario, incluidos usos comerciales, pero condicionada a dos requisitos estructurales. El primero, que el acceso al contenido sea lícito. El segundo, que el titular de los derechos de propiedad intelectual no haya realizado una reserva expresa de derechos u opt-out para excluir el entrenamiento. En términos prácticos, esto significa que, en el ámbito comercial, el opt-out del artículo 4(3) DMUD se convierte en el principal mecanismo de exclusión para los titulares de obras protegidas. La excepción opera por defecto, pero puede quedar neutralizada si el titular reserva sus derechos de forma válida. En consecuencia, para evaluar la licitud de un dataset en la UE debe analizarse que, en efecto, el dataset se ha compilado respetando las posibles reservas de derechos, una tarea nada sencilla desde el momento en el que no existe consenso sobre cuándo una reserva de derechos debe considerarse válidamente realizada. 

A este marco de propiedad intelectual se añade una capa regulatoria. Así, el RIA obliga a los proveedores de modelos GPAI que coloquen el modelo en el mercado de la Unión a disponer de una política para respetar el Derecho de autor de la UE y, en particular, para identificar y cumplir las reservas de derechos a las excepciones de TDM bajo el art. 4(3) DMUD. También deben elaborar y publicar un resumen suficientemente detallado del contenido utilizado para el preentrenamiento y entrenamiento, conforme a la plantilla suministrada por la Oficina Europea de IA, tal y como exige el art. 53(1)(d) RIA. 

En consecuencia, el dataset debe tratarse como un activo doble. Por un lado, como activo infraestructural que puede generar una ventaja por calidad y seguridad. Por otro lado, como factor de riesgo si, en supuestos de entrenamiento en abierto, no se puede acreditar que se han cumplido con los requisitos para la aplicación de las excepciones TDM. Además, no debe perderse de vista la necesidad de atender a la obligación de suministrar información sobre fuentes y métodos de obtención de datos sin que esto afecte a la posibilidad de proteger el dataset como secreto empresarial. 

3.1.1. Construcción lícita del dataset o entrenamiento “limpio”

Por entrenamiento limpio nos referimos aquí a un estándar operativo en el que el dataset debe poder reconstruirse y explicarse ex post, con una base jurídica identificable por fuente y con evidencias suficientes para responder a un requerimiento regulatorio, un procedimiento de due diligence en un contexto de inversión, o un litigio por infracción de derechos de propiedad intelectual. El objetivo es reducir puntos ciegos y diseñar procesos de trazabilidad conformes con el estado del arte.

En la práctica, la construcción lícita exige separar, al menos, tres escenarios. En primer lugar, los datos propios o licenciados a terceros, donde la clave pasa por asegurar que los términos de la licencia respetan la finalidad y características del entrenamiento. El segundo bloque sería el de los datos obtenidos sin autorización expresa, pero amparados por las excepciones TDM, donde la clave está en confirmar y poder acreditar, llegado el caso, que el acceso a los datos se ha producido de forma lícita, y que se han respetado los mecanismos de opt-out. El último bloque sería el de los datasets adquiridos a terceros, donde la clave pasa por una correcta asignación contractual del riesgo derivado de su uso mediante cláusulas de goce pacífico, así como la posibilidad de contratar seguros que cubran posibles actos infractores. 

3.1.1.1. Acceso lícito y scraping

El requisito de acceso lícito es, como decimos, el primer filtro. En términos prácticos significa, como mínimo, no obtener contenidos a través de fuentes manifiestamente ilícitas y no eludir medidas tecnológicas eficaces que controlen el acceso. El Código de Buenas Prácticas para modelos GPAI propone concretar este punto exigiendo, para el crawling de la web, compromisos de no eludir medidas tecnológicas eficaces y de evitar fuentes claramente identificadas por autoridades o tribunales como infractoras a escala comercial. Este tipo de estándar es relevante porque sitúa el debate donde realmente opera el riesgo, que es en el diseño del crawler y en la selección ex ante de fuentes.

Ahora bien, el acceso lícito no se agota en la dimensión tecnológica. La discusión europea se ha desplazado hacia la infraestructura y la gobernanza privada del acceso, incluyendo términos y condiciones de uso, lo que complica el análisis y puede introducir divergencias entre Estados miembros. Desde una perspectiva prudente, la empresa responsable del entrenamiento debe tratar las restricciones contractuales relevantes como un elemento de riesgo adicional, incluso si la discusión sobre su interacción con las excepciones de TDM sigue abierta. 

3.1.1.2. Gestión del opt-out

Como hemos avanzado, el art. 4(3) DMUD permite que el titular de la obra protegida pueda reservar derechos para excluir sus contenidos del TDM. Para contenidos disponibles en línea, la norma apunta a medios legibles por máquina. El RIA, por su parte, exige que los proveedores identifiquen y cumplan esa reserva mediante el uso de tecnologías dentro del estado del arte. El Código de Buenas Prácticas traslada esta exigencia al plano operativo, de modo que si el dataset se obtiene con web crawlers), estos deben leer y seguir las instrucciones que los titulares publican conforme al Robot Exclusion Protocol (robots.txt), según el IET RFC 9309. Además, el proveedor debe evitar la elusión de medidas técnicas de acceso y ofrecer información pública básica sobre el funcionamiento de su sistema de recopilación, de modo que los titulares puedan comprender cómo ejercer una reserva de derechos.

El punto crítico no es solo qué señal constituye un opt-out, sino que esa señal sea ejecutable y verificable a escala. La literatura reciente subraya que la reserva no puede depender de una interpretación caso por caso. Para ser efectiva, debe ser accionable por máquina y trazable a escala masiva. De lo contrario, se pierde seguridad jurídica para desarrolladores y control efectivo para los titulares. El aprendizaje para los desarrolladores pasa por la necesidad de diseñar su pipeline de ingesta de forma que pueda detectar señales de opt-out de manera automatizable, traducirlas a decisiones consistentes (p. ej., no indexar, no entrenar, excluir del dataset), y conservar evidencia del estado de esas señales en el momento de la captura.

3.1.1.3. Prueba y trazabilidad

Para demostrar cumplimiento, resulta razonable conservar al menos los logs de crawling, instantáneas versionadas de robots.txt y de otras señales relevantes en el momento del crawl, inventario del dataset, hashes y control de versiones del dataset y políticas de retención y borrado, incluida la capacidad de demostrar exclusión de URLs tras un opt-out. La correcta implementación de estas medidas no solo sirve para probar el cumplimiento ante el regulador o preparar la defensa en un proceso de infracción, sino que también se configura como base necesaria para establecer garantías contractuales adecuadas a lo largo de la cadena de valor.

El caso GEMA v OpenAI (2025) es un indicio de cómo se está tratando la capa probatoria en la UE. Prueba de ello es la forma en la que el tribunal analizó los pormenores de entrenamiento, incluyendo el uso de técnicas de scraping, el respeto de los mecanismos de exclusión y su eficacia. Sin necesidad de extrapolar su solución a todo el Derecho de la UE, el caso ilustra la dirección del problema, ya que sin registros y evidencias sobre los procesos de crawling y opt-out, la posición procesal del desarrollador se debilita.

3.1.2. Mecanismos de protección del dataset

Si el desarrollador consigue construir un dataset de alta calidad con gobernanza y trazabilidad, el siguiente paso es protegerlo como activo. Aquí conviene tener en cuenta que los datos en sí mismos no son automáticamente protegibles mediante la normativa de propiedad intelectual y que, en determinados escenarios, confiar exclusivamente en la protección del dataset como secreto empresarial puede no ser suficiente. En la práctica, la protección más eficaz puede ser una combinación de ambas. 

En primer lugar, puede existir protección por Derecho de autor sobre el dataset entendido como base de datos. La vía de protección puede ser doble. Por ejemplo, aplicable cuando la estructura del dataset pueda ser considerada original debido a sus parámetros de selección o disposición. La clave aquí es que, en efecto, se trate de una estructura original, un requisito extremadamente difícil de conseguir (art. 12 TRLPI). 

De forma adicional, el Derecho de la UE reconoce una protección sui generis de bases de datos, aunque no sean originales, cuando el fabricante pueda acreditar que se ha llevado a cabo una inversión sustancial en la obtención, verificación o presentación del contenido. Acreditada la inversión en este proceso compilador, surgirá la facultad de prohibir la extracción o reutilización de la totalidad o de una parte sustancial (art. 133 y ss. TRLPI). Esta figura puede ser de extremada utilidad contra el uso no autorizado del dataset por terceros, especialmente en aquellos supuestos en los que dicho uso afecte a la capacidad del titular de recuperar su inversión en la fabricación del dataset.

La obtención de derechos de exclusiva sobre el dataset también puede conseguirse, en la práctica, mediante mecanismos contractuales de acceso que prohíban o limiten la extracción automatizada. Ahora bien, su eficacia dependerá de que esas condiciones sean vinculantes. En España, no es tarea sencilla, ya que nuestros Tribunales exigen que la aceptación de las condiciones de uso sea expresa (i.e. click-wrap), no siendo suficiente la mera publicación en la web (i.e. browse-wrap).

De forma adicional, la protección de los datos puede reforzarse con controles tecnológicos de acceso, como sistemas de autenticación, claves, limitación de solicitudes, bloqueo de bots, etc. Cuando dichos controles constituyen “medidas tecnológicas eficaces” en el sentido del art. 196 TRLPI, la elusión deliberada puede activar acciones específicas contra actos de elusión y contra actos preparatorios, al margen de la vía contractual. 

En cuarto lugar, el secreto empresarial puede ser de extrema utilidad para proteger aspectos no divulgados del dataset, como la composición del corpus, criterios de limpieza, señales de calidad, listas de exclusión o metodologías de anotación. No obstante, la protección no es automática, y exige la adopción de medidas razonables de confidencialidad que, llegado el momento, puedan acreditarse. Ahora bien, recordemos que en relación con los modelos GPAI, existen aspectos del dataset que deben publicarse para cumplir con las obligaciones del RIA en materia de transparencia. En el caso de los modelos GPAI, el proveedor debe documentar y publicar información sobre los datos de entrenamiento, en particular un resumen suficientemente detallado conforme a la plantilla de la Oficina Europea de IA. El capítulo de transparencia del Código de Buenas Prácticas reconoce expresamente que parte de la documentación puede ser necesaria en forma resumida para cumplir con ese resumen público. Por tanto, la protección del dataset debe diseñarse asumiendo un equilibrio entre las obligaciones de transparencia del RIA y el derecho del proveedor a preservar su información confidencial.

3.2. Pesos y arquitectura del modelo

El modelo de IA constituye también un activo en sí mismo, respecto del cual conviene distinguir entre su arquitectura y sus parámetros o pesos. Desde el punto de vista empresarial, esta distinción no es meramente técnica, sino que tiene consecuencias directas en la forma de explotación del modelo. En la práctica, lo que se comercializa no suele ser el código en abstracto, sino el acceso remoto al modelo como servicio (por ejemplo, mediante una API), o la puesta a disposición de sus parámetros entrenados para que terceros los ejecuten en su propia infraestructura. Esta diferencia condiciona tanto el grado de control técnico del proveedor como los instrumentos jurídicos disponibles para proteger el modelo y gestionar los riesgos derivados de su uso.

Esta diferencia no es menor. Cuando el proveedor mantiene el modelo en su infraestructura y solo permite el acceso remoto, conserva un mayor control técnico y contractual sobre su uso. En cambio, cuando distribuye los pesos, los llamados open weights, se reduce el control directo sobre el activo técnico y la gobernanza se desplaza hacia el régimen de licencia. En consecuencia, la elección entre modelo servido y distribución de pesos condiciona tanto la capacidad de exclusión como los riesgos asociados y determina qué instrumentos jurídicos resultan más eficaces para su protección.

3.2.1. Vías de protección

Desde la perspectiva de la propiedad intelectual, el código que implementa la arquitectura y la inferencia se aproxima al régimen clásico de software, por lo que puede quedar protegido como programa de ordenador en la medida en que haya una expresión original. Por su parte, y como ya ha establecido el TJUE de forma reiterada, la funcionalidad, los lenguajes de programación o las ideas y principios subyacentes no pueden ser monopolizados a través de la normativa de propiedad intelectual. En ciertos casos, además, elementos concretos de la arquitectura o del proceso de entrenamiento podrían intentar patentarse, aunque debe tenerse en cuenta que en la UE los programas de ordenador no suelen ser patentables a menos que encajen en la categoría de invenciones implementadas por ordenador.

Mayor dificultad entraña la protección de los pesos y, con ello, la captura de su valor competitivo. Cabe plantearse si en determinados supuestos podrían encajar en el derecho sui generis sobre bases de datos. No obstante, no es una vía exenta de dificultades, ya que la protección sui generis protege la inversión en la obtención, verificación o presentación del contenido, no la inversión en la creación del contenido. La jurisprudencia del TJUE ha sido particularmente restrictiva al separar inversión compilatoria e inversión creativa, lo que obliga a plantear esta vía con cautela.

En este contexto, la protección más robusta puede partir de una combinación de protección de secretos empresariales, controles de acceso y medidas tecnológicas complementarias. En particular, cuando el valor reside en pesos no publicados, el régimen de secreto empresarial suele ofrecer una palanca más realista que intentar forzar una protección autoral sobre matrices numéricas. Por el contrario, la publicación de pesos conlleva renunciar al secreto como vía de protección, de forma que la capacidad de exclusión pasa a depender de la eficacia del régimen de licencia y de la posibilidad de acreditar que se han aceptado sus términos de forma expresa. 

3.2.2. Un breve apunte sobre el problema de la memorización

La memorización se produce cuando el modelo retiene contenido de su dataset de entrenamiento, de forma que, bajo determinadas circunstancias, puede llegar a reproducirlo posteriormente. Imaginemos, por ejemplo, que una obra literaria utilizada para el entrenamiento queda memorizada y el sistema genera fragmentos sustancialmente coincidentes con el texto original. No se trata de un efecto inocuo, ya que puede suponer la infracción de derechos de propiedad intelectual de terceros cuando el dataset se ha construido al amparo de las excepciones TDM que, como ya hemos expuesto, no alcanzan a actos de explotación distintos del entrenamiento.

El caso GEMA v OpenAI citado es especialmente interesante a este respecto. El tribunal parte de la premisa de que el modelo no almacena las obras como archivos legibles, sino que las retiene de forma distribuida en sus parámetros matemáticos. Sin embargo, rechaza que esta naturaleza numérica excluya la posibilidad de reproducción. A juicio del tribunal, si determinados fragmentos de una obra quedan fijados, aunque sea indirectamente, en la configuración del modelo, y pueden hacerse perceptibles posteriormente mediante prompts adecuados, ello puede constituir reproducción en el sentido del derecho de autor. Es decir, no estamos ante la reproducción de una obra identificable, sino ante la capacidad del sistema para reconstruir de forma sustancial el contenido protegido. En este sentido, la memorización no es simplemente un fenómeno técnico inocuo, sino que puede convertirse en el presupuesto de una reproducción ulterior. La excepción de TDM puede cubrir los actos instrumentales de reproducción necesarios para el entrenamiento, pero no ampara, como regla general, la generación posterior del contenido protegido como output. De este modo, el modelo puede funcionar, en determinados supuestos, como un mecanismo que facilita o materializa actos de explotación no autorizados. Ahora bien, cabe entender que la mera potencialidad técnica de generar un fragmento protegido no debería equipararse automáticamente a reproducción jurídicamente relevante. Si el proveedor ha implementado mecanismos eficaces que impiden la exteriorización del contenido memorizado, la relevancia de la fijación interna debe analizarse con cautela, especialmente desde la perspectiva de la explotación efectiva de la obra.

La literatura técnica está desarrollando métodos para medir y reducir estos fenómenos como, por ejemplo, estimar la probabilidad de que un output sea “regurgitación” de material de entrenamiento y aplicar técnicas de mitigación para estos escenarios. Desde el punto de vista práctico, el hilo vuelve a la gobernanza del modelo y a la necesidad de evaluar, registrar y ajustar salvaguardas para impedir o reducir el riesgo de memorización.

3.3. Prompts y prompts de sistema estructurados

Además del modelo, el rendimiento de los sistemas de IA también depende de sus capas de orquestación, incluyendo prompts, plantillas, prompts de sistema, reglas de conversación, herramientas de selección de contexto y políticas de filtrado, entre otras. En especial en servicios orientados a la empresa, el know-how del prestador puede materializarse en prompts de sistema estructurados (p. ej. instrucciones, ejemplos, criterios de estilo, restricciones y flujos, etc.), que convierten un modelo generalista en uno especializado y sujeto a parámetros de actuación más consistentes y controlables.

Desde la perspectiva de la protección, el prompt aislado suele tener naturaleza funcional y, además, puede ser breve, por lo que su protección como obra original mediante la normativa de propiedad intelectual suele ser compleja, aunque no imposible. No obstante, la compilación de repositorios de prompts podría obtener protección a través del derecho sui generis sobre bases de datos o, en su caso, como secreto empresarial. El secreto también puede resultar la vía idónea para otros activos, como las cadenas de prompts (multi-step), las skills, o el desarrollo de sistemas de evaluación y selección de prompts. 

Siendo este el contexto, una protección adecuada exige el uso de cláusulas de confidencialidad y medidas técnicas de limitación de acceso. Esto es especialmente importante porque la filtración de prompts de sistema puede permitir a terceros replicar el comportamiento del servicio o incluso explotar vulnerabilidades mediante técnicas de prompt injection. 

3.4. Sistemas de fine-tuning y RAG

En buena parte de los modelos de negocio downstream, especialmente en entornos empresariales, la ventaja competitiva no proviene de entrenar un modelo desde cero, sino de adaptar modelos base existentes a un campo específico, a un cliente o a un proceso. Esa adaptación suele llevarse a cabo mediante técnicas de fine-tuning o RAG.

Esta capa de adaptación es jurídicamente relevante por tres razones. Primera, porque suele ser la capa donde se introducen datos propios o de cliente, con el riesgo que esto conlleva. Segunda, porque la adaptación puede cambiar de manera material el comportamiento del modelo y sus guardarraíles y demás salvaguardas. Tercera, porque de conformidad con el art. 25 del RIA, determinadas modificaciones pueden desplazar el rol regulatorio del actor que, por ejemplo, puede pasar de responsable del despliegue a proveedor del modelo modificado, lo que impacta directamente en sus obligaciones de cumplimiento. 

Desde un punto de vista técnico, el fine-tuning consiste en continuar el entrenamiento de un modelo pre-entrenado sobre un dataset adicional para mejorar rendimiento en tareas específicas o inducir comportamientos como, por ejemplo, estilo, formato, tono o respuestas adaptadas a un campo específico. Puede realizarse de forma completa, lo que supone ajustar gran parte de los parámetros, o mediante métodos de adaptación eficiente que añaden una capa adicional sin modificar todos los parámetros del modelo. En cambio, el RAG opera a nivel de interfaz, de modo que el sistema recupera documentos o fragmentos relevantes desde una base de conocimiento o repositorio en tiempo de consulta y los incorpora como contexto, sin alterar necesariamente los pesos ni el dataset de entrenamiento del modelo base.

Esta distinción tiene consecuencias prácticas desde el punto de vista del modelo de negocio. En el fine-tuning, lo habitual es que el activo con mayor valor sea el modelo en sí, como activo susceptible de comercialización. Por el contrario, en los escenarios RAG el activo valioso pasa a ser el corpus y su índice de recuperación, por lo que el riesgo se desplaza a la gobernanza del contenido recuperado y hacia el diseño del sistema.

3.4.1. Vías de protección

En el fine-tuning, los activos típicos protegibles incluyen el dataset de ajuste, los pesos ajustados y el pipeline de entrenamiento y evaluación. Como ya hemos visto, la protección del dataset puede articularse principalmente a través del derecho sui generis de bases de datos y, en su caso, del secreto empresarial, a lo que se unen posibles restricciones de uso vía contractual. Por su parte, los adaptadores y pesos resultantes del fine-tuning suelen protegerse como secreto empresarial cuando no se publican. 

En el RAG el valor se concentra en el corpus o base de conocimiento, el índice de recuperación, los conectores y reglas de selección del contexto, y los controles de seguridad. En consecuencia, además del secreto empresarial, el derecho sui generis sobre bases de datos puede jugar un papel defensivo muy relevante cuando existe inversión sustancial en la obtención, verificación y presentación del corpus.

En ambos sistemas, la protección y la gestión del riesgo es igualmente importante, ya que, si el valor se concentra en el corpus, se vuelve crítico reducir el riesgo de outputs infractores o de fugas de contenido. El Código de Buenas Prácticas para modelos de propósito general propone, precisamente, medidas técnicas y de política de uso para mitigar el riesgo de outputs que reproduzcan contenido de entrenamiento de manera infractora, así como prohibiciones de uso infractor en políticas de uso aceptable o T&C. Aunque no sustituye el análisis de legalidad del corpus o del entrenamiento, este tipo de salvaguardas tiene valor empresarial, ya que permite ofrecer garantías contractuales más realistas y sostener una diligencia debida más robusta.

3.4.2. Consecuencias de la modificación sustancial del modelo bajo el RIA

El artículo 25 del RIA prevé la posibilidad de que una empresa que actuaba inicialmente como responsable del despliegue de un sistema de IA, pueda pasar a ser considerado proveedor si lleva a cabo actuaciones que supongan una modificación sustancial de ese sistema. Por lo tanto, procesos como el fine-tuning pueden tener implicaciones más que relevantes en la estrategia de adopción de la IA. La pregunta que surge de forma automática es ¿cuándo puede entenderse que una modificación es “sustancial” y hace recaer sobre el modificador obligaciones propias del proveedor? 

La literatura identifica un riesgo doble. Por un lado, si el umbral de sustancialidad es muy bajo, se corre el riesgo de ralentizar la innovación y de imponer gravosas cargas regulatorias a actores que, en realidad, están llevando a cabo modificaciones leves. Por el contrario, si el umbral pasa a ser muy elevado, se abre la posibilidad de que determinados actores acaben eludiendo sus obligaciones bajo el RIA alegando que se trata de modificaciones “no sustanciales” pese a que, en realidad, sí están alterando el comportamiento del sistema o los riesgos que lleva aparejado su uso. 

La Comisión Europea, en sus materiales orientativos, propone una aproximación cuantitativa, entendiendo que la modificación debe considerarse sustancial si el cómputo dedicado a la misma supera un tercio del cómputo empleado para entrenar el modelo original. Cuando el modificador no pueda conocer ese dato, se sugiere recurrir a umbrales de FLOPs.

Esta aproximación puede ser insuficiente ya que, como ha señalado la literatura reciente, el cómputo no siempre refleja el calado de la modificación ni mucho menos sus consecuencias. Por ejemplo, hay modificaciones de bajo cómputo que introducen cambios de comportamiento significativos (p.e. ciertas variantes del fine-tuning, in-context adaptations o la adición de componentes RAG) y otros que suponen un cómputo elevado que no introducen modificaciones sustantivas. Por otro lado, existen métodos de fine-tuning muy eficientes (p. ej. LoRA) que requieren mucho menos cómputo, pero pueden introducir capacidades o riesgos significativos. Siendo así, creemos que es prudente tomar las indicaciones de la Comisión como lo que son, indicaciones, y promover la adopción de otras metodologías que combinen el esfuerzo computacional con otros factores como la realización de evaluaciones de impacto o de las consecuencias introducidas por la modificación. 

En términos jurídicos y de cumplimiento, la consecuencia práctica es clara, ya que toda estrategia de fine-tuning que pretenda ser comercializable debe diseñarse desde el inicio con documentación, trazabilidad y gobernanza, asumiendo la posibilidad de caer en el rol de proveedor del modelo modificado.

Finalmente, aunque este artículo se centra en activos intangibles, conviene subrayar que la problemática de las modificaciones sustanciales es especialmente relevante respecto de los sistemas de alto riesgo. En este contexto, la Comisión ya ha indicado que cuando un sistema de alto riesgo evoluciona y sufre modificaciones sustanciales, puede ser necesaria una nueva evaluación de conformidad. Desde un punto de vista práctico, tengamos en cuenta que, en materia de productos regulados, la ventaja competitiva puede consistir, precisamente, en gobernar las modificaciones de forma adecuada. 

3.5. Output generado

La normativa de propiedad intelectual europea entiende el concepto de “obra” como creación original, entendida como aquella en la que la expresión debe ser resultado de decisiones libres y creativas que reflejen la personalidad del autor. En España, además, la normativa de propiedad intelectual vincula la condición de autor a la persona natural, ya que “se considera autor a la persona natural que crea alguna obra literaria, artística o científica”. Por tanto, el punto de partida es, con carácter general, la imposibilidad de proteger como obra autoral los outputs obtenidos mediante el uso de la IA, sin perjuicio de otras posibles vías de protección como la marca o el secreto empresarial. 

En este contexto, y sin tener en cuenta cuestiones relacionadas con la calidad y la precisión del servicio, el output generado por los sistemas de IA debe abordarse desde una perspectiva de riesgo, en el sentido de que debido a la forma de entrenamiento de los modelos GPAI, es posible su coincidencia con obras de terceros o prestaciones protegidas. De ahí que los modelos de negocio basados en IA generativa deban diseñarse asumiendo que puede existir una exposición a reclamaciones por infracción si el sistema llega a reproducir elementos protegidos. En la práctica, esto obliga a combinar medidas técnicas con una estructura contractual que distribuya riesgos y responsabilidades a lo largo de la cadena de valor, incluyendo el establecimiento de garantías y, cuando sea viable, mecanismos de indemnidad).

3.5.1. Titularidad

En materia de titularidad, y aunque hemos dicho que los outputs generados carecen en general de protección autoral, esto no significa que todo el contenido generado con ayuda de IA quede automáticamente excluido del ámbito de protección del Derecho de autor. La cuestión clave es si el humano ha utilizado la IA como herramienta subordinada dentro de un proceso creativo controlado, o si la IA ha operado como instrumento creativo principal, dejando al usuario en un plano de instrucciones genéricas o meramente funcionales. Si el objetivo de la empresa es acreditar que sus obras han sido creadas por humanos, pese a la intervención o asistencia de una IA, la clave estará en poder acreditar que, en efecto, ha sido así. Por ejemplo, preservando prueba sobre la existencia de procesos creativos específicos, incluyendo versionado, bocetaje, prompts, selección de variantes, postproducción o identificación de aportaciones humanas, entre otros elementos probatorios).

3.5.2. Responsabilidad por infracción de derechos de terceros

Por otro lado, que el output no esté protegido por el Derecho de autor no lo convierte en material libre de derechos. Por el contrario, el output puede infringir derechos de terceros si reproduce total o parcialmente obras protegidas o si incorpora signos distintivos de forma no autorizada. 

La atribución de responsabilidad no es automática. El usuario que introduce el prompt y utiliza el resultado puede incurrir en infracción directa, pero ello no excluye que el proveedor del sistema o del modelo pueda responder, en determinadas condiciones, ya sea por responsabilidad indirecta o incluso por responsabilidad directa. Esta línea de análisis conecta con la jurisprudencia europea sobre plataformas y comunicación al público, que atiende al papel del operador y a si implementa o no medidas adecuadas para combatir la infracción.

Un indicador de la relevancia jurídica del output como riesgo es la existencia de una cuestión prejudicial centrada explícitamente en respuestas de chatbots ante el TJUE en el asunto C-250/25, Like Company v Google Ireland. El órgano remitente pregunta, entre otras cuestiones, si la visualización en un chatbot de texto parcialmente idéntico al de publicaciones de prensa constituye un acto de comunicación al público en el sentido del art. 15 DMUD y del art. 3.2 de la Directiva Infosoc. La importancia práctica del pronunciamiento es innegable ya que, si el TJUE responde afirmativamente, los proveedores podrían verse obligados a negociar licencias o acuerdos con editores para operar a escala. 

Por su parte, el caso Getty Images v Stability AI en Reino Unido ilustra cómo la gestión del riesgo del output condiciona tanto el diseño del sistema como la estrategia procesal. En su sentencia, el High Court dejó constancia de que Getty desistió de su pretensión relativa a determinados outputs porque los prompts necesarios para generar los ejemplos presuntamente infractores habían sido bloqueados por Stability, de modo que el remedio pretendido quedaba, en buena medida, satisfecho. La enseñanza es clara: medidas como el bloqueo de prompts, filtros de salida o políticas de uso pueden tener un impacto directo en el riesgo jurídico y reputacional, y pueden redefinir el litigio. Sorprende, la diferencia de enfoque entre el tribunal británico y el alemán en el caso GEMA v OpenAI que ya hemos analizado. 

3.5.3. Asignación contractual de titularidad y riesgo

Dadas las dudas más que razonables sobre la protección del output a través de la normativa de propiedad intelectual, las relaciones entre proveedor y usuario (responsable del despliegue) suelen llevarse a cabo en el plano contractual. En primer lugar, lo habitual es establecer una cesión o licencia “en la medida en que existan derechos” y, en muchos casos, la advertencia expresa de que pueden subsistir derechos de terceros y una limitación de responsabilidad al respecto. Para la empresa cliente usuaria del servicio, trabajar bajo un esquema de responsabilidad AS IS puede ser inasumible, por lo que ciertos proveedores han optado por conceder garantías de indemnidad respecto de posibles infracciones de propiedad intelectual por outputs infractores. 

En este escenario, es lógico que el proveedor trate también de protegerse mediante condiciones de uso, por ejemplo, prohibiendo prompts que induzcan a la infracción o la introducción en el sistema de materiales respecto de los cuales el usuario no dispone de autorización suficiente. El punto crítico es alinear esas cláusulas con medidas técnicas efectivas. Así, para ofrecer una indemnidad por output infractor de manera razonable, el proveedor debe tener control sobre el pipeline de generación, lo que incluye la existencia de filtros, logging, datasets licenciados, sistemas RAG con fuentes autorizadas y trazabilidad, entre otras medidas. En cambio, si el proveedor no controla el contexto porque, por ejemplo, el RAG lo alimenta el cliente, la asignación de riesgo debe pivotar hacia garantías del cliente sobre la licitud del corpus y su gobernanza.

A la luz de lo anterior, queda patente que los modelos de negocio de la IA no pueden seguir una estrategia que consista en ceder o licenciar derechos de propiedad intelectual donde no los hay. Pueden entrar en juego otros activos más relacionados con la gobernanza del sistema de IA, como una correcta determinación de las reglas de uso, sistemas de trazabilidad y preservación de evidencias y una correcta atribución de responsabilidad, incluyendo indemnidades realistas.

3.6. Derechos marcarios

Aun de forma breve, queremos deteneros en un riesgo adicional en materia de derechos marcarios, ya que los sistemas de IA generativa pueden generar o incorporar signos distintivos de terceros en outputs, lo que puede suponer una infracción de marca o la comisión de actos de competencia desleal. A modo de ejemplo, en el caso Getty Images v Stability AI también se incluyeron acciones por infracción de marca y passing off, ligadas, entre otras cuestiones, a la aparición de marcas de agua de Getty en algunos outputs. De ahí la necesidad de salvaguardas técnicas y contractuales, como la implementación de guardarraíles, listas negras de exclusión y políticas de uso aceptable).

3.7. Interfaces y diseños

La interfaz (UI/UX) es la capa visible del servicio de IA generativa y, por tanto, un posible activo de diferenciación comercial. Sin embargo, en muchos productos el diseño de la interfaz, un chat con caja de texto, historial y botones tiende a estandarizarse, lo que reduce la posibilidad de obtener un valor diferencial mediante derechos de exclusiva. Cuando sí existe un diseño novedoso y singular debido, por ejemplo, al uso de ciertos dashboards, flujos de trabajo, iconografía, organización visual de funciones o pantallas de control y auditoría, la interfaz podría llegar a ser protegible.

La protección jurídica de interfaces se articula principalmente por tres vías complementarias. Primero, el software subyacente, que se protege a través de la normativa de propiedad intelectual. En segundo lugar, la apariencia del producto puede protegerse como diseño industrial, registrado o no registrado, cuando concurren los requisitos de novedad y carácter singular, y siempre dentro de los límites de la funcionalidad. Por último, ciertos elementos visuales pueden alcanzar protección por derecho de autor si constituyen una creación original. 

Desde el punto de vista estratégico, la utilidad de esta vía depende del tipo de producto. En servicios generalistas, la interfaz suele ser poco diferencial. Sin embargo, en productos verticales, como el legaltech o el fintech; o en herramientas corporativas, la interfaz puede convertirse en un activo diferencial clave. 

3.8. Know-how y secretos empresariales

Como hemos visto, una parte sustancial de los activos que generan ventaja competitiva en relación con la IA generativa no encaja bien en las categorías clásicas de la propiedad intelectual e industrial. En esos casos, la vía del secreto empresarial cobra especial relevancia siempre que se combine con medidas técnicas y contractuales efectivas para el control de acceso. Esta vía de protección puede resultar especialmente útil respecto de los dataset, pipelines de limpieza y filtrado, metodologías de evaluación, procesos de red teaming, técnicas de alineamiento y mitigación, bibliotecas de prompts y prompts de sistema estructurados, y arquitecturas operativas de RAG, entre otros. 

El régimen europeo de protección de los secretos empresariales exige, no obstante, disciplinar el secreto como activo gestionado. La Ley de Secretos Empresariales requiere que la información sea secreta, tenga valor comercial por ser secreta y haya sido objeto de medidas razonables para mantenerla en secreto. Es decir, para pretender la protección de un activo como secreto empresarial, el titular debe estar en posición de acreditar la existencia de medidas razonables dirigidas a este fin. 

Por último, debe tenerse en cuenta que el secreto empresarial convive con obligaciones regulatorias de transparencia. La doctrina ha subrayado que, en el marco de los modelos GPAI, la información sobre datos y entrenamiento es simultáneamente una fuente de ventaja competitiva y un foco de obligaciones técnicas y de divulgación, donde el sistema pretende un equilibrio complejo entre secreto y transparencia. Así, el artículo 53 del RIA impone a los proveedores de modelos GPAI obligaciones de documentación técnica y la publicación de un resumen público del contenido utilizado para el entrenamiento. En términos estratégicos, esto obliga a diseñar mecanismos de transparencia que permitan cumplir el RIA preservando el núcleo del activo (p. ej., mediante resúmenes agregados, entornos controlados de auditoría y cláusulas de confidencialidad reforzada).

4. CONCLUSIONES

A lo largo de este trabajo hemos podido confirmar que, en efecto, los actuales modelos de negocio basados en IA generativa no construyen su ventaja competitiva en el output individual o, al menos, no es su capacidad de generar derechos de exclusiva sobre éste ya que, a día de hoy, la capacidad de crear obras protegidas por la propiedad intelectual sigue siendo una parcela reservada a los humanos. En este contexto, la estrategia jurídica debe empezar, por tanto, por identificar qué controla realmente la empresa en la cadena de valor de la IA y cómo podemos capturar su valor y obtener una ventaja competitiva. 

Hemos visto que el eje suele desplazarse hacia activos infraestructurales y organizativos. En primer lugar, el dataset y, sobre todo, el acceso recurrente a datos de calidad respecto de los cuales se puede demostrar licitud en origen, trazabilidad y capacidad de reconstrucción ex post. En segundo lugar, las capas de adaptación y los procesos, como el fine-tuning, los sistemas RAG o las capacidades de evaluación y monitorización; se erigen como factores capaces de convertir un modelo generalista en una herramienta fiable para determinados sectores, especialmente los altamente regulados. En tercer lugar, la documentación de cumplimiento y la preservación de evidencia también pueden convertirse en una condición de acceso en entornos empresariales y, con ello, en un factor diferencial. 

Desde el punto de vista de protección, no existe una fórmula mágica, siendo preferible optar por fórmulas mixta de protección que combinen derechos de propiedad intelectual e industrial, secretos empresariales y, de forma decisiva, contratos adaptados al modelo de negocio y controles técnicos dirigidos a controlar el acceso y el uso no autorizados. En particular, allí donde la tecnología se presta como servicio, una buena estructura contractual, acompañada de mecanismos de control de acceso adecuados, pueden ser la forma más eficaz de crear y mantener la ventaja competitiva.

Como abogados, no podemos dejar de tratar la IA generativa como una cadena de suministro en la que el valor se desplaza dependiendo del modelo de negocio y de las dependencias a las que está sujeto. Una gestión adecuada nos exige trascender de los tradicionales derechos de propiedad intelectual e industrial y buscar fórmulas más sofisticadas para capturar valor relacionadas, a menudo, con la posibilidad de acreditar una correcta construcción y utilización del sistema y de los datos que lo alimentan. En un mercado todavía inestable, el cumplimiento desde el diseño puede ser parte del valor diferencial del producto.

5. BIBLIOGRAFÍA

• Alexander PEUKERT; Céline CASTETS-RENARD, “Code of Practice for General-Purpose AI Models – Copyright Chapter”, Working Group 1, 2025.
• Alexander PEUKERT, “Regulating IP Exclusion/Inclusion on a Global Scale: The Example of Copyright vs. AI Training”, Faculty of Law Research Paper No. 3/2024, forthcoming in Liber amicorum Geertrui van Overwalle.
• Alexander XIONG; Xuandong ZHAO; Aneesh PAPPU; Dawn SONG, “The Landscape of Memorization in LLMs: Mechanisms, Measurement, and Mitigation”, 2025.
• Begoña GONZÁLEZ OTERO, “IA y derechos de autor: de la “legibilidad por máquina” a la “accionabilidad por máquina” en el opt-out de TDM, ¿vocabulario o gobernanza técnica?”, Garrigues Digital, 2 de febrero de 2026, disponible en: https://www.garrigues.com/es_ES/garrigues-digital/ia-derechos-autor-legibilidad-maquina-accionabilidad-maquina-opt-out-tdm.
• Christian PEUKERT, “The economics of copyright and AI: Empirical evidence and optimal policy”, Policy Department for Justice, Civil Liberties and Institutional Affairs (DG JUST), European Parliament (JURI Committee), In-Depth Analysis, PE 778.859, December 2025.
• Comisión Europea (AI Act Service Desk), “Frequently Asked Questions (AI Act): General questions | High-Risk AI Systems – How should evolving AI systems be handled?”. 
• Comisión Europea, AI Act Service Desk, “Frequently Asked Questions”, disponible en: https://ai-act-service-desk.ec.europa.eu/en/faq. 
• Comisión Europea (AI Act Service Desk), “Questions and answers on the code of practice for General-Purpose AI (General FAQ)”, 2025.
• Comisión Europea, Comunicación a la Comisión, “Approval of the content of the draft Communication from the Commission – Explanatory Notice and Template for the Public Summary of Training Content for general-purpose AI models required by Article 53(1)(d) of Regulation (EU) 2024/1689 (AI Act)”, Bruselas, 24 de julio de 2025, C(2025) 5235 final.
• Comisión Europea, press release, “Seven consortia selected to establish AI factories which will boost AI innovation in the EU”, Bruselas, 10 de diciembre de 2024, IP/24/6302.
• Comisión Europea, “Commission Opinion of 1.8.2025 on the assessment of the General-Purpose AI Code of Practice within the meaning of Article 56 of Regulation (EU) 2024/1689”, C(2025) 5361 final.
• Comisión Europea, “Guidelines on the scope of the obligations for general-purpose AI models established by the Regulation (EU) 2024/1689 (AI Act)”, Bruselas, 18 de julio de 2025, C(2025) 5045 final.
• Eleonora ROSATI, “Infringing AI: Liability for AI-Generated Outputs under International, EU, and UK Copyright Law”, European Journal of Risk Regulation, 2025, vol. 16, núm. 2, pp. 603–627, doi:10.1017/err.2024.72.
• João Pedro QUINTAIS, “Generative AI, Copyright and the AI Act”, v. 2.0” (1 de noviembre de 2024), Institute for Information Law (IViR), University of Amsterdam.
• Martin SENFTLEBEN, “Win-Win: How to Remove Copyright Obstacles to AI Training While Ensuring Author Remuneration (and Why the AI Act Fails to Do the Magic)”, 100 Chi.-Kent L. Rev. 7 (2025).
• Michael G. JACOBIDES; Annabelle GAWER; Nikolaus LANG; David ZULUAGA MARTÍNEZ, “The Political Economy and Geopolitics of AI Regulation”, 11 de noviembre de 2025 (forthcoming in Management & Business Review).
• Michael VEALE; João Pedro QUINTAIS, “The Obligations of Providers of General-Purpose AI Models”, versión noviembre 2025, en M. Zanfir Fortuna; G. Malgieri; G. González Fuster; A. Mantelero (eds.), The Artificial Intelligence Act – A Thematic Commentary, Hart Publishing, forthcoming 2026.
• Microsoft News Center, “Microsoft anuncia un nuevo compromiso ante sus clientes en torno a los copilots y la propiedad intelectual”, 19 de septiembre de 2023.
• Nuria OLIVER; Rishi BOMMASANI, “Code of Practice for General-Purpose AI Models – Transparency Chapter”, Working Group 1, 2025.
• OECD, “Intellectual Property Issues in Artificial Intelligence Trained on Scraped Data”, OECD Artificial Intelligence Papers, No. 33, febrero de 2025.
• Philipp HACKER; Matthias HOLWEG, “The Regulation of Fine-Tuning: Federated Compliance for Modified General-Purpose AI Models”, Computer Law & Security Review – The International Journal of Technology Law and Practice, vol. 60, abril de 2026.
• Sofia Katriina KARTTUNEN, “Copyright of AI-generated works: Approaches in the EU and beyond”, European Parliamentary Research Service (EPRS), Briefing, 19 de diciembre de 2025, doc. EPRS_BRI(2025)782585.
• Sophie WILLIAMS; Jonas SCHUETT; Markus ANDERLJUNG, “On Regulating Downstream AI Developers”, European Journal of Risk Regulation, Cambridge University Press, 4 de agosto de 2025.
• The Law Commission (England and Wales), “AI and the Law: A Discussion Paper”, Crown copyright 2025.