DigitalTransformation on Carles Abarca

Tu startup de IA no es una empresa: es un feature de OpenAI o de Anthropic

Tue, 05 May 2026 00:00:00 +0000

Y estás construyendo en una grieta que se puede cerrar contigo dentro.

En marzo de 2025, un desarrollador en solitario celebraba en Twitter haber llegado a $12,000 de MRR con su herramienta de resumen de PDFs. Usaba la API de GPT-4, le añadía una interfaz bonita, cobraba $19 al mes, y la vida era buena. Seis semanas después, Google lanzó Gemini 2.5 con capacidad nativa de procesar documentos de 1,500 páginas. Gratis. El MRR del solopreneur no bajó gradualmente — se desplomó como un edificio en un terremoto.

No fue un caso aislado. Fue geología.

Las placas tectónicas de la IA
#

Piensa en OpenAI, Google, Anthropic y Meta como placas tectónicas. Son masas continentales de capital, talento, datos y capacidad de cómputo que se mueven lentamente — pero cuando se mueven, reconfiguran el paisaje entero.

Entre esas placas hay grietas. Huecos temporales donde el terreno parece estable. Donde un emprendedor ágil puede montar su tienda, plantar una bandera, y declarar que ha encontrado un mercado. Y durante un tiempo, tiene razón. La grieta es real, el espacio existe, los clientes pagan.

El problema es que las grietas entre placas tectónicas no son terreno firme. Son zonas de fricción. Y cuando las placas se mueven — porque siempre se mueven — la grieta se cierra.

Con el emprendedor dentro.

El cementerio de features que se creyeron empresas
#

La lista es larga y sigue creciendo:

Code Interpreter mató a las startups de ejecución de código. Docenas de empresas construyeron productos para ejecutar código dentro de conversaciones con LLMs. Luego OpenAI lo añadió como feature nativo de ChatGPT. No hubo transición. Hubo extinción.

GPT-4 Vision borró del mapa a las startups de descripción de imágenes. Empresas que cobraban por analizar imágenes con IA desaparecieron el día que la visión se convirtió en una capacidad estándar del modelo base.

Las herramientas de “chat con tus documentos” se volvieron commodity. Lo que en 2023 era un producto diferenciado, en 2025 es un feature gratuito de Google Drive, Microsoft 365 y Notion. Todas a la vez.

Los wrappers de generación de imágenes que añadían prompts mejorados sobre DALL-E o Midjourney vieron cómo cada nueva versión del modelo hacía innecesaria su capa de “mejora.”

El patrón es siempre el mismo: un emprendedor identifica una limitación del modelo fundacional, construye una solución alrededor de esa limitación, y celebra haber encontrado product-market fit. Pero lo que encontró no fue un mercado — fue un bug temporal en la oferta de un gigante.

La trampa del solopreneur
#

Nunca ha sido más fácil construir un producto de IA. Un desarrollador solo, con Claude Code o Cursor, puede tener un MVP funcional en un fin de semana. Y eso se siente como un superpoder.

Pero esa facilidad es precisamente la trampa.

Si tú puedes construir tu producto en un fin de semana, ¿qué te hace pensar que OpenAI no puede añadir esa funcionalidad en su próximo release? No estás compitiendo con otros solopreneurs — estás compitiendo con organizaciones que tienen miles de ingenieros, miles de millones en financiación, y acceso al modelo fundacional sobre el que está construida tu “empresa.”

Es como montar una tienda de souvenirs dentro de un volcán dormido. El alquiler es barato, la vista es espectacular, y el tráfico de turistas es increíble. Hasta que el volcán deja de estar dormido.

El solopreneur de IA no está democratizando la tecnología. Está ocupando un espacio de mercado inestable — instalado en una grieta que el movimiento tectónico de los hyperscalers puede cerrar en cualquier momento. Y lo más cruel es que cuanto mejor le vaya, más visible se hace para las placas que se lo van a tragar. El éxito es la señal de que la grieta vale la pena cerrar.

La diferencia entre un feature y una empresa
#

No todo lo que se construye sobre un LLM es un feature condenado. Hay startups de IA que sí son empresas reales. La diferencia está en lo que tienen además del modelo:

Datos propietarios que el modelo no tiene. Si tu ventaja competitiva es que entrenas o haces fine-tuning con datos que nadie más posee — datos industriales específicos, históricos regulatorios, corpus especializados — las placas pueden moverse y tu terreno se mantiene. No estás en la grieta; estás en tu propia isla.

