¿Qué es la IA de código abierto?
Fundamentos, modelos y capacidades de IA
La IA de código abierto es IA que se pone a disposición bajo condiciones que permiten a las personas usarla, estudiarla, modificarla y compartirla, con acceso suficiente a los componentes importantes para que esas libertades sean reales. En IA, eso suele implicar ir más allá del código y considerar también los pesos del modelo, el código de entrenamiento o inferencia, la documentación y la información sobre los datos de entrenamiento. El término sigue siendo objeto de debate, por lo que muchos modelos descritos como "abiertos" se describen mejor como de pesos abiertos que como de código abierto en sentido pleno.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
En el software convencional, "código abierto" suele significar que el código fuente está disponible bajo una licencia aprobada que permite la reutilización y modificación amplia. En IA, la situación es más compleja. Un modelo de IA útil no es solo código. También depende de parámetros aprendidos llamados pesos, del código utilizado para entrenarlo y ejecutarlo, de la arquitectura del modelo, de la documentación y de al menos alguna descripción de los datos empleados para crearlo.
Por eso la IA de código abierto no es simplemente "software de código abierto con etiqueta de IA". La pregunta difícil es qué debe estar abierto para que otra persona pueda estudiar y modificar el sistema de forma significativa. Si solo se publican los pesos, las personas pueden ejecutar el modelo y a veces ajustarlo, pero puede que no sean capaces de entender cómo fue construido ni de reproducir algo sustancialmente equivalente. Si solo se ofrece una API, el sistema no es de código abierto en el sentido habitual, porque los usuarios no pueden inspeccionar ni modificar el modelo en sí.
Aquí es donde el término pesos abiertos resulta útil. Los modelos de pesos abiertos ponen los parámetros entrenados a disposición para su descarga. Eso puede ser enormemente valioso: permite el autoalojamiento, la inspección, la evaluación comparativa y la adaptación. Pero los pesos abiertos no equivalen automáticamente a IA de código abierto. La licencia puede seguir imponiendo restricciones, y elementos clave como la receta de entrenamiento o la información sobre los datos pueden seguir faltando.
Así que cuando alguien dice que un modelo es "abierto", la pregunta práctica es: ¿abierto en qué partes, bajo qué condiciones y en qué medida?
Por qué importa
Esto importa porque lo que es "abierto" afecta a decisiones reales de compra y operación. Un modelo genuinamente abierto puede reducir la dependencia de un único proveedor, ofrecer mayor libertad en el despliegue, facilitar el uso local o en instalaciones propias, y hacer posible una personalización más profunda. También puede mejorar el escrutinio, ya que más personas pueden inspeccionar el comportamiento, evaluar el rendimiento e identificar debilidades.
Para muchas organizaciones, el atractivo es claro. Quieren mayor control sobre dónde se ejecutan los modelos, cómo se gestionan los datos, cómo se investigan los fallos y cuánto coste de cambio asumen en el futuro. Los modelos abiertos pueden ayudar en todo eso.
Pero la apertura también desplaza la responsabilidad. Si se descarga y ejecuta un modelo de forma autónoma, se asume una mayor carga operativa. Se necesita infraestructura, aplicación de parches, monitorización, control de acceso, salvaguardas de contenido y un plan para las actualizaciones. La comodidad comercial de un modelo alojado externamente no desaparece simplemente porque exista una opción abierta.
También hay una dimensión legal y de gobernanza. En IA, etiquetas como "código abierto", "modelo abierto", "pesos abiertos" y "código disponible" no son intercambiables. Si un equipo directivo las trata como sinónimos, puede hacer suposiciones erróneas sobre derechos de uso, expectativas de soporte, titularidad del riesgo y adecuación a los procesos de adquisición.
Cómo funciona
La forma más útil de entender la IA de código abierto es descomponerla en partes.
Una parte es el código. Esto incluye el código utilizado para entrenar el modelo, procesar los datos, ejecutar la inferencia y, en ocasiones, ajustar o evaluar el modelo. Sin ese código, aún es posible usar algunos modelos, pero la capacidad de inspeccionarlos o modificarlos es limitada.
Otra parte son los pesos. Son los parámetros aprendidos que determinan el comportamiento del modelo. Publicar los pesos permite a otros ejecutar el modelo directamente, a menudo en su propia infraestructura. Por eso las publicaciones de pesos abiertos tienen tanta importancia en la práctica: reducen la barrera para la experimentación, la adaptación y el autoalojamiento.
Una tercera parte es la información sobre los datos. Esta es una de las áreas más controvertidas. Los conjuntos de datos de entrenamiento en bruto no siempre pueden redistribuirse por razones de privacidad, derechos de autor, contratos o seguridad. Como resultado, el debate actual sobre la IA de código abierto se centra a menudo en si la información detallada sobre los datos de entrenamiento puede ser suficiente para que el sistema sea significativamente abierto, incluso cuando no es posible descargar cada ejemplo de entrenamiento.
La Open Source AI Definition de la Open Source Initiative es un intento importante de responder a esto. Enmarca la IA de código abierto en torno a las libertades de usar, estudiar, modificar y compartir, y establece que esas libertades requieren acceso a la forma preferida para realizar modificaciones. Para los sistemas de aprendizaje automático, eso incluye el código, los parámetros y la información suficientemente detallada sobre los datos utilizados para entrenar el sistema. Es un estándar más exigente que simplemente publicar los pesos.
Por eso la IA de código abierto es diferente del software de código abierto en sentido estricto. En el software convencional, el código fuente suele ser el artefacto central. En IA, el comportamiento emerge de la interacción entre código, pesos, datos y decisiones de entrenamiento. Un equipo puede compartir uno o dos de esos elementos manteniendo el resto cerrado. Eso puede seguir siendo útil, pero no resuelve la cuestión de la apertura.
Las licencias añaden otra capa. Algunas familias de modelos se publican bajo licencias de código abierto conocidas, como Apache 2.0, lo que generalmente indica amplios derechos de uso, modificación y redistribución. Otras familias de modelos utilizan licencias comunitarias personalizadas que pueden permitir el uso comercial en muchos casos, pero que incluyen restricciones que no alcanzan los estándares del código abierto. Si la licencia prohíbe usar el modelo para mejorar otro modelo de lenguaje grande, o impone condiciones adicionales a la redistribución, muchos defensores del código abierto dirán que no es verdaderamente de código abierto.
Por eso ha aparecido en el debate la expresión open-washing. Se refiere a comercializar algo como abierto cuando las libertades prácticas son más limitadas de lo que esa etiqueta sugiere. Un modelo puede ser fácil de descargar y aun así no cumplir los requisitos del código abierto según una definición más estricta.
Al mismo tiempo, los líderes no deben caer en el error contrario de desestimar los modelos de pesos abiertos como irrelevantes por no ser completamente de código abierto. En términos operativos, los modelos de pesos abiertos pueden seguir siendo muy valiosos: pueden autoalojarse, ajustarse, desplegarse rápidamente y tener licencias suficientemente permisivas para muchos usos reales. Para algunas organizaciones, ese es el requisito clave. Para otras, especialmente las centradas en la auditabilidad profunda, la reproducibilidad o la transparencia en la investigación, el estándar más completo importa más.
El mercado actual tiene, por tanto, varias capas. Hay modelos propietarios solo de API. Hay modelos de pesos abiertos con licencias permisivas. Hay modelos de pesos abiertos con restricciones personalizadas. Y hay un número menor de proyectos que aspiran a una apertura más completa en cuanto a pesos, código, receta de entrenamiento e información sobre los datos.
Las implicaciones operativas se derivan de esas capas. Si se quiere ejecutar un modelo detrás del propio cortafuegos, un proveedor solo de API no cubrirá esa necesidad. Si se quiere reentrenar una familia de modelos y publicar un derivado sin restricciones personalizadas, una licencia permisiva es fundamental. Si se necesita entender la procedencia y reconstruir el proceso de construcción, los pesos solos no son suficientes.
Un matiz adicional es que la apertura no garantiza calidad, seguridad ni mantenibilidad. Un modelo abierto puede ser excelente o deficiente, estar cuidadosamente documentado o apenas documentado, contar con una comunidad activa o carecer prácticamente de soporte. La apertura cambia el acceso y el control, no las leyes de la ingeniería.
Así que la definición práctica no es abstracta. La IA de código abierto trata de si otro equipo cualificado puede tomar el sistema de forma significativa, estudiarlo, adaptarlo y compartir los cambios sin necesitar más permisos. Eso es un listón más alto que el simple acceso público.
Ejemplos
Una empresa regulada puede optar por un modelo de pesos abiertos para un asistente interno de documentos porque quiere ejecutar la inferencia dentro de su propio entorno y evitar enviar consultas a un servicio externo alojado. En ese caso, el valor está en el control del despliegue, no en un compromiso ideológico con el código abierto.
Un equipo de producto puede adoptar un modelo con licencia permisiva como base para un asistente especializado en un dominio concreto y luego ajustarlo con material de soporte propietario. Aquí el atractivo es la personalización y la capacidad de controlar la pila de servicio.
Un equipo de investigación puede preferir un proyecto más completamente abierto porque necesita inspeccionar los métodos de entrenamiento, comparar puntos de control o reproducir resultados. Ahí es donde una apertura más completa, que incluya código e información sobre los datos, importa más que el simple acceso a los pesos.
Un equipo de adquisiciones también puede utilizar la apertura como criterio de resiliencia. Si una relación con un proveedor cambia, un modelo descargable junto con una licencia viable puede ofrecer una vía de salida más clara que una dependencia profundamente integrada solo de API.
Malentendidos frecuentes
Un malentendido es que la IA de código abierto simplemente significa "gratuita". No es así. Puede seguir siendo necesario pagar por el alojamiento, el soporte, el ajuste fino, el trabajo de seguridad o las herramientas comerciales en torno al modelo.
Otro es que la IA de código abierto es automáticamente más segura porque más personas pueden inspeccionarla. El escrutinio adicional puede ayudar, pero el acceso abierto también facilita el uso indebido en algunos contextos. La apertura cambia quién puede inspeccionar y adaptar el modelo, pero no elimina la necesidad de gobernanza.
Un tercer error es tratar los pesos abiertos como idénticos al código abierto. Los pesos abiertos son importantes, pero son solo una pieza. Si la licencia es restrictiva o el proceso de construcción es opaco, llamar al modelo de código abierto puede exagerar lo que los usuarios pueden hacer realmente.
Los equipos también asumen que una licencia permisiva resuelve todas las cuestiones legales. No es así. La procedencia de los datos de entrenamiento, el uso posterior, las normas sectoriales, las obligaciones de privacidad y los términos contractuales siguen siendo relevantes.
Por último, algunos líderes escuchan "IA de código abierto" y piensan "sin soporte de proveedor". En realidad, muchas pilas comerciales se construyen en torno a modelos abiertos. Abierto y comercial no son opuestos.
Riesgos y límites
El principal riesgo es la falsa certeza. Un modelo etiquetado como abierto puede no serlo de la manera que su organización necesita. Es necesario inspeccionar los artefactos reales, la licencia real y las libertades realmente concedidas.
También existen riesgos de gobernanza. Si se autoaloja, la aplicación de parches, las actualizaciones, el control del registro de modelos, la gestión de accesos y la prevención de abusos pasan a ser responsabilidad propia. Si se realiza un ajuste fino, también se asume la necesidad de evaluación y disciplina de reversión.
Los derechos de autor, la privacidad y la procedencia siguen siendo áreas de riesgo activas. Incluso con una publicación permisiva, las preguntas sobre los datos utilizados en el entrenamiento pueden seguir siendo relevantes para los equipos jurídicos y de riesgos. Esto es especialmente importante en usos orientados al cliente o de alto escrutinio.
También existen límites de rendimiento. Algunos modelos abiertos son excelentes; otros no. Muchos van por detrás de los sistemas propietarios líderes en tareas concretas, aunque los superan en flexibilidad o coste. Depende del trabajo a realizar.
Este artículo no constituye asesoramiento jurídico. Si los derechos de licencia, los derechos sobre modelos derivados o el uso de datos regulados son relevantes para su decisión, revise los términos específicos del modelo y el uso previsto con el asesoramiento adecuado.
Qué hacer a continuación
Comience por definir qué necesita realmente de lo "abierto". ¿Necesita pesos descargables, una licencia permisiva, despliegue local, reproducibilidad, transparencia en los datos de entrenamiento o libertad para publicar derivados? Distintos casos de uso requieren distintos grados de apertura.
A continuación, clasifique los modelos candidatos usando categorías claras: solo API; pesos abiertos con licencia permisiva; pesos abiertos con restricciones personalizadas; más completamente abiertos en cuanto a pesos, código e información sobre los datos. Esto solo ya aclara muchas conversaciones confusas.
Después, revise la licencia antes del piloto, no después. Compruebe los derechos de redistribución, los derechos sobre derivados, los requisitos de denominación, las cláusulas de uso prohibido y cualquier restricción sobre el uso del modelo o sus resultados para mejorar otros modelos.
Tras eso, pruebe el lado operativo. ¿Puede su equipo desplegarlo, monitorizarlo, actualizarlo y protegerlo? Un modelo abierto que el equipo no puede ejecutar de forma responsable no es un activo estratégico.
Por último, decida dónde la apertura es estratégica y dónde es opcional. Para algunas cargas de trabajo, una API propietaria puede seguir siendo la mejor opción. Para otras, el control y la flexibilidad de un modelo abierto pueden valer la carga operativa adicional.
¿Tiene alguna pregunta o sugerencia, o quiere saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es la IA de código abierto lo mismo que la IA de pesos abiertos?
No. Pesos abiertos significa que los parámetros entrenados están disponibles. La IA de código abierto plantea una pregunta más amplia sobre el código, la información sobre los datos, los términos y la libertad real de modificar y compartir.
¿Puede usarse la IA de código abierto con fines comerciales?
A menudo sí, pero es necesario leer la licencia real. Algunas publicaciones están bajo licencias permisivas como Apache 2.0, mientras que otras utilizan términos personalizados con restricciones importantes.
¿Es Meta Llama IA de código abierto?
Está ampliamente disponible y es muy influyente, pero muchos defensores del código abierto no la consideran verdaderamente de código abierto debido a las restricciones de su licencia personalizada.
¿Significa la IA de código abierto que el conjunto de datos de entrenamiento completo es público?
No siempre. Este es uno de los debates centrales. Algunas definiciones se centran en la información detallada sobre los datos en lugar de exigir que se publique cada ejemplo de entrenamiento.
¿Es el autoalojamiento de un modelo abierto siempre más barato que usar una API?
No. Depende del volumen de uso, el trabajo de ingeniería, el hardware, las necesidades de fiabilidad y las expectativas de soporte.
¿Son los modelos abiertos suficientemente buenos para usos empresariales serios?
Muchos lo son. La pregunta correcta no es abierto frente a cerrado en abstracto, sino si un modelo concreto cumple los requisitos de rendimiento, riesgo y operación.
Fuentes
The Open Source AI Definition 1.0 (Open Source Initiative). Primary source for the current OSI definition of open-source AI, including freedoms, preferred form for modification, and the required elements of data information, code, and parameters.
OSAID FAQ (Open Source Initiative). Primary source for why AI needs a distinct openness definition, why training data is not treated as software source code, and why detailed data information is still required.
Meta's Llama license is still not Open Source (Open Source Initiative). Primary source for the view that widely available models with licence restrictions should not automatically be described as open-source.
OLMo (Ai2). Primary source for a concrete example of a project presented as fully open across training data, architecture, and evaluation access.
OLMo 2 technical overview (Ai2). Primary source for OLMo 2 as a fully released family with model weights, full training data, code, recipes, logs, and checkpoints.
AI openness: A primer for policymakers (OECD). Secondary source for the broader policy framing that "open source" in AI is a contested and evolving term rather than a settled software analogue.