26% of AI spend is wasted in 2026: build the cost attribution layer before the next bill spike

Summary. Organisations estimate that 26% of all AI spend is wasted, and 52% say no single person owns the AI bill, according to the 2026 State of AI in FinOps report Harness published on 29 July 2026 from a survey of 700 engineering and FinOps leaders conducted by Sapio Research in May and June 2026. For a company spending $1M a month on AI, which describes 1 in 5 respondents, that is $260,000 a month with no measurable return. The visibility gap is worse than the waste: 72% hit an unexpected AI cost spike in the past year, 33% were caught out more than once, and if spend doubled overnight only 20% could name the cause within hours. Meanwhile 98% of FinOps practitioners now manage AI spend, up from 63% in 2025 and 31% in 2024, per the FinOps Foundation's State of FinOps 2026 survey of 1,192 respondents representing more than $83bn in annual cloud spend. The tooling has not caught up: OpenAI, Anthropic, AWS Bedrock, Microsoft Foundry and Google Vertex AI each expose a different attribution primitive, and not one of them returns a dollar figure per request.

This article is the build guide. It covers what each provider actually gives you as of August 2026, where the granularity ceiling sits, how to name an owner without creating a committee, and the 90-day sequence that gets a unified view in place before the next invoice lands.

What the 2026 data actually says

Two independent 2026 datasets point at the same failure, and they disagree on almost nothing.

Harness surveyed 700 engineering leaders and practitioners across five countries: 300 in the United States and 100 each in the United Kingdom, France, Germany and India. Every respondent works at an organisation that actively uses AI or LLM services. The findings, published 29 July 2026:

• 52% say there is no clear cost owner. Responsibility is split across engineering, FinOps, finance and IT.

• 72% have had an unexpected AI cost spike or bill in the past year. 33% more than once.

• Only 20% could identify the reason within hours if spend doubled overnight.

• Organisations estimate 26% of AI spend is wasted.

• 45% of engineers say they understand the cost of the AI features they build.

• 56% say anticipating AI spend is guesswork rather than data.

• 57% of engineers say their organisation actively encourages "tokenmaxxing", maximising AI usage regardless of tangible value.

• 73% have AI cost policies in place, yet only 13% have basic visibility into their AI spend.

• Only 26% have a reliable method for measuring the business value of AI spend.

That last pair is the sharpest number in the report. Three quarters of organisations have written a policy they cannot enforce, because they lack the telemetry the policy depends on. Policy without measurement is a memo.

The FinOps Foundation's sixth annual State of FinOps survey, covering 1,192 respondents and more than $83bn in annual cloud spend, shows the same problem from the practitioner side. 98% of FinOps teams now manage AI spend, against 63% a year earlier and 31% in 2024. "FinOps for AI" is the top forward-looking priority, "AI cost management" is the top skillset teams want to add in the next twelve months, and the single most-requested capability that does not exist in today's tooling is granular monitoring of AI spend across tokens, LLM requests and GPU utilisation.

"AI spend has moved from a line item that occasionally surprises people to a budget category that regularly does," said Patrick Brogan, Director, FinOps Advisory at Harness. "The patterns we're seeing, invoice shock, ownership confusion, governance gaps, are the same ones the industry saw with cloud a decade ago, just compressed into a fraction of the time. Ownership is really the crux of it. This is fundamentally an organizational challenge."

Why AI cost behaves differently from cloud cost

The instinct is to point existing cloud cost tooling at the AI bill. That fails for four structural reasons, and understanding them saves a quarter of wasted integration work.

The spend is not in one place. Cloud cost lands in an infrastructure bill you already ingest. AI cost lands in at least four different ledgers at once: GPU and inference infrastructure, foundation model API charges, SaaS subscriptions for copilots and coding assistants, and managed services. The copilot seats are the sneakiest, because they arrive as ordinary software licences on a procurement line rather than as engineering spend, so the FinOps team never sees them.