Efectos de red que se refuerzan con el uso. Cada nuevo usuario hace el producto mejor para los demás. Un marketplace, una comunidad, un sistema de colaboración. Eso no lo replica un modelo fundacional añadiendo un feature.

Integración profunda en flujos de trabajo existentes. Si tu producto está embebido en el proceso diario de una empresa — conectado a su ERP, su CRM, sus sistemas legacy — el coste de cambio es real. No es una app que se desinstala cuando el modelo base mejora.

Expertise de dominio que el modelo no puede replicar. Hay sectores donde la regulación, la especificidad del proceso, o la complejidad del contexto requieren un conocimiento que va mucho más allá de lo que un prompt puede resolver. Salud, legal, finanzas reguladas, manufactura industrial. Ahí el modelo es un ingrediente, no el plato.

Si tu startup no tiene al menos uno de estos cuatro elementos, no tienes una empresa. Tienes un feature con facturación temporal.

El test de la grieta
#

Antes de celebrar tu próximo milestone de MRR, hazte estas preguntas:

1. ¿Podrían añadirlo en un release? Si la funcionalidad core de tu producto puede ser replicada por OpenAI, Google o Anthropic añadiendo un feature a su siguiente versión, estás en la grieta. No importa que hoy no lo hayan hecho. Importa que puedan.

2. ¿Tu ventaja sobrevive a una mejora del modelo base? Cada vez que sale un modelo más capaz, ¿tu producto se vuelve más valioso o menos necesario? Si la respuesta es “menos necesario,” estás apostando contra la ley de la gravedad.

3. ¿Puedes explicar tu moat sin mencionar al modelo? Si tu pitch empieza con “Usamos GPT-4 para…” ya perdiste. Tu moat tiene que existir independientemente del modelo que uses debajo. Si cambias de OpenAI a Anthropic a Gemini y tu propuesta de valor desaparece, nunca fue tu propuesta de valor.

4. ¿Estás vendiendo una capacidad o un resultado? Las capacidades se comoditizan. Siempre. “Resumir documentos” es una capacidad. “Reducir el tiempo de compliance regulatorio de tu banco de 6 semanas a 3 días” es un resultado. Los resultados requieren contexto, integración, y expertise que no se comoditizan fácilmente.

Qué hacer si estás en la grieta
#

No entres en pánico, pero muévete rápido. La grieta no se cierra mañana — pero sí se cierra.

Primero: acepta la realidad. Tu wrapper no es un moat. Tu UI bonita no es un moat. Tu prompt engineering no es un moat. Nada de eso te protege de un competidor que controla el modelo sobre el que construiste tu producto.

Segundo: busca terreno propio. ¿Puedes generar datos propietarios? ¿Puedes crear efectos de red? ¿Puedes integrarte tan profundamente en el flujo de trabajo de tu cliente que sacarte requiera un proyecto de migración? Si la respuesta es no a todo, tienes un negocio de cash extraction, no una empresa. Extrae el cash, pero no te engañes sobre lo que estás construyendo.

Tercero: construye el negocio que queda cuando quitas el modelo. Si le quitas GPT-4 a tu producto y no queda nada, no tienes un producto. Si le quitas GPT-4 y queda un workflow, una base de datos, una comunidad, una integración — tienes algo que puede sobrevivir al siguiente temblor.

El terremoto que viene
#

Los hyperscalers no van a dejar de moverse. Al contrario — están acelerando. Cada release es más capaz, cada plataforma absorbe más funcionalidad, cada modelo hace innecesaria otra capa de abstracción.

No estoy diciendo que no se pueda construir un gran negocio sobre IA. Se puede, y se está haciendo. Pero los que sobreviven no son los que encontraron una grieta y montaron una tienda. Son los que construyeron sobre roca propia.

La pregunta no es si las placas se van a mover. La pregunta es si cuando se muevan, tú vas a estar en terreno firme o vas a ser otro solopreneur celebrando un MRR que tiene fecha de caducidad.

Mira hacia abajo. ¿Ves la grieta?

Carles Abarca es VP de Transformación Digital en el Tec de Monterrey y ex-CTO de Banco Sabadell. Escribe sobre las implicaciones estratégicas de la IA en carlesabarca.com.

Deja de Pagar de Más por Inteligencia

Fri, 24 Apr 2026 00:00:00 +0000

El comportamiento por defecto de la mayoría de productos con IA hoy es simple: ante la duda, llama al modelo frontier.

Cada mensaje de cliente clasificado por GPT-5. Cada tarea de extracción enrutada a través de Claude. Cada prompt, por trivial que sea, procesado por la misma máquina de varios billones de parámetros diseñada para razonar sobre estrategia legal, redactar patentes farmacéuticas y depurar sistemas distribuidos.

