IA de código abierto para empresas: elegir entre software libre y propietario

Open source, open weights, propietario: ¿de qué hablamos exactamente?

Un modelo de pesos abiertos (open weight), un modelo de código abierto (open source) y un modelo propietario se distinguen por lo que el editor entrega a la empresa: el modelo en sí, sus recetas de entrenamiento, o solo un acceso mediante API.

Open weight: el modelo se descarga

Un modelo open weight puede descargarse y ejecutarse en una infraestructura personal o en la nube [35]. En la práctica, la empresa puede instalarlo en sus propios servidores y utilizarlo sin pasar por la API de un proveedor externo [34].

Open source: los pesos y, a menudo, las recetas

Los modelos llamados open source ofrecen sus pesos y, generalmente, sus recetas de entrenamiento [24]. Esta apertura hace posibles el autoalojamiento y una personalización avanzada [24]. Meta, con Llama, y Mistral AI, con Mistral 7B y Mixtral, se reclaman de esta categoría [37].

Propietario: un único editor conserva el control

Un modelo propietario está controlado por una sola empresa. Generalmente se accede a él mediante una API, sin que el usuario pueda ver ni modificar el código subyacente [23]. La literatura jurídica también habla de modelos «cerrados» o propietarios [9].

Dos precauciones de lectura

• Los ejemplos de la fuente [24] están desfasados. Cita Llama 3, Mistral 7B y Qwen2 en el lado abierto, y GPT-4o y Claude 3.5 en el lado propietario [24]. Ilustran las categorías, no el estado actual de la oferta.
• La etiqueta «open source» es una afirmación del editor [37], y la apertura real varía de un modelo a otro. La sección dedicada a las licencias detalla este punto.

¿Cuáles son las diferencias de fondo entre ambas familias?

Las dos familias difieren en lo que la empresa puede ver, modificar y alojar: el propietario se usa como un servicio listo para usar, mientras que el open source se despliega y se adapta. Un modelo open source (Mistral 7B, Llama 3, Qwen2, por ejemplo) ofrece sus pesos, y generalmente sus recetas de entrenamiento, en libre acceso. Los modelos propietarios (GPT-4o, Claude, Gemini) se ofrecen como API o SaaS [24].

Una lectura que hay que matizar

Varias fuentes de esta tabla son blogs de agencias o editores, no textos institucionales ni trabajos de investigación. Sus descripciones son coherentes entre sí, pero no se basan en ninguna medición. Dos casillas quedan vacías por falta de información fiable: la estandarización y el soporte en el lado open source. Estos puntos deben verificarse con el proveedor o el alojador elegido.

Estas diferencias estructuran las secciones siguientes: el coste, la protección de datos y la dependencia del proveedor dependen de dónde se ejecuta el modelo y de lo que puede modificarse. Oupi permite usar ambas familias en la misma herramienta, lo que evita decidir a priori entre ellas (ver el producto).

¿Los modelos de pesos abiertos alcanzan ya en rendimiento a los propietarios?

Sí, la brecha se reduce, pero el expediente no permite concluir una equivalencia general entre modelos de pesos abiertos y propietarios. Se establecen tres constataciones.

• El nivel alcanzado: modelos de código abierto como Llama-3 de Meta alcanzan el estado del arte que fijaban los modelos propietarios [1].
• El peso en el mercado: el auge de los modelos de código abierto es un factor importante del mercado de la IA generativa [9].
• La oferta: actores chinos hacen sus modelos más accesibles, a veces hasta el código abierto [3].

Modelos que se pueden alojar uno mismo

Llama (Meta) y Mistral figuran entre los modelos más utilizados de la categoría que puede instalarse en los propios servidores, sin pasar por la API de un proveedor externo [34]. Meta con Llama, y Mistral AI con Mistral 7B y Mixtral, se presentan como proveedores de modelos de código abierto [37]. El término se discute: la sección 1 distingue open source de open weights, y la sección 6 trata las licencias.

Lo que el expediente no dice

La afirmación sobre Llama-3 [1] es una constatación cualitativa. El expediente no contiene ningún benchmark comparativo cuantificado. Por tanto, no permite decir, tarea por tarea (redacción, extracción, código, francés), qué modelo gana ni con qué margen. «Alcanzar el estado del arte» no significa ser equivalente en todo, y un modelo concreto puede quedar por detrás en un caso de uso concreto.

La consecuencia práctica: probar con los propios casos

La única vía defendible consiste en evaluar los candidatos de ambas familias con los propios datos. Un protocolo mínimo consta de unos pocos puntos:

1. constituir un conjunto de consultas reales y representativas, en el idioma de trabajo;
2. someter las mismas consultas a un modelo propietario y a un modelo de pesos abiertos;
3. hacer que los equipos de negocio evalúen las respuestas;
4. medir la latencia y el coste observados, porque el rendimiento por sí solo no decide.

Oupi permite usar ambas familias de modelos en la misma herramienta, lo que facilita este tipo de comparación con consultas idénticas (ver el producto).

¿Cuánto cuesta realmente un modelo de IA: API o autoalojamiento?