The unit is not a resource. An EC2 instance runs whether or not anyone uses it, which makes it easy to attribute to whoever provisioned it. A token is consumed by a request, and the request was made by a code path, on behalf of a customer, inside a feature. The dimension you care about, cost per feature or cost per customer, is not a dimension any provider bills on.

Cost is a function of prompt design, not capacity planning. A retrieval change that adds 8,000 tokens of context to every call multiplies the bill without changing a single line of infrastructure. This is why the Harness finding that only 45% of engineers understand what their AI features cost matters more than it looks: the people who move the cost needle are not the people who see the invoice.

Most teams run more than one provider. Each has its own pricing model, its own billing granularity and its own attribution primitive, and none of them agree on a schema. FOCUS, the FinOps Open Cost and Usage Specification designed to normalise exactly this, is at version 1.4, ratified 4 June 2026, and it still does not carry AI model identity or token counts. Foundational support for non-monetary units such as credits and tokens arrived in FOCUS 1.2 in May 2025, but no AI model vendor appears on the FOCUS data generator list at all. The standard meant to solve this has not solved it yet.

The practical consequence is that the unified view has to be built, not bought. That sounds worse than it is. The work is a week of plumbing per provider, plus a schema decision you make once.

The attribution primitives, provider by provider

Here is what each major provider actually exposes as of August 2026, verified against vendor documentation rather than vendor marketing.

OpenAI: projects are the unit, and the budget is a suggestion

OpenAI attributes cost through projects. Each project gets its own API keys, its own service accounts that cannot be used outside the project, and its own model rate limits. An organisation can create up to 2,000 projects by default.

Two admin endpoints do the reporting work. The Costs API returns dollars and groups by project_id, line_item or api_key_id:

            curl "https://api.openai.com/v1/organization/costs?start_time=1785715200&bucket_width=1d&group_by[]=project_id&group_by[]=line_item&limit=30" \
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY"
          

The Usage API returns token counts and groups on more dimensions: project_id, user_id, api_key_id, model, batch and service_tier. If you omit group_by, fields such as project_id and model come back null, which is the single most common reason a first integration looks empty.

Two limits matter for design. bucket_width on the Costs API accepts only 1d, so there is no hourly dollar view. And the per-project monthly budget with notification thresholds is alert-only. OpenAI's own documentation states it does not enforce a hard cap on spending. A budget you cannot enforce is a smoke alarm, not a sprinkler.

There is a per-request identifier, safety_identifier, which uniquely identifies an end user and is sent as the OpenAI-Safety-Identifier header on Realtime. Its documented purpose is abuse monitoring, and it is not a grouping dimension on either the usage or the cost endpoint. Do not build a per-customer chargeback design on it.

Anthropic: workspaces, and an admin key you have to mint separately

Anthropic segments spend by workspace. The Usage endpoint is GET https://api.anthropic.com/v1/organizations/usage_report/messages and the Cost endpoint is GET https://api.anthropic.com/v1/organizations/cost_report. Both require an admin API key prefixed sk-ant-admin01-, which is distinct from the standard API key your application uses.

The usage endpoint is the richer of the two. It filters and groups by API key, workspace, model, service tier, context window, inference_geo for data residency, and speed behind a beta header. Bucket widths run to 1m with a maximum of 1,440 buckets, which is genuinely minute-level telemetry. The cost endpoint is narrower: it groups by workspace_id or description only, and runs at daily granularity, with all costs in USD reported as decimal strings in cents.

Three documented gotchas will cost you an afternoon if you meet them cold. The default workspace has a workspace_id of null. Workbench usage has an api_key_id of null. And Priority Tier costs are excluded from the cost endpoint entirely, so you have to track those through the usage endpoint with service_tier=priority and price them yourself. Data typically appears within five minutes of a request completing, and the supported polling rate is once per minute.

AWS Bedrock: four mechanisms, and the one you reach for first is the wrong one

Bedrock has the richest attribution surface and the most opportunity to pick the wrong tool.

