Por qué las empresas tienen dificultades para fijar precios para la IA

Google News destacó un informe de la BBC del 4 de agosto que refleja un conflicto creciente en la inteligencia artificial: las empresas aún no pueden decidir cuánto vale un producto de IA.

Esta incertidumbre afecta ahora a los desarrolladores de modelos, proveedores de software, compradores empresariales y equipos financieros que aprueban los despliegues. La IA puede venderse por usuario, token, acción, conversación, capacidad o resultado empresarial. Cada opción distribuye los costes y el riesgo de forma diferente.

El problema se volvió más difícil a medida que la IA fue más allá del chat. OpenAI y Anthropic popularizaron el acceso basado en tokens, mientras que Microsoft y Salesforce incorporaron agentes al software empresarial consolidado. Los agentes pueden ejecutar varias llamadas al modelo, buscar datos de la empresa, usar herramientas y revisar su propio trabajo antes de completar una solicitud.

Los precios tradicionales del software parten de la premisa de que añadir otro usuario genera poco coste operativo adicional. La IA rompe esa premisa porque cada respuesta generada consume recursos informáticos. Los sistemas basados en agentes amplían el desajuste al realizar una cantidad impredecible de trabajo por cada tarea.

El resultado es una pugna entre suscripciones previsibles y consumo variable. Los proveedores necesitan ingresos que sigan sus costes informáticos. Los clientes necesitan facturas que puedan prever y un valor que puedan justificar. Ninguna de las partes quiere absorber toda la incertidumbre.

La noticia de Google News apunta a un mercado que aún prueba su modelo de negocio

El cambio importante no es un precio nuevo. Es el abandono del sector de una única forma fiable de vender software.

Las empresas de software pasaron décadas haciendo que las suscripciones fueran fáciles de entender. Una empresa contaba a sus empleados, elegía funciones y negociaba un contrato. El uso podía variar sin que la factura cambiara de forma drástica.

La IA generativa introdujo un vínculo directo entre la actividad del cliente y el gasto del proveedor. Un token, la pequeña unidad utilizada para procesar y generar texto, representa trabajo realizado por un modelo. Las indicaciones más largas, los documentos más extensos, un razonamiento más profundo y las llamadas repetidas a herramientas aumentan el consumo.

Ese sistema parece preciso, pero la precisión no garantiza claridad. La mayoría de los empleados no sabe cuántos tokens requiere una tarea. Un equipo de compras no puede traducir fácilmente los tokens en informes terminados, casos resueltos o decisiones de producto más rápidas.

El desafío crece cuando un agente se encarga de la tarea. Un chatbot normal puede responder una vez. Un agente puede planificar, recuperar registros, llamar a sistemas externos, evaluar un resultado y volver a intentarlo. Por tanto, una solicitud visible puede generar muchas operaciones ocultas del modelo.

Las opciones empresariales de OpenAI ilustran esta distinción. Su modelo de capacidad permite a los clientes de la API reservar capacidad de procesamiento de tokens para una instantánea concreta del modelo. Esto ayuda a gestionar la disponibilidad, pero los compradores aún deben estimar cuánta capacidad necesitan sus aplicaciones.

Microsoft utiliza otra capa de abstracción. Algunas capacidades de Copilot y de agentes seleccionadas usan facturación por consumo, mientras que la capacidad prepagada sigue disponible para ciertos despliegues. Su documentación indica que los modelos de razonamiento pueden activar más de un medidor de facturación durante una sola interacción.

Estos enfoques no son intrínsecamente injustos. Reflejan un servicio con costes de producción variables. Sin embargo, trasladan el trabajo de previsión a los clientes antes de que estos comprendan plenamente su uso futuro.

El titular de la BBC que circula a través de Google News importa porque describe un problema estructural, no un ciclo temporal de promociones. Los proveedores de IA están probando cómo conectar el coste informático, el valor para el cliente y contratos comprensibles. Esos tres elementos rara vez avanzan al mismo ritmo.

