Model usage is only one part of an implementation budget. The larger uncertainty often sits in the existing process: fragmented sources, undocumented interfaces, inconsistent permissions and an acceptance standard that has not yet been agreed. A useful estimate makes those dependencies visible.
Set a boundary that can be estimated
Name the input, work product, user group and systems involved. Identify which decisions remain with people and which actions the software may perform. An estimate for preparing a claims summary should not quietly include replacing the claims platform. Record exclusions and the conditions that would require a scope change.
Assess the data and integration work
Inspect a representative sample of source files and the actual interfaces available. Poor scans, conflicting versions and missing permissions can require substantial preparation. A documented API differs from browser automation against an unstable screen. Identify these conditions before treating two vendor estimates as directly comparable.
Include acceptance and adoption effort
Someone must define correct output, review test cases and train the operating team. Budget for that client effort as well as engineering. Evaluation should include exceptions and review burden, not only model response quality. A workflow that saves drafting time but adds more verification may need to be redesigned before expansion.
Compare the same unit of completed work
A useful operating estimate describes the unit being processed: a document, a case, a conversation or a completed action. Include expected input size, number of model calls, retrieval work, retries and human review. Then distinguish the cost of processing from the cost of maintaining the service. An average token charge alone does not describe the economics of the workflow.
Ask each proposal to identify its largest uncertainty and the evidence that would reduce it. If the uncertainty is document quality, review samples before committing to the full build. If it is access to a legacy system, prove the interface early. This makes the estimate a sequence of decisions instead of a single apparently precise figure.
Plan the cost of running the service
Separate model and infrastructure usage from support, monitoring, source maintenance and release testing. Estimate a range using representative workload assumptions, then replace assumptions with measured pilot usage. Identify who pays for unusually long requests, repeated retries or volume spikes. Commercial terms should make responsibilities and change control clear.
Before the next decision
Planning checklist
- Workflow, exclusions and dependencies documented
- Representative data and interface review
- Client reviewer and adoption effort included
- Operating assumptions and change terms visible
Sources and further reading
Sources checked 5 October 2026. The design recommendations in this guide are AID’s analysis. Sector obligations depend on the use case and jurisdiction.
Apply this to a defined workflow
AID can use a readiness assessment and scoped pilot to replace major estimate assumptions with evidence from the intended workflow.
