Cross-cloud AI cost attribution, unifying FinOps and AI cost in one layer

A CFO opens two dashboards on the same Wednesday morning. One shows cloud spend per team from a FinOps tool like Vantage or CloudZero. The other shows AI spend per workflow from a proxy layer or provider dashboard. Neither adds up to the total she is being asked about, and the reconciliation between them takes a full day of controller time each month. Cross-cloud AI cost attribution is the discipline that turns those two dashboards into one and does it without adding a tagging burden on every engineering team. This guide describes why cloud FinOps and AI cost attribution have historically been separate, where the two disciplines break down when a modern application runs on both cloud infrastructure and multiple AI providers, and the architecture that unifies attribution across both without requiring manual tagging on every request.

The audience is finance directors, platform engineering leads, and FinOps practitioners at European organisations where AI spend has grown to a meaningful fraction of cloud spend and the reconciliation between the two has become an operational headache.

Why cloud FinOps and AI cost attribution have been separate disciplines

Cloud FinOps grew out of the AWS, Azure, and GCP billing surfaces over the last decade. The FinOps Foundation formalised the practice around three pillars (inform, optimise, operate), a set of best-practice patterns for tagging resources at provisioning time, and a tooling ecosystem that consumes cloud billing exports. Cloud FinOps tools like Vantage, CloudZero, Cloudability, Kubecost, and CAST AI are built around the assumption that costs attach to provisioned resources (EC2 instances, GKE clusters, RDS databases) which carry consistent tags applied at creation time.

AI cost attribution grew out of a completely different surface: per-request API calls to OpenAI, Anthropic, Google, Mistral, and Azure OpenAI, priced per token with metadata that only exists at the moment of the request. Attribution here does not attach to provisioned resources because there are none in the classical sense. The API endpoint is stateless from the buyer's perspective, and the tagging pattern that FinOps relies on has no natural equivalent. AI-native attribution tools (governance-layer proxies, provider dashboards, per-request loggers) grew separately because the request shape is fundamentally different.

For most of the 2020s that separation was fine, because AI cost was a small fraction of cloud cost at most organisations. In 2026 that has stopped being true at any organisation that has adopted generative AI seriously. Cross-cloud AI cost attribution has become the discipline that unifies both surfaces into one attribution model.

Where cloud FinOps and AI cost attribution break down when combined

Five specific breakdowns appear when a modern organisation tries to use its cloud FinOps tools for AI spend or vice versa.

Cloud FinOps tools do not see per-request AI cost. Cost exports from AWS, GCP, and Azure include the aggregate API-consumption line but not the per-request breakdown. A team spending 3,000 EUR on Azure OpenAI Service in a month sees one line item in the FinOps tool. That single line cannot be attributed to specific workflows, customers, or product features without additional per-request telemetry that the FinOps tool does not capture.

AI attribution tools do not see cloud infrastructure cost. A proxy layer that captures every LLM call records the cost per request beautifully. It does not know that the request was served from a Kubernetes pod on a GKE cluster whose infrastructure cost belongs to the same product feature. Trying to compute total cost per feature requires two lookups in two systems and a manual join.

Tag drift is different in each system. Cloud FinOps assumes tags are applied at resource provisioning and stay stable. AI attribution assumes attribution metadata is applied at request time. The two do not naturally align: a workflow that changes its cost centre reassigns both cloud resources and AI requests, and keeping them in sync manually is a chore that almost always fails within a quarter.

Currency, tax and margin logic is handled twice. Cloud FinOps applies your organisation's markup and currency logic on cloud spend. AI attribution applies its own logic on AI spend. If both need to feed the same customer invoice or the same P&L line, the reconciliation is manual.

Audit trail sits in two places. The EU AI Act Article 12 audit log covers AI system events. The financial audit trail on cloud spend sits in your ERP or billing engine. When the accountant asks "what AI cost sat behind this specific customer engagement in Q3?", combining the two audit trails to answer is not a query, it is a research project.

Each of these five breakdowns is manageable at small scale. Combined at scale they explain why organisations with real AI adoption end up with a controller spending days per month on reconciliation the tools should have automated.

The requirements for a cross-cloud AI cost attribution layer

A layer that unifies cloud and AI cost attribution needs five capabilities that no single vendor covers by default in 2026.

