Gran parte del software moderno se construye sobre código abierto. Frameworks, librerías, herramientas de infraestructura, runtimes y modelos dependen del trabajo de comunidades y organizaciones que publican tecnología bajo distintas licencias. Usar open source, sin embargo, no significa usarlo sin condiciones: cada licencia define derechos y obligaciones. Y cuando un proyecto crece, gestionarlas deja de ser solo un asunto de desarrollo y pasa a formar parte de la gobernanza tecnológica de la empresa.
Qué es OpenChain ISO/IEC 5230
OpenChain ISO/IEC 5230 define los requisitos de un programa de cumplimiento de licencias open source: procesos que permiten a una organización identificar y gestionar de forma consistente las obligaciones asociadas al software abierto que utiliza. Myukura, nuestro producto de IA clínica, ha completado un programa conforme con este estándar.
El estándar no determina qué tecnologías debe elegir una empresa, y tampoco certifica la seguridad o la calidad de un producto. Se concentra en una cosa concreta: el proceso de cumplimiento de licencias open source.
Por qué importa especialmente en inteligencia artificial
En IA las dependencias se han vuelto especialmente complejas. Una misma aplicación puede reunir librerías tradicionales, frameworks de machine learning, runtimes, datasets, pesos de modelos y otros artefactos de entrenamiento. Y no todo lo que se llama públicamente open source usa la misma licencia ni concede los mismos derechos.
Algunos componentes permiten modificación y uso comercial con pocas obligaciones. Otros exigen conservar avisos, publicar determinadas modificaciones o cumplir condiciones específicas de distribución. En los modelos de IA, además, existen licencias de pesos que no siempre coinciden con las licencias open source habituales del software. Para quien investiga distintos modelos y arquitecturas, conocer esas diferencias es fundamental.
Cumplimiento desde las primeras etapas
Es habitual dejar la documentación de dependencias, las atribuciones o la revisión de licencias para una etapa posterior. El problema es que reconstruir años después qué componente entró en un producto, en qué versión y bajo qué condiciones resulta bastante más difícil.
Nuestra aproximación es introducir estas prácticas mientras la arquitectura aún está creciendo, de modo que cada decisión técnica incorpore desde el principio preguntas como:
- qué licencia tiene una dependencia;
- qué obligaciones introduce;
- si permite el uso previsto;
- qué avisos deben conservarse;
- y qué implicaciones tendría distribuir o modificar ese componente.
Open source no significa ausencia de responsabilidad
Que un proyecto publique su código o sus pesos no significa que pueda usarse sin restricciones, ni que todas las licencias abiertas sean equivalentes. La innovación basada en open source funciona precisamente porque existen reglas que permiten reutilizar tecnología respetando las condiciones elegidas por sus autores. Gestionarlas bien es parte de construir software profesional.
La confianza en un producto tecnológico no depende solo de lo que se ve en la interfaz. También depende de cómo se construye.
Qué puede llevarse tu organización
No hace falta ser una empresa de IA para que esto sea relevante. Cualquier organización que adopte modelos, librerías o herramientas abiertas hereda sus condiciones de licencia. Un buen punto de partida es tener claro qué componentes se utilizan, bajo qué licencia y con qué obligaciones, antes de que un sistema llegue a producción. Es el tipo de pregunta que conviene incorporar desde el diseño de cualquier proyecto, ya sea de consultoría y soluciones o de formación para equipos.
Una capa más de gobernanza tecnológica
Para Myukura, trabajar conforme a OpenChain forma parte de un principio más amplio: arquitectura, seguridad, privacidad, gestión de dependencias, licencias y supervisión de los sistemas de IA son parte de la infraestructura invisible de un producto. Nuestra intención es que estas prácticas crezcan junto con el producto y no después de él.
Es una línea distinta de la certificación de empresa emergente de ENISA, que acredita a la empresa y no al producto. Y responde a una idea que repetimos a menudo: desarrollar IA responsable no consiste solo en controlar qué responde un modelo. También implica saber con qué está construido el sistema, bajo qué condiciones puede utilizarse y qué responsabilidades se asumen al hacerlo.