GPT-4 salió a 60 dólares por millón de tokens de salida. Dos años después, el coste de usar los mejores modelos había caído un 82%, según un gráfico que Ethan Mollick difundió en 2025. Un plan de negocio de IA escrito en 2023 tenía mal casi todas sus líneas de coste, y a menudo también el precio que podía pedir.
Ese es el problema de fondo para un Product Manager. En un SaaS clásico el modelo de negocio descansaba sobre costes estables: problema, demanda, propuesta de valor, precio, adquisición, retención. En un producto con IA esa secuencia sigue valiendo, pero ya no alcanza.
La IA mete variabilidad donde antes había estabilidad. El coste cambia con el uso. La calidad no es del todo determinista. Los modelos se degradan con el tiempo. Y la ventaja competitiva suele vivir en el sistema completo que rodea al modelo.
Por eso el PM tiene que responder más preguntas que antes. ¿Es deseable la función? Sí, pero además: ¿es sostenible en euros por usuario, se puede gobernar, se puede evaluar con rigor, hay datos para que funcione y deja una ventaja repetible o solo una demo vistosa?
Primero el problema: frecuencia, impacto y datos, las tres a la vez
El error más común es empezar por la tecnología. Qué modelo usar, si conectar documentos propios (RAG) o ajustar el modelo (fine-tuning), qué proveedor responde más rápido, cómo meter un asistente en la interfaz. Son preguntas legítimas, pero llegan demasiado pronto.
Antes hay que saber qué problema se resuelve, con qué frecuencia aparece, cuánto cuesta hoy y qué datos existen. La IA por sí sola no crea valor. Lo crea cuando amplifica una parte importante del trabajo del usuario, mejora una decisión o reduce un coste estructural.
Un problema adecuado para IA cumple tres condiciones a la vez:
- Frecuencia. Aparece tan a menudo que justifica una solución sistemática.
- Impacto. Tiene un efecto económico, operativo o estratégico visible.
- Datos. Existe una base razonable para entrenar, recuperar, evaluar o ajustar el sistema.
Si falla una, el caso de uso puede ser atractivo técnicamente y débil como negocio. Suelen encajar las tareas de gran volumen, alta repetición o mucho dato no estructurado: clasificación, predicción, búsqueda, priorización, síntesis, detección temprana de riesgo.
Ejemplo ilustrativo: una gestoría mediana procesa 4.000 facturas al mes y dedica 3 minutos a cada una. Son 200 horas al mes, más que una persona a jornada completa.
Si la IA extrae los datos y el empleado solo revisa, el tiempo baja a 1 minuto por factura. Quedan 67 horas: se liberan 133 horas al mes. A 25 euros la hora con cargas, son 3.325 euros al mes, unos 40.000 al año. Esa cifra es el techo de lo que el producto puede cobrar y gastar en inferencia.
Ahora cambia una variable. Si la gestoría procesa 400 facturas en vez de 4.000, el ahorro baja a 333 euros al mes. El problema es el mismo y la tecnología también. El negocio, no.
Aquí el PM evita dos trampas opuestas. Una es sobrevalorar la novedad y creer que cualquier proceso con texto o imágenes merece una capa de IA. La otra es tratarla como una mejora incremental del software existente. Lo sensato es buscar los puntos donde la IA cambia de verdad la relación entre coste, velocidad, calidad y experiencia.
De las tres condiciones, la de los datos es la que más se subestima. Que existan facturas no significa que se puedan usar: hace falta permiso del cliente, un formato legible y un histórico con la respuesta correcta. Sin ese histórico no hay forma de medir la precisión. Y sin precisión medida no hay precio defendible.
Seis rutas de valor, y solo una paga las facturas
«Más inteligente», «más automatizado», «más personalizado»: con eso no se modela un negocio. Hay que precisar qué crea la IA en ese contexto.
En la práctica el valor llega por seis rutas:
- Reducir costes: sustituye o comprime trabajo manual.
- Acelerar procesos: menos tiempos muertos y ciclos de revisión más cortos.
- Mejorar la precisión: menos errores y menos retrabajo.
- Detectar riesgo antes: fraude, cumplimiento normativo, soporte, finanzas.
- Mejorar la experiencia: recorridos más fluidos o más útiles.
- Abrir usos nuevos: copilotos, interfaces conversacionales, generación contextual.
Enumerarlas sirve de poco. Al PM le toca decidir cuál será el motor económico dominante, porque de ella sale el precio.
En la gestoría del ejemplo el motor es el ahorro, y el precio se ancla en horas. En otro producto será la expansión de capacidad: el mismo equipo hace más sin crecer. En un tercero la IA no ahorra nada directamente, pero sube la retención o la conversión, y el precio se defiende con esas métricas.
Sin esa elección la propuesta de valor sale confusa. Más tarde, la monetización también: nadie sabe qué cobrar por algo que no sabe nombrar.
Una pista para elegir: la ruta dominante es la que el comprador ya mide. Un director financiero mide horas y euros. Un director de producto mide retención. Un responsable de riesgos mide incidentes evitados. Vender ahorro a quien mide retención alarga el ciclo de venta, porque el comprador tiene que traducir tu argumento a su métrica antes de defenderlo dentro de su empresa.
El foso está en el sistema, porque el modelo se abarata cada año
Guido Appenzeller, de a16z, bautizó en noviembre de 2024 el fenómeno como «LLMflation»: a igual capacidad, el coste de inferencia cae alrededor de 10 veces al año. Si el modelo se abarata así para todos, elegir el modelo correcto no protege a nadie durante mucho tiempo.
Cambiar de API tampoco es gratis: obliga a revisar integración, evaluaciones y condiciones del proveedor. Pero el rendimiento bruto deja de diferenciar. Lo que protege es el sistema que se construye alrededor.
El código que llama al modelo es una pieza pequeña dentro de un sistema mucho mayor de datos, configuración, monitorización y servicio. Ahí se acumulan tanto la deuda como la ventaja.
Ese sistema suele tener cuatro capas:
- Datos: cómo entran, se limpian y se etiquetan; cómo se preparan para la búsqueda; dónde se guardan; cómo vuelve la opinión del usuario.
- Modelos: modelos base, modelos ajustados, búsqueda de contexto en documentos propios (RAG) y pruebas de calidad.
- Orquestación: las instrucciones (prompts), qué modelo atiende cada consulta, los agentes, el plan B cuando algo falla y la memoria. Es la capa más infravalorada.
- Experiencia: lo que el usuario ve, copilotos, automatizaciones, paneles, asistentes.
La mayoría de los fallos de escalabilidad nacen en las tres primeras capas. Ninguna pieza protege mucho por separado. Lo que cuesta copiar es cómo encajan.
Esto cambia la forma de priorizar. Un copiloto luce más que una capa de evaluación, pero quizá sea la evaluación la que sirva a cuatro productos más adelante. Una capacidad merece prioridad cuando cumple seis criterios:
- buen encaje entre problema y modelo;
- datos disponibles hoy, no prometidos;
- requisitos de latencia y precisión manejables;
- dependencia técnica aceptable;
- riesgo de gobernanza asumible;
- coste de inferencia que el precio puede absorber.
Para decidir entre alternativas basta una hoja con tres columnas por opción: coste por llamada, latencia esperada y tasa de respaldo humano. RAG frente a fine-tuning, modelo pequeño frente a grande, caché frente a inferencia dinámica. Con esos números delante, la discusión deja de girar en torno a preferencias técnicas.
Así el PM deja de perseguir solo victorias rápidas y empieza a pensar en lo que se acumula. Una buena priorización pregunta por el impacto visible. Pero también pregunta qué hace aprender más rápido al equipo, qué reduce el riesgo y qué abarata las apuestas siguientes. Una capa de evaluación que hoy no ve nadie puede ahorrar semanas en cada lanzamiento de los próximos dos años.
¿Cómo se ve un modelo que se degrada en silencio?
Se ve bien en el panel de uso. Un modelo que pierde calidad puede mantener estables las métricas de uso durante semanas mientras sus respuestas empeoran. En el software tradicional la lógica es estable y las variaciones vienen del usuario. En IA no.
La calidad cambia con los datos, el contexto, la distribución de consultas, los ajustes del proveedor y el paso del tiempo. Por eso la analítica tiene que mirar en dos direcciones a la vez.
Del lado del usuario siguen contando la activación, cuánto usa el producto, las tareas completadas, el tiempo ahorrado y la retención. Del lado del modelo cuentan la precisión, la exhaustividad, cuántas respuestas se inventa, cuánto tarda en responder, cuánto cuesta cada consulta y si empeora con el tiempo (drift).
Medirlas por separado sirve de poco. El PM necesita saber qué caída de precisión afecta a la experiencia, qué subida de latencia destruye la activación y qué cambio de coste rompe la unidad económica.
Una de esas conexiones se puede medir en cualquier producto: la latencia. Si la variante con más contexto tarda más en responder, parte de los usuarios abandona antes de ver la respuesta, y la mejora que el modelo mostraba offline nunca llega al negocio.
La cadena es corta: más contexto, más latencia, menos conversión. Un modelo más listo que tarda dos segundos más puede vender menos que uno más simple, y eso solo se ve si la latencia y la conversión aparecen en el mismo panel, con la misma segmentación por usuario.
Dos de esas señales engañan si se leen solas. La precisión dice cuántas de las salidas marcadas como positivas lo son de verdad; la exhaustividad, cuántos de los casos reales recupera el sistema. Subir una suele bajar la otra, y cuál importa más lo decide el coste del error: una factura urgente que se escapa acaba en queja, una falsa alarma solo cuesta una revisión. La latencia conviene mirarla en el percentil 95, porque la media esconde la cola lenta, que es la que abandona.
Un ejemplo de cómo se lee junto: un clasificador de facturas marca 1.000 como «urgentes»; 850 lo son (precisión del 85%). Había 1.200 urgentes reales, así que recupera 850 de 1.200, un 71% de exhaustividad. Las 350 que se escapan son las que acaban en una queja.
El drift se vigila con un conjunto fijo de consultas reales ya etiquetadas. Por ejemplo, 200 facturas revisadas a mano, unas 10 horas de trabajo una sola vez. Se vuelven a pasar cada vez que el proveedor actualiza el modelo o cambia el prompt. Si la precisión cae más de 3 puntos, el cambio no se despliega. Es barato, y es la única forma de enterarse antes que el cliente. Si el proveedor actualiza el modelo una vez por trimestre, esas 10 horas iniciales se amortizan con el primer despliegue defectuoso que se queda fuera de producción y nunca llega a los clientes.
La IA afecta también al embudo completo: acelera el onboarding y el primer momento de valor, sube el engagement, predice el churn o detecta oportunidades de venta adicional. Por eso su analítica no puede vivir aislada en un panel técnico. Tiene que entrar en la lectura de negocio del producto, en la misma reunión donde se mira la retención.
Un experimento de IA mide cinco dimensiones a la vez
Un experimento de interfaz pregunta si el usuario prefiere una versión. Uno de IA pregunta además si el modelo es viable en condiciones reales, si mantiene la seguridad, si la economía cierra y si el sistema aguanta la carga.
Las pruebas con datos históricos sirven para avanzar rápido y descartar opciones débiles. No sustituyen a las pruebas con usuarios reales. En producción llegan consultas distintas, casos raros, entradas inesperadas, caídas de rendimiento cuando hay mucho tráfico y comportamientos que en el laboratorio no existen.
Así que cada experimento mide cinco cosas: resultado de usuario, rendimiento del modelo, seguridad, latencia y coste. Si una variante gana en la primera y pierde en la última, todavía no ha ganado.
La tasa de victorias reales es baja incluso sin IA: la mayoría de las ideas que llegan a un test no mueven la métrica principal. Con cinco dimensiones que vigilar, la probabilidad de que una variante gane en todas a la vez es todavía menor, y conviene planificar el calendario de pruebas contando con ello.
Las salvaguardas son parte del modelo de negocio, no solo del control interno. Por ejemplo: cuántas respuestas inventadas se toleran, qué temas están prohibidos, qué margen de error se acepta y cuándo pasa el caso a una persona. Protegen la reputación y el cumplimiento normativo, y con ellos la viabilidad comercial.
Ese cumplimiento tiene además un coste propio: formar al personal que opera el sistema, documentar los controles y revisar las salidas de riesgo. Es una línea que conviene presupuestar desde el principio, con su responsable.
El caso Moffatt contra Air Canada lo ilustra. En febrero de 2024 un tribunal civil de la Columbia Británica obligó a la aerolínea a pagar 812,02 dólares canadienses porque su chatbot había dado información falsa sobre una tarifa. La cifra es pequeña; el precedente, que la empresa responde de lo que dice su asistente, no lo es.
Para el PM, la lección se traduce en una línea más del modelo: errores esperados al mes por coste medio de cada uno. Si un asistente responde 10.000 preguntas al mes, se equivoca en una de cada mil de una forma que obliga a compensar al cliente y cada compensación cuesta 300 euros, son 3.000 euros mensuales. Esa cifra tiene que estar en la misma hoja que el coste de inferencia, porque a menudo lo supera.
Por la misma razón, el primer aumento de conversión merece cierta desconfianza. Antes de celebrarlo hay que comprobar que la muestra alcanza la potencia estadística fijada de antemano y que la latencia y el coste de la variante ganadora siguen dentro de sus límites.
Un margen bruto del 50-60%: la economía ya no es la del SaaS
Martin Casado y Matt Bornstein, de a16z, estimaron en febrero de 2020 que las empresas de IA trabajaban con márgenes brutos del 50-60%, frente al 60-80% o más de un SaaS comparable. La diferencia sale del coste de servir, que crece con cada consulta.
Ese coste depende del tamaño del modelo, la longitud del contexto, los tokens generados, la frecuencia de uso, los picos de tráfico y la eficiencia de la caché. Un cambio pequeño en la experiencia puede alterarlo por completo. Más contexto o un razonamiento más profundo sube el valor percibido y, a la vez, el coste.
La fórmula que conviene tener a mano:
Coste mensual por usuario = consultas al mes × tokens por consulta × precio por token
Con un precio de 10 dólares por millón de tokens, por ejemplo:
- Usuario medio: 300 consultas × 2.000 tokens = 600.000 tokens, unos 6 dólares al mes.
- Usuario intensivo: 3.000 consultas × 2.000 tokens = 6 millones de tokens, unos 60 dólares al mes.
- Plan a 30 euros al mes más IVA del 21%: el cliente paga 36,30 euros, la empresa ingresa 30.
Con el usuario medio el margen es cómodo. Con el intensivo, cada cliente cuesta el doble de lo que paga. Y son los intensivos quienes más recomiendan el producto, así que el problema crece con el éxito.
Hay palancas antes de tocar el precio. Anthropic factura las lecturas de prompt en caché a 0,1 veces el precio normal; la Batch API de OpenAI cobra un 50% menos a cambio de responder en un plazo de hasta 24 horas. Para tareas que no necesitan respuesta inmediata, eso parte el coste por la mitad.
Vuelve al usuario intensivo del ejemplo. Si el 60% de sus tokens se repite en cada consulta (instrucciones del sistema, documentación del cliente) y se sirve desde caché, el coste efectivo baja a 60 × (0,4 + 0,6 × 0,1) = 27,6 dólares. Sigue siendo alto, pero ya cabe por debajo de los 30 euros del plan. El rediseño técnico ha hecho el trabajo que, si no, habría tenido que hacer una subida de precio.
Cabe preguntarse si todo este esfuerzo merece la pena: si el coste cae unas 10 veces al año, optimizar hoy parece tiempo perdido, porque el problema se resolverá solo. En productos pequeños, con poco uso y márgenes holgados, es así. Deja de serlo cuando el uso crece más rápido que caen los precios, que es justo lo que ocurre cuando el producto funciona: los usuarios piden más contexto, más razonamiento y más automatización, y cada mejora consume la rebaja del proveedor.
A esto se suman los costes de mantener el sistema vivo: preparar y etiquetar datos, ajustar el modelo, evaluarlo, volver a probar lo que ya funcionaba, ampliar la infraestructura, vigilar que no empeore y controlar su uso. En muchos productos acaban pesando más que el desarrollo inicial. Cada uno merece su propia línea, con responsable y frecuencia de revisión.
En precios, la IA suele abrir cuatro caminos: cobro por uso, acceso escalonado, pricing basado en valor y modelos híbridos. El acertado refleja a la vez el coste y la captura de valor. En el ejemplo, un plan con 1.000 consultas incluidas y cobro por uso a partir de ahí protege el margen sin castigar al usuario medio.
Una página con cuatro respuestas antes de aprobar la iniciativa
El retorno también se modela por escenarios. Un modelo de precios puede funcionar en el escenario central y fallar en cuanto el mercado se mueve, y sin un escenario pesimista escrito de antemano nadie sabe cuánto cuesta ese fallo hasta que llega la factura.
Para la gestoría del ejemplo, tres escenarios bastan. Pesimista: solo el 40% de las facturas pasa sin corrección y el ahorro anual se queda en unos 16.000 euros. Central: el 70%, unos 28.000 euros. Optimista: el 90%, unos 36.000 euros. Si el producto solo es rentable en el escenario optimista, no está listo para venderse. Lo útil de los tres escenarios es la distancia entre ellos: 20.000 euros al año separan el pesimista del optimista, y ese rango, más que la cifra central, es lo que el precio y el presupuesto de inferencia tienen que aguantar.
Ordenado como flujo de trabajo, todo lo anterior es manejable: problema y propuesta de valor, viabilidad de datos, mapa de capacidades, criterios de evaluación, experimentos, modelo financiero, escenarios y, al final, alineación organizacional. Muchos productos de IA con buena estrategia y buena tecnología fracasan precisamente en ese último paso, por falta de coordinación entre producto, datos, ingeniería, operaciones y gobernanza.
El flujo rara vez es lineal. Un modelo financiero que no cierra devuelve al equipo al mapa de capacidades. Su valor está en que vuelve repetible el aprendizaje.
Antes de aprobar una iniciativa, el PM puede exigir una sola página con cuatro respuestas:
- Qué problema resuelve, con qué frecuencia aparece y qué datos existen para atacarlo.
- Cuál de las seis rutas de valor será el motor económico dominante.
- Qué capacidad, más allá de la experiencia visible, quedará construida y reutilizable si la apuesta funciona.
- Cuánto cuesta servir a un usuario intensivo, no al medio, con el contexto, el razonamiento y la tasa de respaldo humano que la experiencia necesita.
Si alguna queda en blanco, la iniciativa sigue siendo una demo, por convincente que resulte en una presentación. Si la cuarta solo cierra con el usuario medio, el precio tiene que cambiar antes del lanzamiento.
Si todas cierran, toca fijar los criterios de evaluación y las salvaguardas antes de escribir la primera línea de integración. La pregunta de qué modelo usar llega la última: es la respuesta que más rápido caduca.