Auditoría documental del catálogo de modelos abiertos de Ai2: estado de la evidencia sobre licencias
Imagen generada con gpt-image-2.5-sunburst para InferamaFuente ↗
01

Introducción: la importancia de la trazabilidad legal en modelos abiertos

En el desarrollo de sistemas de inteligencia artificial, la distinción entre la disponibilidad técnica de un modelo y su viabilidad legal para su uso en producción es crítica. Para las organizaciones que evalúan modelos abiertos, la licencia del código fuente no es el único factor determinante; las condiciones bajo las cuales se distribuyen los pesos del modelo y, fundamentalmente, los datos de entrenamiento, pueden imponer restricciones significativas sobre el uso comercial o la redistribución.

El caso de Ai2 es particularmente relevante dado su énfasis declarado en la 'apertura total', que incluye la publicación de código, datos y pesos. Sin embargo, la verificación de estas afirmaciones requiere un examen detallado de las fuentes primarias vigentes. Esta pieza analiza qué información es actualmente verificable a través de la documentación oficial y los repositorios públicos, identificando las áreas donde la evidencia es insuficiente para emitir un dictamen legal definitivo.

La trazabilidad legal no se obtiene con una sola etiqueta de «abierto»: exige vincular cada artefacto concreto con los términos que rigen su uso y distribución. En un mismo catálogo pueden coexistir código, pesos y datos publicados bajo condiciones distintas, por lo que una afirmación institucional sobre apertura describe una política de publicación, pero no reemplaza la lectura de las licencias aplicables a cada componente. Esta separación ayuda a evitar que la disponibilidad para descargar o inspeccionar un recurso se confunda con un permiso irrestricto para incorporarlo a un producto o redistribuirlo.

La incertidumbre documental tampoco equivale por sí sola a una prohibición. Significa que, con los extractos disponibles, no se puede concluir qué permisos o límites se aplican a un artefacto específico. Por eso, el análisis distingue entre lo que está expresamente documentado —como la licencia identificada para ciertos repositorios de código— y aquello que todavía requiere verificación. Mantener esa diferencia permite describir la evidencia sin convertir una ausencia de información en una conclusión jurídica, y deja claro por qué la decisión de adopción puede requerir una comprobación adicional.

02

Metodología de verificación documental

Para auditar el catálogo de modelos de una organización, se establecen tres niveles de verificación: el código de entrenamiento e inferencia, los pesos del modelo (model weights) y los conjuntos de datos de entrenamiento. Cada uno de estos artefactos puede estar sujeto a licencias distintas. La metodología consiste en localizar los repositorios oficiales y los portales de documentación, y extraer las declaraciones de licencia vigentes en el momento de la consulta.

En el caso de Ai2, la documentación oficial para desarrolladores actúa como la puerta de entrada al ecosistema. Esta fuente confirma la existencia de modelos como OLMo, Molmo y Tülu, así como de conjuntos de datos como Dolma y Pixmo. El perfil de la organización en GitHub permite localizar los repositorios de código asociados. La verificación se centra en identificar si estas fuentes primarias contienen declaraciones explícitas sobre los permisos de uso, distribución y modificación.

La auditoría debe seguir la identidad y el alcance de cada elemento, además de anotar dónde se encontró la información. Un archivo de licencia situado en un repositorio de código sirve para evaluar el contenido cubierto por ese archivo; no demuestra, sin una declaración que lo establezca, que los pesos o los datos relacionados estén sujetos a los mismos términos. Del mismo modo, una página general que enumera modelos y conjuntos de datos puede servir para localizarlos, pero su función informativa no basta para atribuirles una licencia concreta.

Para que la revisión sea reproducible, conviene registrar qué fuente primaria se examinó, qué artefacto identifica, qué declaración se pudo observar y qué cuestión queda pendiente. La fecha de consulta importa porque la documentación y los repositorios pueden cambiar; por ello, una conclusión debe entenderse referida a las fuentes vigentes y efectivamente revisadas en ese momento, no como una garantía permanente sobre todo el catálogo. Cuando no aparece una licencia específica, anotar «no verificado» conserva el límite de la evidencia y evita presentar como permiso o restricción aquello que la documentación no permite determinar.

Los tres niveles de la metodología se complementan, pero no son intercambiables. El código permite comprobar los términos asociados al software publicado; los pesos requieren localizar una declaración referida a esos archivos o al modelo correspondiente; y los datos necesitan una revisión de su propia documentación y condiciones. Esta separación también permite identificar con precisión qué pregunta queda abierta: no basta saber que un modelo o conjunto de datos existe, sino que hay que vincular la declaración jurídica con el recurso concreto que se pretende utilizar.

Proceso de auditoría de licencias