Application inference profiles attach cost allocation tags to a profile, and you pass the profile ARN in place of the model ID. The profile's tags are attached to the billing record for each request, and they flow into Cost Explorer and Cost and Usage Reports 2.0. The catch is that each profile is model-specific, so profile count multiplies across model times team times tag set, and the estate becomes unmanageable at about the third model.

Projects are what AWS now recommends. A project is not tied to a specific model, so the model stays a per-request parameter while the project ID is set on the client. Tags flow to Cost Explorer and CUR 2.0 the same way. Requests without a project ID land in the account's default project, which is the bucket you will find everything in on day one.

IAM principal attribution needs no code changes at all. The caller identity is captured automatically for every inference request on the runtime endpoint, and principal tags and STS session tags surface in CUR 2.0 under an iamPrincipal/ prefix, up to 50 tags per role. It requires a new CUR 2.0 data export with the caller identity ARN option selected, and existing exports are not retroactive, so create it before you need it.

Request metadata is the trap. You can attach up to 16 key-value entries per request, keys and values capped at 256 characters:

            # Converse API: requestMetadata in the body
{
  "modelId": "your-model-id",
  "requestMetadata": {
    "feature": "support-summariser",
    "tenant": "acme-corp",
    "env": "prod"
  }
}
          

AWS states plainly that request metadata is not delivered as a cost allocation tag and does not appear in Cost Explorer or CUR. To use it for cost you have to join your invocation logs with the Cost and Usage Report on requestId, or aggregate token counts from log records and multiply by per-token rates yourself. It also only reaches the logs if invocation logging is enabled in that Region.

One line from the AWS documentation is worth pinning above the desk of whoever builds this: the finest grain is per usage type per day, and projects do not produce per-request cost.

Across every tag-based method, activation happens in the Billing console under cost allocation tags, takes up to 24 hours to appear, and is not retroactive.

Microsoft Foundry: tagging you get for free, in Preview

Microsoft Foundry tags every project's underlying usage with a project tag automatically, with no manual tagging step, and you filter Cost analysis by that tag. Project-level cost attribution is in Preview as of the documentation revision dated 14 May 2026, and it supports models sold by Azure including Azure OpenAI, but not models served through Azure Marketplace. Marketplace and partner model meters appear under the resource group rather than the Foundry resource, in a model-name-GUID format, which is how they get lost.

Per-deployment splitting works through Cost analysis under costs by resource, with filters on deployment tags and user-defined tags, and grouping by meter to see per-model-series charges. At subscription scope, Azure OpenAI is not a filterable service in its own right; it sits under the broader Cognitive Services classification, so filter on the Azure OpenAI service tier instead.

As with OpenAI, there is no hard cap. Microsoft's documentation says directly that while OpenAI has an option for hard limits that prevent going over budget, Azure OpenAI does not currently provide that functionality. Budgets are alert-only. Scheduled cost data export to a storage account is Microsoft's recommended way to retrieve datasets, which is the right call for anyone building their own view.

Google Vertex AI: labels that reach billing, for Google models only

Vertex AI takes labels on generateContent and streamGenerateContent calls as a labels object in the request body, up to 64 labels per call:

            {
  "contents": [{"role": "user", "parts": [{"text": "..."}]}],
  "labels": {
    "feature": "support-summariser",
    "team": "cx-platform",
    "env": "prod"
  }
}
          

Google's documentation states that label information is forwarded to the billing system, that built-in billing reports can filter and group costs by label, and that labels can be used to query billing data exports. Costs are typically available within a day and can take more than 24 hours.

The restriction that catches multi-model teams: labels are supported only for Google models. Adding labels to a request for an unsupported model returns an error. Google also advises against creating large numbers of unique labels, and against putting personally identifiable information in them, which rules out the naive "label every request with the customer email" design.

The granularity ceiling nobody puts on the pricing page

Read those five sections together and a single conclusion falls out: no major provider gives you the dollar cost of an individual request.

