Quien lleva un modelo de lenguaje (LLM) a la empresa llega pronto a una encrucijada: usar los servicios en la nube de los grandes proveedores, como OpenAI, Claude de Anthropic o Gemini de Google, o descargar un modelo de pesos abiertos y ejecutarlo en sus propios servidores.
No hay una respuesta válida para todos, y desconfiamos de quien la ofrece. Lo que sí hay son criterios claros para decidir caso por caso, y a menudo la solución más sólida combina los dos caminos. En este artículo los repasamos: confidencialidad, calidad, costes, tiempos de respuesta, mantenimiento y dependencia del proveedor.
Los dos caminos
Modelos en la nube. Se usan a través de una API, una interfaz a la que tus aplicaciones llaman por internet, y se pagan por consumo. El hardware, las actualizaciones y la capacidad corren a cargo del proveedor. Se contratan directamente con los fabricantes y, para muchos modelos, también a través de las grandes plataformas cloud como AWS, Azure y Google Cloud.
Modelos de pesos abiertos (open-weight). Los pesos, es decir, los parámetros que forman el modelo entrenado, se pueden descargar y ejecutar donde se quiera. Algunos ejemplos son Llama de Meta y los muchos modelos publicados en Hugging Face; en agosto de 2025 también OpenAI publicó modelos de pesos abiertos, gpt-oss, con licencia Apache 2.0. Pero “pesos abiertos” no siempre significa open source: la licencia de Llama, por ejemplo, fija sus propias condiciones y hay que leerla antes de un uso comercial. Para probarlos en un ordenador o en un servidor de pruebas basta una herramienta como Ollama; en producción se usan motores pensados para atender a muchos usuarios a la vez, como vLLM.
Confidencialidad y cumplimiento normativo
A menudo es el criterio que decide. Con un modelo en casa, los datos no salen de tu infraestructura: es la opción natural para datos sanitarios, jurídicos o secretos industriales, o cuando un contrato o una política interna prohíbe enviarlos a terceros.
Pero la nube no queda descartada por principio. Con un acuerdo de encargo del tratamiento (DPA, artículo 28 del RGPD), el compromiso del proveedor de no usar los datos para entrenar y el procesamiento en regiones europeas, muchos casos de uso se pueden gestionar dentro de las reglas. Dos ejemplos: Anthropic declara que no entrena sus modelos con los datos de sus productos comerciales, API incluida, y desde febrero de 2025 OpenAI ofrece a los clientes de API que cumplen los requisitos la residencia de datos en Europa. Aun así, las condiciones hay que leerlas y comprobarlas caso por caso, junto con quien se ocupa de la privacidad en la empresa.
Calidad, tiempos de respuesta y mantenimiento
- Calidad en tu tarea: los modelos más grandes suelen rendir mejor en tareas complejas como razonamientos largos, código o documentos extensos; para tareas acotadas (clasificar, extraer campos, resumir) puede bastar un modelo abierto de tamaño medio. Las clasificaciones públicas cambian cada pocos meses: la prueba que cuenta es la que se hace con tus datos y tus preguntas.
- Tiempos de respuesta (latencia): en la nube dependen de la red y de la carga del servicio; en casa, del hardware. Un modelo pequeño en un servidor cercano puede ser muy rápido; uno grande en un hardware insuficiente, no.
- Mantenimiento: en la nube, las actualizaciones y la capacidad son cosa del proveedor, pero los modelos se retiran con un preaviso y hay que volver a probar el sustituto. En casa todo depende de ti: actualizaciones, seguridad, monitorización, gestión de las GPU y de los picos de carga.
Costes y dependencia del proveedor
La estructura de costes es la opuesta. La nube se paga por consumo, según los tokens (palabras o trozos de palabra) procesados: sin inversión inicial y con un gasto proporcional al uso, cómodo para empezar y para volúmenes bajos o variables. En casa, el coste es sobre todo fijo: servidores con GPU, comprados o alquilados, energía y las personas que los gestionan. Compensa cuando los volúmenes son altos y constantes, o cuando la confidencialidad lo exige de todos modos. No damos cifras: dependen del modelo, de los volúmenes y del hardware, y cambian a menudo. Una comparación seria se hace con los números medidos en un piloto.
Luego está la dependencia del proveedor (vendor lock-in): una aplicación construida en torno a las funciones específicas de un único servicio se vuelve cara de trasladar. Con los modelos abiertos el riesgo se reduce, pero no desaparece.
Los servicios gestionados en la nube siguen siendo la opción más sencilla cuando hacen exactamente lo que se necesita. Para Artika, la plataforma de streaming teatral que diseñamos y desarrollamos en AWS, en la región de Irlanda, usamos servicios de IA gestionados: Amazon Transcribe reconoce el idioma hablado y escribe los subtítulos, y Amazon Rekognition revisa los vídeos antes de su publicación, también con un modelo Custom Labels entrenado a medida. No son modelos de lenguaje, pero la lógica de la elección es la misma: ninguna infraestructura de IA que gestionar y los datos en una región europea.
El enfoque híbrido
En la práctica, el camino que recomendamos valorar primero usa las dos opciones, cada una donde más rinde:
- los datos sensibles se quedan en un modelo ejecutado en casa;
- el resto va al modelo en la nube más adecuado por calidad o coste;
- una capa de abstracción, es decir, un gateway interno o una librería como LangChain, ofrece a las aplicaciones una única interfaz y decide adónde enviar cada petición;
- las reglas de enrutamiento son explícitas (por tipo de dato, departamento, coste) y cada llamada queda registrada.
Esta capa también facilita cambiar de modelo o de proveedor. Muchas herramientas, Ollama incluida, ofrecen una interfaz compatible con la de OpenAI: a menudo basta con cambiar la dirección y el nombre del modelo en la configuración, aunque la compatibilidad nunca es total y siempre hay que probarla.
Si estás decidiendo dónde ejecutar tus modelos, podemos ayudarte a comparar las opciones con tus datos y tus volúmenes, y a construir la capa que te deja libre para cambiar. Escríbenos y lo hablamos.