Un modelo más barato puede reducir el coste de una llamada. No hace automáticamente previsible un flujo de trabajo de varios pasos. Un agente eficiente puede completar el trabajo con menos llamadas, mientras que uno mal diseñado puede consumir más recursos sin producir una respuesta mejor.

Por tanto, la fijación de precios se convierte en una cuestión de diseño de producto. El medidor influye en cómo los desarrolladores construyen flujos de trabajo, con qué frecuencia los usuarios dependen de ellos y si los directivos permiten operaciones autónomas. También determina qué fallos resultan económicamente dolorosos.

Una suscripción fija fomenta la experimentación, pero expone al proveedor a los usuarios intensivos. La facturación por tokens protege al proveedor, pero puede desalentar la adopción. La facturación por resultados parece alineada con el valor, aunque exige que ambas partes acuerden qué significa el éxito.

Ningún modelo elimina el riesgo. Solo decide quién lo asume.

El software basado en licencias por usuario choca con los costes variables de la IA

Los proveedores de IA quieren la simplicidad de las suscripciones, pero la economía de la inferencia sigue empujándolos hacia la facturación por consumo.

Los precios por licencia cobran por cada usuario autorizado. Funcionan bien cuando el software sirve como una herramienta que los empleados operan directamente. Un cliente puede estimar el gasto contando usuarios, mientras que el proveedor se beneficia de ingresos recurrentes.

Los agentes de IA complican esa lógica porque pueden realizar trabajo sin intervención humana continua. Un empleado podría iniciar un agente que completa una sola consulta. Otro podría poner en marcha un flujo de trabajo que revisa cientos de documentos y modifica su resultado varias veces.

Cobrar lo mismo a ambos usuarios puede separar los ingresos del coste operativo. También separa el precio del trabajo entregado. El cliente que ejecuta la carga de trabajo mayor recibe más servicio aunque ambas licencias parezcan idénticas.

El modelo opuesto cobra por consumo. Los proveedores pueden medir tokens, mensajes, llamadas al modelo, acciones o capacidad de procesamiento. Así, los ingresos siguen más de cerca la actividad técnica.

La guía de facturación de agentes de Microsoft muestra cuán detallado puede llegar a ser esto. Las distintas funciones de los agentes consumen cantidades diferentes, y los modelos con capacidad de razonamiento pueden activar medidores separados. Tal nivel de detalle ayuda a recuperar costes, pero hace que los presupuestos dependan del comportamiento de los flujos de trabajo.

Los clientes pueden supervisar el uso, establecer límites y optimizar las indicaciones. Estos controles ayudan después del despliegue. No resuelven la cuestión previa de cuánto consumirá a escala un flujo de trabajo no probado.

Esto es especialmente difícil en el trabajo basado en conocimiento. Una tarea repetitiva de clasificación tiene entradas y salidas relativamente estables. La investigación, la programación, el análisis de contratos y la atención al cliente contienen excepciones que llevan a un agente por rutas más largas.

Un agente de soporte podría resolver una solicitud conocida con una sola recuperación de información. Un problema de cuenta poco común podría requerir varias consultas a bases de datos, comprobaciones de políticas y transferencias. La facturación basada en la actividad capta esa diferencia, pero el cliente paga más precisamente cuando el sistema se enfrenta a casos difíciles.

Eso puede generar un incentivo perjudicial. Un proveedor puede ganar más cuando un agente trabaja de forma ineficiente, mientras que el cliente asume el coste adicional. El proveedor puede contrarrestar esta preocupación con registros transparentes, objetivos de eficiencia y controles de gasto. Aun así, la confianza pasa a formar parte del acuerdo comercial.

Las suscripciones fijas invierten el incentivo. El proveedor se beneficia cuando los modelos y flujos de trabajo se vuelven más eficientes porque los ingresos permanecen estables mientras cae el gasto informático. Sin embargo, el acceso ilimitado genera exposición cuando los usuarios automatizan trabajos grandes o ejecutan agentes de forma continua.

