> [!NOTE] ¿Qué es esto? > Es una investigación hecha con ayuda de IA para explicar los conceptos de pesos abiertos y cerrados y profundizar en otros relacionados: _open source_ frente a propietario -en el contexto de la IA, no del software en general-, _model distillation_ y _fine-tuning_. > > No pretende producir investigación científica nueva. Es una pieza de *divulgación bastante más detallada de lo que habitualmente se encuentra por ahí*, construida a partir de las fuentes que aparecen al final. Fecha de corte: 14 de septiembre de 2026. # Investigación: Modelos de IA abiertos y cerrados: pesos, licencias y formas de adaptarlos > Me puse a investigar por qué Llama, Gemma, DeepSeek, Mistral, gpt-oss y OLMo se describen todos como "modelos abiertos" si luego no se parecen en nada. Esto es lo que salió. La conclusión corta es que open source, open weights y gratis son tres cosas distintas, y que casi todo se decide en los pesos, que es justo la parte que nadie explica.  La conclusión principal de esta investigación es que el debate habitual entre "modelos open source" y "modelos propietarios" está demasiado simplificado. Para entender de verdad el mercado actual conviene separar **tres preguntas diferentes**: qué partes del modelo puedo obtener, qué sé sobre cómo se construyó y qué me permite hacer legalmente su licencia. Esta separación es especialmente importante para explicar al gran público por qué Llama, Gemma, DeepSeek, Mistral, Qwen, Phi, gpt-oss o OLMo pueden aparecer todos descritos como "modelos abiertos" y, sin embargo, tener grados de apertura muy distintos. ## 1. Cinco ideas para quedarse desde el principio  1. **Open source y open weights no significan lo mismo.** Que puedas descargar los pesos de un modelo no significa que puedas conocer o reproducir cómo fue entrenado. La Open Source Initiative exige bastante más para considerar una IA realmente open source: libertades de uso, estudio, modificación y distribución, pero también acceso al código y suficiente información sobre los datos utilizados para obtener esos parámetros. [^1] 2. **Los pesos son el activo central de un modelo entrenado.** Son miles de millones de números aprendidos durante el entrenamiento. Tenerlos permite ejecutar el modelo sin llamar necesariamente al fabricante. 3. **Open, transparente y gratuito son conceptos distintos.** Stanford encontró en 2025 que los desarrolladores open-weight son, de media, más transparentes que los closed-weight, pero también que varios modelos de pesos abiertos continúan siendo muy opacos respecto a datos, entrenamiento y otros elementos. [^2] 4. **La destilación no consiste en "comprimir" un fichero.** Consiste en utilizar un modelo potente, el profesor, para enseñar a otro modelo, normalmente más pequeño, el alumno. Es una transferencia de comportamiento o capacidad. 5. **Para una empresa, elegir modelos abiertos o cerrados es fundamentalmente una decisión de arquitectura, economía y gobierno.** Los modelos abiertos dan más control; los servicios propietarios descargan más responsabilidad operativa en el proveedor. Ninguna de las dos opciones gana por defecto. --- ## 2. Antes de hablar de apertura: ¿qué es exactamente "un modelo"?  Para explicarlo sin entrar demasiado pronto en matemáticas, conviene dividir un modelo generativo en varias piezas. | Pieza | Qué es | Analogía aproximada | | ------------------------------------ | -------------------------------------------------------------------------------- | ------------------------------------------------- | | **Arquitectura** | Diseño de la red: capas, atención, MoE, dimensiones, etc. | El plano de una máquina | | **Datos de entrenamiento** | Textos, imágenes, código, audio, datos sintéticos, etc. con los que aprende | El material con el que estudió | | **Código y receta de entrenamiento** | Software, hiperparámetros, filtrado de datos, proceso de entrenamiento | Cómo se le enseñó | | **Pesos o parámetros** | Valores numéricos aprendidos durante el entrenamiento; por comodidad suele llamarse pesos al conjunto de parámetros | Todo lo que quedó ajustado después de aprender | | **Código de inferencia** | Software necesario para ejecutar los pesos y producir resultados | El motor que hace funcionar la máquina | | **Post-training** | SFT, RLHF, DPO, RL, destilación y otras técnicas que modifican su comportamiento | Su educación posterior | | **Licencia** | Derechos y restricciones jurídicas sobre uso, modificación y redistribución | Las reglas que determinan qué puedes hacer con él | La Open Source Initiative define precisamente un modelo de machine learning como la combinación de **arquitectura, parámetros y código de inferencia**, y define los pesos como los parámetros aprendidos que se aplican sobre la arquitectura para producir respuestas. [^1] ### Qué son los pesos Un modelo de lenguaje empieza con miles de millones de parámetros numéricos. Durante el entrenamiento esos valores, que pueden organizarse como matrices, vectores y otros tensores, se van modificando para que el modelo mejore su capacidad para predecir, razonar, reconocer patrones o generar contenido. El resultado del entrenamiento son los **pesos**. No contienen una gigantesca base de datos con frases y conocimientos fácilmente legibles. Tampoco son el "código fuente" del modelo en el sentido tradicional. Representan el estado aprendido de la red. Eso no significa que los datos hayan desaparecido por completo: un modelo puede memorizar fragmentos de entrenamiento y, en algunos casos, llegar a reproducirlos o permitir que se extraigan. Una analogía útil, aunque imperfecta, sería: > La arquitectura describe cómo está construido el cerebro. Los pesos representan cómo ha quedado ese cerebro después de aprender. Esto explica por qué poder descargar los pesos es tan relevante. Con la arquitectura, la configuración, el *tokenizer* y el software de inferencia adecuados, **puedes ejecutar tú mismo ese cerebro entrenado**. --- ## 3. Pesos abiertos frente a pesos cerrados  Esta es probablemente la distinción central de todo el asunto. ### Modelo de pesos cerrados El proveedor conserva sus pesos y normalmente te permite utilizar el modelo como servicio. También puede ofrecer instalaciones restringidas mediante contratos específicos sin publicar los pesos para su descarga general. Tú envías: **prompt → servicio del proveedor → modelo → respuesta** Puedes utilizar modelos GPT mediante ChatGPT o una API, modelos Claude mediante sus productos y APIs o modelos Gemini mediante los servicios de Google, por ejemplo, pero no recibes una copia del modelo que hay detrás. Los términos actuales de las APIs reflejan bien esta idea. Google prohíbe intentar extraer o replicar componentes del servicio Gemini, incluidos específicamente los "parameter weights". [^3] OpenAI prohíbe igualmente ingeniería inversa y ataques de extracción del modelo. [^22] ### Modelo de pesos abiertos El proveedor publica esos parámetros y puedes descargarlos. El esquema puede convertirse en: **prompt → mi infraestructura → mi copia del modelo → respuesta** Eso permite desplegar el modelo en un datacenter propio, en una nube privada, en un proveedor especializado o, si es suficientemente pequeño, incluso en un PC, móvil o dispositivo edge. En esta investigación uso **pesos abiertos** en el sentido habitual de la industria: parámetros disponibles para descargar, aunque su licencia pueda imponer condiciones. No existe una definición normativa única del término. OpenAI describe explícitamente gpt-oss de esta manera: sus pesos pueden descargarse, ejecutarse en infraestructura controlada por el usuario y ajustarse utilizando herramientas abiertas. [^4] La diferencia fundamental es enorme: | | Pesos cerrados | Pesos abiertos | | --- | --- | --- | | Descargar el modelo | No | Sí | | Ejecutarlo sin el proveedor | Normalmente no | Sí | | On-premises | Normalmente no | Sí | | Funcionar offline | Normalmente no | Sí | | Modificar/fine-tunear directamente los pesos | Depende del servicio | Normalmente sí | | Cuantizarlo | No directamente | Sí | | Inspeccionar parámetros | No | Sí | | Congelar una versión indefinidamente | Depende del proveedor | Sí | | Cambiar el sistema de seguridad | Limitado | Sí | | Operación de GPUs | Proveedor | Cliente/hoster | | Actualizaciones del modelo | Proveedor | Cliente | | Coste principal | Servicio/API | Infraestructura + operación | | Responsabilidad operativa | Más proveedor | Más adoptante | Por tanto: **open weights significa fundamentalmente custodia y control operativo sobre una copia del artefacto entrenado.** No significa que adquieras su propiedad intelectual ni dice todavía nada suficiente sobre cómo se creó o qué derechos jurídicos tienes. --- ## 4. Por qué "open weights" no significa necesariamente "open source"  Aquí aparece buena parte de la confusión del mercado. Con software tradicional, publicar el código fuente suele proporcionar una enorme capacidad para comprender y reconstruir el programa. En IA generativa no basta con publicar el equivalente al programa. Para reconstruir un modelo necesitarías conocer también, al menos, buena parte de sus datos, procesamiento, hiperparámetros, entrenamiento y post-training. La **Open Source AI Definition 1.0**, publicada por la Open Source Initiative en octubre de 2024, intenta formalizar esta diferencia. Para considerar una IA realmente open source exige que pueda utilizarse, estudiarse, modificarse y compartirse libremente y que se facilite la forma preferida para modificarla. Esto incluye información suficiente sobre datos, código utilizado para procesarlos y entrenar el modelo y los parámetros resultantes. [^1] Por eso una afirmación aparentemente paradójica es perfectamente posible: > **Puedo tener todos los pesos de un modelo y seguir sin saber realmente cómo se construyó.** Stanford aporta evidencia interesante. En su Foundation Model Transparency Index de 2025, los cinco desarrolladores open-weight evaluados obtuvieron de media mejores resultados de transparencia que los ocho closed-weight. Pero Alibaba/Qwen, DeepSeek y Meta quedaron aun así en la mitad inferior del ranking. La conclusión de Stanford es bastante clara: **la apertura de pesos correlaciona con la transparencia, pero no la garantiza**. [^2] --- ## 5. En realidad existe un continuo de apertura  La clasificación binaria open/closed pierde demasiada información. La OSI utiliza *open source* como un umbral que se cumple o no; dentro del universo más amplio de artefactos publicados sí puede hablarse de distintos grados de apertura. La Linux Foundation ha desarrollado precisamente un **Model Openness Framework** con tres niveles. Su Class III publica arquitectura, parámetros y documentación básica; Class II añade código de entrenamiento, evaluación e inferencia; Class I, "Open Science", añade datasets, preprocesamiento, checkpoints intermedios y otros artefactos necesarios para estudiar todo el proceso. Desde Class III, los componentes exigidos deben publicarse bajo licencias abiertas adecuadas a cada tipo de material, salvo las excepciones que contempla el marco. Publicar pesos y arquitectura bajo una licencia restrictiva no basta para entrar en ese primer nivel. [^5] Aplicado al mercado actual, esta taxonomía resulta práctica: | Categoría práctica | Qué recibes | Ejemplos ilustrativos | | --- | --- | --- | | **Closed-weight / propietario** | Acceso al servicio, no a sus pesos | GPT mediante API/ChatGPT, Gemini mediante API, Claude | | **Open-weight con licencia propia** | Pesos descargables pero condiciones específicas | Llama, Gemma 3 | | **Open-weight con licencia permisiva** | Pesos + amplios derechos de modificación/redistribución, sin que eso demuestre por sí solo que el modelo completo sea open source según la OSI | gpt-oss, Gemma 4, Mistral 3 y diversos modelos similares | | **Open source según la OSI / open science** | Pesos + código + información suficiente sobre los datos; las iniciativas de ciencia abierta pueden publicar además datasets y checkpoints | OLMo 3 e iniciativas Open Science | No hay que tratar estos ejemplos como categorías eternas. **Debe mirarse siempre la licencia de la versión concreta del modelo que se vaya a utilizar.** ### El caso de Llama es especialmente pedagógico Llama 4 publica los pesos y permite uso, modificación y creación de derivados. Pero utiliza una **Llama 4 Community License**, no Apache o MIT. Meta incorpora además condiciones específicas, entre ellas requisitos para organizaciones que superaban 700 millones de usuarios activos mensuales en el momento del lanzamiento. Su política también incorpora determinadas restricciones para los modelos multimodales en la Unión Europea. [^6] La propia model card de Meta califica explícitamente la licencia de Llama 4 como una **custom commercial license**. [^7] Por eso llamarlo "open source" sin ningún matiz es discutible. La OSI, de hecho, ha criticado expresamente ese uso del término en generaciones anteriores de Llama. [^8] ### Gemma muestra por qué hay que comprobar la versión Google proporciona Gemma 3 y otras generaciones anteriores con pesos abiertos, pero bajo sus propios términos. Para los modelos que enumera esa licencia, se consideran derivados determinados modelos que transfieren patrones mediante **distillation** o mediante datos sintéticos generados por Gemma. [^9] Gemma 4, publicado el 2 de abril de 2026, utiliza Apache 2.0. La página de términos de Google lo excluye expresamente de la licencia anterior, así que esas condiciones específicas sobre derivados no se le pueden atribuir a toda la familia. Que Gemma 4 tenga una licencia permisiva tampoco demuestra por sí solo que cumpla todos los requisitos de la OSI sobre código e información de entrenamiento. [^30] Es decir: **descargar el fichero no elimina la licencia.** ### gpt-oss muestra una tercera variante OpenAI publicó gpt-oss-120b y gpt-oss-20b como modelos **open-weight** bajo Apache 2.0. La propia OpenAI evita equiparar automáticamente el término con "open source" y explica que utiliza "open" o "open-weight" para describir la disponibilidad pública de los parámetros entrenados. [^10] ### Y OLMo muestra el extremo mucho más abierto Ai2 publica con OLMo 3 datos, código, pesos y checkpoints, además de rutas documentadas de pretraining y post-training. Se puede intervenir desde distintas etapas del proceso en lugar de partir únicamente del producto terminado. [^11] Aquí sí hay un ejemplo mucho más defendible de *open source* aplicado de forma completa a IA, aunque para clasificar cada componente jurídicamente hay que comprobar sus licencias concretas. --- ## 6. Una frase que aclara buena parte del asunto  Una formulación que lo resume: > **Open source, open weights y gratis son tres cosas diferentes.** Un modelo puede ser gratis mediante una web y completamente cerrado. Un modelo puede tener pesos abiertos y una licencia restrictiva. Un modelo puede estar bajo una licencia permisiva y no revelar sus datos de entrenamiento. Y un modelo realmente abierto puede publicar pesos, código, datasets y checkpoints sin que eso signifique que sea gratis ejecutarlo. --- ## 7. El coste: "pesos gratis" no significa "IA gratis"  Este es otro malentendido frecuente. Si descargas un modelo de 20.000 millones de parámetros gratuitamente, alguien tiene que proporcionar las GPU, memoria, electricidad, almacenamiento, red, inferencia, monitorización y operación necesarias para ejecutarlo. OpenAI lo expresa explícitamente en la documentación de gpt-oss: los pesos pueden descargarse gratuitamente, pero el usuario asume los costes de computación, almacenamiento y hosting. Y señala además que self-hosting puede resultar más barato en algunos escenarios mientras que una API gestionada puede ser económicamente más eficiente cuando se incluyen alojamiento, mantenimiento y actualizaciones. [^12] Esto conduce a una regla empresarial muy útil: **API y self-hosting tienen curvas económicas diferentes.** Con poca utilización o demanda irregular, pagar solamente las llamadas realizadas suele ser atractivo. Con volúmenes elevados, predecibles y hardware bien utilizado, operar un modelo propio puede resultar más barato. No existe un umbral universal. Cambia brutalmente con el tamaño del modelo, contexto, throughput, latencia, batch, cuantización, tipo de GPU y nivel de utilización. --- ## 8. Model distillation: enseñar a un modelo pequeño utilizando uno grande  La idea de **knowledge distillation** es bastante anterior al boom generativo actual. El artículo de referencia de Geoffrey Hinton, Oriol Vinyals y Jeff Dean de 2015 planteaba transferir el conocimiento de un conjunto de modelos grande y pesado a un modelo más pequeño y sencillo de desplegar. [^13] La estructura básica es: **modelo "teacher" → proporciona información o comportamiento objetivo → modelo "student" aprende a aproximarlo** El profesor puede ser caro y extremadamente capaz. El alumno intenta aprender una parte relevante de su comportamiento. Suele ser más pequeño, pero la diferencia de tamaño no define por sí sola la destilación. ### La distilación clásica Supongamos una tarea de clasificación. Un profesor puede responder: `gato: 0,83` `tigre: 0,10` `perro: 0,04` `otros: 0,03` El resultado correcto es "gato", pero el resto de probabilidades también contienen información. El profesor está diciendo implícitamente que ese ejemplo se parece bastante más a un tigre que a un coche. Esas probabilidades, denominadas habitualmente **soft targets**, transmiten más conocimiento que decir únicamente "gato". En el trabajo clásico se utiliza además una **temperature** para suavizar las distribuciones y facilitar esa transferencia. [^13] --- ## 9. La destilación moderna de LLM es algo distinta  Con grandes modelos de lenguaje a menudo ni siquiera tienes acceso a los logits o parámetros del profesor. Pero sí puedes preguntarle cosas. Así que el profesor puede generar cientos de miles o millones de ejemplos: **pregunta → respuesta excelente** o incluso: **problema → razonamiento → respuesta** Esos ejemplos sintéticos pueden convertirse en un dataset para entrenar al alumno con el objetivo explícito de aproximar el comportamiento del profesor. El mero uso de datos sintéticos generados por otro modelo no convierte automáticamente el entrenamiento en destilación. Un esquema simplificado sería: **modelo frontier → 1 millón de demostraciones → dataset sintético → fine-tuning de un modelo pequeño → modelo especializado** Esto ha convertido la generación sintética de datos en una herramienta extremadamente potente para la destilación. ### DeepSeek-R1 es un ejemplo magnífico DeepSeek generó datos de razonamiento con R1 y los utilizó para ajustar modelos mucho más pequeños basados en Qwen y Llama. Publicó variantes destiladas desde 1,5B hasta 70B parámetros. La propia documentación afirma que los patrones de razonamiento de modelos mayores pudieron transferirse eficazmente a modelos densos mucho más pequeños. [^14] Aquí aparece una distinción importante: > **El estudiante no contiene una copia comprimida del profesor. Ha aprendido observando su comportamiento.** Es una diferencia conceptual importante respecto de la cuantización. --- ## 10. Destilación no es fine-tuning, aunque suelen aparecer juntas  Se confunden porque técnicamente una destilación moderna puede utilizar fine-tuning como mecanismo de entrenamiento. Pero describen dos cosas distintas. **Fine-tuning** describe un procedimiento para modificar un modelo a partir de nuevos ejemplos. **Distillation** describe un objetivo profesor-alumno: entrenar un modelo para que aproxime información, representaciones o comportamientos de otro. Puedes hacer fine-tuning sobre documentos creados por humanos sin ninguna destilación. Y puedes realizar una destilación generando ejemplos con un profesor y haciendo después SFT al alumno. En DeepSeek-R1 ocurre precisamente esto: modelos pequeños fueron **fine-tuned utilizando muestras generadas por DeepSeek-R1**. [^14] --- ## 11. Destilación tampoco es cuantización  Son estrategias completamente diferentes. Supongamos un modelo de 30B parámetros. **Cuantizarlo** significa representar aproximadamente los parámetros del mismo modelo con menos precisión: por ejemplo pasar de 16 bits a 8 o 4 bits. Algunos métodos añaden calibración o entrenamiento consciente de la cuantización, por lo que no siempre se limitan a convertir mecánicamente cada número. Sigue siendo esencialmente el mismo modelo, pero ocupa menos memoria y normalmente resulta más barato de ejecutar. La literatura de cuantización muestra precisamente cómo utilizar representaciones numéricas de menor precisión reduce sustancialmente memoria y coste computacional. [^15] **Destilarlo**, en cambio, puede significar enseñar a un modelo nuevo de 7B parámetros utilizando el de 30B como profesor. El resultado es otro modelo. Esto permite una comparación muy sencilla: | Técnica | Qué intenta reducir o cambiar | | --- | --- | | **Cuantización** | Precisión numérica de los pesos | | **Pruning** | Número de pesos/conexiones realmente utilizados | | **Destilación** | Tamaño/capacidad necesaria transfiriendo conocimiento a otro modelo | | **Fine-tuning** | Comportamiento, capacidades o parámetros de un modelo ya existente | | **LoRA** | Cantidad de parámetros que deben modificarse durante el fine-tuning | | **RAG** | Información externa disponible al responder | --- ## 12. Otros conceptos que conviene explicar junto a la destilación  ### Fine-tuning Partes de un modelo preentrenado y continúas entrenándolo con ejemplos específicos. Por ejemplo: **modelo generalista → 50.000 documentos/respuestas legales → modelo especializado** Puede cambiar comportamiento, estilo o capacidades e intentar incorporar información específica, aunque no es una forma fiable de mantener conocimiento factual que cambia con frecuencia. ### SFT - Supervised Fine-Tuning El modelo aprende mediante pares del tipo: **entrada → respuesta deseada** Es una de las primeras etapas habituales del post-training moderno. ### LoRA LoRA evita modificar directamente todos los miles de millones de parámetros. Congela el modelo base y aprende pequeñas matrices adicionales. El trabajo original mostró que esto puede reducir enormemente el número de parámetros entrenables y la memoria necesaria. [^16] Esto ha sido especialmente importante para el ecosistema open-weight porque permite adaptar modelos grandes con hardware mucho más modesto. ### QLoRA Combina ambas ideas: modelo base cuantizado, normalmente a 4 bits, y pequeños adaptadores LoRA que sí se entrenan. QLoRA demostró que era posible ajustar modelos de decenas de miles de millones de parámetros con recursos mucho menores que mediante full fine-tuning. [^17] ### Pruning Consiste en eliminar, poner a cero o dejar de utilizar parámetros poco importantes. La *sparsity* solo reduce de verdad almacenamiento o cálculo cuando la representación y el hardware o software de ejecución saben aprovecharla. SparseGPT mostró, por ejemplo, que modelos GPT de gran tamaño podían llevarse a niveles muy altos de sparsity con pérdidas relativamente pequeñas en determinados experimentos. [^18] ### RAG Retrieval-Augmented Generation introduce una memoria externa. En vez de intentar grabar toda la información nueva dentro de los pesos, el sistema busca documentos relevantes durante la ejecución y se los proporciona al modelo. El trabajo seminal de RAG habla precisamente de combinar la memoria "paramétrica" del modelo con una memoria externa "no paramétrica". [^19] Para empresas esta diferencia es crítica: **fine-tuning modifica el modelo; RAG modifica el contexto que recibe.** Si cambia mañana la lista de precios de una compañía, normalmente interesa actualizar la fuente consultada por RAG, no volver a entrenar el modelo. ### RLHF Reinforcement Learning from Human Feedback utiliza señales humanas para mejorar el comportamiento. Las comparaciones de preferencias son una de sus formas más habituales, pero no la única posible. El trabajo de InstructGPT popularizó una secuencia con demostraciones humanas, modelo de recompensa y reinforcement learning. Un resultado especialmente ilustrativo fue que un InstructGPT de 1,3B parámetros podía ser preferido por evaluadores humanos al GPT-3 original de 175B en las tareas estudiadas. [^20] Es otra demostración de algo importante: **el número bruto de parámetros no determina por sí solo la utilidad de un modelo.** ### DPO Direct Preference Optimization consigue parte del objetivo del RLHF mediante un procedimiento de preference tuning más directo, eliminando la necesidad de algunas de las etapas del pipeline clásico. [^21] --- ## 13. Por qué la destilación se está volviendo tan importante  La primera era de los LLM estuvo dominada por una idea bastante sencilla: **más parámetros + más datos + más cómputo = mejores modelos.** Pero una vez construido un modelo extremadamente capaz aparece otra pregunta económicamente mucho más interesante: **¿cuánta de esa capacidad puedo trasladar a un modelo mucho más pequeño?** Esto abre una segunda curva de innovación. Un modelo enorme puede servir como "fábrica de datos y conocimiento" para producir modelos especializados mucho más baratos. Ahí confluyen: **distillation + synthetic data + fine-tuning + quantization** El resultado puede ser un modelo que no gane al profesor en capacidades generales pero sí sea suficientemente bueno en una tarea concreta a una fracción del coste. Para empresas esto es potencialmente enorme. Un agente que analiza millones de facturas probablemente no necesita utilizar el modelo frontier más potente del planeta para cada factura. Puede interesar utilizar ese modelo grande para crear ejemplos, evaluar resultados o resolver excepciones difíciles y hacer que un modelo mucho más pequeño atienda el 95 % del volumen. --- ## 14. La parte jurídica de la destilación es tan importante como la técnica  Aquí hay otra confusión habitual. **La destilación es una técnica legítima. Eso no significa que tengas derecho a destilar cualquier modelo.** OpenAI restringe en su acuerdo empresarial actual el uso de outputs para desarrollar modelos que compitan con sus productos, salvo excepciones explícitas, y define los ataques de extracción de modelos dentro de sus restricciones de ingeniería inversa. [^22] Google establece de forma similar que Gemini API no puede utilizarse para desarrollar modelos competidores ni para extraer o replicar sus modelos o pesos. [^3] Anthropic describe la distilación como una práctica legítima cuando se realiza con autorización, pero diferencia esto de la extracción industrial no autorizada de capacidades de Claude. [^23] La consecuencia para una empresa es clara: **antes de generar millones de ejemplos sintéticos con un proveedor para entrenar otro modelo, hay que leer la licencia y los términos del servicio.** No es un detalle administrativo posterior. --- ## 15. Las licencias de los modelos abiertos también importan  Apache 2.0, MIT, Community Licenses y términos propios no son equivalentes. Apache 2.0 concede derechos muy amplios de reproducción, modificación y distribución e incluye además una licencia de determinadas patentes aportadas por los contribuidores. Pero la licencia deja también claro que el software se proporciona **"AS IS" y sin garantía**, incluida la garantía de no infracción. [^24] Esta diferencia se vuelve muy concreta en una gran compañía. Un modelo descargado bajo Apache puede darte enormes libertades técnicas, pero la licencia por sí sola no te ofrece necesariamente soporte, SLA, mantenimiento o indemnización. En cambio, un servicio empresarial gestionado puede incorporar algunas de esas protecciones contractuales. Por ejemplo, los términos actuales de la API de OpenAI incluyen, con determinadas excepciones y condiciones, indemnización frente a ciertas reclamaciones de propiedad intelectual relacionadas con los outputs. [^25] Por tanto: **más libertad tecnológica puede significar también más responsabilidad propia.** --- ## 16. Cómo cambia todo esto la decisión de una empresa  No plantearía la decisión como: **Open source vs. propietario.** Plantearía un conjunto de decisiones distintas. | Factor | Closed-weight gestionado | Open-weight autogestionado | | --- | --- | --- | | Tiempo para empezar | Muy bueno | Peor | | Últimas capacidades frontier | Frecuentemente excelente | Cada vez más competitivo | | Control del modelo | Bajo/medio | Alto | | Control de infraestructura | Bajo/medio | Alto | | Datos permanecen técnicamente dentro de infraestructura propia | Depende del servicio | Sí, si se despliega correctamente | | Personalización profunda | Limitada | Alta | | Operación | Proveedor | Empresa | | Hardware | Proveedor | Empresa/hoster | | Seguridad del serving | Proveedor + cliente | Principalmente cliente | | Actualizaciones | Automáticas/proveedor | Decisión propia | | Congelar versión | Menor control | Alto | | Portabilidad | Menor | Mayor | | Coste con demanda irregular | Muy atractivo | Puede ser ineficiente | | Coste con carga masiva y estable | Puede crecer mucho | Puede ser atractivo | | Soporte/SLA | Habitualmente disponible | Hay que contratarlo/construirlo | | Indemnización | Puede existir contractualmente | La licencia normalmente no la proporciona | | Offline/edge | Limitado | Muy favorable | | Soberanía tecnológica | Menor | Mayor | --- ## 17. Privacidad: tampoco existe un ganador automático  Se suele decir: **open model = privado** **cloud model = tus datos salen de la empresa** Es demasiado simple. Un open-weight desplegado completamente dentro de la infraestructura de una compañía proporciona una propiedad potente: **el proveedor original del modelo no necesita ver ninguna inferencia**. OpenAI explica, por ejemplo, que cuando gpt-oss se ejecuta de manera autogestionada no recibe ni procesa esos datos salvo que el usuario los comparta expresamente. [^12] Esto resulta especialmente atractivo para: sanidad, defensa, administraciones públicas, propiedad intelectual muy sensible, fábricas aisladas, edge computing o información sometida a fuertes restricciones de residencia. Pero las APIs empresariales cerradas pueden ofrecer compromisos contractuales muy fuertes. OpenAI establece actualmente que el contenido empresarial no se utiliza para desarrollar o mejorar sus servicios salvo consentimiento explícito. [^22] Google establece igualmente que los prompts y respuestas de sus servicios de pago Gemini no se utilizan para mejorar sus productos. [^3] Por tanto, **privacidad y apertura son dimensiones relacionadas, pero diferentes**. --- ## 18. Seguridad: control también significa responsabilidad  Un servicio cerrado tiene una ventaja estructural: el proveedor controla el modelo que se está ejecutando. Puede modificar mitigaciones, aplicar filtros, detectar abuso, parchear vulnerabilidades o cortar el acceso. Con pesos abiertos sucede algo diferente. Una vez publicados y descargados, esos pesos no pueden recuperarse. OpenAI lo explica explícitamente en la model card de gpt-oss: un atacante puede fine-tunear los modelos para eliminar rechazos de seguridad y OpenAI ya no puede aplicar posteriormente nuevas mitigaciones ni revocar ese acceso. [^10] Pero la otra cara también existe. Pesos disponibles permiten a investigadores y compañías: examinar el modelo independientemente, probarlo sin límites de API, aplicar su propia política de seguridad, aislarlo totalmente de Internet, modificarlo para un dominio específico o construir sistemas soberanos. Por eso la discusión **"open es seguro / closed es seguro"** es poco seria. Son arquitecturas de gobierno diferentes. --- ## 19. Dependencia del proveedor  Los modelos closed-weight crean un tipo de dependencia particularmente profundo. Tu aplicación puede depender no solo de una API, sino también de: la versión del modelo, su política de moderación, precios, límites, ventana de contexto, disponibilidad regional, características y calendario de retirada. Con un modelo open-weight puedes conservar indefinidamente una copia concreta, siempre que su licencia lo permita. Esto tiene valor empresarial. Un modelo validado en enero de 2027 puede seguir siendo exactamente ese modelo en enero de 2029. El precio es evidente: **eres tú quien debe mantenerlo.** --- ## 20. Open weights tampoco elimina al proveedor  Tener un modelo descargable no obliga a comprar GPUs. Puedes ejecutar un open-weight mediante proveedores especializados que lo sirven como API. En ese caso aparece una situación híbrida: **modelo abierto + infraestructura gestionada** Esto desacopla dos decisiones que a menudo se mezclan: **quién creó el modelo** y **quién lo opera**. En los próximos años esta separación probablemente será cada vez más importante. --- ## 21. Mi lectura para las grandes empresas: el enfoque híbrido tiene más sentido  Aquí llevaría un poco la contraria a ambos bandos. No veo una razón sólida para que una gran organización adopte ideológicamente "solo modelos propietarios" o "solo modelos abiertos". La arquitectura más razonable suele ser **un portfolio de modelos**. Un modelo frontier gestionado puede resolver tareas complejas, nuevas o de bajo volumen. Modelos pequeños open-weight pueden encargarse de tareas repetitivas, sensibles o de gran volumen. Un router puede enviar cada petición al modelo adecuado según dificultad, riesgo, coste, sensibilidad de datos y latencia. Y la destilación permite que capacidades demostradas primero con modelos grandes acaben trasladándose a modelos especializados mucho más baratos. El patrón sería aproximadamente: **frontier model → descubre / genera / evalúa → modelo especializado → industrializa** Eso me parece bastante más interesante que la batalla comercial de "open contra closed". --- ## 22. Qué cambia para una persona  Para un individuo, la distinción más tangible es sencilla: **¿puedo ejecutar la IA en un dispositivo que controlo?** Los open-weight pequeños, especialmente cuando están cuantizados o destilados, permiten ejecutar modelos en PCs, workstations, móviles y otros dispositivos. Eso aporta varias posibilidades: trabajo offline, privacidad local, ausencia de coste por token, experimentación y personalización. A cambio requiere hardware, almacenamiento y algo de conocimiento técnico, y normalmente los mejores modelos locales siguen teniendo menos capacidad general que los sistemas frontier servidos desde grandes datacenters. Los servicios cerrados ofrecen justo el intercambio contrario: ninguna instalación, acceso inmediato a enormes recursos de cómputo, últimas versiones, productos integrados y actualizaciones automáticas, pero sin tener bajo tu control una copia del modelo. La aparición de modelos más pequeños y eficientes está reduciendo rápidamente la distancia entre ambos mundos. --- ## 23. Por qué distillation + quantization es especialmente relevante para el usuario final  Imaginemos: **Profesor: 400B parámetros** ↓ destilación **Alumno: 14B parámetros** ↓ cuantización 4-bit **Modelo ejecutable en una máquina mucho menor** La primera operación intenta transferir inteligencia. La segunda intenta ejecutar esa inteligencia eficientemente. Son complementarias. Por eso buena parte de la expansión de IA local no depende únicamente de diseñar modelos pequeños mejores desde cero. También depende de **conseguir que modelos pequeños aprendan de los grandes y después representarlos eficientemente**. --- ## 24. El AI Act europeo utiliza sus propios criterios de apertura  Esto es especialmente relevante en Europa. El AI Act no establece una taxonomía general equivalente a la de la OSI. Fija las condiciones para aplicar determinadas excepciones a modelos de propósito general publicados bajo licencias libres y *open source*: la licencia debe permitir acceso, uso, modificación y distribución, y deben hacerse públicos los parámetros, incluidos los pesos, además de información sobre arquitectura y uso. [^26] Pero la exención no es total. Los proveedores siguen teniendo, entre otras obligaciones, una política relativa al copyright y la obligación de publicar un resumen suficientemente detallado del contenido utilizado para el entrenamiento. Y las excepciones no se aplican de igual forma a los modelos considerados de **riesgo sistémico**. [^26] Desde el 2 de agosto de 2025 las obligaciones para proveedores de modelos GPAI están en aplicación, y desde el 2 de agosto de 2026 la Comisión dispone ya de sus poderes de enforcement sobre estas obligaciones. Hay una excepción transitoria: los proveedores de modelos puestos en el mercado antes del 2 de agosto de 2025 tienen hasta el 2 de agosto de 2027 para cumplir esas obligaciones. [^27] Hay además un detalle conceptual interesante: **la definición regulatoria europea y la definición de Open Source AI de OSI no son idénticas.** El AI Act se centra en determinadas libertades de licencia y publicación de pesos, arquitectura e información de uso para decidir si se aplica una excepción regulatoria concreta. OSI fija un umbral de apertura más amplio sobre el proceso necesario para estudiar y modificar el sistema, incluido código e información sobre los datos. [^26] Por eso conviene evitar afirmar sin más: "Según la definición oficial, esto es open source". Hay varias definiciones según estemos hablando de principios open source, clasificación técnica o legislación. --- ## 25. Un marco mucho mejor para evaluar cualquier modelo  En vez de preguntar únicamente **"¿es open source?"**, propondría evaluar cualquier modelo mediante estas dimensiones: | Dimensión | Pregunta | | --- | --- | | **Pesos** | ¿Puedo descargarlos? | | **Arquitectura** | ¿Sé exactamente cómo está construido? | | **Código de inferencia** | ¿Puedo ejecutarlo de forma independiente? | | **Código de entrenamiento** | ¿Puedo estudiar cómo se entrenó? | | **Datos** | ¿Sé con qué aprendió? ¿Puedo obtenerlos? | | **Checkpoints** | ¿Puedo examinar etapas anteriores del entrenamiento? | | **Licencia** | ¿Puedo usarlo, modificarlo y redistribuirlo comercialmente? | | **Restricciones** | ¿Existen límites de uso, territorio, escala o actividad? | | **Reproducibilidad** | ¿Podría construir algo equivalente partiendo de los artefactos publicados? | | **Hosting** | ¿Puedo desplegarlo donde quiera? | | **Modificación** | ¿Puedo fine-tunearlo, cuantizarlo, podarlo o destilarlo? | | **Garantías** | ¿Quién responde ante fallos, infracción o incidentes? | Esta tabla explica el mercado bastante mejor que una columna binaria **Open source: sí/no**. --- ## 26. Algunas afirmaciones frecuentes que conviene desmontar  | Afirmación | Más correcto | | --- | --- | | "Llama es open source porque puedo descargarlo" | Es open-weight con una licencia propia; descargar pesos no basta para aplicar automáticamente la definición estricta de open source | | "Si los pesos son abiertos, sé cómo se entrenó" | No. Puedes tener el resultado sin tener la receta ni los datos | | "Un modelo abierto es gratis" | Los pesos pueden ser gratuitos; la inferencia cuesta dinero | | "Open significa transparente" | No necesariamente | | "Closed significa que el proveedor entrena con mis datos" | No necesariamente; depende del contrato y producto | | "Distillation es comprimir el modelo" | No exactamente; transfiere comportamiento/conocimiento a otro modelo | | "Quantization crea un modelo pequeño nuevo" | Normalmente representa aproximadamente los parámetros del mismo modelo con menor precisión; puede incluir calibración o entrenamiento adicional | | "Fine-tuning y RAG son alternativas equivalentes" | Uno cambia parámetros; el otro aporta información externa en tiempo de inferencia | | "Open-weight evita vendor lock-in" | Lo reduce en la capa de modelo, pero puedes seguir dependiendo del runtime, GPU, nube o framework | | "Apache 2.0 significa que el fabricante responde" | No; Apache incluye amplias libertades pero también importantes exenciones de garantía | --- ## 27. La idea de fondo  Todo esto va bastante más allá del típico **"open source vs modelos propietarios"**. La tesis: > **Hasta ahora hablábamos de qué IA utilizábamos. Cada vez será más importante hablar de qué controlamos realmente cuando utilizamos esa IA.** Un usuario de ChatGPT o Gemini accede a inteligencia como servicio. Quien descarga un modelo open-weight tiene bajo su custodia una copia ejecutable de una parte sustancial de esa inteligencia, dentro de los derechos que le conceda la licencia. Quien además dispone de código, datos y proceso de entrenamiento puede estudiarla y reconstruirla. Y quien utiliza destilación puede intentar transferir una parte de la capacidad de un modelo a otro mucho más pequeño. Son **cuatro grados diferentes de relación con la inteligencia artificial**: consumirla, ejecutarla, comprender cómo fue construida y enseñar a otro modelo a imitarla. Ese marco explica mucho mejor lo que está pasando. --- ## 28. Una posible metáfora para explicarlo  La metáfora más útil es una **escuela**, no software. Un modelo closed-weight sería un experto al que puedes llamar por teléfono. Le haces preguntas y pagas por sus respuestas, pero no puedes llevártelo a casa ni examinar su cerebro. Un open-weight sería poder llevarte una copia de ese experto. Puedes ponerlo a trabajar donde quieras y seguir entrenándolo. Un verdadero modelo open source/open science sería tener además sus libros, currículo, ejercicios, método de enseñanza y registros de cómo llegó a aprender. Y la destilación sería sentar a un estudiante joven junto al gran experto, hacer que observe miles de soluciones y entrenarlo para que aprenda a resolver problemas de una manera similar. La analogía no es técnicamente perfecta, pero permite introducir después los matices sin tener que desmontarla por completo. --- ## 29. Qué significará esto en adopción empresarial  Veo cinco consecuencias bastante estructurales. **Primera: el modelo empieza a ser sustituible.** Una aplicación bien diseñada no debería acoplar su lógica de negocio a un único modelo. El valor se desplaza hacia datos, workflows, herramientas, evaluación y experiencia de usuario. **Segunda: aparecerán más modelos pequeños especializados.** No tiene sentido económico resolver cada tarea empresarial con el modelo más inteligente disponible. Distillation, synthetic data, LoRA y quantization permiten crear "motores" mucho más eficientes. **Tercera: el coste de la inteligencia será cada vez más heterogéneo.** Una organización podrá utilizar inteligencia carísima para diez peticiones complejas y extremadamente barata para diez millones de peticiones sencillas. **Cuarta: soberanía ya no significará necesariamente entrenar un foundation model propio.** Poder desplegar, modificar y controlar un buen open-weight puede proporcionar gran parte de la soberanía necesaria sin gastarse cientos de millones en pretraining. **Quinta: model governance se convertirá en portfolio governance.** Habrá que decidir qué modelos están aprobados para qué datos, qué jurisdicciones, qué usos, qué niveles de autonomía y qué requisitos de evaluación. --- ## 30. Y una advertencia para empresas que se lancen a los pesos abiertos  Tener un fichero descargado no convierte automáticamente a una compañía en proveedor competente de IA. Con closed-weight, parte de la complejidad está escondida detrás de la API. Cuando una empresa pasa a open-weight necesita hacerse cargo, directamente o mediante terceros, de serving, escalabilidad, observabilidad, actualizaciones, evaluación, ciberseguridad, seguridad del modelo, red teaming, filtrado, protección de datos y continuidad del servicio. Además, licencias permisivas como Apache 2.0 dejan claro que los artefactos se proporcionan sin garantías. [^24] Así que **self-hosting no elimina al proveedor: convierte a la organización en parte del proveedor**. --- ## 31. Mi síntesis final  El mercado de IA generativa ya no puede describirse correctamente mediante dos cajas: **open source** y **propietario**. Hay al menos tres ejes independientes: **Acceso:** ¿puedo obtener los pesos? **Transparencia:** ¿sé cómo se construyó? **Libertad jurídica:** ¿qué me dejan hacer con ello? Y sobre esos tres ejes aparecen después otros dos decisivos: **Operación:** ¿quién lo ejecuta? **Transferencia:** ¿puedo modificarlo, fine-tunearlo o utilizarlo para enseñar a otros modelos? Ahí entra la destilación. Los modelos frontier pueden convertirse no solo en herramientas que responden preguntas, sino en **profesores que producen los datos con los que entrenar modelos más pequeños**. DeepSeek-R1 es una demostración clara del patrón. [^14] Ese fenómeno, combinado con pesos abiertos, cuantización y hardware cada vez más potente, está haciendo posible algo que hace pocos años era mucho más difícil: **mover capacidades de IA desde enormes datacenters hacia modelos que una empresa o incluso una persona puede tener bajo su control y ejecutar.** Eso no implica que los modelos propietarios vayan a desaparecer. Al contrario. Los modelos frontier gestionados seguirán teniendo ventajas enormes en capacidad, simplicidad de uso y velocidad de innovación. El escenario más probable no es una victoria de open sobre closed ni de closed sobre open. Es una **cadena de valor en la que convivirán ambos**: modelos frontier construyendo nuevas capacidades, modelos abiertos distribuyéndolas y modelos destilados y especializados industrializándolas. Para una empresa, saber distinguirlos dejará de ser terminología técnica. Será una decisión sobre **control, coste, riesgo, propiedad y dependencia tecnológica**. ## Fuentes principales  | Fuente | Utilidad | | --- | --- | | [^1] | Definición rigurosa de open source AI y pesos | | [^28] | Clasificación Open Model / Open Tooling / Open Science | | [^2] | Evidencia sobre apertura frente a transparencia | | [^11] | Ejemplo de modelo realmente abierto end-to-end | | [^10] | Ejemplo moderno de open-weight Apache 2.0 | | [^6] | Ejemplo de pesos accesibles bajo licencia específica | | [^9] | Especialmente interesante por su tratamiento jurídico de distillation | | [^14] | Caso práctico excelente de destilación de razonamiento | | [^13] | Trabajo seminal sobre knowledge distillation | | [^16] y [^17] | Adaptación eficiente de modelos | | [^19] | Referencia fundacional para distinguir RAG de entrenamiento | | [^29] | Tratamiento legal de GPAI y modelos open source en Europa | | [^27] | Interpretación práctica y calendario regulatorio | [^1]: [opensource.org](https://opensource.org/ai/open-source-ai-definition) [^2]: [crfm.stanford.edu](https://crfm.stanford.edu/fmti/) [^3]: [ai.google.dev](https://ai.google.dev/gemini-api/terms) [^4]: [help.openai.com](https://help.openai.com/es-419/articles/11870455) [^5]: [lfaidata.foundation](https://lfaidata.foundation/wp-content/uploads/sites/3/2025/01/05_White_paper_MOF_Specification.pdf?_hsmi=344713425) [^6]: [github.com](https://github.com/meta-llama/llama-models/blob/main/models/llama4/LICENSE) [^7]: [github.com](https://github.com/meta-llama/llama-models/blob/main/models/llama4/MODEL_CARD.md) [^8]: [opensource.org](https://opensource.org/blog/metas-llama-license-is-still-not-open-source) [^9]: [ai.google.dev](https://ai.google.dev/gemma/terms) [^10]: [openai.com](https://openai.com/index/gpt-oss-model-card/) [^11]: [allenai.org](https://allenai.org/blog/olmo3) [^12]: [help.openai.com](https://help.openai.com/en/articles/11870455) [^13]: [arxiv.org](https://arxiv.org/abs/1503.02531) [^14]: [github.com](https://github.com/deepseek-ai/DeepSeek-R1) [^15]: [arxiv.org](https://arxiv.org/abs/2103.13630) [^16]: [arxiv.org](https://arxiv.org/abs/2106.09685) [^17]: [arxiv.org](https://arxiv.org/abs/2305.14314) [^18]: [arxiv.org](https://arxiv.org/abs/2301.00774) [^19]: [arxiv.org](https://arxiv.org/abs/2005.11401) [^20]: [arxiv.org](https://arxiv.org/abs/2203.02155) [^21]: [arxiv.org](https://arxiv.org/abs/2305.18290) [^22]: [openai.com](https://openai.com/policies/services-agreement/) [^23]: [anthropic.com](https://www.anthropic.com/news/detecting-and-preventing-distillation-attacks?tblci=GiCQHBQzfHp46MBeKZxSjw9v3P8PGZXptg2qCUEwT-_zzSCJm1Ao7qCE6omykvVDMOX2UA) [^24]: [apache.org](https://apache.org/licenses/LICENSE-2.0.html) [^25]: [openai.com](https://openai.com/policies/service-terms/) [^26]: [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2024/1689/spa) [^27]: [Comisión Europea: obligaciones y calendario para proveedores de modelos GPAI](https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers) [^28]: [lfaidata.foundation](https://lfaidata.foundation/wp-content/uploads/sites/3/2025/01/05_White_paper_MOF_Specification.pdf) [^29]: [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2024/1689/spa) [^30]: [Google: lanzamiento de Gemma 4 bajo Apache 2.0](https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/) y [licencia Apache 2.0 de Gemma 4](https://ai.google.dev/gemma/apache_2).