The Fully Burdened
Cost of Enterprise AI

An AI assistant that costs $22,500 a year in model usage can support a workflow costing $216,000 annually when the people, infrastructure, and implementation investment are included. That is the result of the hypothetical business case we'll build in this guide. The difference comes from work the model bill cannot describe.

The example is deliberately ordinary: a business team uses AI to prepare recurring case analyses. It needs reliable source data, multiple model calls, human review, and staff who can resolve exceptions. All those activities have a cost, even when the final report looks inexpensive to generate.

Enterprise leaders usually have access to a quoted model price or subscription rate long before they have evidence about those other activities. That asymmetry encourages an investment estimate based on the easiest number to obtain.

The FinOps Foundation's AI guidance makes the broader scope explicit. AI spending may span model APIs, cloud infrastructure, software subscriptions, dedicated compute, and data services. Its planning guidance also calls for estimates of unsuccessful outputs, quality requirements, and costs that vary with usage.

The useful starting point is a defined piece of work: a customer case resolved, an analysis approved, or a claim processed to an agreed standard. We can then estimate what it takes to deliver that outcome with AI, identify which costs will actually change, and revisit the estimate after deployment.

Applied case: Klarna’s $59 Million AI Question explores why reported AI cost savings do not, on their own, establish a fully burdened program ROI.

Draw the boundary around the work

Before entering numbers into a spreadsheet, decide what the estimate is supposed to represent.

A model bill measures consumption or committed capacity purchased from an AI provider. An AI program budget may also include applications, data integration, infrastructure, engineering, and operational support. A fully burdened workflow cost includes the human work required to produce an acceptable result. A multiyear investment case adds the timing of implementation expenditure, future changes in workload, and expected financial benefits.

Those are legitimate but different views. A comparison only works when the baseline and proposed process cover the same activities and quality standard.

Consider an analyst who spends 20 minutes preparing a case. That estimate may cover routine preparation but omit a manager's approval, a data-quality correction, or a downstream handoff. If the AI estimate includes those activities while the human baseline does not, the comparison will be distorted. The reverse is equally possible.

For the initial estimate, document the annual volume of successful outputs, the definition of success, the process boundary, and the evaluation period. Identify costs already paid by the enterprise and costs introduced specifically by the deployment. Distinguish expenses that vary with activity from those incurred whether the system handles ten cases or ten thousand.

The FinOps Foundation's planning and estimating capability calls for scenario definitions, shared-service costs, provider pricing, and trial-run evidence. That is a sensible discipline for AI investments, where model architecture and usage patterns may change before the application is stable.

What belongs in the estimate

The categories below organize an estimate by economic activity. They are a working taxonomy for this guide, not a new accounting standard. The underlying costs should still reconcile to the organization's budget and financial records.

Model execution. Include input and output tokens, additional model calls, retries, embedding or evaluation calls where applicable, and charges for paid tools. Consumption pricing is not uniform across providers or services. For example, Amazon Bedrock publishes model-specific pricing for on-demand use and provisioned capacity; OpenAI publishes separate input, output, and cached-input rates for eligible models and processing modes. A self-hosted model moves the expense into compute capacity, utilization, and supporting operations rather than eliminating it.

Data and integration. Count the systems necessary to supply approved inputs and return usable outputs: retrieval, search, storage, data pipelines, connectors, and access controls. Separate per-case charges from the ongoing cost of running a shared platform. In an enterprise setting, permissions and data freshness can matter as much as model capability.

Engineering and maintenance. Include the initial application build, testing, integration, and release work. Then estimate the continuing engineering needed for fixes, evaluations, changes to upstream systems, and model upgrades. Initial development and recurring maintenance should be recorded separately. A team cannot compare an annual license quote with the annual cost of an internally built solution while omitting the latter's maintenance.

Human oversight and rework. Measure review time, escalation, exception handling, corrections, and work required after unsuccessful attempts. The rate should reflect the people performing those tasks. Replacing routine junior work with senior review can change the labor mix even if total hours fall. Oversight requirements should follow the use case's risk and quality requirements rather than a universal review percentage.

Operations and governance. Include observability, security monitoring, incident response, evaluation, vendor administration, and allocated shared operations. The NIST Generative AI Profile describes a voluntary approach to managing generative-AI risks throughout a system's lifecycle. Its guidance is not a cost schedule, but the testing and risk-management activities it contemplates require real capacity in an implementation plan.

Change and adoption. Account for workflow redesign, employee training, documentation, and transition support. These may be substantial during launch and lighter in steady state. If a support function already provides these services, estimate the attributable work rather than charging the entire function to the AI program.

The risk in a comprehensive inventory is double-counting. A vendor contract may already include hosting and monitoring. An engineering team's fully burdened rate may include support costs allocated elsewhere. A shared data platform should be assigned a defensible portion of its cost, not added in full to every AI application using it.

The FinOps Foundation's allocation capability recommends documented approaches for assigning direct and shared costs, including resource labels, usage data, fixed allocations, or other proxies. The right method depends on which consumption data is actually available.

Estimate the number of attempts, not only the number of outcomes