El coste de un modelo de IA depende del volumen procesado y de las competencias disponibles internamente: las fuentes no coinciden sobre la opción más barata.

Dos lecturas enfrentadas

Según Tizy, un modelo open source autoalojado costaría entre 5 y 10 veces menos que un modelo propietario por API, con un volumen comparable [10]. Esta cifra se cita a partir de «Tech Insider», una fuente secundaria. El expediente no proporciona ningún detalle del cálculo, y Tizy es un actor comercial, por lo que debe tomarse con precaución. Otro contenido matiza el alcance: el open source ofrece ahorros significativos sobre todo a las empresas que disponen de experiencia técnica interna [13].

Otras fuentes recuerdan que los modelos son gratuitos de descargar, pero que el cálculo y el almacenamiento corren a cargo de la empresa [11]. Para un uso estándar, una API propietaria, o un modelo open source en un proveedor de inferencia, seguiría siendo a menudo más económico y fiable [22].

Estas posiciones no se contradicen frontalmente: describen situaciones distintas (grandes volúmenes y equipo técnico por un lado, uso habitual por otro).

Los conceptos de coste que hay que incluir

El autoalojamiento obliga a contar [12]:

• una infraestructura de cálculo adecuada;
• la gestión de las actualizaciones;
• el seguimiento del rendimiento;
• la seguridad del pipeline de IA.

Los tres últimos conceptos movilizan tiempo del equipo, que no aparece en una tarifa por token.

Razonar en costes completos

Comparar el precio por token de una API con el coste de un servidor no basta: hay que razonar en costes completos [40]. Para una API, esto significa proyectar el consumo real. Para el autoalojamiento, se suman el hardware o el alquiler de GPU, la explotación y las competencias.

Lo que hay que retener

Las fuentes del expediente no permiten fijar un umbral de rentabilidad universal. Todo depende del volumen y de las competencias: el autoalojamiento resulta pertinente cuando los volúmenes son elevados y el equipo sabe explotarlo, mientras que la API sigue siendo la opción más sencilla para un uso estándar. Para decidir, calcule ambos escenarios con sus propios volúmenes y casos de uso.

Open source o propietario: ¿cuál protege mejor los datos y la soberanía?

Un modelo instalado en los propios servidores ofrece el control de datos más directo. Sin embargo, el open source no garantiza por sí solo la soberanía, y un modelo propietario no queda descartado por principio.

Lo que cambia con el autoalojamiento. Una empresa puede instalar un modelo open source en sus propios servidores y utilizarlo sin pasar por la API de un proveedor externo [34]. Esta configuración permite conservar el control de los datos [18]. Con un modelo propietario, la empresa envía sus datos mediante una API y no tiene visibilidad sobre el funcionamiento interno del modelo [21].

Por qué la soberanía pesa en la elección. La soberanía digital y el cumplimiento normativo, reforzados por la AI Act europea, empujan a las empresas a buscar soluciones en las que controlen su infraestructura y eviten la dependencia de gigantes estadounidenses o chinos [31]. Esta fuente es un blog de agencia: describe una tendencia del mercado, no un análisis jurídico.

El modelo europeo no basta. Elegir un modelo europeo solo resuelve una parte de la cuestión, ya que la soberanía depende también de otros factores, como el alojamiento [22]. Un modelo abierto explotado en un proveedor de inferencia no ofrece, por tanto, el mismo nivel de control que un modelo ejecutado en la propia infraestructura. Hay que verificar dónde se ejecuta realmente el modelo.

Lo que cambia la AI Act según la familia del modelo. El Reglamento (UE) 2024/1689, en vigor desde el 1 de agosto de 2024, introduce una diferencia entre open source y propietario [26]. Para un uso puramente interno, sin puesta a disposición de usuarios externos, la obligación indicada se limita a informar a los colaboradores de que interactúan con una IA [26]. Este ejemplo vale para herramientas como ChatGPT, Claude o Mistral [26].

Por verificar: esta afirmación procede de un blog que remite a service-public.fr [26]. Antes de cualquier decisión de cumplimiento, contrástela con el texto oficial del reglamento.

Una decisión por uso. Las exigencias de confidencialidad varían según los casos de uso. En Oupi, ambas familias de modelos se usan en la misma herramienta (ver el producto), lo que evita imponer una sola elección a toda la empresa.

¿«Open source» significa siempre libre de uso? Lo que dicen las licencias

No: «open source» no indica por sí solo lo que la empresa puede hacer con un modelo. Es la licencia la que lo fija, y varía de un modelo a otro. Según un panorama de Lebigdata, ninguna licencia se impone [33]:

Las condiciones también pueden cambiar de una versión a otra. Meta eligió Apache 2.0 para Muse Glimmer, abandonando su licencia comunitaria histórica [33].

La etiqueta «open source» no siempre resuelve la cuestión. Una publicación de investigación plantea cuándo puede hablarse de licencia open source, incluso a propósito de Mistral 7B [2]. Para un director de sistemas, la mención comercial de un editor no sustituye la lectura del texto de la licencia.

