¿Cuánto margen deja un token que cada año cuesta bastante menos que el anterior? Menos de lo que parece. El precio de los modelos no deja de caer, y para una startup de IA eso suena al fin del problema del margen. No lo es. Con el token barato, el producto hace más por cada usuario: más contexto, más pasos encadenados, más reintentos. El cliente que pagaba 100 euros al mes sigue pagando 100, y el que más usa el producto sigue costando más de lo que paga.
Ahí está la diferencia con el SaaS clásico. En software tradicional el coste marginal por cliente tiende a cero con la escala, y una suscripción mensual aguanta precios imperfectos durante años. En IA cada inferencia cuesta, la calidad exige evaluación continua y el uso intenso puede ser justo la cohorte que hunde la cuenta. Por eso la monetización entra en el diseño del producto desde el primer día.
Un token más barato no deja más margen
La cadena es corta. El precio unitario baja. El equipo de producto lo aprovecha para meter más contexto en cada consulta y encadenar más llamadas. El consumo por tarea sube. Y la competencia, que ve la misma caída de precios, empuja el precio de lista hacia abajo. El margen por cliente se queda casi donde estaba.
El precio de lista, además, solo cubre la inferencia, es decir, el cálculo que hace el modelo en cada consulta. No dice cuánto gasta una startup concreta por tarea resuelta, y lo que rodea a ese cálculo pesa. El coste real de servir incluye guardar el contexto, buscar en los documentos del cliente, vigilar el sistema en producción, la seguridad, la moderación y las pruebas que controlan la calidad. Si el producto trata datos personales de clientes españoles, se suma el trabajo de cumplimiento ante la AEPD.
La regulación europea añade otra partida: desde febrero de 2025, el artículo 4 del Reglamento de IA obliga a quien despliega IA a tomar medidas que apoyen la alfabetización en IA de su personal, y formar al equipo del cliente es trabajo que alguien tiene que pagar. Si ese equipo tiene 20 personas y cada una necesita dos horas de formación valoradas en 40 € la hora, son 1.600 € que deben aparecer en algún lado del contrato.
Todo eso acaba en el margen bruto. El cómputo y la supervisión humana que el software clásico no necesita entran en el coste de cada venta, y una empresa de IA rara vez alcanza los márgenes a los que el SaaS acostumbró a los inversores.
Hay un segundo desajuste, y es de idioma. Dentro de la empresa se habla de tokens, tiempo de respuesta, representaciones vectoriales (embeddings) y reparto de consultas entre modelos.
El cliente piensa en horas ahorradas, errores evitados y expedientes cerrados. Cuando la factura se ancla en la lógica técnica, el cliente no entiende por qué paga más este mes, y la conversación comercial se atasca.
Fijar el precio es la parte fácil. Lo difícil es traducir la capacidad técnica a una métrica de valor que el cliente entienda y que se mantenga estable aunque cambie el modelo de debajo.
El cliente paga por lo que cambia en su trabajo
El mercado rara vez paga por «IA» en abstracto. Paga por el cambio que provoca en un flujo de trabajo, una decisión o un indicador del negocio. Esa distinción separa los productos que impresionan en una demo de los que facturan cada mes.
Un sistema generativo puede escribir un texto excelente. Si ese texto no acelera un proceso que el cliente ya mide, su valor económico es bajo.
Un motor predictivo con buena precisión que no cambia ninguna decisión se queda en curiosidad analítica. Una interfaz conversacional atractiva que no quita pasos a una tarea frecuente tiene poca disposición a pagar detrás.
Un ejemplo lo hace concreto. Un despacho de abogados revisa 400 contratos de arrendamiento al mes. Cada revisión manual lleva 45 minutos de un asociado cuyo coste ronda los 40 euros por hora: unos 30 euros por contrato y 12.000 euros al mes.
Si la herramienta deja la revisión en 15 minutos, el despacho ahorra 20 euros por contrato, 8.000 euros al mes. Esa es la métrica de valor: contratos revisados, con un ahorro medible por unidad.
Cobrar 5 euros por contrato captura una cuarta parte del ahorro y deja al cliente 15 euros por unidad. La factura mensual, 2.000 euros, se explica en una línea. Cobrar por tokens obligaría al despacho a entender algo que no le importa y a prever una cifra que no puede prever.
Según el sector, la métrica cambia: tiempo ahorrado, tareas automatizadas, leads cualificados, expedientes procesados, fraudes evitados, tickets cerrados. Cuanto más directa sea la conexión entre la salida del modelo y ese número, más defendible es el precio.
El caso límite aparece cuando el resultado depende de algo más que la herramienta. Si el despacho revisa más rápido porque además contrató a un asociado con experiencia, ¿de quién es el ahorro?
Por eso el precio por resultado necesita una línea base pactada antes de empezar, por ejemplo los 45 minutos medidos durante el mes previo. Sin línea base, cada factura abre una discusión.
Sin conexión entre la salida y un resultado, el producto vive del entusiasmo inicial. Y el entusiasmo no renueva contratos.
Hay además un efecto comercial. Cuando el precio se apoya en resultados, la negociación gira alrededor del retorno y ya no del coste técnico. El comprador defiende la partida ante su dirección con un número que ya conoce.
Cuatro formas de cobrar, y cuándo gana cada una
Con la métrica de valor definida, queda decidir cómo cobrarla. Hay cuatro opciones habituales, y ninguna sirve para todo.
Pago por uso. Se cobra por tokens, llamadas a la API, documentos procesados o imágenes generadas. El coste se mueve con el uso, así que la factura también. Su ventaja es la honestidad económica: quien usa más paga más, y la startup deja de subvencionar a los usuarios intensivos.
Su límite es la previsibilidad. Un director financiero no aprueba con gusto una partida que puede doblarse sin aviso, y un comprador no técnico no quiere pensar en tokens. Un tope mensual de gasto que el propio cliente configura reduce esa ansiedad sin cambiar el modelo. Gana con desarrolladores y con productos que se venden como API.
Suscripción más consumo. Una cuota fija incluye un volumen de uso, y el exceso se factura aparte. La cuota da previsibilidad a las dos partes; el exceso protege el margen frente a cargas desproporcionadas. Es el punto de partida razonable para asistentes de escritura, búsqueda aumentada y automatización documental.
Precio por resultado. El cliente paga por casos resueltos, expedientes revisados, tickets cerrados o fraudes detectados. Es el modelo más cercano al valor percibido. Además sube el valor total que deja el cliente a lo largo de su vida (CLV), porque el producto entra en un proceso central y sustituirlo obliga a rehacer ese proceso. Exige algo que pocas startups tienen al principio: una definición de «resultado» que ambas partes puedan auditar.
Créditos prepagados. Una variante del pago por uso: el cliente compra un paquete de créditos, por ejemplo 500 € por 10.000 créditos, y cada acción consume una cantidad fija. La startup cobra antes de gastar en cómputo, lo que mejora la caja. El riesgo está en la tabla de conversión: si una acción cuesta hoy 3 créditos y el modelo nuevo la hace más cara, cambiar la tabla se percibe como una subida de precio encubierta.
Vertical premium. En salud, legal, finanzas o ingeniería se venden precisión, trazabilidad y cumplimiento como parte del producto. El precio se apoya tanto en la función como en la credibilidad y en lo difícil que resulta cambiar de proveedor. El cliente paga también por no tener que justificar ante su regulador una herramienta que nadie conoce.
¿Y la suscripción plana de toda la vida? Funciona cuando el coste por unidad está acotado. Wetaca, la empresa de comida por suscripción con cocina central en el barrio madrileño de Villaverde, ganó 602.000 euros netos en 2024, el doble que el año anterior, con ventas un 23% más altas, según Xataka citando a Cinco Días.
Cada táper de Wetaca tiene un coste conocido antes de salir de la cocina. En IA, el «táper» no tiene tamaño fijo: un usuario puede pedir diez veces más cómputo que otro por el mismo precio. La suscripción plana pura solo aguanta si el uso está limitado por diseño.
La regla práctica para elegir:
- comprador técnico y consumo que él mismo puede prever: pago por uso;
- comprador de negocio y uso que varía más de 3 veces entre clientes: suscripción con volumen incluido y exceso;
- un resultado contable que ambas partes registran: precio por resultado;
- error caro y sector regulado: vertical premium con cumplimiento incluido.
El modelo base se copia; los datos y la integración, mucho menos
Elegir bien el eje de cobro protege el margen. La posición competitiva se defiende con otros recursos.
Mucha gente cree que la ventaja de una startup de IA está en su modelo o en su acceso a un modelo fundacional concreto. Esa ventaja dura poco: los modelos se abaratan, los proveedores cambian precios y el código abierto avanza.
La defensa suele estar en tres sitios:
- Datos propios: señales de comportamiento y ciclos de retroalimentación que mejoran el sistema con cada uso.
- Integración profunda en el flujo de trabajo: cuanto más incrustada está la IA en una operación diaria, más caro es sustituirla por una alternativa superficial.
- Confianza: cumplimiento, estabilidad, seguridad, privacidad y respuestas coherentes en casos reales, sobre todo en sectores regulados.
Monetización y defensa están más conectadas de lo que parece. Un precio por resultado, dentro de un vertical con datos propios y cumplimiento fuerte, captura más valor y de paso complica la entrada de competidores genéricos.
Los ciclos de retroalimentación tienen además un efecto compuesto. Si cada contrato revisado y corregido por el asociado entrena el sistema, la precisión del mes 12 es mejor que la del mes 1 en ese tipo de documento concreto, y un competidor que entra tarde empieza desde cero. El despacho del ejemplo no cambia de proveedor por un 10% de descuento si eso le obliga a revalidar 400 contratos al mes con otra herramienta.
¿Y si el proveedor del modelo lo copia? Es el temor más serio: los grandes proveedores de modelos acabarán ofreciendo la misma función dentro de sus propios productos, y la startup quedará como una capa fina que nadie necesita. Para un asistente genérico de escritura, el temor está justificado. Deja de estarlo cuando el producto depende de datos que el proveedor no ve y de un proceso que el cliente no quiere rehacer.
Calcula el margen por cohorte antes de mirar el CAC
En IA, la economía por cliente se calcula pronto, nunca «más adelante». El indicador clave es el margen de contribución: lo que queda tras restar el coste real de servir a cada cliente. Ese coste incluye alojamiento, búsqueda en documentos, memoria, caché, vigilancia del sistema, moderación, seguridad y, cuando toca, revisión humana y reentrenamiento.
Un crecimiento mal diseñado empeora el negocio. Cada cliente nuevo añade coste variable desde el primer día, aunque su ingreso tarde meses en compensarlo. Los usuarios intensivos parecen ideales porque usan mucho el producto. Si el precio no captura esa intensidad, son los que más margen se comen.
CLV, CAC y periodo de recuperación (payback) siguen siendo esenciales, pero se calculan distinto. El CLV debe salir de la retención, la expansión y el margen después del coste variable. El CAC solo tiene sentido frente a ese margen, nunca frente al ingreso bruto.
En SaaS se suele aspirar a recuperar el CAC en torno a un año. En IA el payback depende mucho más del coste de servir y puede variar varias veces entre segmentos del mismo plan: en el ejemplo de abajo, con el mismo CAC de 300 € y la misma cuota de 100 €, un cliente se recupera en menos de 4 meses y otro tarda 20.
Las fórmulas que conviene tener a mano, con precios sin IVA (el 21% que se añade en la factura española no es ingreso de la startup):
- Margen de contribución mensual = precio sin IVA menos coste variable de servir
- Payback en meses = CAC / margen de contribución mensual
- CLV = margen de contribución mensual × vida media del cliente en meses
- Coste por tarea = coste variable mensual / tareas resueltas en el mes
Las herramientas de simulación y de modelado financiero son útiles aquí. Permiten ver la sensibilidad del margen, el impacto del precio y el comportamiento de cada cohorte antes de que la escala vuelva el problema irreversible.
Margen de contribución de dos clientes en el mismo plan
Las cifras son ilustrativas y solo muestran la estructura del cálculo. Precios en euros, sin IVA.
- Cliente ligero, plan plano de 100 €/mes, unas 600 tareas: coste variable de servir (inferencia, base vectorial, moderación) de unos 20 €. Margen = 100 menos 20 = 80 € (80%).
- Usuario intensivo en el mismo plan, unas 2.500 tareas: el coste llega a 85 €. Margen = 15 € (15%). Si su uso crece un 30%, el coste ronda los 110 € y el margen pasa a ser negativo sin que cambie el ingreso.
- Payback con un CAC de 300 €: el cliente ligero se recupera en 300 / 80 ≈ 3,75 meses; el intensivo, en 300 / 15 = 20 meses.
El mismo cliente intensivo en un plan híbrido cambia de signo. La cuota de 100 € incluye 1.000 tareas y el exceso se cobra a 0,08 € por tarea. Sus 1.500 tareas extra suman 120 €, el ingreso sube a 220 €, el margen a 135 € (61%) y el payback baja a 300 / 135 ≈ 2,2 meses.
Reducir el coste también cuenta. Supongamos que la mitad de esos 85 € es contexto repetido en cada consulta. Si el proveedor cobra las lecturas de caché a una décima parte del precio normal, ese tramo baja de 42,50 € a unos 4,25 €, y el margen del cliente intensivo en el plan plano pasa de 15 € a unos 53 €. Para tareas que pueden esperar, el procesamiento por lotes suele salir bastante más barato que la llamada en tiempo real.
Dos cautelas antes de aplicarlo. Los costes son medios por tarea, y una tarea larga puede costar diez veces más que una corta. Y si el plan híbrido espanta al cliente intensivo, los 135 € de margen se quedan en el papel, así que el cambio de plan se prueba primero con una cohorte pequeña.
La lección: un plan plano vuelve no rentables justo a los clientes más activos, y el payback calculado sobre margen lo deja ver meses antes que cualquier cifra de ingresos.
Escalar con un plan plano solo agranda la pérdida
El diseño sigue un orden, y saltarse pasos sale caro:
- Mapear dónde se crea valor, descrito en resultados del cliente: horas, expedientes, euros.
- Elegir el eje de cobro entre uso, workflow, suscripción, híbrido o vertical premium, según valor percibido, patrón de uso y estructura de costes.
- Modelar la cadena completa de costes: inferencia, embeddings, memoria, seguridad, moderación, evaluación y mejora continua.
- Construir escenarios de precio sobre esa cadena y comprobar si el margen aguanta en la cohorte intensiva.
- Diseñar la expansión: licencias adicionales, módulos premium, límites superiores, complementos o verticales más profundos, para subir el CLV sin depender solo de la captación.
- Validar con experimentos: pruebas de precio, análisis por cohortes y sensibilidad al precio y al uso.
Los errores que más margen destruyen tienen síntomas reconocibles:
- Precio tipo SaaS sobre una carga intensiva en IA. Síntoma: el margen bruto cae mientras el uso medio sube.
- Cobrar por una abstracción técnica. Síntoma: cada renovación se negocia sobre el coste del token, nunca sobre el ahorro.
- Infravalorar los costes de seguridad, compliance y gobernanza. Síntoma: los clientes regulados piden auditorías que nadie presupuestó.
- Regalar uso ilimitado en la prueba gratuita. Síntoma: el coste de las cuentas de prueba supera al de los clientes que pagan.
- Hacer cuentas solo con el usuario medio. Síntoma: el margen agregado parece sano mientras una cohorte concreta pierde dinero.
Antes de la próxima ronda de crecimiento, el cálculo del ejemplo se repite con datos reales, cohorte por cohorte, empezando por los usuarios intensivos en planes planos. Si una cohorte tiene margen negativo o un payback mayor que la vida media del cliente, el problema es de diseño. Conviene corregirlo antes de invertir más en captación: cada cliente nuevo de esa cohorte agranda la pérdida.
Las palancas, por orden de impacto, suelen ser tres. Pasar del plan plano a uno híbrido con volumen incluido. Mover la métrica de cobro hacia el resultado que el cliente ya mide. Y bajar el coste de servir con caché, procesamiento por lotes o enrutado entre modelos.
Queda la prueba de estrés: duplicar el uso intensivo, subir un 20% el coste del proveedor y suponer una caída de 5 puntos en la retención. La mejora continua del sistema también tiene precio, así que entra en el escenario.
Con las cifras del ejemplo, el cliente intensivo en plan híbrido aguanta. Si pasa de 2.500 a 5.000 tareas, su coste sube a unos 170 € y su ingreso a 100 más 4.000 × 0,08, es decir, 420 €. Con el proveedor un 20% más caro, el coste llega a 204 € y el margen sigue en 216 €. En el plan plano, el mismo escenario deja una pérdida de 104 € al mes por cliente.
Para seguirlo en el tiempo bastan dos números por cohorte, revisados cada mes: margen de contribución como métrica principal y retención a 90 días como límite. Si el margen mejora y la retención cae más de 5 puntos, el nuevo precio está expulsando a los clientes que más valor obtienen. Las cohortes que siguen en positivo en ambos marcan dónde crecer; las demás, dónde el modelo de negocio sigue regalando cómputo a quien más lo usa.