The short answer#
Budget for a Gen AI application in three parts: getting it into production, operating it each month and changing it safely as the business evolves. Judge affordability by comparing the cost of a completed business task, including human review and unsuccessful attempts, with today's manual process. Approve a bounded pilot that measures those costs before committing to a wider rollout.
Ask for three budgets before approving one total#
A model price tells you what one component consumes. Your approval needs to cover a working service: who can use it, what information it can access, how its answers are checked and who fixes it when something changes.
For an internal assistant that answers questions from operating procedures, ask the team to separate the estimate like this:
| Budget | Work to include | Evidence to request |
|---|---|---|
| Build and deploy | Workflow discovery, data preparation, access controls, integration, evaluation, user interface, deployment and handover | Scope, effort by role, dependencies and acceptance criteria |
| Run each month | Model and tool usage, hosting, retrieval storage, monitoring, support, recurring evaluation and human review | Expected volumes, unit assumptions, owners and a spending ceiling |
| Change | New data sources, revised procedures, model changes, regression checks and additional workflows | What is included in support, what needs a new estimate and who approves it |
Price the work your organisation must supply as well as the vendor's work. A subject expert preparing reference answers and an identity team configuring permissions both consume capacity, even when their time is absent from the supplier's invoice.
Keep one-off preparation separate from recurring upkeep. Cleaning the first document collection is delivery work; keeping that collection accurate and enforcing changed permissions needs an operating owner. Put each activity in one budget so it is neither omitted nor counted twice.
The useful estimate is therefore a scoped amount with assumptions. A proposal that says only “assistant development” leaves you unable to tell whether evaluation, integration or support will arrive as an extra assignment.
The model bill is only one operating line#
For a usage-priced API, start with the number of business tasks, then estimate the model calls each task needs. Count the text sent to the model and the text it produces, including extra calls when the first answer is unusable. A task that finishes after three successful API calls has used three calls even if the business rejected the first two answers.
Anthropic's pricing documentation separates input and output token usage and identifies additional charges for some hosted tools, including web search. Use your selected provider's actual contract and billing categories when filling in the estimate; a token allowance alone may leave tool charges uncovered.
Retrieval adds another operating component. This is the search layer that finds relevant passages in your documents before the model answers. AWS's guidance on retrieval infrastructure identifies the extra cost of its data store. Ask the team to cost initial indexing, updates, storage and search separately from answer generation.
Then add the work of keeping the service useful. AWS's guidance on model quality treats evaluation as recurring work using feedback and test data. Reserve time for checking answers after a procedure, prompt or model changes, alongside monitoring and incident response.
For approval, request both an expected month and a stress case. Change the assumptions that could materially alter your decision: longer documents, more calls per task, higher review effort or lower adoption. A spending alert needs a named person and an agreed response, such as pausing a costly workflow while staff use the manual process.
A worked example: review effort changes the answer#
Consider a hypothetical internal document assistant handling 10,000 tasks a month. Every figure below is an illustrative planning assumption, not a vendor quote, market benchmark or InfoMover price. Replace each one with measured workload data and your own costs.
Assume the business owner counts a task as accepted only when its answer is correct, supported by an authorised source and usable within the agreed response time. Acceptance is measured after any required review; a model returning text does not by itself count as completion.
| Monthly assumption | Calculation | Cost |
|---|---|---|
| Model and tool usage | Assumed allowance covering all attempts | $42 |
| Hosting and retrieval | Assumed operating allowance | $63 |
| Support and recurring evaluation | Allocated staff or supplier effort | $210 |
| Human review | 2,000 tasks × 3 minutes ÷ 60 × $6 per hour | $630 |
| Total operating cost | Sum of the four lines | $945 |
Here, 20% of submitted tasks need three minutes of review. The $6 hourly figure is an assumed cost of staff time. It represents capacity consumed; it need not be an additional cash payment. Keep that distinction visible when comparing the budget with the accounts.
Suppose 9,000 of the 10,000 tasks meet the acceptance criteria. Monthly operating cost per accepted task is $945 ÷ 9,000 = $0. Costs incurred on the other 1,000 tasks remain in the numerator. If those tasks require manual completion afterwards, budget that fallback work separately; it is excluded from this assistant-only calculation.
Now assume initial delivery costs $6,299 and choose a 12-month planning period. Spreading that amount across the period adds $525 a month, taking the planning cost to $1,470 or about $0 per accepted task. This is a comparison method, not an accounting treatment: you still need to fund the delivery payments when they fall due. Separately approved enhancements would add to the calculation.
In a stress case, suppose 40% of tasks need the same review and only 8,000 tasks are accepted. Review costs $1,260; the other operating assumptions stay at $315. Operating cost becomes $0 per accepted task, or $0 including the delivery allocation.
That change comes from review effort and accepted volume. It gives the pilot a concrete job: test those assumptions before the organisation commits to the operating model.
Allocate delivery costs over your chosen planning period.
Measure value against the process you have today#
Choose an outcome the business already recognises: a procedure question resolved, a document checked or a support case completed. Define the quality and response-time conditions before testing, and record how much staff effort completion requires.
AWS's financial-services cost guidance includes a metric for spending per successful task. Applying that principle here, compare the process with the assistant against the manual process at equivalent quality, including fallback work. Keep the API bill visible, but use the whole-process comparison for the investment decision.
Time released has value when the business can use it. Ask which team will absorb more work, reduce a backlog or avoid additional hiring. An hour released from a salaried employee is not automatically an hour of cash savings. Show capacity benefits and changes in cash expenditure separately, with an owner for each claimed benefit.
Avoid selecting a cheaper model on the bill alone. AWS's evaluation guidance recommends assessing models against task-specific test data. Compare candidates on your own representative tasks, recording accepted results, review minutes and total usage. A smaller bill is helpful only if the resulting workflow still meets your acceptance criteria.
What this means for you#
You can approve evidence gathering before approving scale. Fund one bounded workflow, identify its document owners and users, and put a ceiling on both external spend and internal effort. Require the pilot to report task volumes, accepted results, review time, fallback work and operating cost against the assumptions in the proposal.
Set the expansion gate before the pilot starts: the quality threshold, maximum acceptable cost per completed task, response time and operational owner. The thresholds depend on your workflow and its consequences; use values your business owner can defend. If the pilot misses them, decide whether to narrow the scope, improve the workflow or stop.
When comparing build, buy or partner proposals, ask each supplier to use this same boundary. Include licence terms, integration, evaluation, support and exit work where applicable. A managed product may leave substantial work with your staff; a custom build needs an explicit maintenance owner. Require the proposal to show who carries each activity.
For a consulting engagement to review your proposal's three budgets and pilot gates, Discuss your project.
Questions to ask before you approve the next phase#
- What exactly counts as a completed task, and who accepts its quality?
- Which costs are one-off, monthly or triggered by change?
- Whose internal effort is missing from the supplier's estimate?
- What did representative testing show about review time and manual fallback?
- What happens to cost per accepted task if adoption is lower or review doubles?
- Which benefits release capacity, and which change cash expenditure?
- Who owns the service, its spending ceiling and the decision to expand or stop?