Funciona. Se integra rápido. Hace que el producto se sienta inteligente.

Y se está convirtiendo, silenciosamente, en uno de los hábitos más caros del stack moderno de IA.

El default que sobrepaga
#

Hace unas semanas escribí sobre el fin de la IA barata — el momento en el que los límites de suscripción, los caps de uso y los costes reales de inferencia empezaron por fin a reflejar la economía real de los modelos frontier. Esa es la historia macro.

Esta es la historia micro que está por debajo.

La razón por la que tantas empresas están a punto de sentir el aprieto no es solo que los precios frontier estén subiendo. Es que la arquitectura típica se construyó sobre una suposición silenciosa: que no había coste que mereciera preocupación, y que por lo tanto el mejor modelo debía encargarse de todo. Esa suposición se está rompiendo desde los dos lados a la vez.

Por un lado, la inferencia frontier es cada vez más cara, está cada vez más medida y cada vez menos subsidiada.

Por el otro — y esta es la parte que la mayoría de roadmaps aún no han puesto en el precio — los modelos locales y open-weight se han vuelto, silenciosamente, lo bastante buenos para una parte enorme de las tareas reales de empresa.

Esa combinación cambia la economía de la IA más que cualquier anuncio de producto de este año.

Lo que los modelos locales ya saben hacer
#

Hace unos años, “monta tu propio LLM” significaba un proyecto de ingeniería heroico, una clara bajada de calidad y un equipo de infraestructura que echaba de menos la nube en secreto.

Hoy, ya no.

La generación actual de modelos open-weight — Llama, Qwen, Mistral, DeepSeek, Gemma y sus derivados — ha cruzado umbrales de capacidad que en 2023 habrían sonado a ciencia ficción. Un modelo open-weight de 70B parámetros corriendo en una workstation de gama alta o una instancia GPU modesta rinde de forma competitiva en los benchmarks que más importaban a las empresas al inicio de este ciclo: razonamiento general, completado de código, resumen, extracción, traducción, output estructurado.

Y sigue mejorando. Rápido.

Esto no significa que frontier y open-weight sean intercambiables. No lo son. Los modelos frontier todavía sacan clara ventaja en coherencia de contexto largo, planificación agéntica multi-paso, síntesis novedosa de dominios y en los niveles más duros de generación de código.

Pero lo que importa en un roadmap de IA no es si los modelos locales han alcanzado a los frontier en todo. Es si son lo bastante buenos en las tareas específicas que tu sistema realmente ejecuta.

Y para la mayoría de los workloads enterprise en 2026, la respuesta es, cada vez más, sí.

El mapa que la mayoría de arquitecturas de IA no tienen
#

Si miras con atención lo que ocurre dentro de la mayoría de aplicaciones con IA, los workloads se dividen limpiamente en dos grupos.

Tareas que sí necesitan un modelo frontier:

Razonamiento de contexto largo a lo largo de decenas de documentos.
Planificación agéntica multi-paso sobre objetivos ambiguos.
Generación compleja de código desde cero en dominios poco familiares.
Síntesis creativa que mezcla múltiples voces expertas.
Manejo de inputs adversariales o casos borde que exigen juicio real.

Tareas que casi con toda seguridad no:

Clasificación de emails, tickets o documentos por tipo.
Extracción de entidades, fechas e importes en un texto.
Resumen de una o dos páginas de contenido.
Reescritura de un párrafo en un tono diferente.
Generación de output estructurado (JSON, SQL) a partir de texto plano.
Traducción entre idiomas mayoritarios.
Respuesta a FAQs desde una capa de retrieval.
Sub-pasos deterministas dentro de un agente mayor.

La mayoría de arquitecturas de IA tratan a ambos grupos de la misma manera. No deberían.

El trabajo de cualquier stack de IA adulto — y uso “adulto” en el sentido de fase madura, en oposición a la fase de subidón de azúcar de los últimos dos años — es enrutar cada tarea al tier correcto. Frontier cuando se lo gana. Open-weight cuando no.

La palabra que llevo usando internamente para esto es discriminación de tareas. No en el sentido social — en el arquitectónico. La capacidad de reconocer que distintas tareas merecen distintos presupuestos de inteligencia, y diseñar en consecuencia.

No es solo una cuestión de coste
#

El coste es la razón más visible para preocuparse por la discriminación de tareas. No es la única.

Hay otras cuatro razones que no dejan de componerse a medida que una organización usa IA más profundamente.

