Cómo las aplicaciones de IA se ganan su prima de precio: ejecución, contexto y prueba de valor

El artículo, publicado en el boletín de a16z y firmado por Tugce Erten, parte de una tensión que afecta a las empresas de aplicaciones de IA. La bajada de los costes de inferencia puede mejorar sus márgenes, pero los modelos más capaces y las herramientas de desarrollo más sencillas también hacen que partes de una aplicación sean más fáciles de sustituir. La pregunta comercial es qué seguirán pagando los clientes a medida que mejoran sus alternativas. Según el texto, la exposición varía por producto: una aplicación es vulnerable cuando el cliente puede reproducir su resultado principal con un modelo de propósito general y poco esfuerzo continuo.

La autora sostiene que el precio siempre importa, pero ahora más, y que las startups de rápido crecimiento a veces lo posponen. Propone que todas desarrollen y pongan precio a cuatro capacidades que llama obvias pero necesarias: experiencia de dominio, integraciones profundas, ejecución fiable y contexto difícil de obtener. Los fundadores deben entender qué ventajas valoran realmente sus clientes, reforzarlas y cobrarlas.

Como ejemplo de la prueba de «construir o comprar», el texto relata el caso del equipo jurídico de Repsol. En una evaluación a ciegas comparó Harvey con Microsoft Copilot y con su propio prototipo interno, Lexia. Según el artículo, Harvey dio la mejor calidad y superó a las alternativas en precisión y ahorro de tiempo durante un piloto de ocho semanas con 50 abogados de 12 jurisdicciones. Repsol pasó a un despliegue completo. Harvey afirma que los abogados ahorran ahora entre cuatro y seis horas por semana y que la adopción alcanza el 96% del departamento jurídico. El equipo también usó la herramienta para identificar objeciones recurrentes en acuerdos pasados y mejorar sus plantillas con cláusulas alternativas. Un comentario de lector señala con acierto que no queda claro si esas horas ahorradas descuentan el tiempo de revisión de las ediciones de la herramienta. Son cifras que reporta el propio proveedor.

De este y otros casos se extraen tres reglas: operar el flujo de trabajo mejor que el cliente, hacer que el contexto sea más barato de alquilar que de reconstruir, y demostrar el valor para luego fijar el precio que lo capture.

Primera regla: operar el flujo mejor que el cliente. Para debilitar el poder de fijación de precios, un cliente no necesita reconstruir toda la aplicación; basta con internalizar una tarea de alto volumen o con tener una alternativa creíble. Un comprador de una firma global de servicios profesionales explicó que, si un prompt directo a un modelo de frontera producía un mejor resultado que la herramienta de un proveedor, no veía motivo para pagar la prima de la plataforma. Esa firma había construido una plataforma interna de IA capaz de ejecutar modelos en local o en instalaciones propias cuando los clientes no aceptaban productos de terceros, y experimentaba con código abierto. Para defender la prima, el proveedor debe superar la alternativa del cliente en todo el flujo: en la revisión de contratos, eso implica aplicar los estándares legales de la empresa, mantener la coherencia de las ediciones en el documento y conservar el contexto mientras evoluciona la negociación.

Como muestra, el artículo describe la función Playbook Review de Harvey: un agente principal reparte la revisión entre agentes especializados, concilia ediciones contradictorias y comprueba el documento terminado. Harvey evalúa el rendimiento con rúbricas jurídicas y elige modelos según calidad, velocidad y coste para cada tarea. El sistema conserva el contexto de la revisión para que las solicitudes posteriores aprovechen el trabajo previo. Harvey describe además la oportunidad de aprender de las modificaciones que los abogados aceptan, editan o rechazan, de modo que las futuras revisiones necesiten menos guía. Cuando ese aprendizaje mejora el siguiente resultado, la ventaja puede acumularse con el uso. Para los fundadores, la recomendación es comparar el flujo más expuesto con la mejor alternativa creíble del cliente, incluyendo implementación, revisión humana, fallos y mantenimiento, e identificar qué mejora con cada uso.

