La tesis en una frase: la elección entre IA open source y API cerrada casi nunca se juega donde la gente cree. No es una batalla de principios entre «libertad» y «lock-in». Es una decisión de ingeniería con dos relojes —coste a escala y sensibilidad del dato— y para la inmensa mayoría de empresas la respuesta correcta el primer día no es la ideológica. Este artículo va de cuándo importa de verdad y cuándo, sinceramente, da igual.
IA open source vs API cerrada en tu empresa: la mayoría plantea la pregunta al revés
La conversación llega casi siempre viciada. Alguien del equipo leyó que Llama, Mistral o DeepSeek son modelos abiertos, que puedes descargarlos y correrlos «en tu casa», y de repente la pregunta deja de ser «¿qué necesita mi negocio?» para convertirse en «¿somos de los que dependen de OpenAI o de los que se autoalojan?». Eso no es una decisión técnica: es identidad. Y las decisiones de identidad se defienden con orgullo, no con datos.
La pregunta útil es mucho más aburrida: para el problema concreto que quieres resolver, ¿qué te da cada opción y qué te cuesta cada una —en dinero, en tiempo de tu equipo y en riesgo—? Cuando la planteas así, la bandera se cae sola y aparece lo que de verdad decide: el volumen al que vas a llamar al modelo y lo delicado que es el dato que le vas a enseñar.
Qué te da de verdad cada opción (sin la parte de bandera)
API cerrada: velocidad y cero mantenimiento
Una API cerrada —OpenAI, Anthropic, Google— es una llamada de red. No provisionas GPUs, no parcheas drivers, no te preocupas de que el modelo se caiga a las tres de la mañana. Pagas por token, empiezas en minutos y el proveedor mejora el modelo por debajo sin que toques nada. A cambio, el dato sale de tu perímetro hacia el suyo (con contrato de por medio), el coste unitario lo fija otro y estás atado a su hoja de ruta y a su política de precios. Compras rapidez y tranquilidad; alquilas el control.
Open source: control y coste a escala, a cambio de fontanería
Un modelo abierto que corres tú —en tu nube o en tu hardware— te da lo contrario: el dato no se mueve de donde tú digas, el coste por millón de tokens a volumen alto puede desplomarse y nadie te deprecia el modelo por sorpresa. El precio de eso es que ahora la infraestructura es tuya: servir el modelo, escalarlo, monitorizarlo, actualizarlo y responder cuando falla es trabajo de tu equipo, para siempre. No es más «barato»: es que cambias factura de proveedor por nómina de ingeniería. Para quien tiene volumen y personal, sale a cuenta; para quien no, es un pozo.
| Eje | API cerrada | Open source (autoalojado) |
|---|---|---|
| Arranque | Minutos | Semanas de setup |
| Dónde vive el dato | En el proveedor (con contrato) | Donde tú decidas |
| Coste | Por token, lo fija el proveedor | Fijo (infra + equipo), barato a escala |
| Mantenimiento | Cero, mejora solo | Tuyo, para siempre |
| Control / lock-in | Bajo control, alto lock-in | Alto control, sin lock-in |
| A quién le renta | Casi todas al empezar | Volumen alto o dato sensible |
Por qué para el 90% de las pymes la respuesta es empezar por API cerrada
No es pereza ni pragmatismo cobarde: es aritmética. La mayoría de proyectos de IA de una pyme mueren no por elegir el modelo equivocado, sino por no llegar nunca a producción. Y todo lo que alargue el camino a producción sube la probabilidad de muerte. Autoalojar un modelo abierto añade, de salida, un proyecto de infraestructura entero antes de haber validado que la idea siquiera funciona. Es optimizar el coste por token de algo que aún no sabes si vas a usar.
- Tu volumen es bajo al principio. El ahorro por token del open source solo compensa a partir de mucho tráfico. Con pocas llamadas al día, la infraestructura propia sale más cara que la API, no más barata.
- No tienes —ni quieres— un equipo de MLOps. Servir un modelo en producción con alta disponibilidad es un oficio. Si no lo tienes en casa, lo que ahorras en tokens lo pagas en contrataciones o en caídas.
- El modelo abierto de hoy no es tu ventaja. Tu diferencial no es qué pesos corres, es tu proceso y tu dato. Empezar por API te deja centrarte en eso en lugar de en drivers de GPU.
- Migrar después es barato; equivocarte al empezar es caro. Si diseñas la aplicación desacoplada del proveedor, cambiar de API cerrada a modelo propio más adelante es un cambio de configuración, no una reescritura.
La jugada sensata es arrancar con una API cerrada, validar que el caso funciona en tu operación y dejar la puerta abierta a bajar a open source el día que los números lo pidan. Si el proyecto es serio y va a crecer, esa arquitectura —desacoplada, con enrutado de modelos y con el dato bajo tu control— es exactamente lo que montamos en infraestructura de IA empresarial: no para casarte con un proveedor, sino para poder cambiarlo sin dolor.
Cuándo sí tiene sentido bajar a open source
La regla no es «nunca open source». Es «open source cuando un disparador real lo justifique», no cuando lo pida el orgullo. Estos son los disparadores que sí mueven la balanza:
- El dato no puede salir de tu perímetro. Sanidad, banca, legal, secreto industrial: si por contrato o por regulación el dato no puede tocar un servidor de terceros, autoalojar deja de ser una preferencia y pasa a ser un requisito. Antes de dar por hecho que es tu caso, ordena qué puede y qué no puede salir con una política de uso de ChatGPT y modelos externos en la empresa; muchas veces el dato sensible es una fracción pequeña y el resto va perfecto por API.
- El volumen es grande y sostenido. Cuando llamas al modelo millones de veces al mes de forma estable, el coste por token de la API empieza a doler y el modelo propio se amortiza. Aquí sí la aritmética favorece a open source —siempre que ya tengas quien lo opere—.
- Necesitas afinar el modelo con tu conocimiento. Si tu caso exige un modelo especializado en tu dominio y tus datos, controlar los pesos ayuda. Aunque ojo: antes de fine-tuning, casi siempre el arreglo real es recuperación sobre tu información, algo que desglosamos en entrenar el agente con tu propia información.
- Latencia u offline. Si necesitas respuesta local, sin red, o con latencia mínima garantizada, el modelo tiene que vivir cerca de donde se usa. Ahí no hay API cerrada que valga.
El coste que nadie te cuenta: mantener no es gratis
El error clásico al comparar es mirar solo el precio por token y concluir que el open source es «gratis». No lo es. Un modelo autoalojado tiene un coste que no aparece en ninguna tarifa: alguien tiene que servirlo con alta disponibilidad, vigilar que no se degrade, actualizarlo cuando salga una versión mejor y estar de guardia cuando se caiga. Ese coste es una nómina, no una línea de factura, y es recurrente. La API cerrada esconde ese coste dentro del precio por token; el open source te lo pasa entero a tu equipo.
Por eso la comparación honesta no es «API cara contra open source barato». Es «coste variable que no gestionas contra coste fijo que sí gestionas». Para volumen bajo o medio, el variable gana casi siempre. Para volumen alto con equipo dedicado, el fijo. La misma lógica de fondo que separa comprar de construir cualquier pieza de IA, que ya defendimos en comprar agentes de IA o construirlos.
Qué hacer el lunes
- Arranca con una API cerrada y valida que el caso funciona en tu operación real, no en una demo. Optimizar coste por token antes de eso es optimizar algo que no existe.
- Desacopla desde el día uno. Diseña la aplicación para que el proveedor de modelo sea configuración, no cableado. Así migrar después cuesta una tarde, no un trimestre.
- Marca tus disparadores. Escribe, negro sobre blanco, qué dato no puede salir y a qué volumen la factura empezaría a doler. El día que se cumpla uno, tienes tu señal para bajar a open source —y solo ese día—.