1. Per-request capture on both surfaces. The layer must intercept AI provider calls (proxy pattern) AND ingest cloud billing exports at the resource-hour granularity. Anything coarser than that misses the attribution signal.

2. Common identity resolution. The same authentication identity (SSO user, service account, workload identity) needs to resolve to the same attribution key on both AI requests and cloud resource usage. This is the identity-based attribution mechanism that avoids manual tagging on every request. For deeper detail see attribution without tagging.

3. Time-aligned join. Cloud costs arrive at daily granularity from the billing exports. AI costs arrive at per-request granularity from the proxy. The layer must roll AI costs up to the same daily grain for joining without losing the per-request drill-down for when it is needed.

4. Code-path metadata retained through the join. Which service, which endpoint, which git SHA, which feature flag was active. This metadata is captured at AI request time; the layer must propagate it to cloud-cost attribution where possible (via workload-identity tags applied at pod-creation time).

5. Single billing schema on top. Once the two data streams are unified, one billing engine applies margin, currency, tax, and cycle rules to produce a single customer invoice or a single internal chargeback report. See aggregating multi-model compute costs onto one invoice for the billing-side detail.

Buying a solution that does one of these five without the others is common and unhelpful. Cloud FinOps tools do 1 and 4 for cloud. AI proxies do 1 for AI. Nobody does 2, 3, and 5 across both by default. That gap is exactly what has emerged as the cross-cloud AI cost attribution product category.

Mapping cloud costs directly to application code paths

One of the most specific requirements in this space is mapping cloud costs to the application code paths that generated them. FinOps tools that only see provisioned-resource tags cannot answer "which endpoint in the microservice caused the cloud bill to jump this month" beyond the coarse workload-tag level. Mapping to code paths requires two things.

Runtime metadata at cost-generating events. When a pod calls an LLM, when a Lambda function reads from S3, when a Cloud Run instance writes to Cloud SQL, the runtime metadata (source file, function name, feature flag state, deployment version) exists in memory. Capturing that metadata at the moment the cost-generating event happens is what makes code-path attribution work. For AI calls this is the request-interceptor pattern the code-path attribution H2 in the AI spend attribution guide already covers. For cloud events (data transfer, database queries, storage operations) it requires either OpenTelemetry instrumentation on the emitting service or a sidecar pattern that captures the metadata.

Deterministic join key from runtime metadata to cost line. The metadata captured at runtime must produce the same attribution key as the cost line downstream. For AI requests this is the identity + workflow + code-path key. For cloud resources this is the workload-identity + git-SHA-tag applied at pod creation. When both use the same key derivation logic, the join is direct; when they use different logic, reconciliation becomes manual.

An organisation that gets this right can answer "which pull request caused the cloud bill to go up 12 percent last month" as a query, not a research project. Most organisations in 2026 cannot. The gap is not intent; it is that no single tool combines the two.

Attribution without tagging, revisited for the cross-cloud case

Manual tagging is where FinOps discipline collapses. Developers forget, tags drift, and retroactive tagging is impossible for resources that ran three months ago. Identity-based attribution avoids the problem for AI requests (see the tag-less attribution H2). Applying the same principle across cloud requires that cloud resources also carry identity at creation time.

The pattern that works in production for 2026 European organisations is:

• AI requests: identity comes from the authentication context at request time (SSO, service account, workload identity). No manual tag needed.
• Cloud pods and workloads: workload identity is stamped at pod creation via Kubernetes ServiceAccount, ambient identity in AWS via IAM Roles for Service Accounts, GCP Workload Identity, or Azure Workload Identity. No manual tag needed.
• Cloud resources provisioned via IaC: identity comes from the pipeline that ran the deployment (GitHub Actions run ID, deployment version). No manual tag needed if the pipeline stamps consistently.
• Everything else: falls into a residual bucket that finance either owns as overhead or investigates one-off.

For the four categories above, the attribution key comes for free from infrastructure that is already required for other reasons (auth, deployment tracking, workload isolation). Adding tagging discipline on top is duplicative work. Once identity-based attribution is set up in a cross-cloud AI cost attribution layer, the residual bucket typically shrinks from 40-60 percent (typical for tag-based FinOps) to under 10 percent, which is small enough for finance to handle manually.

Where Ciralgo fits cross-cloud AI cost attribution