AWS says so in writing. Anthropic's cost report is daily-only, and its per-request path reports tokens rather than dollars. OpenAI's Costs API accepts only daily buckets. Azure's per-model figures carry an explicit instruction to reconcile against Cost Management and the invoice. Every real-time per-request cost figure you have ever seen in a dashboard was computed by multiplying a token count by a published rate.

That is not a defect to work around. It is the design constraint to build on, and it dictates the architecture:

1. Dollars come from the billing APIs, daily. They are authoritative and they reconcile to the invoice. Use them for chargeback, budget tracking and anything finance sees.

1. Attribution comes from your own telemetry, in real time. Log model, token counts, feature, tenant and environment on every call from your own code. This is the dimension table.

1. The two get joined on the day. Daily provider dollars are allocated across the day's logged token volume by feature. Any team that promises finance an exact per-request dollar is either estimating or lying, so say "modelled" on the dashboard and reconcile monthly.

Doing it this way also removes the dependency on whichever provider primitive is in Preview this quarter. The gateway or client wrapper that stamps every call is code you own.

Name the owner before you buy anything

Harness found that organisations reaching full AI cost maturity follow a consistent sequence, and it starts with a person, not a tool: name a single accountable owner for AI cost before adding new tools or providers, build one unified view across infrastructure, software and models before attempting to optimise, push cost data into engineering workflows at the point of model selection and prompt design, and tie spend to business outcomes before measuring ROI.

The ownership question is where most attempts go wrong, because the obvious answers are all slightly wrong.

The model that holds up is platform engineering owning the bill, with a named individual, on two conditions. The gateway has to be the only sanctioned path to a model provider, otherwise a team with a corporate card routes around it in an afternoon. And the owner needs the authority to say no to a provider contract, otherwise the role is reporting rather than ownership.

Note the FinOps Foundation's reporting-line data here: 78% of FinOps teams report to a CTO or CIO and only 8% to a CFO. The function already sits inside engineering at most companies. The gap is scope, not reporting line.

"Cost visibility has to be part of the infrastructure from day one," said Harish Doddala, VP Product, Cloud and AI Cost Management at Harness. "Waiting until after the damage is done means teams are always reacting instead of preventing."

Push cost into the workflow, not into a monthly deck

The 45% figure, the share of engineers who understand what their AI features cost, is the one to move. Three changes do most of the work.

Stamp every call at the gateway. Model, input tokens, output tokens, cached tokens, feature identifier, tenant identifier, environment. Emit it as a structured log line to the same place your traces go. This single change makes every downstream question answerable, and it works identically across all five providers because it lives in your code, not theirs.

Put the cost delta in the pull request. A retrieval change that adds context to every call should show up as a modelled monthly cost change before it merges, using the same modelled-dollars method as the dashboard. Teams already gate merges on test coverage and bundle size; token cost belongs in the same list. This is the same class of control as catching regressions with automated evaluation in the delivery pipeline, and it fails the same way when it runs only on a schedule instead of on every change.

Kill the tokenmaxxing incentive. If 57% of engineers say their organisation encourages maximising AI usage regardless of value, then some internal target is measuring adoption rather than outcome. Replace the adoption metric with a unit economic: cost per resolved ticket, cost per generated document, cost per successful agent run. Adoption metrics were useful in 2024 to get teams started. In 2026 they buy waste.

Unit economics also have to come before ROI, in that order. Cost per successful run is measurable this quarter. Return is a business argument that needs a denominator, and the denominator is the unit economic. Attempting ROI first is why only 26% of organisations have a reliable method for measuring the business value of AI spend.

India-specific considerations

India was one of the five countries in the Harness sample, with 100 of the 700 respondents, so the findings apply directly rather than by analogy.

Two local factors change the build. First, data residency selection is now a cost dimension as well as a compliance one. Anthropic's usage endpoint exposes inference_geo as a filter and grouping dimension, so a team running Indian residency alongside a default region can separate the two lines without extra instrumentation. Any attribution schema built for an Indian enterprise should carry a residency field from day one, because retrofitting it means reprocessing history.

