Cloud Intelligence™
Cómo validar la atribución de costos de IA en un entorno de producción
Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.
About Gregory Wiedeman
Senior Cloud Architect I
Greg is a Cloud Architecture Strategist at DoiT International and holds an M.S. in Systems Engineering from Regis University. He specializes in cloud architecture, FinOps consulting, and technical advisory services—helping clients optimize infrastructure and make smarter build decisions. When he's not immersed in cloud cost strategies, he enjoys writing about AI governance for non-technical leaders, playing cornhole, or climbing Colorado's many 14ers.
My personal pageEs fácil demostrar que se pueden asignar costos a la IA, pero es difícil confiar en esa asignación.
Un dashboard puede mostrar tokens, solicitudes o uso de GPU; lo difícil es saber si esas cifras corresponden al cliente, la funcionalidad del producto, el equipo o el agente correctos, y si los totales coinciden con los que finanzas e ingeniería ya consideran confiables.
Este artículo presenta un enfoque práctico para verificar la asignación de los costos de IA en producción. El objetivo no es tener un dashboard totalmente funcional desde el primer día, sino establecer una cadena de evidencia medible que conecte la actividad en runtime con el contexto de negocio.
Empieza por definir qué significa "correcto"
Antes de establecer un sistema de atribución, primero hay que decidir qué tipo de pregunta deben responder los resultados.
Por ejemplo:
- ¿Cuál es el costo por cliente de prestar el servicio?
- ¿Qué funcionalidades del producto hacen que los modelos gasten más dinero?
- ¿Cuánto cuesta ejecutar cada agente de IA?
- ¿Qué workloads compartidos están generando los costos de infraestructura?
- ¿Qué proporción del gasto dentro del alcance no se puede asignar por el momento?
Las preguntas se relacionan con distintos aspectos de la atribución; aunque un enfoque a nivel de equipo puede ser suficiente para fines de showback, obtener una vista por cliente requiere identificadores de tenant, detalles de la funcionalidad y un mapeo entre los identificadores de runtime y los nombres de negocio.
Antes de mirar los resultados, hay que dejar por escrito los criterios de validación. Un plan de validación que valga la pena debe especificar:
- Los workloads y proveedores dentro del alcance
- Las dimensiones que deben ser visibles
- La fuente de verdad para la comparación
- La ventana de tiempo que se compara
- La variación aceptable
- El tratamiento del gasto no atribuido
Attribute™ asigna el consumo en runtime a distintas dimensiones como equipo, namespace, workload, modelo, funcionalidad, entorno, tenant o cliente. Lo importante es elegir las dimensiones que corresponden a la pregunta de negocio en lugar de recopilar todas las etiquetas posibles.
1. Empieza con un workload de alcance acotado
No empieces validando todo el entorno de nube. Comienza con una porción pequeña y representativa:
- Un servicio de producción
- Un modelo o gateway
- Una funcionalidad de cara al cliente
- Un namespace de Kubernetes
- Una cuenta de facturación o un proyecto
Como el alcance está acotado, cualquier discrepancia se puede identificar, y además el equipo de plataforma obtiene un resultado de referencia que se puede ampliar en el futuro.
Para la primera prueba, registra por separado la actividad esperada. Entre los datos de comparación útiles se incluyen:
- Datos de uso o facturación del proveedor
- Contadores de solicitudes y tokens del gateway de LLM
- Logs de la aplicación
- Identificadores de tenant o cliente
- Metadatos de workloads de Kubernetes
- Utilización de GPU o de cómputo
No es necesario que todos los sistemas utilicen la misma terminología. Lo único que se busca es entender cómo se relacionan los distintos sistemas entre sí.
2. Asegúrate de que la clave de atribución permanezca visible en runtime
Las fallas de atribución suelen comenzar antes de que se calcule el costo: cuando se recopila la telemetría, la clave de atribución —es decir, el identificador necesario para distinguir una instancia de uso de otra— puede estar ausente.
Para cada dimensión objetivo, responde tres preguntas:
- ¿Qué identificador hace referencia al cliente, la funcionalidad o el tenant?
- ¿En qué punto de la ruta de la solicitud aparece el identificador?
- ¿Puede el recolector en runtime observarlo de forma continua?
Por ejemplo, un identificador de cliente podría incluirse en una solicitud autenticada, en un encabezado del gateway, en un atributo de conexión a la base de datos o en un campo propio de la aplicación; pero si el identificador solo existe en la memoria de la aplicación y nunca pasa por un límite observable, habrá que recurrir a otro método de integración o instrumentación.
Por eso la validación debe empezar por la capacidad de ver la clave en runtime y no por el total que muestra un dashboard; si la clave no se puede observar de manera confiable, la asignación posterior seguirá siendo incompleta aunque la capa de reportes esté cuidadosamente configurada.
Las etiquetas no pueden seguir el gasto de IA a través de GPUs y gateways compartidos. Lee AI Features Have a Visibility Problem para ver por qué la observabilidad en runtime supera a la instrumentación. Descarga el ebook →
3. Define los límites de la recolección
Attribute™ recopila información sobre el consumo en runtime a nivel del kernel mediante eBPF (extended Berkeley Packet Filter, una tecnología del kernel de Linux diseñada para la observabilidad con baja sobrecarga) y no requiere modificar el código de la aplicación ni su SDK. Sin embargo, el límite de recolección sigue siendo importante.
Documenta:
- Qué clústeres, hosts o cuentas están cubiertos
- Qué workloads se incluyen o se excluyen
- Qué sistemas operativos y versiones de kernel son compatibles
- Si el tráfico se cifra antes de llegar al límite observable
- Si la infraestructura compartida está dentro del alcance de la medición
Antes de comenzar el modelado de atribución, el proceso de onboarding de DoiT incluye una revisión de la topología del clúster, una comprobación de compatibilidad del kernel y el sistema operativo, una revisión de los requisitos de seguridad y un análisis del flujo de telemetría. Para más información sobre el modelo de trabajo, consulta la documentación general de Attribute.
Una declaración de cobertura útil se ve así:
La validación incluye el namespace de inferencia de producción, el gateway autoalojado y los nodos GPU asociados desde el lunes a las 00:00 UTC hasta el martes a las 00:00 UTC, y excluye el tráfico de desarrollo, los workloads por lotes y las conexiones preexistentes.
Si se establecen límites claros, los equipos no considerarán un resultado intencionalmente parcial como un error, ni asumirán que un área sin medir tiene costo cero.
4. Crea un mapeo entre los identificadores y el negocio
La telemetría en runtime suele comenzar con identificadores técnicos:
- Nombres de pods
- IDs de contenedores
- Nombres de namespaces
- IDs de modelos
- Claves de API
- IDs de tenants
- Nombres de servicios
Los equipos de finanzas y producto necesitan dimensiones legibles:
- Nombre del cliente
- Funcionalidad del producto
- Unidad de negocio
- Entorno
- Nivel de precios
- Equipo responsable
Asegúrate de que el mapeo sea claro y guarda una copia; anota quién es responsable, cuándo se actualizó por última vez y especifica qué ocurre cuando un identificador no tiene un registro de negocio correspondiente.
Una tabla de mapeo debería incluir al menos las siguientes columnas, por ejemplo:
| Identificador de runtime | Dimensión de negocio | Responsable | Fecha de vigencia | Estado de validación |
|---|---|---|---|---|
tenant-4821 |
Acme / Search Assistant | Product Platform | 2026-09-01 | Confirmado |
tenant-5177 |
ExampleCo / Document Review | AI Applications | 2026-09-01 | Confirmado |
tenant-unknown |
Sin mapear | Platform FinOps | 2026-09-01 | Investigar |
La fila sin mapear es importante. Ocultarla crea la apariencia de una atribución completa y, al mismo tiempo, elimina la evidencia necesaria para mejorar la cobertura.
¿Quieres saber qué clientes te cuestan más? Consigue Cost Per Customer: A FinOps Field Guide to Multi-Tenant Cloud Attribution, con SQL funcional para AWS, Google Cloud y Azure. Descarga la guía →
5. Reúne las tres vistas de la misma actividad
Una validación confiable compara al menos tres perspectivas:
- Actividad en runtime — lo que el workload invocó o consumió
- Uso del proveedor o del gateway — lo que la plataforma reporta en tokens, solicitudes o cómputo
- Costo atribuido — cómo se asigna ese uso a las dimensiones de negocio
Compara la misma ventana de tiempo y ten en cuenta las diferencias temporales: las exportaciones de facturación pueden retrasarse, los contadores del gateway pueden interpretar una solicitud de otra manera y la telemetría en runtime puede registrar reintentos o llamadas en caché de forma distinta a la factura del proveedor.
Dos métricas simples resultan útiles:
Cobertura = gasto atribuido dentro del alcance / gasto total dentro del alcance
Variación = valor absoluto (total de la fuente - total atribuido) / total de la fuente
Conviene seguir estas métricas día a día y por workload, ya que un porcentaje global puede ocultar un problema grave con un cliente o una funcionalidad en particular.
Cuando haya una discrepancia, clasifícala en lugar de cambiar de inmediato la regla de atribución:
- Discrepancia de alcance
- Discrepancia en la ventana de tiempo
- Retraso en la facturación del proveedor
- Identificador de runtime ausente
- Identificador sin mapear
- Reintento o solicitud duplicada
- Trabajo en caché o asíncrono
- Ruta de tráfico no compatible
El proceso de clasificación convierte lo que sería un ejercicio de conciliación en una serie de tareas de ingeniería, y el siguiente ejemplo muestra cómo se lleva a cabo esta conciliación de principio a fin antes de considerar las pruebas de casos límite.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Ejemplo ilustrativo de validación
El ejemplo que se presenta a continuación es solo ilustrativo y no se basa en el resultado de ningún cliente real.
Una empresa SaaS quiere calcular el costo de su funcionalidad de resumen de documentos desde el punto de vista de cada tenant; la funcionalidad realiza sus solicitudes a través de un gateway de LLM compartido que se ejecuta en Kubernetes.
El equipo establece un período de validación de 24 horas que incluye un namespace de producción, un gateway y dos proveedores de modelos, y luego compara los contadores de tokens del gateway, el uso del proveedor y los resultados de Attribute™.
| Etapa de validación | Resultado |
|---|---|
| Total del proveedor y del gateway | $10,200 de uso de IA dentro del alcance |
| Gasto atribuido a tenants conocidos | $9,650 |
| Gasto sin mapear o sin atribuir | $550, es decir, el 5.4% del alcance |
| Conclusión inicial | La atribución es útil, pero aún no está completa |
El equipo investiga la discrepancia en lugar de tratarla como un error de cálculo. Encuentra dos causas:
- El tenant lanzado más recientemente tiene identificadores de runtime que no figuran en el mapeo de negocio.
- Un workload por lotes usa el mismo gateway, pero está fuera del alcance original del namespace.
El equipo agrega el mapeo del tenant faltante, separa el workload por lotes y repite la comparación con las ventanas de tiempo alineadas. Esta vez se obtiene una cobertura del 99% para el alcance definido de la funcionalidad, y el resto de la variación se explica por los tiempos de facturación del proveedor.
Lo importante no es el porcentaje en sí. El equipo ahora cuenta con una explicación consistente de la cifra, una responsabilidad clara sobre el gasto que no se ha mapeado y un procedimiento de validación que puede usar cada vez que se agregan nuevos tenants, modelos o workloads.
¿Sigues viendo gasto de IA sin asignar? Consigue 5 Reasons AI Costs Don't Add Up y descubre por qué las etiquetas y los SDKs no pueden cerrar la brecha. Descarga el ebook →
6. Prueba los casos límite que distorsionan la economía unitaria
No basta con hacer una solicitud, porque los sistemas de IA en producción pueden mostrar comportamientos que afectan el costo aparente de una funcionalidad o de un cliente. Prueba como mínimo:
- Reintentos tras errores del proveedor
- Respuestas en streaming
- Prompts o respuestas en caché
- Solicitudes por lotes
- Varios modelos detrás de un mismo gateway
- Tráfico generado por humanos y por agentes
- Workloads de GPU compartidos
- Conexiones de larga duración a bases de datos o gateways
- Failover entre proveedores
Los workloads de Java merecen una consideración especial, ya que la visibilidad de eBPF a nivel del kernel no es suficiente para el tráfico TLS cifrado dentro de la plataforma Java; por eso Attribute™ desarrolló un agente de Java para este escenario. Si quieres conocer los modos de despliegue compatibles, las limitaciones y las verificaciones que conviene realizar después de la instalación, consulta la Java Instrumentation Guide.
La validación no consiste solo en comprobar si el sensor está en funcionamiento; también implica verificar si el sensor observa el tráfico relevante para este workload tal como el workload opera en realidad.
7. Mantén la cobertura como mecanismo de control
La calidad de la atribución varía según el entorno, ya que pueden surgir brechas después de validar el despliegue inicial cuando se agregan nuevos tenants, gateways, modelos, namespaces o funcionalidades.
Crea una revisión recurrente que verifique:
- Identificadores recién observados sin mapeo
- Gasto asignado a una dimensión desconocida o compartida
- Cambios en la cobertura atribuida
- Cambios inesperados en el costo por solicitud o por funcionalidad
- Workloads que dejaron de reportar
- Diferencias entre los totales del proveedor y los totales atribuidos
Considera la cobertura como una métrica operativa y no como un logro puntual.
Una checklist práctica de aceptación
Antes de declarar que un despliegue de atribución está listo para producción, confirma lo siguiente:
- Se registraron las preguntas de negocio junto con las dimensiones relevantes.
- El alcance exacto y el período de tiempo están claramente definidos.
- El identificador objetivo es visible en la ruta del tráfico en runtime.
- Los clústeres, hosts, cuentas y workloads están documentados.
- Los identificadores de runtime tienen nombres legibles para el negocio.
- El gasto sin mapear y sin atribuir es visible.
- La actividad en runtime se concilia con los datos del proveedor o del gateway.
- Se probaron los reintentos, el caché, el streaming y los workloads compartidos.
- Los workloads de Java con TLS se evaluaron correctamente.
- Hay una persona responsable de la cobertura y la variación, junto con un calendario de revisión.
Conclusión
La atribución de costos de IA solo genera valor en la medida en que las personas confían en ella y toman decisiones con base en ella.
Esa confianza surge de un proceso repetible; para lograrlo, es necesario especificar la pregunta, acotar el alcance, comprobar que la visibilidad en runtime está disponible, vincular los identificadores técnicos con el contexto de negocio, conciliar las distintas vistas, probar los casos límite en producción y vigilar la cobertura a lo largo del tiempo.
Attribute™ proporciona la capa de medición en runtime para la IA junto con la infraestructura compartida; aun así, la calidad de los resultados sigue dependiendo del modelo de atribución, del límite de recolección y del proceso de validación asociado.
Para los equipos que pasan de facturas agregadas de IA al costo por cliente, funcionalidad o agente, la validación no es el paso final después del despliegue: es el sistema operativo del programa de medición.