Pasos para verificar la trazabilidad legal de un modelo abierto:

  1. 01Identificar el repositorio oficial de código (GitHub) y la documentación técnica (portal de desarrolladores).
  2. 02Localizar el archivo de licencia (LICENSE) en el repositorio de código y verificar su tipo (ej. Apache-2.0, MIT).
  3. 03Buscar la declaración de licencia para los pesos del modelo en el portal de distribución (ej. Hugging Face) o en la documentación específica del modelo.
  4. 04Revisar la documentación del conjunto de datos de entrenamiento para identificar la licencia de los datos y cualquier restricción de uso derivada de la procedencia de los datos.
  5. 05Documentar las lagunas: si la licencia de los datos o los pesos no está explícitamente declarada en las fuentes primarias, marcar el estado como 'no verificado'.
03

Estado de la evidencia en las fuentes primarias

La revisión de la documentación oficial de Ai2 confirma la política institucional de 'apertura total', que promete la liberación de código, datos, pesos y recetas de entrenamiento. Esta declaración es un hecho verificable en el portal de desarrolladores. Sin embargo, el texto de la documentación general no especifica las licencias jurídicas exactas que rigen cada uno de estos componentes.

En el perfil de GitHub de la organización, se observa que varios repositorios de código, como 'Olmo-core', 'open-instruct' y 'olmo-eval', están bajo la licencia Apache-2.0. Esto permite verificar la licencia del código de entrenamiento e inferencia para estas herramientas. No obstante, la licencia del código no se extiende automáticamente a los pesos del modelo ni a los datos de entrenamiento, que suelen distribuirse a través de plataformas externas o en repositorios específicos con términos propios.

La evidencia disponible permite formular una conclusión acotada: algunos repositorios de código identificados en la revisión muestran Apache-2.0, mientras que los extractos consultados no ofrecen la misma especificidad para los pesos de OLMo, Molmo y Tülu ni para los datos de Dolma y Pixmo. El alcance de esa conclusión es documental. No demuestra que tales artefactos carezcan de licencia, ni permite deducir cuáles serían sus términos; señala únicamente que la información examinada no basta para verificarlos.

La tabla debe leerse como un inventario del estado de comprobación, no como una clasificación de permisos para todo el ecosistema. «Verificada» se refiere al componente y a los repositorios de código mencionados, no a cualquier elemento asociado con esos modelos. «No verificada» expresa que la licencia no quedó establecida en el extracto consultado; no significa que el recurso esté necesariamente prohibido, ni que la organización no haya publicado información más específica en otra fuente primaria aún no examinada. Esta lectura conserva el límite entre la prueba disponible y las preguntas que permanecen abiertas.

La declaración de apertura institucional y la licencia de los repositorios aportan piezas distintas de la evaluación. La primera documenta que Ai2 declara publicar código, datos, pesos y recetas; la segunda permite identificar condiciones jurídicas para determinados repositorios. Ninguna de esas observaciones, por separado, demuestra que todos los elementos liberados tengan idénticos permisos. Para una conclusión sobre un uso concreto habría que relacionar el artefacto pertinente con sus propios términos, algo que la documentación general descrita aquí no resuelve.

Resumen de la evidencia verificada en fuentes primarias

Estado de la verificación de licencias según las fuentes consultadas.

ComponenteFuente primariaLicencia verificadaEstado de la evidencia
Código de entrenamiento (Olmo-core, open-instruct)GitHub (allenai)Apache-2.0Verificada
Pesos de modelos (OLMo, Molmo, Tülu)Documentación oficial / GitHubNo especificada en el extractoNo verificada
Datos de entrenamiento (Dolma, Pixmo)Documentación oficial / GitHubNo especificada en el extractoNo verificada
04

Análisis de las lagunas en la documentación

Una de las principales limitaciones al auditar el catálogo de Ai2 con las fuentes actuales es la falta de una declaración centralizada y explícita sobre las licencias de los pesos y los datos. La documentación describe la naturaleza 'abierta' de los recursos, pero no detalla los términos legales específicos, como si se permite el uso comercial sin restricciones adicionales o si existen cláusulas de atribución obligatoria.

Esta laguna es crítica para los equipos de cumplimiento legal. La licencia Apache-2.0 del código garantiza la libertad de uso del software de entrenamiento, pero no resuelve la cuestión de los datos de Dolma (3 billones de tokens) ni de los pesos de OLMo. Sin una declaración clara en la documentación primaria, no es posible afirmar con certeza que el uso comercial esté libre de restricciones derivadas de la procedencia de los datos o de los términos de la plataforma de distribución.

La diferencia entre una licencia de software y los términos de los recursos asociados es importante porque cada permiso tiene un alcance definido por su propio texto. La licencia Apache-2.0 identificada para el código permite describir el estado de esos repositorios, pero no se puede extrapolar automáticamente a los pesos ni a los datos. Esa cautela no presupone que existan restricciones: evita afirmar que no las hay cuando los extractos no contienen la declaración necesaria para comprobarlo.

