Las empresas de IA se enfrentan a problemas de medición y facturación para los que la mayoría de las plataformas de facturación SaaS no fueron diseñadas. Los modelos de precios son conocidos (basados en el uso, con tarifas por tramos y recargos por exceso de consumo), pero los requisitos operativos no lo son. Miles de millones de transacciones de tokens al mes, generación de eventos a nivel de milisegundos, asimetría entre entradas y salidas que no encaja en una tabla de tarifas de una sola variable y precios que evolucionan a medida que cambian las capacidades de los modelos. No se trata de casos excepcionales, sino de requisitos básicos para cualquier empresa que comercialice IA.
Este artículo está dirigido a los ingenieros de ingresos y a los equipos de operaciones de facturación de las empresas de IA que están buscando la forma de medir con precisión el uso de tokens, implementar una política de precios con múltiples variables sin necesidad de código personalizado y ampliar la infraestructura de facturación a medida que crece el negocio.
Los retos específicos en materia de medición a los que se enfrentan las empresas de inteligencia artificial
Volumen y velocidad de los eventos
Una sola llamada a la API de un modelo de lenguaje de gran tamaño genera, como mínimo, dos eventos facturables: los tokens de entrada y los tokens de salida. Una plataforma que procesa 100 000 llamadas a la API por hora genera más de 200 000 eventos de facturación por hora. A gran escala, esto supone miles de millones de eventos al mes, un volumen que la mayoría de los sistemas de facturación SaaS no estaban diseñados para gestionar en tiempo real.
El problema del volumen se agrava con la latencia. Las API de IA se utilizan en aplicaciones en tiempo real, en las que los clientes esperan que su uso se refleje de forma inmediata. Un panel de control de facturación con un retraso de tres horas respecto al consumo real no es aceptable cuando se desarrollan productos en los que el coste de las API es una métrica operativa fundamental. La medición en tiempo real de grandes volúmenes requiere una capa de mediación diseñada para el rendimiento, y no una que procese por lotes cada pocas horas.
Asimetría en los precios de insumos y productos»
Todas las principales API de IA aplican tarifas diferentes a los tokens de entrada y a los de salida. La proporción entre tokens de entrada y de salida varía enormemente según el caso de uso: una tarea de resumen genera muchos tokens de salida; una tarea de clasificación, muchos tokens de entrada; y una tarea de generación de código produce tokens de salida en proporciones impredecibles en relación con la indicación.
Esto significa que no es posible predecir con precisión la factura de un cliente basándose únicamente en su recuento total de tokens. Se necesita el desglose de entradas y salidas de cada llamada a la API, con una tarifa aplicada por separado. Un sistema de facturación que solo admita una tarifa de una sola variable («cargo por token») no puede implementar esto correctamente. Se necesita una tarifa basada en fórmulas: (tokens_de_entrada × tarifa_de_entrada) + (tokens_de_salida × tarifa_de_salida), aplicada por solicitud.
Versiones de modelos y precios diferenciados
GPT-4 y GPT-3.5 tienen tarifas diferentes. Un modelo optimizado tiene tarifas diferentes a las del modelo básico. Un trabajo de inferencia por lotes tiene tarifas diferentes a las de una llamada de inferencia en tiempo real. Toda empresa de IA que cuente con más de un modelo o modo de inferencia debe gestionar una estructura de precios diferenciada en función de una matriz que incluya la versión del modelo, el tipo de inferencia y, posiblemente, el nivel de cliente.
En una plataforma de facturación que no cuente con una tarificación nativa basada en fórmulas y con múltiples variables, esto suele implicar crear un plan de tarifas independiente para cada combinación de modelo e inferencia. Esto es manejable con dos o tres modelos. Se convierte en una pesadilla de mantenimiento cuando hay diez, y en un riesgo de auditoría cuando hay veinte.
Los equipos que acaban teniendo más problemas son aquellos que resolvieron esto con soluciones provisionales de ingeniería desde el principio: un script que calcula los valores numéricos de los tokens antes de pasar los datos al sistema de facturación, una integración personalizada que asocia los ID de los modelos a los planes de tarifas en una hoja de cálculo, o un proceso de corrección manual para ajustar los precios de los modelos. Esas soluciones funcionan con dos modelos y cincuenta clientes. Dejan de funcionar con diez modelos y quinientos clientes, normalmente justo en el momento menos oportuno: durante una campaña de ventas, con nuevos contratos empresariales que presentan estructuras de precios para las que la solución provisional nunca se diseñó. La reconstrucción se lleva a cabo bajo presión de tiempo, con facturas en curso. Es la versión más evitable de una crisis de facturación.
Tarificación basada en el tiempo de cálculo frente a la tarificación basada en el número de tokens
Algunos modelos de tarificación de IA cobran en función del tiempo de cálculo, en lugar del recuento de tokens o además de este. A un cliente que ejecuta un trabajo de ajuste fino se le facturan horas de GPU, no tokens. A un cliente que utiliza un modelo de visión se le puede facturar por imagen analizada, mientras que a uno que utiliza un modelo de texto se le factura por token. La capa de medición debe realizar un seguimiento de varios tipos de métricas por cliente, posiblemente de forma simultánea, y dirigir cada una de ellas al modelo de tarificación correcto.
Requisitos del motor de calificación
Compatibilidad con fórmulas multivariables
Requisito imprescindible para la tarificación de la IA. El motor de tarificación debe admitir expresiones del tipo (tokenes_de_entrada × tarifa_de_entrada) + (tokenes_de_salida × tarifa_de_salida), en las que ambas cantidades de entrada se midan por separado y ambas tarifas sean configurables sin necesidad de escribir código. Si la implementación de un nuevo nivel de tarificación para un modelo requiere abrir un ticket de asistencia técnica, la plataforma de facturación no está diseñada para el funcionamiento real de la tarificación de la IA.
Una prueba práctica: ¿puede tu plataforma de facturación configurar lo siguiente en menos de 10 minutos, a través de una interfaz de usuario y sin necesidad de que intervenga el equipo técnico? Precios de GPT-4o: 2,50 $ por cada millón de tokens de entrada, 10,00 $ por cada millón de tokens de salida y 1,25 $ por cada millón de tokens de entrada almacenados en caché. Son tres variables y tres tarifas para un solo modelo. Multiplica eso por tu catálogo de modelos.
Tarificación en tiempo real con consumo visible para el cliente
Los desarrolladores de IA supervisan activamente su consumo de tokens. Incorporan mecanismos de control de costes en sus aplicaciones. Configuran alertas presupuestarias. Para que esto funcione, los datos de uso deben estar disponibles para los clientes casi en tiempo real (a los pocos minutos de la llamada a la API, no al día siguiente).
Se requiere un cálculo del uso en tiempo real (no solo recuentos brutos de eventos). Los clientes no quieren ver que han realizado 1,4 millones de llamadas a la API. Quieren ver que han gastado 47 dólares de un presupuesto de 100 dólares. Para ello, es necesario que el motor de cálculo procese los eventos de forma continua, y no en lotes nocturnos.
Gestión de excedentes y créditos prepagados
Muchas API de IA ofrecen créditos prepagados junto con la facturación basada en el uso. Un cliente adquiere 500 dólares en créditos que se van consumiendo a medida que utiliza la API; una vez agotados los créditos, el uso se factura a tarifas por exceso de consumo (o se bloquea). El sistema de facturación debe realizar un seguimiento de los saldos de crédito en tiempo real, aplicar el consumo a los créditos antes de que se produzca la facturación y generar alertas de umbral cuando los saldos caigan por debajo de los niveles definidos.
Se trata de un modelo híbrido: prepago + consumo + recargo por exceso de consumo, todo en una única cuenta, que puede abarcar varios modelos simultáneamente. Es una estructura habitual de monetización de la IA y una prueba reveladora de la madurez de la plataforma. Los casos extremos son aquellos en los que la mayoría de las plataformas de facturación fallan. El saldo de un cliente pasa a ser negativo a mitad de período cuando se completa un trabajo por lotes de gran volumen después de que se le hayan agotado los créditos. La mayoría de las plataformas detectan esto solo en la conciliación, no en tiempo real, por lo que el cliente recibe un cargo por exceso de consumo que no esperaba y que no había autorizado. Los créditos caducan sin utilizarse al final del periodo sin que se envíe ninguna notificación automática, lo que da lugar a anulaciones inesperadas y reclamaciones. Un cliente compra créditos adicionales a mitad de periodo y el nuevo saldo no se aplica inmediatamente al consumo en curso, por lo que se cobran recargos por un consumo que los créditos deberían haber cubierto. Cada una de estas situaciones requiere que el sistema de facturación realice un seguimiento continuo del estado de los créditos, y no en un proceso por lotes nocturno. Pide a los proveedores que te expliquen cada escenario en una demostración.
Modelos híbridos de suscripción y uso
Los clientes de Enterprise AI suelen funcionar con un modelo híbrido: una suscripción básica (compromiso mensual o anual) que incluye un límite de uso, más recargos por el consumo que supere la cantidad incluida. El sistema de facturación debe realizar un seguimiento correcto del consumo en relación con el límite incluido y aplicar las tarifas por exceso únicamente al uso que supere dicho umbral.
Cuando el cliente renueva o actualiza su plan a mitad de período (modificando su asignación incluida o su tarifa por exceso de consumo), el sistema debe aplicar las condiciones anteriores al consumo realizado antes de la modificación y las nuevas condiciones al consumo realizado después de la misma. La tarificación por períodos divididos es tan importante para las empresas de IA como lo es para cualquier empresa de SaaS.
Requisitos de infraestructura a escala de IA
Mediación para eventos de alta frecuencia
Dado el volumen de eventos que generan las plataformas de IA, la infraestructura de mediación se convierte en una dependencia de la ruta crítica. La capa de mediación debe gestionar el almacenamiento en búfer persistente de eventos (los eventos se almacenan de forma duradera antes de su procesamiento, para que no se pierdan ante picos de carga), garantizar la idempotencia a alto rendimiento (detección de duplicados sin reducir la velocidad de ingesta) y gestionar los eventos tardíos en los trabajos de inferencia por lotes, en los que los eventos de finalización pueden llegar bastante tiempo después de que haya comenzado la inferencia.
Registro de eventos inmutable
Las empresas de IA suelen recibir preguntas sobre la precisión del uso por parte de los clientes, de los inversores que analizan la economía unitaria y de los auditores que examinan el coste de los ingresos. Un registro de eventos inmutable (un registro permanente e inviolable de cada evento de token tal y como se produjo) es la base para responder de forma definitiva a todas esas preguntas. Sin él, una disputa sobre la facturación se convierte en una conversación del tipo «tu palabra contra la mía». Con él, basta con consultar el registro.
Consideraciones sobre la norma ASC 606
Las empresas de IA con contratos corporativos que incluyan componentes basados en el uso deben reconocer los ingresos variables conforme a la norma ASC 606. Esto requiere que los datos de medición sean precisos, estén marcados con la fecha y la hora y sean auditables. La solidez de tu posición en materia de reconocimiento de ingresos depende directamente de la solidez de tus datos de eventos. Una empresa de IA que no pueda rastrear sus ingresos reconocidos hasta los eventos concretos que los generaron se enfrenta a un riesgo en materia de información financiera, no solo a un problema de facturación.
Qué hay que tener en cuenta a la hora de evaluar una plataforma de facturación
A la hora de evaluar plataformas de facturación para la monetización de la IA, incluye estos aspectos en tu lista de criterios de evaluación:
- ¿Permite configurar precios basados en fórmulas con varias variables (tokens de entrada y salida, diferentes tarifas) sin necesidad de programar?
- Consumo calculado en tiempo real: visible para los clientes a los pocos minutos de la llamada a la API, en forma de importes facturados, no como recuentos brutos de eventos.
- ¿Es capaz de gestionar la deducción de saldo de prepago en tiempo real, junto con los recargos por consumo excesivo?
- Modificaciones del contrato a mitad de período: ¿la tarificación por períodos parciales se realiza automáticamente o requiere una intervención manual?
- ¿Cuál es el rendimiento de ingesta de eventos en momentos de máxima carga? Obtén un dato de referencia.
- Un registro de eventos inalterable, desde el evento sin procesar hasta la línea de la factura: pídeles que te lo muestren en directo.
- ASC 606 / NIIF 15: ¿integrado o como módulo independiente? La respuesta a esta pregunta determina quién es el responsable cuando los ingresos reconocidos y la facturación no coinciden.
La cuestión de la infraestructura de facturación es algo a lo que la mayoría de las empresas de IA no dan prioridad hasta que su solución inicial se les queda pequeña. Es posible que la estructura de facturación que funciona para tus primeros 100 clientes empresariales no sirva para tu cliente número 500. Reconstruirla bajo presión de tiempo, con facturas de clientes en curso, es una experiencia mucho peor que hacerlo bien a la primera.
Preguntas frecuentes
¿Qué infraestructura de facturación necesitan las empresas de IA que no ofrece la facturación estándar del SaaS?
Tres capacidades que van más allá de la facturación estándar de SaaS: tarificación basada en fórmulas para precios de tokens con múltiples variables (tokens de entrada y de salida a tarifas diferentes, por modelo, configurables sin código); uso tarificado en tiempo real visible para los clientes a los pocos minutos de una llamada a la API, como importes facturados en lugar de recuentos brutos de eventos; y gestión de crédito prepagado: seguimiento del consumo de crédito en tiempo real, aplicación de créditos antes de facturar tarifas por exceso de consumo y generación de alertas de umbrales. La facturación estándar de SaaS gestiona la suscripción y el exceso de consumo. Ninguna de estas tres funciones forma parte de las capacidades estándar.
¿Cómo funciona la facturación basada en tokens para las API de IA?
La facturación basada en tokens mide los tokens de entrada (texto enviado al modelo) y los tokens de salida (texto generado) para cada llamada a la API, y aplica tarifas distintas a cada uno. La fórmula es (tokens_de_entrada × tarifa_de_entrada) + (tokens_de_salida × tarifa_de_salida). Las tarifas varían según el modelo y, en el caso de los clientes empresariales, según el nivel del contrato o el descuento negociado. El sistema de facturación debe registrar el recuento de tokens de entrada y salida por cada llamada, aplicar el plan de tarifas adecuado para el modelo y el cliente, y agregarlos en períodos de facturación, al tiempo que muestra el consumo en tiempo real a los clientes que gestionan los presupuestos.
¿Cuáles son los casos extremos en la facturación de crédito de prepago que la mayoría de las plataformas gestionan mal?
Los fallos más habituales: el saldo de un cliente pasa a ser negativo a mitad de período cuando se completa un trabajo por lotes de gran volumen después de que se hayan agotado sus créditos. La mayoría de las plataformas solo detectan esto en el momento de la conciliación, no en tiempo real. Los créditos caducan sin utilizarse al final del periodo sin que se envíe ninguna notificación automática, lo que da lugar a anulaciones inesperadas y reclamaciones de los clientes. Un cliente compra créditos adicionales a mitad de periodo y el nuevo saldo no se aplica inmediatamente al consumo en curso, por lo que se cobran recargos por el consumo que los créditos deberían haber cubierto. Cada una de estas situaciones requiere que el sistema de facturación realice un seguimiento del estado de los créditos en tiempo real, no de forma por lotes.
¿Qué implicaciones tiene la norma ASC 606 para las empresas de inteligencia artificial que aplican una tarificación basada en el uso?
Según la norma ASC 606, la contraprestación variable (incluidos los ingresos basados en el uso) debe estimarse e incluirse en el precio de la transacción en la medida en que sea probable que dicho importe no se revierta. Esto requiere datos de medición que sean precisos, estén marcados con la fecha y la hora y sean auditables. Una empresa de IA que no pueda relacionar sus ingresos reconocidos con los eventos subyacentes de los tokens se expone a riesgos en materia de información financiera: si su posición respecto al reconocimiento de ingresos es cuestionada en una auditoría, la única defensa es el registro de eventos. Las empresas de IA con contratos corporativos deben asegurarse de que su plataforma de facturación genere un registro de eventos inmutable que vincule cada dólar reconocido a datos de uso específicos.
¿Por qué es importante el uso ponderado en tiempo real para los clientes de las API de IA?
Los desarrolladores de IA incorporan medidas de control de costes en sus aplicaciones: alertas presupuestarias, límites de frecuencia y topes de gasto. Para que esos controles funcionen, los clientes necesitan ver su consumo en forma de importes facturados casi en tiempo real, no como recuentos de eventos sin procesar al día siguiente. Un cliente con un presupuesto diario de 100 dólares necesita ver «47 dólares gastados» tras sus llamadas a la API de la mañana, no «1,4 millones de tokens consumidos». Para ello, es necesario que el motor de tarificación procese los eventos de forma continua, no en lotes nocturnos, y que muestre a los clientes el consumo con su correspondiente precio en tiempo real. Las plataformas que no pueden hacer esto generan una carga desproporcionada en el servicio de atención al cliente, un factor conocido que provoca la pérdida de clientes en los negocios de API de IA.
Para consultar la guía completa para profesionales sobre medición y clasificación, visita billingplatform.com/metering-and-rating.
Véase también: Fijación de precios basada en fórmulas: cuando las consultas por niveles no son suficientes | Cómo funcionan los motores de tarificación: una guía técnica | Qué provoca la pérdida de ingresos y cómo evitarla | Deduplicación de eventos en la facturación | ¿Qué es la mediación de facturación?