Ciralgo is the EU-hosted governance and attribution layer that intercepts AI provider calls and produces per-request records with identity, workflow, code path, and cost. For cross-cloud AI cost attribution specifically, Ciralgo covers the AI half of the equation cleanly: identity-based attribution, code-path retention, multi-provider aggregation, EU-hosted audit logging.

For the cloud half, Ciralgo integrates with the cloud billing pipeline your organisation already runs. If you use Vantage, CloudZero, or a native cloud billing export as your FinOps source of truth, Ciralgo produces the AI-side records in a schema that joins to your cloud-side records on the common identity key. If you self-serve cloud cost via an in-house data warehouse, the join is the same shape.

What Ciralgo does not replace is your cloud FinOps tooling. Cloud FinOps has a decade of tool maturity and Ciralgo is not trying to displace Vantage-class tools. What Ciralgo provides is the AI-side that those FinOps tools do not cover, in a schema that connects to what they do cover.

For organisations that want an end-to-end cross-cloud AI cost attribution setup, the practical shape is: Ciralgo for AI, a mature FinOps tool for cloud, and a common identity + billing schema that lets both feed one downstream analytics layer.

Talk to Ciralgo

If your finance team is spending days per month reconciling cloud and AI cost dashboards, and the question of code-path or per-customer AI cost is still hard to answer, a 20-minute call is enough to see whether Ciralgo fits. We build the EU-hosted AI-side attribution layer that joins to your existing cloud FinOps setup, we do not only advise. Book a slot via our contact page, we reply within one working day.

Frequently asked questions

Does cross-cloud AI cost attribution replace cloud FinOps tools?

No. Cloud FinOps tools like Vantage, CloudZero, and Cloudability cover cloud infrastructure cost well. Cross-cloud AI cost attribution unifies the AI cost side with the cloud cost side through a common identity and schema. In production, both layers coexist and feed the same downstream analytics.

Can I do cross-cloud AI cost attribution with cloud tags only?

Partially. If your team maintains a rigorous tagging discipline on both cloud resources AND every AI API call, tag-based attribution works. In practice, tagging discipline collapses within a quarter for anyone but the largest FinOps-mature organisations. Identity-based attribution avoids the discipline problem by deriving the attribution key from information that is required for other reasons (auth, workload isolation, deployment tracking).

Which FinOps tools does Ciralgo integrate with?

Ciralgo produces per-request AI cost records in JSON with a well-defined schema. Any FinOps tool that ingests external cost data (Vantage via custom cost sources, CloudZero via custom ingest, in-house data warehouses via direct SQL) can join Ciralgo's output on the common identity key. There is no proprietary lock-in on the AI side.

How is code-path attribution different from feature attribution?

Feature attribution asks "how much did feature X cost this month". Code-path attribution goes one level deeper: it asks "which line of code inside feature X drove the cost", which lets engineering identify the specific endpoint, function, or code branch that generates the spend. For product-led finance analysis, feature attribution is usually enough. For engineering optimisation, code-path attribution is what unlocks actionable decisions.

Does the EU AI Act require cross-cloud AI cost attribution?

Not directly. The AI Act requires audit logging under Article 12, which is a subset of what cross-cloud AI cost attribution produces. If you build attribution correctly, the audit log falls out as a byproduct. Building only the audit log and then trying to layer attribution on top later is substantially more expensive.

What is the minimum viable cross-cloud AI cost attribution setup?

For an SME running two AI providers plus one cloud provider, the minimum viable setup is: (1) Ciralgo or equivalent proxy layer capturing AI requests with identity, (2) cloud billing export with workload-identity tags applied at pod creation, (3) a common identity-resolution table that joins the two, (4) a monthly reconciliation job that produces the unified cost view. This can be built in one to two engineering weeks on top of Ciralgo.

Further reading

• AI spend attribution: multi-model, code-path and identity-based mechanisms
• How to attribute AI costs to teams: four methods for SMEs
• AI cost attribution per client for agencies and consultancies
• Strategic AI cost management for SME CFOs: a four-part framework
• AI cost management for European SMEs
• Machine learning in spend classification
• What is an EU-hosted LLM proxy
• Ciralgo pricing

Last reviewed 11 September 2026. This page is updated semi-annually against changes in FinOps tooling, cloud provider cost exports, and observed cross-cloud attribution patterns.