China AI Pilots: Calculate Cost per Accepted Task
Compare model charges with whole-workflow costs, accepted task counts and setup recovery using a worked enterprise AI pilot ledger.
A lower model charge can produce a higher cost per useful result. For an enterprise AI pilot in China, calculate the cost of completing an accepted business task across the whole workflow, including failed attempts and the people who resolve exceptions.
Start with a shared acceptance rule and a fixed observation window. Then divide the resources used by the number of distinct tasks that actually meet that rule. A model call, an answer displayed and a completed customer request can be three different counts.
Choose a business task that can be accepted
For a document-processing pilot, a task might be one invoice entered with the required fields correct and the required approval recorded before an agreed deadline. Establish that definition before comparing configurations. Keep the input mix, permitted data, quality checks and deadline comparable.
Give each business task one identifier. Link model calls, retries, corrections and human fallback to that identifier. Count the task once when it meets the acceptance rule, regardless of how many attempts it took.
Record whether an accepted task was completed automatically or with human assistance. Keep rejected, overdue and unresolved tasks visible. An unanswered request can consume resources without adding an accepted result.
Build a cost boundary the team can reproduce
Use a single currency and a documented costing period. Separate the following entries so an inexpensive API request does not hide the rest of the workflow.
| Cost entry | What belongs in the pilot record |
|---|---|
| AI and supporting services | Model calls, retries, retrieval, storage and other metered services used within the boundary |
| Human operations | Distinct time spent checking, correcting, resolving exceptions and completing fallback work, valued at an agreed resource rate |
| Other recurring operations | Allocated hosting, monitoring, support or licences, with the allocation basis recorded |
| One-time preparation | Integration, evaluation setup and training, reported separately with an explicit recovery assumption |
Avoid counting a service both in the AI charge and again in the recurring allocation. If support is bundled into a licence, identify that boundary. For shared infrastructure or staff, state how usage was allocated rather than assigning the same capacity in full to several pilots.
MAP 3.2 in NIST's AI Risk Management Framework 1.0 (2023) addresses examining and documenting potential costs connected to system errors and trustworthiness. The worksheet here turns that cost question into a proposed comparison for a defined task; the framework does not prescribe this particular formula.
Compare two configurations on accepted output
Consider a hypothetical test in which configurations A and B each receive 1,000 comparable invoice tasks during the same observation period. All amounts below are assumed resource costs in CNY. Human effort is valued at the same rate, and acceptance includes the same quality, approval and deadline requirements.
| Measure for the observation period | A | B |
|---|---|---|
| AI and supporting service cost | 200 | 500 |
| Human operations cost | 900 | 400 |
| Other recurring operations cost | 400 | 400 |
| Total recurring resource cost | 1,500 | 1,300 |
| Distinct accepted tasks | 750 | 900 |
| Accepted tasks / eligible tasks | 75% | 90% |
| Recurring cost per accepted task | 2.00 | 1.44 |
The calculation is total recurring resource cost / distinct accepted tasks. For A, it is 1,500 / 750 = CNY 2.00. For B, 1,300 / 900 is approximately CNY 1.44, rounded only for display.
A has the lower AI service charge, but B has the lower total recurring cost and supplies more accepted tasks under these assumptions. Both numerators include resources spent on the tasks that failed to meet acceptance. Removing those costs would make the comparison look better without changing the delivered work.
The figures establish only this assumed comparison. Inspect the remaining 250 and 100 tasks: how many were rejected, late or still unresolved? Preserve their costs, outcomes and ages. Also compare the split between automatic and human-assisted acceptance. A low blended unit cost can still require a staffing arrangement that the operating team cannot sustain.
Keep setup cost and cash savings visible
Report one-time setup beside the recurring calculation. If B requires CNY 6,000 of additional setup relative to A, ask which future operating conditions could recover that amount. A comparison at different accepted volumes cannot, by itself, supply the answer.
As a separate planning assumption, suppose a later like-for-like test establishes that both configurations can deliver the same required workload and acceptance mix, with B using CNY 0.50 less recurring resource per accepted task. Simple undiscounted recovery would require 6,000 / 0.50 = 12,000 accepted tasks. If the difference falls to CNY 0.20, it would require 30,000. Neither saving is inferred from the earlier table; each needs its own evidence under comparable operating conditions.
Check whether that volume is feasible before the configuration, pricing or workload changes. A forecast of eligible requests is not a forecast of accepted tasks. If the measured saving is zero or negative, this simple model has no positive recovery point.
Valuing staff time also differs from reducing cash expenditure. A reviewer who spends fewer minutes correcting outputs may remain on the same payroll. Record whether the released time can serve other necessary work, whether overtime or contracted support changes, and which costs actually leave the budget. Use the human-review capacity worksheet to test the staffing assumption.
Leave with a reconciliation the process owner can use
Keep one sheet linking eligible task IDs, their final acceptance status, attempt counts, human effort and allocated costs. Reconcile the task totals to the outcome ledger and the cost totals to the agreed billing and resource records. Preserve open cases when closing the observation window; record later resolution separately.
Repeat the comparison with representative busy and quiet periods and the configuration versions recorded. Use the model-comparison framework for the wider quality and deployment questions. Bring the costing boundary and one unresolved operating assumption to an industry-focused China AI program, so the next evaluation can examine the work behind the unit cost.