Los precios híbridos intentan repartir el riesgo. Una empresa podría incluir el uso habitual dentro de una licencia y cobrar por separado las acciones avanzadas o el mayor consumo. Esto conserva un punto de entrada conocido al tiempo que limita los costes abiertos del proveedor.

Las estructuras híbridas traen su propia complejidad. Los compradores deben entender qué actividades están incluidas y cuáles activan un nuevo medidor. Si el límite aparece solo después del despliegue, una suscripción sencilla se convierte en un contrato variable imprevisible.

El conflicto presiona más a las empresas de software consolidadas. Acostumbraron a los clientes a esperar contratos estables por usuario. Ahora deben introducir facturación variable sin hacer que sus productos parezcan infraestructura en la nube desconocida.

Los proveedores de modelos enfrentan un problema diferente. Su unidad de producción es más fácil de medir, pero sus servicios compiten cada vez más con modelos más baratos. Los clientes pueden dirigir las tareas sencillas a sistemas más pequeños y reservar los modelos prémium para el trabajo exigente.

Ese enrutamiento debilita la capacidad de un proveedor para cobrar una prima generalizada. También vuelve más importante la capa de aplicación porque la orquestación determina qué modelo realiza cada tarea.

Por tanto, el informe de Google News no trata solo de elegir una cifra. Las empresas deben decidir si venden acceso, capacidad informática, trabajo o un resultado. La respuesta cambia el medidor, la relación con el cliente y el producto mismo.

Los precios por resultados de IA parecen justos hasta que alguien define el éxito

En teoría, los precios basados en resultados alinean el pago con el valor, pero la atribución convierte la aparente solución en otra negociación.

Un modelo basado en resultados cobra cuando el sistema produce un resultado acordado. Un proveedor de atención al cliente podría vincular la facturación a conversaciones resueltas. Un producto de ventas podría usar trabajo completado u otro evento verificado.

Este enfoque resulta atractivo de inmediato. Los clientes no quieren comprar tokens por sí mismos. Quieren menos solicitudes sin resolver, análisis más rápidos, mejor servicio o procesos empresariales completados.

Los proveedores también obtienen una narrativa de valor más clara. En lugar de defender una unidad informática invisible, pueden vincular el pago a algo que un directivo ya mide.

Salesforce ofrece ahora varias estructuras de Agentforce en lugar de una respuesta universal. Sus opciones de Agentforce incluyen facturación basada en conversaciones y un sistema flexible de créditos. Salesforce introdujo este último después de que su enfoque inicial resultara insuficiente para todos los flujos de trabajo.

Esa evolución demuestra por qué los precios por resultados se vuelven difíciles. Una conversación puede ser corta o larga. Una acción puede ser trivial o importante. Una resolución puede derivarse del agente, del esfuerzo del propio cliente, de un empleado humano o de varios sistemas que trabajan juntos.

Las partes primero deben definir el evento facturable. Después necesitan reglas para solicitudes duplicadas, casos reabiertos, finalizaciones parciales, abandono por parte del cliente, intervención humana y resultados incorrectos.

La calidad añade otra capa. Un agente podría cerrar un caso de soporte dejando insatisfecho al cliente. Podría clasificar un contacto como cualificado sin generar ingresos. Podría redactar un contrato que ahorre tiempo pero que aún requiera una extensa revisión legal.

Si la facturación sigue el primer evento visible de finalización, el proveedor puede optimizar para el cierre en lugar de para un valor duradero. Si el pago depende de un resultado empresarial posterior, factores externos pueden eclipsar la contribución del agente.

Los precios por resultados también cambian la rendición de cuentas. Un proveedor que acepta pagos solo por éxito parece asumir más riesgo de rendimiento. En la práctica, los contratos pueden restringir la definición de éxito, excluir casos inciertos o exigir a los clientes que mantengan determinados datos y procesos.

