El trimestre pasado, una CFO le hizo a su líder de finanzas una pregunta sencilla: ¿qué cliente está disparando nuestra factura de OpenAI? La líder de finanzas contaba con una estrategia de tagging, una herramienta de FinOps y una factura mensual de OpenAI. Aun así, no pudo responder. La factura mostraba un solo número. El sistema de tagging no tenía a qué engancharse. El código de la aplicación llamaba directo a la API y devolvía una respuesta. Sin centro de costos. Sin ID de cliente. Sin feature flag. Solo tokens que entran, tokens que salen y una línea a fin de mes.
Esta es la brecha de atribución que el gasto en IA abrió dentro del FinOps Framework. La Allocation, como capacidad, se diseñó para compute y storage, donde cada recurso tiene detrás un tag, un proyecto o una cuenta. Una llamada de tokens no tiene nada de eso. La unidad de gasto —una request a la API— no lleva los metadatos de los que depende el tagging. Si los equipos de FinOps quieren responder preguntas de costo por cliente, por feature o por agente, la atribución tiene que pasar de la capa de facturación a la capa de tráfico.
¿Por qué el tagging no resuelve la atribución de costos de IA?
El tagging falla con el gasto en IA porque una llamada de tokens no tiene una etiqueta a la que asociarse. La Allocation tradicional en la nube funciona así: le pones a una instancia EC2 el tag team=platform y, por cada hora que corre esa instancia, el costo se imputa a platform. El tag vive en el recurso. El recurso genera el costo. La cadena no se rompe.
Con las APIs de IA no ocurre lo mismo. Cuando tu aplicación llama a openai.chat.completions.create(), no hay recurso al que ponerle tag. Hay una request, una respuesta y un conteo de tokens que se registra del lado de OpenAI. Tu cloud provider nunca lo ve. Tu sistema de tagging nunca lo toca. A fin de mes, OpenAI te manda una factura por organización, a veces desglosada por modelo, y ese es todo el universo de información con el que cuentas.
La FinOps Foundation define la Allocation como una capacidad central, pero el framework asume que existe una unidad etiquetable. En los proveedores de IA tipo SaaS, no existe. Anthropic y Bedrock siguen el mismo patrón. Los dashboards de los proveedores desglosan el gasto por API key o modelo, no por el cliente o feature que disparó la request. Aun si separas las API keys por equipo, no puedes separarlas por cliente sin levantar miles de claves y gestionarlas como un servicio de directorio.
Por eso, los practitioners de FinOps que trasladan el playbook de tagging de EC2 y lo aplican a OpenAI terminan con la misma respuesta con la que empezó su CFO: un total. Sin allocation.
Tres equipos, tres preguntas, una factura
La misma factura de IA dispara tres preguntas distintas dentro de una compañía, y ninguna se resuelve solo con los datos de facturación del proveedor.
Finanzas quiere unit economics. ¿Cuánto cuesta atender a cada cliente? Si un cliente premium genera $40 en llamadas a Claude al mes y paga $99 por la suscripción, la historia de margen es muy distinta a la de un cliente que genera $2 en llamadas. Sin atribución por cliente, los cálculos de margen bruto son pura adivinanza.
Producto quiere ROI a nivel de feature. ¿Qué features valen el gasto en tokens? Un feature de resumen puede impulsar la retención y costar $8k al mes. Un agente experimental puede costar $22k al mes y ser usado por 40 personas. Producto no puede priorizar sin saber qué feature se lleva qué porción de la factura.
La CFO quiere saber por qué se movió el número. Cuando la factura de Anthropic se duplica de un mes al otro, alguien tiene que explicarlo. ¿Fue un cliente nuevo? ¿Un cambio de prompt? ¿Un agente descontrolado corriendo en loop? La factura no lo dice. Solo muestra el total.
Los datos crudos de facturación cargados en un dashboard de FinOps no responden ninguna de estas preguntas. Vuelven a mostrar la factura. Eso es una capa de reporting, no una capa de Allocation. El FinOps Framework trata Automation, Tools, & Services como el software que habilita las capacidades, incluida la Allocation para categorías de gasto emergentes. En el caso de la IA, esa automatización tiene que meterse dentro de la propia request, porque ahí es donde vive el contexto de negocio.
¿Qué hace realmente la atribución a nivel de tráfico?
La atribución a nivel de tráfico lee cada request de IA en el momento en que ocurre y mapea el conteo de tokens al cliente, feature y agente que la dispararon. En vez de intentar reconstruir la atribución desde una factura agregada, captura el contexto en el instante en que se hace la request, antes de que ese contexto se pierda.
Así se ve en la práctica. Tu aplicación llama a Claude con un prompt. La request pasa por un gateway o proxy que inspecciona el payload y lo etiqueta con el ID de cliente del auth token, el nombre del feature a partir de la ruta de la request y el identificador del agente desde el servicio que la origina. La request sigue su camino hacia Anthropic. Vuelve la respuesta. El gateway registra los conteos de tokens contra las dimensiones etiquetadas. A fin de mes, ya no tienes un solo número de Anthropic: tienes miles de eventos atribuidos, agrupados por la unidad de negocio que te interese.
Esto funciona con OpenAI, Anthropic y Bedrock porque el patrón de tráfico es el mismo. Todos los proveedores devuelven conteos de tokens en la respuesta. Toda request lleva contexto a nivel de aplicación. La lógica de atribución se ubica entre tu código y el proveedor, así que no hace falta reescribir código de aplicación para agregar tags. Si quieres costo por cliente, tienes costo por cliente. Si quieres costo por agente, tienes costo por agente.
Esto se parece más a cómo funciona la observabilidad que a cómo funciona el tagging. Por eso también el tooling se ve distinto. Una herramienta de FinOps basada en tags quiere ingerir un archivo CUR. Una herramienta de atribución a nivel de tráfico quiere ubicarse en la ruta de la request. Arquitectura distinta, capacidad distinta. Para profundizar en por qué importa este cambio, revisa nuestro análisis previo en Why traditional FinOps breaks down with AI workloads.
Dónde encaja esto en el FinOps Framework
La atribución de costos de IA no es un dashboard nuevo. Es una nueva capacidad de Allocation para una categoría de gasto que no encaja con los supuestos actuales de la Enterprise Architecture. El FinOps Framework se diseñó pensando en recursos etiquetables. Compute, storage, red y bases de datos: todos tienen identificadores por los que las herramientas pueden agrupar. El gasto en APIs de IA no. La unidad de consumo es un token, y los tokens viven dentro de las requests, no en los recursos.
Eso significa que la atribución de IA pertenece a la capa de Automation, Tools, & Services del framework, pero con un patrón de implementación distinto al de la Allocation basada en tags. En lugar de ingerir exports de facturación y agrupar por tag, el tooling lee tráfico en vivo y genera registros de atribución que retroalimentan la capacidad de Allocation. Para un usuario de finanzas, el resultado se ve igual: un costo por equipo, por cliente, por feature. Lo que cambia es el mecanismo por debajo.
Esto pesa a la hora de planear el toolchain de FinOps. Si estás armando una práctica de FinOps para IA sobre una herramienta basada en tags, vas a chocar con la misma pared con la que chocó la líder de finanzas de la CFO. Si estás evaluando una herramienta para atribución de IA, la pregunta no es "¿ingiere mi factura de OpenAI?". Todas las herramientas lo hacen. La pregunta es "¿atribuye mi factura de OpenAI?". Eso exige instrumentación a nivel de tráfico, no ingesta de facturación.
Vale la pena releer la página de Capabilities del FinOps Framework pensando en workloads de IA. Anomaly Management, Allocation y Forecasting dan por hecho que la atribución existe. Para el gasto en IA, la atribución es justamente el input que falta.
Frequently asked
questions
¿Cómo atribuyo el gasto de OpenAI o Anthropic a un cliente específico?
Tienes que capturar el ID de cliente en el momento en que se hace la request, porque la factura del proveedor no lo incluye. Esto implica instrumentar el tráfico entre tu aplicación y el proveedor, ya sea con un gateway, un proxy o un wrapper de SDK, para que cada conteo de tokens quede registrado contra un identificador de cliente.
¿Por qué el tagging no resuelve la atribución de costos de IA?
El tagging requiere un recurso al cual asociarse. Las llamadas de tokens a OpenAI, Anthropic o Bedrock no crean un recurso etiquetable en tu cuenta cloud, así que no hay nada a lo que el tag pueda enlazarse. El costo aparece como una única línea agregada en la factura del proveedor.
¿Cuál es el costo por feature de un producto de IA?
Es la suma de los costos de tokens generados por las requests hechas desde ese feature, dividida entre los clientes o sesiones que lo usaron. Solo puedes calcularlo si capturas el identificador del feature en cada request a medida que ocurre, ya que los datos de facturación del proveedor no incluyen contexto de feature.
¿Cómo asignan los equipos de FinOps el gasto de LLM entre clientes y features?
Mueven la atribución de la capa de facturación a la capa de tráfico. En lugar de intentar dividir una factura agregada después del hecho, capturan el contexto por request —cliente, feature, agente— en el momento de la llamada a la API y consolidan esos eventos en reportes de costo.
¿Cómo se rastrea el uso de tokens por agente o workflow?
Necesitas instrumentación que identifique al agente o workflow que hace la llamada en cada request. Esto puede lograrse con headers de request, identificadores de servicio o un gateway que inspeccione el patrón de la llamada, para luego atribuir los conteos de tokens devueltos por el proveedor al agente que los disparó.
El gasto en IA rompió el modelo de tagging porque una llamada de tokens no tiene nada que etiquetar. Finanzas, producto y la CFO están haciendo preguntas que las facturas de los proveedores no pueden responder, y ninguna cantidad de ingesta de facturación va a cambiar eso. La atribución tiene que moverse a la capa de tráfico, donde cada request todavía lleva el contexto de cliente, feature y agente que le da sentido al número.