Modelo open source vs modelo propietario: el criterio real para decidir

La pregunta que en realidad estás haciendo

Esta pregunta casi nunca llega sola. Llega envuelta en otra conversación: “¿por qué seguimos pagando por token si podríamos tener nuestro propio modelo?” o “¿por qué no usamos algo abierto si de todas formas ya pagamos por servidores?”. Detrás de esas preguntas hay una mezcla de dos cosas distintas: una preocupación real de costo y una idea, casi siempre mal formada, de lo que significa “control”.

El error de fondo es tratarla como una discusión técnica de qué modelo razona mejor esta semana. No es eso. Es una decisión de negocio sobre quién controla tus datos, dónde corren, quién es responsable de mantener el modelo actualizado y qué tan cómodo estás dependiendo de un proveedor externo para una pieza central de tu operación.

Se vuelve urgente en momentos muy concretos: cuando legal o cumplimiento pregunta dónde viajan los datos que entran al modelo, cuando el gasto mensual en API empieza a asustar al área de finanzas, o cuando alguien del equipo técnico propone “montar nuestro propio modelo” sin que nadie haya calculado qué implica sostenerlo un año después de instalado.

Qué es cada uno, sin la etiqueta de marketing

Un modelo propietario es el que usas a través de la API de un proveedor (OpenAI, Anthropic, Google, entre otros): no ves ni tocas los pesos del modelo, el proveedor lo entrena, lo actualiza, lo protege y lo sirve. Pagas por uso y a cambio te llevas calidad de punta, soporte enterprise y una hoja de ruta de mejoras que no dependen de tu equipo.

Un modelo open source es el que tiene sus pesos disponibles públicamente: se puede descargar y correr en infraestructura propia, o usar a través de un proveedor que lo sirve como servicio (lo cual, en costo y control, termina pareciéndose más a un modelo propietario de lo que la etiqueta “open source” sugiere). La diferencia real de fondo solo aparece cuando de verdad lo auto-hospedas.

Las diferencias que importan (no las specs del paper)

Estas son las diferencias que de verdad cambian el resultado del negocio, no las que se discuten en un benchmark:

• Control de los datos. Con propietario, los datos salen vía API hacia el servidor del proveedor, aun con acuerdos de no entrenamiento. Con open source auto-hospedado, la información nunca sale de tu infraestructura.
• Costo real. Propietario cobra por token: previsible y bajo con volumen medio o bajo. Open source mueve el costo a GPUs, DevOps y mantenimiento continuo, no lo elimina.
• Calidad y ritmo de mejora. Los modelos propietarios de punta suelen ir un paso adelante en razonamiento y soporte multimodal. La brecha con los mejores open source se cierra, pero rara vez desaparece del todo.
• Soporte y continuidad. Propietario incluye soporte enterprise y actualizaciones automáticas. Open source depende del criterio y la disponibilidad de tu propio equipo, o de un tercero que lo sirva.
• Talento necesario. Usar una API no requiere equipo de infraestructura de modelos. Auto-hospedar exige gente que sepa optimizar inferencia, parchear vulnerabilidades y mantener el modelo al día.
• Cumplimiento regulatorio. Sectores con regulación estricta (salud, banca, gobierno) a veces exigen que el modelo corra dentro del perímetro propio, algo que solo el open source auto-hospedado garantiza sin depender de una cláusula contractual.
• Velocidad de arranque. Propietario se integra en días. Montar infraestructura open source seria toma semanas o meses si el equipo no tiene experiencia previa.
• Riesgo de dependencia. Propietario ata parte de la hoja de ruta del negocio a las decisiones de precio y política de un proveedor externo. Open source cambia ese riesgo por el de mantener el conocimiento técnico interno siempre actualizado.

Cuándo conviene cada uno

No hay una respuesta universal. Hay señales concretas que, cuando aparecen juntas, inclinan la decisión con bastante claridad.

Señales de que el modelo propietario es la opción correcta

• El equipo no tiene, ni va a tener pronto, gente dedicada a mantener infraestructura de modelos.
• El volumen de uso todavía no justifica una inversión fija en GPUs propias.
• La velocidad de salida al mercado importa más que el control absoluto del stack.
• El sector no tiene una exigencia regulatoria que obligue a procesar los datos dentro de un perímetro propio.
• Se necesita lo último en razonamiento o multimodalidad y no hay tiempo de esperar a que el open source alcance ese nivel.

Señales de que el open source auto-hospedado vale la inversión

• Hay una obligación regulatoria real, no percibida, de que los datos nunca salgan de la infraestructura propia.
• El volumen de uso es tan alto y constante que el costo por token de la API supera, con margen claro, el costo de operar GPUs propias.
• Ya existe, o se va a contratar, un equipo con criterio técnico para mantener el modelo actualizado, no solo para instalarlo una vez.
• El negocio necesita ajustar el modelo con datos propios de forma profunda y sostenida, más allá de lo que resuelve un buen prompt o un RAG bien armado.
• El control absoluto (poder auditar el modelo y decidir cuándo y cómo se actualiza) es un requisito de negocio, no una preferencia técnica.

Errores comunes al tomar esta decisión

Los mismos errores se repiten en empresas de tamaños distintos:

• Creer que “open source” significa “gratis”: el costo no desaparece, se muda a infraestructura, talento especializado y tiempo de mantenimiento.
• Auto-hospedar un modelo sin nadie responsable de actualizarlo. En pocos meses queda técnicamente atrás y la empresa terminó pagando la inversión inicial sin capturar el beneficio de estar al día.
• Elegir propietario solo por miedo a “depender de un tercero”, sin medir si ese riesgo es real para el negocio o solo una incomodidad teórica que nunca se materializa.
• Mezclar la discusión técnica con la de negocio: la pregunta no es qué modelo puntúa más alto en un benchmark, es qué opción resuelve el proceso con el costo y el control que la operación necesita.
• Empezar por infraestructura open source “porque es lo serio” en una empresa mediana que no tiene ni el volumen ni el equipo para sostenerla en el tiempo.

Cómo saber si la elección fue correcta

La elección no se valida el día que se firma el contrato o se enciende el servidor. Se valida meses después, con estos criterios:

• Costo total por unidad de trabajo procesada, no solo el precio por token o por hora de GPU.
• Tiempo que el equipo dedica a mantener el modelo actualizado frente al tiempo dedicado al negocio.
• Cumplimiento real de los requisitos regulatorios o de control de datos que motivaron la decisión en primer lugar.
• Estabilidad del servicio: incidentes, caídas y tiempo de resolución cuando algo falla.
• Si la opción elegida sigue siendo defendible seis meses después, cuando el mercado de modelos ya cambió otra vez.

Si nadie en la empresa puede responder estas cinco preguntas con datos, no se tomó una decisión: se hizo una apuesta con presupuesto ajeno.

Mi criterio

Antes de decidir, escribe en una sola frase cuál de esas tres razones aplica a tu caso. Si no puedes escribirla, todavía no es momento de auto-hospedar nada: es momento de empezar con la API y revisar la decisión cuando el volumen o la regulación cambien de verdad.