Esas condiciones pueden ser razonables. Un agente no puede ofrecer resultados fiables a partir de registros incompletos, políticas contradictorias o sistemas inaccesibles. Aun así, cada condición debilita la afirmación de que el precio simplemente sigue al valor.

Un comprador independiente debe preguntar quién controla los datos del resultado. Cuando el proveedor define el medidor, opera el agente e informa del éxito, los clientes necesitan auditabilidad. Deberían poder inspeccionar el evento que activó la facturación e impugnar clasificaciones incorrectas.

Una segunda cuestión se refiere a la optimización. ¿El agente se detiene cuando alcanza el umbral facturable o cuando alcanza el objetivo real del cliente? Esos dos momentos no siempre son idénticos.

Una tercera cuestión se refiere al fracaso. Un agente puede consumir recursos informáticos considerables sin completar una tarea. Bajo una tarificación por resultados, el proveedor absorbe ese coste directo. La respuesta probable es restringir los flujos de trabajo difíciles, incorporar la incertidumbre al precio del contrato o derivar los casos dudosos a personas.

Esto significa que la facturación por resultados no elimina el coste técnico. Oculta ese coste tras un evento comercial y traslada el riesgo a las reglas de elegibilidad.

En flujos de trabajo bien definidos y de gran volumen, el modelo puede funcionar. Ambas partes pueden medir el evento, examinar las excepciones y estimar la frecuencia. El acuerdo se vuelve más difícil para el trabajo de conocimiento abierto, donde la calidad es subjetiva.

Un informe de investigación, una estrategia de producto o un diseño de software rara vez tienen un único punto binario de éxito. Su valor surge más tarde a través de decisiones humanas. Cobrar por resultado exigiría un juicio controvertido sobre la calidad o el impacto.

Esa limitación mantiene vigentes la tarificación por uso y por puesto. Pueden ser imperfectas, pero miden elementos observables. Los modelos por resultados funcionan mejor cuando el resultado es igualmente observable y atribuible.

Los modelos más baratos aumentan la presión sin resolver la brecha de previsión

La competencia puede reducir el coste de la inteligencia, pero unos costes unitarios más bajos no hacen predecibles las cargas de trabajo autónomas.

Los modelos abiertos y los sistemas especializados más pequeños dan a las empresas mayor poder de negociación. Un equipo de desarrollo puede usar un modelo prémium para razonamientos complejos y, después, dirigir la clasificación o extracción rutinaria a una opción menos costosa.

Este enfoque multimodelo reduce la dependencia de un único proveedor. También convierte la selección de modelos en una decisión operativa, en lugar de un compromiso permanente.

Este cambio presiona a OpenAI, Anthropic, Google, Microsoft y otros proveedores para que justifiquen los servicios prémium. El liderazgo en benchmarks brutos importa menos cuando un modelo más pequeño completa de forma fiable la tarea real del cliente.

IDC sostiene que la competencia de la IA se está desplazando hacia resultados medibles. Su análisis de resultados afirma que la preparación operativa sigue siendo una restricción importante cuando las empresas tienen dificultades para trasladar los pilotos a los flujos de trabajo centrales.

Esa distinción es crucial. Una tarifa por token más baja solo ayuda si la carga de trabajo, el prompt, el sistema de recuperación y las llamadas a herramientas siguen siendo eficaces. Una respuesta barata que exige correcciones repetidas puede costar más que un primer intento sólido.

El diseño del agente determina gran parte de la factura final. Los desarrolladores eligen cuánto contexto proporcionar, cuándo recuperar documentos, qué herramientas llamar y cuántos reintentos permitir. También deciden si una tarea necesita un modelo avanzado de razonamiento.

El almacenamiento en caché de prompts ofrece un ejemplo de ahorro arquitectónico. Permite que una aplicación reutilice contenido de prompts procesado previamente, en lugar de volver a calcular el mismo material. La documentación de caché de OpenAI describe cómo los prefijos de prompts repetidos pueden recibir un tratamiento distinto al de la entrada no almacenada en caché.