An application may generate a result on the first attempt, or it may need to try again. A rejected output can still consume model capacity, retrieval services, and human review time.

For a simplified annual model, define a successful attempt as one that produces an outcome meeting the agreed business standard. If each attempt has a stable probability of success and attempts are independent, the expected number of attempts is:

Expected attempts = Required successful outcomes ÷ Success rate

This is a useful planning approximation. Some workflows fail permanently, require fallback to a human process, or have correlated failures. Those should be modeled separately when they matter.

The cost of a model attempt also needs a realistic shape. An application that prepares a report might call the model to plan retrieval, inspect evidence, draft the report, check it, and prepare a final version. One business request can generate several billable model calls.

For token-priced calls, the basic estimate is:

Cost per call = (Input tokens ÷ 1,000,000 × Input rate) + (Output tokens ÷ 1,000,000 × Output rate) + Other metered charges

A production estimate should account for eligible caching, different model prices at different steps, and the actual mix of prompt sizes. For reserved-capacity or self-hosted systems, calculate capacity cost and utilization rather than multiplying tokens by an on-demand rate.

Provider prices change, and a cheap call can be expensive if it frequently fails. The FinOps Foundation's AI workload-estimation paper emphasizes testing cost, accuracy, performance, and hosting assumptions against the specific workload. Until production data is available, treat the estimate as a range.

A worked example: 27,000 approved analyses a year

Suppose a business function needs 27,000 approved case analyses annually, with consistent requirements for accuracy and completeness. Its existing process takes an average of 20 minutes of employee time per approved case. The fully burdened labor rate is $60 per hour.

The annual baseline is:

• Human hours: 27,000 × 20 ÷ 60 = 9,000 hours.
• Fully burdened baseline labor cost: 9,000 × $60 = $540,000.
• Baseline resource cost: $540,000 ÷ 27,000 = $20 per approved case.

Assume a pilot finds that 90% of AI attempts pass the business quality standard. Every attempt needs three minutes of human review. A failed attempt takes another ten minutes of human recovery work. These are illustrative operating assumptions, not findings from an external benchmark.

To deliver 27,000 approved cases, the process is expected to make 30,000 attempts, of which 3,000 fail on the first pass or are otherwise unsuccessful.

The redesigned process therefore needs:

• Review: 30,000 × 3 ÷ 60 = 1,500 hours.
• Additional recovery: 3,000 × 10 ÷ 60 = 500 hours.
• Total remaining human work: 2,000 hours, costing $120,000 annually.

The AI system now needs its own budget. For this illustration, each attempt makes five model calls averaging 15,000 input tokens and 3,000 output tokens per call. We assume a blended effective price of $5 per million input tokens and $25 per million output tokens. These are assumed rates for the example, not a quote from any named vendor.

Each call costs $0.075 in input plus $0.075 in output, or $0.15. Five calls cost $0.75 per attempt. The data and retrieval services add an assumed $0.25 per attempt.

The annual recurring platform and support budget is $54,000, and the initial implementation investment is $36,000. For comparison in the Lab, we'll distribute that one-time investment evenly over a three-year evaluation horizon. This is a modeling convention, not an accounting depreciation or amortization policy.

AI Cost Ledger: annual estimate

The model bill is $22,500. The recurring AI program expense is $84,000. Including the remaining human work and a simple annual allocation of initial investment produces $216,000, or $8 per successful case. The corresponding steady-state operating cost, excluding annualized implementation, is approximately $7.56 per case.

The full workflow cost is substantially below the original $20 resource cost per case. Whether the organization realizes that potential in its financial statements depends on what it does with the labor capacity released.

Why the $324,000 resource improvement is not automatic savings

The new workflow requires 2,000 human hours against the original 9,000, releasing 7,000 hours. At $60 per hour, the theoretical labor value is $420,000.

Suppose management can convert 35% of that released labor value into verified lower expenditure or credible avoided hiring, with no additional contribution from redeployed staff. Realized annual labor benefit would be $147,000. Against the $96,000 annualized AI program cost ($84,000 recurring plus $12,000 of implementation allocated for comparison), the model shows $51,000 of annualized net financial contribution.

The resource-cost comparison, $540,000 versus $216,000, shows $324,000 of potential efficiency improvement. The $51,000 modeled financial contribution is smaller because most released labor capacity has not yet been converted into a financial benefit. The uncaptured capacity may still be useful; its value needs separate evidence. This is the distinction examined in The Headcount Reduction Trap.

Test the assumptions that matter

The base case assumes a 90% success rate and three minutes of review per attempt. If success falls to 80% and review rises to six minutes, expected attempts increase to 33,750 and remaining human work to 4,500 hours. At the same $60 hourly rate, human work costs $270,000. AI program cost increases to $99,750 annualized as the additional attempts consume more variable services.

That produces a fully burdened annualized cost of $369,750, or $13.69 per approved case. With a 35% capacity-capture assumption and no incremental contribution, the modeled net financial contribution becomes negative $5,250.

Both scenarios improve resource cost per case relative to the baseline. Only one clears the illustrative financial hurdle at the specified rate of capacity capture. That is why review effort and the definition of a successful result deserve as much attention as token rates.

