What does enterprise AI cost after review and rework?

Enterprise AI costs what accepted work costs

Enterprise AI costs the total spent producing work the business can accept, divided by the amount accepted. The model invoice is only one input.

Enterprise AI means software that uses machine learning to perform business work across existing systems, controls, and teams. Its useful unit price includes integration, evaluation, human review, exception handling, operations, and downstream error.

This distinction can reverse a purchase decision. A model that appears inexpensive per request can cost more than manual work once people inspect its output and repair its mistakes. A more expensive model can be cheaper overall if it raises acceptance enough to remove those activities.

Model usage is the smallest visible number, not the total

A token is a piece of text processed or generated by a language model. Vendors usually charge separately for input tokens, which enter the model, and output tokens, which the model produces.

The worked example below assumes $10 per million input tokens and $50 per million output tokens. These are illustrative rates, not a current vendor quote. Substitute the rates for your chosen model and request type from the ¹.

Those prices make the model line easy to calculate. They do not price the system around it.

Integration is the work of connecting the model to business data, identity controls, software interfaces, and the system where the finished work will actually live. Evaluation is structured testing against defined requirements, and review is simply a person looking at production output before it counts as done. An exception is a case the normal path cannot finish and has to route elsewhere instead, while operations is everything that keeps the system running day to day: monitoring, incidents, updates, support.

A finance operations manager staring at a monthly model bill can reasonably conclude the system is cheap. What that number does not show is the reviewer's calendar, the integration hours already sunk into the project, or the cost of the rare case that slips through wrong and has to be unwound after the fact.

Production machine learning systems require far more than model code. Google's architecture guidance states that model code forms only a small fraction of a real system, while the surrounding elements are extensive and complex. ²

The denominator matters just as much. Accepted work is output that passes the required checks, enters the business process, and does not need to be recreated. Counting generated drafts, calls, or deployed features hides rejection and repair.

The cost model prices one accepted unit

Use this equation:

Cost per accepted unit =
(model usage
 + integration
 + evaluation
 + production review
 + exception handling
 + operations
 + downstream error)
 / accepted units

Each term needs a named owner and a measurable unit. Integration can be engineering hours. Review can be minutes per inspected case. Downstream error can be the average labor, refund, delay, or remediation cost caused by a defect that escaped review.

Acceptance rate is the share of attempted units that become accepted work. If a system attempts a volume of cases and only part of them pass, the rejected portion still consumed model usage and may also have consumed review time.

This model prevents a common accounting error: putting build costs in a project budget, model usage in a cloud budget, and review in an operating team's budget, then calling only one of them the cost of AI.

A worked estimate turns a cheap model bill into a different decision

Consider a modelled monthly estimate for a document workflow. These are assumptions, not production measurements: the system attempts 10,000 cases, each case uses 8,000 input tokens and 1,000 output tokens, and 90 percent become accepted work. Integration requires 400 engineering hours at an assumed loaded cost of $120 per hour, amortized over 12 months.

The same estimate assumes a recurring evaluation set of 500 cases, production review of 20 percent of attempted cases, and an exception rate of 8 percent. Evaluation and review take 6 minutes per case. Each exception requires 15 additional minutes. Reviewer time uses $35 per hour as a proxy because one published language-model evaluation paid human judges $20 for 20 questions, reported as roughly $35 per hour. ³

Operations require an assumed 40 engineering hours per month at $120 per hour. Finally, 1 percent of accepted cases produce a downstream defect with an assumed average correction cost of $300. That last assumption must be replaced with the buyer's own incident data before approval.

The modelled estimate produces 9,000 accepted cases at $5.87 per accepted case. Model usage contributes about $0.14 per accepted case, or roughly 2.5 percent of the total estimate.

Without downstream error, the same modelled estimate falls to $2.87 per accepted case. That gap is why the question What happens when the AI gets one wrong? belongs in the business case, not in a post-deployment risk register.

The correction assumption is deliberately exposed. If the buyer cannot estimate the frequency and consequence of escaped errors, the total is incomplete rather than low.

Put a name on the reviewer line, too: an operations analyst spending six minutes on each of the 2,000 reviewed cases in this estimate is not a rounding error in a headcount plan. It is real, recurring work for a real person, and it does not show up anywhere in the model's per-token price.

Cheaper models, manual work, and fixed rules change different terms

