La descarga lleva unos minutos. La explotación compromete a la empresa durante meses. Detrás de la promesa de los modelos de IA abiertos —más libertad, menos dependencia, una factura más baja— se esconde una realidad menos espectacular: alguien debe pagar los servidores, supervisar las respuestas e intervenir cuando el servicio falla. El ahorro en el acceso al modelo no garantiza un ahorro en su funcionamiento. De cara a septiembre de 2026, las tendencias ya observadas sugieren que esta distinción debería pesar más en las decisiones de los departamentos de TI.
Abierto no significa gratuito ni sin condiciones
La difusión de familias de modelos como Llama, de Meta, o de modelos publicados por Mistral AI ha cambiado las opciones disponibles. Una empresa puede descargar los pesos, adaptar un modelo y elegir su proveedor de alojamiento, en lugar de consumir exclusivamente una interfaz remota facturada por uso. Este movimiento, ya consolidado en 2023 y 2024, ha convertido estos modelos en una alternativa creíble a los servicios propietarios para numerosos proyectos.
Pero la palabra «abierto» engloba varias realidades. Unos pesos accesibles no dan necesariamente acceso a los datos de entrenamiento, a todos los métodos de creación ni a una libertad de uso sin restricciones. Las licencias varían según las familias y las versiones. Algunas permiten ampliamente los usos comerciales; otras añaden condiciones. Antes de realizar las pruebas comparativas técnicas, hay que leer la licencia, incluidas sus normas de redistribución y sus posibles limitaciones.
Esta comprobación puede parecer secundaria ante una demostración exitosa. Pasa a ser fundamental cuando el modelo se integra en un producto vendido a clientes. El departamento jurídico debe entonces examinar las obligaciones aplicables, las garantías disponibles y las responsabilidades contractuales. La ausencia de cánones no elimina ni este trabajo ni el riesgo que pretende acotar.
El servidor no desaparece con la licencia
Tomemos un caso habitual: un asistente encargado de buscar información en la documentación interna. En la fase de prototipo, unos pocos usuarios hacen preguntas y las respuestas llegan correctamente. En producción, varios equipos se conectan al mismo tiempo, los documentos se alargan y todos esperan una respuesta rápida. El problema ya no consiste únicamente en ejecutar el modelo, sino en mantener la calidad del servicio.
Las necesidades dependen de su tamaño, de la memoria necesaria, de la longitud de los intercambios y del número de solicitudes simultáneas. Reducir la precisión numérica de los pesos mediante cuantización puede aligerar la infraestructura. Agrupar las solicitudes puede mejorar su rendimiento. Sin embargo, estas optimizaciones implican concesiones: hay que comprobar la calidad, vigilar la latencia y dedicar más trabajo de ingeniería.
El factor decisivo suele ser la tasa de utilización de los recursos. Una capacidad reservada pero poco utilizada sigue siendo costosa. En cambio, un servicio estable, muy utilizado y bien optimizado puede hacer atractivo el autoalojamiento. Por tanto, no existe un umbral universal a partir del cual un modelo abierto resulte más barato: todo depende del tráfico, de los compromisos de disponibilidad y del hardware realmente empleado.
La factura oculta suele tener nombre propio
En una comparación superficial, se contrapone el precio de una API al coste mensual de unos cuantos aceleradores. Faltan entonces las personas. Desplegar el motor de inferencia, corregir sus dependencias, supervisar el rendimiento, organizar las copias de seguridad y gestionar los incidentes lleva tiempo. Incluso cuando ya existe un equipo de plataforma, estas tareas consumen una capacidad que no podrá dedicarse a otras actividades.
El mantenimiento del propio modelo añade otra capa. Una nueva versión puede responder mejor, pero modificar el formato de las salidas o fallar en casos hasta entonces controlados. Es necesario repetir las evaluaciones, comprobar las regresiones y prever una vuelta a la versión anterior. La adaptación a los datos del negocio tampoco es una operación definitiva: los productos, los procedimientos y las bases documentales evolucionan.
Una empresa que ya dispone de infraestructura y de un equipo experimentado parte con ventaja. Para una organización pequeña, contratar esos conocimientos puede absorber el ahorro previsto. Entre ambos extremos, el alojamiento gestionado ofrece una solución intermedia: el cliente sigue eligiendo el modelo, mientras que un proveedor se encarga de parte de la explotación. El gasto cambia de partida, no desaparece.
Seguridad: conservar los datos no basta
Alojar un modelo en un entorno propio puede facilitar el control de los flujos de datos. Es un argumento de peso para determinados documentos sensibles. Pero la ubicación es solo una dimensión de la seguridad. También hay que gestionar los permisos de acceso, los secretos técnicos, los registros de conversaciones, las actualizaciones y la procedencia de los componentes descargados.
Un asistente conectado a una base documental puede revelar información a la persona equivocada si los permisos no se propagan correctamente. Un contenido malicioso puede intentar desviar sus instrucciones: es el problema de las inyecciones de prompts. Si el asistente dispone de herramientas capaces de enviar mensajes o modificar expedientes, las consecuencias van más allá de una respuesta inexacta.
Estos riesgos también existen con una API propietaria. La diferencia reside, en particular, en el reparto de tareas y responsabilidades. El autoalojamiento transfiere más obligaciones operativas a la empresa; no constituye una certificación de seguridad. La compartimentación, las pruebas ofensivas, la supervisión y la validación humana deben incluirse en el presupuesto según la criticidad del servicio.
Comparar un resultado útil, no una tarifa anunciada
El coste total de propiedad debe abarcar la preparación, la explotación y la eventual salida. Comparar únicamente el precio por millón de tokens oculta las diferencias de calidad. Un modelo más barato que requiere tres intentos o más correcciones humanas puede resultar más caro por tarea completada. A la inversa, un modelo pequeño y especializado puede bastar allí donde un gran modelo generalista estaría sobredimensionado.
Por tanto, una prueba económica rigurosa debe medir varios elementos sobre las mismas tareas:
- La calidad útil: respuestas aceptables, errores críticos y tiempo de verificación humana.
- El servicio prestado: tiempo de respuesta, disponibilidad y comportamiento durante los picos.
- Los gastos totales: cómputo, almacenamiento, red, integración, seguridad, soporte y trabajo de los equipos.
- La reversibilidad: esfuerzo necesario para cambiar de versión, de proveedor de alojamiento o de proveedor del modelo.
Conviene distinguir varios escenarios de tráfico. El coste medio de un día tranquilo no dice nada sobre la capacidad necesaria durante un lanzamiento comercial. También hay que contabilizar los componentes auxiliares: búsqueda documental, indexación, filtrado y observabilidad. A menudo, el modelo es solo un componente del servicio facturado o utilizado.
La libertad conserva un valor económico
Sin embargo, reducir el debate a una batalla de tarifas sería un error. Poder modificar un modelo, ejecutarlo sin conexión o negociar con varios proveedores de alojamiento tiene valor. Esta autonomía puede justificar un sobrecoste, especialmente cuando depender de un único proveedor representa un riesgo estratégico. Aun así, hay que distinguirla de un ahorro inmediato y comprobar que puede ejercerse en la práctica.
¿Y ahora qué? Para septiembre de 2026 y más allá, una trayectoria plausible es la de carteras híbridas: modelos abiertos para tareas controladas y servicios gestionados para absorber picos o acceder a determinadas capacidades. No es una evolución asegurada. Las empresas mejor preparadas serán las que midan el coste de un resultado fiable, pongan a prueba su capacidad de salida y traten la explotación como un producto duradero, no como el servicio posventa gratuito de una descarga.