La caché ayuda cuando una aplicación envía repetidamente instrucciones estables o material de referencia. Ayuda menos cuando cada tarea utiliza registros distintos o requiere contexto nuevo.

La recuperación puede reducir la cantidad de información enviada a un modelo, pero una mala recuperación genera otros costes. Si el sistema selecciona documentos irrelevantes, el modelo puede producir una respuesta débil o necesitar otro intento.

La revisión humana también debe entrar en el cálculo. Un sistema de IA puede parecer económico en la capa de API mientras desplaza el trabajo de verificación a los empleados. Una medida útil del coste incluye configuración, supervisión, corrección, seguridad y gobernanza.

Por eso las comparaciones basadas únicamente en tokens pueden inducir a error a los compradores. Los tokens son una medida de producción, no una medida completa del trabajo útil.

El mismo problema afecta a las comparaciones de suscripciones. Un plan nominalmente ilimitado puede incluir límites de tasa, restricciones de modelos o políticas que cambian lo que reciben los usuarios intensivos. Las empresas necesitan garantías de servicio y pruebas de carga de trabajo, no solo una etiqueta de plan.

La cobertura de Google News ha reflejado cada vez más esta tensión entre la caída de los costes de los modelos y el aumento del uso agregado. A medida que los agentes realizan tareas más largas, las mejoras de eficiencia pueden impulsar más consumo. Un menor coste por paso no garantiza un menor gasto total.

Este patrón se asemeja a la computación en la nube. El almacenamiento y el procesamiento más baratos ampliaron lo que las empresas construían, mientras que las facturas globales de la nube seguían requiriendo una gestión activa. La IA introduce incertidumbre adicional porque el comportamiento de los modelos y la duración de los flujos de trabajo son probabilísticos.

Un programa determinista sigue una secuencia definida. Un agente puede elegir rutas diferentes para solicitudes similares. Esa flexibilidad crea valor, pero también complica la planificación de capacidad.

Las empresas pueden responder con presupuestos por tarea. Un agente recibe un número máximo de pasos, llamadas a herramientas o tokens. Debe detenerse, pedir aprobación o transferir el trabajo a una persona cuando alcanza el límite.

También pueden enrutar tareas según su complejidad. Un modelo ligero gestiona el trabajo ordinario, mientras que un sistema más capaz recibe solo los casos difíciles. Los datos de evaluación deben determinar esas reglas de enrutamiento.

Para el trabajo intensivo en conocimiento, mantener un contexto fiable es igual de importante. Un flujo de trabajo de conocimiento bien organizado puede reducir búsquedas innecesarias y el procesamiento repetido de documentos. Sin embargo, la calidad de la información sigue requiriendo pruebas dentro de la aplicación real.

El resultado competitivo no pertenecerá automáticamente al modelo más barato. Favorecerá a los sistemas que traduzcan costes variables de inteligencia en trabajo controlado y fiable.

Lo que las métricas de precios de IA todavía no muestran

Todos los modelos de precios actuales dejan fuera una parte de la cadena de valor, por lo que los compradores deberían desconfiar de las afirmaciones de que una sola métrica alinea por completo los incentivos.

La tarificación por tokens mide la actividad del modelo. No mide si la respuesta es precisa, útil o necesaria. Una aplicación puede consumir menos tokens y aun así fallar en su tarea.

La tarificación por puesto mide el acceso autorizado. No revela cuánto trabajo realiza el sistema ni si los empleados lo adoptan. Una empresa puede conceder licencias a muchos usuarios y recibir poco valor operativo.

La tarificación por acción mide los pasos realizados. Puede recompensar a un sistema por hacer más trabajo, incluso cuando una ruta más corta sería mejor. La definición de una acción también puede variar entre productos.

La tarificación por conversación crea una unidad reconocible de atención al cliente. Sin embargo, las conversaciones difieren en duración, complejidad y resultado. Un caso reabierto puede poner de manifiesto la ambigüedad sobre si la interacción original tuvo éxito.

