What determines the cost of an AI project? Six factors
Six factors set the cost of an AI project: the scope of the work, model usage, data preparation, integration with existing systems, the evaluation set-up, and maintenance after launch. Some are paid once; others recur every month. The model fee is usually the most visible item, but most of the effort goes into data, integration and measurement.
Below we open up each factor in turn. We give no figures, because two projects with the same title can land in very different places depending on how these six questions are answered. At the end there is a list you can prepare before asking for a proposal.
Why is there no single answer to “how much does an AI project cost”?
Because “AI project” is not one job. A flow that sorts incoming emails and an assistant that answers from company documents, with access control, sit under the same heading. The first is a single model call and a small integration. The second needs document preparation, a permissions model, a search layer and ongoing measurement.
The way to understand the cost is to break the work into these six factors. Anyone who knows the “light” and “heavy” end of each can also read the gap between two proposals.
1. Scope: which task, how many steps?
Scope is how many different jobs the system does and how many steps each one involves. It drives cost more than anything else.
Questions that widen the scope:
- Will the system only produce text, or will it also do things? Opening a ticket, sending an email or updating a record calls for an AI agent — and every tool it uses needs its own design, permissions and tests.
- How many user roles are there? A system where everyone sees everything is a different job from one with role-based access.
- How many languages and channels? Internal team only, or customers as well?
The most effective way to narrow scope is a pilot built around one task, as described in how to start an AI project in your company.
2. Model usage: how many calls, how long?
Model usage is the variable item you pay every month the system runs. Language models are generally priced by the amount of text processed, measured in tokens. Four things set the bill:
- Number of calls. How many requests, questions or documents a day?
- Context length. How much text goes to the model with each call? Sending a whole long document to answer one question costs far more than sending only the three relevant paragraphs.
- Choice of model. Not every job needs the most capable model. For simple classification, a small, fast model is often enough.
- Number of steps. In agent systems a request rarely ends with one call: the agent reasons, calls a tool, reads the result and reasons again. Each loop is another call.
The last is the multiplier most often overlooked. An agent left without limits can take far more steps than expected to do the same job, which is why we recommend writing step and spending limits into the design from the start.
Matching the model to the task, rather than using one model for everything, is the design decision with the largest effect on running costs.
3. Data preparation: what state is your data in?
Data preparation is the work of making the information the model relies on usable, and in most projects it is the largest share of the effort.
Things that make preparation heavier:
- Scattered sources. The same information in three folders, two systems and several people’s inboxes.
- Conflicting versions. Several versions of the same policy, with no clarity about which is current.
- Scanned documents and tables. Converting them to text and reading tables correctly takes extra work.
- Unlabelled examples. If there are no examples with a known “right answer” for measurement, those must be prepared first.
- Personal data. Which fields are masked, which go to the model and where the data is processed all need separate design. We cover the Turkish data protection side in personal data in an in-house AI assistant.
For assistants that work from company documents, we describe the preparation in what is RAG.
4. Integration: how many systems does it connect to?
Integration means connecting the AI to the systems the company already runs: CRM, ticketing, ERP, document stores, email. Each connection is its own piece of work.
The effort for each depends on:
- Does the system have a documented API?
- Will the AI only read, or also write? Write access needs approvals and logging.
- How does authentication work? Will the assistant act with the user’s own permissions?
If several AI applications will connect to the same systems, a protocol that standardises the connection, such as MCP, can reduce the maintenance load over time.
5. Evaluation: how will we know it works?
Evaluation is the set-up that measures whether the system is right: a test set, criteria, human review and monitoring in live use. It is the item most often left out of budgets — and when it is, every other item risks being wasted.
The effort depends on:
- How many real examples go into the test set?
- Who scores accuracy, and how?
- Are tests rerun after every change?
- Which indicators are watched in live use?
How such a set-up is built is covered in how to evaluate an AI system.
6. Maintenance and operation: what happens after launch?
Maintenance is the ongoing work that keeps the system right after launch. For AI systems it runs somewhat higher than for conventional software.
The reasons:
- Model versions change. Providers update models and retire old versions. Each change means rerunning the tests.
- Data goes stale. Documents are revised and products change; keeping sources current needs an owner.
- Usage shifts. People start asking questions nobody asked in the first weeks.
- Cost needs watching. As usage grows, so does the model bill. Spending limits and alerts need regular review.
We cover the ongoing security work in hallucination, data privacy and human approval.
One-off and recurring items
| Item | One-off or recurring? | Depends on |
|---|---|---|
| Scope and architecture work | One-off | Number of tasks and roles |
| Data preparation | Mostly one-off; updates recur | How scattered the data is |
| Integration | One-off; upkeep recurs | Number of systems; read or write |
| Test set and measurement | Set-up one-off; runs recur | Number of examples; scoring method |
| Model usage | Recurring | Calls, context length, model choice |
| Hosting and logs | Recurring | Data volume, retention period |
| Maintenance and model changes | Recurring | Provider changes, growth in use |
What pushes cost up, and what brings it down
| Pushes it up | Brings it down |
|---|---|
| A broad first release doing many jobs | A pilot built around one task |
| The most capable model for everything | Matching the model to the task |
| Sending whole long documents | Sending only the relevant passage |
| Unlimited agent loops | Step and spending limits |
| Scattered, conflicting sources | Current sources with a named owner |
| Many integrations with write access | Starting with read access |
| Launching without measurement | A test set built from the start |
What to prepare before asking for a proposal
- A one-paragraph description of the task the system will do.
- How often the task is done today — per day, per week.
- Ten to twenty real examples from the task’s history, each with the correct outcome.
- A list of systems to connect to, with a “read or write?” note for each.
- Who will use the system, and who may see what.
- Whether personal data is involved.
- The number you will use to judge success.
With this list ready, you can compare proposals on the same footing. How to read the proposal itself is covered in how to read a software proposal.
Frequently asked questions
Why don’t you publish a price list?
Because two jobs under the same heading can need very different effort depending on the answers to these six factors. A list price would either make one client overpay or start another with too little scope. We clarify the scope together in the first conversation and prepare a written proposal.
Can the model fee be estimated in advance?
Once real usage has been measured during a pilot, a reasonable estimate is possible. With the average number of calls and context length per request known, monthly usage can be worked out from the provider’s published prices. Spending limits stop the estimate being exceeded.
Is a model running on our own servers cheaper?
It depends. A model on your own infrastructure removes per-use fees but brings hardware, set-up and maintenance. The decision weighs usage volume, privacy requirements and whether the model is good enough for the task.
What is the most effective way to reduce cost?
Narrow the scope, and measure. A pilot built around one task, with its success criterion written in advance, removes unnecessary work at the earliest stage. The second is choosing the smallest model that does each job well enough.
Is maintenance really necessary?
For AI systems, yes. Model versions change, sources go stale and the way people use the system shifts over time. A system without maintenance will not keep the accuracy it had on launch day.
If you would like to work out the scope and cost items of your own project together, see our AI systems architecture page or write to us.