Hay una pregunta que aparece siempre cuando alguien está construyendo un producto digital con agentes de IA: ¿cómo se le pone precio?

Detrás de esa pregunta hay algo más profundo: el miedo a diseñar un sistema que crezca en usuarios y, al mismo tiempo, destruya su propia rentabilidad.

El pricing no es solamente una tabla de precios. Es una decisión de arquitectura de negocio: define qué valor prometés, cómo medís el uso, qué riesgos asumís y quién absorbe la variabilidad del coste de inferencia.

El modelo por asiento dejó de contar toda la historia

Durante años, el SaaS se vendió principalmente por usuario. Tenía lógica: más personas usando el software significaban más acceso, colaboración y valor entregado.

Pero en un producto agentic esa relación puede cambiar. Un agente puede ejecutar tareas, consultar sistemas, generar documentos o resolver conversaciones sin que cada acción requiera un nuevo usuario humano. En consecuencia, el asiento sigue siendo útil cuando representa acceso, permisos, colaboración o capacidad de plataforma, pero no siempre refleja el volumen de trabajo que ejecutan los agentes.

Por eso, muchos proveedores están combinando una tarifa de plataforma o por usuario con consumo medido por acciones, créditos, conversaciones o resultados.

La diferencia conceptual es importante: el cliente ya no paga únicamente por entrar a una aplicación. También paga por lo que el sistema ejecuta.

Una forma sencilla de expresarlo sería esta: cobrar por asiento a un agente puede ser tan poco representativo como cobrar plazas de aparcamiento a una flota de coches autónomos.

La pregunta deja de ser solamente “¿cuántos usuarios tienen?” y pasa a ser:

• ¿Cuántos flujos de trabajo completan?
• ¿Cuántas acciones ejecuta el agente?
• ¿Qué resultado produce?
• ¿Qué coste variable genera cada operación?
• ¿Cuánto valor económico captura el cliente?

El coste variable de la inferencia

El SaaS tradicional se beneficia de una economía relativamente favorable: el producto se construye una vez y servirlo a un cliente adicional suele tener un coste marginal bajo.

En un sistema agentic, cada tarea puede generar:

• llamadas al modelo;
• pasos de razonamiento;
• consultas a herramientas;
• búsquedas o lecturas de contexto;
• reintentos;
• salidas largas;
• validaciones;
• escalados a personas.

Eso introduce una variable que no existía con la misma intensidad en el software tradicional: el coste de inferencia.

Una formulación más precisa sería decir que, en un SaaS agentic, el margen bruto deja de depender principalmente del coste fijo de servir software y pasa a estar muy influido por el coste variable de inferencia, herramientas y supervisión.

Además, el precio por token no es el único elemento que determina el coste. También importan:

• la longitud promedio del contexto;
• la cantidad de pasos por tarea;
• el modelo utilizado en cada paso;
• la proporción de peticiones cacheadas;
• el uso de herramientas externas;
• la tasa de errores y reintentos;
• el porcentaje de conversaciones que termina en un agente humano.

El precio de los tokens baja, pero el consumo puede crecer

Los precios de inferencia han caído de forma drástica para determinados niveles de capacidad. El AI Index documentó una caída superior a 280 veces en el coste de inferencia de una capacidad comparable a GPT‑3.5 entre noviembre de 2022 y octubre de 2024.[report-ai]

Eso no significa que todos los modelos, proveedores o niveles de calidad hayan bajado en la misma proporción.

Tampoco significa que el gasto total de una aplicación necesariamente disminuya. Un flujo agentic multipaso puede usar muchos más tokens que una interacción tradicional. Puede incluir contexto extenso, llamadas a herramientas, reintentos y validaciones.

La economía final depende de qué crece más rápido:

• la reducción del precio por token;
• el número de tareas;
• la complejidad de cada tarea;
• la cantidad de pasos por tarea;
• la longitud promedio del contexto.

Por eso, fijar precios suponiendo que los costes seguirán cayendo es una apuesta arriesgada. La reducción del coste unitario puede quedar compensada por un crecimiento mayor del consumo.

Tres familias de pricing

La taxonomía más útil distingue tres grandes unidades de cobro.

Pricing basado en tokens

El cliente paga por el uso del modelo, normalmente según tokens de entrada y salida.

Ventajas:

• protege mejor el margen del proveedor;
• conecta directamente ingresos y coste variable;
• es fácil de calcular internamente;
• permite trasladar cambios de consumo al cliente.

Problemas:

