El modelo se descarga gratis. La factura empieza después. Para una empresa que quiere resumir sus contratos, ayudar a sus desarrolladores o consultar su documentación, los modelos de IA de pesos abiertos ofrecen una promesa atractiva: recuperar el control. Pero sustituir una API por un modelo alojado en una infraestructura propia no elimina las dependencias. Las traslada a los chips, el software y los equipos. Con la vista puesta en septiembre de 2026, esta cuestión merece algo más que un duelo entre una apertura virtuosa y una nube cautiva. Los hechos históricos presentados aquí sirven de base; las posibles evoluciones siguen siendo prospectivas.
Pesos abiertos, no necesariamente software libre
Primera trampa: el vocabulario. Un modelo de pesos abiertos permite obtener los parámetros aprendidos durante su entrenamiento y, según su licencia, ejecutarlo o adaptarlo. Eso no significa que sus datos de entrenamiento, su código y su proceso de creación sean íntegramente accesibles. Ni que todos los usos estén autorizados.
Los lanzamientos de 2024 consolidaron esta diversidad. Meta publicó Llama 3 y después Llama 3.1 bajo una licencia comunitaria con condiciones específicas. Mistral AI distribuyó algunos modelos, entre ellos Mixtral 8x22B, bajo la licencia Apache 2.0. Por tanto, dos descargas pueden conllevar obligaciones muy diferentes, aunque ambos modelos se presenten como «abiertos».
La comprobación debe centrarse en la versión exacta. Uso comercial, redistribución, adaptación, atribución, posibles restricciones sectoriales: el departamento jurídico debe leer la licencia, no solo la ficha comercial. Además, el acceso a los pesos no garantiza ni la ausencia de contenidos protegidos en el entrenamiento ni una indemnización en caso de litigio. En las API, las protecciones contractuales también varían según el proveedor y la oferta.
Alojamiento: la GPU es solo el principio
Imaginemos una empresa de distribución que despliega un asistente para sus equipos comerciales. Con una API, compra principalmente solicitudes o tokens, esos fragmentos de texto que procesa el modelo. Con un despliegue autónomo, debe dimensionar una capacidad: memoria de los aceleradores, rendimiento, tiempo de respuesta y número de usuarios simultáneos. El modelo que funciona durante una demostración puede saturarse al abrir las oficinas.
Un modelo pequeño y especializado puede funcionar sobre una infraestructura relativamente modesta. Un modelo grande, o un contexto muy largo, cambia la ecuación. Reducir la precisión de los pesos mediante cuantización ahorra memoria, pero sus efectos sobre la calidad deben medirse. A ello se suman el almacenamiento, la red, la supervisión, las copias de seguridad y la redundancia. Alquilar GPU evita la compra inicial, no los gastos recurrentes.
Por tanto, la comparación pertinente no es «gratis frente a pago», sino coste total por tarea realizada correctamente. Una respuesta barata que un empleado debe corregir puede costar más que una respuesta con un precio superior. A la inversa, un modelo compacto y bien adaptado puede resultar ventajoso con un volumen elevado, regular y previsible.
Lo que un presupuesto suele pasar por alto
- La capacidad no utilizada entre dos picos de tráfico y la reserva necesaria para absorber los máximos de demanda.
- El tiempo que los ingenieros dedican al despliegue, las evaluaciones y los incidentes.
- Los procesos auxiliares: búsqueda documental, filtrado, registro de actividad y control humano.
- El coste de una interrupción del servicio o de un deterioro silencioso de las respuestas.
La API permite al proveedor compartir una parte de estas cargas entre sus clientes. A cambio, expone a la empresa a sus tarifas, cuotas y decisiones sobre su catálogo. El autoalojamiento ofrece más mecanismos de control, pero obliga a saber utilizarlos.
Seguridad: conservar los datos no basta
El argumento más sólido a favor de un alojamiento bajo control suele estar relacionado con los datos. Los contratos sensibles o los expedientes internos pueden permanecer en un entorno elegido. Aun así, hay que comprobar por dónde pasan los registros, las copias de seguridad, las herramientas de supervisión y los posibles datos de telemetría. Un modelo instalado en una nube externa no es automáticamente sinónimo de soberanía.
Una API profesional, por su parte, puede ofrecer compromisos sobre la conservación, la ubicación o la no utilización de los datos para el entrenamiento. Estas disposiciones deben verificarse contractualmente, sin extrapolarlas a partir de una oferta para el público general. Por tanto, la elección enfrenta dos arquitecturas y dos cadenas de responsabilidad, no necesariamente confidencialidad y exposición.
En ambos casos, persisten los riesgos propios de los asistentes. Un documento malicioso puede contener una instrucción destinada a desviar el comportamiento del modelo: es la inyección de prompts. Si el asistente puede enviar correos electrónicos o modificar una base de datos, las consecuencias van más allá de una mala respuesta. Es necesario limitar sus permisos, aislar las herramientas y exigir una validación humana para las acciones sensibles.
El alojamiento autónomo añade una cadena de software que hay que proteger: procedencia de los archivos, bibliotecas, contenedores y actualizaciones. Algunos repositorios ofrecen código para ejecutar junto con el modelo; aceptarlo sin una auditoría crea un riesgo distinto del de los propios pesos. La apertura facilita la inspección, no la sustituye.
Mantenimiento: tener una versión también implica mantenerla
Un equipo puede conservar durante mucho tiempo una versión descargada, una ventaja real frente a una API que puede retirar un modelo antiguo. Pero esa estabilidad tiene una contrapartida. Los motores de inferencia evolucionan, los controladores cambian y aparecen vulnerabilidades. Incluso sin volver a entrenar el modelo, hay que mantener su entorno y comprobar su rendimiento.
Cambiar de modelo tampoco es un simple intercambio de archivos. El formato de los mensajes, el comportamiento de las herramientas, la longitud del contexto y la calidad en francés pueden variar. Una instrucción eficaz en una versión puede perder fiabilidad en la siguiente. Cada migración exige pruebas con casos reales y criterios de negocio, no solo una clasificación generalista.
Con una API, el proveedor se encarga de gran parte de la operación. No obstante, la empresa sigue siendo responsable de su aplicación: permisos, calidad de las fuentes documentales, control de las respuestas y seguimiento de los errores. Externalizar la inferencia no equivale a externalizar toda la fiabilidad.
¿Menos dependencia u otras dependencias?
Los pesos abiertos ofrecen una posibilidad importante: cambiar de proveedor de alojamiento sin abandonar necesariamente el modelo. Esta portabilidad sigue estando condicionada por la licencia, el hardware disponible y la compatibilidad del software. Una optimización muy vinculada a un acelerador puede recrear una dependencia técnica. La dependencia del proveedor se convierte a veces en una dependencia de las competencias internas.
Para elegir, conviene probar un ámbito de uso concreto durante varias semanas. Medir la calidad real, los plazos, el coste total y el esfuerzo operativo revela más que una comparación de los precios anunciados. Una configuración híbrida también puede ser pertinente: un modelo bajo control propio para ciertos datos y una API para necesidades puntuales, siempre que existan reglas explícitas de enrutamiento.
¿Y ahora qué? Con la vista puesta en septiembre de 2026, parece plausible que la mejora de los modelos pequeños y de las herramientas de despliegue amplíe los usos del autoalojamiento. No es la promesa de una autonomía gratuita. Las organizaciones mejor posicionadas serán aquellas capaces de documentar sus dependencias, probar una solución alternativa y financiar la operación diaria. El verdadero poder de negociación no consiste solo en disponer de los pesos: consiste en poder cambiar de solución sin paralizar la actividad.
