10 cosas a tener en cuenta con la IA generativa de código abierto

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.

“Pero no hay que subestimar el valor de entrar ahí y jugar con estos modelos”, afirma. “Como son de código abierto, es fácil hacerlo e intercambiarlos”. Y añade que la diferencia de rendimiento entre los modelos de código abierto y sus alternativas comerciales cerradas es cada vez menor.

“El código abierto es estupendo”, añade Val Marchevsky, responsable de Ingeniería de Uber Freight. “El código abierto me parece extremadamente valioso”. No sólo están alcanzando a los modelos propietarios en rendimiento, sino que algunos ofrecen niveles de transparencia que el código cerrado no puede igualar, dice. “Algunos modelos de código abierto permiten ver qué se utiliza para la inferencia y qué no”, añade. “La auditabilidad es importante para evitar alucinaciones”.

Además, por supuesto, está la ventaja del precio. “Si tienes un centro de datos que casualmente tiene capacidad, ¿por qué pagar a otro?”, dice.

Las empresas ya están muy familiarizadas con el uso de código abierto. Según el análisis de seguridad y riesgo del código abierto de Synopsys publicado en febrero, el 96% de todas las bases de código comerciales contenían componentes de código abierto.

Como resultado de toda esta experiencia, las empresas deberían saber qué hacer para asegurarse de que están utilizando código con la licencia adecuada, cómo comprobar si hay vulnerabilidades y cómo mantener todo parcheado y actualizado. Sin embargo, algunas de estas normas y buenas prácticas tienen matices particulares que las empresas pueden pasar por alto. He aquí los principales.

1. Nuevos y extraños términos de licencia

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.

Ni Apple ni Meta utilizan licencias de código abierto comúnmente aceptadas, pero el código es, de hecho, abierto. Apple ha publicado no sólo el código, sino también los pesos del modelo, el conjunto de datos de entrenamiento, los registros de entrenamiento y las configuraciones previas al entrenamiento. Lo que nos lleva al otro aspecto de las licencias de código abierto. El software tradicional de código abierto es sólo eso: código. El hecho de que sea de código abierto significa que se puede ver lo que hace y si hay problemas potenciales o vulnerabilidades en él.

Sin embargo, la IA generativa no es sólo código. También son los datos de entrenamiento, los pesos del modelo y el ajuste fino. Todas estas cosas son fundamentales para entender cómo funciona un modelo e identificar posibles sesgos. Un modelo entrenado, por ejemplo, en un archivo de teorías conspirativas sobre la Tierra plana será malo para responder a preguntas científicas, o un modelo ajustado por hackers norcoreanos podría ser malo para identificar correctamente el malware. Entonces, ¿los LLM de código abierto publican toda esa información? Depende del modelo, o incluso de la versión concreta del modelo, ya que no existen normas.

“A veces ponen a disposición el código, pero si no tienes el ajuste fino, podrías gastar mucho dinero para llegar a un rendimiento comparable”, dice Anand Rao, profesor de IA en la Universidad Carnegie Mellon y ex líder global de IA en PwC.

2. Escasez de personal cualificado

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.

3. ‘Jailbreaking’

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.

“No se trata sólo de ensayo y error”, afirma Rao. Los atacantes pueden analizar los datos de entrenamiento, por ejemplo, para descubrir formas de hacer que un modelo identifique erróneamente las imágenes, o que se descarrile cuando se encuentra con un mensaje que parece inocuo.

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.

“Se puede saturar la infraestructura con peticiones para que el modelo no lo haga”, dice Elena Sügis, científica de datos senior y líder de capacidades en Nortal, una consultora global de transformación digital. “Cuando el modelo es parte de un sistema más grande, y su salida es utilizada por otra parte del sistema, si podemos atacar cómo el modelo produce la salida, interrumpirá todo el sistema, lo que podría ser peligroso para la empresa”.

4. Riesgos de los datos de formación

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.

“Muchos desarrolladores de modelos hablan de utilizar datos curados”, afirma. “Y esto es más caro que si le echas todo Internet para entrenarlo”.

5. Nuevas áreas de exposición

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.

“Los piratas informáticos podrían volver a entrenar el modelo con ejemplos de código malicioso, de modo que invada la infraestructura del usuario”, afirma. “O pueden entrenarlo con noticias falsas y desinformación”.

Otro vector de ataque es el aviso del sistema del modelo.

“Suele estar oculto para el usuario”, añade. “El prompt del sistema podría tener guardarraíles o reglas de seguridad que permitirían al modelo reconocer comportamientos no deseados o poco éticos”.

Los modelos propietarios no revelan las indicaciones del sistema, dice, y tener acceso a ellas podría permitir a los hackers averiguar cómo atacar el modelo.

6. Faltan salvaguardas

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.

“Yo intentaría conseguir toda la documentación posible, probar y evaluar el modelo e implantar algunas medidas de seguridad dentro de la empresa”, defiende.

7. Falta de normas

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.

“Es un espacio increíblemente incipiente”, afirma Taylor Dolezal, CIO y responsable de Ecosistemas de la Cloud Native Computing Foundation. “Estoy viendo algunas buenas conversaciones en torno a las clasificaciones de datos, sobre tener un formato estándar para los datos de entrenamiento, para las API, para las indicaciones”. Pero, de momento, son solo conversaciones.

Ya existe un estándar de datos común para las bases de datos vectoriales, dice, pero no un lenguaje de consulta estándar. ¿Y qué hay de los estándares para agentes autónomos?

“Eso no lo he visto, pero me encantaría verlo”, dice. “No sólo hay que encontrar la manera de que los agentes realicen sus tareas específicas, sino también de vincularlas entre sí”.

La herramienta más común para crear agentes, LangChain, es más un marco que un estándar, afirma. Y las empresas usuarias, las que crean la demanda de normas, aún no están preparadas, dice. “La mayoría de los usuarios finales no saben lo que quieren hasta que empiezan a jugar con ello”.

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.

8. Falta de transparencia

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”.

Por ejemplo, el sesgo.

“Descubrimos que los dos mejores modelos cerrados de nuestro ranking tenían bastante documentación e invertían tiempo en explorar el tema”, dice.

9. Problemas de linaje

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.

“Hay muchos aspectos de caja negra con los pesos y los giros”, afirma.

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.

10. La nueva TI en la sombra

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.

“Si vas a experimentar con ello, crea un contenedor para hacerlo de una manera que sea segura para tu organización”, dice Kelley Misata, director senior de Código Abierto en Corelight. Esto debería ser responsabilidad del equipo de gestión de riesgos de una empresa, dice, y la persona que se asegura de que los desarrolladores, y la empresa en su conjunto, entiendan que existe un proceso es el CIO.

“Son los mejor situados para establecer la cultura”, afirma. “Aprovechemos la innovación y toda la grandeza que ofrece el código abierto, pero vayamos con los ojos abiertos”.

¿Lo mejor de los dos mundos?

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.