• el cliente no siempre entiende qué es un token;
• la factura puede ser difícil de anticipar;
• el coste puede variar por decisiones técnicas que el comprador no controla;
• una misma tarea puede costar distinto según el modelo y la longitud del contexto.

Este esquema puede funcionar para desarrolladores y equipos técnicos, pero suele ser menos atractivo como unidad principal para compradores de negocio.

Pricing basado en tareas o acciones

El proveedor cobra por una tarea o acción definida: clasificar un documento, generar una propuesta, actualizar un registro o ejecutar un flujo.

Es más legible para el cliente porque se acerca a la unidad de trabajo que compra. Sin embargo, conviene distinguir entre acción y resultado.

Una acción es una operación ejecutada por el agente. Una resolución es un resultado definido por el proveedor. No son unidades equivalentes.

Un flujo puede requerir muchas acciones antes de producir una resolución real. Por eso, un precio de 0,10 dólares por acción no se puede comparar directamente con 0,99 dólares por resolución o 2 dólares por conversación.

Pricing basado en resultados

El cliente paga por una métrica que ya reconoce como éxito:

• reuniones agendadas;
• facturas cobradas;
• tickets resueltos;
• solicitudes completadas;
• documentos aprobados;
• incidencias cerradas.

Este modelo puede alinear mejor los incentivos, pero exige definir con precisión qué cuenta como resultado.

La definición debe especificar:

• qué evento activa el cobro;
• qué señales determinan el éxito;
• cómo se tratan los abandonos;
• qué ocurre cuando interviene una persona;
• cómo se gestionan las reclamaciones;
• qué sucede si el resultado es parcial;
• qué ventana temporal se utiliza para atribuir el resultado.

La definición es una parte central del producto. Una “resolución” puede significar que el cliente confirmó explícitamente que su problema está resuelto, pero también puede basarse en señales indirectas, como que dejó de responder.

Por eso, “pago por resultado” no garantiza automáticamente una mejor alineación. Todo depende de cómo se mida el resultado.

La arquitectura híbrida suele ser la opción más prudente

El mercado no parece estar sustituyendo de forma generalizada el pricing por asiento por un modelo puro de resultados.

Una encuesta citada por Kyle Poyar entre más de 230 empresas de software e IA B2B identificó el pricing híbrido como una de las estructuras más utilizadas: una suscripción por asiento o plataforma combinada con consumo, créditos o uso de IA.[userpilot]

La lógica del modelo híbrido es sencilla:

• una tarifa base cubre la plataforma, el acceso y la capacidad disponible;
• una franquicia incluida ofrece previsibilidad;
• el consumo adicional captura el uso intensivo;
• los límites y alertas protegen al cliente de facturas inesperadas;
• el proveedor conserva una relación razonable entre ingresos y coste variable.

Una estructura típica podría ser:

• tarifa de plataforma;
• número de usuarios o permisos incluidos;
• cantidad de tareas o créditos incluidos;
• precio marginal por exceso;
• límites de velocidad o uso;
• opción de compromiso anual;
• cargos adicionales para modelos premium o flujos complejos.

La franquicia incluida debería cubrir la zona normal de uso, no ser tan pequeña que convierta cada mes en una negociación sobre excedentes.

El caso Agentforce

Salesforce es un buen ejemplo de un mercado que todavía está experimentando con distintas unidades de cobro.

Agentforce publica varias modalidades:

• pricing por conversaciones;
• Flex Credits para acciones;
• licencias de usuario;
• modalidades de plataforma y productos complementarios.

Salesforce publica una tarifa de 500 dólares por 100.000 Flex Credits. En su tabla de referencia, una acción estándar consume 20 créditos, equivalente a 0,10 dólares por acción. También publica un precio de 2 dólares por conversación para determinados casos de uso.[help.salesforce][salesforce]

En sus resultados del cuarto trimestre del ejercicio fiscal 2026, publicados el 25 de febrero de 2026, Salesforce informó de:

• 800 millones de dólares de ARR de Agentforce;
• crecimiento interanual del 169%;
• más de 29.000 acuerdos cerrados;
• 2,4 mil millones de Agentic Work Units entregadas;
• casi 20 trillion de tokens procesados acumulados.[investor.salesforce]

En español, conviene mantener “trillion” o escribir “casi 20.000 millones de millones de tokens”, porque “billón” en español equivale a 10^{12}, mientras que “trillion” en inglés equivale a 10^{18}.

Salesforce también indicó que más del 60% de las reservas del cuarto trimestre de Agentforce y Data 360 procedieron de la expansión de clientes existentes. Ese dato no debe atribuirse exclusivamente a Agentforce si el comunicado agrupa ambos productos.[investor.salesforce]

