Si tu empresa afina un modelo abierto con sus datos, esto va contigo. 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 responsable del despliegue 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. Del sistema que utilizas bajo tu propia autoridad eres responsable del despliegue. Las obligaciones de los proveedores de modelos de propósito general (GPAI) —Arts. 53 a 55— no son tuyas, y la información y documentación del Art. 53(1)(b) se debe a los proveedores de sistemas de IA que integran el modelo, no a quien despliega; a ti te alcanzan, como a cualquier responsable del despliegue, la alfabetización del Art. 4, las prohibiciones del Art. 5 y lo que corresponda por el uso concreto. Un matiz que se pasa por alto: si con ese modelo desarrollas tú un sistema de IA y lo pones en servicio con tu nombre o marca, aunque sea para uso propio, eres además proveedor de ese sistema —no del modelo— (Art. 3, puntos 3 y 11).
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 tu nombre o tu marca en un sistema de alto riesgo ya introducido en el mercado o puesto en servicio —sin perjuicio de los acuerdos contractuales que asignen las obligaciones de otro modo—, modificas sustancialmente uno de alto riesgo de forma que siga siéndolo, o cambias la finalidad prevista de un sistema que no era de alto riesgo —incluido un sistema de IA de uso general— de forma que pase a serlo. En estos tres supuestos el Artículo 25.1 es claro: se te considera proveedor del sistema de alto riesgo, sujeto a las obligaciones del proveedor del Art. 16. Poner tu marca en un sistema de riesgo mínimo no te convierte en proveedor por esta vía; tu condición se analiza entonces por la definición del Art. 3, punto 3.
La figura recorre, en su orden, las tres circunstancias del Art. 25(1), todas acotadas al alto riesgo: poner tu nombre o marca en un sistema de alto riesgo ya introducido en el mercado o puesto en servicio, modificarlo sustancialmente de modo que siga siéndolo, o cambiar la finalidad prevista de un sistema —incluido uno de uso general— que no era de alto riesgo de modo que pase a serlo. Si el sistema no es de alto riesgo ni pasa a serlo con el cambio, no opera ninguna, y la condición de proveedor se analiza por la definición del Art. 3, punto 3. La figura no representa el umbral de cómputo de los modelos de uso general, que es otro examen.
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 ellas mismas llaman indicativo, 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í.
Si el cómputo de tu ajuste queda por debajo de ese tercio, la lectura práctica es tranquilizadora: con ese criterio, afinar el modelo no te convierte en proveedor del modelo de uso general. Pero es una conclusión que hay que poder sostener con la estimación de tu caso, no dar por supuesta.
Los dos matices que no se eximen nunca
Si trabajas sobre modelos abiertos conviene conocer otra pieza, y esta no está en las directrices sino en el propio Reglamento: el Art. 53(2) libera de las dos obligaciones de documentación del Art. 53(1) —la documentación técnica para la Oficina de IA y las autoridades nacionales competentes, letra a), y la información para los proveedores que integran el modelo en sus sistemas, letra b)— a los proveedores de modelos divulgados con una licencia libre y de código abierto que permita el acceso, la utilización, la modificación y la distribución del modelo, y cuyos parámetros, incluidos los pesos, la información sobre la arquitectura del modelo y la información sobre su uso, se pongan a disposición del público. La excepción no se aplica a los modelos de uso general con riesgo sistémico, y hay dos obligaciones de proveedor que no se eximen en ningún caso: las directrices para cumplir el Derecho de la Unión en materia de derechos de autor, letra c), y el resumen público del contenido utilizado para el entrenamiento, letra d). Si tu modificación te convirtiera en proveedor, «es open source» no te libraría de esas dos.
Y una advertencia complementaria: el fine-tuning y el aprendizaje continuo por parte del responsable del despliegue pueden activar el cambio de papel también en el terreno del alto riesgo, donde el examen no es un umbral de cómputo sino el Art. 25(1): modificar sustancialmente un sistema de alto riesgo de forma que siga siéndolo, o cambiar la finalidad prevista de un sistema —incluido uno de uso general— de forma que pase a serlo. 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:
- 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.
- Registra la finalidad: para qué se afina y para qué no. Es lo que sostiene que no hay cambio de finalidad hacia alto riesgo.
- Ancla la conclusión: «evaluado el criterio del tercio de cómputo; muy por debajo del umbral; papel de responsable del despliegue 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.