En la evaluación de una adopción, el equipo puede separar sus decisiones en preguntas verificables: qué código piensa utilizar y qué licencia aparece para él; qué pesos concretos necesita y qué términos se declaran para esos archivos; y qué datos se han usado o se pretenden utilizar, junto con la documentación disponible sobre sus condiciones. Esta descomposición no resuelve por sí misma la interpretación jurídica, pero ayuda a impedir que una respuesta positiva en el primer punto se trate como respuesta suficiente para los otros dos.

La referencia a los 3 billones de tokens describe el tamaño atribuido a Dolma en la documentación mencionada, pero esa cifra no establece los permisos de uso del conjunto. El volumen de un corpus y las condiciones jurídicas bajo las cuales se distribuye son cuestiones distintas. Por tanto, conocer la escala de los datos no permite inferir si el uso comercial está autorizado, si se exige atribución o si existen otros términos; esas conclusiones requieren una declaración aplicable al conjunto y no pueden derivarse de la licencia del código.

El escenario de evaluación comercial ilustra una consecuencia de la laguna, no un dictamen sobre OLMo ni una afirmación de que Dolma prohíba ese uso. Si la licencia de los datos impusiera una condición incompatible, podría afectar la decisión aunque el código tuviera una licencia permisiva; pero los extractos no establecen que esa condición exista. La decisión responsable consiste en mantener esa posibilidad como una cuestión por verificar y no convertirla en un hecho sobre los datos o el modelo.

05

Límites de la evidencia y preguntas abiertas

La verificación realizada con las fuentes proporcionadas permite confirmar la existencia de los modelos y la licencia del código de entrenamiento, pero no resuelve las preguntas sobre las licencias de los pesos y los datos. La documentación oficial actúa como un índice de recursos, pero no como un contrato legal detallado para cada artefacto.

Quedan abiertas las siguientes preguntas: ¿Cuál es la licencia exacta de los pesos de OLMo y Molmo? ¿Bajo qué términos se distribuyen los datos de Dolma y Pixmo? ¿Existe una documentación oficial que clarifique la relación jurídica entre la licencia del código y la de los datos? Hasta que estas preguntas no sean respondidas con fuentes primarias específicas (como archivos LICENSE en los repositorios de pesos o documentación de datos), la trazabilidad legal del catálogo de Ai2 permanece incompleta.

Las preguntas abiertas pueden convertirse en una lista de comprobación ligada a cada artefacto: localizar la declaración correspondiente a los pesos de cada modelo citado; identificar los términos publicados para cada conjunto de datos; y comprobar si existe una explicación oficial que delimite qué cubre la licencia del código y qué queda sujeto a condiciones separadas. Una respuesta válida debe referirse al recurso pertinente y proceder de documentación primaria aplicable; una mención general a la apertura no suple esa relación.

Hasta completar esas comprobaciones, la conclusión debe conservar su alcance limitado: se confirmó la existencia de los recursos enumerados y la licencia Apache-2.0 en los repositorios de código señalados, pero no se verificaron en los extractos las licencias de los pesos y los datos. Esto no permite concluir que estén restringidos, que estén libres de condiciones o que la licencia del código los cubra. El resultado es una trazabilidad incompleta en la documentación examinada, no una determinación definitiva sobre todos los términos vigentes.

Al revisar metadatos de distribución o archivos específicos, conviene comprobar que la licencia corresponde al recurso que se pretende adoptar y que los términos observados se refieren a su uso, modificación o redistribución, según lo que se necesite evaluar. Si la documentación encontrada sigue siendo general o no identifica con claridad el artefacto, la incertidumbre continúa y debe registrarse como tal. Así se evita cerrar la revisión por la mera presencia de una etiqueta de licencia en un componente distinto.

La recomendación de consultar fuentes específicas es un paso de verificación, no una garantía de que la consulta vaya a resolver todas las cuestiones jurídicas. Si los metadatos del modelo o la documentación de datos no contienen una declaración inequívoca, la licencia seguirá sin estar verificada con la evidencia disponible. En ese caso, lo prudente es conservar la pregunta abierta y no atribuir a los pesos o a los conjuntos de datos los permisos observados para el código.

Qué sigue abierto

  • La licencia específica de los pesos de los modelos OLMo, Molmo y Tülu no está declarada en los extractos de las fuentes primarias proporcionadas.
  • Los términos de uso y la licencia de los conjuntos de datos Dolma y Pixmo no se especifican en la documentación general consultada.
  • No se puede determinar si la licencia del código (Apache-2.0) se extiende a los artefactos de datos o pesos, ya que suelen tener licencias independientes.
06

Continúa explorando

06

Fuentes consultadas

03

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.

Proponer una corrección