Switching models changes the usage line first. It changes total cost only if output quality, latency, or behavior also changes acceptance, review, exceptions, or downstream error.

For comparison, assume a second model costs $0.20 per million input tokens and $1.20 per million output tokens. Under the same usage assumptions, its estimated model bill is $28 instead of $1,300. This is a sensitivity test, not a claim that the cheaper model delivers equivalent quality.

If every other assumption stayed fixed, total cost would fall from an estimated $52,850 to $51,578, and accepted-unit cost would fall from $5.87 to $5.73. The cheaper model saves about $0.14 per accepted case. A small change in acceptance or downstream defects can erase that saving.

This is likely to become more pronounced as inference, meaning the computation used to produce model outputs, gets cheaper. The cost of a system matching GPT-3.5-level performance fell by more than 280 times between November 2022 and October 2024. ⁴ Falling inference cost strengthens the case for modelling the surrounding work because it makes token price a smaller share of the decision.

Manual processing provides a useful comparison. Under an explicit alternative assumption of 10 minutes per case at $35 per hour, completing 10,000 cases manually would cost an estimated $58,333, or $5.83 per completed case. The worked AI estimate costs $5.87 per accepted case, so this particular proposal does not beat the manual baseline.

An operations lead walking into that comparison expecting the AI proposal to win has to sit with the fact that $5.87 lands just above $5.83, not below it. A gap that narrow is easy to close with a slightly cheaper reviewer rate or a slightly higher acceptance rate, which is exactly why it has to be calculated before the model is chosen, not defended after the contract is signed.

Fixed rules are another alternative. They suit inputs with stable formats and decisions that can be stated exactly. They can remove model uncertainty, but they still incur integration, testing, exceptions, and operations. If the rules cannot express the task, forcing the work into them moves cost into manual exceptions.

The right comparison is therefore accepted-unit cost for each feasible method. If none improves cost, capacity, quality, or an independently required control, When should a business not use AI? becomes the governing decision.

Build the estimate from observed workflow data

1. Choose an accepted unit. Name the business result, such as a reconciled invoice or approved response. Do not use requests, tokens, or generated drafts unless those are genuinely accepted outcomes.

2. Measure the current path. Record attempted volume, completion rate, handling time, exception frequency, and the cost of correcting defects. Use the same unit for the AI proposal and its alternative.

3. Run a representative evaluation. Sample the input types, difficult cases, and failure consequences expected in production. Record pass, reject, escalate, and escaped-error outcomes separately. The staffing implications are developed in How much of my team's time will checking the AI take?.

4. Assign every cost line. Include engineering, evaluators, reviewers, exception owners, operators, and downstream teams. State loaded hourly rates, time assumptions, and amortization periods beside the arithmetic.

5. Calculate scenarios. At minimum, vary acceptance rate, review coverage, exception rate, and escaped-error cost. A model comparison that holds all four constant is a token-price comparison, not an enterprise cost comparison.

6. Recalculate after release. Replace assumptions with observed rates. Keep evaluation and production outcomes separate so an improving test set cannot conceal worsening live performance.

The model fails when acceptance and error costs are undefined

This approach cannot make an unpriced consequence precise. Regulatory exposure, customer loss, delayed decisions, and safety events often have wide or discontinuous costs. Averages can conceal a small set of severe failures.

Aggregate software data confirms that production failures deserve their own line, but it does not supply an AI-specific multiplier. A CISQ-commissioned report estimated $1.56 trillion in operational software failures in the United States during 2020, compared with $260 billion for unsuccessful projects that did not ship. ⁵ Those totals show where costs can accumulate, but they cannot price an individual deployment.

The model also breaks when review changes over time. Reviewers can become faster, ignore repetitive warnings, or apply inconsistent thresholds. A fixed minutes-per-case assumption then stops representing the workflow. Sample review may also miss rare failures that matter more than common ones.

Shared infrastructure can make allocation ambiguous. A data platform, identity service, or evaluation harness may serve several products. Assigning all of it to one workflow overstates that workflow's cost, while assigning none understates the investment required.

For high-consequence work, an average cost per accepted unit is insufficient. The decision needs a separate limit for the worst credible error and a rule for cases that must never pass without review. If the team cannot define accepted work, identify who absorbs exceptions, and estimate the consequence of an escaped defect, the enterprise AI cost is still unknown.