Estos resultados muestran tracción comercial, pero no prueban por sí solos que Agentforce esté canibalizando ingresos por asiento. Esa es una hipótesis estratégica posible, no un hecho comunicado por Salesforce.

Puede ocurrir que un agente sustituya algunas licencias, que expanda el contrato del cliente o que ambas cosas sucedan simultáneamente. El efecto depende del caso de uso y de la forma en que Salesforce empaquete el producto.

Comparar precios sin mezclar unidades

Algunos precios publicados en el mercado sirven como orientación, pero deben compararse con cuidado.

Una conversación puede contener múltiples mensajes. Una resolución puede incluir varias acciones. Una acción puede no producir ningún resultado útil.

La comparación correcta requiere estimar la cadena completa:

\text{coste por resolución real}
=
\text{acciones por conversación}
\times
\text{conversaciones por resolución}
\times
\text{coste por acción}

En un modelo por conversación, además, pueden cobrarse conversaciones fallidas. En un modelo por resolución, el proveedor asume una parte mayor del riesgo de rendimiento, pero también tiene incentivos para definir cuidadosamente qué cuenta como resolución.

Los contratos empresariales no son benchmarks universales

Plataformas como Sierra, Decagon o Ada pueden trabajar con contratos empresariales personalizados. En esos casos, el precio puede incluir:

• implementación;
• integración con sistemas internos;
• seguridad;
• soporte;
• volumen comprometido;
• personalización;
• monitorización;
• revisión humana;
• acuerdos de nivel de servicio.

Por eso, no conviene presentar un rango general de 50.000 a más de 600.000 dólares anuales como si fuera una tarifa pública comparable entre proveedores.

La misma cautela aplica a los rangos de precios observados en España. Un rango de 15 a 5.000 euros mensuales puede mezclar productos self-service, automatizaciones pequeñas, soluciones con límites de uso y proyectos empresariales a medida. Puede usarse como orientación comercial, pero no como benchmark representativo del mercado.

Palancas concretas para proteger el margen

Routing de modelos

No todas las peticiones necesitan el modelo más potente.

Podés utilizar modelos pequeños para:

• clasificaciones;
• extracción estructurada;
• respuestas rutinarias;
• detección de intención;
• validaciones simples.

Los modelos más capaces pueden reservarse para tareas complejas, decisiones ambiguas o casos que requieren razonamiento avanzado.

La clave no es simplemente “usar el modelo más barato”, sino enrutar cada tarea al modelo que consiga la calidad necesaria al menor coste total.

Caché de contexto

Los agentes suelen reutilizar partes estables del contexto: instrucciones del sistema, documentación, políticas o esquemas.

La caché puede reducir significativamente el coste de los tokens de entrada repetidos, pero el descuento depende del proveedor y del modelo. OpenAI documentó inicialmente un descuento del 50% para inputs cacheados en sus modelos compatibles. Algunos proveedores y modelos ofrecen descuentos mayores, incluso de hasta 90%, bajo condiciones específicas.[openai]

No conviene prometer “90% de ahorro” como regla universal. Hay que revisar:

• qué parte del prompt puede cachearse;
• cuánto dura la caché;
• cuál es el tamaño mínimo;
• qué eventos invalidan el prefijo;
• si existen costes de escritura;
• si el patrón real de tráfico produce suficientes coincidencias.

Batch y trabajo asíncrono

Las tareas que no necesitan respuesta inmediata pueden ejecutarse mediante procesamiento batch.

Ejemplos:

• enriquecimiento nocturno;
• clasificación masiva;
• scoring offline;
• generación de informes;
• procesamiento de documentos;
• reindexación de conocimiento.

Varios proveedores ofrecen descuentos de aproximadamente 50% para este tipo de trabajo, aunque las condiciones dependen de cada API y del tiempo de entrega aceptado. Anthropic, por ejemplo, documenta descuentos del 50% para su Batch API.[platform.claude]

Límites, alertas y franquicias

El cliente necesita previsibilidad. Una estructura razonable puede incluir:

• una franquicia de uso generosa;
• alertas antes de alcanzar el límite;
• límites configurables;
• aprobación para consumo extraordinario;
• precios marginales publicados;
• opción de contratar capacidad adicional.

El objetivo no es esconder el consumo, sino evitar que una tarea excepcional genere una factura imposible de anticipar.

Monitorización por workflow

No alcanza con medir el coste total de la API. Conviene medir:

