Haces fine-tuning de un modelo abierto: ¿te has convertido en proveedor?

Usar un modelo de IA no es lo mismo que modificarlo, y modificarlo mucho te cambia de casilla en el AI Act. Las directrices de la Comisión ponen un umbral concreto a esa frontera. Qué significa para una empresa que afina Llama o Mistral con sus datos.

Cada vez más empresas dan el salto de usar IA a ajustarla: cogen un modelo abierto —Llama, Mistral u otro— y lo afinan con sus propios datos para que hable su idioma, conozca su catálogo o siga su tono. Es un movimiento técnico razonable y cada vez más accesible. Lo que casi nadie les cuenta es que ese movimiento tiene una lectura regulatoria: en el AI Act, la distancia entre usar un modelo y modificarlo puede ser la distancia entre ser desplegador y ser proveedor. Y las obligaciones de uno y otro no se parecen en nada.

La escalera: usar, modificar, remarcar

El AI Act reparte obligaciones según el papel que juegas en la cadena. Simplificando, hay tres escalones:

Usar. Contratas o descargas un modelo y lo utilizas tal cual, aunque sea con tus prompts y tus integraciones. Eres desplegador. Para modelos de propósito general (GPAI), tus obligaciones directas como tal son mínimas: recibes la información que el proveedor debe darte y usas el sistema con la diligencia general que corresponde.

Modificar. Reentrenas o afinas el modelo con tus datos. Aquí es donde se abre la pregunta de este artículo: ¿en qué punto la modificación es lo bastante sustancial como para que pases a responder como proveedor de lo que has creado?

Remarcar. Pones el sistema en el mercado con tu marca, o le cambias la finalidad prevista hacia un uso de alto riesgo. En estos supuestos el Artículo 25 es claro: asumes el papel de proveedor, con todo lo que implica.

El umbral que puso la Comisión

Para el caso GPAI, las directrices de la Comisión Europea sobre las obligaciones de los proveedores de modelos de propósito general dieron a esa frontera un criterio cuantitativo que el texto del Reglamento no concretaba: un modificador se convierte en proveedor cuando el cómputo empleado en la modificación supera un tercio del cómputo de entrenamiento del modelo original.

Dos matices hacen el criterio manejable en la práctica:

  • Si no conoces el cómputo del original —lo habitual con modelos abiertos—, las directrices ofrecen valores de referencia supletorios según el tipo de modelo, de modo que la evaluación no depende de un dato que el proveedor original quizá no publicó.
  • Las obligaciones quedan limitadas a tu modificación. Si cruzas el umbral, no heredas la responsabilidad por todo el modelo original: respondes como proveedor de la parte que tú has creado. Es un reparto proporcionado, y conviene citarlo así.

Para la inmensa mayoría de fine-tunings empresariales —ajustes ligeros con miles o decenas de miles de ejemplos—, el cómputo de la modificación queda a una distancia enorme de ese tercio. La lectura práctica honesta es tranquilizadora: afinar un modelo para tu negocio no te convierte, por regla general, en proveedor GPAI. Pero es una conclusión que hay que poder sostener, no dar por supuesta.

Los dos matices que no se eximen nunca

Si trabajas sobre modelos abiertos conviene conocer otra pieza de las directrices: las exenciones para modelos open-source (que aligeran ciertas obligaciones de documentación) solo aplican a modelos bajo licencia realmente libre con parámetros públicos, nunca a modelos de riesgo sistémico, y hay dos obligaciones de proveedor que no se eximen en ningún caso: la política de cumplimiento de derechos de autor y el resumen público de los datos de entrenamiento. Si tu modificación te convirtiera en proveedor, "es open source" no te libraría de esas dos.

Y una advertencia complementaria que llega del material práctico español: el fine-tuning y el aprendizaje continuo por parte del desplegador aparecen señalados expresamente como situaciones que pueden activar el cambio de papel también en el terreno del alto riesgo — donde el trigger no es un umbral de cómputo sino la modificación sustancial o el cambio de finalidad. La frontera GPAI y la frontera de alto riesgo son dos exámenes distintos; conviene pasar los dos.

Qué documentar si estás afinando modelos

La conclusión operativa cabe en tres líneas de expediente:

  1. Registra la modificación: qué modelo base, qué datos, qué técnica, y una estimación razonable del cómputo empleado frente al umbral. No hace falta precisión de laboratorio; hace falta un juicio documentado.
  2. Registra la finalidad: para qué se afina y para qué no. Es lo que sostiene que no hay cambio de finalidad hacia alto riesgo.
  3. Ancla la conclusión: "evaluado el criterio del tercio de cómputo; muy por debajo del umbral; papel de desplegador sin cambios; revisión si cambia la técnica o la escala". Una frase así, fechada y firmada, es la diferencia entre una posición defendible y una suposición.

Es el mismo principio que atraviesa todo el Reglamento, y que ya señalamos al hablar del rol de quien coordina la gobernanza de IA en una PYME: las preguntas del AI Act casi nunca exigen respuestas heroicas — exigen respuestas documentadas. Y para responderlas, primero hay que saber qué modelos y sistemas tiene la casa: el inventario, una vez más, es el cimiento.

Este artículo tiene carácter informativo y no constituye asesoramiento jurídico.

Recibe análisis como este en tu correo

Novedades regulatorias y de producto de Alethexis. Sin ruido.

Acepto recibir comunicaciones de Alethexis —contenido sobre IA y regulación, y novedades de producto— y he leído la política de privacidad. Puedo darme de baja en cualquier momento.