Most enterprise AI budgets are still written the way software licences were written: a platform fee, a services line, a contingency. That habit hides the number that actually decides whether an AI system survives its second year, which is the fully loaded cost of one completed transaction. AI deployment economics is, at bottom, the study of that number: what it is made of, which of its parts move with volume, and which of its parts the organisation controls.
The reason the question matters now is that token prices have fallen far enough to stop being the story. Two major model providers currently list their mid-tier models at the same price, 2 dollars per million input tokens and 10 dollars per million output tokens, and their small models at 10 cents and 50 cents respectively (claude.com/pricing and developers.openai.com/api/docs/pricing, both read 25 October 2026). At those rates the model call is rarely the largest line in a production system. Retrieval infrastructure, the humans who review what the model produces, the integration that gets the output into a system of record, and the compliance work that lets a regulated enterprise run the thing at all, together cost more than inference in nearly every realistic configuration we can construct.
This article builds a fully loaded cost-per-transaction model for one illustrative workflow, contract review in a mid- sized Indian enterprise, with every assumption stated in rupees at ₹95 to the dollar. The numbers are illustrative, not observed. The structure of the result is the point: which costs scale with volume, which do not, and what that implies for anyone deciding whether to deploy, and at what volume.
Why unit cost, not total cost, is the right frame
Total cost of ownership is a useful number for a procurement committee and a useless one for an operating decision. A ₹1 crore annual AI programme is cheap if it processes 50,000 documents a month and expensive if it processes 2,000. The decision to automate a workflow is really a comparison between the marginal cost of the automated path and the marginal cost of the human path, at the volume the enterprise actually has, after fixed costs have been spread.
McKinsey's 2025 global survey gives a sense of how rarely enterprises get to the point where this comparison is made cleanly. Only 39% of respondents attribute any EBIT impact to AI, and most of those put it under 5% of EBIT; about a third report having begun to scale AI across the enterprise (mckinsey.com, The state of AI in 2025). An enterprise that cannot state the cost per transaction of its AI systems is unlikely to be able to state their EBIT contribution either.
Bain's Technology Report 2026 makes a related observation from the cost side: most token-cost risk sits in a small number of workflows, so tight control there with lighter oversight elsewhere is the sensible governance posture (bain.com, Technology Report 2026). That is an argument for building the unit-cost model workflow by workflow rather than programme-wide.
The workflow and its assumptions
The illustrative workflow is first-pass review of inbound commercial contracts, the kind of work a procurement or legal operations team does before a document reaches a lawyer. The system classifies the document, extracts key terms, checks clauses against a company playbook retrieved from a document store, and produces a structured summary with flagged deviations. A human reviews a share of the output.
The loaded hourly rate of ₹750 corresponds to roughly ₹13 to 15 lakh a year in salary and overheads for a trained reviewer, which is a reasonable mid-point for a legal operations analyst in an Indian metro. It is an assumption, and any reader with better internal numbers should substitute them.
The fully loaded cost per document
At the base volume the five cost lines come out as follows.
Three things stand out. First, inference is under 8% of the fully loaded cost. If the pipeline were switched entirely to the small model the inference line would fall to ₹0.43 per document and the total would fall by about ₹8, a 7% saving; if it were run in batch mode at the 50% discount the saving would be about ₹4. Neither change alters the economics of the system. Second, human review is the single largest line, at a third of the total, and it is the line most sensitive to model quality. Third, the four fixed lines together are ₹6.67 lakh a month regardless of how many documents flow through, which is what makes volume the decisive variable.
Against a manual baseline of ₹562.50 per document, the automated path at 10,000 documents a month costs about 20% of the human path, an 80% reduction in first-pass review cost. That is the headline number a vendor would quote. The more useful numbers are what happens when the assumptions move.
AI deployment economics under three volumes
At 2,000 documents a month the system still beats manual review, but by a third rather than four-fifths, and a modest increase in review share or a slower integration build would erase the margin. At 50,000 documents the fixed lines almost disappear and inference finally becomes a line worth negotiating. The practical lesson is that the same system is a marginal investment for a company with a small document flow and an obvious one for a company with a large flow, and the difference has nothing to do with the model.
This is also why pooling matters. An enterprise with six workflows each at 2,000 transactions a month can often share retrieval infrastructure, the evaluation harness, the audit logging and much of the compliance work. Shared platform costs spread across 12,000 transactions look like the middle row of the table rather than the first. The operating-model question of who owns that shared platform is covered in a separate PanScience Research piece on AI operating models.
The review share is the hidden lever
The human review line deserves its own sensitivity analysis because it is both the largest variable cost and the one that depends on model behaviour rather than on prices.
Moving from 15% to 50% review nearly doubles the unit cost. That move is not hypothetical: it is what happens when a system is deployed before its evaluation has settled, when the business does not trust the output, or when a regulator or internal audit requires broader checking. McKinsey's survey finds that nearly a third of respondents report consequences from AI inaccuracy and that 51% of respondents from AI-using organisations report at least one negative consequence (mckinsey.com, The state of AI in 2025). Each such consequence tends to raise the review share, which raises the unit cost, which weakens the case that justified the deployment.
The implication runs in the opposite direction too. Spending more on the model, on retrieval quality or on evaluation that lets the review share fall from 15% to 10% saves ₹12.50 per document, more than the entire inference line. In this workflow, model quality is a cost-reduction tool, and the cheapest model is rarely the cheapest system.
Where the model breaks, and how to read it honestly
The model above is deliberately simple and it omits things that a real deployment would have to include. It does not price the time of the business owner, the data preparation needed before the first document is processed, the cost of a failed pilot that preceded this one, or the opportunity cost of the reviewers now redeployed. It assumes the integration build succeeds within budget, which in our observation is the assumption most often violated. It treats retrieval infrastructure as a flat ₹2 lakh a month, when in practice that line steps up at volume thresholds and falls if the enterprise already operates a shared platform. And it treats compliance as attributable to one system, when in a regulated enterprise much of that cost is shared across many.
Two cost lines also behave differently for on-premise deployment. An enterprise running its own inference hardware converts the variable inference line into a fixed one, which improves the picture at high volume and worsens it at low volume. A separate PanScience Research piece on on-premise versus API economics works through that comparison, so it is not repeated here.
PanScience reports that its venture Proteus operates as an LLM gateway that routes, secures and monitors model traffic across an enterprise; in practice, the value of such a layer is precisely that it makes the inference line and the review line measurable per workflow, which is the precondition for running a model like this one on observed rather than assumed figures. The company-reported description is noted here as an example of the instrumentation the analysis requires, not as a recommendation.
Moving from assumed to observed figures
The assumptions above are a starting point, and the useful discipline is to replace them with observed figures line by line as a deployment matures. Each line has a natural instrument. Inference cost per document is available from the provider's usage reports or from a gateway that logs tokens per request, and should be tracked per workflow rather than per account so that one heavy process does not hide inside an aggregate. The review share is available from the workflow tool if every human touch is recorded as an event, which it should be in any case for audit. Retrieval infrastructure cost is a cloud bill, but attributing it fairly across workflows requires tagging resources at the outset, which is cheap to do and expensive to retrofit. Integration and maintenance costs are visible in time sheets if engineering effort is booked against the system rather than against a general AI programme.
Compliance cost is the hardest to observe because it is shared and because much of it is incurred by people whose time is not booked to systems. A reasonable practice is to attribute a fixed share of the information-security, privacy and model-evaluation budget to each production system in proportion to the sensitivity of the data it handles, and to revisit the share annually.
Once four or five months of observed figures exist, the model stops being an estimate and becomes a management instrument. The questions it then answers are concrete: whether the review share is falling as the evaluation set grows, whether the fixed lines are being shared with new workflows or duplicated, and whether volume has crossed the threshold at which inference is worth negotiating.
What the model tells a decision-maker
Four conclusions follow from the structure of the numbers rather than from their particular values.
Volume decides more than price. The same system is marginal at 2,000 transactions a month and compelling at 50,000. Before any model is chosen, the enterprise should know the monthly volume of the workflow and the volume threshold at which fixed costs are covered.
Human review is the cost to manage. It is the largest variable line and the one most directly tied to model and retrieval quality. Investment that lowers the review share pays back faster than investment that lowers the token price.
Fixed costs are a platform question. Integration, retrieval infrastructure and compliance are mostly reusable across workflows. An enterprise that builds them once and shares them has fundamentally different economics from one that rebuilds them per project.
Inference is the line to measure, not the line to optimise first. At under 8% of the base-case total, switching models or buying batch discounts cannot rescue a system whose other lines are out of control; it can, however, matter at high volume, which is why the instrumentation to measure it per workflow should be in place from the start.
The broader lesson for AI deployment economics is that the question "what does the model cost" is almost always the wrong first question. The right one is "what does a completed transaction cost, all in, at our volume, with our review rate", and that question has an answer the enterprise can calculate before it signs anything.
Methodology and sources
The cost model in this article is illustrative. Every assumption, including volumes, token counts per document, infrastructure costs, build and maintenance costs, compliance costs, human review share and hourly rates, is stated in the assumptions table and chosen to be plausible for a mid-sized Indian enterprise; none is an observed figure from a specific deployment. Readers should replace the assumptions with their own data; the arithmetic and the structure of the conclusions are what the article offers.
Model prices are observed, taken from the public pricing pages of two providers read on 25 October 2026: Anthropic's page lists Sonnet 5.5 at $2 per million input tokens, $10 per million output tokens and $0.10 per million cached input tokens, Haiku 5.5 at $0.10, $0.50 and $0.01 respectively, with a stated 50% batch discount (https://claude.com/pricing); OpenAI's page lists gpt-6.1-sol at $2, $0.10 cached and $10 and gpt-6-luna at $0.10, $0.01 cached and $0.50, with a flex or batch tier at half the standard rate (https://developers.openai.com/api/docs/pricing). All conversions use ₹95 per US dollar.
Survey figures are from McKinsey, The state of AI in 2025, a survey of 1,993 participants in 105 nations fielded 25 June to 29 July 2025 (https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-state-of-ai-2025). The observation that token-cost risk concentrates in a small number of workflows is from Bain's Technology Report 2026 landing page (https://www.bain.com/insights/topics/technology-report/). The description of Proteus is company- reported by PanScience Innovations (https://panscience.xyz). No client of any PanScience venture is named or implied.