Mozilla ha presentado un marco destinado a describir con mayor precisión hasta qué punto es abierto un sistema de inteligencia artificial. La propuesta abandona la división simple entre modelos abiertos y cerrados para examinar por separado sus distintos componentes, como los datos, el código, los pesos y la documentación.
El trabajo procede de una iniciativa que Mozilla y el Instituto de Política Global de la Universidad de Columbia pusieron en marcha en 2024. Aquel encuentro reunió a más de 40 investigadores, desarrolladores y especialistas en políticas públicas con el objetivo de crear un vocabulario compartido sobre la apertura de los modelos fundacionales.
La iniciativa ha alcanzado ahora un nuevo hito con la publicación en Communications of the ACM del artículo académico que desarrolla el marco. Su planteamiento busca que desarrolladores, investigadores, reguladores y organizaciones civiles puedan analizar sistemas concretos sin depender de una etiqueta tan amplia como «IA de código abierto».
La apertura no funciona como un interruptor
La idea central es que la apertura debe entenderse como un gradiente, no como una condición binaria. Un modelo puede permitir el acceso a sus pesos y mantener cerrados los datos empleados durante su entrenamiento. Del mismo modo, puede publicar el código sin explicar de manera suficiente cómo fue evaluado.
Esta separación por capas permite identificar qué puede inspeccionar, utilizar o modificar cada actor. También evita atribuir automáticamente transparencia a todo el sistema porque uno de sus elementos sea accesible. En la práctica, dos modelos descritos como abiertos podrían ofrecer posibilidades muy diferentes para auditar resultados, reproducir el entrenamiento o desarrollar productos derivados.
El enfoque aporta contexto a un debate que ya afecta a la competencia y a la capacidad de supervisión. La disponibilidad de pesos puede facilitar que terceros adapten un modelo, pero la ausencia de datos o documentación limita la posibilidad de estudiar sus sesgos, reconstruir decisiones técnicas o comprobar las condiciones en las que fue evaluado.
La seguridad también depende del despliegue
El marco introduce otra distinción relevante: el riesgo no puede evaluarse únicamente a partir del modelo. Mozilla señala que también importan el entorno de despliegue, las salvaguardas, las capas de moderación y las estructuras de gobernanza que rodean al sistema.
Esta visión desplaza parte del análisis desde los pesos hacia el producto completo. Un mismo modelo puede presentar perfiles de riesgo distintos según quién pueda utilizarlo, qué herramientas tenga conectadas, qué controles limiten sus acciones y cómo se gestionen los incidentes. Para empresas y administraciones, la consecuencia práctica es que revisar la licencia o el acceso al código no basta para valorar la seguridad de una implantación.
La propuesta encaja además con una preocupación más amplia por la trazabilidad de las herramientas digitales. Iniciativas como las nuevas tendencias de calidad de código para organizaciones de GitHub muestran cómo la supervisión necesita indicadores específicos, en lugar de una única valoración que oculte diferencias entre componentes y procesos.
Un vocabulario común, no una receta universal
Mozilla evita fijar un nivel de apertura que deba aplicarse a todos los sistemas. El marco no prescribe una combinación «correcta» de datos, código, pesos y documentación, sino que proporciona categorías para describirla y evaluar sus consecuencias caso por caso.
Esa decisión reconoce que los objetivos y riesgos cambian según el uso. Un proyecto de investigación, un asistente integrado en un navegador y un sistema capaz de operar sobre infraestructura crítica no requieren necesariamente las mismas condiciones. La utilidad del marco reside en hacer explícitas esas diferencias y permitir que las decisiones se comparen con criterios comunes.
Para los desarrolladores, esta clasificación puede ayudar a comunicar con exactitud qué partes de un proyecto están disponibles y bajo qué condiciones. Para los reguladores, ofrece una base más detallada para estudiar obligaciones y salvaguardas. Y para investigadores y auditores, permite localizar las capas que siguen fuera de su alcance antes de valorar las afirmaciones de transparencia de un proveedor.
El documento es el resultado de un proceso de alrededor de dos años y de una colaboración entre academia, industria y sociedad civil. Su alcance, por ahora, es conceptual: organiza el análisis y los intercambios sobre apertura, pero no convierte por sí mismo esas categorías en una norma obligatoria ni resuelve qué equilibrio debe adoptarse en cada producto.
La consecuencia más inmediata es una exigencia de precisión. A partir de este enfoque, llamar abierto a un sistema aporta poca información si no se especifica qué ocurre con sus datos, su código, sus pesos, su documentación y su despliegue. Esa descripción por capas puede hacer más verificables las promesas sobre transparencia, competencia, seguridad y rendición de cuentas.