• coste por tarea;
• coste por cliente;
• coste por resolución;
• tokens por flujo;
• pasos promedio;
• tasa de reintentos;
• escalados a humanos;
• margen bruto por plan;
• margen bruto por segmento.

Un dashboard de consumo debería permitir responder cuánto cuesta cada workflow y no solo cuánto gastó la cuenta del proveedor durante el mes.

Definí el éxito por escrito

En pricing basado en resultados, la definición vale más que la tarifa.

Un contrato debería especificar, por ejemplo:

• qué evento constituye una resolución;
• qué ocurre si el usuario abandona;
• qué ocurre si el caso se escala;
• si una reapertura genera un nuevo cargo;
• cómo se atribuyen resultados compartidos entre IA y humanos;
• qué sucede ante errores del sistema;
• qué datos puede auditar cada parte.

Cuanto más ambiguo sea el resultado, más probable es que aparezcan disputas comerciales.

Una buena métrica de éxito debería ser:

• observable;
• auditable;
• relevante para el cliente;
• difícil de manipular;
• suficientemente estable para presupuestar.

Una previsión sobre adopción

Gartner ha proyectado que el 40% de las aplicaciones empresariales incorporará agentes de IA específicos para tareas al final de 2026, frente a menos del 5% en 2025. La afirmación se refiere a aplicaciones, no al porcentaje de empresas que ya hayan desplegado agentes.[finance.yahoo][itbrief.com]

La previsión muestra la velocidad esperada de integración, pero no garantiza que todos esos agentes tengan autonomía amplia, que generen valor económico positivo o que utilicen el mismo modelo de pricing.

También conviene distinguir entre:

• una aplicación que incluye una función agentic;
• un agente que ejecuta un workflow limitado;
• un sistema multiagente con capacidad de actuar en varios sistemas;
• un producto cuyo precio depende directamente del resultado.

Son niveles de producto y de riesgo económico diferentes.

Del dilema al sistema

El pricing de un SaaS agentic no se resuelve copiando una tabla de precios.

Se resuelve diseñando el sistema completo:

• qué promete el producto;
• qué unidad de valor entiende el cliente;
• qué unidad de coste controla el proveedor;
• cuánto consumo se incluye;
• cómo se factura el exceso;
• cómo se define el éxito;
• qué riesgos absorbe cada parte;
• cómo se monitoriza el margen;
• cómo se actualiza el precio cuando cambian los modelos.

La estructura más resistente suele combinar una base predecible con una variable ligada al uso o al valor. La tarifa base sostiene la plataforma. La franquicia reduce la ansiedad del comprador. El consumo adicional captura el uso intensivo. Y el pricing por resultado puede reservarse para aquellos workflows donde el éxito sea realmente medible.

La AI al servicio de la humanidad también significa esto: cobrar por el valor real que entregás, con un sistema que sostenga el negocio en lugar de erosionarlo.

Si estás construyendo un negocio digital con IA y sentís que tenés tecnología, clientes por recomendación y muchas ideas, pero todavía no una estructura clara de monetización, ese es el punto de partida del trabajo estratégico.

En una Sesión de Estructura y Claridad ordenamos el modelo y definimos un plan concreto. El Diagnóstico de Expansión Digital permite evaluar la situación actual y elegir el camino de crecimiento. Y cuando la decisión es construir todo —marca, web, productos, ventas, contenido y automatización—, el Ecosistema Completo convierte el conocimiento en un negocio preparado para escalar.

Reservar sesión

Fuentes

• Why your AI product has SaaS pricing and utility-grade costs
• AI Is Eating Software Margins: How SaaS Companies Now Have to Price In the Token Tax
• Your AI Feature Is Quietly Destroying Your Gross Margin
• Agentic AI Pricing Models: Token, Task and Outcome-Based Pricing
• Technology Spotlight — Accounting for Outcome-Based Pricing in an Agentic AI Software Product
• Pricing Models for Agentic AI Services: A Multi-Sided Market Analysis
• The 2026 State of B2B SaaS and AI Monetization Report
• Salesforce introduces outcome-based pricing for Agentforce AI
• Salesforce Agentforce Pricing: The Full Cost Breakdown
• AI Agent Pricing Comparison 2026: Cost Guide
• From seats to consumption: Why SaaS pricing has entered its hybrid era
• 2025 SaaS Pricing Report: Usage-Based Models and More
• ¿Cuánto cuesta un agente IA para empresas en España? Guía de precios 2026
• SaaS Pricing Is Breaking: Why Per-Seat Models Don’t Survive the AI Agent Era