How to maintain an AI Cost Ledger

The ledger is a working management artifact built from established FinOps practices. It is not a prescribed reporting standard. Each row should carry a consistent set of information so the estimate can be audited and updated:

The monthly actuals should then reconcile to vendor invoices and financial records. Systems that support request-level metadata can improve attribution; Amazon Bedrock's invocation logging, for example, documents fields for model identity and input and output token counts. The organization still needs an application-level identifier connecting those records to a business case and its final outcome.

Microsoft's Foundry cost-management guidance also distinguishes near-real-time estimated model costs from charges recorded in cost management and invoices. That difference matters when numbers are used for financial reconciliation.

For shared services, select an allocation method that reflects actual use where possible. If the data does not exist, document a provisional allocation and keep its uncertainty visible. Avoid treating centrally funded infrastructure as free merely because the business unit does not receive a chargeback.

An enterprise-wide ledger also needs reconciliation rules. The same review hours cannot appear under both human oversight and recurring program expense. A shared platform's costs must be allocated without multiplying the enterprise total. Credits and negotiated discounts should be applied consistently. Costs already represented in the baseline should only enter an incremental investment comparison when the proposed workflow changes them.

Two views should travel together

The complete ledger supports a fully burdened cost-per-successful-outcome measure:

Fully burdened cost per successful outcome = (Recurring AI program cost + Remaining human workflow cost + Relevant implementation allocation) ÷ Successful outcomes

The financial investment view asks a different question. It compares verified reductions in expenditure, avoided spending, and incremental contribution against the new costs of running the AI program. For more formal decisions, use dated cash flows, an explicit evaluation horizon, and the organization's preferred valuation method rather than a simple annual average.

This distinction determines how the ledger feeds the AI Value Realization Lab. The Lab calculates remaining human work separately using success rate, review time, recovery time, and labor rate. Therefore, its AI program cost fields must exclude human review and recovery expense. For the worked example, enter $0.75 for inference and orchestration per attempt, $0.25 for data/retrieval per attempt, $54,000 for annual fixed infrastructure and operations, $36,000 for one-time implementation, and three years for the evaluation horizon.

The Lab will calculate $96,000 in annualized AI program cost and add the $120,000 cost of human review and recovery when displaying fully burdened workflow unit economics. Entering $216,000 again as a program cost would count those elements twice.

Open the worked example in Lab 2.0

Keep the estimate alive after approval

The initial budget should specify who will replace assumptions with evidence and when. Engineering owns the consumption and performance measurements; the workflow owner owns quality, exception handling, and time studies; Finance validates the economic comparison; Risk and Security identify the controls the use case requires. Ownership can reside in existing teams rather than in a new standing committee.

During a pilot, a small sample may be enough to estimate token use and observe quality failure modes. It is rarely enough to characterize production demand, review behavior, or year-round availability requirements. At launch, establish cost and quality baselines, set anomaly thresholds, and review actual unit cost as the case mix changes. The FinOps for AI overview recommends forecasting with shorter revisions early in adoption and tracking costs alongside functional measures such as reliability and accuracy.

The most useful management decision may be to stop adding features that increase expense without improving the success rate. Another may be to accept a more expensive model because it reduces human review or failed attempts. Those decisions require cost and quality data in the same record.

An AI budget is credible when its assumptions can be traced to observed work and updated as the work changes. A $22,500 inference estimate is straightforward to obtain. The $216,000 full-workflow estimate requires coordination across teams, but it provides a basis for deciding how much the organization can afford to spend and what evidence would justify scaling the investment.

Cost evidence is one part of the broader question of value conversion. The Outcome Disconnect uses economic conversion as one of seven diagnostic lenses, alongside workflow, accountability, capability, and attribution.

Sources and methodology notes

The AI Cost Ledger and all numerical examples are illustrative constructs developed for this article. They are not empirical industry averages, proprietary company data, or formal accounting guidance. Pricing rates in the example are hypothetical and should be replaced with applicable contract and usage data. External sources below support the estimation methods and operational considerations rather than the invented example values.

• FinOps Foundation. FinOps for AI Overview. Scope, AI cost drivers, unit economics, quality thresholds, and forecasting practice.
• FinOps Foundation. Cost Estimation of AI Workloads. Pilot-to-production estimation, model-selection tradeoffs, and consumption versus provisioned capacity.
• FinOps Foundation. Planning & Estimating. Scenario-based estimation, shared costs, and trial-run evidence.
• FinOps Foundation. Allocation. Direct and shared cost attribution and allocation strategy.
• FinOps Foundation. Unit Economics. The relationship between resource-efficiency measures, fully loaded cost, and business outcome metrics.
• NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (2024). Risk management and system evaluation considerations.
• Amazon Web Services. Amazon Bedrock Pricing. Examples of provider-specific pricing structures.
• OpenAI. API Pricing. Input/output, processing-mode, and cached-token billing structures.
• Amazon Web Services. Model invocation logging for Amazon Bedrock. Request-level consumption instrumentation.
• Microsoft. Plan and manage costs for Microsoft Foundry. Cost estimates, monitoring, and billing reconciliation.