Construir o comprar no es una pregunta binaria. Hay cinco rutas: la API de un modelo frontera, un modelo de pesos abiertos en un endpoint gestionado, un modelo de pesos abiertos afinado, un modelo entrenado desde cero, y la opcion que casi todos los equipos olvidan: no resolverlo con un LLM en absoluto. Solo tres lentes deciden entre ellas: el coste al volumen proyectado, el techo de capacidad que exige la tarea y la exposicion regulatoria. Para la mayoria de las organizaciones la respuesta practica es empezar comprando, construir una capa de abstraccion desde el primer dia y volver a plantearse construir solo cuando existan datos reales de uso.
Cinco rutas, no dos
El planteamiento habitual del debate produce malas decisiones porque esconde tres opciones intermedias, que es justo donde esta la mayor parte del valor.
| Ruta | Que significa en la practica | Cuando es la correcta |
|---|---|---|
| API de modelo frontera | Llamadas a un proveedor comercial, sin infraestructura propia | Tarea amplia, volumen moderado, equipo sin profundidad en ML |
| Modelo de pesos abiertos gestionado | Pesos abiertos en el endpoint de un proveedor de infraestructura | Necesidad de control de version y coste predecible |
| Modelo abierto afinado | Entrenamiento adicional con tus datos para una tarea estrecha | Tarea estrecha y repetitiva, muy por encima de diez mil ejemplos etiquetados |
| Modelo desde cero | Entrenamiento completo, equipo de investigacion dedicado | Casi nunca. Solo si el modelo es el producto en si |
| Nada de LLM | Reglas, busqueda, un modelo estadistico clasico | Cuando la tarea es determinista y se puede especificar del todo |
Las tres lentes que deciden
Coste al volumen proyectado. No el volumen de hoy, sino el que planificas para dentro de un ano. El calculo rapido: unidades de trabajo al mes multiplicadas por el coste por unidad en la ruta de comprar, contra el coste fijo de ingenieria e infraestructura de la ruta de construir.
Techo de capacidad. Si la tarea exige razonamiento en varios pasos, un idioma poco frecuente o conocimiento amplio del mundo, un modelo pequeno afinado no llegara por mucho que lo entrenes. Si la tarea es clasificar en siete categorias, un modelo frontera es desperdicio.
Exposicion regulatoria. Cuando los datos tienen que permanecer dentro de una jurisdiccion o de una red cerrada, las rutas de compra se estrechan de inmediato. Esta es la unica lente capaz de eliminar una ruta por completo, y por eso conviene revisarla la primera y no la ultima.
Cuando el afinado compensa de verdad
El afinado es la ruta que la mayoria de los equipos elige demasiado pronto. Compensa cuando se cumplen todas estas condiciones a la vez, no algunas:
1. La tarea es estrecha, repetitiva y esta bien definida, y no cambia cada trimestre.
2. Tienes muchos miles de ejemplos etiquetados de buena calidad, de tu propia produccion y no de un corpus generico.
3. El coste o la latencia de la API se han vuelto de verdad la restriccion que manda, no una preocupacion teorica.
4. Alguien del equipo mantendra el modelo, medira la deriva y reentrenara cuando cambie la distribucion.
Si falta alguna condicion, el afinado anade un coste de mantenimiento permanente sin devolverlo. El patron que funciona es el contrario: quedarte en una API, recoger datos de produccion de forma sistematica y volver a la pregunta despues de unos noventa dias de uso real, cuando tengas numeros en lugar de estimaciones.
La capa de abstraccion: la unica decision que hay que tomar ya
No necesitas elegir ruta el primer dia, pero si necesitas decidir no comprometerte. Una capa fina de abstraccion entre tu codigo y el proveedor del modelo es el seguro mas barato del proyecto.
| Que contiene la capa | Por que importa |
|---|---|
| Una interfaz unica para las llamadas al modelo | Cambiar de proveedor es tocar un archivo, no reescribir |
| Enrutado por tipo de tarea | Permite mandar tareas baratas a un modelo barato sin tocar la logica |
| Registro uniforme de entrada, salida y coste | Sin el no hay datos con los que decidir dentro de tres meses |
| Validacion de la salida | Permite cambiar de modelo sin cambiar el contrato de salida |
Los costes que no estan en la hoja de calculo
Una comparacion de construir contra comprar hecha en una hoja de calculo tiende a pesar el precio de la licencia contra el coste de computo y se deja fuera tres costes que en realidad deciden el resultado: el tiempo hasta el mercado, el coste de oportunidad de un equipo construyendo en lugar de vendiendo, y el mantenimiento a lo largo de anos. Las publicaciones hasta 2026 recogen que las organizaciones que construyeron capacidad de IA a medida sin validarla antes contra una opcion de mercado perdieron un calendario considerable antes de descubrir que la direccion era equivocada.
Desde el otro lado, comprar para siempre crea dependencia de un unico proveedor y le quita a la organizacion la capacidad de mejorar aquello que la distingue. El equilibrio practico es casi siempre hibrido: compra la base y construye la capa de encima donde vive la ventaja competitiva (los datos, la recuperacion, las reglas de negocio y la interfaz), no el modelo.
La secuencia recomendada
1. Define la unidad de trabajo y el criterio de exito antes de elegir tecnologia.
2. Revisa la lente regulatoria. Si elimina rutas, todo lo demas sobra.
3. Haz una prueba de concepto sobre una opcion de mercado aunque estes convencido de que vas a construir. Es barato y crea una linea base.
4. Construye la capa de abstraccion y el registro el primer dia.
5. Vuelve a la decision a los noventa dias con coste por unidad real, tasa de exito y distribucion de tareas.
Preguntas frecuentes
Cual es la diferencia practica entre afinado y recuperacion desde una base de conocimiento?
La recuperacion anade informacion actual al prompt en tiempo de ejecucion; el afinado cambia el comportamiento del modelo en si. Para conocimiento organizativo que cambia, la recuperacion es casi siempre la eleccion correcta. El afinado encaja con cambios de estilo, de formato o con una tarea estrecha, no con inyectar hechos.
Cuantos ejemplos etiquetados exige realmente el afinado?
El orden de magnitud aceptado son muchos miles de ejemplos de calidad para una tarea estrecha. El factor determinante no es la cantidad sino la calidad y la representatividad: mil ejemplos limpios de tu propia produccion valen mas que decenas de miles sinteticos.
No anade complejidad innecesaria una capa de abstraccion?
Una capa fina que solo unifica la llamada, el registro y la validacion cuesta unos pocos dias de desarrollo. El coste de no tenerla aparece el dia en que necesitas cambiar de proveedor, enrutar tareas baratas a un modelo barato o explicar de donde salio una factura.
Cuando tiene sentido entrenar un modelo desde cero?
Casi nunca, salvo que el modelo sea el producto que vendes o que dispongas de datos propios excepcionalmente grandes en un dominio que los modelos generales no cubren. Para la mayoria de las organizaciones el coste supera al beneficio en ordenes de magnitud.
Como se sabe que llego el momento de pasar de comprar a construir?
Cuando se cumplen tres condiciones a la vez: el coste mensual de comprar ha superado el coste anual de ingenieria y mantenimiento de la alternativa, la tarea se ha estabilizado y ha dejado de cambiar, y tienes datos de produccion suficientes para entrenar y medir. Dos de tres no basta.