How to Validate AI Cost Attribution in a Production Environment

Start with a definition of “correct”

We should first decide what kind of question the results are intended to answer before establishing an attribution system.

For example:

• What is the cost on a per-customer basis for providing the service?
• Which product features cause the models to spend the most money?
• What is the cost of running each AI agent?
• What are the workloads that are in common and causing the infrastructure costs?
• What proportion of the spending within the scope is at the moment not assignable?

The questions relate to various aspects of attribution; although a team-level approach might be adequate for the purpose of showback, obtaining a per-customer view would require tenant identifiers, details regarding the feature, and a mapping between runtime identifiers and business names.

Before you look at the output, you must write down the validation criteria. A worthwhile validation plan should specify:

• The workloads and providers in scope
• The dimensions that must be visible
• The source of truth for comparison
• The time window being compared
• The acceptable variance
• The treatment of unattributed spend

Attribute™ assigns runtime consumption to various dimensions such as team, namespace, workload, model, feature, environment, tenant, or customer. The important choice is to select the dimensions that correspond to the business question rather than gathering every possible label.

1. Begin with a workload of limited scope

Do not start by validating an entire cloud estate. Instead, begin with a small, representative slice:

• One production service
• One model or gateway
• One customer-facing feature
• One Kubernetes namespace
• One billing account or project

As the scope is restricted, any discrepancies can be identified, and it also provides the platform team with a reference result which can be extended in the future.

For the first test, capture the expected activity independently. Useful comparison data could include:

• Provider usage or billing data
• LLM gateway request and token counters
• Application logs
• Tenant or customer identifiers
• Kubernetes workload metadata
• GPU or compute utilization

It is not necessary for all the systems to employ the same terminology. All we want to do is understand the way in which the various systems relate to one another.

2. Make sure the attribution key stays visible at runtime

Failure in attribution usually starts before the cost is calculated; when the telemetry is collected the attribution key—that is, the identifier which is needed to tell one instance of usage apart from another—may be absent.

For each target dimension, answer three questions:

• Which identifier refers to the customer, feature, or tenant?
• Where in the request path does the identifier appear?
• Can the runtime collector keep continuous watch over it?

For instance, a customer identifier might be included in an authenticated request, in a gateway header, in a database connection attribute, or in a field specific to the application; but if the identifier is present only in the application's memory and never passes through any observable boundary, then a different method of integration or instrumentation will have to be used.

That is why validation should start with the ability to see the key at runtime rather than with the total displayed on a dashboard; if the key cannot be reliably observed, the downstream allocation will still be incomplete even if the reporting layer is carefully configured.

Tags can't follow AI spend through shared GPUs and gateways. Read AI Features Have a Visibility Problem to see why runtime observability beats instrumentation. Download the ebook →

3. Set the limits of the collection

Attribute™ gathers information about runtime consumption at the kernel level by means of eBPF (extended Berkeley Packet Filter – a Linux kernel technology designed for low-overhead observability) and does not necessitate any modifications to the application code or to the application SDK. However, the collection boundary remains important.

Document:

• Which clusters, hosts, or accounts are covered
• Which workloads are included or excluded
• Which operating systems and kernel versions are supported
• Whether traffic is encrypted before it reaches the observable boundary
• Whether shared infrastructure is inside the measurement scope

Before attribution modeling begins, DoiT's onboarding process includes a review of the cluster topology, a check that the kernel and operating system are compatible, a review of security requirements, and a look at the telemetry flow. For more information on the engagement model, refer to the Attribute overview documentation.

A useful coverage statement looks like this:

The validation includes the production inference namespace, the self-hosted gateway, and the associated GPU nodes from Monday at 00:00 UTC to Tuesday at 00:00 UTC, with development traffic, batch workloads, and pre-existing connections being excluded.

If clear boundaries are set, teams will not regard an intentionally partial result as broken, and will not treat an unmeasured area as having a cost of zero.

4. Create a mapping from identifier to business

Runtime telemetry often begins with technical identifiers:

• Pod names
• Container IDs
• Namespace names
• Model IDs
• API keys
• Tenant IDs
• Service names

Finance and product teams need readable dimensions:

• Customer name
• Product feature
• Business unit
• Environment
• Pricing tier
• Owning team

Ensure that the mapping is clear and keep a copy of it; note who is responsible for it, when it was last updated, and specify what occurs when an identifier does not have a corresponding business record.

A mapping table should include at least the following columns, for example:

Runtime identifier	Business dimension	Owner	Effective date	Validation status
tenant-4821	Acme / Search Assistant	Product Platform	2026-09-01	Confirmed
tenant-5177	ExampleCo / Document Review	AI Applications	2026-09-01	Confirmed
tenant-unknown	Unmapped	Platform FinOps	2026-09-01	Investigate

The unmapped row is important. Hiding it creates the appearance of complete attribution while removing the evidence needed to improve coverage.

Want to see which customers cost you the most? Get Cost Per Customer: A FinOps Field Guide to Multi-Tenant Cloud Attribution, with working SQL for AWS, Google Cloud, and Azure. Download the guide →

5. Bring together the three views of the same activity

A reliable validation compares at least three perspectives:

• Runtime activity — what the workload called or consumed
• Provider or gateway usage — what the platform reports for tokens, requests, or compute
• Attributed cost — how that usage is assigned to business dimensions

Compare the same time window and account for timing differences: billing exports could be delayed, gateway counters might interpret a request differently, and runtime telemetry might observe retries or cached calls differently from the provider's invoice.

Two simple metrics are useful:

Coverage = attributed in-scope spend / total in-scope spend

Variance = absolute (source total - attributed total) / source total

You need to keep an eye on the metrics day by day on the basis of the workload, since a general overall percentage might mask a serious issue involving a particular customer or feature.

When there is a mismatch, classify it instead of immediately changing the attribution rule:

• Scope mismatch
• Time-window mismatch
• Provider billing delay
• Missing runtime identifier
• Unmapped identifier
• Retry or duplicate request
• Cached or asynchronous work
• Unsupported traffic path

The classification process turns what should be a reconciliation exercise into a series of engineering tasks, and the following example shows how this reconciliation is carried out all the way through before edge-case testing is considered.