Latencia. Un modelo local de 8B o 13B corriendo al lado de tu aplicación puede devolver una clasificación en menos de 100 milisegundos. Un round-trip a una API cloud frontier rara vez es así de rápido. Para experiencias interactivas, agentes de cara al usuario o automatizaciones internas de alta frecuencia, esa diferencia importa.

Privacidad y residencia de datos. Enrutar cada email de cliente, cada historia clínica, cada expediente académico o cada memorando interno a través de un modelo de terceros es una postura de gobernanza que envejece mal. Los reguladores lo han notado. Los consejos lo han notado. Para un número creciente de casos de uso — salud, educación, legal, defensa, gobierno y cualquier dominio cubierto por regímenes locales de protección de datos — la inferencia local no es una optimización. Es un requisito.

Fiabilidad. Cuando tu arquitectura depende de un único proveedor frontier, también depende de sus rate limits, sus restricciones de suscripción, sus caídas y su roadmap comercial. Es un nivel de dependencia sistémica que levantaría cejas en cualquier otra parte del stack tecnológico.

Determinismo y control. Un modelo más pequeño que controlas por completo, fine-tuneado o prompt-tuneado para una tarea estrecha, suele comportarse de forma más predecible que un modelo frontier generalista optimizado para manejar el universo entero. La predictibilidad está infravalorada hasta que falta.

Ninguno de estos puntos, por sí solo, es razón para abandonar los modelos frontier. Todos juntos son razón suficiente para dejar de usar modelos frontier por defecto para todo.

Los números no son sutiles
#

Déjame ilustrarlo con un escenario simple.

Imagina una organización de tamaño medio corriendo un millón de llamadas ligeras de IA al mes: una mezcla de clasificación, extracción, resumen y output estructurado. Pongamos que la llamada media consume del orden de mil tokens de entrada y salida.

Enrutadas a través de un modelo frontier de primera línea, la factura de inferencia para esas llamadas se sitúa cómodamente en las decenas de miles de euros al mes. Multiplica por doce, añade crecimiento, y es el tipo de línea presupuestaria que empieza a aparecer en las revisiones del CFO.

El mismo workload, enrutado a través de un modelo open-weight bien desplegado — on-prem o en una instancia GPU dedicada en un proveedor especializado — sale un orden de magnitud más barato, a veces dos. Y la diferencia de calidad, en precisamente este tipo de tareas, suele ser invisible para el usuario final.

Eso no es un error de redondeo. Es la diferencia entre que la IA sea una capacidad operativa sostenible y que la IA sea una línea que tu CFO empieza a cuestionar en cada forecast.

Y las organizaciones que se den cuenta primero no van a usar el ahorro para reducir. Lo van a usar para escalar más.

Cómo lo corro yo en mi propio escritorio
#

La forma más honesta de escribir sobre discriminación de tareas es describir lo que yo mismo corro, no lo que creo que otros deberían correr.

En mi propio setup tengo un Mac Studio dedicado a publicar modelos locales para mis agentes. Está apoyado en una estantería, publica un endpoint de inferencia privado a través de LM Studio y aloja una pequeña biblioteca de modelos open-weight optimizados para MLX — el framework que permite a estos modelos aprovechar al máximo la GPU de Apple Silicon y la memoria unificada.

Nada de esa máquina está expuesto a internet público. El endpoint vive dentro de mi red, detrás de los límites que cualquier setup serio exige. Para el tipo de trabajo que enruto por ahí, eso no es opcional.

Elegí un Mac Studio frente a la alternativa obvia — un rig GPU dedicado — por razones que no son puramente técnicas. Tiene potencia suficiente para los tamaños de modelo que me importan de verdad. Es extraordinariamente fiable. Es casi perfectamente silencioso. Y su consumo en reposo es lo bastante bajo como para poder dejarlo encendido 24/7 sin pensármelo. Nada de eso importa cuando estás alquilando H100s por hora. Importa mucho cuando la máquina es una pieza permanente de tu stack operativo.

La arquitectura en sí es deliberadamente simple.

El orquestador principal — el LLM que da vida a mis agentes — es un modelo frontier. Ahí es donde ocurre el razonamiento duro, donde la ambigüedad tiene que resolverse, donde el plan completo tiene que sostenerse. Para ese papel, pagar por el mejor merece la pena.

Pero por debajo del orquestador, reglas de routing empujan las subtareas al endpoint local siempre que es posible o recomendable. Local hace el trabajo rutinario. Frontier hace el pensamiento.