Second, the Digital Personal Data Protection Act 2023 constrains what goes into attribution labels. Google's Vertex documentation already warns against putting personally identifiable information in labels, and that guidance becomes an obligation rather than a suggestion under DPDP. Use an opaque tenant identifier that maps to the customer inside your own systems. Never the email, never the phone number, never the account name. The same rule applies to Bedrock request metadata and OpenAI's safety_identifier, which is explicitly meant to carry a hash rather than a username.

For Indian teams building the unified view, the sequencing advantage is real: most are earlier in AI adoption than their US counterparts, which means the attribution layer can go in before the estate sprawls. Retrofitting attribution across four providers and thirty features is a quarter of work. Instrumenting the gateway before the third provider arrives is a fortnight.

The 90-day sequence

Two of those exit criteria are worth defending hard. "Zero direct-to-provider calls" is the one that decides whether the whole exercise works, because a single unrouted service reintroduces the blind spot. And "traced within one hour" is deliberately set against the 20% benchmark in the Harness data, so you can tell whether you have actually joined the better fifth or merely bought a dashboard.

Cost allocation tags take up to 24 hours to appear on AWS and are not retroactive, and Google billing data can take more than 24 hours, so the day 56 to 75 window assumes the day 16 to 30 work actually happened on schedule. Skipping ahead produces an empty dashboard and a fortnight of debugging the wrong layer.

FAQ

How eCorpIT can help

eCorpIT builds the attribution layer described above as a delivery engagement: a single AI gateway that stamps model, token, feature, tenant, environment and residency metadata on every call, the daily join between provider billing APIs and your own telemetry, and the dashboard finance and engineering both read from. Our senior engineering teams work across OpenAI, Anthropic, AWS Bedrock, Microsoft Foundry and Google Vertex AI, and we design the data handling to align with Digital Personal Data Protection Act requirements from the first commit. eCorpIT is CMMI Level 5 appraised, ISO 27001:2022 certified and MSME registered, and works with AWS, Microsoft and Google as technology partners. If your AI bill spiked this quarter and nobody could explain why within the day, talk to our cloud and FinOps team about a 90-day attribution build.

For related reading, see our guides to cutting cloud spend with FinOps for Indian teams, AI and cloud cost control across AWS, Azure and GCP, choosing between the AWS FinOps agent and third-party FinOps tools, Claude enterprise spend controls and the usage admin API, and Gemini Enterprise governance, billing and token cost control.

References

1. New Harness Report Reveals Enterprise AI Spend Has Outgrown the Systems Built to Track It, PR Newswire, 29 July 2026

1. 1 in 4 dollars spent on AI goes to waste, report finds, CIO Dive, 29 July 2026

1. State of FinOps 2026 data, FinOps Foundation

1. FOCUS specification, current release 1.4, FinOps Foundation

1. FOCUS specification v1.3, extensibility and non-monetary units

1. OpenAI Costs API reference, organization costs endpoint

1. OpenAI completions usage API cookbook, group_by behaviour

1. Managing your work in the API platform with projects, OpenAI Help Center

1. OpenAI safety best practices, safety_identifier

1. Usage and Cost API, Anthropic platform documentation

1. Cost management with application inference profiles, AWS Bedrock user guide

1. Cost management with projects, AWS Bedrock user guide

1. Cost management with IAM principal tracking, AWS Bedrock user guide

1. Cost management with request metadata, AWS Bedrock user guide

1. Plan and manage costs for Microsoft Foundry, Microsoft Learn, updated 14 May 2026

1. Add labels to API calls, Vertex AI generative AI documentation, updated 2 June 2026

1. FOCUS specification tackles AI token economics, SiliconANGLE, 8 June 2026

1. Digital Personal Data Protection Act, 2023, Ministry of Electronics and Information Technology

Last updated: 3 August 2026.