La tarificación por resultados mide un resultado declarado. Tiene dificultades con la atribución, la calidad, los efectos diferidos y los factores externos. También invita a desacuerdos sobre quién controla la medición.

Ninguna métrica lo capta todo. Por tanto, un comprador necesita un conjunto de medidas técnicas y comerciales.

La parte técnica debe incluir el consumo por flujo de trabajo, modelo, entorno y tipo de tarea. Los equipos necesitan tasas de fallos, recuentos de reintentos, latencia, llamadas a herramientas y escalamiento a humanos.

La parte comercial debe incluir calidad de finalización, tiempo ahorrado, adopción, respuesta del cliente y coste de supervisión. Estas medidas deberían conectarse con una línea de base definida antes de la implementación de IA.

Sin una línea de base, tanto proveedores como clientes pueden afirmar que han tenido éxito. El proveedor apunta a la actividad. El cliente señala que los resultados empresariales no han cambiado. Ninguno puede establecer qué mejoró realmente el sistema.

Un piloto controlado debería responder a algo más que si el agente puede realizar una tarea. Debe mostrar la distribución del consumo entre casos fáciles y difíciles.

Los promedios ocultan variaciones peligrosas. Un agente podría ser económico en la mayoría de las solicitudes, pero extremadamente caro en un pequeño grupo de excepciones. Esas excepciones pueden dominar el gasto total tras la implementación.

Los compradores también deben probar entradas adversariales y malformadas. Un agente que entra en un bucle, llama repetidamente a una herramienta o procesa documentos inesperadamente grandes puede consumir recursos sin aportar valor.

Los límites de gasto son esenciales, pero los límites indiscriminados pueden interrumpir procesos empresariales. Los equipos deberían combinar límites globales con controles y alertas específicos para cada flujo de trabajo.

La gobernanza importa porque los empleados a menudo no tienen visibilidad del efecto comercial de sus acciones. Un usuario ve un botón. El sistema detrás de él podría invocar varios modelos y servicios empresariales.

Las interfaces claras deberían indicar cuándo una tarea utiliza razonamiento prémium, contexto amplio o un flujo de trabajo autónomo. El objetivo no es cargar a cada usuario con contabilidad de tokens. Es ayudarles a comprender las decisiones con consecuencias.

Los proveedores deberían exponer datos de facturación al nivel sobre el que los clientes pueden actuar. Un total mensual no basta. Los equipos necesitan identificar qué agente, flujo de trabajo o función provocó un cambio.

Los clientes también deberían resistirse a la falsa precisión. Un sistema detallado de créditos puede parecer transparente y, aun así, seguir siendo difícil de vincular con la actividad informática real. Los créditos ayudan a empaquetar la complejidad técnica, pero solo si sus reglas de conversión permanecen estables y documentadas.

La visión escéptica es que la tarificación de la IA seguirá sin asentarse porque los productos subyacentes siguen sin asentarse. Las capacidades de los modelos cambian, los métodos de inferencia mejoran y los agentes asumen nuevas tareas. Una métrica duradera no puede surgir fácilmente mientras la unidad de valor sigue cambiando.

Eso no hace imposible la adopción empresarial. Significa que los contratos deberían preservar la flexibilidad. Los compradores necesitan la capacidad de supervisar el consumo, cambiar de modelos, revisar límites y reconsiderar los precios a medida que maduran los flujos de trabajo.

Mientras tanto, los proveedores deben evitar usar la complejidad como cobertura. Si los clientes reciben repetidamente facturas sorpresa o no pueden explicar los cargos internamente, la adopción se ralentizará independientemente de la calidad del modelo.

La confianza dependerá de si una empresa puede predecir el gasto antes de escalar y conciliarlo después.

Tres señales mostrarán hacia dónde se dirige la tarificación de IA

El modelo de precios ganador será el que haga predecibles los costes de los agentes sin desconectar el pago del trabajo útil.