El resultado es que mi factura de modelos frontier se ha colapsado sin ninguna pérdida perceptible de calidad en la experiencia de extremo a extremo. No porque local haya alcanzado a frontier en todo — no lo ha hecho — sino porque una parte enorme de lo que cualquier agente hace en realidad no es razonamiento en el sentido duro. Es clasificar. Extraer. Resumir. Reformatear. Traducir. Producir output estructurado.

Modelos como qwen3.6-35b-a3b-ud-mlx, gemma-4-31b-it-mlx o gpt-oss-20b-mlx resuelven esas tareas a la perfección. Corriendo en local. Con latencias que un round-trip a la nube no puede igualar. Y sin enviar un solo byte de contexto a un tercero.

Eso no es una arquitectura teórica. Es lo que está corriendo en mi escritorio, hoy.

Entonces, ¿qué debería cambiar?
#

No hace falta arrancar nada. Hace falta rearquitecturar.

Al menos en cinco frentes.

1. Construye una taxonomía de tareas
#

Cada llamada de IA en tu producto o en tus operaciones pertenece a un tier de complejidad. Mápealas. La mayoría de equipos descubre que más de la mitad de sus llamadas caen cómodamente en el cubo de “no necesita frontier” — y llevan años pagando precios frontier por ellas sin darse cuenta.

2. Empieza con un router, no con una migración
#

El primer paso con más apalancamiento no es cambiar de modelo. Es añadir una capa de routing inteligente — a veces tan simple como “clasifica la intención, luego despacha” — que envíe las tareas triviales a un tier más barato y solo escale cuando la confianza sea baja o la complejidad alta.

3. Mide coste y calidad por tarea, no por modelo
#

La pregunta “¿qué modelo es el mejor?” es la equivocada. La pregunta correcta es “¿qué modelo es el mejor para esta tarea específica a este coste específico?”. Construye la observabilidad que responda a eso.

4. Trata lo local como una capacidad, no como una rebaja
#

Los modelos open-weight ya no son un premio de consolación. En muchos workflows son la herramienta correcta — más rápidos, más baratos, más privados, más controlables. Los equipos que todavía hablan de ellos en tono defensivo están señalando cuánto tiempo hace que no los miran.

5. Diseña híbrido por defecto
#

Las arquitecturas de IA interesantes de 2026 no serán puramente frontier ni puramente locales. Serán sistemas orquestados que combinan un modelo frontier para las partes difíciles, modelos open-weight para las partes rutinarias y modelos pequeños fine-tuneados para lo estrecho y de alto volumen — cada uno llamado cuando, y solo cuando, se lo gana.

La verdadera palanca de coste de la IA en 2026
#

La narrativa dominante este año seguirá enfocándose en la frontera: modelos más grandes, benchmarks más altos, capacidades más afiladas. Esa narrativa es real, y importa.

Pero por debajo hay un desplazamiento más silencioso que va a determinar qué organizaciones construyen de verdad operaciones de IA sostenibles — y cuáles acabarán racionalizando recortes de coste agresivos en 2027.

El desplazamiento no va de elegir entre frontier y local. Va de aprender a usar los dos, deliberadamente, en los momentos correctos, en las combinaciones correctas.

La optimización de IA más barata disponible en 2026 no es conseguir un mejor precio de tu proveedor actual.

Es la decisión de dejar de usar un modelo frontier para trabajo que un modelo local hace igual de bien.

La inteligencia está empezando a ser abundante. El criterio para usarla bien se está convirtiendo en el recurso escaso.

Las empresas que ganen la próxima fase de este ciclo no son las que paguen más por llamada.

Son las que ya han descubierto qué llamadas no hacía falta pagar.

DigitalTransformation on Carles Abarca

Tu startup de IA no es una empresa: es un feature de OpenAI o de Anthropic

Las placas tectónicas de la IA #

El cementerio de features que se creyeron empresas #

La trampa del solopreneur #

La diferencia entre un feature y una empresa #

El test de la grieta #

Qué hacer si estás en la grieta #

El terremoto que viene #

Deja de Pagar de Más por Inteligencia

El default que sobrepaga #

Lo que los modelos locales ya saben hacer #

El mapa que la mayoría de arquitecturas de IA no tienen #

No es solo una cuestión de coste #

Los números no son sutiles #

Cómo lo corro yo en mi propio escritorio #

Entonces, ¿qué debería cambiar? #

1. Construye una taxonomía de tareas #

2. Empieza con un router, no con una migración #

3. Mide coste y calidad por tarea, no por modelo #

4. Trata lo local como una capacidad, no como una rebaja #

5. Diseña híbrido por defecto #

La verdadera palanca de coste de la IA en 2026 #