How Much Does It Cost to Maintain an AI Assistant? The Line Items to Consider

The development quote for an AI assistant is the part people most enjoy reading, because it's a single number with an end point. The cost that actually decides whether the project makes sense, though, is the one that repeats every month, and it's made up of items that often don't appear in any document until the day they show up.

This guide is about building the list of items and turning them into an estimate using your own volumes. You won't find prices here: they change, and a number written today would be wrong within a few months. They should be taken from the price lists in effect on the day you decide, attached to the document and dated.

Three phases that aren't paid for the same way

Before estimating, it's worth separating what you pay once from what repeats. These are three distinct blocks, and they're often presented as one.

• Build: integration with your systems, permissions, interface, logs. Paid for once, and paid for again in part with every subsequent change.
• Data preparation: gathering, cleaning, structuring, deciding what the assistant can read and what it can't. It's the most underestimated item of all, and the only one that depends entirely on the state of your documents.
• Testing and tuning: a sample of cases, corrections, a second round of testing. It isn't a formal certification: it's the work that decides whether the system is usable.

Data preparation is a one-time cost if the sources are stable, and becomes a recurring item if they change. A price list updated every quarter, a manual that changes along with the products, an internal policy that gets revised: each of these moves an item from the first block to the third.

The recurring cost items

This is the list to fill in with your own numbers. No row is optional: the ones you decide not to fund stay uncovered, and sooner or later they show up in the form of a malfunction.

The last two rows almost always get confused with each other. The hours budget for keeping what already exists running isn't the same thing as a request to make the assistant do something new. Keeping them in the same chapter makes maintenance disappear, because the new features eat up the budget — and maintenance that doesn't happen gets paid for anyway, later and worse.

Cost per unit is the only comparable figure

The monthly total doesn't tell you whether it's worth it, because it isn't comparable to anything. What you need is a cost per unit of work: per conversation handled, per document read, per case routed.

1. Choose the unit: it has to be something someone does by hand today and that can be counted.
2. Estimate how many units per month, across three scenarios, starting from the volume you have now.
3. Calculate the variable part per unit: model usage and the external services called.
4. Add the fixed costs divided by the number of units in that scenario.
5. Compare it with how much the same activity costs today done by hand, including error corrections.

The fourth step explains why, at low volumes, the cost per unit is high: infrastructure, monitoring, and supervision get divided across few units. That's why a project that makes sense in the long run can look uneconomical in the early period, and it needs to be said upfront rather than discovered later.

Three scenarios, with your own volumes

A three-scenario model is built like this. The figures below are illustrative and are meant to show the shape of the calculation, not to produce your actual quote: in place of V, put the monthly volume you have today.

The interesting comparison isn't between the totals of the three scenarios, but between the costs per unit. If the cost per unit doesn't drop when moving from one scenario to the next, there's something to revisit in the structure before increasing volumes: it's almost always the amount of data sent with each request, or supervision that grows proportionally instead of in steps.

The items that show up later

Some items don't exist at the time of the quote and show up in the months that follow. It's worth naming them upfront, even without putting a number on them.

• Growth of the document archive and its connected search indexes.
• Log retention for the period you've decided on or that's required of you.
• Increased context: more searchable documents means more cost for every single request, even if the number of requests doesn't increase.
• Edge cases that emerge from real-world use, which require new rules and new testing.
• Training for people who join the company after launch.
• Adjustments due to changes in connected systems or in vendors' terms.

When the estimate can't be made yet

In some situations, any number would be made up, and the right next step isn't a quote.

• You don't know how many requests you receive today: count them for a few weeks, it's a quick piece of work.
• It isn't clear what the assistant is supposed to do: an undefined scope produces undefined usage, because any request can turn into anything.
• The source documents don't yet exist in a readable form: until you know how much work it takes to prepare them, the biggest item stays uncovered.
• No one can say how much it costs today to do the same activity by hand: without that point of comparison, the estimate isn't useful for deciding anything.

In these cases, the way forward is a pilot project with a limited sample, a stated duration, and a decision set from the start on what would make it continue or stop. It costs less than a quote built on assumptions.

What this guide doesn't cover

This guide covers the structure of the running costs of an AI solution. The broader comparison between a software project's build cost and its running cost over time is covered in its own dedicated guide; how to set up a pilot project, with a goal, a sample, and a decision criterion, also has a guide of its own. Price figures don't appear in this guide because they need to be taken from the price lists in effect on the date you make your estimate.