La primera señal es si los principales proveedores de software simplifican sus métricas tras implementaciones empresariales reales. Salesforce ya ofrece opciones por usuario, por conversación y de consumo flexible. Microsoft combina licencias, capacidad prepagada y estructuras de pago por uso en sus productos de agentes.

Más opciones pueden respaldar distintas cargas de trabajo. También pueden indicar que los proveedores no han encontrado una unidad de valor estable.

Observe si esas empresas consolidan sus opciones o añaden más distinciones. La consolidación sugeriría que compradores y proveedores han identificado patrones repetibles. Más capas demostrarían que el comportamiento de los agentes sigue siendo demasiado variado para un contrato común.

La segunda señal es la calidad de los controles de uso. Los paneles de facturación deberían pasar de los informes mensuales a la previsión a nivel de flujo de trabajo, la detección automática de anomalías y los presupuestos de tareas exigibles.

Esto importa más que otra reducción nominal de precio. Un equipo financiero puede gestionar un servicio relativamente caro cuando el gasto es explicable. Dudará ante un servicio más barato con una exposición impredecible.

Mejores controles reforzarían la tarificación por consumo. Los clientes pueden aceptar facturas variables cuando pueden rastrear, prever y limitar la actividad. Los controles débiles harían que los compradores regresaran a suscripciones fijas o pilotos de alcance muy limitado.

La tercera señal es si la tarificación por resultados sobrevive al contacto con procesos empresariales complejos. La atención al cliente ofrece una de las pruebas más claras porque las conversaciones, resoluciones, reaperturas y escalaciones pueden registrarse.

Si proveedores y clientes acuerdan definiciones duraderas, auditan las disputas de forma eficiente y preservan la calidad del servicio, la facturación por resultados puede expandirse a otros flujos de trabajo estructurados.

Si los contratos acumulan exclusiones y los compradores cuestionan qué cuenta como éxito, la tarificación por resultados seguirá siendo una opción selectiva en lugar de la predeterminada.

El análisis independiente de las implementaciones empresariales será más útil que los anuncios de los proveedores. Los compradores deberían buscar pruebas que cubran el coste operativo total, no solo el consumo de modelos. Eso incluye integración, supervisión, revisión humana y trabajo fallido.

La próxima generación de productos de agentes probablemente admitirá varios modelos comerciales. La asistencia habitual a los empleados puede encajar en una licencia por usuario. La automatización de gran volumen puede usar consumo medido. Los flujos de trabajo específicos con resultados verificables pueden admitir facturación por resultados.

Ese futuro mixto es menos elegante que una respuesta universal. También es más realista, porque los productos de IA realizan distintos tipos de trabajo.

Para los desarrolladores, la arquitectura de precios ya forma parte del diseño de sistemas. El enrutamiento de modelos, el almacenamiento en caché, la gestión del contexto, las políticas de reintento y los controles de aprobación afectan al producto comercial.

Para los compradores empresariales, la adquisición ya no puede concluir antes de que comience la implementación. Las condiciones contractuales deben reflejar el comportamiento observado de las cargas de trabajo, y los equipos técnicos necesitan acceso a los datos de facturación.

Para los trabajadores del conocimiento, la cuestión no es si cada prompt tiene un cargo visible. Es si las organizaciones restringen herramientas útiles después de que aparezca un consumo inesperado.

Google News ha puesto de relieve una auténtica línea de fractura en la economía de la IA. Los proveedores venden software cuyos costes operativos se parecen a los de la infraestructura y cuyo valor prometido se parece al trabajo humano. Ningún modelo tradicional de precios encaja limpiamente.

La pregunta decisiva es práctica: ¿puede su organización vincular cada carga de trabajo de IA a un coste controlado y un resultado medible? Hasta que los proveedores faciliten esa respuesta, el enfoque más seguro es una implementación limitada, una medición transparente y la expansión solo después de que la economía resista el uso real.