Un proyecto abierto también puede cambiar de rumbo. Una publicación de investigación recuerda que puede tomar un giro propietario [4]. Conservar la licencia aplicable a la versión realmente desplegada es una precaución prudente, porque las condiciones de una versión posterior pueden ser diferentes.

Los modelos conformes con OSAID se presentan como más seguros jurídicamente. Según ZDNET, ofrecen a las organizaciones transparencia, seguridad jurídica y funciones de personalización completas [20]. El criterio es un filtro de partida, no una garantía: no dispensa de verificar la licencia del modelo elegido.

En cambio, los modelos llamados cerrados o propietarios no dan acceso a su código fuente [9]. Sus condiciones de uso se rigen entonces por el contrato del editor.

Antes de cualquier uso comercial, lea la licencia del modelo, versión por versión, y haga validar sus condiciones por su servicio jurídico. Oupi permite usar ambas familias de modelos en la misma herramienta, lo que facilita la comparación con sus casos de uso (ver el producto). La verificación de las licencias debe hacerla usted.

¿Qué riesgo de dependencia del proveedor (lock-in) según la elección del modelo?

El riesgo de dependencia del proveedor existe con ambas familias de modelos, pero no adopta la misma forma. El lock-in designa la situación en la que cambiar de proveedor cuesta demasiado en tiempo, desarrollo u organización.

El riesgo del lado del modelo propietario

Una vez que un modelo propietario está profundamente integrado en los flujos de trabajo y las API, resulta difícil de reemplazar [7]. Cuanto más avanza la integración, más cara resulta la salida. Es sobre todo en el momento del diseño cuando hay que preocuparse por ello.

El riesgo es especialmente claro para las pymes: quien construye una oferta sobre un modelo de IA propietario se expone a este riesgo [3]. Las empresas cuya actividad depende de API propietarias deben, por tanto, evaluar ese riesgo [5].

El contexto comercial también influye. Según el análisis de la Autoridad de la Competencia, ciertos proveedores pueden incitar a las jóvenes empresas de IA a elegir sus servicios [6]. Una oferta de entrada atractiva no dice nada sobre el coste de un cambio posterior.

El riesgo del lado del open source y de las ofertas mixtas

Elegir un modelo abierto no elimina toda dependencia. Algunos editores combinan componentes de IA propietarios con plataformas de código abierto. Este enfoque facilita el despliegue y garantiza un acompañamiento técnico sólido, pero crea una dependencia del proveedor, tanto en los costes como en la comprensión real del funcionamiento de los modelos [27]. Esta fuente es un medio especializado, no un estudio, pero el mecanismo descrito es claro: la etiqueta «open source» de la plataforma no impide el bloqueo por los componentes que la rodean.

Preguntas que conviene plantear antes de comprometerse

• ¿El modelo puede sustituirse sin reescribir los flujos de trabajo y las integraciones API?
• ¿Qué componentes de la oferta siguen siendo propietarios, incluso en una plataforma abierta?
• ¿Cuánto costaría la salida, tanto en desarrollo como en competencias internas?

Limitar el lock-in consiste sobre todo en conservar la posibilidad de cambiar de modelo. Oupi permite usar ambas familias de modelos, de código abierto y propietarios, en la misma herramienta (ver el producto). El uso no queda, por tanto, ligado a una sola familia.

¿Cómo decidir en la práctica: propietario, open weights o híbrido?

La elección entre propietario y open weights no es ni binaria ni definitiva: depende del nivel de madurez tecnológica de la empresa y de sus necesidades [15][29]. Una decisión tomada hoy puede, por tanto, revisarse cuando cambien los volúmenes, las competencias o las restricciones.

Cuadro de decisión

El híbrido consiste en repartir los usos entre ambas familias, tarea por tarea. Es una opción realista en la oferta: algunos actores ya proponen a la vez modelos propietarios y de código abierto [6].

Una arquitectura sencilla para empezar

Una fuente comercial, gensai.ai, sostiene que un modelo de pesos abiertos bien elegido, un RAG sobre los propios documentos y una memoria de aplicación cubren la inmensa mayoría de las necesidades, por una fracción del coste de un desarrollo propietario [30]. Esta afirmación procede de un actor que vende este tipo de solución: ofrece un punto de partida, no una prueba.

Comparar con los propios casos de uso

Oupi permite usar ambas familias de modelos en la misma herramienta. Un equipo puede así someter un mismo caso de uso a un modelo propietario y a un modelo de pesos abiertos, sin cambiar de interfaz, y comparar los resultados (ver el producto).

Probar con volúmenes reales

Las cifras genéricas no sustituyen a una medición. Antes de decidir, se recomienda:

1. elegir dos o tres casos de uso representativos;
2. ejecutarlos en ambas familias con volúmenes cercanos a los de producción;
3. comparar la calidad de las respuestas, el coste completo (infraestructura y tiempo de explotación incluidos) y el plazo de puesta en marcha;
4. revisar la decisión a intervalos regulares, ya que la elección no es definitiva [15].