Segunda regla: hacer el contexto más barato de alquilar que de reconstruir. El contexto puede justificar una prima por acceso exclusivo, por preparación útil, o por ambos. Las observaciones privadas que el cliente no puede obtener en otro sitio tienen valor propio; para la información accesible, la ventaja depende del coste de hacerla precisa, actual y utilizable. Un proveedor de software vertical con el que habló la autora había acumulado durante años referencias de precios propias de unas 3.000 empresas y exploraba ofrecerlas mediante un servidor del Protocolo de Contexto de Modelos (MCP) para que los sistemas de IA las consulten directamente. La lógica económica es que el proveedor recopila, organiza, valida y mantiene la información una sola vez y reparte el coste entre muchos clientes, que alquilan contexto fiable por menos de lo que costaría reconstruirlo. Lo mismo podría aplicarse a información del propio cliente (políticas, registros de CRM, contratos, historial de flujos): puede ser suya, pero prepararla para un uso fiable exige permisos, normalización, recuperación y validación continua. La recomendación es identificar si el cliente paga por el acceso, por la preparación o por ambos, y comparar el precio con el esfuerzo de ingeniería, validación y mantenimiento que se le ahorra.

Tercera regla: demostrar el valor y después fijar el precio para capturarlo. El artículo cita una encuesta de a16z de agosto de 2026 a 100 responsables de decisión de empresas sobre LLM: el 94% esperaba que el gasto total en LLM aumentara y el 37% que, al menos, se duplicara en el próximo año. Con más gasto, los clientes necesitan ver qué obtienen: cuánto trabajo se hace, con qué calidad y a qué coste total frente a sus alternativas.

La propuesta es partir de una unidad que el cliente reconozca (un contrato revisado, una conversación de soporte resuelta, una tarea de investigación completada, un registro enriquecido) y medir su coste completo de entrega: recuperación de información, llamadas a modelos, herramientas, reintentos, evaluación y revisión humana, incluyendo los intentos fallidos al calcular el coste por unidad completada con éxito. Después hay que mostrar cuánto vale ese trabajo, comparando precio, implementación, supervisión y trabajo humano residual con el coste y la calidad del proceso sustituido, y, si construir internamente es una opción creíble, con sus costes de desarrollo y mantenimiento.

Como ejemplo, el texto cita el caso de Decagon con Notion: Notion valoró construir internamente, pero eligió una solución externa para que sus equipos se centraran en la plataforma principal, tras evaluar calidad, integraciones, seguridad y relación con el proveedor. El caso publicado informa de una mejora de hasta el 34% en el tiempo de resolución de tickets.

En cuanto al modelo de precios, la autora remite a un texto anterior suyo y de Sarah Wang, «You Are Not a Model. Don’t Price per Token», cuyo argumento es que las aplicaciones deben cobrar en la capa de valor más alta que puedan medir, atribuir y defender de forma fiable. El trabajo reconocible puede cobrarse directamente o empaquetarse en créditos, que son una moneda y no una métrica de valor, y deben corresponder a tareas o niveles de esfuerzo que el cliente pueda planificar. La previsibilidad debe resistir además la economía de cargas reales: según el memorando de precios de Clay, los precios fijos de IA cobraban de más las cargas simples y volvían inviables las complejas. Clay separó los Data Credits de las Actions para la orquestación, mantuvo créditos fijos para cargas de IA más acotadas y repercutió el coste real de tokens, sin margen, en los modelos de razonamiento más variables. Cuando el precio está ligado a trabajo reconocible, el proveedor puede usar enrutamiento, caché o mejores modelos para mejorar márgenes, bajar precios o incluir más trabajo, y los clientes comparten las ganancias sin seguir cada cambio en la mezcla de modelos.

La conclusión es que la prima se debe seguir ganando. La prueba es si comprar la aplicación ofrece una mejor combinación de coste total, calidad, velocidad y riesgo que la mejor alternativa creíble del cliente, incluyendo el esfuerzo de implementar, operar y mantener cada opción. Ejecución, contexto, prueba y precio refuerzan juntos el argumento de compra. Como el progreso de los modelos mejora continuamente la alternativa del cliente, la ventaja del proveedor debe ampliarse más rápido para seguir justificando la prima.

Nota del editor: el texto procede de una firma de capital riesgo (a16z) con intereses en empresas del sector, y varias de las cifras de casos (Harvey, Decagon) proceden de los propios proveedores o de casos publicados por ellos.