¿Exime la Ley de IA a los modelos open source de todas sus obligaciones? No como suele suponerse. Las excepciones de los artículos 2 apartado 12 y 53 apartado 2 del Reglamento (UE) 2024/1689 son estrechas, se adhieren al sistema de código abierto o al modelo y no a la empresa que lo usa, y los deberes que más importan siguen en pie.
Stand: 2026-09-29
La frase aparece en casi toda primera reunión: "usamos modelos open source en local, así que la Ley de IA no nos afecta". Suena razonable, porque el Reglamento sí nombra el código abierto en varios puntos y sí promete alivio. El alivio, sin embargo, cae en un sitio distinto del que casi todos esperan. Tomarlo por una exención general compra una falsa seguridad que el texto no respalda.
El error que sale caro
La Ley de IA separa de forma constante al proveedor, que desarrolla y suministra un modelo o sistema, del responsable del despliegue, que lo usa bajo su propia responsabilidad. Las excepciones de código abierto están escritas para el proveedor. Una empresa que ejecuta Llama, Qwen o Mistral en su propio hardware es, en casi todos los casos, responsable del despliegue, no proveedor. Para ese papel el Reglamento no prevé ninguna excepción general de código abierto.
Esa es la trampa real. La licencia del modelo no dice nada sobre qué deberes asume tu empresa. Que un modelo sea abierto, parcialmente abierto o propietario decide las obligaciones de quien lo fabrica. Tus propias obligaciones dependen de para qué usas el modelo y en qué nivel de riesgo cae ese uso. Conviene separar bien las dos preguntas, o se saca de la libertad del modelo una conclusión sobre la situación propia que el texto no autoriza.
Qué exime de verdad el artículo 2 apartado 12
El artículo 2 apartado 12 deja fuera del ámbito del Reglamento a los sistemas de IA distribuidos bajo una licencia libre y de código abierto. La frase que sigue estrecha la excepción. No se aplica cuando el sistema se introduce en el mercado o se pone en servicio como sistema de alto riesgo según el artículo 6 y el anexo III, ni a las prácticas prohibidas del artículo 5, ni cuando el sistema queda sujeto a las obligaciones de transparencia del artículo 50.
Queda poco detrás. Lo que sobrevive a esas tres excepciones de la excepción son sistemas de IA de riesgo mínimo, un filtro antispam o un corrector ortográfico, por ejemplo. Tales sistemas no cargan con obligaciones reales bajo el Reglamento de entrada, sean de código abierto o no. Por eso los juristas llaman a esta excepción en gran medida declarativa: enuncia de forma expresa para el código abierto lo que ya rige para los sistemas de riesgo mínimo en general, pero no levanta ningún deber concreto que de otro modo habría aplicado. Leer el artículo 2 apartado 12 como un salvoconducto para una herramienta de cribado de currículos o un sistema de scoring crediticio es saltarse la frase decisiva, porque esos son justamente los usos de alto riesgo que excluye.
Qué ahorra el artículo 53 apartado 2 al proveedor del modelo, y qué no
La segunda excepción, la que más cuenta en la práctica, afecta a los modelos de propósito general, los grandes modelos de lenguaje en sí. Según el artículo 53 apartado 1 un proveedor de un modelo de propósito general debe cuatro cosas: documentación técnica del modelo en la letra a, información para los proveedores posteriores en la letra b, una política de cumplimiento del derecho de autor de la UE en la letra c y un resumen suficientemente detallado del contenido de entrenamiento en la letra d.
El artículo 53 apartado 2 releva al proveedor que publica el modelo bajo una licencia libre y de código abierto de las dos primeras, la documentación técnica y la información a los proveedores posteriores. Las otras dos permanecen. La política de derechos de autor de la letra c y el resumen público del contenido de entrenamiento de la letra d se aplican también a un modelo abierto. Es la parte que más se pasa por alto: un modelo abierto sigue teniendo que exponer con qué se entrenó y cómo respeta el derecho de autor.
La excepción trae además condiciones. La licencia debe permitir acceso, uso, modificación y distribución, y los parámetros, incluidos los pesos, la arquitectura y la información sobre el uso del modelo, deben estar disponibles públicamente. Si el modelo se ofrece a cambio de pago, la excepción decae. Un modelo con los pesos tras un muro de pago no es de código abierto a efectos de esta norma, por mucho que la licencia lleve la palabra "open". Y el límite más importante está al final: para los modelos con riesgo sistémico según el artículo 55, en la práctica los modelos de frontera entrenados por encima de 10^25 FLOPs de cómputo, la excepción no se aplica. Cargan con las obligaciones completas al margen de la licencia. Un punto conexo afecta a los proveedores de fuera de la UE: según el artículo 54 apartado 6 no necesitan designar un representante autorizado en la Unión para un modelo de código abierto sin riesgo sistémico.
El punto que casi todos pasan por alto
Todo lo anterior atañe al proveedor del modelo. Para una empresa en funcionamiento la pregunta decisiva es otra: ¿qué me aplica a mí cuando despliego un modelo abierto? La respuesta no está en las normas de excepción. Está en los deberes del responsable del despliegue, y esos no conocen ninguna excepción de código abierto.
Desde el 2 de febrero de 2025, el artículo 4 exige a todo responsable adoptar medidas para apoyar el desarrollo de la alfabetización en IA de las personas que trabajan con el sistema. Desde el 2 de agosto de 2026 rige el deber de transparencia del artículo 50: un chatbot debe darse a conocer como máquina, y los contenidos generados por IA deben marcarse como tales. Si despliegas un sistema de alto riesgo, los deberes del artículo 26 se suman desde el 2 de diciembre de 2027, fecha fijada por el Reglamento (UE) 2026/1744 de julio de 2026. Ninguno de esos deberes pregunta bajo qué licencia está el modelo. Cuando tu propio papel pasa de responsable a proveedor, por ejemplo por una modificación sustancial del modelo, lo explicamos en responsable o proveedor.
Qué significa para una empresa con un modelo open source en local
En la práctica se reduce a una comprobación breve que compensa antes de apoyarse en la licencia. Clasifica primero el uso, no el modelo. Un modelo local para la búsqueda documental interna es de riesgo mínimo; el mismo modelo usado para preseleccionar candidaturas es de alto riesgo según el anexo III, y la licencia abierta no cambia nada ahí. Resuelve después la transparencia: si el sistema habla con clientes o produce contenido publicado, entra el artículo 50. Atiende en tercer lugar a la alfabetización en IA de las personas implicadas, el deber que más fácil se olvida y más fácil se cumple. Mantén por último separadas la protección de datos y la Ley de IA: el RGPD se aplica en paralelo y no conoce ninguna cuestión de código abierto.
La ventaja de un modelo abierto está en otro sitio, y es real. Tener los pesos en tu poder y ejecutar el modelo en tu propio hardware te da control pleno sobre los datos, te libera de la dependencia de cualquier contrato de proveedor y te permite acreditar la procedencia del modelo. Es una contribución concreta a la soberanía de los datos y facilita cualquier auditoría posterior. Ahora bien, es una ventaja para cumplir los deberes, no una liberación de ellos. Las ayudas como el Kit Digital financian el proyecto real, no la licencia del modelo.
El código abierto es una ventaja, no un salvoconducto
La versión corta para la dirección: la Ley de IA premia el código abierto, pero no te exime. Los artículos 2 apartado 12 y 53 apartado 2 alivian la posición del fabricante del modelo en puntos muy acotados, el derecho de autor y los datos de entrenamiento siguen siendo obligatorios incluso ahí, y los modelos con riesgo sistémico quedan excluidos por completo. Para tu empresa como responsable del despliegue lo que cuenta no es la licencia, sino la finalidad del uso. Trazar esa línea con limpieza te ahorra la sorpresa desagradable en la primera auditoría.
En qué nivel de riesgo cae tu uso concreto, y qué deberes se derivan de ahí, se resuelve mejor sobre el proyecto real. Es justo lo que hacemos en un proyecto piloto antes de que un modelo pase a la operación regular. Este texto ordena la situación jurídica según nuestra interpretación y no sustituye el asesoramiento jurídico en cada caso.
Preguntas frecuentes
¿La Ley de IA exime a los modelos open source de todas las obligaciones?
No. El artículo 2 apartado 12 exime a los sistemas de IA de código abierto solo mientras no sean prohibidos, no sean de alto riesgo y no entren en las obligaciones de transparencia. El artículo 53 apartado 2 releva al proveedor de un modelo de propósito general de código abierto de dos deberes de documentación, y de nada más.
¿Si solo uso un modelo open source, tengo igualmente obligaciones?
Sí. Las excepciones afectan al proveedor del modelo, no a ti como responsable del despliegue. Quien pone un modelo en uso operativo asume los deberes de los artículos 4 y 50 con independencia de la licencia, y el artículo 26 si el sistema es de alto riesgo.
¿Qué sigue siendo obligatorio para un proveedor de modelo open source pese a la excepción?
Aun con licencia libre siguen vigentes el artículo 53 apartado 1 letra c, la política de derechos de autor, y la letra d, el resumen público del contenido de entrenamiento. Si el modelo tiene riesgo sistémico según el artículo 55, la excepción no se aplica en absoluto.
¿Desde cuándo se aplican estas reglas?
Las obligaciones para los modelos de propósito general se aplican desde el 2 de agosto de 2025, ejecutables con las competencias de la Comisión desde el 2 de agosto de 2026. El deber de transparencia del artículo 50 rige desde el 2 de agosto de 2026, y los deberes del responsable para sistemas de alto riesgo desde el 2 de diciembre de 2027.