How much does an AI project cost?

01

Separate the pilot, the product and ongoing operations

The cost question often starts with an idea: an internal assistant, a search across company documents, information extraction or an automated workflow. Estimating it means turning the idea into observable work. Who will use it? With which information? What should a person do when an answer is incomplete?

A trial that produces a convincing answer and a feature used every day have different scopes. The first tests a hypothesis. The second also needs access management, error handling, updates and service continuity. We recommend separating these stages in the proposal so that decisions about the next step are based on observed results.

02

Define the task and the level of autonomy

“Add AI” does not describe a feature. Drafting a reply, classifying requests and triggering an action in a business tool are three different jobs. For each one, specify the starting point, the expected result and the person who remains responsible for it.

Autonomy also changes the work required. A draft reviewed before use has different consequences from an automatic CRM update. Once an action affects a business tool, discovery should cover permissions, approval, an action history and recovery from errors. If a conventional rule can solve the task, it belongs among the options considered.

03

Review data and the tools to connect

Before choosing a model, inventory the information that is actually useful: documents, tickets, a catalogue, customer records or procedures. Check formats, currency and who is authorised to read it. Content in a shared folder may still require cleaning, selection and organisation.

Searching company documents can supply relevant passages to a model when a request is made. This requires organising sources, updates and access rights; it is not automatically model training. The scope should also identify available APIs, test environments and the people who will maintain each connection.

04

Estimate recurring costs from actual usage

For a generative model API, usage depends in part on the information sent and the answer produced. These volumes are generally measured in tokens, processing units that do not correspond exactly to words. A long conversation history or many attached documents can therefore affect a call even when the user’s question is short.

Some features, such as web search or tool use, can add billing items. Conditions vary by provider and configuration, so check the relevant documentation when estimating. The operating budget should also distinguish hosting, storage, technical monitoring and the human review time your use case requires.

Prepare several volume scenarios: normal use, a busy period and broader adoption. Estimate the number of tasks, calls and possible retries for each one. Plan alerts and an operational limit, then compare those assumptions with the pilot’s consumption. A solution hosted by your own organisation instead needs an estimate of the resources and skills required to operate it.

05

Plan evaluation before expanding

A plausible answer is not enough to validate a use case. Generative models can produce different answers to the same request. Prepare representative cases, including difficult situations, and define success criteria with the people who will use the solution. Repeat those evaluations when instructions, data or the model change.

The pilot should support a decision: continue, adjust the scope or stop. Compare results with the current process, including review and correction time rather than generation time alone. Also document when the system should ask for clarification or hand the task to a person.

06

Example: helping a support team draft replies

Imagine a team that searches several internal procedures before answering incoming requests. Its initial need is an assistant that drafts replies from approved documents. In the first version, the user selects a request, checks the suggested passages and approves the draft before anything is sent.

A pilot can begin with a limited set of documents and a sample of requests. It helps establish whether the right information is found and whether drafting requires less work than the current process. Connecting the support tool, synchronising documents and managing multiple teams are separate decisions to estimate afterwards.

07

Prepare a brief that makes quotes comparable

To obtain a useful estimate, prepare a description of the current process, example requests, available sources and relevant software. Add the people who need to participate, scheduling constraints and the outcome that would make the pilot successful. This helps separate what is known from what still needs testing.

Ask for a proposal that separates discovery, the pilot, integration and operations. Volume assumptions, deliverables, exclusions and responsibilities should be visible. A demonstration, an operational application and ongoing support cannot be compared on an isolated total alone.

To assess value, establish a baseline: effort spent on a task, turnaround time, errors or cases processed. Then observe what changes, including review and maintenance. This comparison supports a gradual investment without turning an assumed benefit into a promise.