Los modelos de IA generativa de código abierto pueden descargarse gratuitamente, utilizarse a escala sin acumular costes de llamadas a la API y ejecutarse de forma segura tras los cortafuegos corporativos. Pero no hay que bajar la guardia. Los riesgos siguen existiendo.
Parece que hoy en día cualquiera puede crear un modelo de inteligencia artificial (IA). Aunque no se disponga de datos de entrenamiento ni de conocimientos de programación, se puede tomar el modelo de código abierto favorito, modificarlo y publicarlo con un nuevo nombre.
Según el Informe sobre el Índice de IA de Stanford, publicado en abril, en 2023 se publicaron 149 modelos básicos, dos tercios de ellos de código abierto. Y hay un número demencial de variantes. Hugging Face rastrea actualmente más de 80.000 grandes modelos del lenguaje (LLM, por sus siglas en inglés) sólo para la generación de texto y, afortunadamente, cuenta con una tabla de clasificación que permite ordenar rápidamente los modelos según su puntuación en diversas pruebas de referencia. Y estos modelos, aunque van a la zaga de los grandes modelos comerciales, están mejorando rápidamente.
Las tablas de clasificación son un buen punto de partida a la hora de analizar la IA generativa de código abierto, afirma David Guarrera, responsable de IA generativa de EY Americas.
El panorama de los distintos tipos de licencias de código abierto ya es bastante complicado. ¿Un proyecto es seguro para uso comercial o sólo para implementaciones no comerciales? ¿Se puede modificar y distribuir? ¿Puede incorporarse con seguridad a una base de código propietario? Ahora, con la IA generativa, hay algunas novedades. En primer lugar, hay nuevos tipos de licencia que sólo son de código abierto según una definición muy laxa del término.
Por ejemplo, la licencia Llama. La familia de modelos Llama son algunos de los mejores LLM de código abierto que existen, pero Meta la describe oficialmente como una “licencia comercial a medida que equilibra el acceso abierto a los modelos con la responsabilidad y las protecciones existentes para ayudar a abordar el posible uso indebido”.
Las empresas pueden utilizar los modelos con fines comerciales y los desarrolladores pueden crear y distribuir trabajos adicionales a partir de los modelos básicos de Llama, pero no pueden utilizar los resultados de Llama para mejorar otros LLM, a menos que sean derivados de Llama. Y si las empresas -o sus filiales- tienen más de 700 usuarios mensuales, tienen que solicitar una licencia que Meta puede conceder o no. Si utilizan Llama 3, tienen que incluir Built with Llama 3 en un lugar destacado.
Del mismo modo, Apple acaba de publicar OpenELM bajo la Apple Sample Code License, que también se ha inventado para la ocasión y sólo cubre los permisos de copyright, excluyendo los derechos de patente.
El código abierto suele implicar un esfuerzo debido al “hágalo usted mismo”. Las empresas pueden descargar el código, pero luego necesitan expertos internos o consultores contratados para que todo funcione. Este es un gran problema en el ámbito de la IA generativa. Nadie tiene años de experiencia porque la tecnología es muy nueva. Si una empresa está empezando con la IA generativa, o si quiere avanzar rápidamente, es más seguro empezar con una plataforma propietaria, dice Rao.
“Se necesita experiencia para descargar la versión de código abierto”, afirma. Pero una vez que una empresa ha hecho su prueba de concepto, despliega el modelo en producción y las facturas empiezan a acumularse, puede que sea el momento de buscar alternativas de código abierto, añade.
La falta de experiencia en el sector también crea otro problema para la IA generativa de código abierto. Una de las principales ventajas del código abierto es que muchas personas examinan el código y pueden detectar errores de programación, vulnerabilidades de seguridad y otros puntos débiles. Pero este enfoque de “mil ojos” a la seguridad del código abierto sólo funciona si hay, de hecho, mil ojos capaces de entender lo que están viendo.
Los LLM son notoriamente susceptibles al jailbreaking, cuando un usuario le da una instrucción inteligente que lo engaña para que viole sus directrices y, por ejemplo, genere malware. En el caso de los proyectos comerciales, hay vendedores muy motivados detrás de ellos que pueden identificar estas lagunas y cerrarlas a medida que aparecen. Además, los vendedores tienen acceso a los mensajes que los usuarios envían a las versiones públicas de los modelos, por lo que pueden detectar indicios de actividad sospechosa.
Es menos probable que los malintencionados adquieran versiones empresariales de los productos que se ejecutan en entornos privados, en los que las instrucciones no se comunican al proveedor para mejorar el modelo. Con un proyecto de código abierto, puede que no haya nadie en el equipo cuyo trabajo sea buscar indicios de jailbreaking. Y los malos pueden descargar estos modelos gratuitamente y ejecutarlos en sus propios entornos para probar posibles hackeos. Los malhechores también tienen una ventaja en su intento de piratear, ya que pueden ver el sistema que utiliza el modelo y cualquier otra barrera de seguridad que los desarrolladores del modelo puedan haber construido.
Si un modelo de IA añade una marca de agua a sus resultados, un actor malicioso podría analizar el código para aplicar ingeniería inversa al proceso con el fin de eliminar la marca de agua. Los atacantes también podrían analizar el modelo u otros códigos y herramientas de apoyo para encontrar áreas de vulnerabilidad.
Artistas, escritores y otros titulares de derechos de autor están demandando a diestro y siniestro a las grandes empresas de IA. Pero, ¿y si creen que sus derechos de propiedad intelectual están siendo vulnerados por un modelo de código abierto, y los únicos bolsillos llenos son los de las empresas que han incorporado ese modelo a sus productos o servicios? ¿Podrían ser demandados los usuarios empresariales?
“Es un problema potencial y nadie sabe realmente cómo van a desarrollarse algunos de los litigios pendientes”, afirma Guarrera, de EY. Es posible que nos dirijamos hacia un mundo en el que tendrá que haber algún tipo de compensación por los conjuntos de datos, dice. “Los grandes actores tecnológicos están mejor posicionados para tener el dinero que gastar en eso y capear el temporal que puede venir en torno a los derechos de autor”.
Los grandes proveedores comerciales no sólo tienen dinero para gastar en comprar datos de entrenamiento y luchar contra las demandas, también tienen dinero para gastar en conjuntos de datos curados, dice Sügis. Los conjuntos de datos públicos y gratuitos no sólo contienen contenidos protegidos por derechos de autor utilizados sin permiso. También están llenos de información inexacta y sesgada, malware y otros materiales que pueden degradar la calidad de los resultados.
Dado que un proyecto de IA generativa es algo más que el código, hay más áreas de exposición potencial. Un LLM puede ser atacado por malos actores en varios frentes. Podrían infiltrarse en el equipo de desarrollo de un proyecto mal gestionado y añadir código malicioso al propio software. Pero también podrían envenenar los datos de entrenamiento, el ajuste fino o las ponderaciones, dice Sügis.
Algunos grupos de código abierto pueden tener una objeción filosófica a la hora de incluir salvaguardas en sus modelos, o pueden creer que un modelo funcionará mejor sin ninguna restricción. Y algunos se crean específicamente para ser utilizados con fines maliciosos. Las empresas que buscan un LLM para probar no necesariamente saben en qué categoría se encuentran sus modelos. Actualmente no existe ningún organismo independiente que evalúe la seguridad de los modelos de IA generativa de código abierto, afirma Sügis, de Nortal. La ley europea sobre IA exigirá parte de esta documentación, pero la mayoría de sus disposiciones no entrarán en vigor hasta 2026, afirma.
Los proyectos de código abierto impulsados por los usuarios suelen basarse en estándares, ya que los usuarios empresariales prefieren disponer de ellos y de interoperabilidad. De hecho, según una encuesta realizada el año pasado por la Fundación Linux a casi 500 profesionales de la tecnología, el 71% prefiere los estándares abiertos, frente al 10% que prefiere los cerrados. Las empresas que producen software propietario, en cambio, quizá prefieran tener a sus clientes atrapados en sus ecosistemas. Pero si espera que la IA generativa de código abierto esté basada en estándares, se equivoca.
De hecho, cuando la mayoría de la gente habla de estándares de IA, se refiere a cuestiones como la ética, la privacidad y la explicabilidad. Y se está trabajando en este ámbito, como la norma ISO/IEC 42001 para sistemas de gestión de IA, publicada en diciembre del año pasado. Y, el 29 de abril, el NIST publicó un proyecto de plan de normas sobre IA que cubre mucho terreno, empezando por la creación de un lenguaje común para hablar de IA. También se centra en gran medida en cuestiones de riesgo y gobernanza. Pero aún no hay mucho en lo que se refiere a normas técnicas.
En cambio, dice, es más probable que la gente considere las API y las interfaces de los principales proveedores, como OpenAI, como normas de facto incipientes. “Eso es lo que estoy viendo que hace la gente”, asegura.
Se podría pensar que los modelos de código abierto son, por definición, más transparentes. Pero no siempre es así. Los grandes proyectos comerciales pueden disponer de más recursos para crear documentación, afirma Eric Sydell, director general de Vero AI, proveedor de software de BI, que acaba de publicar un informe en el que puntúa los principales modelos de IA de género en función de aspectos como la visibilidad, la integridad, la preparación legislativa y la transparencia. Gemini, de Google, y GPT-4, de OpenAI, obtuvieron las mejores puntuaciones.
“El hecho de que sean de código abierto no significa necesariamente que ofrezcan la misma información sobre los antecedentes del modelo y cómo se ha desarrollado”, afirma Sydell. “Los modelos comerciales más grandes han hecho un mejor trabajo en este sentido”.
Es habitual que los proyectos de código abierto se bifurquen, pero cuando esto ocurre con la IA generativa, se corren riesgos que no se dan con el software tradicional. Digamos, por ejemplo, que un modelo básico utiliza un conjunto de datos de entrenamiento problemático y, a partir de él, alguien crea un nuevo modelo, por lo que heredará estos problemas, dice Tyler Warden, vicepresidente senior de producto en Sonatype, un proveedor de ciberseguridad.
De hecho, esos problemas pueden ir varios niveles más atrás y no serán visibles en el código del modelo final. Cuando una empresa descarga un modelo para su propio uso, el modelo se aleja aún más de las fuentes originales. El modelo base original podría haber solucionado los problemas, pero, dependiendo de la transparencia y la comunicación hacia arriba y hacia abajo en la cadena, los desarrolladores que trabajan en el último modelo podrían ni siquiera ser conscientes de las correcciones.
Las empresas que utilizan componentes de código abierto como parte de su proceso de desarrollo de software cuentan con procesos para examinar las bibliotecas y asegurarse de que los componentes están actualizados. Se aseguran de que los proyectos están bien respaldados, de que se resuelven los problemas de seguridad y de que el software tiene las condiciones de licencia adecuadas.
Sin embargo, en el caso de la IA generativa, es posible que las personas encargadas de la investigación no sepan qué buscar. Además, los proyectos de IA generativa a veces quedan fuera de los procesos estándar de desarrollo de software. Pueden surgir de equipos de ciencia de datos o de skunkworks. Es posible que los desarrolladores descarguen los modelos para jugar con ellos y acaben generalizándose. O los propios usuarios de las empresas pueden seguir tutoriales en línea y crear su propia IA genérica, sin pasar por TI.
La última evolución de la IA generativa, los agentes autónomos, tienen el potencial de poner un enorme poder en manos de estos sistemas, elevando el potencial de riesgo de este tipo de TI en la sombra a nuevas cotas.
Algunas empresas buscan el bajo coste, la transparencia, la privacidad y el control del código abierto, pero les gustaría contar con un proveedor que se encargue de la gobernanza, la sostenibilidad a largo plazo y la asistencia. En el mundo tradicional del código abierto, hay muchos proveedores que lo hacen, como Red Hat, MariaDB, Docker, Automattic y otros.
“Proporcionan un nivel de seguridad y protección para las grandes empresas”, dice Priya Iragavarapu, vicepresidente de Ciencia de Datos y Análisis en AArete. “Es casi una forma de mitigar el riesgo”.
No hay demasiados de estos proveedores en el espacio de la IA generativa, pero las cosas están empezando a cambiar, concluye.
FUENTE: Korolov, Maria. ''10 cosas a tener en cuenta con la IA generativa de código abierto'' Cio.com. 17/05/2024. ( https://www.cio.com/article/2112040/10-cosas-a-tener-en-cuenta-con-la-ia-generativa-de-codigo-abierto.html)