«Monta una SaaS» antes significaba que tenías algo duradero. En 2026, un agente de código con IA puede reconstruir el conjunto de funciones principales de tu app, restilizar tu landing page y desmontar el texto de tus anuncios en una sola tarde —mira también nuestro artículo sobre hasta dónde han llegado los agentes de código. La interfaz, el flujo de onboarding, el posicionamiento: todo eso ahora se copia barato. Lo que no se copia barato es un modelo que has afinado tú mismo, con tus propios datos, que calladamente supera a un modelo genérico de frontera justo en lo único que tu negocio realmente necesita.
Ese es el cambio que merece atención: monetizar modelos de lenguaje pequeños (SLM) afinados —entre 0,5 y 12 mil millones de parámetros, más o menos— de la misma forma en que licenciarías un producto SaaS, en lugar de (o además de) lanzar otro wrapper alrededor de la API de otro.
Por qué se erosiona el foso del SaaS
El foso clásico del SaaS nunca fue realmente el código: era el tiempo que le costaba a un competidor escribirlo. Ese tiempo se ha desplomado. Los agentes de código pueden montar un clon funcional de la mayoría de los productos CRUD-con-panel en horas, no en meses, y son igual de buenos copiando la superficie de marketing: los ganchos publicitarios, la estructura de la landing page, la psicología de la página de precios. Nada de eso requiere robar tu código fuente; basta con mirar tu producto y pedirle a un agente que reconstruya su forma.
Lo que queda como foso real es todo lo que un competidor no puede simplemente pedirle a un agente que reproduzca: datos propios, distribución ya ganada, confianza construida con el tiempo y, cada vez más, un modelo que has entrenado tú mismo y al que un clon genérico sencillamente no tiene acceso.
Qué ha cambiado de verdad: el fine-tuning se volvió fácil
Afinar un modelo antes requería un equipo de investigación en ML. Lo que ha cambiado en 2026 es que los modelos de frontera se han vuelto realmente buenos guiando a un solo operador a través de toda la pipeline de principio a fin, no solo respondiendo preguntas sobre ella, sino haciendo el trabajo mecánico. Modelos como DeepSeek-V4-Pro (con disponibilidad general desde agosto de 2026), GLM-5.3, Kimi K3 (el lanzamiento de Moonshot AI, uno de los modelos abiertos más grandes disponibles) y GPT-6 Astra (el buque insignia actual de OpenAI) pueden encargarse con soltura de la preparación del dataset, la configuración del adaptador LoRA/QLoRA, la depuración de las ejecuciones de entrenamiento y la exportación del resultado a GGUF (para inferencia local al estilo de llama.cpp y Ollama) o MLX (para Apple Silicon): los formatos de despliegue que hacen que un modelo afinado sea realmente ejecutable fuera de un cuaderno de investigación.
Ese es el verdadero desbloqueo. No es que los modelos pequeños se hayan vuelto de repente más listos, sino que las herramientas para especializarlos han pasado de ser un proyecto de investigación de varios meses a algo que una persona técnicamente competente puede ejecutar en días, iterando con un modelo de frontera como compañero de construcción en lugar de hacer cada paso a mano.
El foso nunca fue «tenemos un modelo de lenguaje». Cualquier competidor tiene acceso a las mismas APIs de frontera que tú. El foso es un modelo entrenado con datos que tu competidor no tiene, evaluado contra un listón que no ha superado, empaquetado como algo que controlas de principio a fin.
Por qué un SLM afinado puede superar a un modelo SoTA en una tarea concreta
Un modelo de frontera está construido para ser bueno en casi todo, lo que significa que su capacidad se reparte entre una gama enorme de tareas que nunca verá viniendo de ti. Un modelo pequeño afinado con unos cientos o unos pocos miles de ejemplos bien seleccionados y específicos de una tarea no carga con ese sobrecoste: solo tiene que ser bueno en el único trabajo para el que lo entrenaste, y puede lograrlo con una fracción de los parámetros.
La economía lo respalda. Incluso los actuales modelos abiertos de clase frontera —DeepSeek-V4-Pro, GLM-5.3, Kimi K3— ya funcionan a aproximadamente entre una quinta y una treintava parte del coste por token de las APIs de frontera cerradas, manteniéndose competitivos en los benchmarks generales. Un modelo pequeño, afinado para una tarea concreta y alojado por ti mismo, va considerablemente más allá: se reportan habitualmente reducciones de coste por encima del 90 % y mejoras de latencia de varias veces frente a una API de frontera de propósito general en casos de uso bien acotados, aunque las cifras exactas dependen mucho de la tarea, el modelo base y el rigor de la evaluación. Es tu modelo, alojado en tu propia infraestructura: sin límites de velocidad compartidos, sin cambios de precio sorpresa, sin enviar por defecto los datos de tus clientes a la API de un tercero.
¿No sabes qué flujos de trabajo merecen un fine-tuning?
Lo difícil no es lanzar un job de LoRA: es elegir la tarea correcta, construir un conjunto de evaluación honesto y saber cuándo un fine-tuning realmente compensa mantenerlo. Ese es exactamente el trabajo de definición que hacemos con nuestros clientes antes de que arranque cualquier entrenamiento.
Reservar una consultaLa hoja de ruta: de la idea al modelo licenciable
Paso 1 — Elige una tarea concreta y repetible. Clasificación, extracción estructurada, un estilo de generación específico, un chat de dominio bien acotado: no un asistente abierto. El fine-tuning premia una tarea cuyos límites puedas definir de verdad.
Paso 2 — Cura un dataset de verdad. Unos cientos o unos pocos miles de ejemplos de alta calidad y verificados superan sistemáticamente a un scrape descuidado de 100.000 filas. Usa un modelo de frontera para ayudar a generar y limpiar ejemplos candidatos, y luego haz que una persona revise una muestra representativa antes de que nada entre en el entrenamiento.
Paso 3 — Afina con LoRA o QLoRA sobre un modelo base pequeño. Mantenerte en el rango de 0,5 a 12 mil millones de parámetros hace que una ejecución de entrenamiento sea lo bastante barata como para iterar en una sola GPU o en una instancia alquilada de tamaño moderado, en lugar de un trabajo a escala de centro de datos.
Paso 4 — Evalúa rigurosamente frente a la referencia SoTA. Este es el paso que la gente se salta, y es el que realmente te dice si tienes algo que vender. Construye un conjunto de prueba reservado que el modelo nunca haya visto, ejecuta el modelo de frontera y tu fine-tune en paralelo, y sé honesto sobre dónde gana cada uno.
Paso 5 — Exporta para un despliegue real. GGUF para inferencia local compatible con llama.cpp y Ollama, MLX para Apple Silicon: los formatos que permiten a un cliente ejecutar realmente el modelo en su propio hardware en lugar de confiar en un endpoint alojado.
Paso 6 — Licéncialo como software. Por puesto, por uso, o una tarifa fija por una instalación privada on-premise: los mismos patrones de empaquetado que ya usa el SaaS. El producto, simplemente, son pesos de modelo y un arnés de evaluación en lugar de una app web.
Dónde esto no funciona
Esto no es un sustituto general del SaaS, y tratarlo como tal es como fracasan estos proyectos. Algunas salvedades honestas:
Los casos de uso amplios y abiertos siguen favoreciendo a los modelos de frontera. El fine-tuning brilla en tareas concretas y repetibles con una respuesta correcta clara, no en el razonamiento general ni en la conversación abierta, donde la amplitud es precisamente el objetivo.
Las licencias del modelo base importan. Incluso los modelos abiertos con licencias permisivas pueden llevar condiciones sobre el uso comercial. Revisa la licencia antes de construir un negocio sobre los pesos de otro.
Los modelos envejecen. A medida que mejoran los modelos base, una ventaja afinada puede estrecharse o desaparecer. Presupuesta un reajuste periódico como parte del producto, no como una construcción única que nunca vuelves a tocar.
El cuello de botella es la calidad del dato, no el cómputo. Un fine-tune es tan bueno como lo que le des de comer. Los equipos que se saltan el paso 2 de arriba y confían en que el proceso de fine-tuning arregle un dataset descuidado quedan sistemáticamente decepcionados con el resultado.
Una tendencia silenciosa y poco discutida
Es un patrón que aparece más en círculos técnicos de lo que se habla de él públicamente: operadores que durante el último año han afinado calladamente decenas de modelos concretos y específicos de una tarea, con sorprendentemente poco escrito al respecto en relación con lo efectivos que suelen ser los resultados. Parte de esto es la obsesión del sector con los lanzamientos de modelos de frontera, que desplaza la cobertura del trabajo menos glamuroso de especializar un modelo pequeño para un problema de negocio real. Parte de esto es que un fine-tune que funciona es una ventaja competitiva genuina, y quien lo ha construido tiene poco incentivo para explicar exactamente cómo.
Aun así, el instinto detrás de esto se sostiene: para una tarea concreta, de alto volumen y bien acotada, un SLM afinado a medida supera cada vez más a un wrapper SaaS genérico alrededor de una API de frontera: más barato de operar, más rápido respondiendo, y bajo tu propio control en lugar de alquilado de los límites de velocidad de otro. No es un sustituto de todos los productos SaaS, y no es gratis: el trabajo de dataset y la disciplina de evaluación son costes reales. Pero como categoría que merece la pena explorar en serio en 2026, se ha ganado la atención. Si estás sopesando esto frente al coste de una construcción más convencional, nuestro análisis de cuánto cuesta realmente implantar IA es una buena siguiente lectura, y nuestra visión de la ola de herramientas de IA de código abierto cubre el cambio de herramientas adyacente que hace que todo esto sea más barato de construir.