Enterprise AI economics depends on the cost of producing an accepted business outcome, including failed attempts, review, maintenance, and the work that remains outside the system. The price of a model call is one input. A demonstration that answers a question cheaply does not establish what it will cost to operate a dependable service at scale.
For a finance and technology sponsor considering an employee procurement assistant, the decision is whether the complete operating model creates enough value to justify its fixed commitments and variable exposure. That requires a credible demand estimate, a defined acceptable answer, and an honest treatment of capacity versus cash.
This article develops a unit-economics model using hypothetical figures. It is a planning method rather than a vendor price comparison or a forecast of returns. Its purpose is to identify the assumptions that can reverse an investment decision before a successful pilot becomes an expensive production obligation.
A request, a model call, an answer, and a resolved task are different units. One employee question may trigger retrieval, several model calls, a retry, and a human clarification. Counting only the first call understates consumption; counting every generated answer overstates useful output.
Define an accepted outcome for the use case. For a procurement assistant, it might be an authorized employee receiving a correct, source-supported answer to an in-scope policy question, with unresolved cases routed appropriately. A confidently wrong answer does not belong in the accepted denominator.
Keep appropriate abstention visible. Declining to answer an unsupported question can be the correct behavior, but it may not deliver the same economic value as resolving the task. Track accepted answers, useful referrals, and failed interactions separately rather than forcing them into one success label.
Measure a business outcome when possible. An answer about a purchasing process is more useful if it helps the employee complete that process correctly. A satisfaction rating or a short interaction can be informative, but neither establishes that downstream work was completed without correction.
List costs that exist even at low usage: implementation, integration, security review, evaluation design, source preparation, licenses or reserved capacity, and operating ownership. Some are initial investments; others recur. Keep them separate so the model shows both the launch commitment and the steady-state burden.
Then list costs that vary with activity: inference, retrieval, tool calls, storage or transfer where relevant, human review, and recovery. Use the actual provider billing units and the organization’s resource assumptions. A token price alone may omit expensive tool paths or repeated failed work.
Include ongoing source and evaluation maintenance. Policies change, documents are replaced, permissions move, and unsupported questions reveal gaps. The assistant needs an owner for those changes. Treating this work as a one-time knowledge upload creates an unrealistic operating forecast.
Sculley and colleagues describe data dependencies, feedback loops, and system-level maintenance debt in machine learning. Their analysis supports accounting for the surrounding system; it does not supply a universal percentage to add to an AI budget. Hidden Technical Debt in Machine Learning Systems, 2015
Suppose a hypothetical enterprise expects 20,000 attempted employee questions per month. Under its agreed quality definition, 12,000 produce accepted answers. Other attempts may produce useful referrals, fall outside scope, or require unresolved follow-up. The model does not treat all 20,000 attempts as equivalent value.
Assume combined model and retrieval consumption costs USD 0.12 per attempt, producing USD 2,400 monthly variable consumption. Assume 2,000 cases require two minutes of human review each. That is 4,000 minutes, or about 66.7 hours. At an illustrative internal resource rate of USD 30 per hour, review represents USD 2,000 of valued effort.
Add USD 3,600 for monthly fixed service commitments and allocated source-care and operating effort. The resulting modeled monthly resource cost is USD 8,000: USD 2,400 plus USD 2,000 plus USD 3,600. This combines cash expenses and valued internal capacity; it is not a statement that all USD 8,000 is avoidable cash expenditure.
Dividing by 12,000 accepted answers gives approximately USD 0.67 per accepted answer. Dividing by 20,000 attempts gives USD 0.40 per attempt, but that lower number does not describe the same outcome. Initial implementation and transition costs are excluded from this monthly operating illustration and must be added separately to the investment case.
Now suppose retries and repeated attempts double billed consumption to 40,000 attempts while accepted answers remain 12,000. If review and fixed resource costs remain unchanged for this sensitivity only, consumption rises to USD 4,800 and total modeled resource cost to USD 10,400. Cost per accepted answer becomes approximately USD 0.87.
These are invented assumptions, not observed rates or provider prices. The sensitivity isolates one mechanism. In a real service, retries could also increase support and review, making the unchanged-cost assumption too favorable. The model should be updated with measured operating behavior before commitment.
Compare with the process employees would otherwise use. Some questions may previously require a service-desk interaction. Others may be answered through search, a colleague, or a concise policy page. New convenience can also create demand that did not previously consume equivalent staff time.
Do not value every accepted answer as a replaced human ticket. Establish which population actually substitutes for existing work, which improves quality, and which represents new activity. Those benefits may all matter, but they need different evidence and valuation.
Distinguish capacity from spending changes. Reduced handling time can free employees for other work without reducing payroll or external service cost. A cash-return calculation should include only expenditure changes the organization can reasonably realize, under a named owner and timing assumption.
Include costs imposed elsewhere. An assistant may reduce procurement questions while increasing corrections in purchase requests if its explanations are incomplete. Measure the downstream task and support burden rather than accepting a local reduction as enterprise-wide benefit.
A few complicated cases can consume many calls or substantial specialist review. Segment cost and outcome by task type, input length, source quality, and failure route where relevant. An average from a curated pilot may conceal the cases that dominate production cost.
Measure the proportion of work reaching each path. A simple answer, a multi-document comparison, and a referred exception have different consumption profiles. Use those path volumes to model demand instead of multiplying one demonstration’s cost by the entire employee population.
Track latency and abandonment alongside cost. A cheaper configuration may generate more retries because users cannot establish whether the request is progressing. A more expensive initial answer may still be economical if it reduces correction and repeat contact, provided quality is maintained.
Capacity commitments create another tradeoff. Reserved infrastructure can reduce some unit costs while increasing the burden of low utilization. Usage-based arrangements can preserve flexibility while exposing the enterprise to demand spikes. Compare the actual terms and operating constraints rather than assuming one commercial model is universally cheaper.
Identify the assumptions with the greatest effect on value: accepted-outcome rate, replacement of existing work, review effort, retry volume, source-maintenance burden, and adoption. Vary them explicitly. The sponsor should know which plausible changes make the project unattractive.
Use staged financial commitments where practical. A pilot can establish demand and accepted quality before a large integration or long license commitment. The purpose of staging is to reduce a specific uncertainty, not to run demonstrations indefinitely without a decision.
Define the evidence required to expand. For example, the sponsor may require measured accepted-outcome cost over representative tasks, a staffed exception route, and proof that the intended existing workload actually declines. Set thresholds from the organization’s economics and risk tolerance rather than a generic AI return target.
Keep downside and nonfinancial value visible. Better access to consistent guidance may be worth funding even when cash savings are modest. Conversely, a low unit cost does not justify materially incorrect guidance. Quality conditions should be satisfied before optimizing the economic ratio.
Set operating guardrails for expensive paths. Define how many retries or tool calls a task may consume before it is referred, and what happens when a budget or capacity limit is reached. The limit should lead to an honest pending or unavailable outcome, rather than a lower-quality answer presented as complete. Test the employee and support experience at that boundary before relying on the cap in the financial model.
Assign owners for demand, quality, source maintenance, consumption, and benefit realization. Review actuals against assumptions and explain deviations. A cost increase may reflect wasteful retries, a useful expansion in demand, or a provider change; each calls for a different response.
Retain a supported fallback and an exit plan. The enterprise should know how to continue the service, preserve needed records, and stop avoidable commitments if the use case no longer makes sense. Include transition costs in the broader investment assessment.
The sponsor’s next step is to build a small outcome-based model using real pilot logs and a credible comparison process. Reconcile attempts to accepted outcomes, add review and maintenance, and separate cash from valued capacity. Approve production when the complete economics withstand plausible variation. The useful number is what the enterprise pays and gains for dependable work, not what a single impressive answer costs.
